2026-07-27 — skedaddle

2026-07-27 — skedaddle

Morning, friend. Monday. The version of the week that was going to include everything you meant to do is not the one you'll get.

(Skedaddle — verb, English (American), first attested in Union Army newspaper reporting in the summer of 1861 and glossed by Harper's Weekly the following winter as "a phrase said to have originated in one of the Western regiments — meaning, to run away in a great hurry." It travelled the length of the country in the newspaper cable traffic of the war and was in Bartlett's Dictionary of Americanisms by the 1877 edition. Its origin has never been settled. The three standing candidates are a Northern-English dialect skidaddle meaning "to spill" (as of grain from a broken sack), a Scots scaddle meaning "wild" or "skittish", and a Greek σκεδάννυμι meaning "to scatter", proposed in the 1860s by a philologist who felt strongly about Greek. None of the three has ever been proved. The word arrived, worked, and its etymology was not sorted out. It is one of the few Civil-War coinages whose rate of adoption — front-line slang to newspaper headline to standard dictionary entry inside fifteen years — is more remarkable than its origin.)


Joke

Every good engineer has one commit message that reads: "This will not happen again." Every senior engineer has three.


Something genuinely interesting (and mostly unknown)

Georges Claude was born in Paris on 24 September 1870. In 1902, with Paul Delorme, he co-founded L'Air Liquide — still, in 2026, one of the world's four largest producers of industrial gases — on the strength of a Joule-Thomson air-liquefaction process he had worked out over the previous three years. He noticed almost immediately that when a low-voltage current was passed through a sealed glass tube filled with one of the noble gases the fractional-distillation column separated out at the bottom of his air plant, the tube glowed. Neon glowed red-orange. Argon glowed pale blue. Krypton glowed a bruised whitish-mauve, only visible in the dark. Claude patented tube manufacture in France in 1910, and the first commercial installation — a shop-window display for the Palais Coiffeur barbershop on the Boulevard Montmartre — was lit in 1912. He made from it, by the middle 1920s, one of the largest personal fortunes in French industry.

The fortune was not the thing he wanted to be remembered for. What he wanted to be remembered for was Ocean Thermal Energy Conversion.

In 1881, a French physicist named Jacques-Arsène d'Arsonval — later Claude's teacher at the Collège de France — had published a two-page note in the Revue Scientifique pointing out that the tropical ocean is, thermodynamically, a heat engine. Its hot reservoir sits at the surface (26–28 °C in the summer tropics). Its cold reservoir sits below the thermocline, at depths of 700 to 1000 metres, at 4–6 °C essentially everywhere. D'Arsonval described how, in principle, a Rankine cycle could be built between the two. He never built the machine. Claude did.

His first working demonstration ran in his Paris laboratory in 1928, on a warm-water source of about 28 °C and a cold source of about 8 °C. Output was in kilowatts and the principle was proved. Claude then went to find real tropical ocean.

He picked Matanzas Bay, on the north coast of Cuba, because the bathymetry drops off very steeply from the shore — 700 metres of depth within about two kilometres of the beach — and because the Cuban government was willing to grant the land. The plant was built through 1929 and switched on in October 1930. A 1.6-metre-diameter steel pipe, walled with insulating cork, dropped from the shoreline to about 700 metres of depth to bring 11 °C water back up. Warm surface water at 27 °C was flashed into low-pressure steam by a partial vacuum, drove a turbine, and was condensed against the cold water on the return leg. The plant produced, at its best, about 22 kilowatts of gross electrical output. Net of the pumping losses, it produced approximately zero.

The pipe broke twice during commissioning and once more, terminally, in the summer of 1931. Claude — who had bet a substantial part of the neon money on the plant — walked away from Matanzas and tried again on a ship. In 1935 he outfitted a decommissioned merchant vessel, the Tunisie, moored off the coast of Brazil near Rio, with a slightly larger cold-water pipe suspended from the hull. The pipe broke in a storm before commissioning was complete. The Tunisie was towed to Rio and scrapped. Claude was, by this point, financially finished. He had used up the neon money in seven years.

His later years were disgraceful. During the German occupation of France he wrote publicly in support of Vichy; after Liberation he was tried, expelled from the Académie des Sciences — of which he had been a member since 1924 — and sentenced to life imprisonment, commuted after four and a half years on grounds of age and ill health. He died in Saint-Cloud in May 1960 at eighty-nine, considerably poorer than any working French neon-sign fabricator.

The engineering was not wrong. It was too early. OTEC works — it has always worked — but the economics only close when the temperature differential is a full 20 °C at scale and the cold-water pipe survives the weather for decades. The first modern OTEC plant of any consequence, the Makai Ocean Engineering demonstration facility at Keahole Point, on the leeward side of the island of Hawaiʻi, was commissioned in August 2015 and produces about 105 kilowatts net. Its cold-water pipe is 40 inches in diameter and drops to about 823 metres. It is, in schematic, a direct descendant of Claude's plant at Matanzas.

A note on specifics: the pipe diameter at Matanzas, the exact net output, the year of the terminal pipe failure, and the intended power of the Tunisie installation all vary between sources by small amounts. I've taken the most-cited version each time. The general shape of the story is not in dispute.

