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