Episode 76 – 77 – 78: Oberon, Plan 9 and Inferno

None of these are Unix

It’s true. None of the Operating System’s I want to talk about today are what We would call UNIX or Linux like Operating Systems. They might have similarities and/or resemblance to UNIX like systems ( Plan9 was made in Bell Labs where UNIX was born and was indeed building on the UNIX Concepts ) but there is a clear connetion between these systems. They are not usual in any way 🙂 no , seriously they are influenced by one another ( or built upon the experience of one another) in order such as:

Oberon >> Plan9 >> Inferno

Oberon

One screenshot of the Oberon Operating System

The Oberon System is a modular, single-user, single-process, multitasking operating system written in the programming language Oberon. It was originally developed in the late 1980s at ETH Zurich. The Oberon System has an unconventional visual text user interface (TUI) instead of a conventional command-line interface (CLI) or graphical user interface (GUI). This TUI was very innovative in its time and influenced the design of the Acme text editor for the Plan 9 from Bell Labs operating system.

The latest version of the Oberon System, Project Oberon 2013, is still maintained by Niklaus Wirth and several collaborators, but older ETH versions of the system have been orphaned. The system also evolved into the multi-process, symmetric multiprocessing (SMP) capable A2 (formerly Active Object System (AOS),[5] then Bluebottle), with a zooming user interface (ZUI).

The Oberon operating system was originally developed as part of the NS32032-based Ceres workstation project. It was written almost entirely (and since the 2013 version, is described entirely) in the Oberon programming language.

Photo of a Ceres workstation // Copyright www.cpu-ns32k.net

The Ceres Workstation was a workstation computer built by Niklaus Wirth’s group at ETH Zurich in 1987. The central processing unit (CPU) is a National Semiconductor NS32000, and the operating system, named The Oberon System is written fully in the object-oriented programming language Oberon. It is an early example of an object-oriented operating system using garbage collection on the system level and a document centered approach for the user interface (UI), as envisaged later with OpenDoc

Lilith workstation based on AMD 2901

Ceres was a follow-up project to the Lilith workstation, based on AMD bit slicing technology and the programming language Modula-2.

The basic system was designed and implemented by Niklaus Wirth and Jürg Gutknecht and its design and implementation is fully documented in their book “Project Oberon”.The user Interface and programmers reference is found in Martin Reiser’s book “The Oberon System”. It was later extended and ported to other hardwareby a team at ETH Zurich and there was recognition in popular magazines. Wirth and Gutknecht (although being active computer science professors) refer to themselves as ‘part-time programmers’ in the book Project Oberon. In late 2013, a few months before his 80th birthday, Wirth published a second edition of Project Oberon.It details implementing the Oberon System using a reduced instruction set computer (RISC) CPU of his own design realized on a Xilinx field-programmable gate array (FPGA) board. It was presented at the symposium organized for his 80th birthday at ETH Zurich. In the meantime, several emulators for this version were implemented.

According to Josef Templ, a former member of the developer group at Swiss Federal Institute of Technology in Zurich and later member of the Institut für Systemsoftware of Johannes Kepler University Linz, where one forked version (V4) was maintained, the genealogy of the different versions of the Oberon System is this:

Year	Name	Remark
1985		Start of Oberon project
1987	V1	Internal use at ETHZ simple text editing facilities only
1991	V2		Extensible text model and a special editor named Write supporting these extensions
1991		System 3	Kernel extensions supporting persistent objects and object-libraries supporting object embedding and object linking; Gadgets, Script (text editor), Illustrate (graphics editor)
1992			Publication of Oberon Trilogy: “Project Oberon”  “The Oberon System” and “Programming in Oberon”
1992	V4		Functions of Write integrated into standard text editor
		Rel. 1.4	Desktops
1993		Rel. 1.5	Generic document model
1994	V4		Hanspeter Mössenböck appointed at JKU (Linz), V4 development moves there
1995		Rel. 2.0	Document space extended to the whole internet; improved bitmap editor: Rembrandt; online tutorials
2000		ETH-Oberon	System-3 renamed ETH-Oberon
2002		AOS	Active Object System, also Active Oberon System, later renamed Bluebottle, then A2
2013	PO 2013 – V5	Re-implementation of the original Oberon System in FPGA

