Plan 9, and the ideas that escaped it

late 1980s onwardsWhat it set out to do

Built by the group that had built the previous system, and intended to take one of its principles seriously rather than approximately.

The principle is that everything is a file. In the earlier system that was true of devices and roughly true of a few other things. Here it was made true of essentially all resources, including network connections, windows, processes and the interfaces of remote machines, each presented as a small tree of files served by a program.

The protocol underneath

One protocol carried every operation on those files, and it was indifferent to whether the server was a local program or a machine on the other side of a network.

That single decision removes most of the distinction between local and remote. A program that works with files works with anything, anywhere, without knowing which, and without a separate library for each kind of resource.

Namespaces per process

The second idea is the one with the largest inheritance. Each process had its own view of the file tree, assembled from pieces, rather than sharing one global arrangement with everything else on the machine.

A process could therefore be given exactly the resources it should see and no others, and two processes on one machine could disagree entirely about what a given path meant. Both properties are now ordinary and neither was then.

1990s and 2000sWhy it did not spread

It could not run the software people already had. A system that improves on its predecessor by being consistent, rather than by being compatible, asks every user to abandon their existing work.

It also arrived when the predecessor was entrenched, free implementations of that predecessor were spreading rapidly, and no commercial force was pushing the newer system. The comparison was never between the two designs; it was between one design and an entire ecosystem.

1992The idea that escaped completely

The variable-length encoding for text that the world now uses almost universally was designed for this system, by two of its authors, and it won everywhere while the system that produced it did not.

Its properties are the reason: existing seven-bit text remains valid unchanged, no byte of a multi-byte character can be mistaken for a single-byte one, and software that searches for a plain character cannot produce a false match. Those are compatibility properties, which is precisely what the system itself lacked.

2000s onwardsThe ideas that escaped afterwards

Per-process namespaces arrived in the dominant free operating system and became the mechanism underneath containers. Layered file systems, where one tree is stacked over another, became the mechanism underneath container images. The file protocol is used to pass file systems into virtual machines.

So an entire industry of packaging and isolation runs on ideas from a system that almost nobody used, arriving one at a time, decades later, in a system they were designed as an alternative to.

What that pattern says

Ideas travel better than systems. A design that must be adopted whole competes against everything a person already has; a design that can be lifted out and reimplemented competes against nothing.

Which suggests that the useful question about an unsuccessful system is not why it failed but which parts of it are separable, because those are the parts that will turn up somewhere else.

The window system as a file server

The clearest demonstration of the principle, and worth stating because it sounds implausible. The graphical interface was a file server: a program drew by writing to files and read input by reading from them, and the same operations worked unchanged whether the display was attached to the machine or somewhere else entirely.

Remote graphical work therefore needed no separate protocol and no separate library. It was the ordinary mechanism, pointed at a different server.

Why consistency is hard to sell

The benefit of a consistent design is diffuse and arrives later: fewer concepts to learn, fewer special cases, tools that compose without adapters. The cost is immediate and specific: nothing you already have works.

That asymmetry appears in every entry in this part, and it is the reason the section exists. Losing designs are rarely wrong. They are usually correct in a way that requires everybody to move at once.

What it says about reading old systems

The practical reason to read a system nobody uses is that its ideas are still in transit. Two of the four described here arrived in mainstream use twenty years after publication, and arrived without credit because they were reimplemented rather than adopted.

Which suggests the papers are a reasonable place to look for what will be ordinary in another decade, and a better one than most current writing, because the ideas have already survived the criticism of the people who built them.

present dayWhat has not been taken

The consistency. Containers give a process its own namespace and then fill it with the same inconsistent collection of interfaces the original system had: some things are files, some are special calls, some are sockets with their own protocols, and which is which is history rather than design.

The borrowed mechanism arrived without the principle it was built to serve, which is the usual fate of a separable idea and the reason the original is still worth reading.

What we cannot verify

The system, its papers and its source are published and can be run today. The lines of influence into later systems are documented in some cases and asserted in others; where an implementer has stated the influence directly it is firm, and where it is inferred from similarity it is not. We have not attempted to settle contested claims of priority.