The document discusses Plan 9, an innovative operating system developed at Bell Labs by key figures in the creation of Unix. While retaining some Unix features, Plan 9 introduces significant advancements in scalability, networking security, and resource management through a unified protocol (9p) that treats all resources as files. Plan 9 is primarily used by researchers for advanced computing tasks and offers a unique windowing system called 81/2, distinct from traditional Unix environments.

1. Plan 9: Bad Movie, Good Operating System
Quentin Fennessy
First published: Plan 9: Bad Movie, Good Operating System ACM Computer 29, 5 (May 1996), 117-
119,121-123. http://dl.acm.org/citation.cfm?id=620458
Update as of March 2016: This is an old article and facts, links, contact information and the world
itself has changed significantly. Read this out of historical interest – look elsewhere for current
information on Plan 9. Reformatted, citations updated and some graphics tweaked for readability.
Qfennessy@gmail.com (formerly qpf@io.com)
The plan was to build a UNIX out of a lot of little systems, not a system out of a lot of little UNIXes.
Plan 9 is a new operating system from Bell Labs. Some of the original developers of UNIX took
advantage of what operating system developers dream of -- the chance to build a new system from
scratch. Plan 9 addresses issues including system scalability, secure networking, and efficient use of
system resources. The system called Plan 9 may be called a clean sheet design, with all the plusses
and minuses that entails. The name was chosen in the Bell Labs tradition of making marketeers
wince (Plan 9 from Outer Space is supposed to be one of the worst movies ever made).
Recently AT&T (now Lucent Technologies) made Plan 9 available to the general public. For $350 you
can purchase a CD-ROM containing Plan 9 sources, binaries for several architectures including Intel
386, MIPS, Next and SPARC, and two books. The two books contain manual pages and a set of
papers describing many of the features and utilities in Plan 9.
I installed Plan 9 on a few Pentium PCs. This experience combined with readings of the Plan 9
papers and manuals, and conversations with some of the developers helped me write this review.
Plan 9 will be reviewed here primarily in comparison with UNIX so a good working knowledge of UNIX
is essential.
Who created Plan 9 and why?
If you had to pick a group of folks to create a next-generation operating system you could not do
much better than the folks that work in the Computing Sciences Research Center at Bell Labs (now
part of Lucent Technologies, previously AT&T Bell Labs.) Ken Thompson and Dennis Ritchie created
UNIX here. Ritchie is known as the creator of the C programming language. Perhaps because of
Thompson's and Ritchie's reputations Bell Labs has collected an impressive group of computer
scientists. Some of these scientists created the operating system called Plan 9. Among them are Rob
Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom and Dennis Ritchie.
The creators of Plan 9 took this clean-sheet opportunity to revisit issues raised by the evolution of
operating systems, networks and computer technology in the years since UNIX was born. UNIX as
initially created provided a platform for computer programming and typesetting. It grew in both utility
and capability over the years to become a system that was used for a wider set of problems.

