Plan 9 admittedly sucks in many ways. It has limited hardware support,
a weird user interface, and no active community. But also has
redeeming qualities that I miss every day that I have to program on
linux.
In Plan 9 every process has a namespace associated with it that
represents all the resources it has access to. For example, /dev/mouse
represents the mouse in Plan 9. But typically it isn't provided by the
kernel but by the window manager, rio. So when you open rio it opens
the mouse and then provides a new /dev/mouse for each process launched
within it. Every process has a different /dev/mouse that only
activates when the mouse is in that process's window(if it has one).
To draw to the screen there is one function: draw(). You pass it two
rasters and some coordinates and it draws one on top of the
other. That's it. Everything works across networks and architectures.
The thread library is wonderful. Threads in Plan 9 are non-preemptive
and run in a round-robin fashion. They communicate using CSP
channels. CSP can greatly simplify the design of many programs.
In a few of the programs I wrote would access the mouse and keyboard
in seperate threads. You could use the regular open() and read() calls
from each thread and there was no need to worry about locks. When I
wanted something to run on both cpus I forked a process, which is very
cheap.
The text editor, acme, is different and probably sucked for you. But
that is because you misunderstood what it was. In linux and windows
programs are islands. These islands are expected to provide everything
the program does in one executable. Acme is not an island. It does not
have a builtin spell checker or word counter. What it does have is a
namespace that allows you to access its resources.
Plan 9 is a system which was deliberately made by very smart
people. It has serious issues which make it not often a realistic
choice, but it has a clarity and consistency of design that linux will
never know.
Thanks for your insights. I agree that from the point of view of a developer writing complex applications simply, Plan 9 is on the right path. What I read of the cleaner operating system interface is what attracted me to Plan 9 at the start.
I think a lot of the "new" things in programming are also attempts to fill that same need, of a cleaner, simpler interface to the underlying computer. All the "frameworks" out there, Android even, are attempting to clear that tangle of OS interface that has grown up underneath the applications.
However, to have any of the nice design and brain-work come to real usefulness, Plan 9 has to actually address the grundgy parts of the problem. The hardware support must be there -- not for all hardware out there, but you have to get the items that have huge market share and are cheap. The user interface needs to be improved of course, and I think the community is actually pretty active and helpful for it's size -- if other issues were attacked, that would take care of itself.
Thinking over how Plan 9 failed, I am reminded of rms's assertion that there is a GNU operating system, and that there was so much work to do GNU ended up writing everything else except the kernel, and thus GNU is most often used with the Linux kernel from somewhere else. Plan 9 is kind of what an operating system that just has a kernel looks like. They need to copy large parts of GNU as quickly as possible.
I realized what acme was, but I never even attempted any spell-checking or fancy features. I may not have tried hard enough, but I had problems simple placing the cursor where I expected, and simple stuff like that. I never gave it hours uninterrupted learning and experimentation, which is what I did when I decided to become as good at vi as I am with emacs; given the whole Plan 9 system seemed dead, it didn't seem worth it.
If I had infinite money and were dictator of the world and etc, here is what I would do to make Plan 9 happen:
-- Make sure that the cheapest Dell laptop had complete hardware support. Note that this is something that Linux often fails at, and even Windows has problems in this area.
-- Re-license it under the GPL (maybe BSD) licenses. If that is not allowed under the current license, it is conceivable that a small number of smart people could re-write it in a year, using the Lucent as a template, and possibly improving certain areas as they went. Even if they tossed the hard features, once a self-hosting, working, useable system was available under the GPL, a larger community could re-address the problem areas.
Ha, I agree with you, really. Reality is crufty and getting things done involves compromise.
Still, I think there is value in studying other ways of doing things. For example, my studies of Plan 9 introduced me to CSP, erlang style concurrency, which is a great way to structure some types of programs.
And don't forget that some problems can only be solved by introducing simplicity at some level. For example, google achieved high levels of reliability and scalability by using a simpler computational model: map-reduce.
In Plan 9 every process has a namespace associated with it that represents all the resources it has access to. For example, /dev/mouse represents the mouse in Plan 9. But typically it isn't provided by the kernel but by the window manager, rio. So when you open rio it opens the mouse and then provides a new /dev/mouse for each process launched within it. Every process has a different /dev/mouse that only activates when the mouse is in that process's window(if it has one).
To draw to the screen there is one function: draw(). You pass it two rasters and some coordinates and it draws one on top of the other. That's it. Everything works across networks and architectures.
The thread library is wonderful. Threads in Plan 9 are non-preemptive and run in a round-robin fashion. They communicate using CSP channels. CSP can greatly simplify the design of many programs.
In a few of the programs I wrote would access the mouse and keyboard in seperate threads. You could use the regular open() and read() calls from each thread and there was no need to worry about locks. When I wanted something to run on both cpus I forked a process, which is very cheap.
The text editor, acme, is different and probably sucked for you. But that is because you misunderstood what it was. In linux and windows programs are islands. These islands are expected to provide everything the program does in one executable. Acme is not an island. It does not have a builtin spell checker or word counter. What it does have is a namespace that allows you to access its resources.
Plan 9 is a system which was deliberately made by very smart people. It has serious issues which make it not often a realistic choice, but it has a clarity and consistency of design that linux will never know.