
Plan 9: The way the future was - niyazpk
http://catb.org/~esr/writings/taoup/html/plan9.html
======
jbarham
Unsurprisingly given the common pedigree, a number of ideas from Plan 9 have
made their way into Go. E.g., compare <http://golang.org/pkg/net/#Dial> and
<http://plan9.bell-labs.com/magic/man2html/2/dial>.

Go's approach to concurrency is familiar in the Plan 9 world from Alef
(<http://en.wikipedia.org/wiki/Alef_(programming_language)>,
<http://swtch.com/~rsc/thread/alef.pdf>) and Limbo
(<http://www.vitanuova.com/inferno/papers/limbo.html>), the language used to
implement Inferno, a Plan 9 spinoff.

~~~
dhconnelly
Cool. I wasn't sure if it was common knowledge that Ken Thompson and Rob Pike
created Go. The Go compiler toolchain is from Plan 9, too:
<http://golang.org/cmd/>.

------
haberman
Am I the only one who doesn't get excited about the idea of absolutely
everything being a file?

People seem to like the idea of being able to say things like "cat file.wav >
/dev/dsp". But a sound card is a complex thing that can be configured in
umpteen different ways; what if the file has a different sample rate than the
card is currently running at? Even if you gerry-rigged a kernel driver that
could handle this case (by, for example, noticing when the file had been
open()'d and expecting the next bytes to be a WAV header, which it uses to
reconfigure the card), you're left with something that doesn't have even the
most basic functionality that you'd expect from a sound player; for example,
"pause."

So what has representing /dev/dsp as a file really bought you? It doesn't help
you know what devices are available, because there's tons of crap in /dev that
doesn't necessarily have a kernel driver loaded for it. It's not that useful
as an end-user interface for selecting a sound card, because users don't want
to choose between /dev/dsp and /dev/dsp2, they want to see nice names like
"Internal Speaker" or "Apogee Duet."

Files give you a simple API for lots of common operations, which is nice, but
the fact that all files are not created equal means that operations sometimes
don't work like you expect. For example, how would you guess that "tail -f" is
implemented? If you're like me, you would have expected that it works by
calling poll/select/etc. and waiting for the file to become read-ready. But
this approach doesn't actually work for monitoring growing files; the select()
will just return immediately with read-ready even if you're at EOF. So what
"tail -f" actually does is a loop that alternates between sleep() and fstat().
I'm serious!
[http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...](http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/tail.c;h=29ddabd62c650c4b0c9ed9b52bb3270e25f1bb90;hb=02551d8a62d84b8788a8793de121c2f1e5212d63#l1071)

~~~
strictfp
You could configure it by doing something like

    
    
      echo "22050" > /dev/dsp/config/sample_rate_hz
      echo "lanczos" > /dev/dsp/config/resample_algorithm
    

You could then search for configs by using find, back them up by using tar, be
able to easily replicate settings between computers using rsync etc.

The idea is not to have one unconfigurable binary reciever, but rather to
expose the interface as a hierarchy of rw files instead of a number of C
functions, because the C functions have no easy shell representation, and most
command-line tools fail using them.

It's very reminiscent of REST.

~~~
dalke
That API seems so clunky. What if I have two different programs, with
different sample rates, which I want to play back at the same time?

~~~
angersock
Each program sees its own copy of /dev/dsp. Behind the scenes, that copy is
backed by some magic on the OS's part that handles state tracking, mixing,
etc.

The program only ever sees a dumb bit bucket with some flags on how to handle
it--that's why we have OSs, after all: to avoid having to write hardware
driver code for all our programs (see the bad old days of DOS game
programming).

The program still needs to manage sound mixing in userland to fill that
buffer. That's nothing new, however, and you can use PortAudio, FMOD, XACT,
whatever to do that mixing for you, or roll your own.

This abstraction would greatly simplify that process.

~~~
dalke
Thanks to you and others who pointed out that plan9 exposes private copies to
each program. I did not know that, and it would solve the issue I wondered
about.

But that doesn't solve the underlying issue. If my program uses two libraries,
both of which play sounds, then how does each library get its own
configuration filesystem? Is there a way to create a new view, so that the two
libraries can be disconnected from what the main program needs?

------
thristian
The impression I got was that the guys behind Unix were annoyed when their
operating-systems research was stalled in the name of "API compatibility", so
they started Plan 9 and actively resisted commercialisation for as long as
possible (for example, they gave it the least marketable name they could think
of).

There's so many interesting ideas in Plan 9, I'm occasionally tempted to
install it and try it out... but then I read things like the list of keyboard
shortcuts in the standard editor acme¹, and I get cold feet.

¹: <http://acme.cat-v.org/keyboard> \- in particular, note that there are no
keyboard shortcuts for 'move the cursor to the next/previous line'. Think
about _that_.

~~~
4ad
The problem wasn't that the Plan 9 guys opposed commercialization, quite the
contrary, the problem was that AT&T never let the system become open source.
For some time it wasn't even available outside universities. That killed it.

Yes, acme doesn't have keyboard shortcuts, I use it every day.

~~~
hollerith
>the problem was that AT&T never let the system become open source.

The whole thing except the fonts was put under a very liberal open-source
licence 10 or 12 or so years ago. (By then it was owned by Bellcore or Lucent,
not AT&T.) Before then there were severe restrictions; is your opinion that by
time the severe restrictions were lifted, it was too late because Linux had
already become entrenched?

~~~
4ad
Yes, it was made open source in 2000, 8 years after the first release of 1992,
far too late.

------
pavpanchekha
First, one should note that this is a chapter (or section) of "The Art of Unix
Programming", by esr; it is a fantastic book (I'm going through it now, on
chapter 9 of 20, and the wisdom has been near-palpable).

As for the specifics of the article. Plan 9 did indeed do many things right;
in fact, many things are done in a very Unixy way. For example, the networking
stack is build precisely where it ought to be: as a detail below a powerful
network protocol (9P) which can be made as transparent or concrete as
necessary (one can easily write individual TCP or UDP packets using the file
system; just as easily, you can network-export any file system).

Similarly, Plan 9's handling of security, in particular the elimination of the
superuser, was fantastic. And while I in particular disagree with the approach
Plan 9 takes to the GUI, it is certainly a consistent, powerful, and inspired
model. And a variety of its other ideas, such as UTF-8 and the /proc and /sys
file systems, have worked their way into modern Unixes such as Linux.

Now, Plan 9's failure has been aptly explained elsewhere, in particular in the
article linked. But, being somewhat old (2004, I believe; though when that
particular section was written I do not know), it makes the prediction that
Unixes will eventually come to absorb all of the Plan 9 features. Instead, it
looks like the Linux kernel, at least, has mostly given up on ever
implementing union mounts (one of the most inspired of Plan 9's innovations,
at least in my view). And while the /net file system is incredibly useful, its
power is much diminished when you can't assume that the world speaks 9P, which
will seemingly never be the case. And a variety of Plan 9's choices are
impossible without ignoring POSIX compatibility, which causes problems of its
own.

Unix rode the growth of servers in the seventies and eighties, and is by now
rather entrenched (see the History chapter in Art of Unix Programming); much
like the WIMP GUI metaphor rode the personal computing wave. I think both of
these areas are by now too old and entrenched for us to simply replace the
current monopolies there. And I've come to terms with the fact that Plan 9
will never, ever become the standard OS --- it is simply not designed for any
battlegrounds except those it has already lost in. But I strongly urge anyone
designing an OS (or, really, any sort of all-encompassing computer system) to
look over the innovations and ideas of Plan 9. Luckily, I don't think anything
like Windows or Unix will win in a totally new environment, because Windows
and Unix aren't made for any environments but their own. So while Plan 9 never
won, I think its ideas have a good chance of living on. And I await an
exciting time of innovation in Operating Systems in the coming century.

~~~
cturner

        > And I've come to terms with the fact that Plan 9 will
        > never, ever become the standard OS --- it is simply
        > not designed for any battlegrounds except those it
        > has already lost in
    

Why is 9p cool? Are there any gaps - for example - lack of good support from
scripting languages?

Have there been any serious attempts at creating a plan 9 rackspace or cloud
service? Maybe you could get a hobbyist community grown around plan 9 + 9p.

I haven't looked at plan9 for ages, but remember there was some complexity
about setting it up for ssh access.

Update: fgudin pointed me to this for hosting <http://sdf.org/?join>

~~~
jff
9P is cool, but 9P is not Plan 9. 9P is the Plan 9 filesystem protocol.

Plan 9 lacks emacs, bash, C++, and a full-featured web browser; this alone is
enough to make a lot of people post once on the mailing list bitching about
it, then never come back. It does have vim now, although its use is not
encouraged because we have other editors.

If you come at Plan 9 as though it's "just like Unix", you're going to have a
bad time. Expecting to access it via ssh is one part of that--yes, we have an
old ssh server, and yes we now have ssh v2 client support, but to access a
Plan 9 system you want to use something like drawterm on Linux/Windows/Mac or
cpu from another Plan 9 system.

I'm on sdf but have not played with my Plan 9 instance much. If you want to
start off experimenting, I'd recommend just firing up VMware or Virtualbox
instead. If you decide you want a physical Plan 9 system, well, I've found
that it runs pretty well on every Thinkpad I've ever tried.

If you want more info, you can ask here or email me (check my profile).

~~~
rbanffy
Are there reasons why it would be hard to port Unix software to it? Could
something like Cygwin be developed to help make it easier to run Unix-ish
software on it?

~~~
koenigdavidmj
It comes with a library called APE (see [1]), which provides most POSIX-y
things implemented in terms of Plan 9 native API:s. (For example, BSD socket
operations are just functions wrapping the normal file reads and writes that
you would do in native Plan 9 code.)

Some things do not work, though (permissions models are a bit different, and
chroot is entirely unimplemented, for instance).

1: <http://doc.cat-v.org/plan_9/4th_edition/papers/ape>

~~~
rbanffy
That shouldn't prevent things like scripting languages or web browsers to be
ported.

~~~
jff
The difficult thing is getting it ported _correctly_. As several people have
shown, it's easy to get Go running. However, getting Go running properly in
such a way that you can continue to get updates from upstream is much more
difficult. So you end up with ancient versions of gmake, gcc, python,
mercurial, Go, etc., all mostly-functional but no longer getting bugfixes,
because it's much more difficult to make a nice clean port that can be
accepted into the upstream.

Oh, and given that the major web browsers all seem to be written in C++, and
we don't have a C++ compiler... that's problematic.

------
shimon_e
The real shame is that inferno never became android. It was around early
enough. Had the right feature set. I guess it was not in Google's backyard
(America) and had lost it's backbone a little to early.

I guess when Google was shopping for mobile OS they were also looking for a
talent grab. With Inferno by 2005 most had already left.

~~~
sambeau
True, but, they already had all the talent from Plan 9

------
gioele
Plan 9 was and is too good to be ignored. Indeed many of its features are now
a must in Linux systems (for example good support for private namespaces) and
the p9fs, designed to be virtualizable and distributed, is getting serious
traction in the virtualization world (see 9p virtio).

And Plan 9 also has the best mascot around!

~~~
mdwrigh2
It helps that Eric Van Hensbergen, the guy behind 9p virtio, was a Plan 9
developer.

~~~
4ad
s/was/is/

He was one of the guys that ported Plan 9 to the Blue Gene supercomputer. He
has many active projects in the Plan 9 community.

------
mhw
I've often thought that Plan 9's everything-is-a-file system with a consistent
API for access is the missing link between Unix's everything-is-a-file and
REST's consistent interface constraint. I think it's certainly arguable that
Plan 9 shares many features with RESTful architectures.

------
rbanffy
This need updating. "The Room", a film that came after the article was
written, is obviously worse than either "Manos" or "Plan 9", as anyone who saw
even its first minutes will readily attest.

edit: I'm sorry. I often forget my colleagues are humourless at this time in
the morning.

~~~
astrange
I think "Birdemic" would be more appropriate, since the first half is about
someone pitching a tech startup (and the second half is about being vomited on
by animated GIFs of birds).

~~~
rbanffy
I can't disagree with facts. According to IMDB,
<http://www.imdb.com/title/tt1316037/> is worse than
<http://www.imdb.com/title/tt0368226/>

------
runjake
Plan 9 wasn't a failure and it wasn't the future, directly.

It was a research OS that was never even close to being positioned to market,
be it consumers, servers, etc -- although technology coming out of Plan 9 did
make it into some commercial applications.

Indirectly, Plan 9 technologies (or inspired successors) made their way into
real products. Linux's procfs is one notable example.

------
wladimir
It seems that (almost?) everything that was planned out for plan9 is finding
its way into operating systems.

The ideas were good, but somehow they had to take the long way around. It was
way ahead of its time.

~~~
_delirium
I remember an interview with one of the ex-Plan9 people now at Google (Rob
Pike maybe?) talking about how he's switched to Linux, since that's what
Google runs on, and finds it a strange experience, as if a bunch of bugs you
thought you'd fixed 20 years ago have resurfaced in the main branch. But Linux
does seem to be picking up a steady number of the features.

~~~
shimon_e
It was Rob Pike from the slashdot interview.
[http://interviews.slashdot.org/story/04/10/18/1153211/rob-
pi...](http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-
responds)

~~~
johncoltrane
Thanks for the link. (irrelevant: I like how he used wOOd to represent OO
programming)

------
mhd
I always find it pretty sad that while everybody speaks about the integrated
environments of Smalltalk and Plan 9, Niklaus Wirth's Oberon is almost left
forgotten…

~~~
adbge
One of the Plan 9 papers actually refers to Oberon as an example of a
similarly integrated system. I believe it's the one titled 'The Use of Name
Spaces in Plan 9,' but I'm not certain.

Unfortunately, the server is down right now so I'm unable to check but, if
you're curious, the various papers can be found here: <http://plan9.bell-
labs.com/sys/doc/>

~~~
mhd
Probably the acme paper. Oberon definitely had the mouse chording, not sure if
there's previous art in that regard.

------
gosub

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

Isn't this concept applicable to every system once it incorporates
programmability?

------
6ren
Ugly now beats beautiful later.

An elegant solution requires a deep understanding of a problem, and that
understanding takes a lot of data (awareness of cases), and then a lot of time
and effort to create a simple theory of it and to create a simple solution
embodying that theory.

~~~
bct
The trick is to build ugly systems that are able to grow into beautiful ones.

~~~
jff
That is quite a trick. The problem is that pretty soon, everyone depends on
the behavior of the ugly warts in your original system, so now you're stuck
with them lest you break the holy Compatibility.

------
morphles
I recently tried plan 9 for a bit. Though i understand all the cool things it
does and agree with a lot of it. One thing really disappointed and struck me
as totally brain dead: there is no such thing as terminal emulator or it seems
something like text only mode. In general it seems to me that achieving
keyboard only control (that is comfortable to use) is not really possible at
least for now.

------
angli
A good introduction to the Plan 9 UI I found, for any who are interested:
<http://vimeo.com/7748726>

------
Craiggybear
"Those who don't understand UNIX are condemned to reinvent it. Poorly." –
Henry Spencer

~~~
atuladhar
Except that Plan 9 was designed by the people who built UNIX. Are you implying
that the people who built UNIX don't understand it?

~~~
Craiggybear
No, no! Quite the reverse.