Oberon has a text user interface (TUI), which is very different from a terminal user interface. It combines the point and click convenience of a graphical user interface (GUI) with the linguistic strength of a command-line interface (CLI) and is closely tied to the naming conventions of the Oberon language. Text appearing almost anywhere on a screen can be edited and used as command input. Commands are activated by a middle-mouse click on a text fragment of the form Module.Command (optionally followed by parameters, which are terminated by ~). A command is defined by any procedure which is exported and has an empty argument list. Parameters to the command must be defined before executing the middle click, and must be explicitly scanned and retrieved by the procedure. No checks or questions occur during command execution. This is sometimes called a non-modal user interface (UI). Nothing like a command prompt is needed.

Although very different from a command line, the TUI is very efficient and powerful. A steep ascent in the early learning curve makes it a bit difficult at first. No questions are asked: this is a deliberate design decision, which needs getting used to. Most editors ask the user when closing a modified text: this is not the case in the Oberon System. The use of the TUI and programming interface is fully documented in Martin Reiser’s book “The Oberon System”. A short introduction to the user interface can be found on Niklaus Wirth’s home page. The later Versions of System Oberon, Oberon V4 (V4, sometimes also named Linz-Oberon) and Oberon System 3 (or S3, sometimes also named ETH-Oberon or Spirit of Oberon), enhanced the basic interface with different but incompatible implementations for buttons, drop down menus, and other active elements. V4 used for that purpose a dedicated control character embedded in normal text in contrast to System 3, which extended the kernel by introducing persistent objects. Both extensions include a large set of user interface elements.

Mastering the Oberon user interface, both the purely textual and the so-called Gadgets System (under S3), is non-trivial. Thus, after successfully installing Oberon System 3, it is recommended to study André Fischers Oberon System 3 Tutorial. An expanded version of this tutorial was published as a book which it is out of print now. The whole book is available in electronic form under one user license in every installed version of System 3 (Windows, Linux, or Native, i.e., also with the Gadgets toolkit of OLR). More information how to get your own copy of the Oberon Companion may be found in the Getting Started section of the Oberon Wikibook.

Similar user Interfaces have yet to appear in more commonplace operating systems. Rob Pike’s Acme system for Plan 9 from Bell Labs was strongly inspired by the Oberon TUI. Whether the worksheet interface of the Macintosh Programmer’s Workshop influenced Oberon’s TUI or vice versa is difficult to decide: the Oberon System was based on Wirth’s prior computer design the Lilith, and both the Apple Macintosh (and its precursor Lisa) and the Oberon System (on Ceres and its precursor Lilith) have the same roots: they were all inspired by the Alto developed at Xerox PARC.

Versions and Availability

V1 was the first usable version some time before the Oberon Trilogy was published. A major change in the text model together with the editor named Write yielded V2. As foreshadowed in the table in section History above, there was a major fork in the early 1990s: V4 vs. System 3: The group around Jürg Gutknecht introduced persistent objects and object-libraries thereby extending the kernel. The group around Hanspeter Mössenböck realized similar features by introducing active elements mapped to a special character thereby extending fonts without changing the kernel. System 3 was sometimes also named Spirit of Oberon and later renamed ETH Oberon, whereas V4 was sometimes also named Linz Oberon.

As of 2017, the Oberon OS is available for several hardware computing platforms, generally in no cost versions and from several sources, which is quite confusing. The Oberon OS is typically extremely compact. Even with an Oberon compiler, assorted utilities including a web browser, TCP/IP networking, and a GUI, the full package can be compressed to one 3.5″ floppy disk. There are versions which emulated the Oberon OS on another operating system and versions which run on bare hardware. The latter ones are named Native Oberon. There are native versions for the Ceres, Intel IA-32, and ARM platforms. In 2013, Niklaus Wirth adapted the basic system as described in “Project Oberon” to a current FPGA design. According to the preface of the 2013 edition, the whole system compiles in less than 10 seconds on a Spartan-3 board. This version is sometimes also named V5, despite it being much more similar functionally to the original V1 running on the Ceres than any of the later versions.

A version of the Oberon System 3 which was integrated in the Microsoft Windows OS was named Plugin Oberon.[33] Plugin Oberon supported the binary format named Oberon Module Interchange (OMI) or slim binaries, which allowed portable object code between Intel x86, Motorola 68k, and PowerPC architectures. Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple during the transition from 68k to PowerPC architectures. OMI provided portable code based on a compressed version of the abstract syntax tree. The approach of a compressed abstract syntax tree is revived for GraalVM and Truffle.

