Plan 9 from Bell Labs

Plan 9 from Bell Labs was originally developed, starting in the late 1980s, 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. 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. Geoff Collyer, a Plan 9 maintainer, published his Plan 9 work on his personal homepage, which include the 64-bit 9k kernel and a RISC-V port. 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. == 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. 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". Special virtual filesystem /proc in Instead of having system calls specifically for process management, Plan 9 provides the file system. Each process appears as a directory containing information and control files which can be manipulated by the ordinary file IO system calls. The file system approach allows Plan 9 processes to be managed with simple file management tools such as ls and cat; however, the processes cannot be copied and moved as files. /net Plan 9 does not have specialised system calls or ioctls for accessing the networking stack or networking hardware. Instead, the file system is used. Network connections are controlled by reading and writing control messages to control files. Sub-directories such as and are used as an interface to their respective protocols. Unicode To reduce the complexity of managing character encodings, Plan 9 uses Unicode throughout the system. The initial Unicode implementation was ISO/IEC 10646-1:1993. Ken Thompson invented UTF-8, which became the native encoding in Plan 9. The entire system was converted to general use in 1992. UTF-8 preserves backwards compatibility with traditional null-terminated strings, enabling more reliable information processing and the chaining of multilingual string data with Unix pipes between multiple processes. Using a single UTF-8 encoding with characters for all cultures and regions eliminates the need for switching between code sets. Combining the design concepts Though interesting on their own, the design concepts of Plan 9 were supposed to be most useful when combined. For example, to implement a network address translation (NAT) server, a union directory can be created, overlaying the router's directory tree with its own . Similarly, a virtual private network (VPN) can be implemented by overlaying in a union directory a hierarchy from a remote gateway, using secured 9P over the public Internet. A union directory with the hierarchy and filters can be used to sandbox an untrusted application or to implement a firewall. In the same manner, a distributed computing network can be composed with a union directory of hierarchies from remote hosts, which allows interacting with them as if they are local. When used together, these features allow for assembling a complex distributed computing environment by reusing the existing hierarchical name system. == Software for Plan 9 ==

As a benefit from the system's design, most tasks in Plan 9 can be accomplished by using ls, cat, grep, cp and rm utilities in combination with the rc shell (the default Plan 9 shell). Factotum is an authentication and key management server for Plan 9. It handles authentication on behalf of other programs such that both secret keys and implementation details need only be known to Factotum. Unix compatibility Though Plan 9 was supposed to be a further development of Unix concepts, compatibility with preexisting Unix software was never the goal for the project. Many command-line utilities of Plan 9 share the names of Unix counterparts, but work differently. Plan 9 can support POSIX applications and can emulate the Berkeley socket interface through the ANSI/POSIX Environment (APE) that implements an interface close to ANSI C and POSIX, with some common extensions (the native Plan 9 C interfaces conform to neither standard). It also includes a POSIX-compatible shell. APE's authors claim to have used it to port the X Window System (X11) to Plan 9, although they do not ship X11 "because supporting it properly is too big a job". Some Linux binaries can be used with the help of a "linuxemu" (Linux emulator) application; however, it is still a work in progress. Vice versa, the Vx32 virtual machine allows a slightly modified Plan 9 kernel to run as a user process in Linux, supporting unmodified Plan 9 programs. == Reception ==

Comparison to contemporary operating systems In 1991, Plan 9's designers compared their system to other early nineties operating systems in terms of size, showing that the source code for a minimal ("working, albeit not very useful") version was less than one-fifth the size of a Mach microkernel without any device drivers (5899 or 4622 lines of code for Plan 9, depending on metric, vs. 25530 lines). The complete kernel comprised 18000 lines of code. (According to a 2006 count, the kernel was then some 150,000 lines, but this was compared against more than 4.8 million in Linux.) Within the operating systems research community, as well as the commercial Unix world, other attempts at achieving distributed computing and remote filesystem access were made concurrently with the Plan 9 design effort. These included the Network File System and the associated vnode architecture developed at Sun Microsystems, and more radical departures from the Unix model such as the Sprite OS from UC Berkeley. Sprite developer Brent Welch points out that the SunOS vnode architecture is limited compared to Plan 9's capabilities in that it does not support remote device access and remote inter-process communication cleanly, even though it could have, had the preexisting UNIX domain sockets (which "can essentially be used to name user-level servers") been integrated with the vnode architecture. One critique of the "everything is a file", communication-by-textual-message design of Plan 9 pointed out limitations of this paradigm compared to the typed interfaces of Sun's object-oriented operating system, Spring: A later retrospective comparison of Plan 9, Sprite and a third contemporary distributed research operating system, Amoeba, found that Impact X window manager was inspired by acme, a text editor from the Plan 9 project. Derivatives and forks • Inferno is a descendant of Plan 9, and shares many design concepts and even source code in the kernel, particularly around devices and the Styx/9P2000 protocol. Inferno shares with Plan 9 the Unix heritage from Bell Labs and the Unix philosophy. Many of the command line tools in Inferno were Plan 9 tools that were translated to Limbo. • 9atom augments the Plan 9 distribution with the addition of a 386 PAE kernel, an amd64 cpu and terminal kernel, nupas, extra pc hardware support, IL and Ken's fs. Its home page hasn't been updated since 2013, and very little is known about its development or community. • 9front is a fork of Plan 9. It was started to remedy a perceived lack of devoted development resources inside Bell Labs, and has accumulated various fixes and improvements. • 9legacy is an alternative distribution. It includes a set of patches based on the current Plan 9 distribution. • Akaros is designed for many-core architectures and large-scale SMP systems. • Harvey OS (discontinued) is an effort to get the Plan 9 code working with gcc and clang. • JehanneOS is an experimental OS derived from Plan 9. Its userland and modules are mostly derived from 9front, its build system from Harvey OS, and its kernel is a fork of the 9k 64-bit Plan9 kernel. • NIX is a fork of Plan9 aimed at multicore systems and cloud computing. • node9 is a scripted derivative of Plan9/Inferno that replaces the Limbo programming language and DIS virtual machine with the Lua language and LuaJit virtual machine. It also replaces the Inferno per-platform hosted I/O with Node.js' libuv eventing and I/O for consistent, cross-platform hosting. It's a proof-of-concept that demonstrates that a distributed OS can be constructed from per-process namespaces and generic cloud elements to construct a single-system-image of arbitrary size. • Plan B designed to work in distributed environments where the set of available resources is different at different points in time. Originally based on the third edition Plan 9 kernel, Plan B was moved into user space to run on current Plan 9 systems. • R9 is a reimplementation of the Plan 9 kernel on Rust (although there is no port of the Rust programming language compiler to Plan 9). == License ==

Starting with the release of Fourth edition in April 2002, and all previous releases have been relicensed to the MIT License. == See also ==