History of Plan 9

Since the development of UNIX, the programmers of Bell Labs have not been idle. Their next brainchild was the distributed operating system Plan 9.

Background

By the mid-80s, there was a tendency to move away from large centralized computers operating in time-sharing mode to networks on top of small personal machines [usually UNIX workstations]. Users were eager to switch to small systems that they could support themselves despite the loss in computing power. Microcomputers became faster and cheaper, and these losses were compensated. This style of computing remains quite popular today.

When migrating UNIX to personal workstations, however, some of the existing shortcomings and problems were not taken into account. The UNIX operating system was old, monolithic, and operated in time-sharing mode. The possibilities of adapting it to new technologies that appeared later were very limited. Graphics and networking capabilities were added to UNIX back in its heyday and were poorly integrated architecturally and, as a result, difficult to manage.

And most importantly, the early focus on personal machines made it impossible for the trouble-free operation of networks typical of old monolithic time-sharing systems. Time-sharing and management centralization made it possible to amortize costs for large machines. But with the advent of personal computing, the problems of administration have escalated to the limit. Choosing an old time-sharing operating system to run on these personal machines would be unjustified.

Beginning

It was decided to create an OS more adapted to the challenges of the time. Plan 9 originated in the late 1980s as a new system designed to solve UNIX problems that the developers considered “too deep to fix”. At the same time, two goals were pursued:

• the system, built from cheap modern microcomputers, had to be centrally controlled;
• and at the same time be inexpensive.

The idea was to use more than just workstations when building a computing system. Computers should fit their role: small, cheap machines in offices could serve as terminals, providing access to large, central, shared resources such as computing and file servers. Recent multiprocessor systems appeared to be obvious candidates for the role of central machines.

The project was taken over by a specialized division of Bell Labs, known as “Computer Science Research Center” (CSRC). In fact, the development was led by the same team that originally worked on UNIX and the C programming language: Ken Thompson, Dennis Ritchie, Rob Pike, Dave Presotto and Phil Winterbottom. And it was decided to leave the concept the same, developing it as much as possible.

The name of the OS was inspired by the trash horror film “Plan 9 from Outer Space” directed by Edward Wood. Mascot of OS - hare Glenda - was named after the film “Glen or Glenda” by the same director. The same name was given to the default user in Plan 9.

By 1989, the system had become so stable that it was used as the only computing environment in the laboratory. This meant the need to migrate many services and applications that were previously used in UNIX. The researchers used this opportunity to review a lot of things in the OS architecture. Plan 9 had new compilers, languages, libraries, window systems and a variety of new applications. Many of the old utilities have been omitted, and those that have been left behind have been re-written or debugged.

Why was it necessary to review everything to the ground? The differences between the operating system, library, and application are important to operating system researchers, but uninteresting to users. For them, only functionality matters. By creating a completely new system, they were able to solve many problems that needed to be solved. For example, there is no tty driver in the kernel. It is the result of the operation of the window system in the user space. In the modern world, computing systems, by necessity, are multiarchitectural and made up of products from different suppliers. However, conventional compilers and utilities assume that the program must be built to run in a local environment. More importantly, however, the operating environment it provides serves as a certain test for the system. Ensuring greater efficiency when running old programs - the “workhorses” of UNIX - was only a matter of technique. The researchers were much more interested in the fact that the new ideas proposed by the architecture of the new system would contribute to improving work efficiency. Thus, although Plan 9 provides an emulation environment for executing POSIX commands, this is not the main thing in the system. Most of the system software is developed in the native Plan 9 environment.

The completely updated system had certain advantages. The laboratory had experience in developing controllers for experimental peripheral devices. In order to make it easier to write their drivers, they wanted to have a system that would be available as source code [which UNIX could no longer guarantee, even in the laboratory where it was born]. In addition, they wanted to redistribute the work. The software should have been created in a decentralized manner [let me remind you, git and etc. haven’t even thought about it yet, let alone CI/CD]. For example, they could use C compilers from some vendors for the system. But even if they had overcome the problems with cross-compilation, they would have had difficulty redistributing the result of this work.