The version named Oberon V4 (see also History) is closer to the original operating system developed by Wirth and Gutknecht. It was originally developed at ETHZ, but when H.P. Mössenböck went to Institut für Systemsoftware at Johannes-Kepler University in Linz (JKU), the development of V4 moved also. Thus, V4 is sometimes also called Linz-Oberon in contrast to ETH-Oberon. The most recent version of V4 and extensions are available at JKU. Oberon V4 appears to be orphaned, there are almost no changes since 2000. Another repository of V4 is Claudio Nieder’s Oberon V4, which also shows difference between the different V4 implementations. Since 2013 this page moved to/is mirrored at SourceForge. V4 is closer to what would now be called an integrated development environment than an operating system of its own. There were many extensions written for V4, which are still available from the ftp server of SSW at JKU; some documentation can be found on their web-pages, more information is normally included in the packages and it is given in Oberon’s special rich text format.

Around 2010, the computer science department at ETH Zurich began exploring active objects and concurrency for operating systems, and has released an early version of a new language Active Oberon and a new operating system for it, first named Active Object System (AOS) in 2002 then due to trademark issues, renamed Bluebottle in 2005, then renamed A2 in 2008. It is available from ETH Zurich with most source via the Internet. Native versions (A2) run on bare hardware, and are currently possible for Intel IA-32 and x86-64 single- and multi-processor systems, and for the StrongARM CPU family. Versions for other operating systems are available on Windows (WinAos), Unix (UnixAos), Linux (LinuxAos), and macOS (DarwinAos). More detailed information about A2 is on the Russian Wikipedia pages about A2.

As a part of an industrial research project the Native Systems Group of ETH Zurich has developed an application-specific operating system named stailaOS which is based on the latest version Oberon OS. It is intended for uses such as real-time analytics, high performance automated trading system (ATS), main memory based enterprise resource planning (ERP), etc.

Native Oberon

Native Oberon is an Oberon System that runs on bare hardware. PC-Native Oberon is a version that runs on IA-32 (x86-32) PC hardware. There has never been a V4 Native Oberon, so all information in this section implicitly assumes that it is System 3. Native Oberon has small hardware requirements: 133 MHz Pentium, 100MB hard disk, VESA 2 graphics card with resolution minimum of 1024×768 pixels, optional 3Com network card. The basic system runs from one HD floppy disk, and more software can be installed through a network. The full installation includes the Gadgets GUI. It is written fully in the language Oberon.

The Oberon0 installer running on QEMU in Debian Wheezy. The presentation of the partition table illustrates the comprehensibility of the system in general. CC – PeterEasthope

A version named Linux Native Oberon (LNO) uses Linux as a hardware abstraction layer (HAL). Its goal is to be as compatible as possible to PC-Native Oberon. Other versions of the Oberon System, without Native in the name, had partly modified interfaces of low level modules. In 2015, Peter Matthias revitalized LNO under the name Oberon Linux Revival (OLR) as a multi-platform distribution running seamlessly on Intel x86, ARM, MIPS, and RISC-V. It runs well on the Raspberry Pi and on the low cost CHIP computer; with some tweaking (adjusting group membership or/and permissions on some devices) it runs well on Tiny Core Linux. OLR interfaces with Linux kernel by direct system calls. As of June 2017, OLR lacks a network layer.

Project Oberon 2013

In 2013, Wirth and Paul Reed completed a re-implementation of the original Oberon System for the Digilent Xilinx Spartan 3 FPGA Starter Board. The work includes a revision of “Project Oberon” identified as Project Oberon (New Edition 2013). In 2015, Reed collaborated with Victor Yurkovsky to create OberonStation, a Xilinx Spartan 3-based computer designed specifically to run Oberon. The system has since been ported to a Xilinx Spartan 6 FPGA Pepino development board by Saanlima Electronics, and a Xilinx Artix 7-based Digilent Nexys A7-100 FPGA Trainer board by CFB Software. Peter de Wachter implemented an emulator for it, which was also ported to Java and JavaScript by Michael Schierl, running in modern browsers, and ported to Free Pascal/Ultibo by Markus Greim. Andreas Pirklbauer maintains an experimental version and extensions of Project Oberon 2013 at GitHub.

Plan 9

Installation of Plan9 – CC Bell Labs

Glenda the Plan9 bunny mascot

