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.
