And Now, for Something Completely Different - Plan 9 OS from Bell Labs

And Now, for Something Completely Different... I found a New (old) OS, that I had never heard of before, today. I like to read about and try out different Operating Systems. I started with Windows 3.1 and went on through WinXP. I heard about and download BSD in 2003 or 04. But, never got around to learning how to install and run it. And then in 2005. I discovered Linux. And I never looked back! I have been running Fedora and Debian Linux as my main OS's since then. I love to learn about and try out Different Linux Distros. And I recently got a Radio Shack TRS-80 to Play with. I almost bought one back in the early 80's and passed on it. Still, all of these years later. I got my chance to try out a TRS-80. Yes, it's very different than Today's Operating Systems. But, that's not my story today. Today, I discovered, Plan 9 from Bell Labs. Here's a bit from Wikipedia on it... Plan 9 from Bell Labs is a free softwaredistributed operating system. It was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 continues to be used and developed by operating system researchers and hobbyists. Plan 9 has novel features such as the 9P protocol for accessing local and remote resources as files, union mounts, an improved proc file system, and native unicode support throughout the system. In Plan 9, all system interfaces, including those required for networking and the user interface, are represented through the file system rather than specialized interfaces.The name Plan 9 from Bell Labs is a reference to the Ed Wood 1959 cult science fictionZ-moviePlan 9 from Outer Space.[3] Also, Glenda, the Plan 9 Bunny, is presumably a reference to Wood's film Glen or Glenda. From, http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

Plan 9 is so Different... That I just spent several hours. Just reading about it. Before I even Downloaded the ISO Image and tried to Boot it up in Virtual Box. It seemed to hang up, after a bit. But, I didn't wait all that long either. And I'm downloading a Qemu VM Image from here right now anyway, http://www.oszoo.org/wiki/index.php/Plan9_070107.zip So, I'll soon be trying it out too (well the qemu image didn't boot at all for me). So, I want to get to writing this Post. While things were fresh on my mind. But, I found a video showing a successful Boot here...