Plan 9 from Bell Labs is a distributed operating system, originating in the Computing Science Research Center (CSRC) at Bell Labs in the mid-1980s, and building on UNIX concepts first developed there in the late 1960s. 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-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.

The name Plan 9 from Bell Labs is a reference to the Ed Wood 1959 cult science fiction Z-movie Plan 9 from Outer Space (The name of the project’s mascot, “Glenda, the Plan 9 Bunny”, is presumably a reference to Wood’s film Glen or Glenda.) The system continues to be used and developed by operating system researchers and hobbyists.

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.

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[24]
2000	Plan 9 3rd ed. (Brazil)	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,

[t]he foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol.

— Pike et al.

The first idea (a per-process name space) means that, unlike on most operating systems, processes (running programs) 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 (a message-oriented filesystem) 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 (mice, removable media, etc.) 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: mouse, which can be read by a program to get notification of mouse movements and button clicks, cons, which can be used to perform textual input/output, and bitblt, writing to which enacts graphics operations (see bit blit). 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 mouse, cons and bitblt 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 cpu command starts a remote session on a computation server. 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.

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 (such as Berkeley sockets, X resources or ioctl system calls) 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 (called names) from different directory trees in a single location. The resulting union directory behaves as the concatenation of the underlying directories (the order of concatenation can be controlled); if the constituent directories contain files having the same name, a listing of the union directory (ls or lc) will simply report duplicate names. Resolution of a single path name is performed top-down: if the directories top and bottom are unioned into u with top first, then u/name denotes top/name if it exists, bottom/name only if it exists and top/name does not exist, and no file if neither exists. No recursive unioning of subdirectories is performed, so if top/subdir exists, the files in bottom/subdir are not accessible through the union.

A union directory can be created by using the bind command:

; bind /arm/bin /bin
; bind -a /acme/bin/arm /bin
; bind -b /usr/alice/bin /bin

In the example above, /arm/bin is mounted at /bin, the contents of /arm/bin replacing the previous contents of /bin. Acme’s bin directory is then union mounted after /bin, and Alice’s personal bin directory is union mounted before. When a file is requested from /bin, it is first looked for in /usr/alice/bin, then in /arm/bin, and then finally in /acme/bin/arm.

The separate process namespaces thus replace the notion of a search path in the shell. Where Unix shells have a list of directories to search for programs when given a command, the Plan 9 shell only looks in the directory /bin; adding commands is done by binding several directories together to appear as a single /bin.

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

Instead of having system calls specifically for process management, Plan 9 provides the /proc 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.[6]

/net
Plan 9 does not have specialised system calls or ioctls for accessing the networking stack or networking hardware. Instead, the /net file system is used. Network connections are controlled by reading and writing control messages to control files. Sub-directories such as /net/tcp and /net/udp are used as an interface to their respective protocols.

Software for Plan9

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.

Graphical programs

Unlike Unix, Plan 9 was designed with graphics in mind. After booting, a Plan 9 terminal will run the rio windowing system, in which the user can create new windows displaying rc. Graphical programs invoked from this shell replace it in its window.

The plumber provides an inter-process communication mechanism which allows system-wide hyperlinking.

Sam and acme are Plan 9’s text editors.

Storage system

Plan 9 supports the Kfs, Paq, Cwfs, FAT, and Fossil file systems. The last was designed at Bell Labs specifically for Plan 9 and provides snapshot storage capability. It can be used directly with a hard drive or backed with Venti, an archival file system and permanent data storage system.

Software development

The distribution package for Plan 9 includes special compiler variants and programming languages, and provides a tailored set of libraries along with a windowing user interface system specific to Plan 9. The bulk of the system is written in a dialect of C (ANSI C with some extensions and some other features left out). The compilers for this language were custom built with portability in mind; according to their author, they “compile quickly, load slowly, and produce medium quality object code”.

A concurrent programming language called Alef was available in the first two editions, but was then dropped for maintenance reasons and replaced by a threading library for C.

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”.[46] 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.

Acme text editor which is more than just a text editor

Plan9 running acme and rc . CC – Bell Labs

acme on Plan9

Acme is a text editor and graphical shell from the Plan 9 from Bell Labs operating system, designed and implemented by Rob Pike. It can use the Sam command language. The design of the interface was influenced by Oberon. It is different from other editing environments in that it acts as a 9P server. A distinctive element of the user interface is mouse chording.

