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.

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.

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

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:

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:

% 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.

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.

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)

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

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

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.

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

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.

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;

print("%s\n", 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

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.

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).