Don't know if you saw Tanenbaum's latest defence of microkernels but here it is if not.

http://www.cs.vu.nl/~ast/reliable-os/
via
http://developers.slashdot.org/developers/06/05/15/1637206.shtml

Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
---------------------------
>philt (ptay1685@bigpond.net.au) on 5/14/06 wrote:
>>
>>Where they differ is about whether there are advantages
>>to Microkernels that outweigh these disadvantages. Linus
>>seems to think not. Others disagree.
>
>Well, so far, "others" haven't even been able to actually
>name those hypothetical advantages.
>
>I've seen insane claims of speed (and yes, I've seen
>benchmarks too - microkernels are often very fast when
>you benchmark something like context switching, because
>that's what they've spent all their time optimizing for).
>
>I've seen insane claims of "easier" (in fact, this was the
>claim for much of the 80's and 90's), and I even bought
>into it at one time. Having actually learnt what is easy
>and what is hard - and having seen people fumble with their
>microkernels over and over again - it's become obvious not
>only to me that the "easier" argument was bogus.
>
>For a while there the claim was "scales better". The logic
>behind that argument was basically that since the model
>forces you to make all your services appear distributed
>anyway, then it should obviously naturally result in
>microkernels being wonderful for clustering etc.
>
>That, btw, would appear to be a logically sound argument,
>but it ends up falling down on the fact that microkernels
>want to support memory mapping too (sometimes more than a
>monolithic kernel, since memory mapping is also a way to
>avoid some of the performance issues - the Hurd tried to
>really push this angle), and suddenly the whole transport
>isn't network-transparent after all.
>
>(There are other problems with the whole "scaling" argument,
>not the least of which is that scaling on SMP and in a
>cluster are two almost totally different dimensions, and
>using the same model for the two is just not sensible, but
>that's another issue).
>
>For the last year or so, the new magic world has been
>"security". It appears as totally bogus as the "ease of
>maintenance" tripe was (and for largely the same reasons:
>security bugs are often about the interactions
>between two subsystems, and the harder it is to write
>and maintain, the harder it is to secure).
>
>I'm sure that ten years from now, it will be something else.
>
>There's always an excuse.
>
>>It is interesting to note what has happened to the Hurd as
>>an example of a real world Microkernel project. It appears
>>to have a reached a resonable level of maturity, enough
>>for Debian to build a distro based on it - but is now
>>stalled, despite apparently have come so close to its goal.
>>It would appear that certain insurmountable problems
>>(speed and reliability?) have forced developers to rethink
>>and look at other kernels (L4, Coyotos).
>
>Well, there's (I think) several arguments for why this
>happens.
>
>If you're a microkernel person, the first argument is that
>Hurd isn't really a microkernel, it's an abomination that
>makes all other microkernels look bad. Talk to any L4
>person, and they'll tell you Hurd is something else
>entirely.
>
>The other argument is that doing something that works
>well enough to support basic UNIX system calls isn't that
>hard. I should know. Linux 0.01, back in 1991, largely did
>that. Making a whole Debian distribution on top of such a
>system isn't actually that hard. The hard part is making it
>all actually work well.
>
>The final (and I think deciding) argument is that the
>real argument for microkernels has nothing to do with
>speed, ease of implementation, security, or anything else.
>
>The real reason people do microkernels (and probably will
>continue to do them, and make up new reasons for why they
>are better) is that the concept sounds so good. It
>sounded good to me too!
>
>The whole "make small independent modules" thing just sounds
>like manna from heaven when you're faced with creating an
>OS, and you realize how daunting a task that is. At
>that point, you can either sit back and enjoy the ride
>(which I did - partly because I didn't initially really
>realize how daunting it would be), or you can seek mental
>solace in an idea that makes it sound easier than it is.
>
>So that "microkernels are wonderful" mantra really comes
>from that desperate wish that the world should be simpler
>than it really is. It's why microkernels have obviously
>been very popular in academia, where often basically cannot
>afford to put a commercial-quality big development team on
>the issue, so you absolutely require that the problem
>is simpler.
>
>So reality has nothing to do with microkernels. Exactly the
>reverse. The whole point of microkernels is to try to
>escape the reality that OS design and implementation is
>hard, and a lot of work.
>
>It's an appealing notion.
>
>>No doubt Linus hopes thay won't.
>
>Actually, if I were afraid of competition (and, quite
>frankly, I'm not - since I'm not competing as much as
>just having a damn good time), microkernel people aren't
>where it would be.
>
>I'd worry about some really smart kid in some random country
>that I've never heard of, who just doesn't know how hard
>things are, and who is hungry for the challenge, and decides
>to "just do it". And does things differently (in some
>respect - maybe he decides that the real problem is the
>language, and writes a much better model for handling all
>the complex issues).
>
>For Linux, the "does things differently" wasn't so much
>technical, but in the development model.
>
>That's how real progress is made. Not by people who are
>afraid of the complexity. Real progress is made by people
>who are too ignorant to even realize that there is
>complexity, and how things are "supposed" to work, and they
>just do it their own way. And most of the time, their way
>was just totally crazy. But sometimes that naïve way ends
>up being something that nobody else had done before, and
>that really really worked.
>
>Over-thinking things is never how you do anything real.
>
>Linus