
Plan 9: why no compelling successor to Unix has got off the ground - ionfish
http://www.faqs.org/docs/artu/plan9.html
======
russell
It's a chapter from Eric Raymond's The Art of Unix Programming. His take is
that Plan 9 wasnt enough of an advance over Unix to make a compelling switch.
I think that, except for times when the market is in a state of flux, a new
entrant with a modest improvement doesn't stand a chance. I remember reading a
while back that a newcomer won't blow away an entrenched incumbent unless
there is a 5 to one price performance advantage. This was the world of atoms,
but something like that probably holds in software. Linux won because free
trumps $500 per cpu, and it was really the same thing as Unix.

~~~
vegai
" Linux won because free trumps $500 per cpu, and it was really the same thing
as Unix."

Linux won the hearts of many in mid and late 90's because it was VASTLY better
than the mainstream OS back then. That Linux was the first many tried before
other possible things (minix, bsd, plan9, etc.) most of all was because of the
name.

Yes. The name. Linux sounds cooler than any of the other alternative OSs, and
therefore it won them.

~~~
bad_user
Actually, Linux won over BSD because BSD's legal status was in question when
AT&T sued BSDi.

Also, Linux was appealing for hackers, as even today, it's harder to
contribute to BSD, having a more centralized development methodology than
Linux.

~~~
rbanffy
Not only that. The BSD license does nothing to prevent a competitor from
grabbing your contributions and make a proprietary product with them.

Linux is a better target for companies like Canonical or Red Hat because of
the GPL.

BTW, this is why Linux is a better target for companies like IBM, HP, SGI,
Oracle and so on: because when they contribute something they can expect to
get all other contributions in return. There is no such guarantee in BSD.

And yes. The AT&T lawsuit did not improve BSD's prospects a bit.

------
RobGR
I used Plan9 for a while, I had a project going with some other people that
involved a lot of distributed access, and Plan9 was pitched as solving a lot
of our problems from the start, that we would have to hack around if we used
anything else. (I describe the project down below, for the curious.)

The title, "Plan9: why no compelling successor to Unix has gotten of the
ground" presumes that Plan9 is better than Unix. Plan9 sucks, and is a waste
of your time.

The thesis of this article is that Plan9 was better than Linux, but Linux was
good enough no one had a big enough reason to switch to go to the trouble;
this fails to take into account that Plan9 was dead before Linux ever got out
the door.

One reason for that was the license. For a while it was under some Bell Labs
license that no one was sure was "open source" or not. As the Lucent took over
the labs, and then had troubles itself, there was a lot of uncertainty about
it. At some point the license was changed or clarified or something, and the
new license could possibly be interpreted as allowing you to re-license it
under the GPL, and there were rumours and hints that Rob Pike or some other
iconic figure had told someone the goal of the license was to allow that, but
it was obfuscated to get it past corporate lawyers. That didn't inspire
confidence.

At one point in my life, I am embarassed to say, my goal was to spend the next
year sitting down and reading every single source file in Plan9, putting a GPL
or LGPL license on it, and then re-distribute "Plan9-GPL". I was convinced the
license allowed it, and I figured that if I did it and was the obvious target
for a law suit from Lucent and I was not sued, then Plan9 would take off. One
good thing about Plan9 is that the total number of lines of code is low, one
person could do that. However, like other powerful computer systems, sometimes
there is a lot packed in few lines.

The user interface is worse than TWM. It's main editor basically requires that
you constantly have one hand on the mouse and hunt and peck keys with the
other hand, as if it was designed by one of those old computer illiterate
people who can't type and clutch the mouse in a death grip the entire time
they are in front of the computer. Certain people in the Plan9 "community"
talk about rio like it is something better than Windows 2.0 or Commodore 64
GEM, and make a lot of jwz-like snarky comments about X, but it isn't.

I suspect the reason for this is that no one actually uses Plan9 on a daily
basis. The headers of emails on the 9fans mailing list indicate that everyone
except for a few holdouts uses Outlook. I think they edit their files in
windows, and copy them to Plan9 via ftp or samba.

I wanted to document how to set up a "node" for our project in painstaking
detail. As a result, I repeatedly wipped a disk using dd if=/dev/zero from
tom's root boot floppy, and re-installed again. A few weeks into my
experimenting, they updated Plan9 and it lost the ability to write the MBR, so
I had to fdisk from a linux each time. This remained a bug for nearly two
years, causing me to realize that in all probability, no one in the Plan9
developer community was installing any new computers.

That was a shock to me, as I had invested a lot of money in hardware that
would run Plan9 (specific video cards and wireless cards, mostly) and a HUGE
amount of time. When I saw some poor dude post on the 9fans mailing list 18
months later or whatever wondering why Plan 9 wouldn't boot after a clean disk
install, I knew it was dead and that all that time was wasted.

I believe that most instances of Plan9 are currently run in VMWare on Windows
desktops. If you are doing operating system research, and operating systems
are the interface between application code and hardware, and you need a two
layers of closed source between you and the hardware just to get started, you
have failed.

It may have once been a framework for some cutting edge experiments in
operating systems, and maybe still is. The C compiler it has is fast and nice,
at least compared to gcc of the 2002 era or so. If I had some reason to write
a C compiler, I would dig up the 9c code and take a look at it, and possibly
start there.

