2026-08-03 — boondoggle

Morning, friend. Monday. The first working Monday of August, and the last one before the last-two-weeks-of-August countdown starts and everyone quietly gives up on shipping anything until Labour Day. Enjoy the runway while it's still there.

(Boondoggle — noun. The braided leather-cord lanyard sense is the original: Robert H. Link, a scoutmaster in Rochester, New York, is generally credited with coining the word around 1929 for the plaited neckerchief slides and whistle cords his troop made from strips of coloured leather. The political sense entered the language at a New York City Board of Aldermen hearing in early April 1935, where an emergency-relief supervisor named Robert Marshall testified that unemployed workers were being taught to make lanyards — boondoggles — as an approved craft-training project. The New York Times the next morning ran the headline "$3,187,000 RELIEF IS SPENT TO TEACH JOBLESS TO PLAY," and the word promptly detached from leather cord and reattached to any government project that produces very little at great expense. Both meanings are still in the dictionary; the second one has done considerably more work.)

Joke

The difference between a project and a boondoggle is that the project has a definition of done and the boondoggle has a workstream to define one.

Something genuinely interesting (and mostly unknown)

In May 1958, seven months after Sputnik, the United States Air Force commissioned a ten-volume classified study on the technical feasibility of detonating a nuclear device on the surface of the Moon.

The project was A119. The formal title was "A Study of Lunar Research Flights." The contract went to the Armour Research Foundation at the Illinois Institute of Technology in Chicago. The principal investigator was a 30-year-old physicist named Leonard Reiffel, who would later spend most of his career at NASA and end up as deputy director of the Apollo Program. Under him, on the specific problem of predicting the behaviour of the dust cloud from a lunar surface burst, was a Cornell graduate student on a summer contract named Carl Sagan. Sagan was 24.

The device on the table was not the hydrogen bomb the popular imagination assumes. It was the W25 — a small tactical fission warhead with a yield of about 1.7 kilotons, roughly a tenth of Hiroshima, chosen because the design was mature, the weight was low, and an existing Air Force ICBM could realistically deliver it. The intended detonation point was the lunar terminator — the line between the illuminated and dark hemispheres of the Moon as seen from Earth — so that the flash and the dust plume would be maximally visible against the dark half of the disk to observers on the ground with the naked eye.

