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

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.

The Web Site to Remember National Semiconductor's Series 32000 Family
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:

1985Start of Oberon project
1987V1Internal use at ETHZ simple text editing facilities only
1991V2Extensible text model and a special editor named Write supporting these extensions
1991System 3Kernel extensions supporting persistent objects and object-libraries supporting object embedding and object linking; Gadgets, Script (text editor), Illustrate (graphics editor)
1992Publication of Oberon Trilogy: “Project Oberon”  “The Oberon System” and “Programming in Oberon”
1992V4Functions of Write integrated into standard text editor
Rel. 1.4Desktops
1993Rel. 1.5Generic document model
1994V4Hanspeter Mössenböck appointed at JKU (Linz), V4 development moves there
1995Rel. 2.0Document space extended to the whole internet; improved bitmap editor: Rembrandt; online tutorials
2000ETH-OberonSystem-3 renamed ETH-Oberon
2002AOSActive Object System, also Active Oberon System, later renamed Bluebottle, then A2
2013PO 2013 – V5Re-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

Plan 9 from Bell Labs (Installation).png
Installation of Plan9 – CC Bell Labs
Glenda bunny mascot of plan 9 from bell black.jpg
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.

1992Plan 9 1st editionReleased by Bell Labs to universities
1995Plan 9 2nd editionReleased by Bell Labs for non-commercial purposes[24]
2000Plan 9 3rd ed. (Brazil)Released by Lucent Technologies under an open source license
2002Plan 9 4th editionReleased 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


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]

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 4th Edition.png
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.


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.


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.


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.


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 | Operating system projects
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.
























The Server Room Show – Episode 67 – 68 AIX


I have always liked Operating Systems. They make computers become something usable and something you can actually interact with to do things Vs what they are in reality which is just a bunch of electronic parts shoved together in some pretty box.

While growing up I have been exposed to the Home Computer boom which was at its height during the 80s with iconic members like the Commodore 64 and some Z80 Clones like the HT-1080Z which were available at high schools during 1983 – 1986 my infancy in Hungary (see the links on the bottom and the image below).

I do still remember the first time somewhere around the late ’87-’88 when I first had the opportunity to touch one HT-1080Z and play with in a high school where my father worked at that time and He took me one early morning with him.

The HT-1080Z was built by Hiradastechnika Szovetkezet after purchasing the license for the Hong Kong based EACA company’s Video Genie computer which looks identical to the HT-1080Z. The Video Genie version sold in North American was called the PMC-80.

The Video Genie itself was considered a TRS-80 Model I clone although the two had hardware and software differences.

HT-1080Z School Computer (1983) – Péter Hoványi

I saw Commodore’s Basic, MS DOS and later on and some Novell Netware, Windows 3.1, OS/2 , BeOS, Linux, Mac OS, BSD then FreeBSD as I grew older.

It was during that time I have seen once a Pegasos motherboard/system running Amiga OS with true multitasking and multimedia which was very unique and not affordable to me at all and to this day I have never forgot the experience or the way it made me smile 🙂

But I have only heard about but never had any experience or exposure to z/OS, z/VM from IBM or UNIX of any kind (HP-UX, Solaris, AIX ) They were all very mystical and unreachable for me while I was a kid and even later when I was in my way through adulthood.

When eventually I became an IT Professional I though I would get exposure to all of these systems I have lusted after to know more about for years and years but the sad truth is that I have never had any well not at my jobs.

With the advent of virtualization and cloud computing these things are somewhat changing now but still it is not easy and most of the time not free to tinker around with these systems even just for your own amusement or educational reasons to pick some new or old knowledge up.

Big companies like IBM (AIX and z/OS) and HP (with HP-UX or OpenVMS) are not on the forefront to accommodate homelabbers ( hobbyist) with ways to run these systems for free for non-profit and home use in their home labs. There are some options open to partners and developers through business contracts for huge amounts of money per year which I’m sure no single individual can spare ( the realms of 5 – 10 thousands of euros).

Shows this nothing better than after many years of successful running HP is discontinuing the OpenVMS hobbyist license for individuals on the 31st of December 2021. It will mark an end of an era.


AIX (Advanced Interactive eXecutive) is a series of proprietary Unix operating systems developed and sold by IBM for several of its computer platforms. Originally released for the IBM RT PC RISC workstation, AIX now supports or has supported a wide variety of hardware platforms, including the IBM RS/6000 series and later POWER and PowerPC-based systems, IBM System i, System/370 mainframes, PS/2 personal computers, and the Apple Network Server.

