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.
Plan 9 seems to my untrained eyes like a more than modest improvement, but I suspect even immodest improvements will generally not be sufficient to oust an embedded solution that is, as Raymond says, "just good enough."
Choosing one's operating system is not merely about possibility, it's about productivity.
If a system is simpler, and has fewer and more robust APIs that work for more attached systems, then in theory at least it will be less work to program for, the programs will require less maintenance, and tasks will be accomplished with less friction.
The question, of course, is whether this improvement is sufficient to warrant the many headaches of changing operating systems; in general, it isn't, which is why Plan 9 failed.
Sure. So, what's the application that can be built more easily, with less friction, on Plan 9? I'll make it easy; what's the application that's easier to build on Plan 9 than on Win32?
> There is no ftp(1) command under Plan 9. Instead there is an ftpfs fileserver, and each FTP connection looks like a file system mount.
So, an application which needs access to files on another system can make one call to ftpfs, then return to using normal system calls to read and write files. With ftp, you would have to write an application to deal with the ftp client's api instead.
Presumably this advantage wasn't enough to get Plan 9 lots of users.
I don't even think it's an advantage to application developers. Some of the ideas behind application-filesystems have been discredited (for some of the same reasons as RPC was discredited), but more than that, it's just not that much more convenient for the application developer.
In every programming environment I can think of, you're only ever a library call away from FTP anyways.
I think it is an advantage to application developers. A lot of good ideas die because the programmer has to write 900 lines of cruft wrapper code to experiment with a 100 line cool idea, and the programmer never makes it through the 900 lines.
If you can mount web pages as a file system, then you can write a web search indexer in a few tiny lines of code. In fact, you can focus on making simply index-search functionality, and ignore whether it is a web search engine or desktop search engine.
Alternatively, you can use curl or some other library, and you can still get the job done. But you end up thinking a lot more about interface stuff to write applications, and computers end up having huge amounts of duplicate code on them -- curl, the code in various browsers, just numerous different implementations of client http all over the place, and many of them incomplete or buggy.
There's a difference between "an operating system as a platform for developing applications" and "an operating system as a system-level REPL".
As a platform for developing apps: not sure about plan9.
As a hypothetically richer system-level REPL: having a larger subset of "everything" accessible through a filesystem-like interface allowed Plan9 to offer at least the possibility of more possibilities here.
Fuse and the contributed filesystems are pretty close in spirit I think: eg, the grabfs filesystem for macfuse (which gives you access to the per-window images via a file system interface).
It's not about what you can or cannot build. It's about how you build it. For example, if you build a distrubuted system on unix or win32, the MPI API is almost the only way to go for you, which turns your code and entire application into complete mess. Whereas, Plan9 introduces a very different approach, which makes your code neat, lean and robust and you can dynamically add/remove nodes without rewriting and/or restarting your app.
I believe there will come some Linus Torvalds into Plan9 world who will revive the system and its ideas. From my point, Plan9 is ideal infrastructural solution for heavily loaded distributed web systems (AKA cloud networking) and other Web 2.0 stuff.
Operating systems are a means to an end other than building an application. Libraries are a means to the end of building an application. Operating systems are a means to a different end: running multiple applications together.
The way that operating systems do this has changed over the years. At first, it was just by letting one run while the other is waiting on the tape drive, or the user. Later, it was by letting one read the files of the other, or by permitting you to readily use hundreds of kilobytes of memory on a 16-bit machine by connecting processes through FIFOs, or by allowing objects in one process to call methods on objects in another.
There were a number of kinds of interactions between applications that seem like they should be more straightforward to build in Plan 9 than in Linux. I don't have any experience with Plan 9, so I could be wrong about these:
Untrusted processes in Plan 9 can do the equivalent of chroot, and because things like network access go through the filesystem, chrooting them can restrict those things too. Something like VNC, providing a shared window to run graphical applications in, should be nearly trivial to build in 8½, and wouldn't lose accelerated graphics --- it should even be easier than in the VT-100 world where screen runs. Virtual desktop software should be easier, and work better, in 8½ than in X (at least prior to Compiz). Spreading such a large virtual display across more than one physical display, as with x2x (but with the ability to move windows between them) is the same problem as the shared display. A networked chat application should be able to use 9P (within the SSI) and therefore the client should be a simple shell script, while the server merely has to provide a 9P service accessible over the network. And then there are the examples that are actually in the Plan9 papers: exporting your local process namespace to a compute server so that your compute-intensive process there can access all of your local resources transparently; 8½ itself. And of course anything that deals with text on Plan9 can assume it's in UTF-8, rather than guess. (To the extent that's not true, it's because it's trying to interact with programs beyond the boundaries of the Plan9 system. You can't expect Plan9 to make much of a difference for how applications not on Plan9 interact.)
There are any number of features that are implemented currently on Linux, but badly, that a cleaner architecture like Plan9's would support better. x2x is one example; the "virtual filesystems" in GNOME and KDE, which permit you to access network servers and digital cameras and CD audio (but only in some applications) are another. International text is a third; I don't know about you, but I'm constantly running into character-set incompatibilities. (What do you mean, Python doesn't know what encoding my source code is in? And why isn't naïve a valid variable name?) Attempts like Janus and Plash and CPUShare (and Chrome! and Native Client!) to run native code in an environment without full access to your account are, I think, a fourth.
The other disadvantage is that the other OS (Linux, at least), can steal the good ideas of it's competitors. Take /proc for example. Now, plan9 may have a nicer interface, but it cannot compete on a features-level.
The Linux and BSD /proc is a pale imitation of plan9's, though. The most interesting ideas in plan9 are inherently incompatible with Unix because they're direct consequences of a deep overhaul of its security and file/namespace systems. (Much deeper than, say, adding sudo.) The free Unices' /proc filesystems attach to the global filesystem namespace, but on plan9 each process can have its own, and consequently what you can do with them is very different.
(FWIW, I detest the plan9 GUI, and am more interested in microkernel-based approaches such as in Minix 3, but getting into that in any real way is so far down my spare-time-fun list that I can only consider myself a curious onlooker.)
" 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.
By 1994, when I first used Linux, it was vastly better than any other Unixes for interactive use. The basic Unix software was much higher quality than other Unixes (see the original "fuzz") paper for some measurements of this), much more featureful (look at the old joke about GNU Hello, the "hello, world" program with 150 options), and much more usable (e.g. --version and --help, long options in general, tab-completion and WYSIWYG command-line editing in bash; compare to csh !-2:s/vresion/version/).
Linux defaults in 1994: fvwm, rxvt, color (in ls and rxvt), Emacs, Seyon, less. Unix defaults in 1994: twm (or mwm if you were really unlucky), xterm (huge memory hog), black and white, vi (not Vim!), cu, and a more where you couldn't scroll backwards. Also remember term? You could get, approximately, an internet connection through a dialup shell account on Linux, by the simple expedient of recompiling all of your networking software to use term.
When I started using IRIX in 1994, ls to a terminal defaulted to single-column output; find . -follow -print on a directory with symlinks up the hierarchy would infinite-loop; find defaulted to starting from no directories and not doing anything with the files it found; etc. It had a much prettier GUI and 3-D acceleration, though.
Remember also that at the time Microsoft OSes shipped with no TCP/IP support.
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.
