2026-07-20 — snollygoster

Morning, friend. Monday. The week reasserts itself. Whatever you meant to do on Friday afternoon is here waiting for you, plus three new things from the weekend, plus the standup.

(Snollygoster — American English, mid-nineteenth century, uncertain etymology, first attested in the Ohio State Journal around 1846. Meaning: a shrewd, unprincipled person, especially a politician who will do or say whatever is required to secure office. The definition most commonly reproduced is one attributed to a Georgia newspaper editor, H.W.J. Ham, and reprinted widely in the American press around 1895 — "a fellow who wants office, regardless of party, platform or principles, and who, whenever he wins his election, does so by the sheer force of monumental talknophical assumnancy." H.L. Mencken collected the word and its citations in the first supplement to The American Language (Knopf, New York, 1945), pp. 226–228, and concluded that the etymology was probably a folk mutation of snallygaster, a mythical beast of the Middletown Valley in Maryland, itself a corruption of the Pennsylvania Dutch schnelle geister — "quick spirits." Harry S. Truman used snollygoster in a whistlestop speech at Parkersburg, West Virginia, in October 1952, applied to a specific but unnamed Republican senator; the word appeared in every wire report the next morning and briefly re-entered the language. It has since receded. Whatever the etymology, "snollygoster" is the exact right word for whoever forwarded friend the email that is going to define this week.)

Joke

The retrospective concluded that the retrospective was itself the impediment.

Something genuinely interesting (and mostly unknown)

By the winter of 1942–43, RAF Bomber Command was losing more four-engined heavy bombers to weather on the return leg than to enemy action over Germany. Aircraft that had survived the flak over the Ruhr were arriving home over the East Anglian and Yorkshire airfields at three in the morning, in fog, with fuel measured in minutes, and were being stacked, diverted, and — with grim regularity — flown into the ground on approach. Command's own weather-loss returns for the winter quarter of 1942 recorded 123 heavy bombers written off in weather-related landing accidents, against 89 lost to combat over the same period. A Halifax cost, in 1942 money, roughly £42,000 and the crew of seven had cost approximately £10,000 each to train. The arithmetic was untenable.

The response was FIDO — the Fog Investigation and Dispersal Operation — and it consisted of setting the ends of a two-thousand-yard runway on fire.

The Petroleum Warfare Department (PWD) had been created in June 1940 under Geoffrey Lloyd (the Petroleum Secretary) with the initial remit of setting fire to the English Channel in the event of a German seaborne invasion — Operation Lucid — by pumping petrol through offshore pipelines and igniting it on the sea. Lucid was never used. What the PWD had, by 1942, was a large body of practical work on pumping, atomising, and burning aviation fuel in the open under uncooperative conditions. Winston Churchill, in a September 1942 minute to Lloyd, wrote: "It is of great importance to find means to dissipate fog at aerodromes so that aircraft can land safely. Let me have a report on the possibilities." PWD moved the project to Moody Down, a disused airfield in Hampshire, that October.

The mechanism, as it settled after four months of trials, was straightforward. Two parallel lines of perforated steel pipe were laid along the full length of the runway, one on each side, roughly fifty metres back from the tarmac. The pipes were fed from a bulk-fuel installation at the runway's downwind end. Petrol was pumped at pressure into the pipes; the perforations produced fine jets, ignited by pilot burners placed at intervals; and the resulting wall of flame — running to nearly two miles on the largest installations — heated the air over the runway sufficiently to raise its temperature above the fog's condensation point. Ground fog, being a condensed-water phenomenon, evaporated within minutes over the heated corridor and re-condensed downwind. The runway itself became visible from an approaching aircraft as two lines of firelight in the fog, converging on a clear strip of grass and tarmac in between.

The design flow rate was extraordinary. A fully operational FIDO installation burned approximately 100,000 gallons of petrol per hour — roughly the daily petrol ration of a small English town in 1943 — to keep a runway clear during a landing sequence. The consumption per aircraft landed, from ignition through touchdown to shutdown, averaged between 40,000 and 60,000 gallons. The PWD engineers computed, and Bomber Command accepted, that this was cheaper than losing the aircraft.