AIX is based on UNIX System V with 4.3BSD-compatible extensions. It is one of four commercial operating systems that have versions certified to The Open Group’s UNIX 03 standard (the others being macOS, HP-UX and eulerOS).

The AIX family of operating systems debuted in 1986, became the standard operating system for the RS/6000 series on its launch in 1990, and is still actively developed by IBM. It is currently supported on IBM Power Systems alongside IBM i and Linux.

AIX was the first operating system to have a journaling file system, and IBM has continuously enhanced the software with features such as processor, disk and network virtualization, dynamic hardware resource allocation (including fractional processor units), and reliability engineering ported from its mainframe designs


As we saw on the episode of UNIX on this podcast Unix started life at AT&T’s Bell Labs research center in the early 1970s, running on DEC minicomputers. By 1976, the operating system was in use at various academic institutions, including Princeton, where Tom Lyon and others ported it to the S/370, to run as a guest OS under VM/370. This port would later grow out to become UTS a mainframe Unix offering by IBM’s competitor Amdahl Corporation. IBM’s own involvement in Unix can be dated to 1979, when it assisted Bell Labs in doing its own Unix port to the 370 (to be used as a build host for the 5ESS switch’s software). In the process, IBM made modifications to the TSS/370 hypervisor to better support Unix.

It took until 1985 for IBM to offer its own Unix on the S/370 platform, IX/370, which was developed by Interactive Systems Corporation and intended by IBM to compete with Amdahl UTS. The operating system offered special facilities for interoperating with PC/IX, Interactive/IBM’s version of Unix for IBM PC compatible hardware, and was licensed at $10,000 per sixteen concurrent users

AIX version 1

AIX Version 1, introduced in 1986 for the IBM RT PC workstation, was based on UNIX System V Releases 1 and 2. In developing AIX, IBM and Interactive Systems Corporation (whom IBM contracted) also incorporated source code from 4.2 and 4.3 BSD UNIX.

The IBM RT PC Workstation

IBM PC RT 6151
IBM RT PC 6151 booting AIX 2.2.1

The IBM RT PC (RISC Technology Personal Computer) is a family of workstation computers from IBM introduced in 1986.

These were the first commercial computers from IBM that were based on a reduced instruction set computer (RISC) architecture. The RT PC used IBM’s proprietary ROMP microprocessor, which commercialized technologies pioneered by IBM Research’s 801 experimental minicomputer (the 801 was the first RISC). The RT PC ran three operating systems: AIX, the Academic Operating System (AOS), or Pick.

The RT PC’s performance was relatively poor compared to other contemporary workstations and it had little commercial success as a result; IBM responded by introducing the RISC System/6000 workstations in 1990, which used a new IBM-proprietary RISC processor, the POWER1. All RT PC models were discontinued by May 1991.

The primary operating system for the RT was AIX version 2. Much of the AIX v2 kernel was written in a variant of the PL/I programming language the PL/8, which proved troublesome during the migration to AIX v3. AIX v2 included full TCP/IP networking support, as well as SNA, and two networking file systems: NFS, licensed from Sun Microsystems, and IBM Distributed Services (DS). DS had the distinction of being built on top of SNA, and thereby being fully compatible with DS on the IBM midrange AS/400 and mainframe systems. For the graphical user interfaces, AIX v2 came with the X10R3 and later the X10R4 and X11 releases of the X Window System from MIT, together with the Athena widget set. Compilers for C and Fortran programming languages were available.

Some RT PCs were also shipped with the Academic Operating System (AOS), an IBM port of 4.3BSD Unix to the RT PC. It was offered as an alternative to AIX, the usual RT PC operating system, to US universities eligible for an IBM educational discount. AOS added a few extra features to 4.3BSD, notably NFS, and an almost ANSI C-compliant C compiler. A later version of AOS existed that was derived from 4.3BSD-Reno, but it was not widely distributed.

The RT forced an important stepping-stone in the development of the X Window System, when a group at Brown University ported X version 9 to the system. Problems with reading unaligned data on the RT forced an incompatible protocol change, leading to version 10 in late 1985.

IBM PS/2 series

AIX PS/2 (also known as AIX/386) was developed by Locus Computing Corporation under contract to IBM. AIX PS/2, first released in October 1988, ran on IBM PS/2 personal computers with Intel 386 and compatible processors.AIX PS/2 1.3 AIXwindows Desktop

