Cheng Tan

The Dream Is to Disappear

On the ultimate problem of computer systems

· systemsphilosophy ·中文

Many fields in CS have their holy grail problems. For AI, it could be AGI: the ambition is as old as the field’s founding document—the 1956 Dartmouth proposal already conjectured that “every aspect of learning or any other feature of intelligence” could be described precisely enough for a machine to simulate it. For a complexity theorist, the answer is likely P versus NP, the one with a million-dollar bounty on its head. A verification person may point you to Tony Hoare’s grand challenge, the verifying compiler—a compiler that proves the correctness of every program it compiles. Different fields, different dreams. Solve one, and a good fraction of that field would celebrate and happily call it a day.

Now ask a systems researcher. I am one, and I notice the pause. We have famous problems and famous fights, but seemingly no widely agreed final dream. I think it has one, and I think it is stranger than everybody else’s. The dream of computer systems is to disappear.

A world with no systems

To see why, start from a thought experiment that sounds absurd: delete the systems. Nothing in computability requires an operating system, a database, or a network stack. Any task could be one standalone binary that talks straight to the hardware—fuse everything into one big piece and run it. This is not even hypothetical. It is how computing worked in the early 1950s.

The experiment fails, and it is worth being precise about how. It does not fail logically. It fails economically. In that world, every program that wants persistent storage reimplements a file system; every program that wants to do two things at once reimplements scheduling; everyone pays full price for the same work, over and over. The first thing we would now recognize as an operating system—GM-NAA I/O, built in 1956 for the IBM 704—existed precisely to stop the bleeding: batch the jobs, share the I/O routines, and throughput rose roughly tenfold. Systems was not founded on a theorem. It was founded on a refusal to pay for the same work twice.

So the field’s job description, first draft: find the parts everyone keeps rebuilding, build them once, and build them well.

A system is a promise, not a library

“Build it once” is misleading, though, because a mere library already does that. The difference is important. A library hands you code; when the world misbehaves, the details are still your problem. A system hands you a promise—and takes on the obligation to keep it while the world misbehaves. A file system does not just offer read and write routines; it promises your bytes will still be there after the crash. Virtual memory promises every program a machine of its own. A transaction promises all-or-nothing in the middle of concurrency and failure. The hard part of the artifact is exactly the part the user never sees: keeping the promise through crashes, races, and malice.

The proper name for such a promise is an abstraction: the functionality kept, the details hidden. And a good abstraction is not a comfortable blur. Dijkstra, in his Turing lecture: “the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.” Files, addresses, processes, packets, transactions—each one is a new semantic level, exact enough to build the next level on top of.

Abstraction is how minds work anyway

If this were only an engineering convenience, the story would end here. It goes deeper: abstraction is not a trick we invented for computers; it is the native move of understanding. Psychology has known this since Miller’s “The Magical Number Seven” (miscited by almost everyone, me included): the mind’s working capacity is small and fixed, so we cope by recoding—folding many details into one chunk and carrying the chunk. Nobody remembers driving muscle by muscle; you remember how to drive, one handle standing in for a thousand details. Your mind does not keep the raw tape of experience. It builds interfaces to itself.

Civilization advances, as Whitehead put it, “by extending the number of important operations which we can perform without thinking about them”— and systems do the same. Every abstraction we ship is one more important operation that the rest of computing—and eventually the rest of civilization—performs without thinking.

Computing that disappears

Now circle back to the holy grail problem of computer systems. Each good abstraction takes something people had to think about and makes it something they don’t. What sits at the top, when everything has been abstracted away?

One widely shared version of the dream, dating to the 1960s, is to make computing a utility like the telephone or running water: everywhere, and easy to get. Sixty years later, that dream is half true. We call it the cloud: computation out of a socket, pay for what you draw.

Half true—because the utility still shows through. It fails, it leaks, it must be provisioned, patched, and watched by armies of operators carrying pagers: someone is still being paged at 3 a.m. to worry about the system so that you don’t have to. That someone marks the unfinished half. Being everywhere turned out to be the easy part; needing no one is the hard part. So state the dream in full: computation as an unbounded utility—correct, secure, always on, managing itself, administered by no one—that no human ever has to think about. Computing that disappears.

The field that dreams of vanishing

Put our dream next to the others and the strangeness stands out. AGI is a monument. A proof of P versus NP is a monument—a thing that stands there afterward with its builders’ names carved in. The systems dream is an anti-monument: achieved in full, it leaves nothing to look at. Other fields dream of being remembered for solving their problem. Ours, solved perfectly, is forgotten.

And it will never be finished—by construction. There is a quip Butler Lampson attributed to David Wheeler: any problem in computer science can be solved with another level of indirection. Wheeler’s less-quoted completion: but that usually creates another problem. Every layer that vanishes becomes the floor of a new layer that hasn’t vanished yet. The physical machine disappeared into the virtual machine; the virtual machine disappeared into the cloud; the cloud is currently busy disappearing into something agents manage. The machine vanishes, and reappears one level up. The dream recedes exactly as fast as we approach it—which is not a flaw in the dream. It is the mechanism by which the field stays alive.

So systems has no million-dollar problem, and it never will. Its dream is asymptotic in the large and achieved daily in the small: somewhere just now, your program wrote a file, and you did not think about it once. Other sciences dream of a monument with their names on it. Ours ends in silence—the highest honor a system can earn is being taken entirely for granted.

References