Hardware Reference
In-Depth Information
Now the absence of an API is not always a good or bad thing. If you used Plan 9 every day and wrote programs
and tools just for Plan 9 it would not matter in the slightest that it did not have an API. After all, you would be so used
to the 9P2000 protocol. Now you will notice there are very few programs from other operating systems ported to Plan
9. This is where not having an API comes at a huge cost. Most modern operating systems such as Linux, Mac OS, and
Windows all have APIs. So if you wanted to port the LibreOffice package to Plan 9 you would need to change every
single API to fit with Plan 9's 9P2000 protocol. That's not an easy task for anyone!
Plan 9 makes heavy use of the concept that all objects are files on a filesystem. In Plan 9 you manipulate a file to
get something to happen in much the same way you can in Linux or Unix for that matter, but Plan 9 uses this concept
for everything. The logic behind this is simple: if everything is a file it's very easy to distribute something across the
network as part of the grid. Let me give you an example. In Plan 9 your keyboard and mouse of your local terminal can
be represented as
/dev/kbd
and
/dev/mouse
and they are just simple stream devices. On a remote terminal node I can
mount up your
/dev/
filesystem and write to your
/dev/mouse
stream device file. I would then be moving your mouse
on your terminal. This concept can be applied to any device connected to the Plan 9 systems. After all, everything
from your mouse to your local storage is just a file on a filesystem somewhere.
Given the fact you can mount (or
bind
as it's referred to in Plan 9) any remote filesystem how do you manage
paths? Under Plan 9 you can bind many directories to one top-level directory. Say, for example, you have the following
list of directories:
/usr/local/bin
•
/usr/contrib/bin
•
/home/brendan/bin
•
In Unix and Linux you would fiddle with your system's path variable to ensure your applications can be executed.
In Plan 9 you would bind the directories to the main
/bin
directory. This would make any files under
/usr/local/bin
appear as if they were part of the
/bin
directory. This concept is similar to hard links in Unix and Linux but works on a
directory level and is not destructive.
There are two other filesystems in Plan 9 that have a lot of functionality: they are the
/proc
and
/net
filesystems.
The
/proc
filesystem is similar to what's found in Unix and Linux but has many more features. With Plan 9's version
of
/proc
you can control applications with basic system tools to get the same functionality as an API call to an
application in Unix and Linux. This is why Plan 9 has no API: you manipulate files on the filesystem instead.
Then you have
/net
: this is how you set up your network and gain information about your network. Each
configuration is read or written into files inside
/net
. There are even files to represent TCP and UDP data streams.
This all sounds pretty interesting, but before you jump into Plan 9 there are a few small things you must
understand. First, Plan 9 is built around a three-button mouse. In Plan 9 the left mouse button is solely used to select
text on the screen. The middle mouse button is for menu and context choices and the right mouse button is for
high-level options like moving a window around. You can simulate the middle mouse button with the Shift key and
the right mouse button, or your mouse's scroll wheel can sometimes act like a third button. Using this method gets
annoying quite quickly so see if you can find a three-button mouse.
Another odd thing is that when you're using an application that gives out scrolling text, Plan 9 will not scroll the
output of any window by default. This means that if your text file is three pages long, unless you scroll the window
yourself you will be stuck on page 1. You can use the arrow keys or the scroll wheel on your mouse to move the output.
■
Note
Unlike in Linux and Unix, the Delete key, not Crtl+C, in plan 9 will terminate a running job.
Plan 9 also has some funny jargon. Take a look at Table
11-2
to see some of the more common ones.
