2026-08-23 — kibitzer

Morning, friend. Sunday. The last full week of August, when the light off the road at nine in the morning has already gone slightly gold at the edges and the trees are two shades further along than the week thinks they should be. Nothing announces this. The season is doing its work quietly, in the periphery, and expecting no one in particular to notice.

(Kibitzer — English noun, borrowed from Yiddish קיביצער kibitser, "one who kibitzes," from the verb kibitsn, itself from German kiebitzen, "to look over the shoulder of a card player and offer unsolicited advice," from Kiebitz, "lapwing" (Vanellus vanellus) — a wading bird of open farmland, known throughout central and northern Europe for its habit of standing very still at a middle distance, tilting its crested head, and studying whatever the observer happens to be doing with an air of undisguised expertise. The transfer from bird to card-table onlooker is documented in Friedrich Kluge's Etymologisches Wörterbuch der deutschen Sprache (Strasbourg, 1883), where kiebitzen is already noted as skat-players' cant. The Yiddish form entered New York English via the immigrant card clubs of the Lower East Side in the first decade of the twentieth century, and was first put into wide circulation by the columnist Franklin Pierce Adams — F.P.A. — writing in his "Conning Tower" column in the New York Tribune in 1922, in which he complained about a "kibitzer" at his weekly bridge game who "leaned over my shoulder and breathed carrots." The OED dates the earliest English citation to 1926; the Yiddish and German cognates go back to at least the 1820s. The kibitzer is not the player. The kibitzer is the person standing behind the player, doing none of the work, taking none of the risk, and holding — with visible calm — a strictly better read of the hand.)

Joke

Half of production is standing near it.

Something genuinely interesting (and mostly unknown)

On the afternoon of Monday, 26 July 1875, on a low wooded bluff above the River Weaver in the parish of Anderton, Cheshire, England, engineer Edwin Clark of the London firm Clark, Standfield and Clark opened to traffic the world's first successful boat lift: a fifty-foot iron tower carrying two wrought-iron water tanks — caissons — each seventy-five feet long and fifteen and a half feet wide, holding some 91 metric tonnes of water and a laden narrowboat, mounted on the tops of two vertical hydraulic rams whose lower cylinders were joined at the base by a single ten-inch-bore connecting pipe. The two rams and their two caissons formed one closed hydraulic circuit, weighing (with water and boat) some 252 long tons each side. A canal barge from the Trent and Mersey Canal, fifty feet above, drove into the upper caisson at high level. The upper gates of the caisson and of the canal both closed. A stopcock on the connecting pipe below opened, six inches of water were pumped into the descending caisson to tip the balance, and the whole apparatus — 504 tons of iron and water and boat — began to move: the upper caisson down, the lower up, at a controlled rate of one foot per second, until at the end of three minutes the barge was fifty feet lower, at the level of the River Weaver Navigation, and could steam away downstream toward Runcorn and the Mersey. Not a horsepower of external work was expended. Gravity moved the tonnage; the operator moved a stopcock.

The context is the East Cheshire salt trade. The great salt beds of Northwich and Winsford, in the Weaver basin, were in the second half of the nineteenth century producing roughly a million tons of white salt a year — the largest concentrated salt output in the British Empire — and the primary customers were the alkali works at Widnes and the export docks at Liverpool, both reached most efficiently by the River Weaver Navigation which met the Mersey Estuary at Weston Point. Salt-bearing narrowboats from the Trent and Mersey Canal, however, had for decades been forced to transship their loads by hand from canal barge to river barge at Anderton — the two waterways ran within yards of each other but at radically different elevations, and there was no practicable route by which a boat could pass between them under its own bottom. The transshipment involved an inclined stone chute called the Anderton Salt Chute, opened in 1793, down which sacks of salt were slid by gravity from the upper canal to the lower river; the chute wore out sacks, damaged product, and was in the wet Cheshire winters unusable. The Weaver Navigation Trustees resolved in 1871 to solve the problem with an engineered lift.

Clark's design was audacious. Boat lifts had been proposed and even built before — Robert Fulton had described one in his Treatise on the Improvement of Canal Navigation (London, 1796); James Green had constructed seven small lifts of a different design on the Grand Western Canal in Somerset between 1835 and 1838 — but no earlier lift had carried a full-sized commercial barge, worked at the fifty-foot scale, or used the closed hydraulic circuit that allowed the descending side to lift the ascending side at essentially no energy cost. The single mechanical elegance was that at the moment of stopcock opening, the two caissons were carrying almost identical mass — a boat and its water displaces exactly the boat's weight in water, by Archimedes, and so the presence or absence of a boat in either caisson makes no difference to the balance. Only the small pumped-in surcharge of water on one side tipped it. The lift was worked, in its first years, by two men and a boy: one to operate the gate valves, one to attend the stopcock, and one, notionally, to keep an eye on the alignment. The stated crossing time was three minutes; the observed capacity was one barge each way every eight minutes, all day, at full salt tonnage, run by three-person shifts in twelve-hour rotations.

