OK, my other post didn't really "explain the elements which make Plan 9 stuff awesome (in noob terms)". Here is one that attempts to, while not duplicating what's already been said.
It's been said already that on Plan 9 you've got the same interface to local and remote resources. That's cool and all, but how many computers have you got, really? And how many of them run Plan 9?
So here's a related example, a corollary almost, of local vs remote.
You see, it isn't just local vs remote, it's also in-kernel vs user-mode. On most systems, you make system calls to ask the kernel to do something for you, and you make library calls to access functionality that's been implemented in user-mode.
In Plan 9, you've got some system and library calls, but for most services you've got the same interface whether they're in the kernel or in user-mode. REgardless of what language they're implemented in, too.
In the 90's, Plan 9's networking interface was a user-mode filesystem written in Alef. The IP stack was, the hardware drivers were in the kernel though.
In 2000 or so it was all moved into the kernel (except the connection server). But it was still a filesystem. The same interface. A service was moved from userspace to the kernel, and the method of accessing it didn't change, so no programs had to be changed, or even relinked or recompiled.
I mentioned the connection server (cs). You wanna know about the cs? Basically, it's a program that understands network types FOR YOU, so you don't have to. You _could_ access the network without cs, but the feel would basically be the same as using sockets: you would have to know whether you're connecting to TCP, UDP, or other, and make different calls accordingly; you would have to know whether your user has passed you a DNS name or an IP address; etc. With cs, you ask cs to do it, and nicely receive a file descriptor to the correct type of network.
That IPv6 support was added without changing any programs is due to cs. This sounds similar to the other example, but it's different. In the first example, the implementation changed but the _types_ of networks supported remained constant. The Blue Gene has all sorts of esoteric networks not used anywhere else. Only thing that had to be done to Plan 9 was write the hardware drivers and teach cs the new networks.
If I could make this post shorter and still have all the same information, I would, honestly. But I could talk for hours about Plan 9.
Plan 9 is basically a redesign where your files and username/password are centralised like on a Unix network with dumb terminals (70s up to mid 80s Unix), but at the same time, you're able to make use of the local resources of your "terminal" like use the CD driver or a scanner or whatever. You have access to them as if you're root.
Plan 9 says: whoever turns the machine on is basically root. If you have physical access to the box, you could theoretically fuck it up any way you wanted, so we might as well just give you root - there's nothing valuable (security wise) on a terminal anyway. Enjoy your CD drive.
The paragraph before the last one is more important than you think. You see, all that other stuff I said about /net, that came afterwards. The original goal was just to have centralised auth and (disk) fs, and stateless terminals. But then, all that other stuff we have in Plan 9 (e.g. network transparency, no real superuser) sort of emerged as a corollary of that first goal.
Other things that Plan 9 users are obsessed with (e.g. mouse chording, output which is usable as input, etc) more fall under the category of things with would be equally easy or difficult to implement regardless of the underlying OS.
I'm really glad we've got all these nice things under one OS, because it's totally conceivable that someone could have designed an OS where (say) everything is a file, but doesn't have (say) clean readable code. We have both, but we also have relaxing colours, mouse chording, easy-to-use concurrency, and a cool mascot.
It's been said already that on Plan 9 you've got the same interface to local and remote resources. That's cool and all, but how many computers have you got, really? And how many of them run Plan 9?
So here's a related example, a corollary almost, of local vs remote.
You see, it isn't just local vs remote, it's also in-kernel vs user-mode. On most systems, you make system calls to ask the kernel to do something for you, and you make library calls to access functionality that's been implemented in user-mode.
In Plan 9, you've got some system and library calls, but for most services you've got the same interface whether they're in the kernel or in user-mode. REgardless of what language they're implemented in, too.
In the 90's, Plan 9's networking interface was a user-mode filesystem written in Alef. The IP stack was, the hardware drivers were in the kernel though.
In 2000 or so it was all moved into the kernel (except the connection server). But it was still a filesystem. The same interface. A service was moved from userspace to the kernel, and the method of accessing it didn't change, so no programs had to be changed, or even relinked or recompiled.
I mentioned the connection server (cs). You wanna know about the cs? Basically, it's a program that understands network types FOR YOU, so you don't have to. You _could_ access the network without cs, but the feel would basically be the same as using sockets: you would have to know whether you're connecting to TCP, UDP, or other, and make different calls accordingly; you would have to know whether your user has passed you a DNS name or an IP address; etc. With cs, you ask cs to do it, and nicely receive a file descriptor to the correct type of network.
That IPv6 support was added without changing any programs is due to cs. This sounds similar to the other example, but it's different. In the first example, the implementation changed but the _types_ of networks supported remained constant. The Blue Gene has all sorts of esoteric networks not used anywhere else. Only thing that had to be done to Plan 9 was write the hardware drivers and teach cs the new networks.
If I could make this post shorter and still have all the same information, I would, honestly. But I could talk for hours about Plan 9.
Plan 9 is basically a redesign where your files and username/password are centralised like on a Unix network with dumb terminals (70s up to mid 80s Unix), but at the same time, you're able to make use of the local resources of your "terminal" like use the CD driver or a scanner or whatever. You have access to them as if you're root.
Plan 9 says: whoever turns the machine on is basically root. If you have physical access to the box, you could theoretically fuck it up any way you wanted, so we might as well just give you root - there's nothing valuable (security wise) on a terminal anyway. Enjoy your CD drive.
The paragraph before the last one is more important than you think. You see, all that other stuff I said about /net, that came afterwards. The original goal was just to have centralised auth and (disk) fs, and stateless terminals. But then, all that other stuff we have in Plan 9 (e.g. network transparency, no real superuser) sort of emerged as a corollary of that first goal.
Other things that Plan 9 users are obsessed with (e.g. mouse chording, output which is usable as input, etc) more fall under the category of things with would be equally easy or difficult to implement regardless of the underlying OS.
I'm really glad we've got all these nice things under one OS, because it's totally conceivable that someone could have designed an OS where (say) everything is a file, but doesn't have (say) clean readable code. We have both, but we also have relaxing colours, mouse chording, easy-to-use concurrency, and a cool mascot.