Foreword

A book about operating systems written in 2026 has to start by acknowledging an awkward fact: most readers will arrive thinking the topic is settled. Unix won. The kernels in your laptop, your phone, your watch, your car, your router, your refrigerator, and the servers running the cloud you are reading this from are all either Linux or a near cousin. The two non-Unix consumer holdouts — Windows and the proprietary embedded systems in industrial gear — have been quietly absorbing Unix ideas for thirty years, to the point that even Microsoft now ships a Linux kernel inside its own OS. The argument is over.

This book is not an attempt to reopen it. The argument is over, and that is fine. Unix is a good system, the world it built is mostly a better world than the one it replaced, and the cost of switching away from it now is so enormous that it can only be paid for reasons unrelated to operating system design. What this book is about is something else.

Unix won on a particular set of design decisions. Files-as-everything. Plain text as the universal interchange format. Many small tools, each doing one thing, composed by a shell on a stream of bytes. The user-as-administrator model, where the person running the program is also the person responsible for installing it, configuring it, and dealing with its mess. None of these were the only choices available. They were not even, at the moment they were made, the most prestigious choices. Other groups of competent people were working in directions that looked, from inside their projects, just as obviously correct.

Those other groups lost. Not because they were wrong about everything, and not because Unix was right about everything. They lost because the merits of Unix happened to align with the moment Unix arrived — a moment defined by cheap minicomputers, by AT&T's willingness to license a research system for almost nothing, by the rise of C as a portability bridge, by an academic culture that adopted Unix as a teaching tool and then graduated a generation of engineers who knew nothing else. The alternatives had real merits, real shipping products, and real users. Then they had fewer users, then fewer, then almost none.

The cost of their losing was not that they lost. People who care about operating systems should be comfortable with the fact that systems get replaced. The cost was that, a generation later, the decisions Unix made became so ambient that they stopped looking like decisions at all. They became the air. A working programmer in 2026 can have a long career, ship significant software, mentor more junior people, and never once encounter a system organized along genuinely different principles. The choices stop being visible as choices. They become, instead, the way computers are.

This book is about making them visible again. Not so the reader can mourn, not so the reader can argue Unix was wrong, but so the reader can recover the ability to see the design space. The design space is the point. There is more than one way to build a system that supports a person doing work with a computer, and a designer who can only see one of them is a worse designer than one who can see several. The book exists to give back the second kind of vision.

A note on what this is not. It is not a history of operating systems in general. There is no chapter on VMS, OS/2, or the various proprietary mainframe environments that ran serious business workloads for decades. Those systems lost too, and to some of them more was lost than to any of the systems covered here, but they lost to Unix the way a competing brand of car loses to another competing brand of car: on price and distribution and timing. The systems in this book lost in a different way. They proposed something categorically different about what computing was for, and that proposal lost.

It is also not a book about Windows or macOS, except where they enter the story as carriers of ideas from elsewhere. The Mac is not absent from the story — it is, in its 1984 form, the closest thing the consumer market ever got to a Smalltalk-influenced interface — but it is not the topic. The topic is the road not taken in the room one floor up from the room where the road that was taken got designed.

A note on tone. The book is opinionated. When a system was elegant, the book says so. When the people behind it made decisions that in retrospect look like mistakes, the book says that too. The tradition some of these systems came from — the MIT AI Lab, Xerox PARC, Bell Labs in its second decade — produced some of the most extraordinary working environments in computing history and also produced a culture that, by 1990, had so thoroughly priced itself out of the market that nothing it touched could survive contact with mass adoption. The book tries to tell both halves of that story.

A note on the easy slide. A book titled "What We Lost When Unix Won" has a natural gravitational pull toward nostalgia. The chapter ahead on Genera will be tempted to describe it as a paradise from which we were exiled. The chapter on Plan 9 will be tempted to read like a tract. The chapter on Smalltalk will be tempted to channel Alan Kay's exasperation at the world's failure to listen. The book refuses all three temptations on principle. Nostalgia is the enemy of design clarity. The point is not that the past was better. The point is that the past was different, and the difference is informative, and pretending otherwise — in either direction — makes the reader worse at their job.

A note on sources. The events covered in this book happened mostly between 1965 and 2000. Many of the people involved are alive, several are still working, and most have given talks, written papers, and answered emails. The book paraphrases liberally from primary sources, names them where appropriate, points the reader at the documents in the chapter text, but does not reproduce them at length. A book that quoted Alan Kay for eighty pages and Rob Pike for forty more would be a useful book, but it would be a different book.

A note on what to do with the book. Read it in order if you want; jump around if you want. The chapters are mostly independent, with the exception that the closing chapter assumes you have read the foreword's statement of the thesis, because the closing chapter returns to it. The thesis is this:

Unix won on a particular set of design decisions. Those decisions are so ambient now that we mistake them for the only possible decisions. The cost wasn't the alternatives losing — it was that we stopped being able to see them as alternatives at all. The book's job is to make them visible again.

That is the whole argument. Everything that follows is evidence and texture.

Begin with how we got here. The rest follows.

What Won, What It Beat, Why It Won

The standard short version of the story is that two researchers at Bell Labs, locked out of a doomed mainframe project, wrote a small operating system on a discarded minicomputer in their spare time. The system was elegant. People liked it. Universities adopted it. C, written alongside it, made it portable. Sun and a generation of workstation makers turned it into a commercial product. The free-software movement and then the Linux kernel turned it into the substrate of the internet. By the time anyone noticed, Unix had won everything worth winning.

That story is mostly true. It is also, like most just-so stories about technology adoption, designed to make the outcome look inevitable in retrospect. The outcome was not inevitable. It happened the way it happened because of several specific contingencies — economic, legal, cultural, personal — that, taken together, gave a particular small system a quarter-century runway during which it could ride hardware improvements that would have benefited any system its competitors managed to ship in the same window. The competitors did not ship. That is the story this chapter is really about. The winner only had to be plausible. The losers had to be impossible to stop using, and they were not.

Multics and the Bell Labs exit

In 1965, three institutions — MIT, General Electric, and Bell Labs — committed to building a successor to MIT's Compatible Time-Sharing System. The successor was called Multics, the Multiplexed Information and Computing Service, and it was extravagantly ambitious. Multics proposed a single computer utility, available like electricity, that would serve hundreds of users at once with strong protection between them, dynamic linking of code at runtime, a hierarchical and uniformly named file system, support for multiple programming languages, and per-process address spaces large enough that the file system itself could be addressed as if it were memory.

By 1969, Multics had shipped — or rather, had begun to ship; it was a system that would continue to develop into the 1980s — and Bell Labs had decided it was costing the company more than it was worth. Bell Labs withdrew. The two Bell researchers who had been working on Multics, Ken Thompson and Dennis Ritchie, found themselves with no operating systems project, a PDP-7 that was not being used for much, and an interest in continuing some of what Multics had been trying to do, on a much smaller scale, without the committee that had been making Multics so slow.

This is the first contingency. Unix did not arise as a rejection of Multics by people who thought Multics was wrong about everything. Unix arose as a salvage operation by people who had liked many of the Multics ideas but did not want to spend their careers writing them. The famous Unix name itself — a pun on Multics, a system that did one thing where Multics did many — was a joke about scope, not about correctness. The hierarchical file system, the idea of treating devices and files uniformly, the shell as a user-level program rather than a kernel feature: all of these were borrowed, simplified, and shipped, by people who had seen the more ambitious version up close.

The second contingency was the PDP-7 and then the PDP-11. The hardware available to Thompson and Ritchie was small. The PDP-7 had 8 kilowords of memory; the PDP-11/20 they moved to in 1970 had 24 kilobytes of physical memory in its initial configuration and a 16-bit address space. A system designed to run usefully on these machines could not afford the protection rings of Multics, could not afford dynamic linking, could not afford the elaborate type system of the file system catalog. It had to be small or it would not run at all. The constraints of the hardware shaped Unix's character permanently. By the time hardware grew large enough that the original constraints did not bind, the design decisions made under them had become part of what Unix was.

The third contingency was AT&T and the consent decree. The 1956 antitrust settlement that had constrained AT&T's behavior — and the related 1956 final judgment — limited AT&T's ability to enter businesses other than telephony. When Bell Labs had a working system in the early 1970s, AT&T could not sell it as a commercial product the way IBM, DEC, or any of the minicomputer vendors would sell their operating systems. AT&T could only license the source code to universities and research labs for what amounted to a paperwork fee. From 1973 onward, Unix was the operating system you could get the source for, study, modify, and run with very little friction — and the recipients were students and researchers who, on graduating, would carry it with them into the industry that was about to be built.

The fourth contingency was C. Ritchie's C language was, like Unix, a salvage and simplification of earlier ideas. It dropped most of the safety apparatus of contemporaneous research languages, gave the programmer access to memory addresses, and supplied just enough structure to make moderately large programs writable. As a portability bridge between machines, it was extraordinary. By 1978, the second edition of Kernighan and Ritchie's book had crystallized a language that could be implemented for new processors quickly and that would run essentially the same code on every implementation. Unix, written in C, could be retargeted in a way that no contemporary commercial operating system could. Once Unix was portable, the marginal cost of supporting a new minicomputer or workstation collapsed, and Unix went where the hardware went.

What Unix actually was, in design terms

It is worth being precise about what won, because "Unix" by 2026 is a label so broad it covers systems that disagree with each other about most things. The Unix that won — the Unix whose design decisions became invisible — is the Unix whose character was fixed by the late 1970s and codified in the System V and BSD lineages of the 1980s.

That Unix made four bets that all turned out to be load-bearing.

The first bet: files are everything. Devices are files. Pipes are files. Network connections, once Berkeley added them, were almost files; sockets are the bookkeeping where the analogy broke. The user looks at a unified namespace of byte streams and uses the same primitive operations (open, read, write, close) on all of them. Whatever the underlying object is, it presents as a sequence of bytes.

The second bet: plain text is the universal interchange format. The system's configuration files, log files, source code, mail, manuals, and inter-program data are all text. There is no privileged binary format, no system-wide marshaling layer, no schema registry. If two programs need to communicate, they print and parse text. The cost is that every program reinvents parsing; the benefit is that any program can talk to any other program with no prior coordination.

The third bet: small tools, composed. The kernel does the irreducible things — scheduling, memory protection, the file system — and almost everything else is a program. Programs are written to do one thing, expecting their input from a stream and writing their output to another stream. The shell composes them with pipes. There are no built-in editors, no built-in mail clients, no built-in window managers in the kernel; all of these are application-level programs that the user can replace.

The fourth bet: the user is the administrator. There is no operator class, no central registry of installed software (initially), no privileged install path. The person at the terminal compiles the program, runs the program, installs the program, configures the program, and is also responsible for the consequences. Multics had assumed the operating system was a service run by professionals for users who would never see its internals. Unix assumed the user was a programmer who would. This assumption is at the root of why Unix took so naturally to academic environments and so awkwardly to enterprise environments, and why a generation of "enterprise Unix" products were essentially attempts to walk this assumption back without admitting it.

These four bets were not independent. They reinforced each other. Plain text made small tools work. Small tools made the user-as-administrator model tractable. Files-as-everything made all four bets compose into something a single person could hold in their head. The Unix of 1978 was, for the kind of person who used it then, a coherent design.

It was not the only coherent design.

The contemporaries

When Unix was settling into its character at Bell Labs, several other groups of equally serious people were committing to incompatible visions of what an operating system was.

At MIT, the Artificial Intelligence Laboratory and Project MAC were running ITS, the Incompatible Timesharing System, on PDP-10s. ITS rejected the principle that the operating system should protect users from each other. Any user could inspect or interrupt any other user's program. There were no passwords; there were no file permissions to speak of; there was a culture of mutual trust enforced by social means. The ITS culture would, in the late 1970s, build the first Lisp Machine — a personal computer designed around a single high-level language, with no separation between operating system and application code, where every primitive in the running system could be inspected, modified, and recompiled in place. The Lisp Machine assumed the user was more than a programmer; the user was the developer of the system itself. Chapters 2 and 3 cover the Lisp Machines in detail.

At Xerox PARC, a group led by Alan Kay had spent the early 1970s building the Alto and the Smalltalk environment that ran on it. Smalltalk assumed the user was a child, or at least a non-programmer who would become a programmer in the act of using the system, and that the operating system should disappear into a single coherent message-passing image where every object was discoverable, modifiable, and live. PARC produced a working prototype of the personal computer six years before the IBM PC and a working prototype of the graphical, networked, mouse-driven office a decade before the Macintosh. It produced, in Smalltalk-80, a complete computing environment that even its critics conceded was years ahead of anything in commercial production. Chapters 4 and 5 cover Smalltalk.

At Bell Labs itself, while Unix was being licensed to the world, the original Unix authors and their colleagues were preparing their own response to Unix's deficiencies. Plan 9, begun in the mid-1980s, would treat everything as a file in a way Unix only approximated, would distribute services across machines via a single network protocol, would give every process its own view of the namespace, and would, in its inventors' judgment, fix the problems Unix had created. It would also fail, commercially and culturally, to the system its own authors had built fifteen years earlier. Chapters 6 and 7 cover Plan 9 and its descendants.

At ETH Zürich, Niklaus Wirth — designer of Pascal and Modula — built Oberon in the late 1980s, a complete operating system, language, and user environment written by a small group, on a custom workstation, around a worldview that prioritized simplicity and verifiability over compatibility with anything that came before. At Be, Inc., in the early 1990s, Jean-Louis Gassée's team built BeOS, a multimedia-focused desktop OS with pervasive threading and a database-style file system. Both of these are covered in Chapter 9.

These were not amateur efforts. They were the work of some of the best designers of the period, with substantial funding, working for years, producing systems that ran real workloads and had real users. They each represented a coherent answer to the question of what a personal computer was for. They each lost to Unix.

Why Unix won

If you ask the people who built the alternatives why they lost, you get a remarkably consistent answer: the world wasn't ready, or the market didn't appreciate the difference, or we were ahead of our time. If you ask the people who built Unix why they won, you get a different and more uncomfortable answer: we were small enough to be cheap, we were portable enough to be everywhere, and we showed up with source code at the moment the universities needed an operating system to teach.

Both answers are partly right. The fuller picture is that Unix won on a confluence of factors, none of which were technical superiority in any narrow sense.

Hardware economics. The minicomputers of the 1970s and the workstations of the 1980s could run Unix because Unix was designed to run on machines that small. The Lisp Machine, in contrast, could only run on custom hardware that cost five to ten times what a Sun workstation cost in the late 1980s. As general-purpose microprocessor performance grew, the custom-hardware advantage of the Lisp Machines eroded, and the cost gap remained. Smalltalk could run on more general hardware, but its memory and CPU demands in the early 1980s were aggressive enough that it remained a research or specialist product on most machines until the late 1980s. By the time hardware caught up with Smalltalk's needs, the market it would have entered was already running Unix workstations or Macs.

Licensing. AT&T's near-zero licensing terms in the 1970s seeded universities and research labs with Unix in a way that no proprietary alternative could match. By the time AT&T tried to commercialize Unix aggressively in the 1980s, the universities had already produced BSD, which was free in the sense the recipients cared about. Linux, in the 1990s, then closed the loop by making a Unix that was free in every sense and that ran on commodity hardware.

C. The language portability story is impossible to overstate. A system written in a portable language could follow the hardware. Each new generation of processors — VAX, MC68000, SPARC, MIPS, x86, ARM — got Unix support quickly. None of the alternatives had a comparable portability story. The Lisp Machine was tied to its custom CPU. Smalltalk had a portable virtual machine in principle but a community small enough that ports lagged. Plan 9 was portable, in fact more cleanly portable than Unix, but arrived too late to leverage that fact into market presence.

Culture. The Unix culture rewarded composition, terseness, and self-sufficiency. It was a culture you could enter by reading the manual and trying things. The Lisp Machine culture rewarded long apprenticeship and a willingness to absorb the entire system before doing anything with it. The Smalltalk culture, to a lesser degree, did the same. The cost of entry to Unix was a weekend. The cost of entry to Genera was a graduate degree. In a world where computers were spreading to thousands of new users a year, the weekend system won.

Timing. Each of the alternatives reached its peak technical form just slightly late. The Symbolics 3600 was a beautiful machine, but it was a beautiful machine in 1983, when Sun was already shipping commodity hardware that did 80% of what 3600s did at 20% of the price. Plan 9 was first released externally in 1992 — three years after the World Wide Web's first prototypes and two years before its mainstream breakout. The world Plan 9 was designed for, in which networks of small machines would replace the single-system-with-attached-terminals model, was already arriving, but it was arriving on top of Unix workstations, because Unix workstations were what the people building the web had on their desks. Plan 9 arrived to find its niche already occupied.

Sufficiency. Unix was, for the workloads its users actually had, sufficient. It did not have to be the best system. It had to be good enough to write a paper on, to host a web server on, to compile a kernel on. The alternatives had better answers to questions some users were asking, but those users were a minority. Most users asked, can I edit a file, compile a program, run it, and not lose my data? Unix answered yes, on small cheap hardware, with source available. That answer was sufficient, and sufficient won.

This is not the heroic story. The heroic story is that Unix won because it was right. The honest story is that Unix won because it was right enough, at the right time, on the right hardware, under the right licensing terms, in the right institutions, in front of the right students. The merits aligned with the moment. The systems whose merits did not align with the moment lost.

The inheritance

By 1992, Linus Torvalds was writing the Linux kernel as a hobby project, intending to make a Unix-compatible system for his 386. By 1995, Linux was widely usable and the BSDs (FreeBSD, NetBSD, OpenBSD) were established as serious open-source operating systems. By 2000, Linux was the dominant operating system on internet servers. By 2010, Android — Linux underneath — was on its way to becoming the most-shipped operating system in human history. By 2020, every major cloud provider's infrastructure was Linux, every container runtime was Linux, and the most influential consumer device of the period (the iPhone) ran a system whose userland and kernel were both members of the Unix family.

Linux's victory is not the same as Unix's victory. Linux carries forward Unix's four bets, sometimes more strictly than Unix itself did. The Linux kernel rejects code that does not match its conventions; the Linux userland's GNU tools elaborate on rather than reform the small-tools tradition; the Linux distributions, even the ones that try to be different, all eventually look like Unix from outside. But Linux also carries forward something Unix had only in muted form: a community that has decided, collectively and by inertia, that this is what computers are. The alternatives, where they survive at all, survive as research projects, hobbyist communities, or layers running on top of Linux. There is no longer a credible challenger.

That is the situation the rest of this book is set against. The systems in the chapters that follow were not failed Unix implementations. They were attempts to build a different kind of computer, with different assumptions about what users were, what programs were, what files were, and what a system was for. Some of those attempts produced ideas that quietly migrated into Unix-land. Some of those attempts produced ideas that are still waiting for someone to recover them. All of those attempts produced ideas that, in the world we have now, are hard to even think clearly about, because the language we have for talking about operating systems is the language Unix gave us.

The way to read what follows is not as a list of better alternatives. It is as a list of different alternatives. The point of looking at them is not to choose. The point is to remember that there was, and is, a choice.

Genera and the Image

In the basement of the MIT AI Lab in the late 1970s, a small team built a computer designed to run one programming language as the operating system. The language was Lisp. The computer was the CADR — a successor to the earlier CONS machine — and it became the prototype for the commercial Lisp Machines that Symbolics and Lisp Machines Incorporated would sell through the 1980s. Symbolics' eventual operating system, Genera, was the most mature commercial expression of the idea, and the one this chapter is about.

The reason to take Genera seriously today is not that it was a beautiful curiosity. It was beautiful, and by 2026 it is certainly a curiosity. The reason to take it seriously is that it represents the most fully realized commercial example of a computing model — image-based, language-uniform, live-introspectable — that essentially no production system has shipped since. Reading what Genera was is the easiest way to recover what those three adjectives might mean if they were taken seriously as design constraints rather than as research curiosities.

What the image is

The Unix model has a sharp boundary between the operating system, the programs the operating system runs, and the data those programs manipulate. The kernel is in memory; programs are on disk; data is on disk; processes are temporary memory states constructed by loading programs and serviced by syscalls into the kernel. When the machine shuts down, the running state of the system is discarded — the kernel will be reloaded fresh from disk, the programs will be relaunched, the data will be re-read from files.

Genera dissolved that boundary. The entire state of a running Genera machine — the operating system, every loaded program, every open editor buffer, every variable in every running computation, every compiled function and every uncompiled source form — lived in a single object graph called the world. To save the state of the machine, you wrote the world to disk as a band: a snapshot of memory that could be reloaded later to restore the machine to exactly the state it had been in when the band was written. Booting the machine was, in effect, unfreezing a previously frozen running state.

This had immediate practical consequences. There was no "starting up an application." Applications were already in the world; the band you booted from contained them. There was no install/run distinction. Loading code into the running machine did not produce a separate program; it added definitions to the world, which then participated in everything else the world was doing. There was no compile/run boundary. You wrote a function in an editor, the editor incrementally compiled it as you typed, and the moment you finished the form it was available to call. If you changed the definition of a function that was already being called by a thousand other functions, those thousand other functions did not need to be recompiled or relinked; the next call site would resolve to the new definition. The world was always running, and you were modifying it from inside.

This is what "image-based computing" means. The image is the machine. To program the machine is to modify the image. To save your work is to write the image to disk. To resume your work tomorrow is to load the image back into memory and find every variable, every window, every editor buffer, every error in the debugger, exactly where you left it.

Language uniformity

The world ran on a single language: Lisp. Specifically, the dialect that became Common Lisp, with Symbolics' extensions for graphics, multitasking, networking, and hardware control. Every component of the system was written in Lisp. The window system was Lisp. The file system was Lisp. The compiler was Lisp. The device drivers were Lisp. The networking stack was Lisp. There was no C, no assembly except where the lowest microcoded levels needed it, no shell language different from the application language, no scripting language different from the system implementation language.

This produced a property the Unix tradition does not have any equivalent of: every name in the running system was a name you could investigate. If you typed a function name into the listener — Genera's REPL, though calling it a REPL undersells what it was — you got the function, with a complete record of where its source lived, what file or buffer that source had been loaded from, what types its arguments were, what other functions called it, what other functions it called, and a way to step into its definition with the keyboard. If you saw an unfamiliar error, you could ask the error itself what condition had been signaled, where the signal had come from, and which restart options the relevant code had registered. Every object in the system carried, by default, the same kind of metadata.

Genera made this navigability a first-class part of the user interface. The system had a feature called the dynamic window, a graphical display surface in which every output of every command was a clickable, typed object rather than a sequence of characters. If a function returned a list of pathnames, the pathnames were objects in the window, and right-clicking on one offered the appropriate operations for pathnames: edit, copy, rename, show contents. If you ran a command that produced an error, the backtrace in the debugger contained, at every frame, the actual live values of the local variables — not their textual representations, but the values themselves, which you could examine, modify, and resume from. The line between displaying a result and operating on a result was almost erased.

In a Unix terminal in 2026, the same operation requires you to read text, mentally extract the relevant tokens, retype them as arguments to other commands, and hope the formatting between programs lines up. Genera assumed this work was beneath the user and offloaded it to the system, on the theory that the system already had the typed objects in memory and there was no good reason to flatten them to text just so the user could re-construct what the system had already discarded.

Live introspection

A common shorthand for Genera's character is "everything is live." The word does a lot of work. What live meant, in practice, included at least the following:

Compilation was incremental and pervasive. When you saved a function in an editor buffer, the new definition was compiled, installed, and visible immediately. There was no link step. There was no relaunch. Functions called the latest definition the next time they were called. If you wanted to fix a bug, you fixed the function, and the next iteration of the loop that contained the bug picked up the fix.

Debugging was the normal mode. When an error occurred in a running program, the program did not crash. It entered the debugger with full access to its current state — the call stack, the local variables at each frame, the source of each function in the stack, the condition object representing the error, and the set of restart options that the calling code had set up to recover from this kind of condition. The user could examine the situation, modify variables, replace function definitions, and resume the program from any point in the stack. A long-running computation that failed two hours in could be patched and resumed, not restarted.

Inspection was reflexive. Any object in the system could be inspected. The inspector was a window that showed an object's type, its slots, the values in those slots, the operations applicable to it, and a way to navigate from any slot into its contents. Inspecting a window showed you the window's geometry, its event handlers, the application managing it. Inspecting a process showed you its stack and its state. Inspecting an inspector showed you the inspector — there was no privileged level the user could not see from.

Documentation was structured. The function documentation, manual pages, and tutorial materials were not text files. They were typed objects in the world, linked to the functions and concepts they described. From any function you could ask for its documentation; from any documentation node you could ask which functions and types it covered; from any topic you could navigate to related topics. The system shipped with thousands of pages of documentation accessible by direct interrogation rather than by remembering filenames.

The cumulative effect was that, for a user who had absorbed the system, the friction between having a question about the running machine and getting an authoritative answer from the running machine itself was nearly zero. You did not need to grep source code, search the web, or consult documentation in a separate window. The machine knew the answer about itself and would tell you if you asked.