The product was announced in September 1988 with a baseline tag price of $595, although some utilities like uucp were included in a separate Extension package priced at $250. nroff and troff for AIX were also sold separately in a Text Formatting System package priced at $200. The TCP/IP stack for AIX PS/2 retailed for another $300. The X Window package was priced at $195, and featured a graphical environment called the AIXwindows Desktop, based on IXI’s X.desktop. The C and FORTRAN compilers each had a price tag of $275. Locus also made available their DOS Merge virtual machine environment for AIX, which could run MS DOS 3.3 applications inside AIX; DOS Merge was sold separately for another $250. IBM also offered a $150 AIX PS/2 DOS Server Program, which provided file server and print server services for client computers running PC DOS 3.3.

The last version of PS/2 AIX is 1.3. It was released in 1992 and announced to add support for non-IBM (non-microchannel) computers as well. Support for PS/2 AIX ended in March 1995.

AIX version 3 and 4

Among other variants, IBM later produced AIX Version 3 (also known as AIX/6000), based on System V Release 3, for their POWER-based RS/6000 platform. Since 1990, AIX has served as the primary operating system for the RS/6000 series (later renamed IBM eServer pSeries, then IBM System p, and now IBM Power Systems). AIX Version 4, introduced in 1994, added symmetric multiprocessing with the introduction of the first RS/6000 SMP servers and continued to evolve through the 1990s, culminating with AIX 4.3.3 in 1999. Version 4.1, in a slightly modified form, was also the standard operating system for the Apple Network Server systems sold by Apple Computer to complement the Macintosh line.

RISC System/6000 (RS/6000)

The RISC System/6000 (RS/6000), is a family of RISC-based Unix servers, workstations and supercomputers made by IBM in the 1990s. The RS/6000 family replaced the IBM RT PC computer platform in February 1990 and was the first computer line to see the use of IBM’s POWER and PowerPC based microprocessors. In October 2000, the RS/6000 brand was retired for POWER-based servers and replaced by the eServer pSeries. Workstations continued under the RS/6000 brand until 2002, when new POWER-based workstations were released under the IntelliStation POWER brand.

IBM RS6000 AIX File Servers IBM.COM 1998.jpeg
File servers used by IBM for ibm.com in the late 1990’s. These are RS/6000 AIX servers. The author writes: “ibm.com used AFS to share files amongst systems in Schaumburg, IL and Columbus, OH. The R/W master was in Schaumburg, while R/O secondaries were in Schaumburg and Columbus.”

AIX version 5

AIX 5L 5.1, May 4, 2001

AIX 5.1 on POWER4 architecture made a leap forward towards future virtualization on IBM Power

  • 64 bit kernel installed but not enabled by default
  • Ability to run Logical Partitions on POWER4. A logical partition (LPAR) is a subset of a computer’s hardware resources, virtualized as a separate computer. In effect, a physical machine can be partitioned into multiple logical partitions, each hosting a separate instance of an operating system
  • JFS2 file system up to 1 TB file system with 1 TB file size support
  • Reliable Scalable Cluster Technology
  • Linux Compatible program interface
  • Workload Manager GUI and functional upgrades

AIX 5L 5.2, October 18, 2002

AIX 5.2 brought even more enhancements:

  • Dynamic logical partitioning for processors, memory, and I/O o Dynamic Capacity Upgrade on Demand Enhancements to Scalability and Workload Manager
  • Enhancements to Enterprise Storage Management
  • Cluster Systems Management for monitoring and administering multiple machines (both AIX and Linux) from a single point of control
  • Advanced RAS features
  • Additional security features and enhancements
  • Network enhancements including Mobile IPv6, SNMP V3, and upgrade to BIND V9
  • APIs from the latest C language and single UNIX specification standards

AIX 5L 5.3, August 13, 2004

The enhancements which came with AIX 5L 5.3 combined with POWER5 series enabled an advanced Power virtualization platform which is still in use today on Power Systems (in a form of PowerVM)

  • Micro-partitioning support for a single processor being shared by up to 10 logical partitions
  • Virtual SCSI disks that allow partitions to access storage without requiring a physical storage adapter
  • Virtual networking: Virtual Ethernet provides high-speed connections between partitions; Shared Ethernet Adapter provides connectivity between internal and external VLANs.
  • NFS v4

AIX version 6 and newer