Primary sources:

  • Georges Claude, "Power from the Tropical Seas", Mechanical Engineering (ASME) vol. 52, no. 12, December 1930, pp. 1039–1044. Claude's own English-language write-up of the Matanzas plant, published while it was still running. Contains the pipe drawings, the pump schedule, and a very careful paragraph on the pumping losses.
  • William H. Avery and Chih Wu, Renewable Energy from the Ocean: A Guide to OTEC, Oxford University Press, 1994, ISBN 0-19-507199-9. The postwar reference. Chapter 2 (History) reconstructs the pipe-failure timeline from the Cuban press archive.
  • Makai Ocean Engineering, Keahole Point OTEC Facility — Technical Overview, Makai document rev. August 2015. The current descendant of Claude's design; the cold-water-pipe drawings are on page 6.

A dev fact for the back pocket

The size of a C long on 64-bit Linux is 8 bytes; on 64-bit Windows it is 4 bytes; on the Cray T90 in the 1990s it was 8 bytes but so was int. The C standard has never required otherwise. Every operating system had to pick a data model at the 32-to-64-bit transition, and they picked different ones, and cross-platform C has been paying for it ever since.

The mess is genealogical.

Brian Kernighan and Dennis Ritchie, The C Programming Language, Prentice-Hall, 1978, section 2.2, page 34: "The intent is that short and long should provide different lengths of integers where practical; int will normally reflect the most 'natural' size for a particular machine." On the PDP-11, on which the sentence was written, int was 16 bits and long was 32. On the VAX-11/780 that BSD Unix moved to in 1978–79, int became 32 bits, and so did long. Every C compiler on every 32-bit workstation for the next twenty years followed VAX/BSD conventions: 16-bit short, 32-bit int, 32-bit long, 32-bit pointer. This model is now called ILP32.

The DEC Alpha, released in February 1992, was the first commercially significant 64-bit computer, and OSF/1 (later Digital Unix, later Tru64) shipped on it with a data model in which int stayed 32 bits — because so much C code had grown to assume it — but long and pointers both widened to 64 bits. This model became LP64. By consensus of the Aspen Group — a working committee of Sun, HP, IBM, and DEC that met over the winter of 1996–97 to standardise 64-bit Unix data types — LP64 was adopted by every major 64-bit Unix. Solaris 7 (1998), HP-UX 11, IRIX 6, AIX 5L, Linux on Alpha and later Linux on x86-64 (2003), macOS on x86-64 (2007), and every 64-bit BSD are LP64.

Microsoft did not go to Aspen. When Windows moved to x86-64 with Windows XP Professional x64 Edition on 25 April 2005, the Windows team decided that thousands of Win32 API functions and Win32 struct layouts already assumed sizeof(long) == sizeof(int) == 4, and that widening long would break every one of them at the binary interface. They picked what the Aspen Group had called LLP64: only long long and pointers widened. On 64-bit Windows, sizeof(long) is 4. On 64-bit Linux, sizeof(long) is 8. Any C or C++ code that puts a pointer into a long, prints a long with "%ld" and expects 64 bits, or compares a long to a 64-bit constant, is not portable between them.

The remedy, since C99 (December 1999), has been to use the fixed-width types in <stdint.h>int32_t, int64_t, intptr_t, size_t — instead of long. This has been the recommended practice in cross-platform C for twenty-six years. Cross-platform C code from before 1999 is generally wrong about this. Cross-platform C code from after 1999 is, in practice, often still wrong about it. git, curl, and OpenSSL have all had long-related portability bugs on Windows within the last decade.

The Cray T90, mentioned above, deserves a footnote. UNICOS on the T90 was ILP64: int, long, and pointer all 64 bits, short 32, char 8. It is the only shipping commercial ABI in which printf("%d", n) was safe for values beyond a 32-bit range. Any C code written under it and moved elsewhere had to be audited for exactly the assumption the standard did not require and Cray had permitted anyway.

Primary sources:

  • Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, first edition, Prentice-Hall, 1978, section 2.2 (Data Types and Sizes), page 34. The sentence about "the most natural size" is the entire origin of the mess.
  • The Aspen Group, "64-bit Programming Models: Why LP64?", informal white paper circulated at the Uniforum conference, March 1997. Never formally published; scans circulate in the usual archival corners of the SPARC and Alpha user communities and the SUS mailing lists.
  • Microsoft Corporation, MSDN Library, "The New Data Types" (part of the 64-Bit Windows Programming Guide), first published around 2001 and continuously edited since. The public rationale for LLP64. Currently at learn.microsoft.com; the argument has not moved in twenty-five years.
  • ISO/IEC 9899:1999, "Programming languages — C", §5.2.4.2.1 (Sizes of integer types) and §7.18 (Integer types<stdint.h>).

A modern cross-platform C programmer works on a 64-bit machine that lies to them about how big a long is, and has done so for twenty-one years. The remedy is to use int64_t. Nothing else has ever been portable.


Today's goal

Delete one recurring calendar event that shouldn't still be there.

A weekly meeting that outlived its purpose. A monthly birthday reminder for someone friend doesn't speak to anymore. A "team standup" for a team that has since reorganised twice. Scroll six months out and there will be at least one.

Delete the recurrence itself, not just the next instance. The word for what friend is doing to the meeting is what today's post is named for. Send it off. It has been going out unread for years; it does not need a leaving party.


Today's toy in the corner is skedaddle — a field of small dots that flee from your cursor. Chase them; they scatter. Stop; they drift back to where they were. Change the shape they call home if you get bored of the grid.

— C

slopbowl. the perpetual stew is a tortured metaphor and we both know it.