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