AIX 6 was announced in May 2007, and it ran as an open beta from June 2007 until the general availability (GA) of AIX 6.1 on November 9, 2007. Major new features in AIX 6.1 included full role-based access control, workload partitions (which enable application mobility), enhanced security (Addition of AES encryption type for NFS v3 and v4), and Live Partition Mobility on the POWER6 hardware.

AIX 7.1 was announced in April 2010, and an open beta ran until general availability of AIX 7.1 in September 2010. Several new features, including better scalability, enhanced clustering and management capabilities were added. AIX 7.1 includes a new built-in clustering capability called Cluster Aware AIX. AIX is able to organize multiple LPARs through the multipath communications channel to neighboring CPUs, enabling very high-speed communication between processors. This enables multi-terabyte memory address range and page table access to support global petabyte shared memory space for AIX POWER7 clusters so that software developers can program a cluster as if it were a single system, without using message passing (i.e. semaphore-controlled Inter-process Communication). AIX administrators can use this new capability to cluster a pool of AIX nodes. By default, AIX V7.1 pins kernel memory and includes support to allow applications to pin their kernel stack. Pinning kernel memory and the kernel stack for applications with real-time requirements can provide performance improvements by ensuring that the kernel memory and kernel stack for an application is not paged out.

AIX 7.2 was announced in October 2015, and released in December 2015. AIX 7.2 principal feature is the Live Kernel Update capability which allows OS fixes to replace the entire AIX kernel with no impact to applications, by live migrating workloads to a temporary surrogate AIX OS partition while the original OS partition is patched. AIX 7.2 was also restructured to remove obsolete components. The networking component, bos.net.tcp.client was repackaged to allow additional installation flexibility. Unlike AIX 7.1, AIX 7.2 is only supported on systems based on POWER7 or later processors.

AIX 7.3 is due to be released in Q4 of 2021

More about AIX

The default shell was Bourne shell up to AIX version 3 and was changed in AIX version 4.
The default graphical user interface is CDE – Common Desktop Environment.

As part of the Linux Affinity introduced in AIX version 5 and thanks to the AIX Toolbox for Linux Applications a certain set of open source tools kind of a core set of some of the most common tools like development tools and libraries are available in rpm package form like Curl, Samba and PostreSql tools, sed, mutt.

I left a link in the show notes so You can check for yourself if Your favourite tool is included or not.

SMIT – System Management Interface Tool

SMIT – System Management Interface Tool – The initial menu, when running in text mode

SMIT is the System Management Interface Tool for AIX. It allows a user to navigate a menu hierarchy of commands, rather than using the command line. Invocation is typically achieved with the command smit. Experienced system administrators make use of the F6 function key which generates the command line that SMIT will invoke to complete it. SMIT also generates a log of commands that are performed in the smit.script file. The smit.script file automatically records the commands with the command flags and parameters used. The smit.script file can be used as an executable shell script to rerun system configuration tasks. SMIT also creates the smit.log file, which contains additional detailed information that can be used by programmers in extending the SMIT system.

smit and smitty refer to the same program, though smitty invokes the text-based version, while smit will invoke an X Window System based interface if possible; however, if smit determines that X Window System capabilities are not present, it will present the text-based version instead of failing. Determination of X Window System capabilities is typically performed by checking for the existence of the DISPLAY variable.

Object Data Manager (ODM)

Object Data Manager (ODM) is a database of system information integrated into AIX analogous to the registry in Microsoft Windows. A good understanding of the ODM is essential for managing AIX systems.

Data managed in ODM is stored and maintained as objects with associated attributes. Interaction with ODM is possible via application programming interface (API) library for programs, and command-line utilities such us odmshowodmgetodmaddodmchange and odmdelete for shell scripts and users. SMIT and its associated AIX commands can also be used to query and modify information in the ODM.

Example of information stored in the ODM database are:

  • Network configuration
  • Logical volume management configuration
  • Installed software information
  • Information for logical devices or software drivers
  • List of all AIX supported devices
  • Physical hardware devices installed and their configuration
  • Menus, screens and commands that SMIT uses

My experience with AIX

Zero, Null, Nothing. – AIX Community is much smaller in size than for example Linux and it reminds me more of a secret society with a lot of Secrecy. For a newcomer it is pretty much impossible to get any exposure to it or any experience with it and sometimes even harder to find someone who is willing to help you to start your journey with AIX.

People who helped me from the AIX Community and to whom I am grateful for their support

I want to give special thanks to Andrey Klyachkin from power-devops.com who helped me to get up and running with a small AIX server on the cloud in a matter of hours. Andrey has a vast experience in AIX administration and he is a very pleasant person to talk to.

