The idea of a microkernel is good (if your hardware sucks, i.e. RISC) because it adds to reliability and turns kernel drivers and "components" into normal programs that can be written in any language, but these microkernels all suck because they're written in C and designed for UNIX. Like JavaScript is better than C, these C/C++ microkernels are better than UNIX, but they still suck. If there was a microkernel that's not written in C or C++ and not designed for UNIX/POSIX, it probably wouldn't suck.
Subject: I Have Seen The Future Of The Future And It Sucks Too.
So I figured I was better than your average unix-haters
reader since, hey, I hack Mach kernels; I'm not just
bitching about how bad things are, I'm actually doing
something about it, damn it!
Well, it all started with when my research version of Mach
went down in flames and took bits and pieces of the file
system with it. In hindsight, I suppose I should have just
lived with things like not being able to print to certain
printers. Well anyway, I had the Facilities people "add 10
megs or so to the root partition, oh and while you're at it,
why don't you rebuild the disk since the filesystem's been
kind of flaky since that, uh, big kernel crash last week..."
So anyway, I came in today and found a brand spankin new
filesystem. All I had to do was replace the v2.5 production
kernel with a v3.0 research kernel. Yep, just replace a
couple files on the root partition and reboot, no problem.
Well, it's a little more complicated than that. For some
unknown reason, mach machines have a "root" directory ("/")
and a "superroot" directory ("/../.."). Once someone tried
to explain why but I didn't quite get it.
Anyway, you have to have hard links to your kernel file in
both root directories. Then since mach is not a kernel but
a microkernel (the micro kernel binary with symbol tables,
debugger, etc is a svelte 950k on a MIPS box, unix emulation
is only another 1500k; I actually *needed* the extra 10 megs
on the root partition) you have to create a mach_servers
directory and populate it with various programs that mach
uses to emulate unix.
Now the tricky part is that since you have two root
directories you can put the mach_servers directory in the
root directory and then put a symlink in the superroot or
you can put the mach_servers directory in the superroot and
put a symlink in the root directory.
The documentation says you can do it either way.
Unfortunately, the documentation doesn't say that it only
works when you put mach_servers in the superroot with a
symlink in root. This also happened to be the second case
given in the documentation and I had the misfortune to use
the first case given in the documentation. Silly me.
So I proceeded to boot my machine 10 or 12 times only to
crash into the kernel debugger every time. I stared at
stack traces and read code and read code and stared at stack
traces. The error messages were no help, they said "init
died". Thanks a lot.
So I finally figured that one out and redid the mach_servers
directory and rebooted once more. It crashed again at about
the same place complaining about "error 6000". Now the
annoying thing about mach is that since your operating
system is spread out over 69 different address spaces, you
never really know for sure who is generating an error code.
You just have to memorize a mapping from error code ranges
to subsystems. Eg errors in the 2500's are from the
device-independent device routines (go figure), -300's are
arg checking errors in an IPC stub routine, you get the
idea. Well anyway, I never ran across 6000 before. So I
hit the source code again... Oh. Error 6000 means some
file is not executable.
One of those damn programs in mach_servers was trying to
exec another of those damn programs in mach_servers which
unfortunately didn't have it's execute bit set so naturally
the exec function, in it's penultimate moment of existence,
exclaimed "6000!" before it crashed the whole show.
I guess the moral is that Mach looks like unix on the
outside but does totally different stuff internally.
However, when you strip away the tasks, threads, ports,
messages, and memory objects, when you get down to the very
essence of the system, the thing is still unix. There is no
hope.