Acme can be used as a mail and news reader, or as a frontend to wikifs. These applications are made possible by external components interacting with acme through its file system interface. Rob Pike has mentioned that the name “Acme” was suggested to him by Penn Jillette of Penn & Teller during a movie night at Times Square when he asked for a suitable name for a text editor that does “everything”.

A port to the Inferno operating system is part of Inferno’s default distribution. Inferno can run as an application on top of other operating systems, allowing Inferno’s port of acme to be used on most operating systems, including Microsoft Windows and Linux. A project called acme: stand alone complex intends to make acme run as a standalone application on the host operating system.

A working port of acme for Unix-like operating systems is included in Plan 9 from User Space, a collection of various ported programs from Plan 9. Currently it has been tested on a variety of operating systems including: Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Solaris and SunOS.

The wmii X window manager was inspired by acme, a text editor from the Plan 9 project.

Impact of Plan9

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. Some features from Plan 9, like the UTF-8 character encoding of Unicode, have been implemented in other operating systems. Unix-like operating systems such as Linux have implemented 9P, Plan 9’s file system, and have adopted features of rfork, Plan 9’s process creation mechanism. Additionally, in Plan 9 from User Space, several of Plan 9’s applications and tools, including the sam and acme editors, have been ported to Unix and Linux systems and have achieved some level of popularity. Several projects seek to replace the GNU operating system programs surrounding the Linux kernel with the Plan 9 operating system programs. The 9wm window manager was inspired by 8½, the older windowing system of Plan 9; wmii is also heavily influenced by Plan 9. In computer science research, Plan 9 has been used as a grid computing platform and as a vehicle for research into ubiquitous computing without middleware. In commerce, Plan 9 underlies Coraid storage systems. However, Plan 9 has never approached Unix in popularity, and has been primarily a research tool:

[I]t looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. 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. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

— Eric S. Raymond

Other factors that contributed to low adoption of Plan 9 include the lack of commercial backup, the low number of end-user applications, and the lack of device drivers.

Plan 9 proponents and developers claim that the problems hindering its adoption have been solved, that its original goals as a distributed system, development environment, and research platform have been met, and that it enjoys moderate but growing popularity.Inferno, through its hosted capabilities, has been a vehicle for bringing Plan 9 technologies to other systems as a hosted part of heterogeneous computing grids.

Several projects work to extend Plan 9, including 9atom and 9front. These forks augment Plan 9 with additional hardware drivers and software, including an improved version of the Upas e-mail system, the Go compiler, Mercurial version control system support, and other programs. Plan 9 was ported to the Raspberry Pi single-board computer.The Harvey project attempts to replace the custom Plan 9 C compiler with GCC, to leverage modern development tools such as GitHub and Coverity, and speed up development.

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.
• 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 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 Plan9-9k 64-bit Plan9 kernel.
• NIX is a fork of Plan9 aimed at multicore systems and cloud computing.
• Plan B designed to work in distributed environments where the set of available resources is different at different points in time.

Inferno

Screenshot of Inferno 4th edition Operating System

Inferno is a distributed operating system started at Bell Labs and now developed and maintained by Vita Nuova Holdings as free software. Inferno was based on the experience gained with Plan 9 from Bell Labs, and the further research of Bell Labs into operating systems, languages, on-the-fly compilers, graphics, security, networking and portability. The name of the operating system and many of its associated programs, as well as that of the current company, were inspired by Dante Alighieri’s Divine Comedy. In Italian, Inferno means “hell” — of which there are nine circles in Dante’s Divine Comedy.

History

Inferno is a descendant of Plan 9 from Bell Labs, 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.

In the mid-1990s, Plan 9 development was set aside in favor of Inferno. The new system’s existence was leaked by Dennis Ritchie in early 1996, after less than a year of development on the system, and publicly presented later that year as a competitor to Java. At the same time, Bell Labs’ parent company AT&T licensed Java technology from Sun Microsystems.

In March–April 1997 IEEE Internet Computing included an advertisement for Inferno networking software. It claimed that various devices could communicate over “any network” including the Internet, telecommunications and LANs. The advertisement stated that video games could talk to computers,–a PlayStation was pictured–cell phones could access email and voice mail was available via TV.