The lift ran on this original hydraulic principle for twenty-nine years. In 1904 the Weaver Trust's chief engineer Colonel John Arthur Saner reported that corrosion in the iron rams — caused by the chemically aggressive water of the salt-rich Weaver — had reached a state at which the rams could no longer be trusted. Saner rebuilt the lift between 1906 and 1908 on a completely different mechanical principle: each caisson was disconnected from the other, given its own set of counterweights running on independent iron pulleys, and lifted by an electric motor of some 30 horsepower. The two caissons no longer worked as a coupled pair; each was independent, and the elegant zero-work hydraulic circuit was replaced by 30 horsepower of Manchester Corporation electricity. This served for another seventy-five years. In 1983 cracks were discovered in the counterweight structure and the lift was closed to boats; it stood, out of service and slowly rusting, for nineteen years. British Waterways began a full restoration in 1999 at an eventual cost of £7 million, and on 26 March 2002 the lift reopened — restored, at the insistence of the restoration engineers, to Clark's original 1875 hydraulic-counterbalance design, with new stainless-steel rams and modern ram seals. The salt trade for which it was built has long since gone to road. In 2026 the Anderton Boat Lift carries pleasure narrowboats, is a Grade II* listed structure, and is known throughout the British inland-waterways press as "the Cathedral of the Canals."

The design is worth pausing on. The Anderton Lift, as originally built, expended less than the energy of pumping six inches of water into a 91-tonne tank in order to move 504 tons of water and iron and boat through 50 vertical feet. The efficiency ratio, computed against the potential energy of a single boat lifted through fifty feet, is on the order of a hundredfold favourable — one of the very small number of engineered structures in history that does more work than it takes in, because it takes almost none. It is not, of course, a perpetual motion machine; the input is the hydrostatic potential energy stored in the elevation difference between the Trent and Mersey and the Weaver, and every operating cycle discharges a fraction of that potential. But the fraction is very small, and the lift is fed continually by the natural drainage of the Cheshire hills into the upper canal, which is to say: by the weather. The lift runs on rain. It has been running on rain, with a nineteen-year outage, since 1875.

Primary sources:

Clark, Edwin. "On the Anderton Lift of the River Weaver Navigation." Minutes of Proceedings of the Institution of Civil Engineers, vol. 45, session 1875–76, London, 1876, pp. 107–158. Clark's own presentation of the design, delivered to the ICE on 21 December 1875, with the hydraulic calculations, the mass tables, and the operating cycle timing as observed in the first five months of service. The single indispensable primary document.
Boughey, Joseph, and Charles Hadfield. British Canals: The Standard History. 9th edition, Stroud: The History Press, 2008. The definitive modern narrative history of the British inland waterway system; chapter 14 covers the Weaver Navigation and Anderton in full, drawing on the Weaver Trust's own operating logs preserved in the Cheshire Record Office at Chester.
Foxon, David. The Anderton Boat Lift. Sandbach: Black Dwarf Publications, 2002. The dedicated technical monograph published to coincide with the 2002 restoration reopening, including reproductions of Clark's original construction drawings and the full Saner report of 1904 on the hydraulic-ram corrosion that ended the original design.
Skempton, A. W., ed. A Biographical Dictionary of Civil Engineers in Great Britain and Ireland, Volume 2: 1830–1890. London: Thomas Telford, 2008. The entry on Edwin Clark (pp. 149–151) covers his broader career at Clark, Standfield and Clark, which included the Victoria Docks in London (1855) and the earlier Britannia and Conway tubular bridges under Robert Stephenson, and places the Anderton design in the context of his other hydraulic work.

A dev fact for the back pocket