Result

The basic concept of Plan 9 is that it is a distributed operating system, unlike UNIX. Network functionality is extended by mechanisms such as remote login and a network file system in it. In Plan 9 network support is built into the OS functionality. For example, all resources, theoretically, can be transparently distributed in the Plan 9 network. The system hides from the user that the resources are not local. Plan 9 supports not only file servers, but also authorization and computing servers, and this list can be expanded¹².

The system was built on three principles:

• Firstly, resources are named and can be accessed as files in a hierarchical file system;
• Secondly, there is a standard protocol called 9P for accessing these resources;
• Finally, the unrelated hierarchies provided by the various services are joined together into a single personal hierarchical file namespace.

The unusual properties of Plan 9 are due to the purposeful consistent application of these principles.

Plan 9 is based on the UNIX paradigm that “everything is a file”. Relying on a huge collection of add-ons, UNIX absorbed more and more changes that went against this original, fundamental principle. An example of this is the terrible socket mechanism used for the functions of reading and writing network resources, different than regular files. Plan 9 puts an end to this by providing a file-oriented system interface. For example, /net/tcp and /net/udp for network interfaces. Most system services also follow the server principle. In Plan 9, for example, there is no regular ftp program. Instead, ftpfs mounts the FTP server to the /n/ftp directory. The 9660fs server is responsible for mounting CD’s.

Although Plan 9 was originally intended to work with traditional files, its ideas have been extended to many other resources. File hierarchy export services include I/O devices, backups, window system, network interfaces, and more. The file system model is well understood by both system developers and ordinary users, so that services with file-like interfaces are easy to build, understand and use. The files come with familiar, unified rules for protection, naming, and access (both local and remote). Therefore, services built in this way are ready for use in distributed systems. This is the difference from object-oriented models, where these aspects have to be dealt with anew for each class of objects. The following articles will provide examples illustrating these ideas in practice.

One example would be the /proc file system command, which provides a clear way to explore and manage current processes. Plan 9 was the first OS to support the file-oriented process management system proc. Precursor systems are based on a similar idea³, but in Plan 9 the metaphor of files is developed much further⁴. Later, /proc was integrated into GNU/Linux.

In Plan 9, the main network functionality is provided by the 9P protocol, which includes about 30 control messages. The implementation of 9P in GNU/Linux has been added to the main kernel since version 2.6.14 This eliminated any obstacles in the interaction between GNU/Linux and Plan 9. The 9P protocol is structured as a set of transactions, each of which sends a request from the client process to a local or remote server and returns the result. 9P controls the file system, not just the files. It includes procedures for distinguishing file names and converting the hierarchy of file system names provided by the server. On the other hand, unlike systems such as Sprite⁵, the user namespace is supported only by the client system, and not on or with the server. In addition, file access occurs at the byte level, not at the block level, which distinguishes 9P from protocols such as NFS and RFS.

A typical Plan 9 installation consists of a number of computers connected to a network and each providing services of a certain class. Shared multiprocessor servers ensure the execution of computing cycles. Other large machines serve as file storages. These machines were located in an air-conditioned room and connected by a high-performance network. Networks with lower bandwidth, such as Ethernet, connect these servers to office or home workstations or PCs, called terminals in Plan 9 terminology.

The modern style of computing assumes that each user has a dedicated workstation or PC. Plan 9 uses a fundamentally different approach. Although it can function on a workstation with files stored on a local disk, this configuration is not canonical. Instead, machines with monitors, keyboards, and mice gain access to most computing resources and storage systems over the network, becoming terminals of the system, similar to the terminals of the old time-sharing system. The terminal is temporarily personalized by this user when using Plan 9.

The principle of building equipment for the user does not work here. Plan 9 offers the possibility to programmatically change how it is perceived by the user. This adjustment is accompanied by giving publicly visible resources on the network local personal names. Plan 9 provides a mechanism for organizing a personal representation of a shared space with local names of globally available resources. Since the most important network resources are files, the model of this representation is file-oriented.

