Plan 9 from Bell Labs
Plan 9 from Bell Labs is an operating system designed by the Computing Science Research Center at Bell Labs in the mid-1980s, built on the UNIX concepts first developed there in the late 1960s. Since 2000, Plan 9 has been free and open-source. The final official release was in early 2015.
Under Plan 9, UNIX's everything is a file metaphor is extended via a pervasive network-centric filesystem, and the cursor-addressed, terminal-based I/O at the heart of UNIX is replaced by a windowing system and graphical user interface without cursor addressing. Plan 9 also introduced capability-based security and a log-structured file system called Fossil that provides snapshotting and versioned file histories.
The name Plan 9 from Bell Labs is a reference to the Ed Wood 1957 cult science fiction Z-movie Plan 9 from Outer Space. The system continues to be used and developed by operating system researchers and hobbyists.
History
Plan 9 from Bell Labs was originally developed, starting in the late 1980s, by members of the Computing Science Research Center at Bell Labs, the same group that originally developed Unix and the C programming language. The Plan 9 team was initially led by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with support from Dennis Ritchie as head of the Computing Techniques Research Department. Over the years, many notable developers have contributed to the project, including Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup and Bruce Ellis.Plan 9 replaced Unix as Bell Labs's primary platform for operating systems research. It explored several changes to the original Unix model that facilitate the use and programming of the system, notably in distributed multi-user environments. After several years of development and internal use, Bell Labs shipped the operating system to universities in 1992. Three years later, Plan 9 was made available for commercial parties by AT&T via the book publisher Harcourt Brace. With source licenses costing $350, AT&T targeted the embedded systems market rather than the computer market at large. Ritchie commented that the developers did not expect to do "much displacement" given how established other operating systems had become.
By early 1996, the Plan 9 project had been "put on the back burner" by AT&T in favor of Inferno, intended to be a rival to Sun Microsystems' Java platform.
In the late 1990s, Bell Labs' new owner Lucent Technologies dropped commercial support for the project and in 2000, a third release was distributed under an open-source license. A fourth release under a new free software license occurred in 2002. In early 2015, the final official release of Plan 9 occurred.
A user and development community, including current and former Bell Labs personnel, produced minor daily releases in the form of ISO images. Bell Labs hosted the development. The development source tree is accessible over the 9P and HTTP protocols and is used to update existing installations. In addition to the official components of the OS included in the ISOs, Bell Labs also hosts a repository of externally developed applications and tools.
As Bell Labs has moved on to later projects in recent years, development of the official Plan 9 system had stopped. On March 23, 2021, development resumed following the transfer of copyright from Bell Labs to the Plan 9 Foundation. Unofficial development for the system also continues on the 9front fork, where active contributors provide monthly builds and new functionality. So far, the 9front fork has provided the system Wi-Fi drivers, audio drivers, USB support and built-in game emulator, along with other features. Other recent Plan 9-inspired operating systems include Harvey OS and Jehanne OS.
| Date | Release | Comment |
| 1992 | Plan 9 1st edition | Released by Bell Labs to universities |
| 1995 | Plan 9 2nd edition | Released by Bell Labs for non-commercial purposes |
| 2000 | Plan 9 3rd ed. | Released by Lucent Technologies under an open source license |
| 2002 | Plan 9 4th edition | Released by Lucent Technologies under a new free software license |
Design concepts
Plan 9 is a distributed operating system, designed to make a network of heterogeneous and geographically separated computers function as a single system. In a typical Plan 9 installation, users work at terminals running the window system rio, and they access CPU servers which handle computation-intensive processes. Permanent data storage is provided by additional network hosts acting as file servers and archival storage.Its designers state that,
The first idea means that, unlike on most operating systems, processes each have their own view of the namespace, corresponding to what other operating systems call the file system; a single path name may refer to different resources for different processes. The potential complexity of this setup is controlled by a set of conventional locations for common resources.
The second idea means that processes can offer their services to other processes by providing virtual files that appear in the other processes' namespace. The client process's input/output on such a file becomes inter-process communication between the two processes. This way, Plan 9 generalizes the Unix notion of the filesystem as the central point of access to computing resources. It carries over Unix's idea of device files to provide access to peripheral devices and the possibility to mount filesystems residing on physically distinct filesystems into a hierarchical namespace, but adds the possibility to mount a connection to a server program that speaks a standardized protocol and treat its services as part of the namespace.
For example, the original window system, called 8½, exploited these possibilities as follows. Plan 9 represents the user interface on a terminal by means of three pseudo-files:, which can be read by a program to get notification of mouse movements and button clicks;, which can be used to perform textual input/output; and, writing to which enacts graphics operations. The window system multiplexes these devices: when creating a new window to run some program in, it first sets up a new namespace in which, and are connected to itself, hiding the actual device files to which it itself has access. The window system thus receives all input and output commands from the program and handles these appropriately, by sending output to the actual screen device and giving the currently focused program the keyboard and mouse input. The program does not need to know if it is communicating directly with the operating system's device drivers, or with the window system; it only has to assume that its namespace is set up so that these special files provide the kind of input and accept the kind of messages that it expects.
Plan 9's distributed operation relies on the per-process namespaces as well, allowing client and server processes to communicate across machines in the way just outlined. For example, the command starts a remote session on a computation server. The command exports part of its local namespace, including the user's terminal's devices, to the server, so that remote programs can perform input/output using the terminal's mouse, keyboard and display, combining the effects of remote login and a shared network filesystem.
9P protocol
All programs that wish to provide services-as-files to other programs speak a unified protocol, called 9P. Compared to other systems, this reduces the number of custom programming interfaces. 9P is a generic, medium-agnostic, byte-oriented protocol that provides for messages delivered between a server and a client. The protocol is used to refer to and communicate with processes, programs, and data, including both the user interface and the network. With the release of the 4th edition, it was modified and renamed 9P2000.Unlike most other operating systems, Plan 9 does not provide special application programming interfaces to access devices. Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write. Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.
Union directories and namespaces
Plan 9 allows the user to collect the files from different directory trees in a single location. The resulting union directory behaves as the concatenation of the underlying directories ; if the constituent directories contain files having the same name, a listing of the union directory will simply report duplicate names. Resolution of a single path name is performed top-down: if the directories and are unioned into with first, then denotes if it exists, only if it exists and does not exist, and no file if neither exists. No recursive unioning of subdirectories is performed, so if exists, the files in are not accessible through the union.A union directory can be created by using a sequence of commands:
bind /arm/bin /bin
bind -a /acme/bin/arm /bin
bind -b /usr/alice/bin /bin
In the example above, is mounted at, the contents of replacing the previous contents of. Acme's directory is then union mounted after, and Alice's personal directory is union mounted before. When a file is requested from, it is first looked for in, then in, and then finally in.
The separate process namespaces thus usually replace the notion of a search path in the shell. A path environment variable still exists in the rc shell ; however, rc's path environment variable conventionally only contains the and directories and modifying the variable is discouraged, instead, adding additional commands should be done by binding several directories together as a single. Unlike in Plan 9, the path environment variable of Unix shells should be set to include the additional directories whose executable files need to be added as commands.
Furthermore, the kernel can keep separate mount tables for each process, and can thus provide each process with its own file system namespace. Processes' namespaces can be constructed independently, and the user may work simultaneously with programs that have heterogeneous namespaces. Namespaces may be used to create an isolated environment similar to chroot, but in a more secure way.
Plan 9's union directory architecture inspired 4.4BSD and Linux union file system implementations, although the developers of the BSD union mounting facility found the non-recursive merging of directories in Plan 9 "too restrictive for general purpose use".