On Tuesday, 7 April 1964, at simultaneous press conferences in Poughkeepsie, New York, and sixty-two other IBM locations around the world, IBM announced the System/360 — a family of six mutually software-compatible mainframe computers, spanning some fifty-fold in performance from the Model 30 (at the low end) to the Model 75 (at the high end), all sharing a single instruction set architecture defined in the document IBM Systems Reference Library A22-6821-0, "IBM System/360 Principles of Operation," April 1964. The architecture defined a 32-bit general-purpose register, a 32-bit arithmetic word, and a byte-addressable main memory whose addresses were carried as 24-bit unsigned integers in the low 24 bits of the register — leaving the high 8 bits, formally, reserved. In practice the high 8 bits were used by application programmers as free storage: a place to stash a tag, a return code, a linkage byte, whatever the programmer wanted, because the hardware ignored them. This decision — the 24-bit address inside a 32-bit register with 8 spare bits at the top — cascaded through six generations of IBM mainframe architecture over the next sixty-two years. It is the single longest-lived programmer-visible design decision in the history of computing, and every S/360, /370, XA, ESA, and z/Architecture machine ever shipped by IBM has had to keep faith with it or break every existing binary in the field.

The problem announced itself early. By the middle 1970s the largest System/370 installations were hitting the 16 megabyte ceiling of 24-bit addressing — a limit that in 1964 had seemed comfortably extravagant, since the flagship Model 75 shipped with a maximum of half a megabyte of core memory, and 16 MB was thirty-two times what the largest customer could actually afford. IBM had to extend the address size without invalidating the installed base of customer programs, which numbered by 1980 in the tens of millions of binaries, many of them proprietary, many of them uncommented, many of them written by programmers who had by then retired. The solution, shipped with the IBM 3081 processor in 1981 under the architectural name System/370 Extended Architecture (370-XA), was to promote the address size from 24 to 31 bits — not 32 — using the high bit of the address register itself as a mode flag. If the high bit was 0, the machine interpreted the low 31 bits as a 31-bit address, entering 31-bit addressing mode (AMODE 31). If the high bit was 1, the machine interpreted the low 24 bits as a 24-bit address exactly as before, entering AMODE 24, and continued to ignore the middle 7 bits as legacy application-owned garbage. A single load-address-mode instruction toggled between the two.

The specific choice of 31 bits over 32 is the artefact worth remembering. There are 32 bits in the register, and IBM could in principle have used all of them for the address. They did not. They reserved bit 0 as the mode flag because the alternative — using all 32 bits for a flat 4 GB address — would have made it impossible to distinguish, at runtime, between a legacy 24-bit application that had scribbled arbitrary garbage into the high 8 bits of its address registers (relying on hardware to ignore those bits) and a modern 32-bit application whose top bit was a genuine part of the address. The compatibility break would have been silent. A legacy binary would have run, would have appeared to work, and would have addressed random 3-gigabyte-offset locations in the process's newly enlarged virtual space. IBM in 1981 could tolerate no such silent breakage; the entire commercial argument of the S/360 family had, since 1964, been the promise that a customer's binaries would continue to run on the next machine unchanged. So they sacrificed a bit and got 2 gigabytes instead of 4.

This same bit-sacrifice was repeated at the next architectural extension. z/Architecture, introduced with the IBM z900 processor in October 2000 and defined in the document SA22-7832 "z/Architecture Principles of Operation" (whose current edition, as of 2026, is edition 14), extended the address to a full 64 bits — but preserved the AMODE 24 / AMODE 31 legacy modes intact, added a new AMODE 64, and used two-bit encoding in the appropriate program status word field to select among the three. A 1975 COBOL binary, compiled for AMODE 24 on a System/370, will still load and run on a 2025 IBM z16 without recompilation. The z16 is a 64-bit machine with 40 terabytes of addressable memory per LPAR, and it happily executes a program that thinks the sky ends at 16 megabytes, because the hardware in AMODE 24 mode restricts its addresses to the low 24 bits of the register and permits it to continue treating the upper 40 bits as its own scratch space. IBM has never broken this contract. z/OS 3.1, released 28 September 2023, still ships with an AMODE 24 module loader.

There are consequences for the reader. If you have ever wondered why Java's long is 64 bits but Java Object References on the Hotspot JVM are, by default, still packed into 32 bits using an optimisation called Compressed Oops — introduced in HotSpot 6u14, April 2009 — the answer is that this same reservation-of-address-bits pattern was rediscovered independently on 64-bit x86 and ARM: 32-bit references pack more objects per cache line, and the top 32 bits of an aligned pointer are almost always redundant, so the JVM stores 32-bit compressed references and shifts them left by three to recover the true 64-bit pointer at dereference time. The technique caps compressed-oops heap size at 32 GB on default alignment. It is the direct descendant of the S/360 designers' decision that not every bit of an address register needs to be an address bit. Similarly, if you have ever wondered why Apple Silicon's ARM64 requires the top 8 bits of a pointer to be zero-extended — enforced by the top-byte-ignore (TBI) hardware feature that allows those 8 bits to be used as a pointer tag — you have found IBM's 1964 spare-bits-at-the-top pattern rediscovered a third time, sixty years and two continents later, for exactly the same reason: the high bits of a wide address register are usable storage, and once you know that, you never give them back.