Lucent used Inferno in at least two internal products: the Lucent VPN Firewall Brick, and the Lucent Pathstar phone switch. They initially tried to sell source code licenses of Inferno but found few buyers. Lucent did little marketing and missed the importance of the Internet and Inferno’s relation to it. During the same time Sun Microsystems was heavily marketing its own Java programming language, which was targeting a similar market, with analogous technology, that worked in web browsers and also filled the demand for object-oriented languages popular at that time. Lucent licensed Java from Sun, claiming that all Inferno devices would be made to run Java. A Java byte code to Dis byte code translator was written to facilitate that. However, Inferno still did not find customers.

The Inferno Business Unit closed after three years, and was sold to Vita Nuova. Vita Nuova continued development and offered commercial licenses to the complete system, and free downloads and licenses (not GPL compatible) for all of the system except the kernel and VM. They ported the software to new hardware and focused on distributed applications. Eventually, Vita Nuova released the source under the GPL license and the Inferno operating system is now a Free/Libre/Open Source Software project.

Design principles

Inferno was created in 1995 by members of Bell Labs’ Computer Science Research division to bring ideas of Plan 9 from Bell Labs to a wider range of devices and networks. Inferno is a distributed operating system based on three basic principles drawn from Plan 9:

• Resources as files: all resources are represented as files within a hierarchical file system
• Namespaces: a program’s view of the network is a single, coherent namespace that appears as a hierarchical file system but may represent physically separated (locally or remotely) resources
• Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remote

To handle the diversity of network environments it was intended to be used in, the designers decided a virtual machine was a necessary component of the system. This is the same conclusion of the Oak project that became Java, but arrived at independently. The Dis virtual machine is a register machine intended to closely match the architecture it runs on, as opposed to the stack machine of the Java Virtual Machine. An advantage of this approach is the relative simplicity of creating a just-in-time compiler for new architectures.

The virtual machine provides memory management designed to be efficient on devices with as little as 1 MiB of memory and without memory-mapping hardware. Its garbage collector is a hybrid of reference counting and a real-time coloring collector that gathers cyclic data.[3]

The Inferno kernel contains the virtual machine, on-the-fly compiler, scheduler, devices, protocol stacks, and the name space evaluator for each process’ file name space, and the root of the file system hierarchy. The kernel also includes some built-in modules that provide interfaces of the virtual operating system, such as system calls, graphics, security, and math modules.

The Bell Labs Technical Journal paper introducing Inferno listed several dimensions of portability and versatility provided by the OS:

• Portability across processors: it currently runs on ARM, SGI MIPS, HP PA-RISC, IBM PowerPC, Sun SPARC, and Intel x86 architectures and is readily portable to others.
• Portability across environments: it runs as a stand-alone operating system on small terminals, and also as a user application under Bell Plan 9, MS Windows NT, Windows 95, and Unix (SGI Irix, Sun Solaris, FreeBSD, Apple Mac OS X, Linux, IBM AIX, HP-UX, Digital Tru64). In all of these environments, Inferno programs see an identical interface.
• Distributed design: the identical environment is established at the user’s terminal and at the server, and each may import the resources (for example, the attached I/O devices or networks) of the other. Aided by the communications facilities of the run-time system, programs may be split easily (and even dynamically) between client and server.
• Minimal hardware requirements: it runs useful applications stand-alone on machines with as little as 1 MiB of memory, and does not require memory-mapping hardware.
• Portable programs: Inferno programs are written in the type-safe language Limbo and compiled to Dis bytecode, which can be run without modifications on all Inferno platforms.
• Dynamic adaptability: programs may, depending on the hardware or other resources available, load different program modules to perform a specific function. For example, a video player might use any of several different decoder modules.

These design choices were directed to provide standard interfaces that free content and service providers from concern of the details of diverse hardware, software, and networks over which their content is delivered.

Features

Inferno programs are portable across a broad mix of hardware, networks, and environments. It defines a virtual machine, known as Dis, that can be implemented on any real machine, provides Limbo, a type-safe language that is compiled to portable byte code, and, more significantly, it includes a virtual operating system that supplies the same interfaces whether Inferno runs natively on hardware or runs as a user program on top of another operating system.

A communications protocol called Styx is applied uniformly to access both local and remote resources, which programs use by calling standard file operations, open, read, write, and close. As of the fourth edition of Inferno, Styx is identical to Plan 9’s newer version of its hallmark 9P protocol, 9P2000.

Most of the Inferno commands are very similar to Unix commands with the same name.