Please check out his website at power-devops.com (link in the show notes) as he most probably be able to answer your questions regarding AIX operating system and using devops tools on it.

AIX Community and Literature

There are some articles on the web about AIX and some great sites too like http://aix4admins.blogspot.com/ You can also go to reddit at /r/aix but I found it to be mostly for people who has already experience with AIX and have all the required access to the tools and utilities required.

I have to say that because of the size of the AIX Community and the slightly reserved nature of most of its members I came across it is not a very easy task for a newcomer to get acquintance with AIX Operating System and be up and running in no time and as easy as it might be with other distributions like Linux.

I was particularly unlucky as I came across a used AIX server on a secondhand website here in Spain two times from two different sellers but both of them went AWOL on me after we have agreed on the price and a local pickup. 🙁

Therefore up until this day I have stayed without owning a physical Power Architecture Server to run AIX 7.1 or 7.2 on my own in my homelab. (( I am not giving up just yet ))

While there are limited amount of literature out there about AIX in a form of books when compared to Linux, AIX well IBM has something up its sleeve which might give them the upper hand.

IBM Redbooks. IBM Redbooks content is designed to help you learn, adopt and deploy solutions. Their offerings include brief documents, books and videos. And best of all — they’re available at no charge.

While IBM Redbooks aren’t meant to replace IBM manuals or the IBM Knowledge Center. Instead, they offer practical technical information that’s not covered in product manuals.

One of the advantages of IBM Redbooks publications is that you can start learning anytime, anywhere. Redbooks are available for immediate download in PDF and EPUB format, and on-demand printing is available for those who want to read a hard copy.

IBM Redbooks cover IBM and Red Hat solutions as well as third-party and open-source technologies. You can learn about OpenShift on IBM Z and Power, open source IT operations management, security features in IBM Z and LinuxONE, cloud object storage, SAP HANA on Power Systems, agile integration, and so much more than just the AIX Operating System.

I linked one in particular regarding AIX 5L which can come handy to start to learn more about AIX and build upon as you progress further later on.

Get Your Hands on IBM AIX

While there are not really *free* ways to get your hands on AIX there are cloud solutions if you have and wish to spend money and try out AIX.

One of the cheapest and best combination would be to sign up for IBM Cloud account upgrade it to a Pay-As-You-Go Tier and use the welcome voucher 200$ (expires in 1 month) to run an AIX virtual machine until your money runs out with Skytap on IBM Cloud (also available on the Azure Marketplace) or Power Systems Virtual Server offering from IBM Cloud.

IBM Cloud accounts comparison

I recommend that you apply Skytap‘s welcome voucher which is valid for 90 days worth of 500$ to run AIX Virtual Machines for another 3 months after the initial IBM voucher of 200$ rans out using the Power Systems Virtual Server offering. (( I can not confirm if this is something You can do ,,applying the 500$ voucher of Skytap after the 1 month 200$ credit rans out from IBM Cloud ))

Both solutions runs your AIX Operating System as a full virtual machine on an IBM Power Server.

Estimated Price with Power Systems Virtual Server on IBM Cloud

Estimated Price for a shared Scale Out (S922) HW running shared 0.25 vcpu (1 physical core equals 4 vcpus on this HW) with 2GB of Ram and 20GB of Tier 3 Storage for Frankfurt 1 DC Region estimates before taxes and/or any discounts at 44.56 Euros per month.

If you plan to use the VM let’s say 5-6 hours in total per week then in a month your cost will be very little as per these estimates ( around 3-5 euros perhaps)

Estimated Price for third party solution from Skytap on IBM Cloud

Skytap on IBM Cloud VM Control Panel

Estimated usage cost in EMEA Region which is applicable for me for 1x Power based VM for 5 hours per week x 4 = 20 hours a month runtime with 2GB Ram and10GB Storage with 1x CPU set to Entitled Capacity of 0.05 capped/can not go over would be charged around:

Skytap Cloud Power RAM: 20hrs x 2GB x $0.065 = $2.60
Skytap Cloud Storage (persistent): 730 hrs x 10GB x $0.00011 = $0.80
Total: $3.40 per month (i guess its before taxes)

This is very affordable if You want to learn about AIX and when You have some limited time to tinker with it and You do not require it to run 24/7 as most of us hobbyst/homelabbers do not.