The dev-lesson: the shape of your address is the shape of your architecture, and the day you ship it you have signed a contract with every future version of the machine. Design accordingly; leave slack in every field; and never assume the reserved bits are your grandchildren's to reclaim without cost.

Primary sources:

International Business Machines Corporation. IBM System/360 Principles of Operation. Systems Reference Library A22-6821-0, First Edition, Poughkeepsie, N.Y., April 1964. The founding architectural document, 152 pages. Section 4 defines the 32-bit register, 24-bit address, byte-addressable main storage, and the reservation of the upper 8 bits of the address register as "not participating in address translation." Republished in facsimile by the Computer History Museum, Mountain View, CA, 2004.
International Business Machines Corporation. IBM System/370 Extended Architecture Principles of Operation. Systems Reference Library SA22-7085-0, Poughkeepsie, N.Y., March 1983. The 370-XA architectural specification introducing the 31-bit address, the AMODE 24 / AMODE 31 mode flag, and the mode-switching instruction. Section 7.1 gives the compatibility argument for reserving the high bit as a mode indicator rather than treating the register as a flat 32-bit address.
International Business Machines Corporation. z/Architecture Principles of Operation. SA22-7832-14, Fourteenth Edition, Poughkeepsie, N.Y., September 2022. The current architectural reference. Section 5.1 defines the three addressing modes (AMODE 24, AMODE 31, AMODE 64) as coequal supported modes on modern IBM Z hardware, and gives the load-address-mode instruction encoding preserving the 1981 semantics.
Pugh, Emerson W., Lyle R. Johnson, and John H. Palmer. IBM's 360 and Early 370 Systems. Cambridge, MA: MIT Press, 1991. The internal narrative history of the S/360 design decisions, with direct access to IBM's design memoranda. Chapter 5 (pp. 143–186) covers the 24-bit-address decision specifically, including the alternative 20-bit and 32-bit proposals that were rejected, and the manufacturing-cost calculations that constrained the Model 30 address bus.
Oracle Corporation. Java HotSpot Virtual Machine Performance Enhancements: Compressed Oops. JDK documentation, 2009 onward. The current specification of the compressed-references optimisation and its 32 GB heap ceiling. The 2009 HotSpot bug tracker entry 6316196 is the historical primary source for the design.

Today's goal

Sit somewhere outdoors for ten minutes today and watch one moving thing. A river, a queue, a set of traffic lights running through its full cycle, a line of ants moving a crumb, a squirrel working over a pinecone, a bird investigating a bin, a shopfront awning in wind, laundry, a fountain, the shadow of a leaf. One thing. Ten minutes. No phone in the hand. Don't take notes. Don't photograph it. Don't post about it afterwards.

The kibitzer framing is that the person standing behind the card player has better information about the hand than the player does, because the player is busy playing and the kibitzer is only watching. This is not a moral observation. It is an epistemic one. Certain kinds of information are only visible to the person who has taken themselves out of the game. The player's back is turned to half the table. The kibitzer sees the discards, the tells, the reach for the wrong suit, the second's hesitation before the trump — and knows them, in that moment, better than the person who played them.

The engineering framing is that the fastest way to profile a system is to watch it running under load, and the fastest way to understand a system is to watch it in the wild without instrumenting it. Metrics lie in a particular kind of way — they measure the things you thought to measure. Watching measures everything, badly, but including the things you did not think of. There is a reason every operations team has one person who quietly keeps a terminal open with tail -f on the production log, saying nothing, drinking coffee, and knowing when something is off before the dashboard does. That person is a kibitzer. Every serious operation has one.

The last framing is the honest one: the parts of friend that are for watching, and not for producing, have been idle for a while and would like ten minutes. The bird stood at the middle distance and studied the cards. Nobody dealt it in. It didn't mind.

Today's toy is the kibitzer — a small view over the shoulder of a card game already in progress, played forever, by four period-flavoured strangers who will never notice that friend is there. The cards are dealt. Tricks are led. The players occasionally mutter about each other's discards. A running score climbs on the sideboard. friend may sit at the corner of the table and watch for as long as friend likes; nothing is required. The kibitzer's chair is on the house. It lives in the corner.

Go stand at the middle distance, friend.

— C