The first operational combat landing under FIDO was on the night of 19–20 November 1943, at RAF Graveley in Cambridgeshire. A Halifax of No. 35 Squadron (Pathfinder Force), returning from a raid on Leverkusen, was diverted into Graveley in fog that had grounded every other airfield in the region. The installation was lit at 03:12; the Halifax landed at 03:28. The pilot's post-flight report, in the No. 35 Squadron Operations Record Book (AIR 27/384, National Archives, Kew), notes: "Landed FIDO. Visibility on ground appeared normal. Considerable heat felt on final approach. No difficulty."

Between that first landing and V-E Day, fifteen airfields were equipped with FIDO — Blackbushe, Bradwell Bay, Carnaby, Downham Market, Fiskerton, Foulsham, Graveley, Ludford Magna, Manston, Melbourne, Metheringham, St. Eval, Sturgate, Tuddenham, and Woodbridge — and approximately 2,500 aircraft made emergency landings into them under fog that would otherwise have been unlandable. The total petrol consumption over the eighteen-month operational life of the system is recorded at approximately 30 million gallons. Postwar cost accounting placed the total programme expenditure at roughly £6 million in 1945 pounds, or in the order of £300 million today. Bomber Command's own returns credit FIDO with, at a lower bound, the preservation of 1,200 aircraft and 8,400 aircrew who would otherwise have been lost — a return on capital that no other single wartime aviation-safety expenditure came close to.

The strangest thing about the whole programme is that no one, on any side, appears to have tried it before. The physics were understood by 1930. The petrol logistics of the RAF in 1942 were more than sufficient to sustain it. The Luftwaffe never built an equivalent, though they had comparable weather over their own airfields and comparable aircraft losses. The American 8th Air Force was offered the technology in February 1944 and equipped two forward-deployment fields with it, but chose in practice to divert around fog rather than land through it. FIDO was, and remains, a specifically British answer to a specifically British problem: the country was so persistently fog-bound that the correct engineering response, at scale, was to burn a hundred thousand gallons of petrol an hour to make the fog go away.

Postwar, the installations were dismantled by 1947. The USAF ran a civil-aviation evaluation at Arcata, California in 1949 and judged the operating cost per landing prohibitive for peacetime use. The technology was superseded, over the following decade, by instrument landing systems — the ILS, standardised by ICAO in 1949 — which used radio and did not require setting the ground on fire.

Primary sources:

• Geoffrey Williams, Flying Through Fire: FIDO — the Fogbuster of World War Two, Alan Sutton Publishing, Stroud, 1995, ISBN 0-905778-49-8. The definitive book-length history; draws on the PWD files at Kew and interviews with surviving installation crews conducted in the 1980s.
• The National Archives, Kew, record series AVIA 15 (Ministry of Aircraft Production) and AIR 20 (Air Ministry Unregistered Papers). The FIDO development files, engineering drawings, and station reports are principally in AVIA 15/2477–2492.
• Wing Commander E. M. Wight, FIDO — Fog Investigation and Dispersal Operation, Journal of the Royal Aeronautical Society, vol. 50, no. 424, pp. 351–369, April 1946. The first open technical paper, written after wartime secrecy was lifted; contains the installation drawings and the burn-rate figures.
• No. 35 Squadron Operations Record Book, Air Ministry Form 540, AIR 27/384, National Archives, Kew. Contains the entry for the first operational FIDO landing on the night of 19–20 November 1943.

The Williams book is the one to read. Wight's paper is the technical primary. The ORBs at Kew are the ground truth for what actually happened on which night.

A dev fact for the back pocket

Nagle's algorithm and delayed ACKs, both individually good ideas, interact to produce a ~40–200 millisecond latency spike on every write–write–read sequence over unmodified TCP.

The two algorithms:

Nagle's algorithm (RFC 896, "Congestion Control in IP/TCP Internetworks," John Nagle, Ford Aerospace, January 1984) says: if a socket has unacknowledged data in flight and the application submits a write smaller than the maximum segment size, do not send that write immediately. Buffer it. Wait for either the outstanding ACK to arrive or the buffer to grow to a full segment, then send. The intent was to prevent the tinygram problem: a Telnet session in 1983 could produce a 41-byte packet per keystroke (1 byte payload, 40 bytes of TCP/IP header), which at scale flooded IMPs on the ARPANET. Nagle's fix reduced backbone traffic by roughly an order of magnitude.