Both Skytap’s on IBM Cloud offer and IBM’s Own Power Systems Virtual Server are priced similarly but Skytap seems to have more options to modify / interact with Your Virtual Machine ( boot from a supplied iso you upload to your assets and do an upgrade for example)

Physical hardware

Another option is to purchase some older Power architecture hardware from sites like ebay but I tell you they are not cheap. Most of the time they come wiped without any OS Install discs and even tough You can try to contact IBM representative to obtain install discs for your ,,new” server via its model/serial number it is not always easy without having an actual support contract but your mileage may vary on this.

Also as much as I understood some features come either baked in or not ( activated or not) on your hardware from the factory so its always worth checking out what physical and SW entitlements your server is equipped with. I have limited knowledge here as I do not own any Power architecture server myself.

This path can be interested to some how want to learn and explore features of AIX which can only be explored on bare metal Vs a Cloud virtual machine like IBM AIX’s PowerVM (formerly known as Advanced Power Virtualization) which is a form of para virtualization technique. As far as I can see the server has to come with this enabled from the factory and there is 3 separate editions of it (IBM PowerVM Express/Standard/Enterprise) and it is one of the features I would look for and make sure it exists on the server I am ready to purchase.

PowerVM is available on POWER6 and higher servers.

IBM PowerVM Editions
IBM Power 750 8233 e8b 4x CPU 6-Core, 256 GB RAM

Closing Thoughts

With the advent of Cloud infrastructure it has become easier to get experience with technologies previously unavailable or reserved just to a selected few like IBM’s AIX Unix.

You do not have to purchase expensive hardware and worry about electricity cost and noise if You can make a few compromises coming from the nature of Virtual Machines Vs Physical Hardware.

The running costs of a small Unix server with AIX on the cloud is more affordable than it ever was.

However I still believe that it is necessary that companies like IBM gets rid of old habits and opens towards the community of enthusiasts or hobbyist/homelabbers whom are willing to learn and experiment with Operating Systems like AIX or z/OS in their free time for their own benefit and perhaps to others benefit such as their employer without hurting corporate profits or business intentions in the process.

When corporations like IBM turn themselves away from these insignificant customers who can not afford the license fees and support contracts big enterprises do, what they tend to forget that some of these individuals might be the future C-level or mid-level decision makers.

When the day comes from 12 days or 12 years from now and they need to make a professional recommendation to a platform or a product to implement at their workplace they might not choose your product if they do not know it exists or they have never had any experience with it.

One thing I know for sure is for me to professionally recommend something it has to fit into the below requirements:

  • to know and be familiar with the tool or solution
  • to have a good experience with the brand or corporation who’s offering it
  • to know that it exists (tool , solution , operating system, etc.)
  • to be fit for the requirements

While solution X might tick off 1 out of 4 requirements on my list it is certainly not enough.Not even close.

Let alone if I am not even familiar with it or never had the chance to be exposed to that technology or solution. Now imagine if I even had a bad customer experience with it.

Hobbyst, Homelabbers are no way considered free-riders or someone who eats away corporate profits in my understanding. They are willing to take the thier time for free to use and familiarize themselves with a product or solution of company X. not just for their benefit but perhaps one day for a corporation’s or client’s benefit in the not so distant future. They might or might not be the next C-level decision makers but perhaps the one’s the C-level executive turns to for their opinion and knowledge after a sales representative made its pitch at them.

And seriously what damage a guy with a 42U rack and some used hardware can do from his basement running anything no matter how mission critical that piece of software is being it z/OS or AIX or OpenVMS or HP-UX?

Rule of thumb:

Treat me like I was the C-level executive You wish to present your sales pitch tomorrow.

Viktor Madarasz


Andrey Klyachkin’s power-devops.com website

AIX for System Administrators
Practical Guide to AIX (and PowerVM, PowerHA, PowerVC, HMC, DevOps …)

HT-1080Z School Computer

Video Genie

IBM AIX PS/2 1.3 for Intel i386 in Virtual Box

Skytap 500$ welcome voucher valid for 90 days for new IBM Cloud users

IBM Power and AIX

IBM Redbooks – Example AIX 5L

AIX 5L release notes



AIX Toolbox for Liux Applications

Open Software Foundation

AIX & Qemu ( for the ones who would like to have some fun )
( in my opinion somewhat working and slow performance compared to the VM offerings in the cloud I have explored but nevertheless can be a fun experiment or spend time activity)

Andrey Klyachkin – Install AIX 7.2 in Qemu