I liked a lot of Plan9's ideas, but the whole experience made me appreciate
linux a lot more. I don't think that Linux needs to take the best ideas from
Plan9, Plan9 needs to steal the mediocre ideas from Linux -- like command
completion, how about porting emacs or vi or nano, the basic stuff that allows
you to get to working on the cool stuff.

The people involved with Plan9 seem very interested in the interface between
application code and the operating system, and less interested in the
operating system -- that's why they run Plan9 in Xen on a Linux computer.
However, for people interested in that, they don't seem write much code that
uses that interaction.

========

P.S.: The project was to make this giant tit-for-tat resources trading system
- we were starting with wireless access, so that if a person put up a wireless
access point, you could use it only if you had a wireless access point at your
house that was also open to the first person to use; next we were going to do
offsite storage, so you would make a few gigs available to the system, and get
a quota of a few back, but your stuff would be distributed and replicated
accross many other people's drives thus resistent to disasters; and then a cpu
trading thing similar to folding@home type systems; and so on. There was no
business plan, our goal was to change the world not get rich (the participants
came out of Austin's Cypherpunks group). We had a lot of excitement and hype
going on, and it died due to interpersonal fighting (if you know the
Cypherpunks from that time period you know what I'm talking about).

~~~
dmm
Plan 9 admittedly sucks in many ways. It has limited hardware support, a weird
user interface, and no active community. But also has redeeming qualities that
I miss every day that I have to program on linux.

In Plan 9 every process has a namespace associated with it that represents all
the resources it has access to. For example, /dev/mouse represents the mouse
in Plan 9. But typically it isn't provided by the kernel but by the window
manager, rio. So when you open rio it opens the mouse and then provides a new
/dev/mouse for each process launched within it. Every process has a different
/dev/mouse that only activates when the mouse is in that process's window(if
it has one).

To draw to the screen there is one function: draw(). You pass it two rasters
and some coordinates and it draws one on top of the other. That's it.
Everything works across networks and architectures.

The thread library is wonderful. Threads in Plan 9 are non-preemptive and run
in a round-robin fashion. They communicate using CSP channels. CSP can greatly
simplify the design of many programs.

In a few of the programs I wrote would access the mouse and keyboard in
seperate threads. You could use the regular open() and read() calls from each
thread and there was no need to worry about locks. When I wanted something to
run on both cpus I forked a process, which is very cheap.

The text editor, acme, is different and probably sucked for you. But that is
because you misunderstood what it was. In linux and windows programs are
islands. These islands are expected to provide everything the program does in
one executable. Acme is not an island. It does not have a builtin spell
checker or word counter. What it does have is a namespace that allows you to
access its resources.

Plan 9 is a system which was deliberately made by very smart people. It has
serious issues which make it not often a realistic choice, but it has a
clarity and consistency of design that linux will never know.

~~~
JabavuAdams
> It has serious issues which make it not often a realistic choice, but it has
> a clarity and consistency of design that linux will never know.

Fail. Reality is crufty.

~~~
dmm
Ha, I agree with you, really. Reality is crufty and getting things done
involves compromise.

Still, I think there is value in studying other ways of doing things. For
example, my studies of Plan 9 introduced me to CSP, erlang style concurrency,
which is a great way to structure some types of programs.

And don't forget that some problems can only be solved by introducing
simplicity at some level. For example, google achieved high levels of
reliability and scalability by using a simpler computational model: map-
reduce.

------
ionfish
I'd forgotten that text doesn't show up with a link submission. Here's what I
posted originally: Not new, obviously, but an interesting story for those of
us who don't know it, and some generally applicable lessons. "In 2003 it looks
like 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."

------
natch
My long-held theory is it failed for lack of a blurb. When you visited the
site, it was hard to figure out what Plan 9 was exactly. Digging into the
documentation produced a link to a gzipped .ps file, and after installing
Ghostscript, then Ghostview, then some fonts, then uncompressing the file and
viewing it, one could read an academic paper describing in arcane language
some problems of interest to file systems theoreticians. This state of affairs
continued for years. Not surprising at all that it failed to get much
traction.

------
derefr
A simple question: Rather than waiting for Linux to slowly absorb Plan 9's
ideas, would there be some way to take all of Linux's drivers, scheduling, and
other such excellent-but-non-OS-specific code, and code a new Plan 9 on top of
that?

~~~
sqweek
<http://glendix.org>

------
kqr2
For anyone who wants to play with it, there appears to be a live CD:

<http://plan9.bell-labs.com/plan9/download.html>

~~~
likpok
There are issues with the livecd. I couldn't get it to boot in modern VMware
(they use version 4 or so). I recall having problems booting it on a physical
system.

Not to dissuade people, but try and research which VMs/hardware it supports
/before/ trying it out.

------
bprater
FTP mounting as a filesystem was the big thing? Wowzers.

~~~
jfoutz
I think taking the standard read write calls on arbitrary underlying
implementations to the logical limit was the big thing.

unix is nice, because you can read off a file or a socket or a mouse or a
disk. This lets you do that over ... anything, i guess.