2. Unfortunately, the initial design of UNIX did not take into account either networking, security or
authentication, or graphics. Of course these features were grafted on over the years in various ways
by many different people, but they were not well integrated with the core principles of UNIX.
Plan 9 does not abandon all of the successful features of UNIX. Here are some similarities between
the two systems:
• Both are written in a high level language--C.
• Both have a simple and powerful user interface--the UNIX shell has been refined in Plan 9.
• Both use a hierarchical file system. Plan 9's file system is similar in appearance to UNIX.
• Devices are available using names in the filesystem.
• Both have names that are slightly unusual.
Plan 9 does not cling to compatibility for auld lang syne. Here are some differences between the two
systems:
• A Plan 9 terminal almost requires a windowing system (called 8 ½) to be useful.
• A Plan 9 installation that takes advantage of the system's strengths is not a single
standalone machine, but instead a collection of general and special purpose machines
connected by various networks.
• Plan 9 authentication is network-secure, with no plaintext passwords on the network.
• Plan 9 can effectively use one-time authentication methods. It appears some of the lessons
of Kerberos (MIT's network authentication service) have been integrated with the core of Plan
9.
• A Plan 9 system may have several simultaneous users, but each user will have a personally
customized view of the filesystem (called namespace in Plan 9).
• Plan 9 uses an ASCII compatible version of Unicode for its character set. This allows use of
several distinct alphabets.
• All access to computing resources is handled via a single protocol called 9P. 9P allows a user
to treat remote devices such as disks, network connections or special purpose hardware as
local.
What is Plan 9 used for?
Approximately 40 Bell Labs researchers use Plan 9 (actually its successor called Brazil) as their
regular computing environment. This means they use Plan 9 for text processing, electronic mail,
program development and computer science research among other things. There are researchers at
other universities such as University of Toronto, University of York and Sydney University who use
Plan 9 for their own work. Uses include filesystem research, queuing algorithms, multimedia and
program development.

3. A Hypothetical Plan 9 Environment
FIGURE 1 HYPOTHETICAL PLAN 9 ENVIRONMENT
Plan 9 installations may vary considerably. The simplest case may be a single PC running as a
standalone machine. At the other end of the spectrum is the environment at Bell Labs where the
users have Plan 9 terminals on their desks, use powerful cpu servers over the network, and store
files on a massive Plan 9 fileserver.
A basic setup that demonstrates many features of Plan 9 might look like this: Say there are 6
researchers in a group. Each researcher has on her desk either a 486 PC with 16MB of RAM or a
68040 Nextstation running Plan 9 code. These are called terminals in Plan 9. Researchers store files
on a Sun SPARCstation 2 fileserver with 128 MB of RAM and 8GB of scsi disk. They use two cpu
servers, both 133Mhz Pentiums with 64MB of RAM. Plan 9 authentication is handled by an old 386
PC with 8MB of RAM. Dialup PPP is provided by another 386 PC with 8 serial ports also running Plan
9.
These systems are on an Ethernet that is connected to the Internet. The researchers in this lab work
free of worry that someone may break into their machines. The fileserver and cpu servers will only
communicate with authenticated clients. The terminals do not export any services. The researchers
run web browsers, editors and electronic mail tools on their terminals. They run heavier jobs such as
compilations and simulations on the cpu servers.
This hypothetical case shows one-way Plan 9 systems may work together well. Say the department
hires 2 more researchers -- they could configure the two Pentium PCs as terminals and purchase 2
faster systems as cpu servers. These recycling options where older and slower machines are still
useful means computing resources may be used very efficiently. Upgrades and new hardware may
be optimized for specific problems rather than having to handle every sort of task. It may be perfectly

4. reasonable for a cpu server to be installed that is lousy at disk IO -- cpu servers do not need to be
good at disk io.
Plan 9 Basics
At the heart of Plan 9 is a protocol called 9P. This protocol enables Plan 9 to treat all computing
resources as files and to make these resources available to local and remote computer users. 9P
may be compared to a protocol such as NFS. NFS allows clients to access plain files on networked
file servers. NFS does not allow access to device files, and NFS may not be used to access local files.
Therefore, a UNIX kernel needs to know several methods to access files: NFS for remote files,
kernel-installed filesystem code for access to local files and devices. There is no way for an NFS
client to access remote UNIX devices using filesystem access methods.
A Plan 9 system uses 9P to access all files. A Plan 9 process uses filesystem semantics to access
almost all computing resources. Therefore, the only protocol a Plan 9 server needs know is 9P. 9P is
implemented for local access with kernel procedures and remotely using RPC over a protocol called
IL. IL is built on top of IP (Internet Protocol, c.f. TCP/IP) and provides reliable delimited message
service. IL was created as part of Plan 9 because the existing suite of IP protocols did not provide
what 9P needed.
A process in Plan 9 has a namespace. The UNIX analog is the filesystem - that is, a UNIX process may
read and write files in whatever filesystems are mounted on that machine. Plan 9 differs from UNIX
in that Plan 9 processes on the same machine may have completely different namespaces.
The Plan 9 namespace is rooted at / like a UNIX root filesystem. Conventionally there is a directory
called /bin that is a union of all directories that contain Plan 9 programs the user might want to run.
/bin usually combines a directory of shell scripts with a directory of architecture specific binary
programs. It may also include more directories such as a personal directory of shell scripts or
binaries. This way /bin obviates a user’s shell PATH. Directories may be united in various ways to
provide the correct search order. The user shell only has to search one place to find programs to
execute.
On a UNIX system the file /dev/tty always refers to the device through which a process is
connected. Therefore /dev/tty is unique per user -- the same name means different things to
different processes. In spite of the possibly confusing fact /dev/tty is a useful concept. Plan 9
expands on this concept. UNIX's /dev/tty is hardwired into the kernel. Files in the Plan 9
namespace are possibly all unique per process or process group although in practice many are
shared.
UNIX System V Release 4 and other variants have a /proc filesystem. This allows filesystem access
to processes for programs like debuggers or ps. Plan 9 uses this idea as well. Under Plan 9 there is a
device called #p which is bound to the directory /proc. Under /proc there are files with decimal
numbers as names, corresponding to Plan 9 processes. Typically, all processes on a Plan 9 system
see the same /proc directory. So for example for process 345 there are directory entries such as
this:

5. Filename Contents
/proc/345/ctl Control of process (stop, start, etc.)
/proc/345/mem Process memory image
/proc/345/status ps(1) like status information
/proc/345/text Reference to the file from which the process was executed.
/proc/345/note File to which notes (signals) are written.
The existence of these files means access to status and control of a process is handled by reads and
writes from files. For example, each process has a status file. Ps could be implemented via a shell
command that did this:
% cat /proc/*/status
The example of the ctl file demonstrates another Plan 9 convention -- that reads and writes to files
are done with text messages. Rather than use binary message formats some performance is
sacrificed in order to gain a simpler interface and more network portability. There are no network
byte ordering issues when messages are sent as text.
Another example of a UNIX feature implemented in Plan 9 is the process environment. To bind it to a
namespace a command like this might be run:
% bind '#e' /env
Under Plan 9 most processes will have distinct /env hierarchies (although child processes may
share their environment with the parent process). Then a process with 3 environment variables
might have these files under /env:
Filename Contents
/env/user quentin
/env/pid 345
/env/prompt '% ' '<TAB>
So to list all environment variables something like this might be run:
% (cd /env; echo *)
These examples demonstrate that system services are provided as devices available in the
namespace (filesystem). Other examples of services provided as devices are pipes, dup, STREAMS,
serial communications, and a SCSI interface. This means that often a shell script is sufficient for
debugging or configuration purposes.
Not only are system services provided as devices, some services such as FTP are only provided as a
filesystem! There is no shell command called ftp. Rather there is a command called ftpfs. When
called like this:

6. % ftpfs -a quentin@delrio plan9.att.com
This would cause an anonymous FTP login to be made to the machine plan9.att.com using the
password quentin@delrio. A filesystem would be mounted on /n/ftp. Below that directory would
be the hierarchy of files available to the anonymous user logged into ftp.plan9.att.com. Rather
than using an FTP client with its own little command structure a user can use familiar shell
commands to manipulate files. For instance, a user may retrieve a file called readme.ps with these
commands:
% cd /n/ftp/plan9/doc
% cp readme.ps $home
There are similar user-level fileservers for tar and cpio files -- say a user had a tar archive file
called project32.tar which contained some C source files. They could investigate the contents by
running these commands (sam is a Plan 9 editor):
% fs/tarfs project32.tar
% cd /n/tapefs/src
% sam *.c
UNIX traditionally offers one type of process while more modern systems tend to include other types
of threads of control, sometimes called threads or light-weight processes. Plan 9 has eschewed the
idea of different types of processes. Instead it offers different ways to create new processes. The
Plan 9 system call rfork is similar to the fork system call from UNIX. rfork returns twice, one to
the calling (parent) process and once to the newly created child process. Unlike fork, rfork takes a
bitmap argument that defines how resources will be shared between the two processes. These
options include the capability of sharing, copying or clearing the namespace, the environment or the
file descriptor table. Plan 9 developers call this technique a success as it allows efficient use of
resources while keeping the kernel relatively simple.
In order to use a Plan 9 cpu server (say one called laredo) for a large compilation one might type
this command while logged into a Plan 9 terminal and running 8½:
% cpu -h laredo -c (cd $home/src; mk)
This would run the command within parentheses on laredo, in the same namespace as the Plan 9
terminal. This combines advantages of NFS (where remote disk is made available) with the
advantages of rsh and rlogin (where remote cpu is made available).
If you run Plan 9 on a network that includes UNIX systems a simple command makes UNIX files
available to Plan 9. (The UNIX system must be running a Plan 9 compatible server, available with the
Plan 9 distribution).
There is no concept of a privileged user in Plan 9. Files that reside on a fileserver are made available
only to authenticated users. Plaintext passwords are never passed over the network.

7. Plan 9 Applications
Plan 9 offers several familiar and several new applications. Old friends include troff, awk,
ghostscript and TEX. New offerings include 8½ (a window system), acme (an editor/programming
environment), acid (a debugger), rc (a shell), mk (a make equivalent) and sam (an editor.) Below I
have tried to do justice to some of the new approaches taken in the new tools.
8 ½
8½ is a minimalist window system. It has a small and powerful set of features that allow window
operations to be handled quickly and easily. It is fair to compare the combination of Plan 9 and 8½
with the combination of UNIX and the X Window System. 8½ lets you manage several windows on
the screen at once, running local and remote programs. These programs may be text based such as
the editor Sam, or the programming tool acme, or graphical programs such as a postscript viewer.
FIGURE 2 TAKEN FROM 8 ½, THE PLAN 9 WINDOW SYSTEM. USED WITH PERMISSION.

8. It is also fair to contrast 8½ with X. 8½ is a tiny program relative to X, with little of X's please-
everyone, policy-free implementation. Often X user interfaces are specified so as to be usable with
just a keyboard. I do not believe 8½ is usable without a three button mouse, keyboard and
bitmapped display.
From a user point of view, the 8½ screen is a normal windowing environment. There are no icons --
windows may be hidden and quickly retrieved from a menu. Windows may be easily created, resized
and moved. The typical 8½ runs the Plan 9 shell rc in it. rc (discussed later in this article) offers no
command history recall or editing features. Instead 8½ allows a user to edit any text on the screen
and execute it as a command. Say you mistype a long command line -- rather than asking the shell to
redisplay the command a user can use mouse and keyboard commands to fix the error and then use
the mouse commands snarf to capture the command line and send to cause the corrected line to
be re-executed.
8½ differs from other system in other details -- there are ways to delay a process from reading input
even when that input includes several newlines. Once the input is complete 8½ may be allowed to
read the input. This allows mail messages to be composed and edited in a window without using an
editor.
8½ is more than just a window system -- it is also a fileserver. In the programming model of Plan 9
where fileservers are easy and natural interfaces a program may interact with 8½ by reading and
writing device files. Say a process is running within a window and needed to access mouse activity. It
would do so by reading the device file /dev/mouse. /dev/mouse is unique to each window -- if the
mouse has moved (and the window is active) then the read returns a few bytes describing the state
of the mouse and mouse buttons. There are also devices such as /dev/cons which provides
keyboard input a line at a time, /dev/rcons for character at a time input, and /dev/window for the
bitmap of the whole window. /dev/screen is global for all of 8½ and allows a process to access
the bitmap of the 8 (Fennessy, 1996) (Fennessy, 1996) (Fennessy, 1996)½ session. The Plan 9
kernel has no tty driver as in UNIX -- all sophisticated user input must be handled by applications
such as 8½.
8½ offers the capability to run a copy of itself within one of its windows. This allows a user to connect
to a remote cpu server within a window and run 8½ from the cpu server. With this method all
processes would naturally run on the cpu server.
8½ is speedy -- windows are created and deleted in less than a second on normal PC hardware. It
has a different look and feel than X or Microsoft Windows in that no effort has been expended to
make it pretty, no icons are used, and the mouse is used for far more than just running programs
from icons. As you can see from the picture of an 8½ session it is very sparse in its look. (included
with permission from 8 ½, the Plan 9 Window System by Rob Pike). There is a UNIX clone of 8½
called 9wm, with a terminal program called 9term. Information on 9wm and 9term is available on the
Plan 9 web pages.
Acme
It is difficult to describe acme succinctly. Essentially Pike has tried to make this windowing
environment as transparent to the user as possible. Windows are created easily (one mouse click)

9. and positioned automatically. acme windows are displayed tiled in 1 or more columns. Each window
has a header or tag and a body. The header typically has a file or directory name and a small list of
words. These words may be selected with the mouse and used as commands. Any text on the screen
may be used as a command, a file to open, a string to search for, or a directory to list. The list of
words in the tag changes dynamically -- the Put or save command will not appear until a file has
been altered. The Look or search command will not be displayed unless there is a file open in that
window -- Look does not make sense if that window has a directory listing in it.
FIGURE 2 FROM ACME: A USER INTERFACE FOR PROGRAMMERS. USED WITH PERMISSION.
Text in these windows may be used in several ways depending on the mouse operations chosen and
the context in which that text was found. In some cases, a selected piece of text will be used as an
argument for a search function -- select some text, select Look from the mouse button 2 menu and
acme will display the next place in that file where the selected text was found. In other cases,
selected text may be used as a file name, and the appropriate action (Get) will cause a new window
to be created with that file opened in it for viewing or editing. Text may be executed as commands
with the Send operation. Windows may be resized and moved with simple mouse operations.
Acme takes a bit of getting used to. Few programs use the mouse and keyboard together to this
extent. Acme ran blazingly fast for me -- no operation other than loading very large files took long at
all. Even searching in large files was virtually instantaneous. I found acme very useful for browsing

10. source trees while trying to understand some Plan 9 operations. I did not end up using it for much
editing as I was more comfortable with Sam, but I believe practice with acme may vindicate the bold
idea of combining window system, shell and editor. Acme has a UNIX clone called wily. Information
on wily may be found on the Plan 9 web pages.
Acid
Acid is a programmable symbolic debugger and is remarkable in that rather than offering a small
set of debugging commands it offers a small set of programming primitives from which arbitrary
debugging operations may be built. Acid may debug running or defunct processes or may initiate a
program run and control its execution.
The paper describing acid (Acid Manual by Phil Winterbottom) admits to a forbidding user interface -
- a prompt at which acid statements may be entered. Despite this interface there are interesting
possibilities in automation of testing and debugging -- acid could be used to test applications from
the inside out. Most test tools are restricted to feeding a program input and checking output. Testing
with acid could not only handle input and output, it could check process state.
To offer a taste of acid here is a code sample (taken from the acid manual page) that walks
through a linked list and displays values:
% acid
acid: complex Str { 'D' 0 val; 'X' 4 next; };
acid: complex Str s;
acid: s = *headstr;
acid: while s != 0 do {
print(s.val, "n");
s = s.next;
}
acid:
Acid takes advantage of the /proc filesystem. It manipulates the state of the process by writing to
the ctl and note file, and reads the state of the process from the mem and text file. The acid
command language is independent of the language of the program being debugged. It is a shame
that the tcl language could not be used here -- John Ousterhout has created the Tool Control
Language (tcl) and implemented it as a C library that can be easily linked with other applications.
The value of tcl is that several applications can have similar rather than unique command
languages. Of course, tcl is a UNIX utility but I suspect it could easily be ported on Plan 9.
Mk
Mk is the Plan 9 replacement for the UNIX make utility. Mk is used to build programs efficiently
through an understanding of the relationship of various source, include and library files that
comprise a program as defined in a source file called a mkfile. If you are familiar with make, then
mk will not appear strange.
Mk has facilities and conventions that enable Plan 9 programs to be built easily for several system
architectures. There has been a lot of thought put into making mk useful and powerful in a multiple
architecture environment. Mk makes good use of template files that standardize different types of

11. builds. There are templates for each architecture that should be included in each mkfile. For
instance, to build an executable for one architecture a mkfile includes the template file called
mkone. To build executables for several architectures in a single directory a mkfile includes the
template mkmany. In simple cases creating a new mkfile involves very little new work because of
the templates.
Mk shows that there are elegant ways to support program development across platforms. Little or
none of the value of mk is Plan 9 specific. For vendors such as Microsoft, Sun Microsystems or the
Free Software Foundation whose products are sold for several platforms mk could be very useful.
Rc
The standard shell in Plan 9 is rc, rather than the traditional Bourne shell sh. Rc is functionally
equivalent to the Bourne shell. The user command line syntax is very similar to sh and UNIX users
will have little trouble with it. The programming syntax is different.
Rc variables are all implemented as arrays of strings rather than single strings. A UNIX PATH
environment variable has a value that is a string that comprises a list of directories separated by
colons. An rc path variable (not really necessary) is an array of strings, each of which is a directory.
This allows direct reference via subscript to the different values.
The Bourne shell concatenates variable simply -- $foo$bar is the concatenation of the values of foo
and bar. Rc concatenates with a new (actually recycled) operator, the caret ^. So $foo$bar is the
simple concatenation. A more powerful use of this is when lists are combined: if $src is a list such
as (pcfs) and $ext is a list such as (.c .s .a .o) then $src^$ext evaluates to (pcfs.c
pcfs.s pcfs.a pcfs.o).
Lists can be built from the output of other commands, similar to the command substitution of sh. So
when fred, ann, peter and don are logged in a command line like
% users=`{who}
means that $users is a list of (fred ann peter don).
Plan 9 processes may exit with a string as their exit status, rather than the small integer of UNIX. Rc
captures this in $status (similar to the $? in UNIX).
Rc provides for and while loops, if statements, switch (case) statements, and other
conventional shell features. It also provides sophisticated access to the Plan 9 rfork system call
where the new forked processes may share or not various resources with the parent processes. Rc
also provides access to arbitrary file descriptors.
Rc does not provide either C-shell or Korn shell like command recall and editing. Rc does nor provide
access to the X Window system library. Rc does not have an emacs facility, or file name completion.
The combination of Rc running in an 8½ window makes many of these facilities redundant (except
for filename completion). Rc does provide simpler quoting rules than many other shells. Similar to
tcl, input is only scanned once. This means nested quotes and nested command substation have a
much more graceful syntax. The end result is a shell that is easy to use and useful for shell scripts.

12. There are two versions of Rc reimplemented for UNIX systems, one called Rc and one called es
(extensible shell). Information on both can be found on the Plan 9 web pages.
Sam
Sam is called the standard editor of Plan 9, much as ed is the standard editor for UNIX. It is
developed for use under a window system that uses mouse and keyboard for input, and a bitmapped
display for output. Of course in Plan 9 that window system is 8 ½. There is a version of Sam available
for UNIX systems as well, with information and source available at the Plan 9 home page.
Sam can edit several files at one time. Text can be selected, cut, pasted and searched for via mouse
commands. Files may be opened, written and closed with the mouse. There is a textual command
language in the tradition of ed, expanded to allow more sophisticated editing. This language allows
editing single and multiple files with single commands. Sam uses regular expressions as used in
egrep with some small additions.
Sam has the same online help facilities as ed. Sam is implemented in an interesting way -- there are
two cooperating processes. One manages the display and the other the host functions (file access,
etc.).
Sam evolved from an editor called jim that ran on terminals called Blits which had limited cpu.
Because of this the two functions were split. Sam is designed to work reasonably well even when the
two processes are connected by a low-speed link. Of course Sam works well on a single host or on
hosts connected via high-speed network.
While unique, the command language of Sam is no more obscure than other UNIX editors such as vi
or emacs. It has the virtue of being designed deliberately rather than evolving via the work of several
people. Therefore, the language is complete and consistent. It may be too complete as the author
admits that few users actually use or know all of it.
Both the Plan 9 and UNIX versions of Sam are fast and useful programs. I admit to having vi trained
fingers and so when confronted with an editor that allows no keyboard control of cursor movement I
have a hard time being productive. I like many features of Sam, especially the mouse interface and
the ed-like syntax. I think if I could somehow use the keyboard for cursor movement then Sam would
be my editor of choice.
My Experiences
The Plan 9 papers include a document on how to bootstrap your Plan 9 environment using a PC. I
was able to do so using two Pentium systems, both with 16MB of RAM and 1GB of SCSI disk. The
instructions are complete to a fault -- they are obviously written for someone with little PC or DOS
experience. DOS itself is used in the installation process, and as a loader for a real operating system
DOS does a fine job. The full (CD-ROM) installation requires 500MB of free disk. Plan 9 does not
obey PC conventions for partitions and operating systems. I only experimented with the simplest
case but I suspect there are obstacles for users who wish to run several sophisticated operating
systems on one PC including Plan 9.
My first installation went exactly as the instructions predicted. I ended up with a full Plan 9 system.
Unfortunately, my VGA card (Trident 8900 based) was not supported and so I was not able to use it

13. at its highest resolution. VGA support is obviously a sore spot with the Bell Labs folks -- the devices
differ enough that it is difficult to support every VGA device. There are several VGA devices that are
supported but unfortunately I did not have one of them.
After adding an account for myself and logging in the first thing I noticed was that the 8½ windows did
not scroll. Fortunately, I found the –s argument to 8½ that set the windows so that text scrolled off
the screen and I could use a pager or the scroll bar to read large files. I did not like the default font
as I had only a 14" monitor. I was able to find a slightly smaller font that met my needs. I believe the
default font would be fine if I were to have used a reasonably sized monitor.
My Ethernet card was not recognized at boot time. I decided to dive in and try to figure out why. I ran
acme on the source tree and looked around for network card support. I found it easily and searched
the file -- the code that configured the 3C509B card looked straightforward so I added a few print
statements and rebuilt the kernel. I booted from the kernel but could not figure out why the card
would not work. (The same card had worked fine under BSDI). Fortunately, I was able to find help in
the Usenet newsgroup comp.os.plan9 and one of the folks from Bell Labs pointed out that the
3C509B card did not work while the Plug-N-Play feature was enabled. I ran the DOS configure
program for the Ethernet card and my problem was solved.
The first network program I ran was ftpfs. Plan 9 has no ftp command -- instead ftpfs
establishes a connection to an FTP server and offers the files on that server via a filesystem. Ftpfs
worked well as a demonstration of a synthetic filesystem for user programs.
The next step in sophistication for a Plan 9 network is to install a Plan 9 fileserver. I had a similar
Pentium PC to use and I tried to install the fileserver code there. Unfortunately, the fileserver code as
delivered on the CD-ROM has a problem with fast systems. I was advised by the very helpful Plan 9
community to download some patches and I was able to boot the fileserver. Fileserver installation is
somewhat peculiar: First you install Plan 9 on a PC as I had. Second you boot the system you wish to
be a fileserver from a Plan 9 floppy. Then you convince the fileserver to load the contents of the Plan
9 CD-ROM from the first Plan 9 system over the network. Peculiar yes, but it worked as advertised. I
had a fileserver after a few hours of waiting.
In order to use Plan 9 network authentication, I had to install an authentication server. The
instructions detailed how to configure the first system as a combined CPU and authentication server.
I followed the instructions and was able to establish an authentication domain. After a few more
steps I was able to boot the CPU server from the fileserver across the network. The network boot
process for my small set of systems was never painless because I never installed a Plan 9 bootp
server. This meant I had to type in some values each time the CPU server booted. Nevertheless, it
worked well.
I did not benchmark the system but I did some seat-of-the-pants performance testing. I compiled
several programs using the networked Plan 9 disk. Performance for these compilations was
comfortably speedy. (The two systems communicated across an unloaded 10Mbit/sec Ethernet).
The manual pages were accurate and occasionally humorous. Typing vi never did what I expected. A
reading of the manual page for emacs was instructive in understanding some of the designers
prejudices. The Bugs section of the yesterday manual page is as accurate as any I have ever read.

14. Unfortunately, my access to that Plan 9 lab ended and so did my experiments. I hope to find
resources to be able to learn more of Plan 9 and to use it to experiment with some network security
ideas. I imagine that a Plan 9 system may be able to efficiently route IP according to policy set by a
user program.
Program Development under Plan 9
Plan 9 is written in C. There are several facilities and conventions that make supporting a multi-
architecture Plan 9 environment relatively painless. Mk has been described elsewhere in this article.
Plan 9 generally supports cross-compilation, so if you develop on a SPARC cpu server you can build
MIPS and Intel 386 executables. Each architecture has its own C compiler, named according to that
architecture so you are not lost in a sea of cc's. For example, the Intel 386 C compiler is called 8c,
and the SPARC C compiler is kc. Similarly, the assemblers are named 8a and ka. The current target
machine type is stored in the environment variable $objtype (also available as /env/objtype -- try
cat /etc/objtype as an equivalent to echo $objtype!) The machine on which the compilation
is being run is stored in $cputype.
C under Plan 9 is ANSI C with some extensions, a slightly different preprocessor, and better (than
UNIX) organized libraries and include files. Conditional compilation is not supported with #if
statements. Each application includes u.h. Each library has a similarly named include file -- if you
use the library called libc.8 then your program will include libc.h. A refreshing reorganization
from traditional UNIX.
To aid in building non-native (typically UNIX) programs under Plan 9 there is a facility called APE, the
ANSI POSIX Environment. Essentially the Plan 9 compilers are run by a program called pcc. Pcc runs
with ANSI and POSIX include files and libraries. In this fashion several programs such as awk,
ghostscript and troff were ported to Plan 9.
The Plan 9 system libraries support C as well as a new concurrent programming language called Alef.
I did not experiment with Alef but a reading of the documentation shows it to be easy to learn for
someone with a C background. The language supports object-oriented programming by
implementing static inheritance and information hiding. Abstract data types may have methods
(functions) associated with them. Alef syntax is C-like, with a few different variable types (byte as
opposed to C's char, and adt, aggr and tuple for complex structures). The most interesting
features are those that support concurrency. Alef programs can simply and easily communicate via
message passing with the chan() and alloc() operations:
chan(byte*) x;
alloc x;
x <-= "hello world";
These lines declare a channel x that passes byte values. This channel is then allocated and
initialized. The message "hello world" is then transmitted over that channel. Another thread
might execute this code:
byte *s;
s = <-x;

15. print("%sn", s);
This receives the string from the first example and prints it.
Alef supports threads with the proc, task and par statements. Proc creates a new preemptively
scheduled process, task creates a non-preemptively scheduled thread within a process, and par
executes a block of statements each as an individual process essentially in parallel, sharing memory
including automatic variables and function parameters. There are synchronization facilities to make
this work well.
Alef also supports methods of sharing variables and good facilities for error recovery. Most Plan 9
libraries are also implemented for Alef so it is a reasonable choice for program development under
Plan 9. Alef appears to be a powerful language with reasonably simple support for concurrent
programming. This short section does not do it justice. Alef is documented in The Alef Reference
Manual included with Plan 9, and also available at http://plan9.att.com/doc/{ref.html,
ug.html}.
The future of Plan 9
The version of Plan 9 that is available to the public is a snapshot of the Bell Labs computer
environment. As a result, the CD-ROM version is static while the Bell Labs version has continued to
evolve. The next version of Plan 9 at Bell Labs is called "Brazil". Brazil is an incremental improvement
to Plan 9, including very high speed graphic support (basically allowing applications access to the
raw graphics hardware). At one time AT&T considered using Plan 9 as an operating system for TV
cable boxes (set-top systems).
Could Plan 9 be improved? Of course! It needs emacs, vi, perl, the X Window system, display
Postscript... Just kidding -- the Plan 9 designers have suggested that if someone is interested in Plan
9 then they should try the whole environment, rather than bringing all their old UNIX tools with them.
Plan 9 could implement a domain sort of system to allow straightforward support of large
environments. The PC installation program might be improved to the level of Linux or FreeBSD. The
fileserver code could be integrated with the rest of the system.
The last few years have been a golden era for people who wished to run sophisticated operating
systems on inexpensive hardware. Not only is there a commercial version of UNIX available with
source code, there are several freely available versions that include source. BSDI, FreeBSD and
Linux have made UNIX and operating system technology more accessible to people than ever before.
Plan 9 is not freely available -- the startup cost is $350. This hampers its potential success. I do not
believe Bell Labs will make a profit from CD-ROM sales even at this price. If it was sold for one tenth
the price, or made available for free Plan 9 environment would benefit from more exposure and
more people contributing improvements.
Microsoft is an intimidating competitor in operating systems -- just ask IBM. I do not believe Plan 9
will repeat the success of UNIX. It may be used as an operating system for special purpose devices. I
think the real benefit of Plan 9 and the Plan 9 distribution are the ideas tested and demonstrated
therein. A per-user or per-process namespace is an elegant solution to several network computing
problems. The cross-architecture development environment might serve well in commercial
products. Easy to write and use fileservers provide a nice interface to system resources. And finally

16. the Plan 9 model makes true the old marketing slogan "the network is the computer." This
networked computing environment can take efficient advantage of computing resources -- both fast,
slow, old and new. Resources may be allocated where they serve best, rather than installing powerful
computers for every function.
I hope that AT&T continues to share Plan 9 with the public. Maybe they will make Brazil available as
well, possibly incorporating improvements from other Plan 9 developers.
Where to get Plan 9
AT&T will license Plan 9 to individuals or corporations for their own use. Terms of the license
essentially allow you to use Plan 9 for research or education but not for profit. The license carefully
spells out that what belongs to AT&T stays the property of AT&T and what is your own work stays your
own. AT&T would also like to sell Plan 9 to those who wish to sell it as a product. That part of AT&T
(Software Solutions) is available at (800) 462-8146.
The source and binaries for Plan 9 are available in two forms. The developers assume the most
common platform will be an Intel-based PC, specifically a 386, 486 or Pentium system with at least 8
MB of RAM. Unfortunately, as Plan 9 was developed by a small group of people it does not work with
all PCs. Therefore, they offer a trial version available via ftp on the Internet. This trial version fits on 4
diskettes and allows someone to sample the Plan 9 environment and to test the compatibility of Plan
9 with their hardware. The trial distribution is available at ftp://plan9.att.com/plan9/pcdist.
To learn what hardware is supported by Plan 9 read the paper The Various Ports at
http://plan9.att.com/plan9.doc/port.html.
For those with compatible hardware the full Plan 9 system is available for $350 on CD-ROM,
including two volumes of manual pages and papers on the system. The documents are all available
on the World Wide Web as well. Plan 9 is distributed by Harcourt Brace and Company. To order it call
(800) 782-4479. From Canada and the Caribbean call (800) 841-9938. Elsewhere call 1 (407) 345-
3800. The ISBN is 0-03-017143-1. The manuals alone may be ordered for $125 -- that ISBN is 0-03-
017142-3. Bookstores should be able to order these items as well. Complete information on
ordering Plan 9 is available at http://plan9.att.com/plan9/distrib.html.
Where to learn more about Plan 9
There is a small and growing group of people interested in using and improving Plan 9. This group
uses the mailing list 9fans, which is gatewayed to the newsgroup comp.os.plan9. This is archived
at http://www.ecf.toronto.edu/plan9. The Frequently Asked Questions list is available at
http://www.ecf.toronto.edu/plan9/plan9faq.html. There is a Plan 9 ftp site at
ftp://ftp.ecf.toronto.edu/pub/plan9. Bell Labs maintains a web page with the Plan 9
papers and manuals online at http://plan9.att.com/plan9/index.html. There are links to
several other Plan 9 web sites on the Bell Labs Plan 9 web page.
Thanks to my former employer, SEMATECH, and my former manager, Carol MacNaughton for
allowing me the use of SEMATECH resources for some of my Plan 9 work.

17. Works Cited
Fennessy, Q. (1996, May). Plan 9: Bad Movie, Good Operating System. Computer, 29(5), 117-
119,121-123.
Pike, R. (1995). Acme: A User Interface for Programmers. In R. Pike, D. Presotto, S. Dorward, B.
Flandrena, K. Thompson, H. Trickey, & P. Winterbottom, Plan 9 Programmers Manual (Vol. 1).
New York, New York, United States: Harcourt Brace.
Pike, R., Presotto, D., Dorward, S., Flandrena, B., Thompson, K., Trickey, H., & Winterbottom, P.
(1995). Plan 9 from Bell Labs. In R. Pike, D. Presotto, S. Dorward, B. Flandrena, K.
Thompson, H. Trickey, & P. Winterbottom, Plan 9 Programmers Manual (Vol. 2). New York,
New York, United States: Harcourt Brace and Co.
Winterbottom, P. (1994). Acid: A Debugger Built From A Language. In Proc. of the Winter 1994
USENIX Conf. (pp. 211-222).