Ports

Inferno runs directly on native hardware and also as an application providing a virtual operating system which runs on other platforms. Programs can be developed and run on all Inferno platforms without modification or recompilation.

Native ports include these architectures: x86, MIPS, ARM, PowerPC, SPARC.

Hosted or virtual OS ports include: Microsoft Windows, Linux, FreeBSD, Plan 9, Mac OS X, Solaris, IRIX, UnixWare.

Inferno can also be hosted by a plugin to Internet Explorer. Vita Nuova said that plugins for other browsers were under development, but they were never released.

Inferno has also been ported to Openmoko, Nintendo DS, SheevaPlug and Android.

Distribution

Inferno 4th edition was released in early 2005 as free software. Specifically, it was dual-licensed under two licenses. Users could either obtain it under a set of free software licenses, or they could obtain it under a proprietary license. In the case of the free software license scheme, different parts of the system were covered by different licenses, including the GNU General Public License, the GNU Lesser General Public License, the Lucent Public License, and the MIT License. Subsequently, Vita Nuova has made it possible to acquire the entire system (excluding the fonts, which are sub-licensed from Bigelow and Holmes) under the GPLv2. All three license options are currently available.

9front and 9legacy

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.

You can find a lot of information on both 9front’s and 9legacy’s websites and read more about it … the 9front one is definitely full with information

Harvey OS and Jehanne OS ( both inspired by Plan9)

Jehanne OS

Harvey OS

Harvey OS description from it’s website:

Harvey is an effort to provide a modern, distributed, 64 bit operating system. A different environment for researching and finding new lines of work.

It runs on x86_64 (amd64) machines. Main work is focused in improving the kernel and userland, trying to bring up a full usable operating system with common tools for development and a USB installation image. It collects many different ideas and concepts that, across many platforms and operating systems, influenced the computing world for years.

Jehanne OS description from it’s website:

Jehanne is a simple operating system.

It shows that few orthogonal abstractions can be composed to provide everything you want from modern operating systems.
And more.

A vision for simplicity

Jehanne is named after a peasant girl that was burned as an heretic and then canonized as a saint.

Everybody can see why it’s an heretic OS: it breaks many traditions of Plan 9 from Bell Labs, it challenges some design decisions and even breaks some common conventions rooted in Unix.

There is no /bin folder. There is no sleep system call.
There is no swap. Markdown replaces troff for documentation.
GCC is the default compiler. 9P2000 is still supported, but replaced.

However, the point of this research is not to disrupt well established habits, but to pursuit a vision for simplicity.

Beware, there’s no glory for simplicity: everybody can do it, after.

More with less

Jehanne is simple in many different ways.

The kernel API is minimal and uniform: 26 system calls control devices, memory, IPC, scheduling and namespaces.
Everthing is a file. Really. Even directories.
The default file system provides a clean taxonomy.
The project scope includes a minimal system: compilers, editors, browsers, games… many useful softwares can be ported to Jehanne through libposix and newlib (and soon musl).

Also, Jehanne is free software. And it will always be.
The kernel and older tools are GPLv2, everything new is AGPLv3.
It’s not only “formally” open, like many other projects from big names: you are wellcome to challenge my assumptions, prove I’m wrong, even remove my code.

You just have to make it both simpler and more useful.

Links

https://pspodcasting.net/dan/blog/2019/plan9_desktop.html

http://www.projectoberon.com/

http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/forschung/weitere_seiten/lilith/index_EN/popupfriendly/

http://cpu-ns32k.net/Ceres.html

https://thedorkweb.substack.com/p/a-week-with-plan-9

https://en.wikipedia.org/wiki/9P_(protocol)

https://en.wikipedia.org/wiki/List_of_Plan_9_applications

http://acme.cat-v.org/

https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/

https://www.operating-system.org/betriebssystem/_english/bs-plan9.htm

https://en.wikipedia.org/wiki/Oberon_(operating_system)

https://en.wikipedia.org/wiki/Acme_(text_editor)

https://en.wikipedia.org/wiki/Inferno_(operating_system)

https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

https://www.harvey-os.org/

http://jehanne.io/pages/overview.html

https://github.com/Harvey-OS/harvey/wiki

https://harvey-os.org/

http://fqa.9front.org/fqa1.html

http://fqa.9front.org/

http://9legacy.org/

https://github.com/0intro/wmii