Re: If QNX is successful, why NOT GNU Microkernels

[Olivier Galibert]

Feeling defensive are we?

On Wed, Jan 21, 2004 at 02:11:02PM +0100, Alfred M. Szmidt wrote:
>    Mach has some issues that seem to make it intrinsically slow[1],
>    Hurd has its own issues on top of it that makes it even worse[2],
>    and functionality-wise it doesn't really seem to give much more
>    than a pair of funky userspace filesystems like the ftp translator,
>    compared to monolithic kernels like a modern linux or bsd.  And the
>    userspace is the same.
> 
> And better security,

Security is essentially dependant on userspace.  And frankly the linux
and bsd kernels have been way more reviewed in that area, so I'd trust
them more.  The security model of the translators in presence of crons
runs from priviledged accounts with find in them can be interesting in
particular.


> well designed,

I've heard a lot of things about Mach, but never that it was well
designed.  Its task/thread model sucks, its VM model sucks, the
marshalling/unmarshalling on syscalls is a performance nightmare.

Hurd itself is better, but still has its problems, the main one being
the lack of distributed memory caching management.  And it still has
to cope with the mach annoyances, in particular cthreads.


> far more stable since the system
> won't crash if the file-system/driver/etc fubars.

You're leaving in dream land here.  Modern linux, and I have
first-hand experience with failures there, usually won't crash on
driver/fs problems if the problem is recoverable.  And if it isn't
(stuck shared irq, runaway dma all over the kernel memory, / fs
lost...), userspace drivers won't do any better.


>    Hurd is neither, and is so behind the curve that it's hard to find
>    developers motivated by it.  Especially since it's very hard to see
>    what Hurd could propose that is not already in the other ones.
> 
> And you base these claims on what?

On several years of keeping an eye on hurd and installing it from time
to time, and on the amount of development and innovation done in here
compared to say lkml.


> What is has to do, and how fast it does it are completely different
> things; also note that the Hurd is completely unoptimised.

To the point of been unusable.  And that's one of the reasons why it
is unsuccessful.

Avoiding premature optimization does not mean "if you have multiple
ways of implementing something, use the slowest".

  OG.