Current Page -
Last modified Tue Dec 3 16:45:36 CET 2013
Plan 9 is a (relatively) new computer operating system and associated utilities. It was built by the Computing Science Research Center of Bell Laboratories (now part of Alcatel-Lucent), the same group that developed Unix, C, and C++.
Plan 9 is a distributed system, able to make use of different kinds of resources and servers spread across almost any network. It has very low resource requirement compared to most systems, has a very consistent, simple design, and performs very well.
Inferno is a spin-off of Plan 9 using many of the same ideas (and much of the same code). Inferno has several additional benefits; even lighter resource requirements, a virtual machine (Dis), a new language for concurrent programming (Limbo), and the ability to run as an application on top of an existing Operating System (including Plan 9, Windows, and a variety of Unixes).
This FAQ mostly talks about Plan 9, but the ideas largely translate to Inferno. See the last few questions for some Inferno-specific information.
The answer to this question varies by user; Plan 9 shows up in lots of different types of applications, making use of different benefits. It is used in embedded systems, where the low overhead is important. It is used in commercial products where the reliability and performance are important. It's used in massive supercomputers where the novel interconnections and low "system noise" are needed. What you get out of it largely depends on what you're looking for from it.
Most frequently, people using Plan 9 seem to focus on the simplicity of the system and the great distribution mechanism. This later idea, in particular, is very central to Plan 9: all resources are represented as normal files (as opposed to Unix, where most things are files, but not all files are "real" files), and the system uses a common method to talk to them all (9P, a.k.a. Styx). This, and related points like the fact that the namespace is per-process, affects the organization of the entire system, leading to all sorts of interesting, novel uses. This is the key point to understand in Plan 9, and also the biggest mental jump from Unix or other systems.
Plan 9 is not Unix (or anything else you're likely familiar with). While the command set is superficially similar, it's most certainly not the same (cat on Unix has a dozen or so options; on Plan 9, it has zero). Many people come to Plan 9 expecting unix++ or similar, and are disappointed when they find something much more different than that. Even the development environment is similar but entirely distinct: we use mk, not make; we use C, but the library isn't ANSI and our compilers understand some C extensions that aren't in GCC (and not most of the non-standard ones that GCC made up); the default preprocessor is much simpler than ANSI's.
There are also some very specific issues with using Plan 9 as your primary OS, mostly relating to application support. We don't have a GUI word processor, a spreadsheet program, or popular games. Most notably, we don't have a "modern" web browser with CSS and JavaScript support (but see the question about some of those below). Plan 9 does not aim to replace any existing desktop system, and thus using it has a higher initial bar than using systems which do try to fill such a roll.
The Plan 9 community is small but active. The best places to find it are the 9fans mailing list and in #plan9 on Freenode. Several people in both places have been using Plan 9 for a decade or more, and the mailing list in particular gets occasional traffic from the original authors.
The man pages and papers for the system are available online. The wiki has a lot of good information, although the organization is not always as good as it could be.
Read the papers. Read the installation instructions and hardware requirements. Decide what your installation will look like. Download the distribution. Install the system.
Maybe. Before you start, remember that this is not Unix; first look for the Plan 9 way of solving whatever problem it is your Unix application is addressing. Source or binary compatibility with Unix has never been a design goal of Plan 9, so every solution is imperfect. Still, there are times when it's needed, so there are solutions which work well in many cases.
If you've got source for the application, it's reasonably self-contained, and reasonably standards-compliant, you've got a good shot at being able to compile it within Plan 9 using APE, the ANSI/Posix Environment. This gives you a full ANSI C pre-processor, make, a POSIX shell, and a bunch of related tools. The "configure" script for some applications work "out of the box", although many make bad assumptions about linux-specific features.
If you don't have the source or building it on Plan 9 is otherwise infeasable, linuxemu may be of help. This will emulate enough of the linux kernel and system call interface to allow a wide variety of linux applications to run. See the documentation for particular shortcomings.
Related to the above, there is also an X11 server for Plan 9 called equis. It is available from fgb's contrib directory (see below).
Almost certainly not. Remember: Plan 9 is not Unix. While it's true that we have APE and an X11 environment for importing foreign applications or running applications on Unix systems with local display, very large programs like these typically have a slew of dependencies. If possible at all, it would be a lot of work.
The spartan nature of the Plan 9 user interface is one of the first things which strikes newcomers. There are no desktop icons, almost no window decoration, no configuration files, and no Start menu. The simplistic interface is not due to lack of attention, but is rather a conscious design decision. The Plan 9 interfaces follow a "get out of my way" philosophy which, in many ways, runs exactly counter to the common desktop environments on other systems.
The short answer is "no"; the long answer is "kinda". These won't run on Plan 9 directly, but you might have good luck with running them within linuxemu. Firefox, Opera, and dillo, at least, have been shown to work this way, although there are some restrictions on which version of glibc they're built against.
Note also that we do have our own browsers, but they, um... let's call them "basic". In Plan 9, see abaco; in Inferno, see Charon. The version of Charon which ships with acme-sac is particularly neat.
No, certainly not. The distributed nature of Plan 9 - allowing resources to be on a variety of hosts across a network - doesn't mean that you can't run those services on the same host. The system will, for the most part, perform exactly the same with your authentication server on your box versus in another country, for example. The default installation sets up a stand-alone terminal which allows you to get at most of the interesting features of Plan 9.
It is true that some of the distributed nature of Plan 9 shows best in an environment with multiple computers. In particular, separating your terminal from the rest of the system is of particular benefit, but many combinations are possible. You can add systems and move functions incrementally as your use of Plan 9 increases.
Coming soon.
First off, if you've not read the papers, do so. They're available in your new installation under /sys/doc, as well as online. Particularly useful are 9.ps, names.ps, acme/acme.ps, auth.ps, fossil.ps, and plumb.ps, in roughly that order, although they're all worth a read.
Remember that this is not Unix, even though it will sometimes feel like it. Make frequent use of the man pages. They're both more concise and more useful than on most Unix systems.
You'll want to create a user for yourself. When you're just on your terminal, this is easy: you just need to tell fossil, and then create a useful default environment (with newuser(8) or /sys/lib/newuser). It gets a bit more complex when you have multiple systems involved; see auth/changeuser in auth(8) for details.
The default installation gives you a terminal running with a local file system. The easiest way to expand this is to turn your terminal into a combined cpu+file+authentication server and add a terminal booting off that system. Adding additional cpu servers then becomes trivial, and moving authentication to a dedicated server is easy. See the wiki for details.
Bell Labs runs a system called "sources", which contains not only the current system (used for staying up to date), but also a set of "extras" published by the Labs (although largely contributed by others) and "contrib", a set of user-maintained repositories. From within Plan 9, run '9fs sources', and explore /n/sources. An index of the extras and contrib directories is available online (although it's not exhaustive).
Some members of the community also have their own collections; see the wiki page for a list. Also, there's a growing list of Plan 9 or Inferno projects hosted on bitbucket.
There are a few places that hand out Plan 9 accounts. We have a list of public plan 9 servers, but others, likely closer to you, come and go more frequently than that list gets updated. Probably your best bet to find something good is to come ask in #plan9 on freenode.
For a long time, the longest standing and largest user community was the Tokyo Inferno and Plan 9 Users Group, or tip9ug, but they've went down due to a catastrophic hardware failure in the autumn of 2010, and have said they're likely to be down until late in 2011.
. As the name implies, they're in Japan, which makes latency sometimes a bit of an issue.
First, just use the system. Become familiar with it, and participate in the community. Once you're familiar with the system, the best way to help is by writing. If you're a good C programmer, there's lots of things you can do to help. We can always use more driver support. Think about how Plan 9 can help you solve a particular problem, and then solve it and share the results. Write documentation; while we have excellent reference material, we're not so great on "how to" documents at the moment. Take notes on your learning process, and when you're a bit further along, turn them into a nice getting started guide. Scratch an itch.
First, note that Plan 9 runs well in a variety of virtualization systems, including Parallels, VMWare, Xen, and lguest. If hardware support is your primary issue, one of those might solve your problem.
If that's not an option for whatever reason, and you're on some flavor of Unix (including Mac OS X), check out 9vx - a Plan 9 kernel running as an application above Unix. It's not as stable as the "real thing" and has a few quirks, but it works very well for lots of cases.
You can get at many of the Plan 9 ideas without actually running Plan 9. The most complete way is probably Inferno, which in addition to running on bare hardware can run as an application on top of an existing OS. You'll get the same resource distribution mechanism, the same great clean code, and many of the same tools, and Limbo and Dis on top of that. In fact, Limbo on its own probably makes Inferno worth checking out regardless of what you end up doing with Plan 9 (remember you can run Inferno on top of Plan 9, Unix, or Windows).
Beyond that, there are a number of ways to get at bits and piecse of the ideas of Plan 9 in other systems. If you're interested in the cleaner, more consistent user or programming environments, check out Plan 9 from User Space, a port of many of the Plan 9 tools and libraries to various Unix-like systems. If you're interested in using 9P to distribute resources, check out v9fs, a Linux kernel module implementing 9P, or one of the many 9P implementations in various languages.
If you're using one of the alternatives discussed in the previous few questions, there are still good ways you can help. If you're a Unix user, particularly a Linux user, you could package Plan 9 from User Space or Inferno for your particular system. For "extra credit", try to get the results included in the base system. If you're a Windows developer, you could work on porting 9vx or Plan 9 from User Space to Windows. And if you're using Inferno, the best answers are largely the same as if you're using Plan 9 itself: the best contribution is to use the system to solve a problem, and to write, code and documentation. And if your'e a developer in some language other than C or Limbo, it's likely that we could use work on the 9P/Styx implemenation in that language, especially authentication.
