Zum Inhalt springen

The Multics Story

Zusammenfassung

Multics — Multiplexed Information and Computing Service — was the most ambitious operating system ever attempted. Begun in 1964 as a joint project of MIT, Bell Labs, and General Electric, it introduced dynamic linking, hierarchical file systems, ring-based security, shared memory segments, and online reconfiguration of a running system. Nearly every feature of every modern operating system was invented or refined in Multics. The system also arrived years late, ran only on prohibitively expensive hardware, and was so complex that the Bell Labs researchers who worked on it abandoned it to write a simpler alternative — which they called Unix. Multics is the operating system the industry built the future on without ever using it.

Project MAC and the Time-Sharing Vision

The story begins at MIT in the early 1960s, where Fernando Corbató led Project MAC — Mathematics and Computation, or Multiple Access Computers, depending on who was telling the story. Corbató had already demonstrated CTSS (Compatible Time-Sharing System) on an IBM 7094, showing that multiple users could share a single computer interactively. CTSS was a proof of concept. What Corbató wanted to build next was an “information utility” — a computer system that users could connect to like electricity from a wall socket, continuous and reliable, always available.

The vision, articulated in a 1965 paper by Corbató and Vyssotsky, was radical: a computing system that would run continuously without scheduled downtime, support hundreds of simultaneous users, protect each user’s data from every other user’s access, and allow the system itself to be extended while running. This was not a program. It was a new relationship between humans and computers.

MIT partnered with General Electric to build the hardware (the GE-645, a modified 36-bit mainframe with hardware support for the memory segmentation and protection rings Multics required) and with Bell Labs to provide software engineering expertise. The project was called Multics.

The Architecture That Invented the Future

Multics introduced or first implemented at scale a remarkable set of ideas that became standard in all subsequent systems:

Hierarchical file system: Multics organized files in a tree of directories, where each directory could contain files or other directories. This seems obvious today because every operating system since has used it. Before Multics, file systems were flat or had at most two levels.

Dynamic linking: Programs in Multics did not need to include copies of the libraries they called. Instead, they referenced library procedures by name; the system linked them at runtime. This enabled shared code, smaller executables, and library updates that took effect without recompiling anything that used them.

Ring-based security: Multics organized privilege into eight concentric rings, numbered 0 (most privileged) to 7 (least privileged). Code running in a ring could call code in a more privileged ring only through carefully defined gates. The kernel occupied ring 0. User processes ran in outer rings. Hardware enforced the boundaries. Modern operating systems reduced the eight rings to two (kernel and user mode), but the concept was Multics.

Memory segmentation: Rather than treating memory as a flat array of bytes, Multics gave each procedure and data structure its own named segment, with independently specified access permissions. A procedure segment was read-execute only. A data segment could be read-write. Sharing a data structure between processes meant sharing the segment — not copying it.

Online reconfiguration: A Multics system could add CPU boards, memory boards, and disk drives while running, without rebooting. This was considered nearly impossible in 1965. It remains remarkable today.

Single-level store: Multics unified main memory and disk into a single address space. A segment was “in memory” when actively used and automatically paged to disk when not. The programmer saw only segments; the hardware and operating system managed the physical location transparently. This model influenced virtual memory in every subsequent system.

The Complexity Trap

The architecture was coherent and visionary. The implementation was a disaster.

The specification document, known as the Multics System Programmer’s Manual, grew to tens of thousands of pages. The software was written in PL/I, a language chosen because it had the features Multics needed — but which GE’s compiler implemented slowly and incorrectly. The first running version of Multics, in 1969, was years behind schedule and orders of magnitude slower than projections.

The GE-645 hardware required to run Multics cost roughly $7 million in 1970 dollars. MIT’s installation was subsidized; commercial customers were rare. When GE’s computer division was sold to Honeywell in 1970, the new owners supported Multics for two decades — but it never became a mainstream system.

Fred Brooks, visiting MIT during the Multics development, described the experience in The Mythical Man-Month: the project illustrated the principle that software systems grow beyond their specifications as implementation reveals the complexity hidden in seemingly simple requirements. Multics was designed to be everything. The attempt to implement everything delayed it past the window when it might have mattered.

Bell Labs Leaves — and Writes Unix

Ken Thompson and Dennis Ritchie were among the Bell Labs researchers assigned to Multics. Thompson found Multics stimulating but unwieldy; he had been using it to develop a game called Space Travel and appreciated the interactive environment. When Bell Labs withdrew from the Multics project in 1969, citing cost and complexity, Thompson found himself without a comfortable computing environment.

On a spare PDP-7 minicomputer, Thompson wrote a simple operating system that borrowed Multics’s hierarchical file system and process model but discarded nearly everything else. The new system had no dynamic linking, no memory segments, no rings of protection — just files, processes, and pipes. Ritchie joined to write a new language, C, to replace the assembly code. They called the new system Unix, a name that was partly a pun on Multics and partly an admission that it did far less.

Unix was not designed. It was carved from Multics by removing everything complex enough to cause trouble. The relationship is not ironic but generative: Multics created a generation of systems programmers who understood, viscerally, why complexity was dangerous. Unix was their correction.

Thompson later said of Multics: “It was overdesigned and overbuilt and over everything. It was a failure in its time.” That failure taught more than most successes.

The Legacy

Multics ran commercially at dozens of sites through the 1980s. Honeywell marketed it as a secure multi-user system, and it earned a security rating (B2, the highest achieved by a commercial OS at the time) from the US Department of Defense. The last commercial Multics system was shut down in 2000 at the Canadian Department of National Defence.

The ideas did not die with the system. Every hierarchical file system descends from Multics. Every protected-mode operating system with kernel and user space inherits the ring architecture. Linux’s capability system is a modern reconstruction of fine-grained privilege that Multics designed in 1967. Shared libraries implement the dynamic linking Multics defined. Virtual memory implements the single-level store that Multics described.

When Linus Torvalds wrote Linux, he was writing a Unix clone — which was itself carved from Multics. The operating system the world runs on is Multics’s grandchild, simplified twice to become usable.

📚 Sources