Plan 9 from Bell Labs (What's the Deal?)

Video Link...
http://www.youtube.com/watch?v=tegAIAs0EZU

Here's some info from the Plan 9 Site and plenty of links at the bottom...

Don

Plan 9 from Bell Labs

Rob Pike

Dave Presotto

Sean Dorward

Bob Flandrena

Ken Thompson

Howard Trickey

Phil Winterbottom

Bell Laboratories

Murray Hill, New Jersey 07974

USA

Motivation

By the mid 1980’s, the trend in computing was away from large centralized time-shared computers towards networks of smaller, personal machines, typically UNIX ‘workstations’. People had grown weary of overloaded, bureaucratic timesharing machines and were eager to move to small, self-maintained systems, even if that meant a net loss in computing power. As microcomputers became faster, even that loss was recovered, and this style of computing remains popular today.

In the rush to personal workstations, though, some of their weaknesses were overlooked. First, the operating system they run, UNIX, is itself an old timesharing system and has had trouble adapting to ideas born after it. Graphics and networking were added to UNIX well into its lifetime and remain poorly integrated and difficult to administer. More important, the early focus on having private machines made it difficult for networks of machines to serve as seamlessly as the old monolithic timesharing systems. Timesharing centralized the management and amortization of costs and resources; personal computing fractured, democratized, and ultimately amplified administrative problems. The choice of an old timesharing operating system to run those personal machines made it difficult to bind things together smoothly.

Plan 9 began in the late 1980’s as an attempt to have it both ways: to build a system that was centrally administered and cost-effective using cheap modern microcomputers as its computing elements. The idea was to build a time-sharing system out of workstations, but in a novel way. Different computers would handle different tasks: small, cheap machines in people’s offices would serve as terminals providing access to large, central, shared resources such as computing servers and file servers. For the central machines, the coming wave of shared-memory multiprocessors seemed obvious candidates. The philosophy is much like that of the Cambridge Distributed System [NeHe82]. The early catch phrase was to build a UNIX out of a lot of little systems, not a system out of a lot of little UNIXes.

The problems with UNIX were too deep to fix, but some of its ideas could be brought along. The best was its use of the file system to coordinate naming of and access to resources, even those, such as devices, not traditionally treated as files. For Plan 9, we adopted this idea by designing a network-level protocol, called 9P, to enable machines to access files on remote systems. Above this, we built a naming system that lets people and their computing agents build customized views of the resources in the network. This is where Plan 9 first began to look different: a Plan 9 user builds a private computing environment and recreates it wherever desired, rather than doing all computing on a private machine. It soon became clear that this model was richer than we had foreseen, and the ideas of per-process name spaces and file-system-like resources were extended throughout the system—to processes, graphics, even the network itself.

By 1989 the system had become solid enough that some of us began using it as our exclusive computing environment. This meant bringing along many of the services and applications we had used on UNIX. We used this opportunity to revisit many issues, not just kernel-resident ones, that we felt UNIX addressed badly. Plan 9 has new compilers, languages, libraries, window systems, and many new applications. Many of the old tools were dropped, while those brought along have been polished or rewritten.

Why be so all-encompassing? The distinction between operating system, library, and application is important to the operating system researcher but uninteresting to the user. What matters is clean functionality. By building a complete new system, we were able to solve problems where we thought they should be solved. For example, there is no real ‘tty driver’ in the kernel; that is the job of the window system. In the modern world, multi-vendor and multi-architecture computing are essential, yet the usual compilers and tools assume the program is being built to run locally; we needed to rethink these issues. Most important, though, the test of a system is the computing environment it provides. Producing a more efficient way to run the old UNIX warhorses is empty engineering; we were more interested in whether the new ideas suggested by the architecture of the underlying system encourage a more effective way of working. Thus, although Plan 9 provides an emulation environment for running POSIX commands, it is a backwater of the system. The vast majority of system software is developed in the ‘native’ Plan 9 environment.

There are benefits to having an all-new system. First, our laboratory has a history of building experimental peripheral boards. To make it easy to write device drivers, we want a system that is available in source form (no longer guaranteed with UNIX, even in the laboratory in which it was born). Also, we want to redistribute our work, which means the software must be locally produced. For example, we could have used some vendors’ C compilers for our system, but even had we overcome the problems with cross-compilation, we would have difficulty redistributing the result.

This paper serves as an overview of the system. It discusses the architecture from the lowest building blocks to the computing environment seen by users. It also serves as an introduction to the rest of the Plan 9 Programmer’s Manual, which it accompanies. More detail about topics in this paper can be found elsewhere in the manual.

Design

The view of the system is built upon three principles. First, resources are named and accessed like files in a hierarchical file system. Second, there is a standard protocol, called 9P, for accessing these resources. Third, the disjoint hierarchies provided by different services are joined together into a single private hierarchical file name space. The unusual properties of Plan 9 stem from the consistent, aggressive application of these principles.

A large Plan 9 installation has a number of computers networked together, each providing a particular class of service. Shared multiprocessor servers provide computing cycles; other large machines offer file storage. These machines are located in an air-conditioned machine room and are connected by high-performance networks. Lower bandwidth networks such as Ethernet or ISDN connect these servers to office- and home-resident workstations or PCs, called terminals in Plan 9 terminology. Figure 1 shows the arrangement.

The modern style of computing offers each user a dedicated workstation or PC. Plan 9’s approach is different. The various machines with screens, keyboards, and mice all provide access to the resources of the network, so they are functionally equivalent, in the manner of the terminals attached to old timesharing systems. When someone uses the system, though, the terminal is temporarily personalized by that user. Instead of customizing the hardware, Plan 9 offers the ability to customize one’s view of the system provided by the software. That customization is accomplished by giving local, personal names for the publicly visible resources in the network. Plan 9 provides the mechanism to assemble a personal view of the public space with local names for globally accessible resources. Since the most important resources of the network are files, the model of that view is file-oriented.

The client’s local name space provides a way to customize the user’s view of the network. The services available in the network all export file hierarchies. Those important to the user are gathered together into a custom name space; those of no immediate interest are ignored. This is a different style of use from the idea of a ‘uniform global name space’. In Plan 9, there are known names for services and uniform names for files exported by those services, but the view is entirely local. As an analogy, consider the difference between the phrase ‘my house’ and the precise address of the speaker’s home. The latter may be used by anyone but the former is easier to say and makes sense when spoken. It also changes meaning depending on who says it, yet that does not cause confusion. Similarly, in Plan 9 the name /dev/cons always refers to the user’s terminal and /bin/date the correct version of the date command to run, but which files those names represent depends on circumstances such as the architecture of the machine executing date. Plan 9, then, has local name spaces that obey globally understood conventions; it is the conventions that guarantee sane behavior in the presence of local names.

The 9P protocol is structured as a set of transactions that send a request from a client to a (local or remote) server and return the result. 9P controls file systems, not just files: it includes procedures to resolve file names and traverse the name hierarchy of the file system provided by the server. On the other hand, the client’s name space is held by the client system alone, not on or with the server, a distinction from systems such as Sprite [OCDNW88]. Also, file access is at the level of bytes, not blocks, which distinguishes 9P from protocols like NFS and RFS. A paper by Welch compares Sprite, NFS, and Plan 9’s network file system structures [Welc94].

This approach was designed with traditional files in mind, but can be extended to many other resources. Plan 9 services that export file hierarchies include I/O devices, backup services, the window system, network interfaces, and many others. One example is the process file system, /proc, which provides a clean way to examine and control running processes. Precursor systems had a similar idea [Kill84], but Plan 9 pushes the file metaphor much further [PPTTW93]. The file system model is well-understood, both by system builders and general users, so services that present file-like interfaces are easy to build, easy to understand, and easy to use. Files come with agreed-upon rules for protection, naming, and access both local and remote, so services built this way are ready-made for a distributed system. (This is a distinction from ‘object-oriented’ models, where these issues must be faced anew for every class of object.) Examples in the sections that follow illustrate these ideas in action.

The Command-level View

Plan 9 is meant to be used from a machine with a screen running the window system. It has no notion of ‘teletype’ in the UNIX sense. The keyboard handling of the bare system is rudimentary, but once the window system, 8½ [Pike91], is running, text can be edited with ‘cut and paste’ operations from a pop-up menu, copied between windows, and so on. 8½ permits editing text from the past, not just on the current input line. The text-editing capabilities of 8½ are strong enough to displace special features such as history in the shell, paging and scrolling, and mail editors. 8½ windows do not support cursor addressing and, except for one terminal emulator to simplify connecting to traditional systems, there is no cursor-addressing software in Plan 9.

Each window is created in a separate name space. Adjustments made to the name space in a window do not affect other windows or programs, making it safe to experiment with local modifications to the name space, for example to substitute files from the dump file system when debugging. Once the debugging is done, the window can be deleted and all trace of the experimental apparatus is gone. Similar arguments apply to the private space each window has for environment variables, notes (analogous to UNIX signals), etc.

Each window is created running an application, such as the shell, with standard input and output connected to the editable text of the window. Each window also has a private bitmap and multiplexed access to the keyboard, mouse, and other graphical resources through files like /dev/mouse, /dev/bitblt, and /dev/cons (analogous to UNIX’s /dev/tty). These files are provided by 8½, which is implemented as a file server. Unlike X windows, where a new application typically creates a new window to run in, an 8½ graphics application usually runs in the window where it starts. It is possible and efficient for an application to create a new window, but that is not the style of the system. Again contrasting to X, in which a remote application makes a network call to the X server to start running, a remote 8½ application sees the mouse, bitblt, and cons files for the window as usual in /dev; it does not know whether the files are local. It just reads and writes them to control the window; the network connection is already there and multiplexed.

The intended style of use is to run interactive applications such as the window system and text editor on the terminal and to run computation- or file-intensive applications on remote servers. Different windows may be running programs on different machines over different networks, but by making the name space equivalent in all windows, this is transparent: the same commands and resources are available, with the same names, wherever the computation is performed.

The command set of Plan 9 is similar to that of UNIX. The commands fall into several broad classes. Some are new programs for old jobs: programs like ls, cat, and who have familiar names and functions but are new, simpler implementations. Who, for example, is a shell script, while ps is just 95 lines of C code. Some commands are essentially the same as their UNIX ancestors: awk, troff, and others have been converted to ANSI C and extended to handle Unicode, but are still the familiar tools. Some are entirely new programs for old niches: the shell rc, text editor sam, debugger acid, and others displace the better-known UNIX tools with similar jobs. Finally, about half the commands are new.

Compatibility was not a requirement for the system. Where the old commands or notation seemed good enough, we kept them. When they didn’t, we replaced them.

The File Server

A central file server stores permanent files and presents them to the network as a file hierarchy exported using 9P. The server is a stand-alone system, accessible only over the network, designed to do its one job well. It runs no user processes, only a fixed set of routines compiled into the boot image. Rather than a set of disks or separate file systems, the main hierarchy exported by the server is a single tree, representing files on many disks. That hierarchy is shared by many users over a wide area on a variety of networks. Other file trees exported by the server include special-purpose systems such as temporary storage and, as explained below, a backup service.

The file server has three levels of storage. The central server in our installation has about 100 megabytes of memory buffers, 27 gigabytes of magnetic disks, and 350 gigabytes of bulk storage in a write-once-read-many (WORM) jukebox. The disk is a cache for the WORM and the memory is a cache for the disk; each is much faster, and sees about an order of magnitude more traffic, than the level it caches. The addressable data in the file system can be larger than the size of the magnetic disks, because they are only a cache; our main file server has about 40 gigabytes of active storage.

The most unusual feature of the file server comes from its use of a WORM device for stable storage. Every morning at 5 o’clock, a dump of the file system occurs automatically. The file system is frozen and all blocks modified since the last dump are queued to be written to the WORM. Once the blocks are queued, service is restored and the read-only root of the dumped file system appears in a hierarchy of all dumps ever taken, named by its date. For example, the directory /n/dump/1995/0315 is the root directory of an image of the file system as it appeared in the early morning of March 15, 1995. It takes a few minutes to queue the blocks, but the process to copy blocks to the WORM, which runs in the background, may take hours.

There are two ways the dump file system is used. The first is by the users themselves, who can browse the dump file system directly or attach pieces of it to their name space. For example, to track down a bug, it is straightforward to try the compiler from three months ago or to link a program with yesterday’s library. With daily snapshots of all files, it is easy to find when a particular change was made or what changes were made on a particular date. People feel free to make large speculative changes to files in the knowledge that they can be backed out with a single copy command. There is no backup system as such; instead, because the dump is in the file name space, backup problems can be solved with standard tools such as cp, ls, grep, and diff.

The other (very rare) use is complete system backup. In the event of disaster, the active file system can be initialized from any dump by clearing the disk cache and setting the root of the active file system to be a copy of the dumped root. Although easy to do, this is not to be taken lightly: besides losing any change made after the date of the dump, this recovery method results in a very slow system. The cache must be reloaded from WORM, which is much slower than magnetic disks. The file system takes a few days to reload the working set and regain its full performance.

Access permissions of files in the dump are the same as they were when the dump was made. Normal utilities have normal permissions in the dump without any special arrangement. The dump file system is read-only, though, which means that files in the dump cannot be written regardless of their permission bits; in fact, since directories are part of the read-only structure, even the permissions cannot be changed.

Once a file is written to WORM, it cannot be removed, so our users never see ‘‘please clean up your files’’ messages and there is no df command. We regard the WORM jukebox as an unlimited resource. The only issue is how long it will take to fill. Our WORM has served a community of about 50 users for five years and has absorbed daily dumps, consuming a total of 65% of the storage in the jukebox. In that time, the manufacturer has improved the technology, doubling the capacity of the individual disks. If we were to upgrade to the new media, we would have more free space than in the original empty jukebox. Technology has created storage faster than we can use it.

Unusual file servers

Read More...
http://plan9.bell-labs.com/sys/doc/9.html

Download and Installation

CD Image | Floppy Image

This is the distribution for the Fourth Edition of Plan 9. It contains source of the kernel, libraries, and commands for all supported architectures. It also contains complete binaries for the x86 architecture. See the release notes for information about what’s new in this release.

The Plan 9 CD Image is both a live boot CD and an installation CD. When you boot it, a menu will give you a choice between the two. You can boot as a live CD to explore the system. People inside Alcatel-Lucent should first ask for an account on the nearest Plan 9 system (e.g., in Murray Hill or Antwerp), find the CD image in /n/other/dist on Plan 9 in Murray Hill if necessary, or populate new disks using replica(1) or dircp (in tar(1)).

You can also install by booting a floppy disk, but you will still need the CD (or at least the CD image) in order to install the system. The CD is the preferred method of installation. In order to fit a Plan 9 kernel into the floppy image, support for various devices has been omitted, notably for USB, AHCI (native SATA interface), VT6105M Ethernet interfaces (used by newer Soekris machines, for example), Intel’s PCI-Express Gigabit Ethernet interfaces, and all 10-Gigabit Ethernet interfaces. The floppy disk also has a minimal plan9.ini file on it. If you have special requirements, you may need to customize it.

Before installing Plan 9, you should print out and read the installation instructions and the supported PC hardware list. You may also find it useful to print the plan9.ini(8) and prep(8) manual pages for reference during the installation.

Enjoy!

Go there...
http://plan9.bell-labs.com/plan9/download.html

Supported PC Hardware

This page lists hardware known to work with Plan 9. Most hardware is listed by chipset, you may need to know what chipset your particular cards use. There is also a list of known broken hardware.

IDE/ATAPI CONTROLLERS

Plan 9 supports almost all motherboard IDE/ATAPI controllers, but DMA transfers are only used on these recognized chipsets (chipsets not listed here will simply run slower; you can try turning on DMA by editing /sys/src/9/pc/sdata.c).

• ALi M1543, M5288 SATA
• AMD 755, 756, 766, 768, 3111, CS5536
• AMD/ATI SB400, 200M, 4379 SATA
• CMD 640B, 646
• HighPoint HPT366
• Intel PIIX, PIIX3, PIIX4, ICH, ICH0, ICH2-7, ICH9, 6300ESB
• NS PC87415
• nVidia nForce 1-4, MCP 55, 61, 65, 69, 430
• PC-Tech RZ1000
• Promise PDC202xx, Ultra/133 TX2, 20378
• ServerWorks IB6566
• SiL 3112 SATA, 3114 SATA/RAID
• SiS 962
• VIA 82C686, VT8237 SATA/RAID

SATA CONTROLLERS

Plan 9 supports a few SATA controllers in their native AHCI mode, as opposed to the IDE-compatibility mode that some of them offer.

• AMD SB600
• Intel 63xxESB
• Intel 82801GxM, for x = B or H
• Intel ICH8, ICH9

The non-AHCI Marvell 88SX series four- and eight-port PCI-X chipsets are also supported.

ATA-OVER-ETHERNET DEVICES

Plan 9 supports access to ATA-over-Ethernet devices.

USB

USB audio, disks, Ethernet, keyboards, mice and printers are supported (see usb(4)) via the UHCI, OHCI and EHCI interfaces. XHCI (USB 3, 5Gb/s) is not yet started.

ETHERNET

Read More...
http://plan9.bell-labs.com/wiki/plan9/supported_pc_hardware/index.html

Installation instructions

SYSTEM REQUIREMENTS

These instructions are for a x86 based PC. See the Supported PC hardware page.

Find an x86-based PC with:

• >32MB of RAM
• a hard disk with 300 MB of unpartitioned space and a free primary partition slot

These are requirements for the installation procedure. A machine with 16MB of memory and no free disk space at all will work fine as a terminal net-booted but won't be able to run the installer.

If you wish to install from local media, you need a FAT file system or a CD-ROM drive. If you wish to install over the internet, you need a supported Ethernet card or a PPP dial-up account using a modem.

SITE PLANNING

There is nothing magical about installing Plan 9. It's just a matter of populating a Plan 9 file system (typically a fossil file system) and arranging a bootstrap to eventually load a Plan 9 kernel that can use that file system as its root.

Once that initial file server is running, enabling authentication and pxe booting (bootp and tftp) will allow all other local Plan 9 systems to load kernels from the file server and share its file system.

If you find yourself reinstalling Plan 9 frequently, something is wrong. This should not be necessary. In particular, there is no need to give each Plan 9 system its own file system.

DOWNLOAD THE CD IMAGE

Download the ISO from plan9.bell-labs.com or from a local mirror. See the download page.

BOOT THE INSTALLATION CD

(NOTE on vmware fusion for Mac OS X, you probably want to use SCSI disks as the IDE emulation makes Plan 9 difficult to boot at this time. SCSI on the other hand works VERY fast for booting and installtion)

Cold boot (power off, power on) your machine using your CD. You will be given the choice of installing Plan 9 or just booting a full Plan 9 system directly from the CD.

Booting the system directly lets you explore the system without installing and also makes a good recovery CD.

The installer on the CD assumes that your CD-ROM is on the second IDE master. If your CD-ROM is elsewhere, you will see the following error:

Unknown boot device: sdD0!cdboot!9pcflop.gz  Boot device: fd0  boot from:  

IDE/ATAPI drives in Plan 9 are named like sdD0, where the capital letter is C for the primary IDE interface and D for the second. The digit is 0 for the master and 1 for the slave. So if your CD-ROM is the primary slave, use sdC1:

boot from: sdC1!cdboot!9pcflop.gz  

If you find yourself at a "boot from:" prompt or a "root is from:" prompt, it is likely that the bootstrap program has not detected your floppy drive. See installation troubleshooting.

You will be asked if DMA should be enabled for your ide drives, the default is 'yes', only answer 'no' if you had problems during the installation with DMA enabled.

You will be prompted for a "mouseport"; if you have a USB mouse ignore this prompt, you won't have mouse support during install, but that should be OK.

Last you will be asked for your vga settings, the default resolution is the safest option and should be enough to run the installer, you can change this later once the system is installed.

Note: If you know your videocard is not supported, answer "vesa" when prompted for a monitor type.

BEGINNING THE INSTALLATION

If your video card and resolution is supported (or you selected vesa) the window system will start.

Otherwise you will be dropped into a % prompt. To start the installer in text mode run:

% inst/textonly  

The installer is the same in text and graphical mode, but graphical mode is a bit more friendly.

In graphical mode the window system (rio(1)) will display a grey screen with some windows. The large upper window contains the install process itself. The window under it, is a running log of what has happened. A statistics graph is in the bottom corner; the graph, from top to bottom, shows system load, memory usage, interrupt rate, system call rate, context switch rate, and ethernet packet rate.

Interaction with the installation program is textual and you don't need to interact with rio during the install process. For systems with very small screens, you may find necessary to use the keyboard's arrow keys to scroll the window up and down.

When you are prompted to provide information (e.g., an IP address) or asked to select from a list of choices (e.g., the disk to use), the prompt will be of the form

 Your choice (foo, bar, baz, quux)[quux]:  

When there is a small list of possible answers, they will be listed in parentheses. If there is a default choice, it will be given in square brackets and pressing enter will select this default.

The installation program is structured as a sequence of tasks that must be performed; some tasks have successful completion of others as prerequisites.

At each step, you will be shown the list of completed tasks and the list of tasks that are ready to be done. Task names appear in parentheses in the text that follows. Typing <control-d> at any prompt will abort the current task and return you to the main menu.

CHOOSE A FILESYSTEM

(Configfs) Fossil(4) is the Plan 9 fileserver. Venti(8) is an archival block storage server. You may run fossil on its own or as a write buffer backed by a Venti server. The primary value of using Venti is to store daily snapshots of your filesystem (see yesterday(1)).

PARTITION YOUR HARD DISK

Read More...
http://plan9.bell-labs.com/wiki/plan9/installation_instructions/

Download

PLAN 9 FROM BELL LABS

Go there...
http://plan9.bell-labs.com/wiki/plan9/download/index.html

Plan 9 from Bell Labs

Fourth Edition

(at plan9.bell-labs.com)

Introduction
         overview, screen shot, Glenda Documentation
         release notes, papers, manual pages,
         wiki, more... Download
         live CD/install CD, installation notes,
         browse the source (enabled again), additional software Conference
         Seventh International Workshop on Plan 9, Dublin, Nov 14—16, 2012 Related Resources
         mailing lists, Plan 9 from User Space,
         Inferno, community, 9grid,
         Plan 9 kernel history

Go there...
http://plan9.bell-labs.com/plan9/

Plan 9 from Bell Labs

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Plan 9 from Bell Labs

Installation of Plan 9
Company / developer	Bell Labs
Programmed in	Dialect of ANSI C
Working state	Current
Source model	Free and open source software
Initial release	1992 (universities) / 1995 (general public)
Latest stable release	Fourth Edition / April 28, 2002; 10 years ago
Latest unstable release	Snapshots / daily
Available language(s)	English
Update method	replica
Supported platforms	x86 / Vx32, x86-64, MIPS, DEC Alpha, SPARC, PowerPC, ARM
Kernel type	Monolithic
Default user interface	rio / rc
License	Lucent Public License
Official website	plan9.bell-labs.com/plan9

Plan 9 from Bell Labs is a free software distributed operating system. It was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 continues to be used and developed by operating system researchers and hobbyists.[1][2]
Plan 9 has novel features such as the 9P protocol for accessing local and remote resources as files, union mounts, an improved proc file system, and native unicode support throughout the system. In Plan 9, all system interfaces, including those required for networking and the user interface, are represented through the file system rather than specialized interfaces.
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.[3] Also, Glenda, the Plan 9 Bunny, is presumably a reference to Wood's film Glen or Glenda.

Contents 1 History 2 Design concepts 2.1 9P protocol 2.2 Union directories and namespaces 2.3 Special virtual filesystems 2.3.1 /proc 2.3.2 /net 2.4 Unicode 3 Combining the design concepts 4 Software for Plan 9 4.1 Graphical programs 4.2 Storage system 5 UNIX compatibility 6 Impact 7 License 8 See also 9 References 10 External links

History

Date	Release	Comment
1992	Plan 9 1st Edition	Released by Bell Labs to universities
1995	Plan 9 2nd Edition	Released by Bell Labs for non-commercial purposes[4]
2000	Plan 9 3rd Edition (Brazil)	Released by Lucent Technologies under an open source license for non-commercial use
2002	Plan 9 4th Edition	Released by Lucent Technologies under a new free software license

Plan 9 was a Bell Labs internal project from its start during the mid 1980s. It 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. In 1992, Bell Labs provided the first public release to universities, and three years later a commercial second release version became available to the general public. In the late 1990s, Lucent Technologies, having inherited Bell Labs, dropped commercial support for the project. In 2000, a non-commercial third release was distributed under an open source license. A fourth release under a new free software license occurred in 2002.[5]
A user and development community, including current and former Bell Labs members and Massachusetts Institute of Technology personnel, continues to produce minor daily releases in form of ISO images. Bell Labs still hosts the development.[6] The development source tree is accessible over the 9P and HTTP protocols and is used to update existing installations.[7] 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.
Plan 9 from Bell Labs was originally developed by members of the Computing Science Research Center at Bell Labs, the same group that originally developed UNIX and C.[8] 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.[9]

Design concepts

Plan 9 from Bell Labs is like the Quakers: distinguished by its stress on the 'Inner Light,' noted for simplicity of life, in particular for plainness of speech. Like the Quakers, Plan 9 does not proselytize.

—Sape J. Mullender, Pierre G. Janson.
Real Time in Real Operating System[10]

Plan 9 is an evolution of UNIX design concepts:[11]

1. all objects are either files or file systems
2. communication is over a network
3. private namespaces allow their owners to access local and remote processes transparently

Plan 9 is a grid computing platform. It is an effort to provide a computing environment for geographically distributed clusters running on heterogeneous hardware, engineered for modern distributed environments and designed from the start to be a networked operating system.[12] It can be installed as a self-contained system and used on a single computer, but also has the capability to separate its components between separate computers. In a typical Plan 9 installation, users work at terminals running 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.[13] Currently available desktop computers can emulate this architecture internally using multiple virtual machines.

9P protocol

Main article: 9P

To reduce the number of custom APIs and system calls, Plan 9 makes heavy use of the 9P protocol. 9P is a generic medium-agnostic byte-oriented protocol that provides for messages delivered between a server and a client.[14] The protocol is used to refer to and communicate with processes, programs, and data, including both the user interface and the network.[15] With the release of the 4th edition, it was modified and renamed 9P2000.[5]
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.[14] 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.[3]

Union directories and namespaces

Plan 9 allows the user to collect the files (called names) from different directory trees in a single location. The name resolution is then performed from top to bottom: If the name doesn't exist in the top directory, it is looked up in lower ones until found. The same name in lower directories will be shown in the directory listing, but will not be accessible; thus, the merging of subdirectories is not handled.[16]
A union directory can be created by using the bind command:

; bind /arm/bin /bin  ; bind -a /usr/inferno/Plan9/arm/bin /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. Inferno'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 /usr/inferno/Plan9/arm/bin.

This mechanism of union directories replaces the search path of conventional UNIX shells. As far as you are concerned, all executable programs are in /bin.

—Brian Kernighan[17]

Furthermore, the kernel can keep separate mount tables for each process,[10] and can thus provide 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.[18] Namespaces may be used to create an isolated environment similar to chroot, but in a more secure way.[14]
Plan 9's union directory architecture inspired BSD and Linux union file system implementations.[19]

Special virtual filesystems

/proc

Listing processes with list contents of directory (ls, lc) command[20] in /proc

Main article: procfs

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.[16]
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.[21]

/net

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

Unicode

Further information: UTF-8, Comparison of Unicode encodings

To reduce the complexity of managing character encodings, Plan 9 uses Unicode throughout the system. The initial Unicode implementation was ISO 10646. Ken Thompson invented UTF-8, which became the native encoding in Plan 9. The entire system was converted to general use in 1992.[22] UTF-8 preserves backwards compatibility with traditional null terminated strings, enabling more reliable information processing and the chaining of multilingual string data with Unix pipes between multiple processes. Using a single UTF-8 encoding with characters for all cultures and regions eliminates the need for switching between code sets.[23]

Combining the design concepts

Though interesting on their own, the design concepts of Plan 9 were supposed to be most useful when combined together. For example, to implement a network address translation (NAT) server, a union directory can be created, overlaying the router's /net directory tree with its own /net. Similarly, a virtual private network (VPN) can be implemented by overlaying in a union directory a /net hierarchy from a remote gateway, using secured 9P over the public Internet. A union directory with the /net hierarchy and filters can be used to sandbox an untrusted application or to implement a firewall.[14] In the same manner, a distributed computing network can be composed with a union directory of /proc hierarchies from remote hosts, which allows interacting with them as if they are local.
When used together, these features allow for assembling a complex distributed computing environment by reusing the existing hierarchical name system.[21]

Software for Plan 9

Further information: list of Plan 9 applications

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.[24] Its compiler is a dialect of C with some extensions and restrictions.[25]
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.[26]

Graphical programs

Plan 9 running acme and rc

Unlike Unix, Plan 9 was designed with graphics in mind.[15] After booting, a Plan 9 terminal will run the rio windowing system, in which the user can create new windows displaying rc.[27] 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.[28]

Storage system

Plan 9 supports the FAT and Fossil file systems. The latter 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.

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. Still, many command line utilities of Plan 9 have aliases to the names of their UNIX counterparts.[20]
Plan 9 can support POSIX applications and can emulate the Berkeley socket interface through the ANSI/POSIX Environment (APE).[29] Some Linux binaries can be used with the help of a "linuxemu" (Linux emulator) application; however, it is still a work in progress.[30]

Impact

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

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.[27] 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 limited forms of rfork-like system calls. 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.[32][33] The 9wm window manager was inspired by 8½, the older windowing system of Plan 9;[34] wmii is also heavily influenced by Plan 9.[31]
However, Plan 9 has never approached Unix in popularity, and has been primarily a research tool:

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[3]

Other criticisms focused on the lack of commercial backup, the low number of end-user applications, and the lack of device drivers.[27][28]
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.[10] 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.[35][36][37][38]
Several projects actively work to extend Plan 9, including 9atom and 9front. These forks augment Plan 9 with additional hardware drivers and software, including nupas (an improved version of the Upas e-mail system), the go compiler, Mercurial version control system support, and other programs.[2][39]

License

The full source code is freely available under Lucent Public License 1.02; it is considered to be open source by the Open Source Initiative (OSI), free software by the Free Software Foundation, and it passes the Debian Free Software Guidelines.[14] However, it is incompatible with the GNU General Public License.[40]

See also

Free software portal

• Alef (programming language)
• Glenda, the Plan 9 Bunny
• Rendezvous (Plan 9)
• Inferno (operating system)

References

1. ^ Robertson, James (2011-07-16). "Plan 9 Forked, Continues as 9front". OSNews. Retrieved 2011-12-31.
2. ^ a b "9atom". Retrieved 2011-11-11.
3. ^ a b c Raymond, Eric S. (2003-09-17). "Plan 9: The Way the Future Was". The Art of UNIX Programming. Addison-Wesley. ISBN 0-13-142901-9. Retrieved 2007-05-07.
4. ^ "Announcement of the first release to general public".
5. ^ a b Loli-Queru, Eugenia (2002-04-29). "Bell Labs Releases New Version of Plan 9". OSNews. Retrieved 2011-12-31.
6. ^ "How to contribute". Bell Labs. Lucent Technologies. Retrieved 2011-11-30.
7. ^ "Staying up to date". Bell Labs. Lucent Technologies. Retrieved 2006-04-27.
8. ^ "From the inventors of UNIX system comes Plan 9 from Bell Labs" (Press release). Lucent Technologies. 1995-07-18. Archived from the original on 2006-02-09.
9. ^ McIlroy, Doug (1995-03). "Preface to the Second (1995) Edition". Bell Labs. Lucent Technologies. Retrieved 2006-04-02.
10. ^ a b c Mullender, Sape J.; Janson, Pierre G. (2004-02-26). "Real Time in Real Operating System". In Herbert, Andrew J.; Jones, Karen Spärck. Computer systems: theory, technology, and applications : a tribute to Roger Needham. Springer Science+Business Media. p. 211. ISBN 978-0-387-20170-2. Retrieved 2011-12-24.
11. ^ Bischof, Hans-Peter; Imeyer, Gunter; Wellhöfer, Bernhard & Schreiner, Axel-Tobias (1999). Das Netzbetriebssystem Plan 9. ISBN 3-446-18881-9.
12. ^ Hancock, Brian (2003). "Reinventing Unix: an introduction to the Plan 9 operating system". Library Hi Tech (MCB UP) 21 (4): 471–476. doi:10.1108/07378830310509772.
13. ^ Presotto, Dave; Pike, Rob; Thompson, Ken; Trickey, Howard. "Plan 9, A Distributed System". Bell Labs. Lucent Technologies. CiteSeerX: 10.1.1.41.9192.
14. ^ a b c d e Pereira, Uriel M. (2006) (avi). The Unix Spirit set Free: Plan 9 from Bell Labs. FOSDEM. Retrieved 2011-12-02. Lay summary.
15. ^ a b Minnich, Ron (2005). "Why Plan 9 is not dead yet And What we can learn from it" (pdf). Los Alamos National Laboratory. FAST-OS. Retrieved 2011-12-02.
16. ^ a b Ballesteros, Francisco J. (2007-09-28). "Introduction to OS abstractions using Plan 9 from Bell Labs" (pdf). Universidad Rey Juan Carlos. Archived from the original on 2010-09-21.
17. ^ Kernighan, Brian (1995). "Readme". Lucent Technologies. Retrieved 2012-01-25. Hosted by mirtchovski.com.
18. ^ Pike, R.; Presotto, D.; Thompson, K.; Trickey, H.; Winterbottom, P.. "The Use of Name Spaces in Plan 9". Bell Labs. cat-v.org. Retrieved 2011-12-05.
19. ^ Valerie, Aurora (2009-03-25). "Union file systems: Implementations, part I". LWN.net. Retrieved 2011-12-05.
20. ^ a b "UNIX to Plan 9 command translation". Bell Labs. Lucent Technologies. Retrieved 2011-12-02.
21. ^ a b c Pike, R.; Presotto, D.; Dorward, S.; Flandrena, B.; Thompson, K.; Trickey, H.; Winterbottom, P.. "Plan 9 from Bell Labs". Bell Labs. Lucent Technologies. Retrieved 2011-12-02.
22. ^ Pike, Rob (2003-04-30). "UTF-8 History". Retrieved 2006-04-27.
23. ^ Lunde, Ken (1999-01). CJKV information processing. O'Reilly Media. p. 466. ISBN 978-1-56592-224-2. Retrieved 2011-12-23.
24. ^ Dixon, Rod (2004). Open source software law. Artech House. p. 213. ISBN 978-1-58053-719-3. Retrieved 2011-12-25.
25. ^ Thompson, Ken (1992-02). "A new C Compiler". Australian UNIX systems User Group Newsletter (Kensington, Australia: AUUG, Inc.) 13 (1): 31–41. ISSN 1035-7521. Retrieved 2011-12-25.
26. ^ Cox, R.; Grosse, E.; Pike, R.; Presotto, D.; Quinlan, S.. "Security in Plan 9". Bell Labs. Lucent Technologies. Retrieved 2011-12-02.
27. ^ a b c Hudson, Andrew (2006-07-19). "Investigating the Plan 9 Operating System". OSNews. Retrieved 2011-12-31.
28. ^ a b "An interview with Russ Cox". The Setup. 2011-04-09. Retrieved 2012-01-01.
29. ^ Trickey, Howard. "APE – The ANSI/POSIX Environment". Bell Labs. Lucent Technologies. Retrieved 2011-04-27.
30. ^ "Linux emulation". Bell Labs. Lucent Technologies. Retrieved 2011-12-02.
31. ^ a b "window manager improved 2". suckless.org. Retrieved 2012-01-02. "[wmii] has a 9p filesystem interface and supports classic and tiling (acme-like) window management."
32. ^ "Glendix: Bringing the beauty of Plan 9 to Linux". Retrieved 2011-12-01.
33. ^ "Plan 9 From Gentoo: Plan 9 Meets Gentoo". Gentoo Linux. Retrieved 2011-12-01.
34. ^ "The 9wm Window Manager". 9wm. Retrieved 2012-01-02. "9wm is an X window manager which attempts to emulate the Plan 9 window manager 8-1/2 as far as possible within the constraints imposed by X."
35. ^ "9grid". Bell Labs. Lucent Technologies. Retrieved 2006-03-28.
36. ^ "Press Release: Vita Nuova Supplies Inferno Grid to Evotec OAI" (pdf) (Press release). Vita Nuova. 2004-05-18. Retrieved 2006-03-28.
37. ^ "Press Release: Rutgers University Libraries Install Inferno Data Grid" (pdf). Vita Nuova. 2004-05-12. Retrieved 2006-03-28.
38. ^ "Press Release: The University of York Department of Biology install Vita Nuova's Inferno Data Grid" (pdf) (Press release). Vita Nuova. 2004-05-04. Retrieved 2006-03-28.
39. ^ "plan9front - the front fell off". Retrieved 2011-12-01.
40. ^ "Lucent Public License Version 1.02 (Plan 9 license)". Various Licenses and Comments about Them. Free Software Foundation. Retrieved 2011-12-02.

External links

Wikimedia Commons has media related to: Plan 9 (operating system)

• Official website
• 9fans, the Plan 9 mailing list hosted by http://9fans.net
• Ninetimes Plan 9, Inferno, Unix, and Bell Labs operating systems news
• #plan9, the Plan 9 IRC channel hosted by freenode
• Cat-v.org Random Contrarian Insurgent Organization, the Plan 9 user and developer community

[show] v t e Unix and Unix-like operating systems

[show] v t e Rob Pike

Categories:

• Real-time operating systems
• Embedded operating systems
• Plan 9 from Bell Labs
• Computing platforms
• Software projects
• 1992 software

• This page was last modified on 1 December 2012 at 21:59.
  
• Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
  Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
  

Go there...
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

Plan 9 OS from Bell Labs was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002

Plan 9 on the Raspberry Pi

Getting Plan 9 running on the Raspberry Pi | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Plan 9 from Bell Labs

Plan 9 — The Documents (Volume 2)

Plan 9 from Bell Labs - Wikipedia, the free encyclopedia

newbie-guide.pdf (application/pdf Object)

research!rsc: A Tour of Acme

Glenda, the Plan 9 Bunny - Wikipedia, the free encyclopedia

A Tour of the Acme Editor - YouTube

Plan 9 from Bell Labs - Google Search

Plan 9 from Bell Labs

recovering lazyholic blog: bell labs

Plan 9 from Bell Labs - Google Image Search

Plan 9 and Inferno at the Google Summer of Code

Plan 9 From Bell Labs « Dan's Thoughts

7th International Workshop on Plan 9

Plan 9 from Bell Labs on IBM's Blue Gene Supercomputers

Maney|Digital | Tag Archive | Bell Labs

7th International Workshop on Plan 9 | uplbcoss.ph

Plan 9 from Bell Labs (What's the Deal?) - YouTube

dmr: stories | Maney|Digital

dmr - YouTube

Installation instructions (Plan 9 wiki)

Plan 9 Download

Download (Plan 9 wiki)

Plan 9

Installation instructions (Plan 9 wiki)

Supported PC Hardware (Plan 9 wiki)

Plan 9 /sys/man/8/plan9.ini

Plan 9 /sys/man/8/prep

Inferno Downloads

Category:Plan9 images - FreeOsZoo

Plan9 070107.zip - FreeOsZoo