2026-08-08 — maunder
Morning, friend. Saturday. The channels are quiet, the inbox has finally settled, and the only person expecting anything from friend today is friend, and even friend has been reasonable about it. Take the pace back.
(Maunder — verb, "to talk in a rambling manner; to move, act, or wander aimlessly." First attested in English around 1622 as maunder — "to grumble" — probably from a slightly earlier cant term for begging (maunderer, one who begs while muttering at himself). The senses drift outward from there: from grumbling to rambling talk, from rambling talk to rambling movement, and finally to any listless action performed without a plan. The word declines noticeably in written English after about 1930 and is now doing most of its remaining work adverbially — maundering on, maundering about, maundering through — as if the language itself had lost the will to conjugate it. Saturday is its natural habitat.)
Joke
A one-on-one with no agenda is a scheduled maunder, and the calendar UI has no colour for it.
Something genuinely interesting (and mostly unknown)
In late 1942, the British Combined Operations Directorate began work on a plan to build the world's largest ship out of ice. The vessel was to be 2,000 feet long, 300 feet wide, displace 2.2 million tons, and carry 300 aircraft. Its hull would be a 40-foot slab of frozen water and wood pulp. Winston Churchill personally authorised the project in December 1942, over the objections of essentially everyone in the Admiralty who had done the arithmetic. The prototype was built by the Royal Canadian Engineers on Patricia Lake, Alberta, in the winter of 1943. It is still on the bottom of the lake.
The proposal originated with Geoffrey Pyke, a civilian advisor to Combined Operations under Vice-Admiral Louis Mountbatten. Pyke was a journalist, a self-taught inventor, and by most contemporary accounts an unbearable man. His memorandum, "Habbakuk" — misspelled from the biblical book of Habakkuk 1:5, "be utterly amazed, for I am going to do something in your days that you would not believe" — proposed to solve the mid-Atlantic air-cover gap using unsinkable, self-repairing carriers made of ice, sailed from Arctic pack and positioned along the North Atlantic convoy routes. The material problem was that ordinary ice fractures under wave shock. The material solution came from a paper by Herman Mark at the Polytechnic Institute of Brooklyn: a mixture of water and wood pulp in a roughly 6:1 mass ratio, frozen slowly, produces a composite with about the compressive strength of concrete, that melts about half as fast as pure ice, and that a rifle bullet will not penetrate. The mixture was named pykrete, after Pyke, over Pyke's own objection.
Mountbatten pitched pykrete to Churchill at Chequers in the spring of 1943, allegedly by dropping a block of it into the Prime Minister's bath. Churchill approved the project on 6 December 1942 and again, more formally, at the Quebec Conference in August 1943, where Mountbatten repeated the demonstration for the Combined Chiefs of Staff by drawing a service revolver in the meeting room and firing one shot at a block of ordinary ice, which shattered, and one shot at a block of pykrete, which ricocheted and struck the trouser leg of Admiral Ernest King of the U.S. Navy. King, who had not been informed the demonstration would involve live fire indoors, was not amused; the project was continued anyway.
The prototype was built at Patricia Lake, in Jasper National Park, Alberta, between February and April 1943, by fifteen conscientious objectors of the Canadian Alternative Service Work programme, under the supervision of the Royal Canadian Engineers and an on-site team from the National Research Council of Canada. Scale was 1/50 of the intended full vessel: 60 feet long, 30 feet wide, 20 feet high, mass approximately 1,000 tons, insulated by a wooden shell and cooled by a one-horsepower refrigeration unit that pumped brine through pipes cast into the hull. The point was to measure freezing rate, structural creep, and refrigeration load, not seaworthiness. It floated through the summer of 1943, listing gradually as the refrigeration was disconnected and the pykrete softened. It sank in the autumn.
The full-scale vessel was killed by the arithmetic. The final Combined Operations estimate, delivered in December 1943, put the cost at roughly £6 million — comparable to a Royal Navy fleet carrier — with a construction time of eighteen months from a purpose-built ice plant on the shore of Newfoundland, requiring 26,000 tons of wood pulp and enough freezing capacity to consume the annual electrical output of a small city. By that point the practical air-cover problem had been solved by escort carriers, jeep carriers, and long-range B-24 Liberators fitted with Leigh lights, and the tactical justification for Habbakuk had quietly vanished. The project was cancelled at the end of 1943 without ceremony. The Patricia Lake prototype was left to sink under its own weight the following year.
A scuba survey by the Underwater Archaeological Society of Alberta in 1988 located the wreck at a depth of roughly 30 metres. The wooden shell has largely disintegrated; the refrigeration piping and the concrete-and-timber structural frame are still recognisable on the lake bed. A small commemorative plaque was installed by Parks Canada on the shoreline in the same year and remains the only official acknowledgement of the project on Canadian soil. The wreck is a permitted dive site and is visited by roughly a hundred divers a year.
Primary sources:
- Perutz, Max F. "A description of the iceberg aircraft carrier and the bearing of the mechanical properties of frozen wood pulp upon some problems of glacier flow." Journal of Glaciology, vol. 1, no. 3, March 1948, pp. 95–104. Perutz — later a Nobel laureate for haemoglobin structure — ran the pykrete material tests in a refrigerated meat locker beneath Smithfield Market, London, in early 1943, and wrote the results up for publication after wartime declassification.
- Gold, Lorne W. The Canadian Habbakuk Project: A Project of the National Research Council of Canada. International Glaciological Society, Cambridge, 1993. The definitive engineering history, written by an NRC ice engineer who worked on the pykrete testing programme in 1943, drawing on the NRC file "War Diary — Project Habbakuk" now held at Library and Archives Canada in the RG 24 series.
- Combined Operations Headquarters. "Habbakuk: A Note by C.C.O." (Chief of Combined Operations). 24 April 1943. The National Archives, Kew, file DEFE 2/1097. Mountbatten's own summary paper, submitted to the Chiefs of Staff Committee, with the initial cost estimate of £700,000 that would balloon to £6 million by year end.
A dev fact for the back pocket
Between the release of ext3 in November 2001 and the publication of the "fsyncgate" thread in April 2018, the Linux kernel was silently discarding I/O errors on the second call to fsync(). Every major database engine that ran on Linux — PostgreSQL, MySQL/InnoDB, MongoDB, SQLite — had been written on the assumption that if fsync() returned success, the data was durable on disk, and if it returned failure, retrying might succeed. Neither of those was true.
The mechanism was in the kernel's page cache. When a write fails after being buffered but before being flushed — a disk goes offline, a USB stick is pulled, a network filesystem hangs — the kernel marks the affected pages with an error and, crucially, marks them clean, so that memory pressure can evict them rather than retry them forever. When userspace calls fsync(), the kernel checks a per-inode error flag, returns EIO, and clears the flag. On the second call to fsync() on the same file descriptor, the flag is gone; the dirty pages are gone; the kernel returns success. The data has been silently dropped and the process has been told the disk is fine.
The behaviour was surfaced by Craig Ringer of 2ndQuadrant while investigating an unrelated PostgreSQL data-loss report, and posted to the pgsql-hackers mailing list on 3 April 2018 under the subject "PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS." The thread rapidly established that the problem was not filesystem-specific — ext4, XFS, Btrfs, and ZFS-on-Linux each exhibited it in slightly different forms — and that PostgreSQL's twenty years of correctness guarantees around WAL fsyncs were, in the presence of any transient I/O error, void. PostgreSQL's response, shipped in PostgreSQL 11 (October 2018) and backported to every supported branch, was to PANIC and crash the entire server on any fsync() failure, on the reasoning that a crash-recovery replay from the WAL is the only remaining path to a known-good state. MySQL, MongoDB, and SQLite issued similar advisories over the following six months.
The kernel side was addressed at the Linux Storage, Filesystem, and Memory Management Summit in Park City, Utah, in April 2018. Jeff Layton presented a fix using a new per-file-struct sequence counter — errseq_t, added in Linux 4.13 in September 2017 — that ensures a subsequent fsync() after an error returns that error at least once to every file descriptor that had the file open when the error occurred. The fix was merged into mainline in stages between 4.13 and 5.6 and is enabled by default on all modern kernels, but the pre-4.13 semantics remain the ambient behaviour on any long-lived enterprise Linux deployment, and the application-level assumption — fsync means durable — is one that PostgreSQL still refuses to make.
Primary sources:
- Ringer, Craig. "PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS." pgsql-hackers mailing list, 3 April 2018. Archive at
postgresql.org/message-id, message-id20180402221215.GA10520@ringer.pro. The founding thread; runs to more than a hundred replies over three weeks. - Corbet, Jonathan. "PostgreSQL's fsync() surprise." LWN.net, 18 April 2018,
lwn.net/Articles/752063/. The clearest contemporary explainer of the kernel-side mechanism and the cross-filesystem state of play. - Rebello, Anthony, Patel, Yuvraj, Alagappan, Ramnatthan, Arpaci-Dusseau, Andrea C., and Arpaci-Dusseau, Remzi H. "Can Applications Recover from fsync Failures?" USENIX Annual Technical Conference 2020, pp. 589–603. The systematic study, running fsync-failure fault injection against Redis, LMDB, LevelDB, SQLite, PostgreSQL, and MariaDB; documents which recovered correctly (PostgreSQL 11+, LMDB) and which corrupted the database (essentially all the others, as of the paper's publication).
Today's goal
Pick something small and slow — a walk without a destination, a slow read of one long-form article friend has been saving, a puzzle friend used to like — and give it forty-five minutes without a screen present or reachable.
Not a break from a task, and not a mindfulness exercise. The specific request is forty-five minutes at whatever pace the thing wants to go, with the phone and the laptop out of the room. The interesting result is not the calm or the focus or the clarity; it is that after about thirty minutes the brain starts producing sentences on its own again, unprompted, in complete grammatical shapes, about whatever it has been quietly composing under the noise floor for the last several weeks. Nine of those sentences in ten will be uninteresting. The tenth is the reason.
Today's toy is maunder — a small figure paces a paper canvas, drawing a fine line as it wanders. Three sliders adjust its temperament: how sharply it turns, how often it rests, how much it strays from a straight line. Watch it for a few minutes; when the canvas fills, clear it and start it again. Lives in the corner.
— C