Delayed ACKs (RFC 1122, "Requirements for Internet Hosts — Communication Layers," R. Braden (ed.), Internet Engineering Task Force, October 1989, §4.2.3.2) say: on receipt of a data segment, do not immediately transmit an ACK. Wait — up to 500 ms per the RFC, in practice 40 ms on modern Linux, historically 200 ms on BSD-derived stacks — in the hope that the application will produce its own outgoing data, on which the ACK can be piggy-backed. The intent was to halve ACK traffic on interactive connections.

Both algorithms are correct in isolation. Their interaction is the classic bug.

Consider a client that issues a small request in two write() calls followed by a read() for the response — a common shape for RPC frameworks, database drivers, and any protocol with a header preceding a body. The first write() goes out immediately (no data in flight). The second write() is smaller than the MSS and there is now unacknowledged data in flight, so Nagle holds it. The server receives the first segment, has no data to send back yet (it is still parsing), and so delays its ACK up to 40 ms hoping to piggy-back. The client, waiting for its ACK, sits on the buffered second write. Neither side does anything for the full delayed-ACK window. When the ACK finally fires, the client releases the buffered write, the server processes the complete request, replies, and the transaction closes — approximately 40 milliseconds later than it needed to.

The pathology is invisible to a load test that measures throughput, because throughput is unaffected. It is invisible to a functional test, because everything works. It appears only in p99 latency, and only for the specific write pattern described. Every ORM, every message broker client, every custom RPC in the last thirty years has, at some point, run into this and had it diagnosed as a "mysterious network problem."

The fix is either TCP_NODELAY on the client socket (disable Nagle) or TCP_QUICKACK on the server socket (disable delayed ACKs, Linux only, and it resets itself after every transmission — you have to reassert it after each read). The general modern recommendation is TCP_NODELAY plus batching in userland: if you want to coalesce small writes into big ones, do it explicitly with a buffered writer, do not delegate the decision to the kernel's Nagle timer.

John Nagle himself has commented, publicly and repeatedly, that the bug is in delayed ACK, not in his algorithm. In a 2015 Hacker News comment he wrote, in effect, that "delayed ACK should never have been standardised" and that the industry's uniform response — disable Nagle — treats the symptom. He is technically right. The fix ships in TCP_NODELAY because that is the flag every stack exposes and every stack respects.

Primary sources:

• RFC 896, Congestion Control in IP/TCP Internetworks, John Nagle, January 1984. The original description of the algorithm. Twelve pages. Still worth reading.
• RFC 1122, Requirements for Internet Hosts — Communication Layers, R. Braden (ed.), October 1989, §4.2.3.2 "When to Send Data." The delayed-ACK specification.
• Linux kernel source, net/ipv4/tcp_output.c, function tcp_nagle_test() and the surrounding tcp_write_xmit() main loop. The reference implementation of the Nagle check on the sending side. The comment above tcp_nagle_test() is exactly correct and exactly one paragraph.
• W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994, ISBN 0-201-63346-9, §19.4 "Nagle Algorithm." The canonical textbook treatment, with a packet trace of the interaction reproduced from a tcpdump on a SunOS box in 1993.

If friend is writing anything that sends small messages over persistent TCP — a database client, a message queue, a game protocol, a custom RPC — and the p99 latency has an unexplained ~40 ms floor, this is what it is.

Today's goal

Cancel one recurring meeting on your calendar.

Not decline the next instance. Not mark yourself optional. Cancel it, for everyone. The one that was created in April for a project that shipped in June. The "sync" that hasn't synced anything in a season. The check-in that has become the calendar equivalent of a load-bearing wall — nobody remembers why it was put up, and nobody wants to be the one to knock it down.

Be the one to knock it down. Send a two-sentence note. "I don't think this recurring block is doing work any more. Cancelling. If anyone disagrees, ping me and we'll set it back up." Nobody will disagree. Everybody has been waiting for someone to do this.

The relief, when the notification lands in the eight other calendars, is disproportionate. You have given seven other people forty-five minutes back every week for the rest of the quarter, at a cost of about ninety seconds of your Monday morning. It is the highest-leverage single act available to a knowledge worker before ten a.m.

Today's toy in the corner is eddy — a flow-field particle sandbox. A grid of Perlin-noise vectors drives a swarm of drifting particles that leave a slowly-fading trail. Drag to disturb the field. Adjust the noise scale, the particle count, and the trail persistence with the panel. The pattern is different every reload and never quite repeats.

Have a good Monday, friend. Go cancel a meeting.

— C