Page 1 of 1
Microkernels versus Monolithic redux
Posted: Mon May 15, 2006 8:40 pm
by Colonel Kernel
This might have made the rounds already, but I noticed this today:
http://www.cs.vu.nl/~ast/reliable-os/
Linus said something about microkernels again, and Andrew Tanenbaum has responded. Semi-interesting stuff... I'm still reading through the thread that Linus posted to, and I noticed our own Brendan asked a few questions in there.
Anyway, I just thought this might be interesting to some...
Re:Microkernels versus Monolithic redux
Posted: Mon May 15, 2006 10:54 pm
by mystran
Tannenbaum has good points on high-level, but if you dig deeper, I think all the other projects mentioned are more interesting than MINIX3, and in any case (without having studied the source of MINIX3) I don't think MINIX3 is the solution.
I am a supporter of microkernels, but I'm not sure Tannenbaum is the right guy to follow.
Re:Microkernels versus Monolithic redux
Posted: Mon May 15, 2006 11:09 pm
by LongHorn
Micro kernel is a future story, now it is monolithic. Linux succeeded being a commercial OS. I don't think any microkernel OS haven't won commercially ( though minix was written for commercial pupose, selling books ) yet he is one of the best authors and a serious osdev.
Re:Microkernels versus Monolithic redux
Posted: Mon May 15, 2006 11:23 pm
by Colonel Kernel
mystran wrote:I am a supporter of microkernels, but I'm not sure Tannenbaum is the right guy to follow.
I tend to agree... I've never been very impressed with MINIX from an engineering standpoint. QNX and L4 always stood out to me as better examples of how to design a microkernel, even if there are some flaws with the basic concept.
To me, Singularity seems like the natural evolutionary path of microkernels... If you ignore the fact that you can't run any existing code or any code written in "unsafe" languages on it (and that's a big
if ), it has all of the advantages and none of the drawbacks of today's microkernels. In fact, the system as a whole seems to have even more advantages in terms of the larger classes of errors that can be detected statically.
Anyway, I made a follow-up post in that RWT thread... Hopefully it will not simply go back to being a flame-fest.
Re:Microkernels versus Monolithic redux
Posted: Mon May 15, 2006 11:44 pm
by mystran
Every time I read something written by Tanenbaum, it seems to me that he's main motivation is to prove something. That is ofcourse totally understandable, because he seems to be pretty prototypical scholar. Scholars prove things (and try to seem impressive so they can sell books to make a living).
As it is, I don't think "Design and Implementation ..." is named right. It should be called "Design of an Implementation and Implementation ...", because to me, MINIX has never looked like an operating system design, just an implementation of the general Unix design.
Look at Hurd, and you see the difference. Hurds main motivation seems to be getting rid of a centralized kernel, and therefore taking a step beyond the Unix system. Or look at Plan9; I believe that qualifies as a distributed system.
To me MINIX is simply "Look at how microkernels help us manage complexity, so that we can add more and more features."
As wise people know, features are not design. Really good design, OTOH does usually enable new features.
YMMV.
Re:Microkernels versus Monolithic redux
Posted: Tue May 16, 2006 4:01 am
by paulbarker
Thats why I chose "Modern Operating Systems" rather than "Design and Implementation...". You get all the information but it lets you do the design rather than providing one (a design called "UNIX").
I think the microkernel debate is a bit pointless myself. To me its a secondary thing to the actual design of the kernel, which is a good set of APIs. My kernel should really be compilable as a microkernel or a monolithic kernel just by changing a few options, but I'll see if thats possible once I have a working system.
I also hate the religous aspects of this debate... even within the areas of kernel programming there are many different target systems and intended uses for kernels. The fact of life is that microkernels are the best for certain jobs and monolithic systems are better at other jobs. Its not a "one size fits all".
Lastly microkernels can help to abstract code and isolate failures. A well designed and implemented monolithic system will always beat (on performance, security and stability) a poorly written microkernel system. A mircokernel is not a panacea which solves all problems and allows a novice coder to write a perfect system.