If I want to access files from a remote machine — mount its file system. Want to play my music from my laptop using the speakers connected to my stationary computer — mount its sound card into my device folder. If want to use another machine as a network gateway — I mount its /net.
Even the editor acme has its own file system, which makes writing a script doing something fancy in my editor really easy. The file system gives easy access (read/write) to anything from the currently selected text in each window, to the "menu" at the top (called the tag). And if I write a script, it is executed anywhere in acme by middle clicking its name.
What makes this all work smoothly is that mounted file systems can overlap, and that each process is presented its own name space. This completely removes the need for symbolic links and unix sockets.
Wow, that sounds really powerful. I've just read a bit about inter-process communication and sharing in Linux, and that seems like much more of a hassle than this.
> Even the editor acme has its own file system, which makes writing a script doing something fancy in my editor really easy. The file system gives easy access (read/write) to anything from the currently selected text in each window, to the "menu" at the top (called the tag). And if I write a script, it is executed anywhere in acme by middle clicking its name.
That sounds like it might be the answer (an answer) to something I've been wondering about: how to let another process - outside the editor - have access to the contents of the editor. Like for example synchronizing the editing/viewing of a file, instead of the outside process only using the file stored on the disk, and reloading whenever the editor saves the file. Could one use the file system of Acme to have another process view for example the file that it is being used to edit, in real time? I'm thinking that something like that might be useful for collaborative editing (at the least, letting one person edit the file while the other person watches the editing, maybe in the same kind of editor but hopefully through whichever editor or program that she wishes to use).
Here is a video of using Acme, and a port of Plan 9 userspace tools to other systems:
It is the logical successor to unix that never took off because unix is "good enough"
The programming language (Plan 9 has its own C dialect), breaking with POSIX, abolishing the process/thread dualism and doing away with the root user just to name a few.
By getting rid of all these inherited liabilities they were able to create a much slicker, much more uniform and most importantly truly network centric OS, which in many aspects (not necessarily in terms of performance) still surpasses modern unix-derived operating systems(you know...the usual suspects). On the other hand the lack of backwards compatibility and the high barrier of entry prevented Plan 9's widespread adoption outside the research community.
On the contrary if we need new functionality today the way to go seems to be piling new layers of abstraction on top of the already overly complex stuff we gatherd over the years until everything becomes an incomprehensible mess of special cases(16 million loc linux kernel, anyone?). That of course is a good ol' tradition, which started when we first fumbled network support into the unix kernel and thereby broke the open-read-write-close interface convention.
To summerize: Plan 9 is not Unix. Thankfully...
Access everything like a local filesystem: ftp, ssh, etc. it's all built-in and just works.
That is; Plan 9 is a research project and it is relevant the way research is relevant: For the future.
In some alternate Microsoft strategic universe it might have been released as "OS/2 3.0", but it has effectively no inheritance from the OS/2 1.x/2.x/3.x code base.
With that said:
* All services are network-enabled file servers speaking a common protocol called 9P.
* UI makes heavy use of mouse chording, is inspired by Oberon and old school Smalltalk environments. Supports seamless interaction through an inter-application messaging mechanism called plumber (e.g. you can write a rule that will make all ISBN numbers in a desktop application automatically act as a hyperlink to a web application).
* The rc shell fixes a lot of deficiencies in the Bourne shell.
* Per-process namespaces obsolete a whole lot of things like symlinks.
* There is no superuser (root account). This is obsoleted by an auth server called Factotum.
* Uses its own compiler suite that makes cross-compilation particularly easy, compared to the mess of doing so with GCC. It also uses its own much cleaner libc routines that are quite distinct from POSIX or the messy glibc additions of today. Has its own thread library, as well.
* All network information is held in a text file database mounted on a file server.
* The default file system (Venti) is inherently versioned, introspectable and has backup built into it. You can do things like swap in libraries from cache and revert changes without a hitch.
* Everything is statically linked.
* Uses mk instead of make.
* A lot of things like recursive copy and find aren't built into the standard commands. It's expected you actually chain together commands instead of reinventing the wheel for every single operation. The canonical example is the use of du to walk the file system tree, for everything. This replaces find and other things.
* Designed not just to be multi-user, but multi-tenant. Makes many uses for containers and access controls unneeded because of its core design.
* So much more.
Try it. It's more relevant now than ever.