Past and present
Posted 2024-10-31. Last updated 2024-11-05.
Since the development of **UNIX**, the programmers of **Bell Labs** have not been idle.
Their next brainchild was the distributed operating system **Plan 9**.
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.
It was decided to create an OS more adapted to the challenges of the time.
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**.
"“Look, that rabbit’s got a vicious streak a mile wide! It’s a killer!” – Tim the Enchanter" Glenda
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.
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.
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.
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.
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.
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.
Precursor systems are based on a similar idea[^3], but in Plan 9 the metaphor of files is developed much further[^4].
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.
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[^5], 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.
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.
This adjustment is accompanied by giving publicly visible resources on the network local personal names.
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**.
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.
It is these conventions that guarantee reasonable behavior in the presence of local names.
But until recently, the source code was under a commercial license that bounded developers and users.
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.
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]**.
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[^6].
You can try **9front** on a virtual machine, either by installing it on a PC or a single-board computer.
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.
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.
[2] Plan 9 Inferno-like registry server
[6] 9FRONT “DO NOT INSTALL” RELEASED
© 2024 POLYSERV BY MODERN HOME