What it enabled

The Lisp Machines were not built as elegant toys. They were built because, in the late 1970s, the AI Lab needed working environments where they could build large interactive Lisp programs without the wall-clock pain of the batch compilation cycle on PDP-10s. They were built, and then they were sold, primarily to customers who needed exactly that property: people building expert systems, knowledge representation engines, theorem provers, computer-aided design tools, scheduling systems, and the early commercial work on what was then called AI. Symbolics had real customers — Schlumberger for oil exploration, the DOD for various classified applications, hospitals for diagnostic systems, companies like American Express for what would now be called rules engines.

For the kind of work those customers were doing, the image model paid off. Building an expert system involved an enormous amount of iteration: refining rules, adding cases, watching the system behave on inputs the engineers had not anticipated, and adjusting. A system where you could change a rule and instantly see its effect on a running case, where you could enter the debugger inside a failing inference and ask why that branch had been taken, where you could save the state of an in-progress session and resume it the next morning, was simply a better tool than a Unix workstation running a batch-compiled C program for this kind of work. Genera users routinely reported productivity differences of three to five times over comparable Unix environments. Whether that number is exaggerated or not, the qualitative experience was different in a way that anyone who has used the system in 2026, through an emulator, can verify in an afternoon.

Genera also enabled a kind of programming in the world that has almost no current equivalent. A user could open the source of any function in the system, change it, and have the change be live in the next call. This was used heavily for customization: users would extend the editor, add commands, redefine system behaviors, patch bugs in code they did not own. The system shipped with the source for itself. Reading the source for a system feature was, in Genera, the default way to find out what it did, and modifying that source was a normal user operation. Unix never quite shipped this property — even GNU systems, where source is technically available, require a rebuild cycle that makes "modify the running system" a different category of action than "use the system."

What it cost

Genera was not, on technical merits, free. It was an expensive system and the expense was structural.

Memory. The world was large. Even the slimmest Genera installations had a working set of several megabytes by the early 1980s and tens of megabytes by the late 1980s, in an era when commodity workstations shipped with one to four megabytes of RAM. Symbolics built specialized hardware with much larger memory configurations than competing workstations of the same era, which was part of why the hardware was expensive.

Hardware cost. Symbolics machines used custom processors — the LM-2, the 3600 series, and later the Ivory chip — designed to execute Lisp efficiently with hardware support for tagged data, garbage collection, and runtime type checking. These processors were not produced in the volumes that allowed Intel and Motorola to drive down prices on commodity CPUs. A Symbolics 3640 in 1986 cost something north of $100,000. A Sun 3/160 in the same year cost a fifth of that and did 80% of what most customers actually wanted. The custom-hardware story is what eventually killed the Lisp Machines: not that they were not good, but that general-purpose hardware closed the performance gap while remaining cheaper.

Cultural cost. Genera was hard to learn. It assumed you knew Lisp, that you were comfortable with a keyboard-and-modifier interface heavily inspired by the AI Lab keyboards (the famous "space-cadet" keyboards with bucky bits, super, hyper, meta), that you would invest months becoming fluent in a system whose surface was nearly bottomless. The reward for that investment was high — Genera was, by accounts of people who used it for years, the most pleasant programming environment in the industry. The cost of admission was real, and in a world where Unix workstations could be used productively after a weekend of orientation, the cost of admission to Genera was a barrier to adoption even when the system was technically superior.

Single-language commitment. Everything was Lisp. This was a feature for Lisp programmers and a wall for everyone else. C programs could not be naturally hosted; Fortran integration was awkward; later, when the industry moved toward C++ for performance and Perl/Python for scripting, Genera had nothing comparable to offer. Symbolics built a C compiler eventually, but it was always a guest in someone else's house.

Single-user assumption. Genera was, like the Lisp Machine concept generally, a personal computer. It was not a timesharing system. It assumed one user per machine, and that user owned the machine completely. This was visionary in 1980 — the Lisp Machine was, after the Alto, one of the very first personal computers in the modern sense — but it made the system unfit for the multi-user workgroup model that Unix workstations slotted into so naturally in commercial environments. Symbolics machines could share files over the network, of course, but each machine was an island of one user's work.

The hardware story

Symbolics did not die because Genera was a bad operating system. Genera was the best operating system Symbolics could have shipped, and it kept getting better through the late 1980s, with the 8.x releases adding features (the Dynamic Lisp Listener, Concordia for hypertext documentation, the Joshua expert-system tool, CLIM for portable user interfaces) that made it more capable, not less. Symbolics died because the custom-hardware bet stopped paying.

The argument for custom hardware in 1980 was solid: general-purpose CPUs of the period did not support tagged data, hardware-assisted garbage collection, or fast type dispatch, all of which Lisp benefited from enormously. A custom processor could run Lisp at speeds general-purpose CPUs could not match, and the price difference — large in absolute terms, but small as a fraction of the cost of an engineer's time at a company doing AI work — was tolerable.

The argument stopped working in the late 1980s for two reasons. The first was that general-purpose RISC processors — SPARC, MIPS, the Motorola 88000 — closed enough of the Lisp-specific performance gap that commodity workstations running ports of Common Lisp (Lucid, Allegro, Franz) were within striking distance of Lisp Machine performance for many workloads. The second was that the AI Winter of the late 1980s cut funding to exactly the customers Symbolics depended on. Defense work shrank, expert-system projects were cancelled, university budgets dried up. The customers Symbolics had built its business around could not afford new machines, and the customers it had not yet won were buying Sun workstations instead. The financial story is its own book; the short version is that by 1993 Symbolics was a shadow of itself, by 1996 it was effectively gone as a hardware vendor, and the Ivory chip that should have carried it through the 1990s never had the volumes to be cost-competitive.

The ideas survived in two forms. The Open Genera port to DEC Alpha, released in the early 1990s, ran the Genera software stack on commodity 64-bit RISC hardware via a software emulator for the Ivory instruction set. Open Genera proved that the system could survive without the hardware, and copies of it still run today, on emulated Alphas, on enthusiast machines. The other survival path was through the Common Lisp ports — SBCL, CCL, Allegro CL, LispWorks — which carry the language forward without the integrated environment. Reading the next chapter requires keeping both threads in mind: the integrated environment was not Common Lisp, and what people miss about the Lisp Machines is the environment, not the language.

What to take from it

If you have never used Genera, the easiest way to feel its character in 2026 is to install an Open Genera image on an emulator or to spend an afternoon in a modern Lisp environment that preserves some of the same gestures: SBCL with SLIME or Sly, or — for the most direct living descendant of the Genera idea — a recent build of McCLIM, which reimplements the Common Lisp Interface Manager that Genera shipped. These are not Genera. They are partial reconstructions of pieces of it. They still give you something Unix does not give you, which is the experience of a working system where the running state is the primary artifact and where every name in that state is reachable from every other.

The thing to take from Genera is not nostalgia. The Lisp Machines were not a paradise. They were expensive, they required a long apprenticeship, they were vulnerable to bad behavior by any user (since protection was minimal), they could crash in ways that took the entire image down at once, and they competed in a market that wanted cheap rather than excellent. They lost for understandable reasons.

The thing to take is the proof that a different shape of computing could work. The Lisp Machine is the existence proof that an operating system can be a single live language image rather than a kernel-plus-userland architecture, that compile/run can be a continuous gradient rather than a sharp boundary, that every object in a running system can be introspectable by default, and that a user can extend and modify the running system from inside it without breaking it. None of these are theoretical. Genera shipped them. Real engineers did real work in them for fifteen years.

The Unix tradition has no equivalent of this. Even Unix tools that aim at liveness — REPLs, hot-reloading development servers, language-server-based IDEs — are working against the underlying model rather than with it. They simulate, at the application level, properties Genera had at the operating-system level. The simulations are useful. They are also less coherent than the original, because the original did not have to defend the boundary between "the language" and "the operating system" — there was no boundary.

The next chapter looks at where Genera came from: the MIT AI Lab CADR, the LMI lineage, the ITS culture that produced both. The shape of Genera was not an accident. It was the result of a specific subculture of programmers building, for fifteen years, the machine they wished they had.

The MIT and LMI Lineage

Genera did not appear out of nowhere. It was the commercial flowering of a research program that had been running at the MIT Artificial Intelligence Laboratory for more than a decade, on hardware that the lab had designed and built itself, on an operating system the lab had written and refused to make conventional, by a group of programmers with strong shared opinions about what computing should feel like. This chapter is about that program, the machines it produced, and the culture from which both of those came.

The reason to spend a chapter on this is not historical completeness. It is that the Lisp Machine, as a category, was the output of a specific way of thinking about computers. The category did not survive its makers. To understand why nothing has replaced it — why no group, in 2026, is building anything like a Lisp Machine — it helps to look at the conditions under which it could be built at all, and to be honest about which of those conditions are gone for good.

The AI Lab and ITS

Through the 1960s and into the 1970s, the MIT AI Lab ran on a small fleet of DEC PDP-6 and PDP-10 machines under a homegrown timesharing system called ITS, the Incompatible Timesharing System. The name was a joke. The system it referred to was not a joke. ITS was the operating environment that produced or supported the early work on Lisp, Emacs, robotics, computer vision, planning, theorem proving, and what was then called artificial intelligence — work that defined much of what those fields became.

ITS was unlike the contemporaneous commercial timesharing systems in several ways that matter for this book.

There were no passwords. To use the machine, you walked up to a terminal and identified yourself by typing your name. The system recorded that you had logged in, but it did not authenticate you. The assumption was that the people in the lab knew each other and that anyone who came in off the street could be dealt with socially.

There was no protection between users. Any user could inspect any other user's running programs. Any user could send any other user a message that would appear on their terminal. Any user could attach to any other user's process and look at its memory. The system supported a pair of commands — OS, "output spy," and IS, "input spy" — that let one user watch another user's terminal session in real time, originally introduced as a debugging aid and culturally tolerated as a kind of open-door policy on computing.

There was no privacy on the file system. Files had owners, but anyone could read, write, or delete anyone else's files. The community managed this with social conventions: you did not delete other people's files unless they had asked you to, and if you wanted privacy for something you took it home on tape.

The system shipped with its sources. Reading the source for ITS was the way you learned how ITS worked. Modifying the source for ITS, when you found a bug or wanted a feature, was a normal user activity. The boundary between "working on ITS" and "using ITS" was porous in the same way it would later be porous on the Lisp Machines.

This was not a sustainable model for computing in general — the moment any of those properties was tried on a system with adversarial users, it failed catastrophically — but it was the model under which the AI Lab worked, and the Lisp Machines inherited their ergonomic shape from it directly. The fundamental ITS assumption was that the user was trusted, competent, and interested in the machine itself. The Lisp Machine, when it came, was designed for the same kind of user.

Why a Lisp Machine

By the mid-1970s, AI Lab researchers building large Lisp programs on PDP-10s were running into a wall. The PDP-10s were timesharing machines. Compiling a large Lisp program on a busy PDP-10 could take a long time. Garbage collection paused the entire system for everyone. The interactive feel that Lisp afforded on a lightly loaded machine evaporated on a heavily loaded one. The lab had outgrown the hardware.

Two researchers, Tom Knight and Richard Greenblatt, began designing a personal computer that would run Lisp natively. The idea — a single-user machine, dedicated to one researcher, fast at the operations Lisp needed — was, in 1975, novel. Personal computing in any modern sense did not yet exist. The Alto, at PARC, had been running for two years, but the Alto was a research curiosity at Xerox and few people at MIT had used one. The Apple II was still a year from shipping. The IBM PC was six years off. The Knight-Greenblatt machine was a personal computer not because the market wanted one but because the AI Lab needed one.

