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-like operating systems is replaced by a windowing system and graphical user interface without cursor addressing, although rc, the Plan 9 shell, is text-based.

[20] 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.

[22] It explored several changes to the original Unix model that facilitate the use and programming of the system, notably in distributed multi-user environments.

[23] 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.

[24] 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.

[25] A user and development community, including current and former Bell Labs personnel, produced minor daily releases in the form of ISO images.

[28] 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.

[29] As Bell Labs has moved on to later projects in recent years, development of the official Plan 9 system had stopped.

[10][30][31] Unofficial development for the system also continues on the 9front fork, where active contributors provide monthly builds and new functionality.

[35] Plan 9 from Bell Labs is like the Quakers: distinguished by its stress on the 'Inner Light,' noted for simplicity of life, in particular for plainness of speech.

[38] 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.

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.

The command exports part of its local namespace, including the user's terminal's devices (mouse, cons, bitblt), 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.

Plan 9 allows the user to collect the files (called names) from different directory trees in a single location.

[47][39] 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.

Similarly, a virtual private network (VPN) can be implemented by overlaying in a union directory a /net hierarchy from a remote gateway, using secured 9P over the public Internet.

[43] In the same manner, a distributed computing network can be composed with a union directory of /proc 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.

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".

[60] 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).

[43]) 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.

In most cases the real interface type comprises the protocol of messages that must be written to, and read from, a file descriptor.

Instead, communication has to rely on conventions, which are prone to error and do not scale.A later retrospective comparison of Plan 9, Sprite and a third contemporary distributed research operating system, Amoeba, found that the environments they [Amoeba and Sprite] build are tightly coupled within the OS, making communication with external services difficult.

Such systems suffer from the radical departure from the UNIX model, which also discourages portability of already existing software to the platform (...).

In retrospect, Plan 9 was the only research distributed OS from that time which managed to attract developers and be used in commercial projects long enough to warrant its survival to this day.Plan 9 demonstrated that an integral concept of Unix—that every system interface could be represented as a set of files—could be successfully implemented in a modern distributed system.

Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position.