Local namespaces provide a way to implement a network representation “for yourself”. All services available on the network export file hierarchies. Those of them that are important to the user are gathered together into a personal namespace. Currently of no interest are ignored [this approach is hard to understand, but it is one of the most important concepts implemented in the system]. This usage style differs from the homogeneous global namespace in UNIX. Plan 9 has well-known names for services and unified names for files exported by these services, but their representation is completely local. An example is the difference between the phrase “my home” and a clearly formulated exact address. The latter can be used by anyone, whereas the former is used only in colloquial speech: the meaning of a phrase varies depending on who says it and when, but it is considered understandable. Similarly, in Plan 9, the name /dev/mouse always refers to the mouse, and /bin/date is the date output command, but what files these names represent depends on circumstances, for example, on the architecture of the machine executing the date command. Plan 9 thus has local namespaces that obey global conventions. It is these conventions that guarantee reasonable behavior in the presence of local names.

Present day

Plan 9 carried several innovations that influenced many subsequent systems. But until recently, the source code was under a commercial license that bounded developers and users. Bell Labs and a small community of programmers continued to improve and develop Plan 9.

The license was softened from year to year, and in 2003 Plan 9 was finally released under the first free license. The commercial branch, known as Inferno, is now also available under a free license.

9front

This is a fork of Plan 9, which has been worked on by a team of developers from the NineTimes community since 2011. It consists of fans of the original OS from Bell Labs. One of the main problems of the original Plan 9, which slowed down the development of the system, was the lack of drivers and weak support for peripheral equipment. This was due to the uniformity of the equipment in the laboratory. This is exactly the problem that the developers of 9front tried to solve. They wrote OS drivers for USB, Wi-Fi, audio cards, game emulators [you can run DOOM]. The fork was distributed under the same open Lucent Public License as Plan 9. At the moment, distribution is conducted under the MIT license.

The creators of 9front have placed a package repository on the network, which greatly facilitates the installation of system components. The loader was completely rewritten in this fork. It is called 9boot and is distinguished by the use of rc scripts that allow you to access shell at any stage of loading [which may be useful if something went wrong].

Plan 9 supported several file systems: first, the native Fossil developed at Bell Labs specifically for this platform, as well as Kfs, Paq, cwfs and FAT ** [where without it]**. In 9front, the main FS is cwfs (cwfs64x) - this is also a file system from Plan 9, which supports encryption of disk partitions, and also allows you to securely store backups of OS components and user data.

The Go programming language compiler has been added to 9front. A simple text editor hold was also added to the package. The distributed version control system Git is used to update the OS. In order to provide more flexible hardware support, the message-triggered interrupts subsystem MSI (message signalled interrupts) was introduced.

The system is regularly updated, the latest up-to-date version was released on April 28, 2024⁶. You can try 9front on a virtual machine, either by installing it on a PC or a single-board computer.

System operational

Yes, it is certainly not suitable for everyday use. Like Plan 9, 9front is still an experimental, research OS. The main purpose of the creation was to bring to life some of the original ideas of UNIX and implement them on a more advanced and modern hardware platform. It was generally successful. In research laboratories Plan 9 was used quite effectively as a platform for distributed computing. At a minimum, Plan 9 and 9front have proven that the basic concept of UNIX - each system interface can be represented as a set of files - is quite successfully implemented in a modern OS.

Like other forks of Plan 9, among which it should be noted 9atom, Harvey OS and Jehanne OS, 9front is an OS for programmers and engineers. For those who prefer to dig into configs and write their own code rather than run someone else’s. 9front can be called the most active offshoot from the “classic” Plan 9. The creators of the fork are continuously working to improve hardware support and develop new drivers. Their efforts also have practical applications: for example, the ATA over Ethernet protocol, created for NAS clusters, works on principles similar to the Plan 9 architecture.

With the advent and development of the Internet of Things and single-board computers with limited performance, the demand for distributed operating systems that allow flexible redistribution of computing resources in the network and ensure their balancing is sure to grow.

This means that this project has a future.