Broadening Horizons with Other Operating Systems
Looking at GNU HURD and Plan 9
I like UNIX. I like it a lot. As a matter of fact, it is somewhat disgusting at how narrow-minded I can be about it considering how many other operating systems are out there. My motivations should be obvious: I look for power, efficiency and the ability to get close to the system. One can only get such things from a well-written multitasking operating system. It could also be said, truthfully, that I really would not like to switch to maintaining/developing/whatever on any other OS than is not UNIX-like. What I can concede is that someday, another OS of some sort, whether a UNIX variant or some sort of descendent, will replace or extend into UNIX. What that system may be, I do not know.
Right now UNIX systems meet my personal and professional criteria. This is not to say there are not some quality operating systems out there that are different from UNIX (or are some sort of UNIX variant, like our beloved Linux) that are quite good. They are simply not in widespread use at this time. These other operating systems still have something of value; their design philosophy is somewhat different than UNIX systems. Who is to say that understanding these ideas might not provide some insight into how current UNIX systems could be changed or just into new perspectives on a project?
Just reading about the HURD is exciting to me. The HURD represents total user empowerment. The HURD seeks to reduce the wall between the user and the system as much as possible. At first glance one might consider this blasphemous, but take another look. The HURD developers are well aware that users cannot have complete access to everything. Instead, they would simply give as much access as safely as possible. The reason I find this exciting is the safe-testing value of the HURD.
Safe System Hacking
Within the HURD, a user can create a new experimental device driver, load it and test it without interfering with other users or the system itself. As a matter of fact, the user could build specialized drivers, interfaces--just about whatever they wanted--in their own user-space. Now, imagine it, pooling the resources of hundreds of developers onto one machine to independently build and test drivers, file systems, interfaces and so on without risking a system-wide crash. Development would move at an intense speed. In theory, this of course would not be limited to low-level development but wuld include any development. Just that thought alone tantalizes my dreams of development speed.
An Overview of The HURD Magic
So how does it work? The idea behind how the HURD talks to the micro-kernel is interesting and really seems to be the key to how it works magic. Under most architectures, the MACH will open a port for each file in the system. Under a UNIX system, this, of course, is very handy since everything is a file (repeat the mantra: everything is a file). Under the HURD, however, it works differently--a translator is associated with the port instead. This means all specific information does not have to reside within the kernel itself. Trent Fisher has an article called Towards a New Strategy of OS Design with this excerpt that really explains the translator:
" The translator is given a port to the actual file and asked to return the port when it is done."
In essence, user control. If you read this carefully you will see the hidden implication: the HURD is a much more dynamic operating system than most.
There are also limitless ideas that spring from the HURD design philosophy; upgrading and installing hardware could be done easily by testing it in an isolated user space without affecting the rest of the system. The same would be true of software installs. Real-time systems could easily take advantage of the ideas behind the HURD (or with it) by embedding auto-start user processes. Entire factory production lines upgraded with ease and zero risk...and...and--okay, I am getting carried away.
In essence, the HURD offers failsafe scalability without intense redundancy or cost.