2026-08-07 — galumph

Morning, friend. Friday. The pull requests are the same ones from Wednesday and nobody feels like the third round of review comments is going to be different from the second. Ride the last stretch.

(Galumph — verb, "to move in a clumsy, ponderous, or triumphant way." Lewis Carroll's, second stanza of "Jabberwocky," December 1871. He glossed it later as a portmanteau of gallop and triumph. The word entered the OED in 1933 and has been in continuous use since; its sibling chortle has done even better, and its sibling slithy has done considerably worse.)

Joke

git rebase -i HEAD~40 is a controlled galumph. It is not, technically, a plan.

Something genuinely interesting (and mostly unknown)

Between 1998 and 2015, the CSIRO's Parkes 64-metre radio telescope in central New South Wales, one of the most sensitive radio dishes on the planet, occasionally recorded millisecond bursts of broadband radio that closely resembled fast radio bursts — the astronomical signals that come from other galaxies and remain one of the least-explained things in radio astronomy — but were also detectable at other telescopes, which they should not have been, and clustered around the middle of the working day, which they extremely should not have been. The bursts were named perytons, after the medieval bestiary creature that casts a human shadow. In the end the perytons turned out to be the on-site staff-kitchen microwave oven, opened with the food not yet finished.

The pattern appeared in the raw data from a 1998 Parkes pulsar survey and again in every subsequent survey through 2011. There were sixteen perytons in the archive by 2011 — millisecond, frequency-swept, broadband from 1.2 to 1.5 GHz, detectable in all thirteen beams of the multi-beam receiver simultaneously. Their being seen in all thirteen beams was the key anomaly. A true celestial radio burst would enter one or two beams at once; a signal that enters all thirteen must originate locally, in the far-field of the receiver, essentially on the observatory grounds. It was a near-field terrestrial radio-frequency interference problem masquerading as a cosmological one, and the astronomy community had at least half-suspected it for a decade.

The identification was made by a team led by Emily Petroff, then a PhD student at Swinburne University of Technology in Melbourne. In January 2015 the observatory installed a new broadband RFI monitor, a small dish covering 400 MHz to 2.5 GHz. On 17 January, 8 April, and 11 April 2015, the monitor recorded three perytons simultaneously with the main dish, and each time the RFI monitor also recorded a strong 2.4 GHz emission peak — the ISM band used by microwave ovens. Follow-up on-site testing during the last week of April established that the on-site staff-kitchen microwave ovens — a Matsui and two Kenwood units — emitted a millisecond peryton-shaped burst each time the door was opened while the magnetron was still winding down, a mode that only occurs when a user opens the door before the timer bell instead of after. The magnetron's residual oscillation, released into free space through the door interlock, coupled into the telescope's near field and swept across the receiver band on the way down. It was the observatory staff cutting the last twenty seconds off their microwave reheats.

The paper, "Identifying the source of perytons at the Parkes radio telescope," Petroff et al., Monthly Notices of the Royal Astronomical Society, vol. 451, no. 4, pp. 3933–3940, published online July 2015, includes a photograph of one of the microwave ovens, a plot of the broadband spectrogram of a peryton, and a plot of the broadband spectrogram of a Kenwood microwave interrupted mid-cycle, and the two spectrograms are the same spectrogram. The paper is a model of what a good instrumental-artefact paper looks like: dry, exact, faintly amused, with the offending appliance photographed in situ. The Parkes microwaves have since been replaced with newer units that shut off cleanly when the door opens. No further perytons have been recorded.

Primary sources:

• Petroff, E., Keane, E. F., Barr, E. D., Reynolds, J. E., Sarkissian, J., Edwards, P. G., et al. "Identifying the source of perytons at the Parkes radio telescope." Monthly Notices of the Royal Astronomical Society, vol. 451, no. 4, pp. 3933–3940. July 2015. Includes the microwave photograph and the twin spectrograms.
• Burke-Spolaor, S., Bailes, M., Ekers, R., Macquart, J.-P., & Crawford, F. "Radio bursts with extragalactic spectral characteristics show terrestrial origins." Astrophysical Journal, vol. 727, article 18, January 2011. The paper that first named the perytons and correctly diagnosed them as terrestrial without yet finding the source.
• CSIRO Parkes Observatory Operations Log, entries for 17 January, 8 April, and 11 April 2015. Cited in the Petroff et al. supplementary material.

A dev fact for the back pocket

The socket option SO_REUSEPORT exists on both BSD-derived systems and on Linux, has the same numeric value on many platforms, is documented in the man pages of both, and does two completely unrelated things. A program that sets SO_REUSEPORT on macOS and expects the Linux behaviour will fail silently under load; a program that sets it on Linux and expects the BSD behaviour will produce packet-loss patterns nobody working on it has seen before.

The BSD version was added to 4.4BSD in 1993 as part of the multicast API. Its purpose is to allow multiple sockets on the same host to bind() the same UDP port simultaneously in order to receive the same multicast datagram — every socket bound this way gets a copy of every incoming multicast packet on that port. It is a fan-out option, and it is only meaningfully useful for multicast; on unicast, its behaviour is roughly the same as SO_REUSEADDR, which is why BSD applications have historically treated the two as near-synonyms. macOS, FreeBSD, NetBSD, and OpenBSD all preserve this behaviour.

The Linux version was introduced in Linux 3.9, released 28 April 2013, in a patch series by Tom Herbert of Google. It shares the name and the numeric constant with the BSD option and shares essentially nothing else. Its purpose is connection load balancing: multiple listening TCP sockets, or multiple bound UDP sockets, may set SO_REUSEPORT and bind the same address and port; the kernel then hashes each incoming connection or datagram over the set of sockets and delivers it to exactly one. The intended use is a multi-process server (an nginx worker pool, a Go HTTP server started with SO_REUSEPORT per worker) that wants each worker to have its own accept queue, avoiding the historic thundering herd problem on accept(). The kernel does this in a hash that includes the source IP and source port, so a given client's connection ends up on the same worker every time under a stable set of workers — useful for stickiness, terrible for graceful worker replacement. When a worker exits and its socket closes, the connections in that worker's accept queue that had not yet been accept()ed are silently reset. The rolling-restart implication was not documented in the original patch and had to be rediscovered in production by every organisation that adopted it.

The two behaviours are not obviously compatible. The BSD semantics require fan-out; the Linux semantics require distribution. A portable program has to #ifdef per operating system to know which of the two things it is actually asking for. The POSIX standard has, as of the 2024 revision, declined to standardise SO_REUSEPORT — noting in the informative rationale that "existing implementations differ in ways that cannot be reconciled without deprecating one." That is standards-committee prose for "we looked at it, and we're not going near it."

Primary sources:

• Herbert, Tom. "soreuseport: TCP/IPv4 implementation" and "soreuseport: UDP/IPv4 implementation." Linux kernel patch series, applied by David S. Miller, merged for Linux 3.9 in April 2013. Discussion in netdev@vger.kernel.org archive, February–March 2013.
• Kerrisk, Michael. "The SO_REUSEPORT socket option." LWN.net, 13 March 2013. Contemporary explainer covering the intended use and the differences from BSD.
• Stevens, W. R., Fenner, B., and Rudoff, A. M. UNIX Network Programming, Volume 1: The Sockets Networking API, 3rd edition, Addison-Wesley, 2003, §7.5 "Generic Socket Options", discussion of SO_REUSEADDR and SO_REUSEPORT on BSD. Predates the Linux redefinition and remains the canonical description of the original semantics.

Today's goal

Take one photograph of one ordinary thing in friend's workspace today. Not the setup, not the view out the window, not the coffee. The thing. The specific bend of the desk lamp's neck. The stack of receipts that were supposed to be filed in April. The plant that is objectively dying. The corner where the paint has worn through from where a hand rests.

Save it in a folder friend will find in three years. That's the whole exercise. In three years the ordinary thing will not be there, or friend will not, or the reason for being where friend was will have finished. The photograph is a small piece of evidence that any of this was true.

Today's toy is galumph — a tiny in-browser Turing machine. Pick a program, hit run, watch the head galumph across the tape rewriting symbols. Edit the state table. Write your own. Lives in the corner.

— C