Re: Linus replies

[Martin Schoenbeck]

Hi Richard,

Richard Braun schrieb:

> > Rebuttal from Linus' post:
> > ***
> > And anybody who tells you that distributed algorithms are "simpler" is 
> > just so full of sh*t that it's not even funny.
>
> Right.

It clearly depends on what you'll call 'simple'. Nowadays system tend to
be supported by people who didn't implement them. So design simplicity
will far be overcompensated by higher maintenance simplicity. The server
concept, used in (AFAIK) most microkernel operating systems enforces a
clear definition of responsability. While this of course can be done
with monolithic kernels, it also can be ignored. And anything which can
be ignored will be ignored. At least by several people.

> > Microkernels are much harder to write and maintain exactly because of this 
> > issue. You can do simple things easily - and in particular, you can do 
> > things where the information only passes in one direction quite easily, 
> > but anythign else is much much harder, because there is no "shared state" 
> > (by design). And in the absense of shared state, you have a hell of a lot 
> > of problems trying to make any decision that spans more than one entity in 
> > the system.
>
> That's where the Hurd slightly differs from what is said here: the
> problem about a "decision that spans more than one entity" is the
> interface between those entities. Within a monolithic kernel, these
> interfaces can easily change since it is internal to the kernel

First, that is a disadvantage in my opinion, second if you have write
access to all software implementing this with a microkernel, you can
change the interface between them as easy as with monolithic kernels.

> (except
> of course system calls and interface with userland processes). With a
> multiserver microkernel, they must be very carefully designed 

that's a very big advantage and leads to less maintenance efforts.

> so that
> services implemented on top of the microkernel can evolve with very few
> changes to the interface (the best case being extension only, without
> any modification on the existing interface).

Whether you change interfaces internally in a monolithic kernel or
interfaces within parts of a microkernelsystem doesn't make a real
difference. But you'll have to understand what belongs to that interface
without missing a piece of the puzzle.

<snip>
> > And I'm not just saying that. This is a fact. It's a fact that has been 
> > shown in practice over and over again, not just in kernels. But it's been 
> > shown in operating systems too - and not just once. The whole 
> > "microkernels are simpler" argument is just bull, and it is clearly shown 
> > to be bull by the fact that whenever you compare the speed of development 
> > of a microkernel and a traditional kernel, the traditional kernel wins. By 
> > a huge amount, too.
>
> This comparison is quite stupid IMHO, since the simple fact that the
> number of developers is really not the same is the real issue about
> the speed of development.

ACK.

> Microkernels are not simpler, they are
> more complicated. 

I don't believe that. We are maintaining the L3 with two people know
(and of course do much other things, too). While the L3 probably
couldn't be called a real microkernel, it contains most design
principles of the L4. The most maintenance efforts we have to do belong
to exactly that part of L3 where Jochen Liedtke later decided to remove
it from the kernel for L4: the backing storage management and the memory
management.

> But they allow simpler development of new components,
> and this is clearly true on the Hurd, since using software like the
> well known glibc or gdb helps a *lot* when debugging new translators
> (even if glibc and gdb sometimes have bugs too, which makes debugging
> a little harder ;-)).

And because most pieces of a microkernel based OS _are_ such components,
it makes the whole development process much easier.

I won't try to imagine TCP/IP implemented in the kernel. It makes me
shudder.

> > The whole argument that microkernels are somehow "more secure" or "more 
> > stable" is also total crap. The fact that each individual piece is simple 
> > and secure does not make the aggregate either simple or secure."
> > ***
>
> Well, I completely disagree on that. Microkernels are more secure
> because accesses to objects and services is always controlled the same
> way, so the code that makes checks is easy to maintain and keep secure.

They are more secure also because the code which could hurt any process
at will is much smaller and therefore better to validate.

> Concerning stability, excluding the kernel and critical services, any
> process can crash without crashing the system. The issue concerns
> processes that hang, and makes related processes hang too, but there
> are solutions to that as well.

And that eases development, too. I did an (or a?) USB implementation for
the L3 and I can't remember a single situation where I had to press the
reset button to recover from that driver hanging.

> > Could someone refute these statements for me?  Or do you agree with Linus' 
> > that microkernels are actually not easier to maintain?
>
> I hope this gives you some answers. Microkernels may not be easier to
> maintain,

They may (I don't believe) be less easy in the development stage. But
I'd bet the maintenance stage is easier to handle. At least if you are
going to get comparable stability and security. Perhaps we'll have some
figures somewhere in the future.

Martin