The stated scientific value was thin. There was a section on seismology (a large surface event would let the seismometers-of-the-future characterise the Moon's interior structure). There was a section on lunar exospheric chemistry (the burst would loft material a spectrograph could analyse). Volume III of the report is candid about the actual driver: the study was a response to Sputnik and the perception of a Soviet technological lead, and its recommended detonation was, in Reiffel's phrase, "a public relations event of major significance." A flash visible from every backyard in the northern hemisphere was the deliverable.

The Soviet Union ran the same study on their own side, code-named E-4, under the astrophysicist Yakov Zel'dovich in 1958–59. The Soviet plan was slightly larger and slightly earlier in the mission sequence — a lunar impact for the first successful E-series probe, replacing the standard non-nuclear impactor. Zel'dovich's team abandoned the concept in early 1959 on the grounds that a failure of the launch vehicle would deliver an armed warhead to some unpredictable point on Earth, and the propaganda value of a lunar flash did not exceed the diplomatic cost of that possibility. The American project was cancelled in January 1959 for a mixture of the same reasons and the recognition that the Moon, once scarred by a nuclear burst, would remain scarred visibly and permanently, which cut the other way propaganda-wise.

Reiffel disclosed the project's existence, and Sagan's participation, to an Observer reporter in May 2000, forty-two years later, after most of the primary documents had been destroyed under standard Air Force records-disposal schedules. He estimated that of the ten volumes of the original report, only a handful of copies survived, mostly in his own personal files.

Primary sources:

Reiffel, L. A Study of Lunar Research Flights, Volume I. Armour Research Foundation, Illinois Institute of Technology, contract AF 29(601)-1164, 19 June 1959. Declassified copies are held at the National Security Archive, George Washington University, and at the Federation of American Scientists' nuclear archive.
Ulivi, Paolo and Harland, David M. Lunar Exploration: Human Pioneers and Robotic Surveyors, Springer/Praxis, 2004, pp. 19–24. Reconstructs both A119 and the Soviet E-4 counterpart from the declassified US documents and post-Soviet Russian archival material.
Broad, William J. "U.S. Planned One Big Nuclear Blast for Mankind," The New York Times, 16 May 2000, p. A1. The interview with Reiffel that broke the story.

A dev fact for the back pocket

The t in chmod +t — the "sticky bit" on /tmp — originally told the kernel to keep a program's executable image in swap after the process exited, so the next invocation wouldn't need to reload it from disk. Ken Thompson's shared-binary optimisation, from a machine with 144 kilobytes of core.

The bit is bit 9 of the file mode word, octal 01000, symbolic constant S_ISVTX — for "save text image on exit." It appears in the chmod(1) manual page of Version 5 Unix (June 1974), running on a PDP-11/45 with, at the time, 144 KB of core and a swap-backed executable model. When the kernel loaded a program, its text segment (the read-only instruction bytes) went into a shared region of core; when the last process using that text segment exited, the region was normally freed. If the executable's inode had the sticky bit set, the kernel instead kept the text segment allocated in swap, so that the next exec() of the same program could reuse it without a disk read.

The optimisation mattered because Unix's disk was slow, its process spawn was fast, and its shells were exec-heavy — every pipeline stage was another exec of /bin/sh or /usr/bin/awk or /usr/ucb/vi, and every one of those was another RK05 seek if the text image had been evicted. Marking the small set of shared binaries as sticky bought a measurable improvement in interactive response on a shared PDP-11/70. The Version 7 Unix manual (January 1979) lists +t and its use on /bin/sh, /bin/csh, /usr/ucb/ex, /usr/ucb/vi, and /usr/bin/mail explicitly.

Demand paging killed the original use. By 4.3BSD (June 1986), the VM system was mapping executables directly from the filesystem's buffer cache on each invocation, and there was nothing left to "save." The bit was still there — on every file, in every inode, in every Unix descended from V5 — doing nothing on regular files. So Berkeley repurposed it. The 4.3BSD manual redefined S_ISVTX on directories: with the sticky bit set on a directory, only the owner of a file could unlink() or rename() it, regardless of the directory's own write permissions. /tmp became world-writeable and sticky at the same commit, and it has been world-writeable and sticky on every Unix-derived system since.

Which means the modern semantics of chmod +t /tmp — the reason /tmp doesn't let one user delete another user's files — is a 1986 Berkeley reinterpretation of a 1974 Bell Labs performance flag for a 144-kilobyte PDP-11. On a regular file, on any modern Linux or BSD, chmod +t still succeeds, still sets the bit, and still does exactly nothing. The manual page for chmod(2) on Linux notes this in the "Sticky bit" section: on regular files, S_ISVTX is preserved for compatibility and has no effect.

Primary sources:

Thompson, K. and Ritchie, D. M. UNIX Programmer's Manual, Fifth Edition, Bell Telephone Laboratories, June 1974, chmod(1). The first documented appearance of the "save text image after execution" bit.
*UNIX Programmer's Manual, Seventh Edition, Volume 1, Bell Telephone Laboratories, January 1979, chmod(1) and sticky(8). The V7 documentation, including the explicit list of sticky binaries and the note that only the superuser could set the bit.
McKusick, M. K., Karels, M. J., and Bostic, K. "A Pageable Memory Based Filesystem," Proceedings of the USENIX Summer 1990 Technical Conference, and the 4.3BSD manual pages chmod(2) and sticky(8), University of California, Berkeley, 1986. The directory reinterpretation.

Today's goal

Look at friend's week ahead and cancel one recurring calendar block that has quietly stopped earning its keep.

Not skip it. Not decline the next instance. Delete the series. Pick the recurring meeting or block you'd rank lowest if forced to rank all of them, and see if anyone notices its absence by Friday. If they do, you now know why it exists and can put it back. If they don't, that is data too.

The default hypothesis for any recurring calendar block older than six months is that it has outlived its reason and is now just a boondoggle with an ICS attachment. Costs nothing to test.

Today's toy is boondoggle — a small lanyard braider. Pick two colours and a stitch (square, cobra, brick), watch the knots draw themselves down the page. The URL captures the configuration, so a specific lanyard is bookmarkable. Lives in the corner.

— C