The first prototype was called CONS. It was followed by a more refined design called CADR. (The names are Lisp jokes. car and cdr are Lisp primitives; cons builds pairs; cadr is car of cdr.) The CADR was the basis of every commercial Lisp Machine that followed. It established the architectural pattern: a microcoded processor that supported tagged data types in hardware, a large physical memory by 1976 standards (initially 256K, expandable), bit-mapped graphics output to a high-resolution display, a mouse, a network connection (initially Chaosnet, the AI Lab's own protocol), and a complete operating environment written almost entirely in Lisp.

By 1979, the CADR was a working machine that several AI Lab researchers were using as their primary workstation. The lab was producing them in modest numbers, but it was still a research project, not a product. Two groups within and adjacent to the lab decided, almost simultaneously, that this was about to change.

The split: Symbolics and LMI

In 1979 and 1980, two companies were founded to commercialize the Lisp Machine. Richard Greenblatt founded Lisp Machines Incorporated (LMI), with a philosophy that the company should remain close to the MIT research culture, licensing the CADR design and continuing to evolve it without major architectural changes. Russell Noftsker and a group that included Tom Knight, David Moon, Howard Cannon, and several other AI Lab senior staff founded Symbolics, with the intention to build a more aggressive, better-capitalized product company that would design its own successor hardware and pursue commercial customers more directly.

The split was contentious at the time, and it has been romanticized as a culture clash between the pure-research wing and the venture-backed wing of the AI Lab. The romanticization is partly accurate. What it misses is that the underlying technical question was real: should the Lisp Machine evolve incrementally from the CADR, on commodity-adjacent technology, betting that the install base would grow as workstations grew? Or should it leap to a custom processor designed for Lisp from the ground up, on the bet that Lisp's specific needs justified the engineering cost? Symbolics took the second bet, designing the 3600 series and later the Ivory chip. LMI took the first, continuing to ship CADR-derived machines into the early 1980s.

In the short run, Symbolics' bet looked correct. The 3600 was faster than LMI's machines, better-supported, more capable, and built by a company with deeper pockets and a more aggressive sales operation. By 1985, Symbolics had eclipsed LMI in unit shipments and prestige. LMI went bankrupt in 1987. The Symbolics machines became, for the rest of the decade, what most people meant when they said "Lisp Machine."

In the long run, Symbolics' bet looked correct only until commodity hardware caught up. The same custom-CPU strategy that gave Symbolics a performance advantage in 1983 became a cost millstone by 1990, when a Sun workstation running Lucid Common Lisp could do most of what a Symbolics machine could do at a fifth of the price. The 3600's advantage over the CADR had been hardware. The 3600's disadvantage against the SPARC was, eventually, hardware. The lesson, if there is one, is that betting on custom silicon for a niche workload is a strategy with a short useful life unless the niche grows into a mainstream.

Texas Instruments licensed the Symbolics design and produced its own Lisp Machines under the name Explorer, with a microcoded version of the 3600 architecture and, later, a microprocessor implementation called the LMI-Lambda lineage's successor MicroExplorer that ran on a NuBus card inside an Apple Macintosh II. The MicroExplorer is the curious endgame of the Lisp Machine as discrete hardware: a Lisp Machine on a card, hosted by a personal computer that had won the market the Lisp Machines had hoped to win.

What the lineage shared

All of these machines — CADR, Lambda, 3600, MicroExplorer, Explorer — shared a set of properties that distinguished them from any contemporary machine outside the family.

Tagged hardware. The machine's word size included tag bits identifying the type of the data in the word. A Lisp Machine fixnum was distinguishable from a pointer in hardware, with no software check needed at runtime. Type errors — passing a string to a function expecting a number, say — could be caught in a single instruction by the processor itself, rather than checked in software at every operation. This is the technical reason Lisp ran fast on Lisp Machines. It is also why no commercial processor since has caught up exactly: tagged data is not what general-purpose ISAs are optimized for.

Hardware garbage collection support. The processor provided primitives that made generational, incremental garbage collection efficient. The CADR and 3600 architectures included read barriers — hardware checks on every pointer dereference that could trap into the GC if needed — that made it possible to collect the heap incrementally without pausing the user-facing program for long intervals. Modern garbage collectors, in JVMs and CLR, use software emulations of this idea (read barriers via memory-protection traps), with much more software overhead than the Lisp Machines paid in hardware.

Microcoded instruction sets. The Lisp Machines did not have fixed instruction sets in the sense a modern processor does. The actual operations the processor performed were defined by microcode that the operating system loaded at boot. This had two consequences. One: the same hardware could be retargeted, by changing microcode, to run different languages or different versions of the same language. (TI's Explorer line, for instance, supported both a Lisp microcode load and a Prolog microcode load on the same hardware.) Two: improving the system meant editing the microcode, which the Lisp Machines exposed to the operating system in ways no general-purpose machine has since.

Integrated graphics from the start. The Lisp Machines were bitmap-graphics machines from the CADR onward. The user interface was graphical, in an era when most commercial workstations were still character-oriented. The display was, in a meaningful sense, part of the machine rather than a peripheral. Window management, font rendering, and the system's notion of what an output device was were built into the OS, not bolted on.

Network from the start. The CADR shipped with Chaosnet — a local-area protocol designed at the AI Lab — and later acquired TCP/IP. Networked file servers, network-aware remote procedure calls, and the assumption that machines lived in groups rather than alone were all baked into the system from early on. A 1981 Lisp Machine had a network experience that a 1985 commodity workstation did not.

Source-on-the-machine. Every commercial Lisp Machine shipped with the source for itself. Reading the source for a system feature was how you found out what it did. Modifying it was a routine user activity. This was not a marketing differentiator — Symbolics did not advertise it as one — but it was a basic property of the system culture, inherited directly from ITS.

The hacker ethic of the era

The Lisp Machines were built by, and for, a culture. The culture is hard to describe in 2026 because the closest thing the contemporary industry has to it — the open-source kernel community, perhaps — is a much more diffuse, more remote, more rule-governed phenomenon. The AI Lab culture was small, in person, and intensely opinionated.

A few features of it bear on the Lisp Machine story.

The machine was the work. You did not use the machine to write programs; you used the machine to improve the machine. A normal day involved tweaking the editor, redefining a debugger command, fixing a bug in a system function, or extending a library. The boundary between "users" and "developers" did not exist in the lab. Everyone was both. The Lisp Machine's architecture supported this because the source was on the machine and the running state was modifiable. The architecture supported it because the culture demanded it.

Tools were personal. The space-cadet keyboards of the era had keys labeled Super, Hyper, Meta, Greek, Top, and Front, in addition to the standard modifier keys. Different users bound the modifiers differently. Editor commands were customized per user. The notion that a computer should present a uniform user interface to everyone was a commercial idea that arrived later; in the lab, every user's environment was personally tuned.

Documentation was secondary. The primary way to find out what something did was to read its source. This had two effects. It produced programmers with an unusual fluency in reading other people's code, since the system itself was the documentation. It also produced programmers who, when they later moved to industry, had trouble understanding why their colleagues kept asking for manuals when the source was right there.

Brilliance was status currency. The lab valued cleverness, technical depth, and the demonstrated ability to do things no one else could do. It did not particularly value team-building, mentorship of less-experienced engineers, or accommodation of users outside the in-group. This produced extraordinary individual work and famously poor handoffs to the outside world. The cultural pattern persisted into Symbolics, where it became a real factor in why the company could not adapt its product to less-specialized customers as the market shifted.

Software was free, in a sense that did not survive. The lab's software was shared freely with anyone who could use it. There was no licensing apparatus. There was a strong sense that knowledge was meant to circulate. When Symbolics began enforcing source licenses on its commercial code in the early 1980s, the resulting conflict with Richard Stallman (then an AI Lab employee) was the precipitating cause of the GNU project. Stallman's stated motive was that the lab's software-sharing culture had been broken by the commercialization, and he wanted to rebuild a community where the culture could continue. The GNU project, and the free-software movement it eventually became, is the broadest surviving cultural descendant of the AI Lab — not a descendant of the Lisp Machines technically, but a descendant of the culture in which they were built.

What did and did not transfer

When the Lisp Machines died, the people who had built them did not vanish. They moved into industry, academia, and a smaller set of niche tool vendors. The ideas they carried with them went into many places, in mostly diluted form.

The integrated development environment, in something like its modern sense, comes from the Lisp Machine. Smalltalk had a parallel tradition, covered in Chapters 4 and 5; the two influenced each other. The idea that an editor, a compiler, a debugger, a runtime, and a documentation browser should be facets of a single environment rather than separate tools is not natively a Unix idea. Unix bolted IDEs on later. The Lisp Machines were built that way.

Hot code reloading, in the sense that languages like Erlang, Clojure, and Elixir have it, descends directly from Lisp Machine practice. The principle that you can replace a function in a running system without restarting the system is one of the durable Lisp Machine ideas.

The condition system of Common Lisp — the structured way of handling errors with restarts and handlers — was crystallized on the Lisp Machines and ported to other Lisp implementations. Ruby's exception system, Python's, Java's, are all weaker versions of what the Lisp Machine condition system provided in the mid-1980s.

Image-based development, the idea that the running state is the primary artifact, did not survive into the mainstream. Smalltalk preserved it; the modern Pharo and Glamorous Toolkit communities preserve it; the Lisp world preserves it in REPL-based development with SLIME-like tooling. The general industry, though, runs on file-based development, where the source files are the primary artifact and the running state is something that gets reconstructed from them. The difference is sometimes hard to feel, because file-based tooling has gotten very good, but the underlying model is the Unix model, not the Lisp Machine model.

Hardware-supported tagged data and GC barriers did not transfer. Modern processors execute managed languages quickly through clever JIT compilation and software techniques, not through hardware support for runtime type checking. The Lisp Machine's hardware bet did not survive even as architectural inspiration — when general-purpose hardware caught up, it did so by being better at general-purpose computation, not by becoming more like a Lisp Machine.

The ITS-shaped hole

The deeper thing that did not transfer is the working culture. ITS, the Lisp Machines, and the AI Lab worked because they assumed a small, mutually-trusted community of users who were all also developers of the system. That assumption was a luxury of being a research lab in a single building with a few dozen people in it. As soon as you scale the user base, introduce adversarial users, network the machine to the internet, and ship the system to customers who have no interest in modifying it, the assumption breaks. The protection model has to come in. The privileged-administrator model has to come in. The line between users and developers has to come in. The result, even on a system that started as a Lisp Machine, would be a Lisp Machine that had grown a Unix-shaped scar tissue around all of its most pleasant properties.

This is the part of the Lisp Machine story that is hardest to recover. The technical ideas — the image, the introspection, the integrated environment, the condition system — are still applicable. The cultural conditions under which they could be applied to an entire operating system, at the level of the operating system, are not coming back. We live in a world where the user is not the administrator, where machines are adversarial environments, where networks are full of attackers, where the assumption of mutual trust is unsupportable. The Lisp Machine's design assumed otherwise, and the assumption was both its strength and the reason it could not survive contact with the world it was about to enter.

The next two chapters look at Smalltalk, which was a parallel and equally serious effort, with a different culture and a different set of failed and surviving ideas. Then the book turns to Plan 9, which was an attempt — by exactly the people who had built Unix — to do Unix correctly the second time. Each of these projects has its own version of the same story. A small group of strong designers built something extraordinary for an environment they understood, and then the environment changed faster than the system could adapt to it.

Genera and the Lisp Machines are interesting in 2026 because they make visible what was lost. They are not interesting because they should come back as they were. They probably could not, and arguing they should is the kind of nostalgia the foreword warned against. What can come back, in some form, is the question they were trying to answer: what does it feel like to use a computer where the system is an artifact you can inspect, modify, and live inside? That question has not been retired. It has only been buried under thirty years of conventions that assume a different answer.

Alan Kay's Actual Proposal

Alan Kay is a difficult subject for this book. He is one of the most cited and least correctly understood figures in computing. He has spent fifty years talking and writing about ideas that the industry has, by Kay's own assessment, largely failed to absorb. He is associated, in popular memory, with the invention of object-oriented programming, the invention of the personal computer, the invention of the graphical user interface, and a kind of computing-as-humanism that the industry never built. Some of those associations are accurate. Some are not. Most are accurate in a sense Kay would describe as superficial.

This chapter is not going to try to do Kay justice in the sense of summarizing his views; Kay has done that many times and is still doing it. The chapter is going to do something narrower and more useful: extract the actual technical and intellectual proposal that the Smalltalk research at Xerox PARC represented, separate it from the museum-piece version that survived in the textbook treatment of object-oriented programming, and put it in the context of the operating-systems argument this book is making.

The reason this matters is that Smalltalk lost, in much the same way the Lisp Machines lost, and for some of the same reasons and some different ones. The reason its loss is harder to see is that pieces of it kept surfacing in commercially successful systems — the Mac, Java, Ruby, the modern web browser — in forms diluted enough that, by 2026, "object-oriented" means something almost unrelated to what Kay meant by the term, and the parts of Smalltalk that Kay considered essential are mostly absent from systems that nevertheless claim descent from it.

The Dynabook and Personal Dynamic Media

The frame Kay worked inside in the early 1970s was not "we are inventing a new operating system." It was a frame about what computers are for. The frame was articulated most clearly in two documents: a 1972 paper by Kay called "A Personal Computer for Children of All Ages," which described a portable, networked, child-usable computer called the Dynabook; and a 1977 paper Kay co-wrote with Adele Goldberg, "Personal Dynamic Media," which described how a computer like the Dynabook could function as a medium in the sense that print, film, and television were media.

The frame is worth taking seriously because it constrains everything else about Smalltalk. Kay was not trying to build a better tool for programmers. He was trying to build a medium for thought, and his model for what a medium did was the printing press: a technology that, by being available to everyone and by giving everyone the means of authorship, changed how civilizations thought. Computers, in Kay's view, had the same potential, and most contemporary computer designs — including the timesharing systems of the era and the workstation systems being designed at PARC's other groups — were misusing that potential by treating computers as tools rather than as media.

A medium, in Kay's sense, had three properties that mattered for the design.

It was active. A printed page sat there; a Dynabook page could compute. The content was not just data but data and behavior together, simulating, responding, transforming.

It was malleable. The user did not just consume the medium; they authored within it. A child reading a book about geometry on a Dynabook could change the geometry, ask it questions, build their own simulations on top of it. The medium had no first-class consumers and second-class producers. Everyone was a producer.

It was integrated. The medium did not consist of separate applications stitched together. The text, graphics, sound, simulation, and program code were all the same kind of object, interoperable by default, navigable by uniform means. The system did not have a word processor, a drawing program, and a calculator as separate things. It had a substrate in which a document could contain words, drawings, calculations, and simulations as different shapes of the same underlying object.

The Dynabook hardware never shipped as Kay envisioned it. The form factor — book-sized, portable, networked, with high-resolution display and stylus or keyboard — was approximately what laptops became, twenty years later, after fits and starts. The software substrate — the part that mattered to Kay more than the form factor — was Smalltalk, and Smalltalk did ship, in successive forms, on the workstations PARC could afford to build.

Smalltalk-72: language as performance

Smalltalk did not begin as a finished proposal. It began as a series of experiments, and the experiments differed enough that the dialects each carry a different intellectual emphasis. The earliest version that ran on the Alto, Smalltalk-72, was almost unrecognizable compared to later Smalltalks.

Smalltalk-72 took the message-passing idea so seriously that it dispensed with syntax in any normal sense. An object received a stream of tokens. The object decided, by examining the tokens, what to do with them. There were no fixed grammar rules at the language level; each object parsed its incoming messages itself. This made the language extensible in directions no later mainstream language has been. New constructs — conditionals, loops, control structures — could be defined by users by writing objects that parsed the right token streams.

The cost was that Smalltalk-72 was idiosyncratic and hard to learn. Different objects responded to messages with different rules, and reading code required understanding which object was receiving and how it parsed. The expressiveness was paid for in legibility. By 1974, the group was building Smalltalk-74, which began to constrain the message-passing model — fixed selectors instead of arbitrary token streams — and Smalltalk-72 was retired as an active platform.

The Smalltalk-72 experiment is worth remembering because it shows what taking message-passing as a worldview looks like when carried as far as it can go. The mainstream object-oriented languages that descend from later Smalltalks — Java, C++, Python — preserve a much weaker version of message-passing, where method dispatch is the only message-like operation and the language's other structures (control flow, declarations, types) are syntactic features the user cannot extend. Smalltalk-72 said that even the syntactic features were objects' responses to messages. It was an extreme position, and the moderation that came in Smalltalk-76 made the language usable, but moderation also made it less radical than it had begun.

Smalltalk-76: the language coheres

Smalltalk-76 was the version where the language we now think of as "Smalltalk" came into focus. Dan Ingalls, Adele Goldberg, Diana Merry, Ted Kaehler, and the rest of the team — Kay was the intellectual leader but a smaller fraction of the implementation — wrote a Smalltalk that ran efficiently on the Alto, supported a complete bitmap graphical user interface, and shipped with an integrated browser, editor, debugger, inspector, and a library of system code that the user could read and modify.

The technical shape of Smalltalk-76 deserves naming because it is what later Smalltalks elaborated rather than replaced.

Everything is an object. Integers are objects. Booleans are objects. Classes are objects. The compiler is an object. The execution stack is an object. There is no primitive type that is not an object. Comparisons, arithmetic, control flow, and reflection are all uniform: send a message to an object and the object responds.

Computation is message-passing. The only operation is sending a message. An expression like 3 + 4 is sending the message + with argument 4 to the object 3. An expression like aCollection do: [:each | each print] is sending the message do: to aCollection with a block of code as argument. There is no statement form distinct from expression form. There is no operator dispatch separate from method dispatch. Everything is method dispatch.

Behavior lives in classes; classes are objects. Each object has a class. Each class has its own methods. Method lookup follows the inheritance chain. A subclass inherits methods from its superclass and can override them. Classes themselves are objects, instances of Metaclass, with their own methods and their own metaclass. This regularity — turtles all the way up — is one of the durable properties of Smalltalk. Java has classes-as-objects in a limited form (reflection); Python has it more fully; Ruby has it more fully still. Smalltalk had it from the beginning, without bolts.

The system is its own library. The Smalltalk environment shipped with the source for the language's libraries and tools as Smalltalk classes that the user could browse, modify, and recompile from within the running system. The class browser was the central tool. You navigated the system by navigating its class hierarchy. You learned the system by reading its source through the browser. The system's source was, in a strong sense, the system's documentation.

The user interface is part of the language. Smalltalk-76 had a bitmap display, overlapping windows, a mouse-driven interaction model, and a set of widgets — text editors, browsers, inspectors, debuggers — that lived in the same Smalltalk image as user code. The UI was not a separate subsystem with its own programming model. It was a library of classes that the user could read, extend, and replace. The same uniformity that applied to the language applied to the system the language presented to the user.

This is the Smalltalk that made the case Kay had been making since the 1960s. It was a complete, working environment in which the medium ideas — active, malleable, integrated — were demonstrated rather than theorized. By 1979, Smalltalk-76 was being used inside PARC for real work: by the kids in the Learning Research Group's tutorials, by PARC employees designing user interfaces, by researchers building simulations and education prototypes.

Smalltalk-80: the public version

Smalltalk-80 was the version Xerox released to the outside world, in a deliberate effort to seed the system in other research institutions and companies. It was published as a set of books — the "blue book" describing the language, the "purple book" describing the implementation, the "orange book" describing the system's design — and a portable specification for a virtual machine that anyone could implement.

Smalltalk-80 made the system available but it also made a quiet, important compromise. The Smalltalk-80 image, as published, was a more conservative version of Smalltalk-76, hardened for portability and for the assumption that the receiving institutions would not have PARC's specific hardware. The integrated bitmap display, the mouse-driven interface, and the assumed-always-available high-resolution graphics had to be portable across whatever workstations Sun, Apollo, HP, and the universities were running. The result was a Smalltalk that could be ported widely — and was, to dozens of platforms — but that on most platforms ran inside a window of someone else's operating system, rather than being the operating system itself.

This is a subtle loss that matters for the operating-systems argument of this book. On the Alto, Smalltalk was the operating system. The Alto booted into the Smalltalk image. There was no host OS underneath. The system Kay's group had built was a complete environment, not an application. On a Sun workstation in 1985 running Smalltalk-80, the same image ran inside a window on top of SunOS, and the user's experience was of a guest environment, not a host one. The integration that Smalltalk-76 had achieved at the system level was, for most Smalltalk-80 users, an integration only within the Smalltalk window.

This is the form in which Smalltalk reached most readers of this book, if they have encountered it at all. It is the form in which the academic study of object-oriented programming encountered it. The Smalltalk-80 books were enormously influential — they were how Bjarne Stroustrup, who designed C++, learned about classes and inheritance; how the original Java team, which included James Gosling, formed its understanding of OO; how Ruby's Yukihiro Matsumoto thought about message passing. But the form in which Smalltalk-80 traveled out into the world was already a downsized version of what PARC had built, and the further dilutions that happened as the ideas moved through C++ and Java were dilutions of an already partial picture.

Message-passing as worldview

The single most important idea Kay tried to communicate, and the one that has been most thoroughly misunderstood by the industry, is the idea that message-passing is a worldview, not a feature.

The dominant industry interpretation of object-oriented programming, by the late 1990s, was: data and the functions that operate on it should be packaged together as objects, and methods on those objects should be dispatched dynamically based on the object's class. This is, technically, what Smalltalk did. It is also a description in which the central idea is missing.

The central idea, in Kay's framing, is that an object is a small computer. Objects do not share memory. Objects do not call each other's functions. Objects send each other messages, and the receiving object decides, internally and privately, what to do with each message. The system as a whole is not a program but a network of these small computers communicating by sending messages. The closest analogy Kay used was biological cells: discrete, encapsulated, communicating only by signaling, never by reaching into each other's interior.

The reason this matters is that the worldview implies a very different model of computation than the one C++ and Java made standard. In Kay's model:

Encapsulation is total. An object's internal state is invisible to other objects, not by convention but by architecture. Other objects cannot read an object's fields. They can only ask, by sending a message, and let the recipient decide what to answer.

Polymorphism is universal. Any object can respond to any message, so long as it knows how. There is no compile-time check that the receiver supports the message; the runtime asks the object, and the object responds or signals a "doesn't understand" condition. This is structurally what duck typing in Python or Ruby is. Static-type-system devotees consider this a weakness; in Kay's view it was the point. The interactions between objects should be discoverable at runtime, not committed to at compile time.

Composition is by message. You build a system not by writing functions that call other functions but by setting up arrangements of objects that send each other messages in response to user actions and other messages. The control flow is in the messages, distributed across the participants.

Late binding is everywhere. The decision about what code will run in response to a message is made as late as possible: at the moment the message is received. This is what makes the system extensible — new objects can plug in and respond to existing messages without recompiling anything — but it is also what makes the system feel different from a statically-compiled program. The behavior emerges from the runtime configuration, not from the source code in any one place.

When Kay later said, in a famous interview, that C++ was not what he had in mind when he invented the term "object-oriented" — and that nobody had asked him to define the term — he was not being eccentric. He was pointing out that the term had come to denote a feature set (classes, inheritance, virtual methods) rather than a worldview (objects as small computers, messages as the only operation, late binding as the default).

The worldview is the part that matters for the operating-systems argument. A system organized around small computers communicating by messages is structurally different from a system organized around files, processes, and pipes. The Smalltalk environment was one possible expression of the worldview. The web — which we will return to in Chapter 10 — turned out, by accident, to be another, with HTTP playing the role of the message-passing protocol and HTML documents playing the role of the receiving objects. The worldview in pure form survives in some research languages and in agent-oriented frameworks; it does not survive in any of the systems that became standard.

What PARC did and did not get right

Smalltalk was not perfect. Some of its failures are worth naming.

The performance gap was real. On the hardware of the late 1970s, Smalltalk was slow compared to compiled C. The virtual machine was efficient by interpreted-language standards, but it was an interpreted language, and the performance penalty showed in graphics, numeric computation, and large-scale data processing. Later JIT compilation techniques — pioneered for Smalltalk dialects like Self and then transferred to Java HotSpot and to JavaScript in V8 — closed the gap, but those came too late to help Smalltalk's market position.

The single-image model was hard to deploy. If your application was an image, packaging and distributing it was awkward. You could ship the whole environment to users, but the whole environment was tens of megabytes and required the Smalltalk VM as a runtime. Compared to shipping a C executable, this was substantial overhead. Even today, Pharo and Squeak applications struggle with the same issue.

The standalone-application model was missing. Smalltalk's vision was that the user would live in the image and customize it. Industry wanted users to launch applications, do work, and quit. The image model resisted this kind of compartmentalization. Commercial Smalltalk environments — Digitalk's Smalltalk/V, ParcPlace's VisualWorks — added apparatus for packaging Smalltalk applications as more or less standalone programs, but the seam was always visible.

Kay himself, in retrospective talks since the 1990s, has expressed frustration with the implementation choices the team made and would have made differently — he has, for instance, questioned whether class-based inheritance was the right model, and pointed to prototype-based systems like Self (which came out of PARC and was a strong influence on JavaScript) as closer to what he was after. The Smalltalk that was shipped, in his view, was a snapshot of a design conversation that he wished had gone several more rounds.

What the worldview made imaginable

Despite these limitations, the Smalltalk worldview made imaginable things that no other contemporary system did. Three are worth mentioning:

The graphical user interface as we know it was substantially developed in Smalltalk, on the Alto, by Smalltalk programmers using Smalltalk as the medium. The Macintosh team that visited PARC in 1979 saw the Smalltalk environment and went home with a set of ideas — overlapping windows, the mouse, click-and-drag manipulation, menus, the desktop metaphor — that they re-implemented in the language Apple was building for the Mac. The Macintosh user interface is, at one remove, a Smalltalk artifact, even though the Mac itself ran neither Smalltalk nor anything like it.

Object-oriented programming as a discipline became, despite the dilutions, a working idiom for industry. The Smalltalk books trained two generations of language designers in a way of thinking that became the default for new languages from 1985 through 2010. Even languages that did not adopt the message-passing worldview adopted its surface — classes, methods, inheritance, polymorphism — as the standard vocabulary. The vocabulary persists.

The integrated development environment — particularly the modern IDE with live error reporting, interactive debugging, code browsing, and refactoring tools — descends in part from Smalltalk's class browser and debugger. Eclipse and IntelliJ are, at one remove, Smalltalk-environment ideas embedded in a more conservative file-and-process model.

The next chapter looks at the parts of Smalltalk that did not get diluted: the image, Morphic, and the living descendants in Squeak, Pharo, and Glamorous Toolkit, where the worldview is still being practiced by people who did not give up. Then the book turns to Plan 9, which approached some of the same problems — uniform composition, namespace-as-system — from the Unix side. Smalltalk and Plan 9 are not usually mentioned in the same paragraph; they should be, because they are two of the strongest attempts at coherent system design, by very different cultures, in the same fifteen-year window.

The Image and Morphic

The previous chapter was about what Smalltalk was supposed to be. This chapter is about the parts of Smalltalk that actually shipped, that worked, and that — in some places — are still in active use thirty-five to forty-five years after they were designed. The Smalltalk world did not end with Smalltalk-80. It went through several reincarnations, each carrying a slightly different fraction of the original argument forward, and each preserving a different part of what Unix's design did not.

Two ideas anchor this chapter. The first is the image — the running state of the system as the primary artifact. The second is Morphic — a graphical-object substrate that grew out of the Self project at Sun in the early 1990s and became the user-interface foundation for the Squeak and Pharo systems that descend from PARC's Smalltalk. The image is older and more fundamental; Morphic is younger and more specifically about direct manipulation. Together they describe what working in a Smalltalk environment is like in 2026.

What an image is, mechanically

The mechanics are simpler than the implications. A Smalltalk image is a memory snapshot. The Smalltalk virtual machine, on startup, reads the image file from disk and reconstitutes it as the running heap. From that moment on, the user's session is conducted entirely inside the image: every class definition, every running process, every open window, every variable, every compiled method exists as an object in the heap. When the user wants to save their work, the VM serializes the heap back to disk as a new image file. Restarting the VM with that file loads the state back.

This means there is no file representation of the user's program in any normal sense. There is no foo.st source file that the user edits and then compiles. The source for every method exists as text on the class, accessible through the class browser, modifiable in place. When you save the image, you are saving all of that — the source text plus the compiled bytecode plus the running stacks plus the open windows plus the in-progress debugger sessions plus the user's preferences plus the system's libraries.

This is a different unit of work than the Unix model offers. In Unix, the unit of work is the file, and the running state of a program is ephemeral: it exists from the moment of exec to the moment of exit, and serious effort goes into making sure that nothing important is held only in that running state, because the state is going to disappear. In Smalltalk, the unit of work is the image, and the running state is durable: it exists from the moment you save the image until the heat death of the universe or until you overwrite the file, whichever comes first.

The Lisp Machine model from Chapter 2 was the same idea pursued at the hardware level. The Smalltalk image is the software-only version: a single application — the Smalltalk VM — that maintains a persistent heap and presents the heap as the user's workspace. The advantage of the software version is portability: a Smalltalk image written on a Mac will run, with no changes, on a Linux box or a Windows machine if the VM is available there. The disadvantage is that the image lives inside a host operating system that does not share the image's assumptions. Saving the image is fast; saving everything outside the image — preferences in OS files, network configurations, hardware state — is not the image's responsibility, and the user gets stuck managing the seam.

What you can do inside an image that you can't easily do outside one

The properties an image gives you that file-based systems struggle to match:

Pause and resume across days. A long-running computation, debugging session, or interactive exploration can be saved as an image and resumed days, weeks, or years later. The state — variables, call stacks, partly-rendered windows — comes back exactly as it was. Some Pharo projects have running images that are years old, periodically updated by loading new code into them. The image becomes a kind of long-lived workbench.

Modify the running system without restart. Adding a method to a class affects all future calls to that method immediately. Replacing a method affects all future calls. Inheritance changes propagate through the class hierarchy automatically. The application you are working on does not need to be relaunched between iterations. The compiler is already in the image; it compiles new code into the same heap.

Reach every running thing from every other running thing. The class browser, the inspector, and the debugger can navigate the entire heap. Any object can be reached, examined, modified, or instrumented. The image is a single uniform space, not a collection of isolated processes with private memory.

Carry data through development. While you are building a feature, the data you have been working with is right there in the image. There is no reload step that resets the test cases. If you are iterating on a chart-drawing routine, the dataset is loaded; if you are debugging a parser, the half-parsed input is on the stack. The friction between "I have a state I want to keep" and "I want to write new code" is essentially zero.

The cost of these properties is that the image is opaque to the world outside the VM. A file on disk can be read by grep, processed by awk, indexed by a search engine, or backed up by rsync. The contents of an image are visible only to the Smalltalk VM. The image is an island. Modern Smalltalk environments have built up apparatus to export source code to text files for version control — Pharo's Iceberg integrates Git directly, Squeak's Monticello had its own format — but this apparatus is, in an important sense, a workaround for the fact that the rest of the world thinks in files.

Squeak: the image as a research vehicle

In 1996, Alan Kay, Dan Ingalls, Ted Kaehler, John Maloney, Andreas Raab, and several others — most of them former PARC and Apple researchers, by then at Disney's research arm — set out to build a fresh Smalltalk environment, modernized for late-1990s hardware, with an explicit goal of producing a system that could be used to teach programming to children and to do serious media research. They called it Squeak.

Squeak was, like Smalltalk-80, an image-based system. The new thing about Squeak was its implementation strategy. Instead of writing the virtual machine in C and the libraries in Smalltalk, the Squeak team wrote a Smalltalk subset called Slang, and wrote the VM in Slang. A small program translated Slang to C, which was then compiled to a native executable. The effect was that the Squeak VM was itself a Smalltalk program — the team could inspect, debug, and modify the VM using Smalltalk tools. The bootstrap was not magic; it was a translator.

This had a subtle consequence. The Squeak environment was, more thoroughly than any previous Smalltalk, all the way down. You could open the source of any method in the user interface, navigate to its callers, navigate to the system primitives those callers depended on, and (with effort) navigate into the Slang code that implemented those primitives. The boundary between "the language" and "the runtime" did not disappear, but it became porous in a way previous Smalltalks had not been.

Squeak shipped. It is still shipping. It is the platform underneath etoys, a children's programming environment that Kay's group built and that has been used in schools in dozens of countries. It is the platform underneath Croquet, an experimental 3-D collaborative environment from the 2000s. It is the platform from which Pharo forked in 2008, with the goal of producing a more disciplined, industrial-quality Smalltalk environment for professional software development.

Squeak is interesting in 2026 partly because it is itself the most direct surviving expression of Kay's PARC vision, written by the people who built that vision the first time, on a long enough runway to do it the way they had wanted to. The Squeak environment has, at its center, an unusual user-interface system called Morphic, which is the other half of this chapter.

Morphic: direct manipulation as substrate

Morphic was originally designed for Self, a Smalltalk-derived prototype-based language that Sun's research group developed in the late 1980s and early 1990s. Self, like Smalltalk, was an image-based environment with strong emphasis on dynamic compilation; its UI substrate, Morphic, was built around an idea that Smalltalk-80's UI had not quite committed to: every visible thing on screen is a live object the user can grab and manipulate.

In a standard windowing system, the UI consists of widgets — buttons, text fields, lists — that an application places on a window. The widgets respond to predefined events; the user clicks them, types into them, and the application responds. The widgets are not, in the user's mental model, things. They are controls.

In Morphic, the UI consists of morphs: objects that have a visible form on screen, a position, a behavior, and (this is the central commitment) a default ability to be picked up, moved, rotated, resized, dropped onto other morphs, and inspected. A button is a morph. A window is a morph. The desktop is a morph. The text in a text editor is a morph. Each morph carries with it, by default, a halo of meta-operations — accessible by command-click or by a designated handle — that lets the user grab it, inspect it, change its properties, send messages to it. The UI is, in the most direct sense, the object graph made visible and manipulable.

This sounds like a curiosity. It is not. The user experience that Morphic produces is fundamentally different from what a button-and-window toolkit produces. A Morphic environment encourages the user to think of the screen as a workspace in which arbitrary objects can be assembled. A child building an etoys simulation drags morphs around, connects their behaviors, and ends up with a running program that is also a UI, with no separate "design mode" and "run mode." The same gestures that the child uses to play with the simulation are the gestures used to build it.

For developers, Morphic has a related but distinct utility. Because every morph is inspectable and every morph carries the same uniform set of operations, debugging a UI in a Morphic environment is qualitatively different from debugging one in, say, GTK or Cocoa. You can grab any visible piece of UI in the running application, ask it what class it is, browse its methods, change them, and watch the change take effect. The UI is not built from opaque widgets supplied by the toolkit. It is built from objects you can read and modify on the running screen.

Pharo: image computing for production

Pharo, which forked from Squeak in 2008, is the most serious effort to make image-based development viable for industrial software work. The Pharo project has been led from INRIA in France and now by a small consortium, and has produced steady releases since 2009. The current Pharo, in 2026, is a Smalltalk environment that ships with substantial libraries, mature tooling for distributed development, integration with Git, and a community using it for production work in finance, robotics, and academic research.

Pharo's significance is not that it is better than the original Smalltalk-80 — it is, in many ways, more conservative, deliberately removing some of the more idiosyncratic features of Squeak in favor of a smaller, more consistent core. The significance is that Pharo has produced an answer to the question of whether image-based development can be done in a way that integrates with file-based source control and modern team-based software workflows. The Iceberg system, Pharo's Git integration, exports class definitions to a structured directory layout that Git can version, then re-imports them into the image when other developers' changes need to be merged. The integration is not seamless — there are still cases where the image and the repository disagree, and the user has to mediate — but it is functional.

The Pharo project's broader contribution is to demonstrate that the image-based model is not a historical artifact. In 2026, you can write a serious application in Pharo, version-control it in Git, deploy it as a packaged image, and maintain it through a release cycle that looks recognizably like how production software is built elsewhere. The user experience inside the image is still the user experience PARC had in 1980: every class is browsable, every method is editable in place, every error opens a debugger, the system is the source. Pharo is the proof that this experience can be made compatible with how the rest of the industry works.

Glamorous Toolkit: the moldable case

The most recent significant entry in this lineage is Glamorous Toolkit, a Pharo-based environment developed primarily by Tudor Gîrba and a small team at feenk. GT is, on the surface, a development environment. Under the surface, it is an argument about what tools should do.

The argument is something like this. Most software engineering effort is spent on reading and understanding code, not writing it. Tools that help with reading and understanding are systematically underdeveloped compared to tools that help with writing. The reason for the underdevelopment is that we use generic tools — text editors, IDEs with a fixed feature set, debuggers with a fixed UI — for problems that are specific to each system. The text editor does not know that this file is a YAML configuration for a Kubernetes deployment; the debugger does not know that this object is a parsed AST; the IDE does not know that this database row represents an unpaid invoice. Information that exists in the developer's head, about what the entities they are working with mean, is not available to the tools.

GT's response is to make the development environment moldable: a substrate in which developers can write small, custom views for the data they are looking at. Instead of a generic inspector that shows fields and values, GT lets you write a custom inspector for, say, an AST node that shows the source code, the parse tree, the resolved types, the call graph, and a graphical visualization, all as panes in the same inspector. The cost of writing these custom views is low — they are short Smalltalk methods. The result is that, over time, a GT-based development environment grows tools specific to the system it is being used on. The environment becomes part of the codebase.

This is, in a real sense, the contemporary continuation of what Kay was after with Personal Dynamic Media. The user is not just an operator of the tool; the user is its co-author. The tool becomes part of the artifact, customized to the artifact, evolving with it. GT pushes the image-based model into a domain — software engineering tools — where its strengths are most visible: pervasive object access, live introspection, easy customization of the running environment.

Whether GT will scale beyond its current users is an open question in 2026. It has demonstrated value in research and in a small number of production settings. It has the structural problem that all image-based systems have: it requires the developer to commit to the image as their workbench, which is a different commitment than committing to Emacs or VS Code as an editor that lives on top of the file system. The commitment is worth it for some kinds of work and not for others. The fact that the option exists in 2026 — that you can sit down at a modern computer and live inside an image — is itself worth noting.

What the image preserves that Unix has not absorbed

The Unix tradition has, over forty years, absorbed many of the surface ideas Smalltalk produced. Object-oriented languages, IDEs, debuggers, interactive REPLs, and live reloading are all part of the contemporary Unix development experience. What it has not absorbed is the deeper structural choice that the image represents.

Under Unix, the source files are the program. The running state is a temporary projection of those files. Tools are designed around the assumption that the source files are the truth and the running process is the consequence. This produces certain kinds of leverage: source files are easy to share, version, search, and reason about, because they are static text. It also produces certain kinds of friction: every time you want to act on a running process, you have to first do something — attach a debugger, dump core, log values — that translates the process's state back into something the file-oriented tools can handle.

Under the image model, the running heap is the program. The source files (when they exist at all) are export formats for the heap. Tools are designed around the assumption that the heap is the truth and that the source files are convenient projections. This produces a different leverage: live introspection is free, modifying the running system is normal, persistence across sessions is automatic. It also produces a different friction: sharing code with other people requires exporting it from the heap, versioning it requires constant export-and-reimport, and the heap is opaque to anything outside the VM.

Neither model is wrong. Each model is well-adapted to a kind of work: the file model to distributed teams shipping discrete artifacts to many users, the image model to individuals or small teams iterating on a complex evolving system that they themselves use. The industry's choice of the file model was not an error. It was an answer to the dominant question of the late 1980s and 1990s — how do we let large numbers of people collaborate on software they ship to even larger numbers of people who do not work with them? — and the file model answered that question better than the image model could.

What was lost is the model for the other kind of work: the small team building a complex tool for themselves, the researcher exploring a problem over years, the educator building a learning environment that their students can grow into. For these uses, the image was a better answer. The image model survives in Smalltalk environments because the people using them are doing this kind of work. They are not wrong to be doing it that way. They are using the right tool for the work they have, and the rest of the industry is using the right tool for the work it has, and there is no contradiction between these statements.

The next chapter turns to Plan 9, which approached the operating-system question from inside the Unix tradition. Plan 9's authors were, by background and temperament, almost the opposite of Kay's group — a Bell Labs systems team, not a PARC media research group, with a deep commitment to plain-text composability and a skeptical view of integrated environments. They produced a system that critiqued Unix from the Unix side, and that, in its own way, was as much a road not taken as anything in this book.

The Bell Labs Second Swing

In the mid-1980s, the same group of people at Bell Labs who had built Unix decided to build another operating system. They had been using Unix for about fifteen years by then. They knew, more intimately than anyone else, what was wrong with it. They had also watched as the world adopted Unix on the back of cheap minicomputers, then cheap workstations, then cheap PCs, and as the design decisions they had made under tight resource constraints in 1970 calcified into an industry-wide architecture by 1985. They had the rare combination of capability, motivation, and institutional patience that would let them try again.

What they built was Plan 9 from Bell Labs. The name is a Bell Labs joke about Plan 9 from Outer Space, the Ed Wood film widely considered one of the worst movies ever made. The system was the opposite: a coherent, carefully designed second attempt at what Unix had been a first attempt at. The people who built it were Rob Pike, Dave Presotto, Ken Thompson, Phil Winterbottom, Howard Trickey, Tom Duff, Brian Kernighan, and a small group of others — names that anyone with passing exposure to Unix history will recognize. The fact that this team, with this much credibility, with this much institutional support, built Plan 9 and that Plan 9 then failed to dent the market is one of the most instructive facts in this book.

This chapter is about what Plan 9 was. The next chapter is about what happened after.

The premise

Plan 9 started from the observation that Unix had won, that its early design choices were now embedded in everything, and that some of those choices had aged badly. In particular, the Plan 9 authors had three complaints about late-1980s Unix that motivated the new system.

The first complaint was that "everything is a file" had been a slogan more than a discipline. Unix made the file abstraction available for many things, but it also made many things not files. The network was not a file; you used sockets. Inter-process communication was not a file; you used pipes for some cases and System V IPC primitives for others. Process management was not a file; you used ps and kill, which interrogated the kernel through ad-hoc system calls. The window system was not a file; you talked to X via a binary protocol. The mouse and keyboard were not files in any directly useful sense. The actual practice of Unix had drifted away from the file abstraction in a hundred places, and the result was that the user could not learn one composition mechanism and apply it uniformly to everything.

The second complaint was that Unix had no good story for distributed computing. By 1985, Sun's Network File System and a few competing protocols had made it possible to share files across machines, but the rest of the system — processes, devices, network connections, system services — was machine-local. If you wanted to run a job that used the compute power of one machine, the disk of another, and the printer of a third, you assembled the pieces by hand, with different tools for each, and the abstraction the user lived in was always "I am on this machine, talking to that machine." There was no system-level construct that let you act on a federation of machines as a single resource.

The third complaint was that Unix's authentication and security model was a 1970s artifact that did not scale. The user was identified by a numeric UID on a single machine; cross-machine identity required separately-maintained mappings; the model assumed a small set of users on a single host, all of whom trusted the operator of the host. Networks of workstations broke this model and the patches applied to fix it — NIS, Kerberos, eventually LDAP — were complicated and full of failure modes that Unix users had had to absorb.

Plan 9's authors set out to fix all three.

9P: the unifying protocol

The architectural heart of Plan 9 is a network protocol called 9P. Everything in Plan 9 — every file, every device, every service, every running process — is accessed by sending 9P messages over a connection. 9P is, structurally, a remote file system protocol, but the trick is that everything in Plan 9 is exposed as a file system, and 9P is therefore the only protocol you ever need.

This is the slogan "everything is a file" taken literally and pushed all the way through the system, with no exceptions for inconvenient cases. Some examples of what this looks like in practice:

The network stack is a file system. To make a TCP connection, you do not call socket(). You open a file in /net/tcp/clone, read it to get a connection number, write the destination address to the appropriate connection's control file, and then read and write the data file. To listen for incoming connections, you open a file in the appropriate directory and read it; the read blocks until a connection arrives. The user is doing the same kinds of operations — open, read, write — that they would do on any file. Network programming becomes file programming.

The window system is a file system. Each window appears as a directory containing files representing the window's state: a file you write to to display text, a file you read from to get mouse events, a file you read from to get keyboard input. Programs that want to use the window system open and read and write those files. There is no protocol to learn beyond the file operations.

The process table is a file system. Each running process appears as a directory under /proc, containing files for its memory, registers, control, status, and so on. To send a signal to a process, you write to the appropriate control file. To examine its memory, you read from the memory file. To stop it, you write to the control file. The ps command becomes a directory listing; kill becomes a file write.

The system clock, the audio device, the disk, the graphics card — all of these are exposed as file systems. Each driver presents a directory hierarchy with the operations the driver supports. The user composes them with the same shell tools they use to manipulate text files.

This is more than a uniformity gimmick. The consequence is that the system has exactly one access protocol. Any tool that can read and write files can interact with any system service. Any service can be implemented by any program that can serve a file system. Any service can be made available remotely with no additional protocol work: you mount the remote machine's file system at a path on the local machine, and the services become available at that path as if they were local. The composition is the same.

Per-process namespaces

The second technical idea that distinguishes Plan 9 is the per-process namespace. In Unix, the file system layout is a global property of the machine. Every process sees the same root, the same /etc, the same /usr/local/bin. Plan 9 abandoned this. Each process — or, more precisely, each group of cooperating processes — has its own file system namespace. The same path means different things in different processes' contexts.

This matters because of the previous point. Since everything in Plan 9 is a file, the namespace controls everything the process can see. Two processes with different namespaces are, effectively, running on different machines, in terms of which devices, which services, which directories they can reach. A process can mount another machine's file system into its namespace and gain access to that machine's services. A process can hide parts of the local file system from its children by not including them in their namespace.

The mechanism Plan 9 used to compose these namespaces was the union mount. A directory in a namespace could be the union of several other directories, with a stacking order, so that lookups walked the stack until something was found. The user could, with a single command, layer a new directory on top of an existing one — say, layering their own bin on top of the system's bin — without modifying any file or environment variable, simply by changing the namespace.

The practical effect was that the configuration model that Unix had grown up around — environment variables, dotfiles, search paths — could be replaced by namespace composition. Want a different compiler in your shell? Mount it over the standard bin. Want to test a service without affecting other users? Run it in a private namespace where the standard service is hidden. Want to provide a sandboxed environment for a guest user? Compose a namespace with only the services they should see. The mechanism is the mechanism, not a special-case sandbox layer bolted on top.

This is one of the ideas that has, slowly, leaked into the Unix world over the last twenty years. Linux's mount namespaces, used by container runtimes like Docker, are a partial reinvention of the Plan 9 idea. The Linux version is implemented as a set of features on top of the conventional Unix model, with backward compatibility to single-namespace assumptions; the Plan 9 version was the model from the start. The fact that containers became Linux's most consequential 2010s innovation is not unrelated to the fact that Plan 9 had been doing this for twenty-five years and the kernel developers, eventually, ported the idea.

CPU servers, file servers, terminals

Plan 9's distribution model assumed three roles for machines, each specialized:

Terminals were the machines users sat at. A terminal had a screen, keyboard, mouse, and modest CPU. Its job was to render the user's interface and provide a local environment. Terminals were not where serious computation happened.

CPU servers were machines with substantial compute resources but no users physically attached. CPU servers ran the heavy computation that the terminals delegated to them. A user at a terminal would, when they wanted to compile a large program, send the compilation to a CPU server and watch the output appear on their terminal as if it were local.

File servers were dedicated machines that stored data. The file servers exposed their storage as 9P file systems to the network. Terminals and CPU servers mounted the file server's file systems into their namespaces and interacted with the data as files.

The key trick was that, because of the per-process namespace and the uniform 9P protocol, the distinction between local and remote was almost invisible to the user. A user at a Plan 9 terminal had, in their namespace, files from the file server, processes running on the CPU server, devices from the terminal itself, and services from any other machine they had mounted. They interacted with all of these as files in a single namespace. The system did not have to remind them which physical machine each file lived on, because the system did not care, and neither did most programs.

This is, again, a model that Unix has since approached from many directions. Distributed file systems (NFS, AFS, CIFS), remote process execution (rsh, ssh), distributed object systems (CORBA, gRPC), and most recently cloud-native architectures with their service meshes and remote-state assumptions, all reach toward what Plan 9 had. None has reached it as cleanly, because Unix's model — local namespace, separate services, distinct protocols — gets in the way. Plan 9's architecture put the distribution at the bottom of the design rather than the top.

The user model

Plan 9 also rethought authentication and the user model. The system did not assume that users had accounts on individual machines. Instead, an authentication server (the factotum later, but originally a related component) held the user's keys and answered authentication challenges on the user's behalf when the user's processes needed to access remote services. The user's identity was an attribute of a session, not of a machine. The same user could log in from any terminal and have the same namespace, the same access, the same environment, because the environment was constructed from services and file servers rather than from local machine state.

This part of Plan 9 was, by the standards of late-1980s Unix, alien. Unix users were used to having an account on each machine, with separate home directories, separate dotfiles, separate everything. Plan 9 made this seem antiquated. The price was that you had to commit to running a Plan 9 cluster — terminals, CPU servers, file servers — to get the benefit. You could not migrate piecemeal.

What was good about it

There is a strange genre of writing about Plan 9, mostly from people who used it for a few months and never went back to a Unix workstation feeling the same way about Unix. The common observation in this writing is not that Plan 9 was fast or pretty or featureful — it was, by most accounts, fewer of those things than contemporary Unix — but that Plan 9 was coherent. The same patterns worked everywhere. You learned one set of file operations and you could administer the network, manage processes, work with devices, and program the window system using them. The friction of the system was uniformly low, because there were not five different mechanisms to learn, each with their own quirks.

This is the thing Plan 9 had that Unix lacked. It is also the thing that is hardest to convey to someone who has not used the system. A demo of Plan 9 looks unimpressive: a window manager that is austere by 1990s standards, an editor (acme) that does not look like anything else, a shell that has clean syntax but feels like a Unix shell to a Unix user. The advantage of the system is not in any individual feature; it is in the smoothness with which the features combine. Plan 9 paid a one-time cost for radical uniformity and received, in return, a system where most non-obvious things worked smoothly because they had been designed by people who took uniformity seriously.

Several specific tools deserve mention. The Plan 9 C compiler suite, written from scratch by Ken Thompson and others, was small, fast, and supported a clean cross-compilation model that Unix's mainstream C compilers spent the next twenty years failing to match. The acme editor, by Rob Pike, was a mouse-driven text environment that integrated with the file system and the shell in a way no Unix editor had — you could type a command in the middle of a document and middle-click it to execute, with the output going wherever you placed the cursor. The Plan 9 shell, rc, was a clean redesign of the Bourne shell with fewer quoting bugs and cleaner control flow. The sam editor, also by Pike, had a structural-regex-based command language that prefigured later editors' multiple-cursor and search-and-edit features by twenty years. The Plan 9 system had, in short, a set of tools that were small, well-designed, and built by people who understood Unix's tools and were trying to do them again with the lessons applied.

Why it did not win

Plan 9 was made publicly available in 1992 and again, in successive releases, through the 1990s and 2000s. It had institutional support from Bell Labs through the early 2000s. It was free for non-commercial use. It was, by most accounts, technically superior to contemporary Unix workstations for the kind of work its authors did.

It did not win. By 2026, the install base of Plan 9 — across the original Bell Labs distribution, the 9front fork, and various other derivatives — is in the low thousands of active users. The system has a reputation as a beautiful curiosity. Working programmers who have used Plan 9 are an exotic minority within the population of programmers who have heard of it.

The reasons are not subtle, and they are mostly not Plan 9's fault.

Plan 9 arrived after Unix had won. By 1992, the BSD and System V lineages had standardized enough of the Unix world that an entire industry was being built on Unix assumptions. Sun, HP, DEC, SGI, and IBM were all shipping Unix workstations with overlapping but incompatible variants. The pain of moving from one Unix to another was already non-trivial. Moving from Unix to not Unix was a different category of decision. The relevant decision-makers — IT departments, university administrators, startup founders — were going to choose between Unix variants, not between Unix and Plan 9.

Plan 9 was incompatible with everything. Plan 9 was not a Unix variant. Plan 9 binaries did not run on Unix. Unix binaries did not run on Plan 9 (there was a Unix emulation environment, but it was not a first-class part of the system). The X window system did not exist on Plan 9, by design — Plan 9 had its own window system. The Plan 9 C dialect (Alef and later Limbo, plus a simplified C without the preprocessor's macro system) was not the C the rest of the world was writing. Even the file system layout was unlike Unix's. Plan 9 was a different operating system, in the strong sense, and adopting it meant porting or rewriting everything.

The hardware story did not help. Plan 9 ran on Bell Labs's custom terminals (the Gnot, the Magnum), then on commodity hardware, but it never had the close-knit relationship to a specific hardware platform that Unix had to the DEC and SPARC ranges. Without a flagship hardware partner, Plan 9 stayed in the research-system category for its commercial-decision-maker audience.

The web showed up. By 1995, the World Wide Web had become the dominant story about distributed computing. The Plan 9 architectural insight — that you could federate machines through a uniform protocol — was already being expressed, at a much higher level of abstraction and with much weaker guarantees, by HTTP and URLs. The web was Plan-9-ish enough that it absorbed much of the conceptual oxygen Plan 9 was breathing. We will return to this in Chapter 10.

Bell Labs changed. The institutional support that had carried Plan 9 from the mid-1980s through the 1990s was a function of a particular Bell Labs management environment — the one that had also carried Unix's first ten years. That environment did not survive the breakup of AT&T, the formation of Lucent, the dot-com bust, and the subsequent reorganizations. By the early 2000s, the Plan 9 authors had mostly moved on. Rob Pike and Ken Thompson eventually ended up at Google, where they used what they had learned in Plan 9 to design the Go programming language. Plan 9 itself was open-sourced and left to its community.

What survives in 2026

The ideas in Plan 9 have survived in three forms.

As features in Linux. Mount namespaces, cgroups, and the container model are partial reinventions of Plan 9 ideas. The container ecosystem in 2026 — Docker, Kubernetes, the various runtime stacks — is doing things Plan 9 was doing in 1990, with substantially worse coherence but vastly more market success.

As Go. Pike and Thompson's later language carries forward several Plan 9 sensibilities: small surface area, plain text, channel-based concurrency (which descends from the Newsqueak language Pike wrote in the 1980s and which Plan 9's threading model borrowed from), and the assumption that programs should compose. Go is the closest thing to a Plan 9 sensibility that has entered the mainstream.

As 9front. The Plan 9 community — particularly the 9front fork, which we will cover in the next chapter — is small but active. People run Plan 9 on commodity hardware in 2026. The system is still being improved. It will probably never be more than a research and enthusiast platform, but it is not dead, and the operating-systems researchers who care about the ideas in it still have a working system to point to.

The next chapter looks at Inferno, Limbo, the 9 lineage's afterlife in 9front, and what happens to a system designed by people whose institutional environment changes. Plan 9 is not the last word on the operating systems argument. It is, however, the strongest argument from inside the Unix tradition that Unix as it shipped was not the only possible Unix, and that the alternatives the same group of people could imagine — given a second chance — looked very different from what we ended up with.

Inferno, Limbo, and the Plan 9 Afterlife

Plan 9 did not end when Bell Labs lost interest in it. The system was open-sourced, a small community kept it running, and several of its authors went on to design successors that carried specific pieces of the Plan 9 idea into new contexts. None of those successors won either. But the patterns of their failure are informative — they tell us which parts of the Plan 9 argument were transferable and which were tied to conditions that no longer existed.

This chapter covers three of those afterlives: Inferno and its language Limbo, the 9front fork, and the smaller experimental descendants like Plan B. The chapter ends with a frank look at why a system whose proponents were largely correct on the technical merits nonetheless failed to take hold.

Inferno: Plan 9 as a runtime

In 1995, while Plan 9 was still being developed at Bell Labs, a subset of the same team — Rob Pike, Sean Dorward, Phil Winterbottom, Dennis Ritchie, and others — started a project called Inferno. The premise was that Plan 9's ideas were valuable, but the assumption that you would replace your operating system in order to get them was a non-starter. Inferno was designed as a portable runtime: a virtual machine and a small set of services that could run as a hosted process on top of whatever operating system you already had, or run natively on bare metal as its own OS.

The motivating use case was set-top boxes and embedded devices, an industry that was thought, in the mid-1990s, to be on the verge of a major consumer expansion. Cable companies and telecom providers were starting to ship interactive set-top boxes, network terminals, and early thin-client devices. These devices needed an operating environment that was small, networked, secure, and capable of running mobile code downloaded from the network. The Plan 9 team's argument was that they had spent a decade learning how to build such an environment and that they could productize the lessons.

Inferno's technical design carried Plan 9's central ideas through almost intact. Everything in an Inferno system is exposed as a file in a 9P-served namespace. Per-process namespaces are used to control what each running program can see. The same uniformity of file-as-protocol governs devices, services, processes, and network connections. The differences from Plan 9 are mostly in two areas: the language and the deployment model.

Inferno introduced Limbo, a programming language designed by Sean Dorward, Phil Winterbottom, and Rob Pike for the runtime. Limbo had several distinguishing features. It was strongly typed, garbage collected, and modular — a separate module system at the language level was central to how Inferno applications were composed. It had first-class channels for concurrent communication between threads, in a model derived from CSP and Newsqueak. It compiled to bytecode for a portable virtual machine called Dis, which Inferno's runtime executed and which could be JIT-compiled on platforms that supported it.

The combination — Inferno as the runtime, Limbo as the language, 9P as the protocol — produced a coherent picture: a small operating environment that could be embedded in devices, hosted on existing OSes, or run on bare metal, with a single programming model and a single distribution protocol that let services move between machines effortlessly. In 1996, this was a remarkable proposition. The Inferno team licensed the system to various vendors. A few products shipped with Inferno running underneath, including some network terminals and a Lucent VoIP product.

The story did not end there in a good way. The set-top-box market did not materialize on the timeline the Inferno team had expected. The cable companies were slower to ship interactive products than the predictions suggested; when they did ship them, they used commodity operating environments (proprietary RTOSes initially, then embedded Linux) rather than licensing Inferno. The thin-client market collapsed into the desktop-PC market as PC prices kept falling. The set-top boxes that eventually became important — TiVo, Roku, the streaming devices of the 2010s — ran on commodity Linux because by then commodity Linux was small enough, cheap enough, and supported enough to be the default.

Inferno was open-sourced in 2003 and is now maintained by Vita Nuova Holdings and a small community. It still runs. It is still maintained. It remains a useful intellectual artifact. It did not become the operating environment for the network of small devices it was designed for.

Limbo's afterlife in Go

The most consequential thing about Limbo, in retrospect, is not that Limbo itself succeeded — it did not — but that Limbo's design heavily influenced Go, the language Rob Pike and Ken Thompson designed at Google starting in 2007. Go's concurrency model — goroutines and channels — is directly descended from Limbo's threads-and-channels model, which was itself descended from Newsqueak and CSP. Go's module system is more conservative than Limbo's, but the lineage is visible.

This is one of the recurring patterns in the post-Plan-9 history. The systems themselves did not win. The ideas they incubated, when carried by their authors into the mainstream years later, found audiences they would not have found inside the original systems. Go in 2026 is, with Rust, one of the two most influential systems languages of the past fifteen years. Inside Go is a digested version of Limbo, which was a digested version of Newsqueak, which had been the experimental concurrent language Rob Pike was using inside Bell Labs in the late 1980s.

The lesson, if there is one, is that operating system design is harder to push through the market than language design. A new language can be adopted incrementally — you write some code in it, run it on your existing OS, and decide whether you like the result. A new operating system requires replacing the substrate that everything else runs on. Languages travel; operating systems do not, except in unusual circumstances.

9front: the living fork

The Plan 9 codebase that Bell Labs released has been forked several times. The most active fork in 2026 is 9front, started in 2011 by a group of developers who felt that the official Plan 9 release was no longer being maintained at the pace the user community needed. The 9front project has, over the past fifteen years, become the de facto Plan 9 distribution. The original Bell Labs distribution still exists in archived form; the active Plan 9 community is largely on 9front.

The 9front community is small. It is also serious. The project ships regular releases, maintains the kernel, ports drivers for contemporary hardware (network cards, sound cards, GPUs to the limited extent Plan 9 graphics can use them), and keeps the system viable as a daily-driver operating system for the people who choose to use it. The number of those people is in the hundreds, not the millions, but it is non-zero and it has been stable for years.

A few features of 9front are worth naming. The Hjfs file system, a simpler alternative to the original Fossil file system that Plan 9 came with, has made the system easier to install and maintain. The project has added support for more contemporary network protocols, including reasonable IPv6 support and some modern crypto. The acme editor has continued to evolve. The system runs on common 2026 hardware — recent laptops, desktop PCs, the Raspberry Pi — well enough that an interested user can install it on a spare machine and have a working Plan 9 system within an afternoon.

What 9front does not offer is integration with the rest of contemporary computing. There is no web browser of consequence; some users use a basic browser that handles simple HTML, while others read web pages through a text-mode renderer or do not read them at all on Plan 9. There is no Firefox, Chrome, or Safari, because the engineering effort to build a modern browser is well beyond what a small community can supply. There is no Slack, no Zoom, no Microsoft Teams. There is no Photoshop, no Adobe, no Microsoft Office. The cost of running 9front as your primary system in 2026 is that you have to accept that you are stepping outside the application ecosystem that most other people live in.

The users who pay this cost are not naive. They are people who have decided that the coherence of the system, the pleasure of working in a clean environment, and the intellectual interest of the project are worth more to them than the convenience of using the same applications as everyone else. They are an existence proof that Plan 9 can be a working system in 2026 if you are prepared to live with what it does not have. They are not, and never will be, a market.

Plan B and the experimental fringes

Several smaller projects have tried to push Plan 9's ideas in new directions. Plan B, a research operating system designed by Francisco J. Ballesteros, modifies Plan 9's namespace model to support volatile contexts — namespaces that change as the user moves between physical locations and devices. The motivating use case was mobile and ubiquitous computing: the user moves from their desk to a meeting room to a cafe, and the namespace adapts to expose the services available in each context.

Plan B did not become a product, but the underlying idea — that the namespace is a context rather than a static configuration, and that the system should adjust the user's view as the user's situation changes — is a research direction that remains open. The contemporary mobile computing world (smartphones, smart speakers, the various wearables of 2026) has versions of this concept buried in their architectures, usually less coherently than Plan B did and always without the file-system uniformity that gave Plan 9 its leverage.

Other experimental Plan 9 derivatives have looked at things like multi-user identity in distributed namespaces, capability-based access control on top of 9P, and unification of the Plan 9 model with cloud-style service composition. None of these have become widely used. All of them are interesting documents about what a Plan-9-derived design could look like if pushed in particular directions.

Why Plan 9 didn't win even when its proponents were right

Here is the uncomfortable part. The Plan 9 designers, by most accounts, were technically correct about most of their criticisms of Unix. The system they built is, in important ways, better designed than the Unix systems that won. The ideas in Plan 9 keep showing up in Unix-land thirty years later as if rediscovered — namespaces, containers, the file-system-as-API for system services in /proc and /sys. The Plan 9 designers also had the institutional advantage of being Bell Labs employees, the credibility advantage of being Unix's own creators, and access to enough computers and salary and patience to do the work properly. They knew exactly what they were doing.

They lost anyway. The question is why, and the honest answer is more interesting than the easy one.

The easy answer is that Plan 9 was too late. Unix had locked in. There is some truth to this, and Chapter 1 made this case at length. But "too late" is not really a satisfying explanation, because there was no point at which Plan 9 would have been on time. In 1980 it would have been a fringe research project competing with the same Bell Labs's own Unix. In 1985 it would have been competing with the BSD ascendancy. In 1990 with the workstation Unix market. In 1995 with Linux's arrival. There is no version of this story where Plan 9 catches the curl of the wave. The wave was Unix.

The real answer, I think, is about what users wanted. Plan 9 was designed by a small group of expert users for a small group of expert users. The system rewarded a kind of careful, system-aware programming that was characteristic of the AT&T research environment and rare elsewhere. The user who would benefit most from Plan 9 is someone who deeply understood Unix's deficiencies, was committed to investing time in learning a new system's idioms, and was prepared to pay the price of incompatibility with the rest of the industry. That user existed. There were probably ten thousand of them in 1995. There were not ten million.

Unix, by contrast, met users where they were. Unix was good enough for the work most people wanted to do, and the cost of learning it was low. A graduate student in 1985 could go from never having seen Unix to writing a thesis on it in a semester. A graduate student in 1985 could spend a semester learning Plan 9 — assuming they had access to a machine that ran it, which most did not — and come out the other side with deeper knowledge of a system that did not run their statistics package, their physics simulation, or their text-processing pipeline. The math did not favor Plan 9.

There is also a deeper point. Plan 9's coherence was bought at the cost of incompatibility. To get the uniform file-system interface to everything, Plan 9 had to re-implement everything. It had its own networking stack, its own window system, its own compiler suite, its own editors, its own user-space tools. None of the libraries, languages, or applications written for Unix worked on Plan 9 without porting. The coherence was real; the cost of getting it was also real.

Unix, in contrast, accumulated incoherence as the price of compatibility. Each new feature was added to the existing surface, often with poor fit, and the result was a system full of seams. But the seams meant that the existing software kept working. A C program from 1990 still compiles on Linux in 2026. A shell script from 1995 still runs. A make-based build still builds. This continuity is a feature of immense practical value, and it is a feature that Plan 9's clean re-implementation strategy could not offer.

This is a real tradeoff and Plan 9 lost it on the terms most users were making the trade. The users who would have chosen Plan 9 if they could were the users for whom system coherence was worth more than software continuity. That was a minority position in 1995 and it remains a minority position in 2026.

What the Plan 9 story tells us

The Plan 9 story is the cleanest case study in this book for a question that runs underneath everything: why don't better-designed systems beat worse-designed systems?

The standard answers — path dependence, network effects, switching costs, ecosystem lock-in — are all real, and Plan 9 suffered from all of them. But there is a deeper answer that those terms gesture at but do not name directly. Better-designed is a property of the system; winning is a property of the encounter between the system and the world. A better-designed system that fits poorly into the world it arrives in will lose to a worse-designed system that fits well. The fit can be measured in many dimensions — hardware availability, licensing, education pipelines, the personalities of the users, the funding model — and a system has to score adequately on all of them to win, while it only has to fail on one to lose.

Plan 9 was a beautifully designed system. It also required users to abandon the application ecosystem they were embedded in, learn a new system from scratch, and accept incompatibility with the rest of the industry as the price of admission. The other dimensions of fit — funding, hardware availability, market positioning — were marginal even when they were good. The system needed to score nine out of ten on adoption-friendliness dimensions to overcome the seven-out-of-ten Plan 9 had on technical-quality dimensions. It scored about three out of ten on the first set. The technical lead was real and the technical lead was insufficient.

This is the pattern that recurs throughout this book. The Lisp Machines were technically excellent and economically untenable. Smalltalk was conceptually deep and culturally hard to enter. Plan 9 was beautifully coherent and ecosystemically isolated. Multics, which Chapter 8 covers next, was ambitious in scope and expensive in deployment. Oberon was elegant and obscure. BeOS was responsive and unaffordable as a corporate dependency. Each of these systems had a real claim on superiority on some technical axis. None of them had a sufficient claim on adoption-friendliness on the axes that mattered for actually winning.

The thing to take from the Plan 9 chapter is not that Plan 9 should have won. It is that Plan 9 not winning is a separate question from whether Plan 9's ideas were correct. Many of those ideas were correct. They are showing up in Linux, in container ecosystems, in modern service architectures, thirty years later, in worse-organized forms. The ideas are recoverable. The system, as a system, probably is not. The world has moved on from a place where a small group of researchers could persuade a thousand institutions to swap out their operating system, and the world is not coming back to that place.

The next chapter goes further back and looks at Multics, the system Unix was a reaction against and that — once it is treated seriously rather than as the bloated thing Unix replaced — turns out to have made several proposals that the Plan 9 designers, working twenty years later, would partially recover. The pattern of forgetting and rediscovery, of which Plan 9 is one instance, runs through computing's history. Multics is one of the earliest cases, and one of the most informative.

Multics — What Unix Was a Reaction Against

The standard treatment of Multics in Unix folklore is as the bloated, over-engineered, committee-designed predecessor that Unix improved on by being smaller and simpler. This treatment is half right and entirely misleading. Multics was over-engineered for its hardware, costly to develop, and consumed more institutional resources than its sponsors were willing to keep paying for. It was also, on its merits as an operating system, more advanced than anything its successors produced for the next two decades. Several of its design decisions were correct, were abandoned by Unix for hardware reasons, and were eventually reinvented — usually poorly — in later systems. This chapter is about taking Multics seriously as a design rather than as a cautionary tale.

The historical frame is this. In 1965, a consortium of MIT, General Electric, and Bell Labs began work on the Multiplexed Information and Computing Service, or Multics. The goal was to build a computer utility: a single machine that could serve hundreds of users simultaneously, the way the electric utility serves hundreds of homes simultaneously, with strong protection between users, full virtual memory, dynamic linking, and a uniform file system. The system would run on custom hardware — the GE-645, later the Honeywell 6180 — designed in close collaboration with the operating system team. Multics shipped in stages from 1969 onward and continued to run, at sites across the world, until the last installation was decommissioned in 2000.

Multics did not become the dominant operating system of its era. Bell Labs withdrew from the project in 1969, judging the cost-to-benefit unfavorable; the Bell researchers who left went on to write Unix. General Electric exited the computer business in 1970 and sold its computer division to Honeywell. Honeywell shipped Multics commercially through the 1980s, with a peak install base of about eighty sites — universities, government agencies, the Air Force, a handful of corporate customers. Compared to Unix's eventual ubiquity, this is a rounding error. Compared to most operating systems' install bases, it was a respectable run for a system that was, at every point in its life, complex and expensive.

What Multics actually proposed

A clean way to read Multics is as a system designed to answer the question: what would an operating system look like if it took mainframe-style timesharing seriously and added everything the engineers of the era thought a computer should be? The answer was: it would have rings, segments, the file system in memory, dynamic linking, a high-level systems language, and a uniform protection model.

These are the parts of Multics that deserve attention now.

Rings of protection

Multics introduced the protection ring, an idea that has since survived in some form into every general-purpose CPU architecture. The Multics rings were eight nested levels of privilege; code running at a higher ring (ring 7, least privileged) could not access data or call procedures at a lower ring (ring 0, kernel) except through carefully checked gates that the lower-ring code had explicitly exposed. The system used the rings to separate the kernel, the trusted utilities, the user's own privileged libraries, and the user's ordinary application code into distinct privilege domains.

The point of the rings was not just security; it was graduated trust. Unix has a binary distinction: kernel mode and user mode. Either you are the kernel and you can do anything, or you are user-mode and the kernel checks every system call you make. Multics had a finer distinction. The user could write code at ring 4 that called code at ring 3, where the ring 3 code had more privileges to access certain resources and could enforce its own protection rules on the ring 4 code's behavior. A library could be its own little kernel, protecting its data from its callers without being part of the kernel.

This is one of the Multics ideas that nominally survived — x86 processors have four rings, and ARM has its own privilege hierarchy — but in practice does not get used. Operating systems use ring 0 and ring 3 and leave the intermediate rings unused. The reasons are partly historical (Unix-derived systems were designed around a two-ring model), partly performance-related (each ring transition has a cost), and partly cultural (writing software for an eight-ring system requires a discipline most software is not written with). The Multics idea was that protection should be a continuous design space, not a binary; the systems that came after settled on the binary.

Segments and the unified address space

The Multics memory model was based on segments. A segment was a named, variable-length, individually-protected region of memory. Each running process had access to a collection of segments — its code segment, its stack segment, segments containing data, segments containing shared libraries. The hardware supported direct addressing within segments, with the segment number and offset together forming the virtual address.

The crucial feature was that the file system was, structurally, a hierarchical namespace of segments. A "file" on Multics was a segment. When you wanted to read a file, you did not call an I/O routine to load its contents into a buffer in memory. You referenced the segment, and the hardware paged the relevant portions into physical memory on demand. The file system was memory, in a strong sense: opening a file meant adding it to your address space; reading a file's contents meant dereferencing pointers into the segment.

This is memory-mapped I/O for everything, as the default. Unix has mmap as an optional system call you can use to map a file into memory. Multics had the converse arrangement: the file system was always memory-mapped, and the byte-stream read/write model that Unix used was, on Multics, an unnecessary indirection.

The advantage was that programs could treat files as if they were data structures in memory, because they were. A program could traverse a linked list across multiple "files" by following pointers; the hardware would page in the segments containing the pointed-to data as needed. There was no impedance mismatch between in-memory data structures and persistent data structures. This is one of the things that, in retrospect, looks like a bet on a future that never quite arrived — persistent memory, mapped object stores, the long-running effort to "make everything a database" — and that Multics shipped fifty years ago.

The cost was that the model required substantial hardware support: large virtual address spaces, robust paging, hardware segmentation. The GE-645 had this hardware; the PDP-7 and PDP-11 that Unix grew up on did not. Unix's byte-stream model was, in part, what you arrived at when the hardware made the Multics model unavailable. By the time hardware caught up — by the late 1980s, virtual memory and paging were standard on workstations — the byte-stream model was so embedded in software conventions that no one rebuilt on top of segments.

Dynamic linking

Multics had dynamic linking from the beginning. When a program called a procedure in a library, the call was not resolved at compile time. The linker would, at the moment of the first call, locate the library segment, fault it into memory if it was not already loaded, look up the procedure's entry point, and patch the call site so that subsequent calls would go directly to the procedure. Subsequent calls had no per-call overhead.

The implications were structural. Updating a library meant replacing the library segment; the next process that ran would link to the new version automatically. Sharing a library across processes was free; the segment was already in the file system, and each process's address space could reference it without copying. Patching a running system meant updating libraries; the running processes would link to the new versions on their next call to the changed code.

Unix did not have dynamic linking initially. Early Unix programs were statically linked: the libraries were copied into the executable at link time, and updating a library required rebuilding every program that used it. Shared libraries came to Unix in the 1980s and 1990s — first as SunOS .so files, then as a portable standard through ELF and the various implementations of ld-linux.so. The Unix shared-library mechanism, by 2026, is functional but has noticeably more friction than Multics had: the various library-versioning rules, the failure modes when versions mismatch, the surface for security vulnerabilities exposed by the loader, the build-time complexity of writing libraries that can be shared. Multics had paid the price up front and gotten a cleaner mechanism.

PL/I as the systems language

Multics was written in a subset of PL/I, IBM's general-purpose language. The choice was, in retrospect, distinctive. PL/I in 1965 was an enormous, ambitious language designed to subsume Fortran, COBOL, and ALGOL; the subset Multics used was significantly smaller, but it was still high-level. It supported structured programming, complex data types, multi-dimensional arrays, and exception handling, at a moment when most operating systems were written in assembly or a thin macro language over assembly.

Writing an operating system in a high-level language was, in 1965, controversial. It was widely believed that the performance cost would be unacceptable and that the compiler would not be able to produce efficient code for the cases that mattered. The Multics team's bet — that the productivity gains and maintainability of high-level code outweighed the performance cost — was the same bet Unix would make a few years later with C. The difference was that Multics's PL/I was a heavier, more featureful language than Unix's C, and the bet looked more expensive when Multics made it than when Unix made it. The lesson, in retrospect, is that the bet was correct in both cases; the choice between PL/I and C was a matter of how aggressive the bet should be, not whether to take it.

The PL/I-versus-C question is also one of the cleaner cases where Unix's "simpler is better" instinct was directly load-bearing for adoption. Bringing up Unix on a new machine required bringing up a C compiler. Bringing up Multics on a new machine required bringing up a PL/I compiler. C compilers were dramatically easier to write. Once the C compiler existed, Unix followed; once the C compiler did not exist, Multics did not get ported.

Single uniform file namespace, hierarchical

Multics had a hierarchical file system before Unix did. The Unix hierarchical file system — directories containing files and other directories, slashes as separators, a single root — is one of Multics's clearest direct contributions. Multics also had file attributes (creation date, modification date, access control), per-file access control lists with named principals, and a uniform naming scheme for everything in the system. The Unix file system inherited much of this and simplified some parts. The simplifications were not all improvements: Unix's user-and-group permission model is significantly weaker than the ACL model Multics shipped with, and the cost of that simplification was an entire industry's effort to bolt ACLs back on (POSIX ACLs, SELinux, AppArmor, the various security models in Linux distributions of the 2020s).

Why Multics was hard

Multics was famously expensive to develop, slow to ship, and resource-intensive to run. The reasons are worth being specific about because they explain why "Multics" became a kind of object lesson in the Unix folklore.

The system was extraordinarily ambitious for the hardware of the period. Running Multics required custom hardware support for segmentation, paging, and rings. The GE-645 was not a commodity machine; it was, in effect, designed around Multics's requirements. This made the system expensive both to develop (the hardware and software teams had to coordinate closely) and to deploy (you needed a specific class of machine).

The system supported many things at once — virtual memory, dynamic linking, multi-language support, hierarchical access control, multi-level security — and the interactions between those features produced a complex code base. Bell Labs, in 1969, judged that the complexity exceeded what the institution could maintain for the value being delivered, and pulled out. This is the institutional moment that shapes the Unix folklore. The Bell Labs engineers who walked out of Multics carried with them, accurately, the impression that Multics had been too much. Unix's premise — small, simple, focused — was a direct reaction to that impression.

The system was hosted on a small number of expensive computers and never had a path to commodity hardware. The Multics architecture assumed a specific class of hardware that GE and Honeywell could produce in modest volumes for high prices. There was no Multics for a minicomputer, much less a microcomputer. As the industry shifted toward less expensive machines, Multics had no platform to follow it to.

The licensing and commercial story was the opposite of Unix's. Multics was a commercial product of Honeywell, sold to large customers at substantial prices, with the kind of support contracts that Honeywell's mainframe business was built around. Universities had a few sites — MIT, the original — but the system was not cheap or easy to spread the way AT&T's near-free Unix licenses spread.

What Multics got right

Reading Multics in 2026, with the experience of a half-century of operating systems to compare it against, several of its commitments look prescient.

Treating files and memory as the same thing. Multics had this. Unix did not. Modern systems that approach this — memory-mapped databases, persistent memory APIs, the various "object store" architectures — are circling back to what Multics had at the start.

Treating protection as a graduated rather than binary property. Multics had this. Unix did not. The current state of the art in container isolation, capability-based security, and microkernel architectures is a partial recovery of what Multics's ring model already provided.

Treating dynamic linking as the default rather than the exception. Multics had this. Early Unix did not, and Unix's shared-library mechanism is still less clean than what Multics shipped with.

Treating the file system's metadata as first-class. Multics had ACLs, named principals, structured access controls. Unix had owner/group/world bits, and the industry has been bolting on better mechanisms for forty years.

Treating the systems language as a high-level language. Multics did this. Unix did it less aggressively, with C, and the simpler choice was instrumental in Unix's portability — but the principle Multics established was correct.

These are not points where Multics happened to be ahead of its time by accident. They are points where the Multics team made deliberate, considered choices that have, with retrospect, mostly been vindicated. The fact that Unix won despite making weaker choices on most of these axes is the fact this book is about. It is not that Multics was right and Unix was wrong; it is that being right was not enough.

What Multics got wrong

It would be unfair to leave Multics on a clean note. The system was not perfect.

It was complex enough to be hard to learn. The Multics user manual was thick, the system's facilities were many, and the cost of becoming proficient was high. Unix's smaller surface was, for many users, a feature.

It was tied to expensive hardware and a single vendor's commercial strategy. When Honeywell exited the computer business in 1986 (the systems group was sold to Bull), Multics had no path forward. The system survived to 2000 because Bull kept supporting existing installations, but no new sites came on, and the system aged in place.

It made some commitments — multi-level security, B2 evaluation, government-customer-focused design — that pulled its evolution toward use cases that limited its applicability elsewhere. By the 1980s, Multics's customer base was dominated by military and intelligence agencies who valued its security model. The development priorities followed those customers, and the system's relevance to general-purpose computing eroded.

It did not have a portable C-style language with a low compiler implementation cost. This is the single biggest tactical failure relative to Unix. Without an easy retargeting path, the system could not follow the hardware curve as cheaper hardware became available.

The retrospective

The Multics team built a system that, on a number of axes, made better choices than Unix did. The system also cost more, required more hardware, took more years to deliver, and depended on institutional patience that ran out. Unix, picking up the parts of Multics's design that could be made cheap and dropping the parts that could not, captured a market Multics's commitments excluded it from.

This is a recurring pattern. Multics took the maximal position on most of its design axes and committed institutional resources to implementing those positions. Unix took the minimal position on most of its design axes and committed only what it had to. In a world where hardware was scarce and engineering time was expensive, the minimal-position bet won. In a world where hardware became cheap and engineering time stayed expensive, the minimal positions calcified into permanent design choices that are now hard to revisit.

The thing to take from Multics is not that it was a misunderstood paradise. It was a real system with real shortcomings and a real institutional history that explains why it died. The thing to take is that the design space Unix narrowed had been wider before Unix narrowed it. Several of the choices Unix made were not technically necessary even in 1970; they were technically necessary given Unix's resource constraints in 1970. The constraints have not applied since the mid-1980s. The choices remain in place, because they are now ambient.

Multics is the case where the system that lost had, on the merits, an argument that — taken seriously — would have produced a different forty years. The next chapter looks at two systems that lost to Unix on substantially different time scales: Wirth's Oberon, a complete vision late in a career, and BeOS, a 1990s glimpse of what consumer computing might have been. Both are smaller in scope than Multics but, in their own ways, just as instructive about the design space Unix made hard to see.

Oberon, BeOS, and the Late Possibilities

The systems in this chapter both arrived after the basic shape of the late-20th-century computing industry had been set. They are not stories of major institutional bets the way Multics was, or research-laboratory programs the way the Lisp Machines and Smalltalk were. They are stories of specific individuals or small companies trying, late, to ship a different kind of system into a market that was already converging on Unix-derived workstations and Windows-derived consumer PCs. Neither succeeded commercially. Both produced artifacts that remain useful to look at because they make visible parts of the design space that would otherwise be invisible.

Wirth's Oberon is the smaller and more austere of the two — a complete operating system, programming language, and user environment built by a tiny team in the late 1980s as a statement about how simple a complete system could be. BeOS was the larger and more populated — a 1990s commercial product that built a multimedia-focused desktop OS for consumers and bet on hardware partnerships and developer ecosystems that did not pay off. The two have almost nothing in common except that each was a complete operating system designed from scratch in the post-Unix era and each lost.

Oberon: the system as restraint

Niklaus Wirth, by the time he started the Oberon project at ETH Zürich in 1985, had already had two important careers in computing. He had designed Pascal in the late 1960s, which became the most widely taught teaching language of the 1970s and 1980s and the basis for several commercial languages including the original Apple Macintosh system language. He had then designed Modula-2 in the late 1970s as Pascal's successor, with explicit support for modular programming and modest support for concurrency. Modula-2 was a successful research and teaching language, less popular commercially than Pascal but more widely used than the dialects that came after.

Wirth's career, throughout, was characterized by a particular discipline: each language smaller than its predecessor in some important sense, each language a deliberate reduction of features down to a coherent core. Pascal removed most of ALGOL's complexity; Modula-2 removed Pascal's looser features but added modularity; Oberon, when it came, removed several of Modula-2's features in favor of a stricter core. Wirth's view was that complexity in language design was a debt that compounded, and that the way to a maintainable system was to shed features rather than accumulate them.

In 1985, Wirth took a sabbatical at Xerox PARC. He returned to Zürich convinced that the workstation paradigm — bitmap display, mouse, integrated environment — was the future of personal computing, and that the available implementations of it (the Smalltalk environment, the various Unix workstations starting to be sold by Sun) were vastly more complicated than they needed to be. Wirth, with his student Jürg Gutknecht, set out to build a complete workstation system with a small team, on custom hardware, using a single language that was strictly simpler than Modula-2.

The result, by 1988, was Oberon: a programming language, an operating system, and a user-interface paradigm, all designed together as a single coherent project. The total source code for the system was on the order of a few thousand lines. Wirth and Gutknecht published a book in 1992 — Project Oberon: The Design of an Operating System and Compiler — that contained, by their accounting, the entire system listings. The system had a compiler, a kernel, a window manager, a network stack, a file system, a text editor, and the apparatus for using all of it, in the kind of code volume that a single person could read in a few weeks.

The Oberon UI: tiled windows, executable text

The Oberon user interface was distinctive in a way that no commercial system has copied. The screen was divided into two vertical tracks, each containing tiled (non-overlapping) windows. Each window held text. The text could be ordinary prose, source code, or commands — and the trick was that commands were textual, embedded in any document, and executable by middle-clicking on them.

If a document contained the text Files.List "*.Mod", a user could middle-click on that text and the file listing would appear in another window. If a document contained the text Edit.Open "FooMod.Mod", middle-clicking would open the file in an editor. The user interface was, in this sense, a literate command system: the documents you read were full of executable affordances, and the act of using the system was largely the act of activating those affordances in place.

This produced an interaction style that is hard to describe to people who have not used it. The closest analogy in 2026 is a Jupyter notebook where every cell is also clickable as a command, where the document model and the command model are unified, and where the user lives in a kind of literate workspace that mixes text, commands, and results without distinguishing them sharply. Oberon had this in 1988 in a single coherent system written in a few thousand lines of code.

Garbage-collected systems programming

The Oberon language was strongly typed, strictly modular, and garbage collected. This last point matters because Oberon was designed to be the systems programming language for its own operating system. Wirth's bet was that garbage collection at the language level — and the absence of an unsafe pointer-arithmetic escape hatch — was compatible with operating-system performance on contemporary hardware. The bet was correct. The Oberon system was, on the custom workstation it ran on (the Ceres, designed in-house by ETH), responsive enough to use as a primary workstation. The system did not crash from pointer errors because the language did not let them happen. The Wirth claim, fairly stated, was that the entire genre of memory-corruption bugs that bedeviled C-based operating systems was avoidable at the language level, that the avoidance had modest performance cost on the hardware of the late 1980s, and that the cost had been declining and would continue to decline.

The bet has been validated many times over by now. Modern operating system kernels are still mostly written in C and increasingly in Rust, both of which use manual or compiler-enforced memory management rather than garbage collection — but the property Wirth was after, memory safety at the language level, has become a routine demand on systems software. The Singularity project at Microsoft Research in the 2000s was an explicit Oberon-style bet, with a managed-language kernel; various unikernels and managed-runtime kernels since have made similar choices. The mainstream has not gone all the way to garbage-collected kernels, but the principle Oberon demonstrated — that you can build a real system in a memory-safe language without paying an unreasonable performance price — has become orthodox.

What Oberon proved

Oberon proved that a complete system — operating system, language, environment, applications — could be built by a small team, in a short time, in a strictly small code base, if the team was willing to be disciplined about features. The system did not have everything. It did not have the application catalog of even a 1988 Mac. It was not designed for non-programmers and never tried to be. It was designed for the kind of people who would read the source for the system as part of using it, and for that audience, on the hardware Wirth's group had, it was a working environment.

The Oberon system has not died. It has descendants: A2/Bluebottle, an active-objects operating system from ETH that extends Oberon's ideas into concurrent and reactive computing; Oberon-7, an updated language; several Oberon dialects that survive in teaching and small-research contexts. There are Oberon implementations that run on contemporary hardware. The system is not zero, but it is not mainstream, and the original commercial significance was never there.

What Oberon shows is that the cost of an operating system can be much lower than the industry usually assumes, if you are willing to give up certain things. The complete Linux kernel in 2026 is in the tens of millions of lines of code. Most of that complexity is not gratuitous — it represents the cost of supporting thousands of devices, dozens of architectures, decades of legacy interfaces, and a galaxy of compatibility commitments. But Oberon is a useful counterweight: an existence proof that some of that complexity is industry complexity rather than operating system complexity, and that a determined small team can build a complete system if they are willing to drop the requirements that produce the bulk.

The 2026 reader who looks at Oberon and concludes "this is irrelevant, no real system can be that small" is missing the point. The point is not that you would build Oberon today. The point is that the line between "absolutely necessary complexity" and "complexity we have accumulated by inheritance" runs somewhere, and Oberon helps you find it. The complexity that is absent from Oberon and present in Linux is, at least in part, accumulated rather than essential. Some of it is essential. Distinguishing the two is real design work.

BeOS: responsive computing as a commercial bet

BeOS came from a completely different place. Be, Inc. was founded in 1990 by Jean-Louis Gassée, a former Apple executive, and a small team of veterans of the personal computer industry. The company's goal was to build a consumer multimedia operating system — a system optimized for the kinds of media-creation and consumption workloads that were starting to dominate the consumer PC market by the mid-1990s.

The technical bet was a kernel architecture designed for responsiveness. BeOS used pervasive multithreading. Almost every system service ran in its own thread or group of threads. The window server was multithreaded; the file system was multithreaded; the application server was multithreaded; the audio and video subsystems were multithreaded with priority scheduling that allowed real-time media to coexist with general computing. The result, in BeOS's heyday, was a system that felt qualitatively different from contemporary Windows and Mac OS: you could play video, edit audio, run a build, and operate the UI without any of these activities slowing the others down in the way they did on competing systems.

BeOS was originally designed for a custom hardware platform, the BeBox, a PowerPC-based machine with two CPUs and a distinctive hardware feature set including, famously, the "GeekPort" — a parallel I/O connector accessible from user-space programs that lets the BeBox interface with arbitrary external hardware. The BeBox shipped in 1995 and 1996 in small numbers. It was a halo product, not a serious commercial computer.

Be then ported BeOS to the PowerPC Mac in 1997, hoping that the system would become an alternative OS for Mac hardware. There was a serious moment, in 1996 and 1997, when Apple was looking for a replacement for the aging Classic Mac OS, and BeOS was on the shortlist. Apple ultimately chose to buy NeXT and use NeXTSTEP as the basis of what would become Mac OS X. BeOS, on the Apple side, lost.

Be then pivoted to x86 hardware and tried to sell BeOS as an alternative to Windows. The result, BeOS R3 through R5, was a refined desktop operating system that ran on commodity PCs, with a clean UI, fast boot time, responsive UI under load, a 64-bit journaled file system with database-style queryable metadata, and a developer ecosystem that, while small, was passionate. BeOS R5, the last major release, shipped in 2000.

The company did not survive. BeOS could not generate enough commercial traction to support Be's operations. The company sold its intellectual property to Palm in 2001 for what was reported as around $11 million, and effectively ended.

What BeOS got right

Two things in BeOS stand out for design retrospect.

Pervasive multithreading. BeOS treated every operation as potentially concurrent. The kernel and the standard libraries were designed around threads rather than processes; applications were expected to be multi-threaded, and the system's APIs made multi-threading more natural to write than single-threaded code. The result was that, on the multi-CPU hardware that was just starting to appear in workstations, BeOS scaled in ways contemporary systems did not. Mac OS in the 1990s was largely a cooperatively-multitasked single-threaded kernel; Windows was preemptively multitasked but with substantially less concurrency in its core. BeOS was, structurally, much further along on the path that all desktop operating systems eventually had to walk.

Database-style file system metadata. BFS, the Be File System, was a 64-bit journaled file system that supported arbitrary user-defined attributes on each file. Attributes were typed (strings, integers, dates, etc.) and could be queried efficiently. The Be Tracker, the file manager, used BFS queries to present the file system as if it were a database. You could ask the system to show you all email messages from a particular sender, all MP3 files of a particular genre, all photos taken on a particular date, by issuing a query against the file system's metadata index. The system did not need a separate desktop search engine because the file system was structurally a queryable database.

The Be approach to file metadata has been quietly proven correct by everything that has come since. Modern operating systems have added various forms of indexed file metadata (Spotlight on macOS, Windows Search, Tracker on Linux) on top of file systems that do not natively support it. They all face the same problem: keeping the index synchronized with the file system requires non-trivial machinery, and the integration is always partial. BFS solved this by making the index a property of the file system rather than a separate subsystem. The technical choice was correct; the commercial position was wrong, in that Be could not build the leverage to make BFS standard.

Why BeOS lost

BeOS lost for largely commercial reasons rather than technical ones.

The Apple deal didn't happen. This was the make-or-break event for Be as a company. If Apple had chosen BeOS, Be would have become the basis of Mac OS, and BeOS would have had the volume to fund continued development. Apple chose NeXT instead — partly because NeXT brought Steve Jobs back, partly because NeXTSTEP was more mature, partly because NeXT was willing to take less money for the deal. The decision was contingent on facts about both companies and about Apple's situation that had little to do with the merits of either operating system.

Driver support was insufficient. By the time BeOS was running on commodity PC hardware, the volume of hardware was enormous, and Be was a small company with a small team. The system supported the major hardware classes adequately but had gaps that became dealbreakers for users: a particular sound card unsupported, a particular printer unsupported, a particular network adapter unsupported. Each gap cost a user. Windows and macOS had the volume to ship drivers for almost everything; BeOS did not.

The developer ecosystem was small. BeOS had a passionate developer community, but small. The major commercial applications that consumer PC users relied on — Microsoft Office, Adobe Photoshop, the major email clients of the era — did not have BeOS versions. Linux had the same problem; Linux solved it partly through open-source alternatives. BeOS had open-source ports of some Linux applications but never reached critical mass.

Microsoft made it hard. This is the documented part of the BeOS story that the company itself argued about. Be claimed that Microsoft's contracts with PC OEMs effectively prevented OEMs from offering BeOS as a pre-installed alternative; the case was filed and settled in 2003 for $23.25 million, after Be had already ceased operations. The Microsoft pressure was probably not enough on its own to kill Be, but it was one of several factors that prevented BeOS from getting OEM distribution.

Haiku and the BeOS afterlife

The BeOS source code was acquired by Palm and then by ACCESS Co., Ltd., when ACCESS bought PalmSource. The open-source community started Haiku in 2001, with the explicit goal of producing a binary-compatible reimplementation of BeOS R5. Haiku is, in 2026, a working open-source operating system, still BeOS-shaped in its architecture, still featuring pervasive multithreading and BFS-derived file system features. It has had its first stable release (R1/Beta versions through the late 2010s and 2020s) and is being used by a small community.

Haiku is not a commercial product and never will be. It is, like 9front for Plan 9, the living museum of a system that should have had a better commercial fate. Running Haiku in 2026 lets you experience what BeOS felt like: a desktop operating system that boots in seconds, responds instantly, plays media without stuttering, and lets you query your file system as a database. The qualitative properties BeOS had are still there. The application ecosystem to match them is not.

What the two systems share

Oberon and BeOS are, in surface terms, very different — Oberon austere and academic, BeOS consumer and commercial. They share a less obvious property: each was an attempt to demonstrate that a complete system could be built coherently from scratch, with a small team, in the post-Unix era, optimized for a specific kind of work.

Oberon's specific work was: serious programmers reading and modifying their own system. BeOS's specific work was: consumers creating and consuming media without the system getting in their way.

Both produced working systems that demonstrated the design points they were after. Both failed to capture markets that were structurally configured against them. Both have living open-source descendants that allow a 2026 reader to run the systems and see what they felt like. Both are examples of how the post-Unix world made it harder, not easier, for new operating systems to find footholds — Unix had become the substrate, and a new system that was not Unix had to compete with Unix's ecosystem advantage even when the technical case was strong.

The cumulative lesson, by now familiar in this book, is that operating system design space is not closed. There are real choices that have not been made by the dominant systems. Oberon shows what shedding complexity gets you. BeOS shows what optimizing for responsiveness and media gets you. Both options exist, technically; both options exist, as running code; both options have small communities that maintain them. What they do not have is the network effects, the ecosystem, the OEM relationships, or the educational dominance to scale beyond their current users.

The pattern by now

Eight chapters in, the pattern is clear enough to name explicitly. A system can be technically strong, in a way that is well-documented by its proponents and verifiable to a careful reader, and still not win. Winning requires technical strength plus a set of additional properties: hardware availability at the right price point, an application ecosystem with critical mass, an institutional sponsor with patience, a path of incremental adoption, an educational pipeline that brings new users in, and timing that aligns with broader industry shifts. Unix had all of these in the late 1970s and 1980s. None of the alternatives had all of them. Most had some.

The book is now halfway done with its survey of alternatives. The remaining chapters take a different angle. Chapter 10 looks at the World Wide Web as a second Unix-style victory, with similar virtues and similar costs. Chapter 11 looks at Emacs as the carrier of Lisp Machine ideas into the Unix world. Chapter 12 looks at where Smalltalk ideas survive in 2026. Chapter 13 takes an honest accounting of what is recoverable and what is not, and the closing chapter returns to the thesis the foreword stated. The systems covered so far are the design alternatives; the chapters that follow are about what happened to the ideas after the systems lost.

The Browser as the New Shell

This chapter is about how Unix won a second time. Not by porting itself to the web — although it did that, and the web's servers are overwhelmingly Linux — but by establishing, in the web, an architecture that recapitulates Unix's design choices one level up. The web took Unix's bets — files-as-everything, plain text as interchange, small composable tools, the user as glue — and remade them as URLs-as-everything, HTML/JSON as interchange, microservices, and the user as cross-application orchestrator. The result, by 2026, is a second universal substrate that has the same kinds of virtues and the same kinds of costs as the first.

The reason this matters for the book is that the web is now the layer where most users actually interact with computers, even on Unix-derived workstations. The choices the web made are at least as load-bearing as the choices Unix made, for the working experience of most people. And the alternatives the web made invisible — the alternatives a Genera or a Smalltalk environment might have suggested — are now invisible for a second time, at a second layer. The cost compounds.

The URL as the new file path

The single architectural decision that made the web universal was Tim Berners-Lee's choice, in 1990, to use a unified resource identifier — what became the URL — to name everything the system could refer to. A URL has a scheme (http, https, ftp, mailto, file, others), a host, a path, and optional query parameters. From the user's perspective, a URL is a string that you can paste into a browser and get back a representation of something: a document, an image, a search result, a video, a form to fill out, an application.

The genius of the URL is the same as the genius of the Unix file path: it is a universal naming scheme that any program can produce or consume. A web browser does not have to know what kind of thing a URL refers to until it fetches it; a server does not have to know what the client is going to do with the response. The URL is the unit of reference that makes the entire network composable.

The cost of the URL is the same as the cost of the Unix file path: it does not say anything about what the thing being referred to is. The browser has to guess — by examining the response's Content-Type header, by sniffing the bytes, by inspecting the URL's extension. The web has, over time, accumulated dozens of heuristics for figuring out what a URL refers to, and the heuristics fail in interesting ways. The most familiar version of this is the MIME type system, which is the web's plain-text-equivalent solution to the problem Unix solved by making everything a byte stream: a string identifier that the parties involved agree, by convention, names the format.

The URL also inherited Unix's hierarchical assumption. Paths are slash-separated. The hierarchy is conventional rather than mandatory — a server can serve any URL it likes regardless of structure — but the structure is what users expect and what crawlers, caches, and indexing systems assume. A URL is, structurally, a path through someone else's namespace, and the namespace is administered by the host. The interplay between URLs and DNS, where DNS is the namespace of hosts and URLs are the namespace of resources within a host, is a two-level naming scheme that has, by 2026, become as ambient as the Unix file system was by 1990.

HTML, JSON, and plain text as interchange

The second architectural choice the web made was that documents are plain text. HTML in particular is a textual markup language: tags written in angle brackets, attributes as key-value strings, content as text between tags. The choice was deliberate. Berners-Lee chose textual markup for many of the same reasons Unix chose plain text — universal accessibility, ease of parsing, ability to write and read without special tools.

The cost of the choice was the same too. HTML's structure is poorly delineated by its serialization. Browsers have to forgive ill-formed HTML on a vast scale; the modern HTML5 parsing rules are explicitly designed to produce a useful tree out of essentially any sequence of bytes, in the same way that Unix programs are designed to forgive the wide variations in how text files end lines. The parser is the place where the world's malformed inputs get smoothed over, and the parser is enormous — the HTML5 spec's parsing algorithm is one of the largest specifications in active use.

JSON is the web's later, simpler answer for data interchange. JSON came from JavaScript, and it took over from XML in the late 2000s and 2010s because it was significantly easier to produce and consume. JSON is the web's cat-and-grep-friendly format: a text format with enough structure to encode trees of typed values, and few enough rules that any language can parse and produce it. JSON is to the modern web what plain text was to early Unix: the default exchange format that everyone agrees to.

The fact that both HTML and JSON are plain text inherits one specific Unix property: the user can pipe them. A curl call piped into jq and then into another command is, structurally, a Unix pipeline operating on web data. The shell-shaped composition that Unix's | enabled is now a normal way to work with web APIs. This is not coincidence; the people building these tools were Unix people, and they reached for Unix gestures because Unix gestures were what they had.

Microservices as small tools

The web took Unix's small-tools-composed approach and elevated it to a network-distributed pattern: microservices. The idea, current in the 2010s and now ambient by 2026, is that an application should be decomposed into a set of services each doing one thing well, communicating via lightweight protocols (HTTP, gRPC, message queues), composable into larger applications by configuration rather than recompilation.

This is, in important ways, the same bet Unix made about tools: build small things, let them be combined, do not try to build large integrated systems. The bet has the same trade-offs at the larger scale. Microservice architectures have demonstrably enabled certain kinds of large-scale software engineering — companies with thousands of developers can ship without coordinating tightly, services can be replaced individually, scaling can be applied selectively. They have also produced certain kinds of frictions: the inter-service contracts must be carefully managed, the failure modes multiply, observability becomes a major operational discipline, latency between services becomes a design constraint, and the cognitive load of understanding a large microservice system can exceed that of understanding an equivalent monolith.

The pattern of trade-offs is identical to what Unix found with small-tools composition. When the small pieces are well-designed and the composition is clean, the leverage is enormous. When the pieces are poorly aligned and the seams are rough, the cost of integration eats the benefit of decomposition. Microservices are, in this sense, Unix pipes applied to teams and machines instead of to commands and data.

The user as glue, again

The web's user, like the Unix user, is the glue between systems that were not built to talk to each other. The user has multiple browser tabs open. The user copies data from one site, pastes it into another, manually summarizes what one application told them so they can hand it to a different application, juggles authentication credentials across services, mentally tracks which window is showing which application's state. The user, in 2026, is doing the same job the Unix user was doing in 1985: orchestrating composition that the systems do not orchestrate themselves.

This is one of the under-discussed costs of the web's victory. The Smalltalk and Lisp Machine traditions had aimed to take this work off the user by providing a single integrated environment in which objects from different "applications" could interact directly. The web's federation model — where each application is a separate site, with its own data model, its own session, its own authentication — guarantees that the user remains the only entity that can integrate across applications. The data is somewhere; the integration has to happen somewhere; in the absence of system-level integration, the integration happens in the user's head and through the user's hands.

The industry has produced partial responses. APIs that let services call each other directly are one. Single sign-on systems that let one authentication carry across services are another. Browser extensions and userscripts that let the user automate cross-site behavior are a third. Each of these is a useful tool. None of them changes the architectural fact that the web is a federation of sites, and that the user is the entity responsible for synthesizing what the sites do not synthesize.

This is the same problem Unix had, scaled up. Unix tools are composable because they share a single substrate (the file system, the pipe). Web sites are composable in the same way only at the URL level; below that, each site has its own data, its own UI, its own conventions. The web is more federation, less substrate, than Unix is. The user pays the difference.

The browser as kernel

The browser, in 2026, is structurally an operating system. It manages multiple concurrent applications (tabs). It provides a programming model (JavaScript and the web platform). It mediates access to system resources (cameras, microphones, GPUs, storage, the network) on behalf of those applications. It enforces a security model (the same-origin policy and its descendants, the various permission prompts, the isolation between contexts). It provides UI primitives (DOM elements, CSS, accessibility APIs). It runs on top of a host OS, but for most users, most of the time, the browser is what they are interacting with.

This is a strange position for the browser to be in. Browsers were not designed as operating systems. They were designed as document viewers that grew into application platforms over twenty years. The system properties they have — the security model, the threading model, the storage model, the inter-application communication model — were retrofit onto a foundation that was not built for them. The result is a kind of kernel-in-a-trenchcoat, with many of an OS kernel's responsibilities discharged through evolved-rather-than-designed mechanisms.

The web platform, considered as an OS, has some of the same problems Unix did at its size and some new ones. Like Unix, it has a vast accumulated surface area; modern browser engines are tens of millions of lines of code, and the W3C and WHATWG specifications they implement are enormous. Like Unix, it has multiple competing implementations (Blink/Chromium, Gecko/Firefox, WebKit/Safari) that disagree about edge cases in ways that web developers have to navigate. Unlike Unix, it does not have a single canonical kernel and a single source tree; the relationship between specifications and implementations is contested in a way Linux's is not.

The relevant point for this book is that the browser is the new layer where the choices Unix made are being reproduced. Files-as-everything has become URLs-as-everything. Plain text has become HTML and JSON. Small tools have become microservices and embeddable widgets. The user-as-administrator has become the user-as-tab-juggler. The architecture has the same shape and the same costs.

What the web foreclosed

The interesting cost of the web's victory is the same shape as the interesting cost of Unix's: it foreclosed alternatives at its own layer.

The most direct alternative to the web's federated-sites model was a more integrated approach to networked applications. Smalltalk, Genera, and (in a slightly different way) Plan 9 had each proposed that the operating system itself could span machines, that applications could be objects communicating across the network, that the user's environment could be a coherent single space rather than a collection of separately-administered sites. These models were not adopted at the OS level — for the reasons covered in previous chapters — but the same models could have been adopted at the web level. They were not.

The web chose, deliberately, a model where each site was sovereign. There was no global object model. There was no shared data layer. There was no system-wide notion of identity. Each site had to bring its own version of all of these things. The federation was the point. The cost of the federation was that integration could not happen at the system level; it had to happen at the user level.

Alternative architectures existed. CORBA in the 1990s tried to make networked objects a system-level primitive. The various distributed-object systems (Java RMI, .NET Remoting, the early-2000s SOAP and WS-* stack) tried similar things. Each of them produced complex specifications, large vendor implementations, and modest adoption, because each of them required everyone in the system to agree to a common object model. The web, by requiring nothing except HTTP and HTML, lowered the coordination cost and won by default.

The cost is now ambient. A user in 2026 has accounts on dozens of sites, each with separate data, separate identity, separate UI conventions. The integration between those sites is provided by the user's labor and, increasingly, by intermediaries (oAuth providers, password managers, browser autofill) that paper over the federation rather than replacing it. The kind of seamless object-to-object interaction that Smalltalk demonstrated at the desktop level remains absent at the network level, and the gap is wider, not narrower, with each year of accumulated web infrastructure.

What the web preserved

It would be wrong to leave this chapter only on what the web foreclosed. The web also preserved, or recovered, some things that the desktop tradition had lost.

Distribution. The web's architecture makes networked computation the default. Any web service, by being on the web, is available to any user with a browser. This is a property the Lisp Machines and Smalltalk environments did not have; their distribution was a function of selling hardware and software licenses. The web does not require selling anything; the substrate is open. This has produced more variety of small, weird, useful tools than any prior computing paradigm.

Live updates. A web service can be improved by its developers and the improvements take effect immediately for every user. This is closer to the Lisp Machine model of a live, mutable system than the desktop application model was. It is asymmetric — the developers can update; users cannot modify the running system — but the gap between "deploy a change" and "users see the change" has shrunk to near zero, which is more than the desktop tradition managed.

Discoverability. Search engines, the URL-as-citable-name, hypertext linking, and the open-ness of the web's protocols have produced a global discoverability fabric that desktop applications never had. The Lisp Machine had introspection within the image; the web has, structurally, a planetary-scale introspection through search and links.

A second life for the small-tools mentality. The web's REST APIs, JSON conventions, and shell-callable cURL invocations have produced a kind of pipeline-shaped network computing that has more in common with Unix pipes than with desktop applications. A 2026 developer using curl, jq, and a shell to compose web services is doing something Doug McIlroy would recognize. The Unix sensibility has not been abandoned by the web; it has been carried up into the network layer.

The compound cost

The compound observation, after Chapter 1 and this one, is this. Unix won at the operating-system layer in the 1970s and 1980s. Its choices became ambient. Alternative operating systems — the Lisp Machines, Smalltalk environments, Plan 9, Multics descendants, Oberon, BeOS — were marginalized or eliminated. The design space at the OS layer closed.

The web won at the application layer in the 1990s and 2000s. Its choices became ambient. Alternative application architectures — desktop-integrated applications, networked object systems, single-image environments — were marginalized. The design space at the application layer closed.

The two closings are similar in form and they reinforce each other. A 2026 designer who wants to build something genuinely new has to fight against assumptions at two layers, not one. The web took Unix's choices and amplified them. The browser is a Unix shell with a graphical surface; the URL is a Unix path with a network prefix; the microservice is a Unix pipe with a network hop. The shape of computation we have is, in this sense, doubly Unix-shaped.

This is not catastrophe. Each of the choices is, in the same sense as before, a good choice for the work most users want to do. The web has delivered enormous value. The combination of Unix-at-the-bottom and web-at-the-top has been the substrate for an industry, and the industry has produced things — the internet itself, mass distribution of software, real-time global communication — that would have been hard or impossible on the alternative architectures this book has covered.

It is, however, worth noticing. The pattern of "ambient choice that stops looking like a choice" has happened twice now. Whatever wins next — whatever the equivalent of the 1990s web is for the 2020s and 2030s — will close another part of the design space. The way to retain the ability to see alternatives is to remember that closures have happened before and that the systems that were closed out had real things to teach.

The next chapter looks at Emacs, the most successful surviving carrier of Lisp Machine ideas into the Unix world. Emacs is what happens when one of the alternatives this book has covered manages to disguise itself as a Unix tool and slip past the assumption that Unix tools are what we have. It is not a system. It is, structurally, a system masquerading as an editor, and it is interesting partly because the masquerade has worked for forty-five years.

Emacs as the Last Lisp Machine in Costume

Emacs is the most successful piece of software ever shipped from the Lisp Machine tradition. It has been in continuous use for forty-eight years as of 2026. It has tens of millions of users by any reasonable counting. It runs on every operating system anyone cares about. It is, in the dimensions that matter for software longevity, more successful than Genera was, more successful than Smalltalk has been, more successful than Plan 9 ever became. It is also, in 2026, by any reasonable accounting, the largest and most widely used Lisp environment in active development anywhere in the world.

This is a strange fact, because Emacs is not generally described as a Lisp environment. Emacs is described as a text editor. The Wikipedia article calls it a text editor. The Linux distributions package it as a text editor. Most of the people who use it think of it as a text editor. The fact that it is structurally a Lisp Machine in disguise is a detail that the system has been quietly carrying for almost half a century, mostly successfully hiding from the world that, were the world to notice, might object to the underlying architecture.

This chapter is about what Emacs is, what it preserves from the Lisp Machine tradition, and what it has had to dilute to survive in the world that adopted it. The answer is mostly "everything important survives" and "the dilutions are real but not load-bearing." Emacs is the cleanest counter-example in this book to the pattern of the alternatives losing. It also did not win the way Unix won, but it won enough to keep going, and the way it won is informative.

What Emacs is, structurally

The naïve description of Emacs is: a text editor with a programming language for customization. The accurate description is: a Lisp environment that includes, as one of its responsibilities, a text editor.

When you start Emacs, what runs is a Lisp interpreter (more accurately, a bytecode VM with a JIT in recent versions) loaded with a large quantity of Lisp code. The Lisp code implements the buffer model, the display, the command interface, the keymaps, the syntax-highlighting machinery, the indentation rules for various languages, the file management apparatus, the package management, the documentation system, and tens of thousands of optional features that users have layered on top.

The C core of Emacs — the part that is not Lisp — provides the things that Lisp cannot easily do for itself: the bytecode interpreter, the display rendering, the underlying I/O, the memory management. The C core has, by 2026, grown to around several hundred thousand lines, mostly stable. The Lisp on top is many millions of lines if you count the standard library and the user-contributed packages indexed by ELPA and MELPA. The C is the substrate; the Lisp is the system.

This division mirrors the Lisp Machine model almost exactly. The Lisp Machine had microcode at the bottom, supporting tagged-data operations and garbage collection in hardware; above the microcode was Lisp, all the way up. Emacs has C at the bottom, supporting bytecode execution and display rendering; above the C is Lisp, all the way up. Both systems present, to the user, a Lisp environment whose features are implemented in Lisp and whose customization is done in Lisp at runtime.

The user, in Emacs, can do everything a Lisp Machine user could do in spirit if not in detail. Open a buffer, evaluate Lisp expressions in it, see the results, modify functions while the system is running, inspect the state of any variable, attach a debugger to any failing computation. Pull up the source of any built-in command and read it inline. Replace any keybinding with a new function written on the spot. Save the modified configuration as part of your init file so that the modifications persist across sessions. Build entire applications inside the editor — mail clients, IRC clients, news readers, web browsers, project management systems, version control front-ends, code editors for languages the original Emacs authors never imagined — by writing Lisp.

This is what Genera users did. The fact that Emacs users do it without describing it that way is one of the more impressive feats of marketing-by-omission in computing history.

What Emacs preserved

The specific Lisp Machine properties that Emacs preserved are worth enumerating, because they are the ones that have continued to do real work for the system's users.

Image-like persistence, in a limited form. Emacs does not save its entire heap to disk on exit, the way Genera did. But it does support persistent buffers and project state, it does load all of its Lisp libraries at startup into a single image-like environment, and the user can dump a partly-customized Emacs to disk as a new executable (using the "dump" feature) that starts up with that customization pre-loaded. The full image model is not there, but the practical effect of having a unified runtime environment is.

Live introspection of system code. Every built-in Emacs command is, to the user, a button that says "describe this function" away from being a piece of readable source code. C-h f (function help) on any command shows you what it does, what arguments it takes, and where the source lives, with a clickable link to the definition. C-h v does the same for variables. The system's source is the system's documentation, exactly as it was on the Lisp Machines.

Live modification. You can redefine a function inside Emacs and the new definition is live immediately. The next time the function is called — whether by a user keypress, by a hook, by another function — the new definition runs. There is no restart. The Lisp Machine practice of patching a running system applies to Emacs without modification.

A condition system. Emacs Lisp's condition-case and signal are direct descendants of the Lisp Machine condition system. Errors in Lisp code do not crash the editor; they open a debugger from which the user can examine the state and recover. This was inherited rather than reinvented, and it is part of why Emacs is so resilient to user customizations gone wrong.

Customization through the substrate. The Lisp Machine practice — that you customize the system by writing Lisp code that becomes part of the system — is the default Emacs practice. The init file (originally .emacs, now usually init.el or early-init.el) is a Lisp program. Configuration is programming. There is no separate configuration language, no domain-specific config syntax, no rules layer that is distinct from the runtime layer. It is all Lisp, all the way down.

Documentation as queryable structured data. Emacs's documentation system links commands to their bindings, bindings to their commands, variables to their values, faces to their definitions. The user navigates documentation by interrogating the system rather than by reading external files. The Info manuals, while text-based, are integrated with the editor's navigation primitives and live inside the same environment as the running code.

These are not minor preservations. They constitute the substantial part of what made the Lisp Machine experience distinctive, applied within a single editor application. The fact that they apply within an application rather than across an operating system is the dilution.

What Emacs diluted

The dilutions are real. Emacs lives inside a Unix process. It interacts with the rest of the operating system through the Unix process model. The buffer is not a file; it is an in-memory editing surface that can be loaded from or saved to a file. The Emacs Lisp environment cannot reach into other processes' memory, cannot redefine kernel facilities, cannot present its objects to the network as files (in the Plan 9 sense). The integration that the Lisp Machines had at the operating-system level, Emacs has only inside its own process.

This boundary has consequences. Some specific ones:

Emacs cannot make other applications introspectable. Inside Emacs, every function is browseable. Outside Emacs, you are back in the Unix process model, with whatever introspection apparatus the host OS and the running programs choose to expose. An Emacs user editing a JavaScript file can browse the Emacs Lisp implementation of the JavaScript mode but not the JavaScript engine's internals.

Emacs cannot persist arbitrary running state. Emacs can save buffers, projects, and configurations across sessions. It cannot save the full running state of the Lisp environment the way Genera could save a band. Restarting Emacs reloads the Lisp libraries and reconstructs the environment; the user's interactive state — the history, the open buffers, the position in each — is preserved through specific mechanisms (desktop.el, savehist, recentf), not through image-level persistence.

Emacs is a guest in the OS. It does not own the display the way a Lisp Machine did. It cannot drive devices directly. It cannot speak to the network without going through OS-level APIs. The Lisp environment is sovereign within itself; outside its boundaries, it is just another Unix process competing for the operating system's attention.

These dilutions are the price Emacs paid for being a Unix application instead of a Unix replacement. The price was, in retrospect, worth paying. Emacs got to live in the Unix world rather than fighting it, and as a result Emacs got to live, while the Lisp Machines did not.

Why Emacs survived

The Emacs survival story is, in some ways, the most encouraging piece of evidence in this book that the Lisp Machine ideas were not stranded by their hardware. They could be carried in a Unix process, they could be made portable, they could be made distributable as free software, and they could acquire and keep a user base across decades. The proof is Emacs, sitting on every developer's machine that has a Unix-like OS underneath.

The specific reasons Emacs made the transition that Genera could not are worth being honest about.

Emacs ran on commodity hardware. From its earliest portable versions, Emacs targeted whatever Unix workstation the user had. There was no Emacs hardware. The system did not require custom silicon, did not require an unusual memory configuration, did not need specialized graphics. It ran in a Unix process on whatever Unix the user had bought a workstation for. The cost of adopting Emacs was downloading and compiling it.

Emacs was free. Richard Stallman's choice, made in the early 1980s, to release Emacs under the GPL (then in its evolving forms) meant that Emacs was available to anyone with a Unix machine for the cost of typing some commands. There was no licensing apparatus, no proprietary restriction. Universities adopted Emacs because there was nothing to negotiate. Developers adopted Emacs because they could read the source. This was the same property AT&T's Unix licensing had given Unix; Stallman's choice gave Emacs the same advantage.

Emacs hid its Lisp nature. The Emacs presentation to new users was as an editor. The fact that you could program it in Lisp was an advanced feature, not a barrier to entry. A user could be productive in Emacs for years before they wrote a single line of Lisp, using the system as a powerful editor with built-in commands. This avoided the cost-of-entry problem that had killed the Lisp Machines, where you had to commit to the Lisp environment before you could do anything. Emacs let the user start with the editor and discover the environment later.

Emacs was useful at every scale. From a simple text editor to a complete email-news-IRC-development environment, Emacs scales smoothly with how much the user wants to invest. Most users use ten percent of the system and never look at the other ninety. A few users use most of it. Both groups are well-served. The Lisp Machines had a higher minimum buy-in; Emacs has effectively none.

Emacs was carried by a community. The GNU Emacs project has had continuous active development since 1985. The XEmacs fork in the 1990s and 2000s provided a competing line that eventually rejoined into modern GNU Emacs's feature set. The community has produced massive package ecosystems (ELPA, MELPA), distributions (Spacemacs, Doom Emacs, Prelude), and configurations. The Lisp Machines never had this kind of broad community; their user base was small and the people maintaining them were a handful at any given time. Emacs's community, by contrast, has been continuously several orders of magnitude larger.

The cost of carrying the tradition this way

Carrying the Lisp Machine ideas inside a Unix process has had costs that are worth being clear about.

Performance. Emacs Lisp, by long-standing convention, has been an interpreted language, then a bytecode-interpreted language, with a JIT in recent years (native-comp, which became default in Emacs 28). It has historically been slower than the compiled Lisps that ran on Lisp Machines. The native-comp work has closed much of the gap, but Emacs still pays a cost for being a Lisp environment hosted inside a Unix process running on commodity hardware. Users notice this in startup time, in syntax highlighting on large files, in the responsiveness of editor commands that do a lot of computation.

The buffer model is not the heap model. Emacs's primary data structure is the buffer — a sequence of characters with attached properties. This is a fine data structure for editing text. It is not the same as the Lisp Machine model where the data structure is the heap and the editor is one of the things that displays parts of the heap. The buffer model means that Emacs is, structurally, an editor; the Lisp environment serves the editor rather than being the primary surface. A Genera user who wanted to manipulate a database table did not put the table in a buffer; they manipulated the table directly through inspectors that understood tables. An Emacs user who wants to manipulate a database table edits text that represents the table or builds custom modes for tabular data, with the buffer underneath.

The display model is text-first. Emacs has acquired some graphical capability over the decades — embedded images, more sophisticated overlays, the recent work on tree-sitter integration and richer display — but the underlying display model is a grid of characters with attached properties. The Lisp Machines had a full bitmap graphics model from the start, with the Dynamic Window facility on Genera providing fully graphical, mouse-interactive, object-oriented displays. Emacs's display is, by comparison, a constrained surface. The constraint is part of why Emacs is portable — character grids work on text terminals as well as graphical ones — but it is a real limit on what Emacs can express.

The user has to do the integration. Like with the web, Emacs users find themselves doing the cross-application integration that Genera would have done at the system level. An Emacs user wanting to use email, calendar, project management, source code editing, and chat in an integrated way ends up wiring together separate Emacs packages, each with its own conventions, and dealing with the seams. The integration is better than it would be across separate native applications, but it is worse than it would have been in a single image with uniform object access.

Why this chapter matters

The reason to spend a chapter on Emacs in a book about operating systems is that Emacs is the strongest available evidence that the alternatives this book has covered are not impossibly far away. The Lisp Machine model, in particular, has a working implementation right now, on the machine of almost every reader who is going to read this book, with a user base of millions. The ideas are not gone. They are sitting in /usr/bin/emacs.

This matters for the closing argument of the book. The "what's recoverable" question of Chapter 13 has, in Emacs, an existence proof on the optimistic side. Some of what we lost when Unix won is recoverable, because it has been quietly continuing inside a Unix tool the whole time. An Emacs user, while editing a configuration file, is living inside a partial Lisp Machine. The fact that they may not realize it does not make it less true.

The Emacs story also tells us something about the transmission mechanism. Ideas survive when they can be carried in a form that does not require everyone to switch operating systems. Emacs survived because it did not ask Unix users to leave Unix. It asked them to install one more program. The cost was small enough that the program got installed, and the cost stayed small enough that the program kept being used. The Lisp Machine ideas, packaged this way, traveled. Packaged as a complete operating system requiring custom hardware, they did not.

This is a generalizable lesson. The systems in this book that died at the OS level survive better when they are repackaged as guests inside the dominant OS. Smalltalk survives in Pharo, hosted by Linux or macOS. Lisp Machine ideas survive in Emacs and in SLIME-style tooling. Plan 9 ideas survive as containers in Linux. The host environment, having won, becomes the carrier of the alternative ideas. The carrier is a compromise, but it is a working compromise, and the alternative — extinction — is worse.

The next chapter looks at where Smalltalk's ideas are living in 2026, including the modern Pharo and Glamorous Toolkit projects covered in Chapter 5 plus the broader pattern of Smalltalk concepts surfacing in other languages and tools. Then the book turns to honest reckoning: what is recoverable, what is permanently gone, and how a reader in 2026 should think about both.

Where the Smalltalk Ideas Live Now

Smalltalk lost the operating-system fight, lost the application-platform fight, and lost the language-popularity fight to the C-family languages it had originally inspired. By any straightforward measure, Smalltalk in 2026 is a niche. The number of programmers earning a living in Smalltalk is small. The number of companies maintaining Smalltalk codebases in production is smaller. The likelihood that a graduate of a computer science program in 2026 has written a meaningful program in Smalltalk is essentially zero.

And yet — almost every working programmer in 2026 uses Smalltalk ideas every day, in disguised forms, in systems that do not advertise the lineage. This chapter is an honest accounting of where those ideas survive: which ones made it through, which ones were watered down to the point of unrecognizability, and which ones are still being practiced in their original form by the small but stubborn communities that did not give up.

The living Smalltalk environments

Chapter 5 covered Pharo and Glamorous Toolkit in some detail. The short version: there are working modern Smalltalk environments, they are maintained by small communities, and they preserve the image-based model and the Morphic UI substrate. A reader in 2026 who has never seen a Smalltalk environment can install Pharo in an evening and experience the original PARC sensibility on contemporary hardware.

The community is real. Pharo has annual conferences (ESUG, the European Smalltalk User Group, has been meeting since 1993). Squeak has been continuously released since 1996 and is still the platform for several long-running research and education projects, including the etoys learning environment. Glamorous Toolkit has shipped multiple major releases since 2019 and has working users in research and small-team product development. The Smalltalk world is small but does not have the character of an end-stage project; it has the character of a stable minority practice.

A second category, broader and less coherent, is the commercial Smalltalk that continued to ship after PARC. ParcPlace's VisualWorks, Digitalk's Smalltalk/V, IBM's VisualAge for Smalltalk — these were commercial products of the 1990s. VisualWorks continues today as Cincom Smalltalk; VisualAge for Smalltalk evolved into IBM/Instantiations VA Smalltalk. Both have customers, mostly in finance and healthcare, running production systems written in the 1990s and 2000s and maintained ever since. The annual budgets keeping these systems alive are modest by industry standards but real. The systems work. They are not famous because the customers do not benefit from being known to use Smalltalk; some of them, in fact, would prefer it was not widely known. The result is a quiet running base of production Smalltalk that does not show up in language popularity surveys but does show up in payrolls.

The third category is the Smalltalk-influenced research and tooling work that continues to feed back into the mainstream. The Pharo team's research on object-centric debugging, on moldable inspectors, on remote development in image-based environments, has been picked up by various IDE projects elsewhere. The Glamorous Toolkit team's work on moldable development is one of the more interesting active research programs in software tools. Some of this work will, over the next decade, propagate into mainstream IDEs in the same way that earlier Smalltalk research did into Eclipse and IntelliJ.

Self and the JIT lineage

The most consequential post-Smalltalk research project, in terms of where its ideas ended up, was Self. Self started at Xerox PARC in 1986 and continued at Sun Microsystems through the 1990s. It was, in technical terms, a Smalltalk variant — same image model, same live environment, same Morphic UI heritage — with one major change: Self was prototype-based rather than class-based. Objects inherited from other objects directly rather than from classes. The class concept did not exist in Self; what other languages would call a class was just another object that happened to be referenced by other objects as their parent.

Self never had more than a few hundred serious users. As a language, it was a research curiosity. As a project, it was something more important: Self was where modern just-in-time compilation for dynamic languages got invented.

The Self project's compiler, designed by Urs Hölzle, David Ungar, and Lars Bak, was the first practical JIT compiler for a dynamic language. Self was a fully late-bound language — every method call could go anywhere, every variable was dynamically typed — and the conventional wisdom was that such languages could not be efficiently compiled. The Self compiler proved that they could. It introduced techniques — type feedback, polymorphic inline caches, speculative inlining, deoptimization on type mismatch — that became the standard toolkit for compiling dynamic languages efficiently.

Sun shut down the Self project in the late 1990s, but the people went on to use the same techniques in other places. Lars Bak and Urs Hölzle worked on HotSpot, the just-in-time compiler that made Java performance competitive with C++ for many workloads. Lars Bak later led the team at Google that built V8, the JavaScript engine that made web applications a tolerable platform for serious software. Both of these projects descend from the Self work. The JIT-compiled, garbage-collected, dynamic-language runtimes that power most of the software people use in 2026 — the JVM, the CLR, V8, Node.js, the various Python and Ruby JITs — are working with techniques that came directly out of Smalltalk research and were proven on Self.

This is one of the cleaner cases of an alternative tradition's ideas surviving in dilution. Java in 1995 looked, on the surface, like an industry response to C++'s complexity. Java was actually, in its semantics, a Smalltalk-influenced language with C-like syntax: garbage collected, dynamically dispatched, with a single inheritance hierarchy descending from a root Object class, with reflection, with introspection at runtime. It was Smalltalk for people who would not adopt Smalltalk. The wrapper was different; the contents were largely the same.

Similarly, JavaScript began life as a Self-inspired prototype-based language with a syntax designed to look like Java to make it palatable. The prototype-based object model that JavaScript uses is directly from Self. The decision to make objects mutable bags of properties, with method dispatch resolved at runtime, is a Self design. The fact that modern JavaScript has class syntax now is a 2015-era cosmetic addition on top of the underlying prototype-based system; the prototypes are still there.

This means that, in the most-used programming language in the world — JavaScript, with all of the browser-side and server-side software that runs in it — the underlying semantics are descended from a research project in late-1980s Stanford that had a few hundred users. The Self lineage is everywhere. Most JavaScript programmers do not know it is there. They do not need to.

Object-oriented programming as dilution

The most-discussed Smalltalk-to-mainstream transfer is, of course, object-oriented programming as an idiom. C++ from the 1980s, Java from the 1990s, C# from the 2000s, Ruby and Python with their OO features, Swift and Kotlin and Dart and the various mobile-platform languages of the 2010s and 2020s — all of these are "object-oriented" in a sense that traces, through documentation lineage, back to Smalltalk.

The dilution is, as Chapter 4 covered, substantial. The mainstream OO languages preserve the syntactic surface of Smalltalk — classes, methods, inheritance, polymorphism — while dropping or compromising most of what Kay considered essential. Message-passing as a worldview is gone, replaced by static-dispatch method calls with vtable lookups. Encapsulation, in many of the languages, is a convention rather than an enforcement. Late binding is muted; many of these languages prefer compile-time-resolved calls when they can manage them. The systems built in these languages are not Smalltalk systems written in different syntax. They are imperative-language systems with object-shaped wrappers.

This dilution is, again, the price of mass adoption. The Smalltalk worldview was hard to learn. The OO surface was easier to learn. The industry adopted the surface and left the worldview behind. The result is languages and systems that have most of the engineering benefits of Smalltalk's encapsulation while keeping the performance and tooling familiarity of static languages. The trade is, in industrial-engineering terms, reasonable. The trade is also one of the larger cases of "the alternative had to be flattened to fit the market."

The exceptions are interesting. Ruby is the mainstream language whose semantics are closest to Smalltalk's. Yukihiro Matsumoto, Ruby's designer, has explicitly cited Smalltalk as the main influence and aimed to produce a language with Smalltalk's openness and reflective power in a syntax that Perl programmers could pick up. Ruby has, structurally, the things Smalltalk has: pervasive method dispatch, runtime introspection of every object's class and methods, the ability to reopen classes and add methods at runtime, blocks as first-class arguments to methods. The Rails framework that put Ruby on the map made heavy use of these properties. Modern Ruby remains the most Smalltalk-feeling mainstream language; if you have programmed in Ruby and never in Smalltalk, you have used about 70% of what Smalltalk gives you, in a more conventional file-based deployment model.

Smalltalk's other strong mainstream descendant is Objective-C, which Brad Cox and Tom Love designed in the 1980s specifically to add Smalltalk-style message passing to C. NeXTSTEP (and later macOS and iOS through the 2010s) was built in Objective-C; many of the open-source frameworks that shipped in those systems used the message-passing model from Smalltalk in ways that conventional OO languages of the era could not. Swift, which has been replacing Objective-C inside Apple's platforms, is more conventional but inherits some of the Smalltalk-via-Objective-C sensibility about reflection and dynamic dispatch.

Jupyter as a watered-down image

The other Smalltalk-influenced surface that has had considerable contemporary success is the notebook environment. Jupyter, originally IPython, is the most visible example, but the genre includes Mathematica notebooks (older than Jupyter, by a lot), Observable, the various R Markdown environments, and the document-based interactive environments that have become standard in data science and machine learning workflows.

A Jupyter notebook is, structurally, a degraded version of the Smalltalk image model. The notebook contains a sequence of cells. Each cell holds code, prose, or output. The user runs cells against a long-running kernel process that maintains a persistent execution state. The user can re-run cells in any order, modify their contents, see results inline, and save the entire document — code, prose, and output together — as a file.

The Smalltalk inheritance here is twofold. The image-like persistence — the running kernel state outliving the individual cell executions — is the substantive borrowing. The notion that a document can contain executable code interleaved with prose and results is from Smalltalk's project notebooks and Mathematica's notebooks before that, both of which descend from earlier ideas about literate programming and active documents that PARC researchers had been working on since the late 1970s.

The dilution from Smalltalk to Jupyter is substantial. The notebook kernel has the image-style persistent state, but the notebook surface treats that state as a side effect of running cells rather than as the primary artifact. The cells contain text representations of code, which can drift out of sync with the kernel's idea of the program's state — a common source of bugs in long-lived notebooks, where re-running cells in a different order produces different results than the cells suggest. The Smalltalk image was authoritative; the Jupyter cell sequence is a hint.

The notebook genre's success — across data science, scientific computing, and increasingly other technical fields — is evidence that the user interface for image-based computing has real value. The dilution is in the implementation. A more Smalltalk-faithful notebook environment would treat the kernel state as primary and the cell sequence as one of many possible projections of that state. Some of the more recent notebook environments — Observable, for instance — push in this direction by making cells reactive functions of each other rather than imperative scripts. Glamorous Toolkit's playgrounds are another version of the same idea, with the Smalltalk-faithful semantics preserved.

The general point is that the notebook genre is what happens when the image idea gets attractive enough to be ported into the dominant computing paradigm. The port is partial. The use is real. The Smalltalk-style image is the parent, even when the children do not know who their parents were.

Direct-manipulation UI and the Morphic afterlife

Morphic itself, as a substrate, has not won. Most operating-system user interfaces in 2026 are not Morphic. The mainstream is a stack of widget toolkits — Win32, Cocoa, Qt, GTK, the various web frameworks like React and Vue — that present applications as fixed compositions of components that the user can interact with through prescribed gestures.

Direct manipulation as a principle, however, has won. The idea that the user should grab objects on screen, manipulate them as physical-feeling entities, see immediate visual feedback, and have undo as a first-class operation, is so embedded in contemporary UI design that it does not need defending. The Smalltalk tradition pushed direct manipulation harder and earlier than most competing systems, and the influence is visible in every drag-and-drop interface, every modern touch UI, every interactive design tool.

The direction further than mainstream UI has been willing to go — the direction Morphic and the Self UI pushed, where every visible thing is a live object that can be inspected and modified at runtime — has been adopted only in research environments and developer tools. The contemporary user interfaces of consumer applications are direct-manipulation on the surface and rigid underneath; the user can move the button but not redefine what the button does. Smalltalk's vision was that even the second operation should be available. Most users do not need the second operation, and most application developers do not want to support it. The vision lives in development environments where the user is a developer.

This is the pattern again. The mainstream takes the part of the radical idea that mass users want — direct manipulation on the surface — and leaves behind the part that radical users want — direct manipulation all the way down. The mass adoption is real progress over the previous generation of UIs. The radical option is still there for the people who want it, in environments like Pharo and GT, with much smaller user bases.

The harder reckoning

The pattern from the previous chapters and this one is becoming visible. The Smalltalk ideas survive in three forms:

Diluted into the mainstream, where they have become so ambient that the lineage is not visible. Object-oriented programming as a paradigm. Just-in-time compilation for dynamic languages. Garbage collection as a system service. Reflection as a language feature. Direct manipulation as a UI principle. The image-like persistence in Jupyter notebooks. All of these are now present in everyone's daily computing experience. None of them are at the strength PARC originally proposed them, but the weakened forms are real and useful.

Preserved in their original form in the small Smalltalk environments — Pharo, Squeak, Glamorous Toolkit, Cuis, the commercial Smalltalks. These are working systems with active communities. They are not going to take over the industry. They are not, however, going away. The full Smalltalk experience is available to anyone who wants it in 2026, with modern hardware and modern Git integration.

Carried forward by individual researchers and engineers who absorbed the ideas at one stage and are pushing them somewhere else. Glamorous Toolkit is the most visible example, but the broader research community in human-computer interaction, in moldable tools, in live programming, has Smalltalk ideas at its center. The work continues. It just continues in pockets, on small budgets, with researchers whose names are not famous outside their fields.

The harder reckoning is that the integration the Smalltalk tradition produced — the integration of language, runtime, environment, UI, and user — has not transferred. What transferred were the pieces. The pieces are useful in their new contexts. The integration is gone.

A 2026 software developer can have, individually:

• A garbage-collected language (Python, Ruby, JavaScript, Java, C#, Go, Kotlin, Swift, almost anything modern).
• A live REPL (in any of the above, with various levels of completeness).
• A debugger that lets you examine state at a breakpoint and continue.
• Hot code reloading in some frameworks (Phoenix, Rails in dev mode, web bundlers with HMR).
• Reflection on objects at runtime.
• Direct manipulation in the editor (modern IDEs with refactoring tools).
• Notebook-style persistent state for exploratory work (Jupyter, Observable).
• Documentation-as-data via reflection-based introspection (the documentation strings, type hints, IDE tooltips).

What they cannot have, in a single integrated environment, on top of their host operating system, with their main programming language, on the hardware they bought from a normal vendor, is all of these at once, integrated, with the same fluency, in the same workspace. That integration was what the Lisp Machines and the Smalltalk environments offered. The integration is, for the mainstream stack, structurally unavailable. You can get close in Emacs for some kinds of work. You can get closer in Pharo if you accept the cost of leaving the mainstream stack behind. You cannot get there in VS Code editing a Python file on macOS, no matter how good the tooling gets, because the underlying architecture does not support it.

This is the part of the loss that Chapter 13 will return to. The diluted forms are mostly enough for most work. The integration is gone, and the gone-ness is structural, and getting it back would require either replacing the substrate or building a guest environment that, like Pharo, lives inside the substrate and pays its own integration cost privately.

What this chapter is for

The function of this chapter, like the previous one, is to take the loose anxiety that runs through the book — "we lost something" — and put concrete inventory items on the page. Smalltalk lost. Smalltalk's ideas survived, mostly in pieces, mostly in dilution, mostly in mainstream languages whose users do not know the lineage. The pieces are doing real work. The whole — the integrated Smalltalk environment as PARC built it — is available, in Pharo and its siblings, for anyone who wants to use it.

That is the answer to "what happened to Smalltalk?" The answer is more interesting than "it died." It is closer to "it diffused, with the most acceptable parts becoming standard and the most distinctive parts surviving in small enclaves." This is a normal outcome for a research tradition. It is not, contrary to some Smalltalk advocates' framing, a tragedy. It is the same shape of outcome that has happened to many research programs in computing, and it leaves the door open for further transmission of the unflattened ideas, by people who are willing to pay the cost of carrying them.

The last full chapter takes the broader question that this chapter and the previous one have been circling around: in 2026, which of the things we lost when Unix won are recoverable, which are gone for reasons that have to do with the world rather than Unix's winning, and which are simply not coming back? The book has built up enough context, by now, to answer this honestly. The closing chapter then returns to the thesis.

What's Recoverable, What's Permanently Gone

The previous twelve chapters have surveyed alternatives to Unix that lost. This chapter takes inventory. Some of what was lost is recoverable, in the sense that a person or team in 2026 can adopt the ideas and use them productively. Some of what was lost is not coming back — not because Unix won, but because the world in which the alternatives could be built has changed in ways that make rebuilding them either impossible or pointless. The chapter's job is to distinguish these two categories honestly.

A few ground rules for the inventory.

First, recoverable does not mean mainstream-adoptable. Some things are recoverable for an individual or a small team and not recoverable for the industry. The two are different categories and the chapter will keep them apart.

Second, permanently gone does not mean unmissed or unimportant. Some of the most valuable things this book has covered are in the permanently-gone category. Their permanence does not diminish their value; if anything, it heightens the cost of the loss.

Third, the dividing line between the categories runs through specific facts about the contemporary world — networking, security, hardware diversity, the threat model — not through facts about Unix specifically. The book has been careful, throughout, to avoid blaming Unix for everything. The same care applies here. Some losses are downstream of Unix's win; others are downstream of unrelated changes in the world; many are both.

Recoverable: image-based development for individuals

The single most clearly recoverable property covered in this book is image-based development as a personal practice. The Smalltalk and Lisp Machine traditions both had this property at their core. It survives, in usable form, in 2026 in Pharo, Squeak, Glamorous Toolkit, SBCL with SLIME or Sly, Clojure with its REPL-based workflow, and Emacs with various extensions that approximate it. The cost of adopting image-based development for an individual is the cost of installing one of these environments and committing to using it for a class of work that suits it.

The class of work is real but specific. Image-based development pays off when you are iterating heavily on a complex system you will use for years, when fast feedback is valuable, when persistent state across sessions saves work, and when you do not need to ship a static artifact to many users. Research, custom internal tooling, long-running exploratory analysis, simulations, scientific computing, certain kinds of personal productivity tooling — all of these are well-suited.

The class of work where image-based development pays off poorly is also real: shipping a static artifact to many users, building software that has to run on a server you do not control, working on a team where everyone needs to be productive in the same environment, working on a system whose code base must be visible to standard text-based tools (linters, search, automated review). In these cases, the file-based model has fewer seams.

What is recoverable here is the choice. The 2026 reader does not have to choose between image-based and file-based development as ideologies. Both are available. The choice should be made per project, based on the work's actual shape. The recovery is in the availability of the option. The dominant industry choice does not foreclose the option; it just means you have to ask for it.

Recoverable: live code reloading and condition-style error handling

The Lisp Machine practice of replacing a running function and having the system pick up the new definition immediately is, in 2026, broadly available. Erlang, Elixir, and Clojure ship this property as a first-class part of their development workflow. Common Lisp ships it directly. Smalltalk has it. Many web development frameworks (Phoenix, Rails in dev mode, the Vite ecosystem with HMR) provide weaker versions of it. Python's notebook environments have it. Even Emacs Lisp's eval-defun has it.

The condition system — structured error handling with restarts that the calling code can register — is rarer but recoverable. Common Lisp has it. Clojure has it. Smalltalk has it. The Ruby and Python rescue/except mechanisms are weaker forms; they recover but they do not let the recovery point be chosen by the caller from a menu of options that the called code registered. The full condition-system experience is available if you use one of the languages that has it.

What this means for a 2026 developer is that these properties are choices you can make at the language and framework level. They are no longer experimental research-system features. They are mature, productionized capabilities that any team can adopt. The recovery is in the available options, not in their universal application.

Recoverable: structural composition of services

Plan 9's per-process namespaces and 9P-style uniform protocols are, in compromised form, recoverable in 2026 through the container ecosystem. Linux mount namespaces, cgroups, network namespaces, and the various userland tools built on them (Docker, Podman, Kubernetes, containerd) provide a worse-engineered version of what Plan 9 had natively. The composition that Plan 9 achieved by mounting file systems is achieved, in 2026 Linux, by composing container images, volumes, and network configurations.

The recovery is partial. The Plan 9 model was coherent; the Linux container model is a federation of separately-evolved subsystems with overlapping responsibilities. The composition that worked smoothly in Plan 9 because everything was a file in a uniform namespace works less smoothly in Linux because the underlying primitives are heterogeneous (mount namespaces handle some things, cgroups others, network namespaces others, the various capability bits others still). The user pays an integration tax.

What is recoverable is the structural pattern. A team that wants to build a system out of small, composable services with clean isolation can do so. The tools exist. They are less elegant than what Plan 9 offered. They are vastly more popular and vastly better documented. The trade is a real one and most teams take it; the result is the contemporary cloud-native architecture, which is in important ways a recovery of Plan 9 sensibilities in a Linux environment.

Recoverable: integrated documentation and reflective tooling

The Lisp Machine and Smalltalk practice of having the documentation be queryable structured data, integrated with the running system's code, has been recovered in modern IDE tooling. Language servers (the LSP protocol), tree-sitter parsing, type-system-aware tooling, integrated documentation lookup in editors like VS Code, IntelliJ, and Emacs — all of these are partial recoveries of what the Lisp Machines had natively. The recovery is unevenly distributed (statically-typed languages get more of it than dynamic ones, except for the languages with mature dynamic-introspection tools), but it is broadly available.

What is recoverable for a developer in 2026: a tooling experience in which navigating from a function call to its definition, from a variable to its type, from a type to its documentation, is instant and integrated. This is the part of the Lisp Machine experience that the industry has, by long effort, brought into the mainstream. It is not perfect — the integration is often partial, with several tools collaborating across protocols rather than living in a single environment — but it is much better than it was twenty years ago.

The notebook environments and the moldable-tooling research are pushing this further. A user of Glamorous Toolkit or a sophisticated Jupyter setup can have a working environment in which the data they are looking at carries its own viewer code, where the inspector knows what kind of object it is showing and presents an appropriate UI. This is the part of the Smalltalk and Lisp Machine experience that is most recoverable, because the tooling does not require operating-system-level changes; it requires editor and IDE work, which has been steady.

Partially recoverable: a single integrated environment

Where recovery becomes harder is at the level of full integration. The Lisp Machines and Smalltalk environments offered a single coherent environment in which the language, the runtime, the editor, the debugger, the documentation, the libraries, the UI, and the user's data lived in one image with uniform access. A 2026 developer can recover most of the pieces but cannot recover the integration in the dominant computing context.

The reasons are largely the same as the reasons covered in the OS chapters: the modern computing stack assumes a host operating system providing process isolation, a user shell providing the file-and-process model, a language runtime that runs as a guest in the host OS, and applications that exist as separate processes. The integration that the Lisp Machines and Smalltalks had at the system level cannot be recovered without rebuilding the system level. Pharo recovers it inside its image and pays the cost of being a guest. Emacs recovers it inside its process and pays the cost of being just an editor. Neither is the full thing.

What is partially recoverable: a developer can commit to working inside Pharo, Emacs, or a similar guest environment for a significant fraction of their work, and gain a meaningful portion of the integration benefit. The cost is that they live in the guest environment, with whatever it does and does not provide, and the host environment is the place they go for things the guest does not handle. This is a viable workflow for some kinds of work. It is not a viable workflow for everything.

Partially recoverable: composable graphical computing

Morphic-style direct manipulation of every visible thing, the property that made Squeak and Glamorous Toolkit feel different from conventional GUI toolkits, is partially recoverable. The recovery channels are: working inside Pharo or another Morphic-using environment for whatever fraction of one's work suits; using research tools like Glamorous Toolkit that push direct manipulation further than mainstream GUI frameworks; or — in a different but related direction — using design tools (Figma, the various contemporary creative software) that expose strong direct-manipulation models for specific domains.

What is not recoverable, in the mainstream, is the uniform direct-manipulability of every visible element across all applications. The mainstream UI stacks (Cocoa, Win32, Qt, the web platform, the React ecosystem) all assume that direct manipulation is something each application implements for the affordances it chooses to expose, not something the substrate provides by default. The result is that any given application may be quite manipulable internally and entirely opaque from outside. The PARC vision of a unified direct-manipulation substrate has not transferred and probably will not transfer to the mainstream.

The partial recovery is real for users willing to spend significant fractions of their time inside Pharo or GT. It is not available outside those environments at a comparable depth.

Permanently gone: hardware-supported runtime semantics

The Lisp Machine's hardware support for tagged data, hardware-assisted garbage collection, and microcoded high-level instructions is gone and is not coming back. Modern processors are general-purpose RISC or RISC-derived architectures, with extensions for specific workloads (vector operations, machine-learning acceleration, cryptography) but not for runtime semantics of high-level languages. The market does not support custom processors for niche language workloads. JIT compilation has filled most of the performance gap that hardware support used to bridge.

This loss is real but mostly does not matter in 2026. Modern JIT-compiled dynamic-language runtimes are fast enough that the performance argument for tagged hardware is weak. The Lisp Machine performance advantage was real on 1985 hardware; it would be marginal on 2026 hardware. The recovery is in software techniques (HotSpot, V8, the various other JITs), and the software techniques are good enough that the hardware loss is mostly invisible.

Permanently gone: the trust assumptions that allowed open systems

The ITS culture — open systems, no passwords, no user-to-user protection, mutual trust enforced by social means — is gone and is not coming back. The reasons have nothing to do with Unix winning. They have to do with networks becoming hostile environments, with the rise of organized cybercrime, with the use of computers for purposes (financial transactions, medical records, election infrastructure, military systems) where openness is structurally unsafe.

The Lisp Machines and the early Unix systems both assumed a trusted user base. Unix's security model was a 1970s artifact, but Unix was at least built for a small set of users with separate accounts; ITS was built for a community of trusted peers. Both models are inappropriate to the contemporary computing environment, where the threat model includes adversarial users, network attackers, malicious software, and state-level actors targeting infrastructure.

What this means concretely: a 2026 system designed along the lines of ITS would be unusable within minutes of being put on the public network. Even private deployments could not safely assume the trust model. The systems we have, including Unix, have evolved security mechanisms — capability-based isolation, mandatory access control, sandboxing, the various Linux security modules — that consume substantial design space in every modern OS. That design space is permanently committed. The Lisp Machine practice of letting users modify any part of the running system from inside it cannot be safely reproduced at the system level, only inside per-user sandboxes where the consequences of modification are contained.

This is the deepest permanent loss in this book. The Lisp Machine experience required trust. The world we have does not support it.

Permanently gone: single-vendor hardware-software integration

The Lisp Machines, the Alto, the Multics hardware-software co-design, BeOS's relationship to the BeBox — all of these benefited from a tight relationship between hardware design and operating system design. The hardware could be tailored to what the OS needed; the OS could exploit hardware features that commodity systems did not have.

This integration is gone in the personal-computer space. It survives in narrow niches: Apple's hardware-OS integration in the M-series Macs is the closest contemporary example, and Apple gets real performance and efficiency benefits from it. But Apple is not building a Lisp Machine. The integration is in service of a Unix-derived OS, not in service of an alternative. The economics that supported the Lisp Machines' custom hardware do not exist in 2026 except for very large vertically-integrated players (Apple, Google with its Pixel hardware, the cloud providers with their custom silicon for specific workloads).

What this means: a new operating-system idea cannot count on its own hardware in 2026 unless its sponsor is a hyperscaler or a near-monopoly platform vendor. The hardware is going to be commodity x86 or ARM. The OS has to run on what is there. This is a meaningful constraint on the design space; some of the things the Lisp Machines did cannot be done as well on commodity hardware.

Permanently gone: the patient institutional sponsor

Multics took years to ship and decades to refine. Smalltalk had Xerox PARC's open-ended research budget for ten years. Genera had Symbolics as a single-product company supporting it through the 1980s. Plan 9 had Bell Labs for fifteen years. Each of these systems benefited from an institutional environment in which a small group of designers could work on a long-horizon project without quarterly revenue pressure.

That kind of institutional environment is rare in 2026. The closest contemporary equivalents are the long-horizon research divisions of the largest tech companies (Google's various research efforts, Microsoft Research, Meta's Reality Labs, the open-source foundations supported by the cloud providers), and they are oriented toward different work than operating-system design. There is no contemporary Xerox PARC. There is no contemporary Bell Labs. The closest analog might be the academic operating-systems research community, which produces interesting work but operates on graduate-student timescales and budgets.

What this means: a Multics-scale or Plan-9-scale alternative OS project is, in 2026, very unlikely to find institutional sponsorship. The work that does get funded is incremental work on the existing OS stack, or domain-specific research that does not aim at full-system replacement. The alternative-systems energy that produced Genera and Plan 9 does not have a contemporary home.

Partially recoverable: the cultural conditions

The cultural conditions in which the Lisp Machine and Smalltalk environments thrived — small communities of expert users committed to a particular system, willing to invest months in learning a deep environment, treating system modification as a normal user activity — are partially recoverable. They exist now in the small communities around Pharo, Glamorous Toolkit, Common Lisp, Emacs power-users, and similar enclaves. They do not exist at the scale of mainstream computing, and they are not coming back to that scale.

A person who wants to live in such a community in 2026 can. They have to seek it out. They have to commit to spending their time in environments where most of the world's software does not run. They get, in exchange, much of the working experience that the original Lisp Machine and Smalltalk users had. The community is small. The community exists.

This is, I think, the most encouraging finding in this chapter. The cultural property — being part of a small community of expert users of a deep system — is independent of any specific technology. As long as there is one alternative environment with a working user base and an active maintainer set, that property is available to anyone willing to join. In 2026 there are several such environments. Their continued existence depends on the people who run them, not on industry trends. The communities have survived thirty to forty years of Unix's dominance and they are likely to keep surviving.

What to do with this inventory

A reader who has gotten this far is probably looking for guidance. Here is what I would offer:

If you are a working developer in 2026 and you have never used an image-based environment or a deep Lisp REPL workflow, spend a week with Pharo or with SBCL+SLIME. The investment is small. The mental adjustment is substantial. You will, at the end of the week, understand things about software development that you cannot understand from reading about them. You will also see, more clearly than this book can describe, why the people who use these environments do not give them up.

If you are designing a system in 2026 that has any open-ended exploratory character — a research tool, a long-running internal product, a complex domain-specific application — consider whether the file-based architecture you are about to default to is actually what suits the work. The image-based alternative is available. The file-based alternative is the default; the alternative requires conscious choice.

If you are an educator — formal or informal — preparing students for the contemporary industry, you have an obligation to show them at least one alternative to the dominant model. This does not mean teaching Smalltalk as a course; it means making sure students know the alternative exists and have at least encountered it. A graduate who has never seen anything except Unix-derived systems and web-derived applications is missing knowledge that, at the level of design intuition, they cannot recover later without effort. The alternatives are not large. They are not hard to find. They are easy to omit, and they are systematically being omitted.

If you are designing a system that other people will use, take seriously the question of where the user's data lives, who owns it, and how composable it is with other systems' data. The web's federated-sites model has produced enormous value and enormous costs. Many of the costs come from the model's assumption that each site is sovereign over its own data. Alternative architectures — where data lives with the user rather than with the application, where composition between applications is enabled rather than blocked — are possible, are being built, and are worth knowing about.

If you are responsible for what gets taught in computer science programs, look at whether your operating-systems curriculum still spends time on alternatives to the Unix-derived model. Most do not. Most spend their time on the implementation of Unix-derived kernels, with brief mentions of other systems. The Multics, Lisp Machine, Plan 9, and Smalltalk literatures are accessible. They should be in front of students who are going to spend their careers designing systems.

The honest summary

The honest summary of what was lost when Unix won is this. The pieces are recoverable. The integration is not, except inside guest environments that pay their own integration costs. The cultural conditions in which the original integrations were built are partially recoverable in small communities and not recoverable at the industry scale. The hardware-software integration that some of the alternatives depended on is permanently gone in the consumer space and only available to a few very large platform owners. The trust assumptions that allowed certain kinds of open systems are permanently gone for reasons that have nothing to do with Unix.

What this means for a designer in 2026 is that the design space is wider than the default suggests, but the available choices are constrained in ways that the original alternatives' designers did not face. A new alternative system, if it were to be built, would have to be a Pharo-style guest in a commodity OS, not a Lisp Machine on custom silicon. It would have to assume a hostile network, not a trusted community. It would have to support standard collaboration patterns, not require single-user image-based commitment. It would have to be approachable for incremental adoption, not require months of investment before producing value. These constraints are not what killed the original alternatives, but they are what shapes the design space for any successor.

The closing chapter returns to the thesis. The point of recovering the visibility of these alternatives is not to revive them as they were. The point is to make the design space visible again, so that the next round of decisions — whatever they turn out to be about — is made by people who can see more than one option.

Closing

The foreword stated a thesis. After thirteen chapters of evidence, it is time to come back to it.

Unix won on a particular set of design decisions. Those decisions are so ambient now that we mistake them for the only possible decisions. The cost wasn't the alternatives losing — it was that we stopped being able to see them as alternatives at all. The book's job is to make them visible again.

The thesis has held up, I think, with the qualifications the chapters have added.

The first qualification is that Unix did not win all by itself. The web carried Unix's design choices forward and amplified them. A 2026 user lives inside both layers: the Unix-shaped operating system at the bottom, the Unix-shaped web at the top, each reinforcing the other's assumptions. The thing called Unix in this book is, in practice, a stack of related winning choices that together fill the space where the alternatives might have stood.

The second qualification is that the alternatives lost for understandable reasons. They were not killed by an industry conspiracy. They were not killed by stupidity. They lost contests that they had real disadvantages in, against a system that had real advantages, in the world that actually existed in the late 1970s and 1980s. None of the alternatives in this book deserved to win in any abstract sense; deserving is not a property systems have. They had merits, and the merits did not align with the moment, and they lost.

The third qualification is that much of what was lost is not gone forever. The pieces are recoverable in 2026. The dilutions are real but not always severe. A 2026 developer can have an image-based environment, a live-coding workflow, a condition-system error model, an integrated documentation experience, a moldable tooling substrate, and a direct-manipulation UI, if they are willing to make some choices outside the default. The choices are available. The defaults pull the other way.

What was lost, then, is not primarily the technical capabilities. Most of those have working contemporary forms. What was lost is harder to put precisely, and the book has been circling it for thirteen chapters. It is something like: the ability to imagine that the system could be different. The technical capabilities can be recovered piecewise; the imagination cannot, except by deliberately seeking out the systems where the alternative imagination was practiced.

This is the part the book is really about. The chapter on Multics, the chapters on the Lisp Machines, the chapter on Genera, the chapters on Smalltalk, the chapters on Plan 9 and its descendants, the chapter on Oberon and BeOS — these are not catalog entries. They are existence proofs. Each of them is evidence that a small group of competent people, working with the materials of the time, could choose to build a computer in a different shape. The shapes were real. They worked. People used them and did serious work in them. The shapes are now mostly gone, and the fact that the shapes existed is the thing that has to be preserved when the artifacts cannot be.

A designer who has read this book and remembered any meaningful fraction of what is in it is, after that reading, less likely to mistake the shape they inherited for the only possible shape. That is the entire payoff. Not that they will go build a Lisp Machine. They will not, and would probably make terrible decisions if they tried. The payoff is in the smaller, more common moments where, faced with a design choice, they remember that the choice is a choice. The available design space is larger than the defaults suggest. The defaults suggest a narrow space because the defaults are downstream of a particular history.

The narrowness is not a moral failing of the industry. It is a normal feature of how any field consolidates. Architecture has its own narrow defaults, downstream of postwar building practices and material economics, and the architects who can see beyond them are the ones who studied the alternatives that lost — Bauhaus, brutalism, the Japanese metabolists, Frank Lloyd Wright's Usonian work, the late-19th-century Arts and Crafts movement. Music has its narrow defaults, downstream of a few decades of recording-industry economics, and the composers who can see beyond them have studied the traditions that did not win the mainstream. The pattern in computing is the same. The way to be a better designer in any of these fields is the same: know the road not taken well enough that the road taken is a choice, not a given.

The systems in this book are the most informative roads not taken in computing's first sixty years. There are others — VMS, OS/2, the Mac before X, the various proprietary mainframe operating systems, the early personal computer operating systems that the IBM PC's success extinguished, the various capability-based research operating systems, the many distributed-systems research programs — that this book did not cover and that would each repay similar attention. The point is not that the chapters here are an exhaustive list. The point is that the exercise of looking at alternatives has value beyond the specific items in any one list.

One more thing. The book has been careful to refuse nostalgia and to refuse the easy framing of Unix as the villain. I want to be specific about the second part. Unix's win has been, in the broad sweep, good for the world. The internet runs on Unix. The mobile computers in everyone's pockets run on Unix-derived systems. The applications that have made global communication possible, that have brought decent computing to most of the world's population, that have produced the abundance of small software the contemporary world relies on — these things happened on Unix. The alternatives, if any of them had won instead, would not have given us this. The Lisp Machines could not have scaled to a billion users. Smalltalk environments could not have shipped to consumer phones in 2010. Plan 9 could not have grown the application ecosystem that drives commerce on the contemporary web. Unix won not just because it was lucky but because it was the right shape for the world that was about to arrive.

What was lost was not what should have happened instead. What was lost was the world where multiple shapes coexisted, where serious people building serious systems could choose between coherent alternatives, where the imagination of computing was not narrowed by the success of one particular ancestor. The cost of the success is not the success. The cost is the narrowing.

The book closes here. The work the book is meant to provoke is downstream of it: in the readers who, having looked at what was lost, take some part of it forward in their own designs; in the educators who add the alternatives to their syllabi; in the researchers who pick up an idea from this book and find a new context for it; in the developers who try Pharo for a week and come back differently from how they left. The systems are not coming back. The thinking they made possible is recoverable. That is enough.

What we lost when Unix won was the visibility of other answers. Naming the answers is how you get the visibility back. The names are: Genera. Smalltalk. Plan 9. Multics. Oberon. BeOS. Pharo. Glamorous Toolkit. Inferno. Emacs. Self. Squeak. Cuis. CADR. Lambda. The list is short, the documentation is available, the working systems still exist for the ones that survive. The next round of design choices belongs to people who, having seen the list, can make choices in front of a wider design space than their tools admit. The book is, in the end, an invitation to that wider seeing.

It is the only invitation the book can extend, and it extends it.

Acknowledgments

Thanks to Georgiy Treyvus, who maintains the CloudStreet backlog and kept this title on it long enough for it to be written.

Thanks to the maintainers of the systems still running in 2026 that made the research for this book possible: the Pharo and Glamorous Toolkit teams, the 9front developers, the Haiku project, the maintainers of Squeak and Cuis, the SBCL and Clojure communities, the people who keep Open Genera alive on emulators, and the working programmers who continue to use Common Lisp, Smalltalk, and Plan 9 derivatives as their daily tools. Without their continued work the alternatives would be inaccessible rather than merely uncommon.

Thanks to the historians and primary-source documentarians whose archived talks, papers, oral histories, and uploaded artifacts make it possible to write about systems whose authors are still alive and whose materials are still scattered across personal sites, foundation archives, and the Internet Archive. The chapters that needed primary-source work — particularly the Lisp Machine, Smalltalk, and Plan 9 chapters — were possible only because of the long work of preservation that other people have already done.

Any errors in the book are the author's, including errors of emphasis, omission, and synthesis. Corrections are welcome and will be incorporated.