After the Why I like microkernels article, I thought it'd be useful to have a view from the "other side" of this endless war. While some of the reasons given by microkernel fans are true, the big picture is somewhat different and it's what I think it keeps traditional-style kernels in the top. Note: please take note that the author is not a native English speaker, so forgive any grammar or spelling mistakes.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
-BeOS is considered an hybrid kernel not microkernel, but I agree that it's responsiveness was good.
-QNX is a microkernel, I don't remember it's responsiveness: it didn't have enough application when I tried it.
-AmigaOS didn't have memory protection if memory serves, that's a fundamental flaw which makes any performance/responsivness measure irrelevant IMHO.
That said, DragonFly has been somewhat inspired by AmigaOS, but I would be very surprised if application ported to it will be more responsive on DragonFly.
Member since:2006-03-17
True, I've heard the BeOS-is-a-hybrid comment before - and that's probably accurate. I would debate that it's hard to specifically define what is the exact size and nature of an 'authentic' microkernel - but that's not really constructive. Of the very few muKs out there, in my gut I feel Be still qualifies - as it was one of Be Inc.'s major marketing buzzwords (but I know marketing's not worth much).
As for 'responsiveness', I'm not sure if you're referring to raw speed or interface performance (responsive has many meanings in computer terms). I've not used (or heard of) DragonFly, I'll give that one a googling - but my use of 'responsive' is mostly in terms of the interface.
ie: When you click or type, does something happen?
The application isn't as liable for this as the underlying OS is, in the case of Be - you almost (almost is key) never have a system lockup caused by one thread/app gobbling up time. I've experienced it once in the case of 'Cortex' - some silly media controller - and it was probably because I did something radically dumb that may have caused a hardware issue. I've used QNX's live desktop disc (seems to not be available anymore) but it was almost as responsive - much more so than XP or Lin/*nix. The scheduling nature of QNX is quite odd, but like a good muK it responded rapidly to user input (from the GUI/input perspective). I'm sure there is a significant performance penalty in swapping between kernel/user spaces, but in the world of Ghz machines this isn't really life-threatening.
I didn't know Amiga didn't have memory protection, that's sad. It was probably sacrificed for performance. I do believe the latest AROS does, I've never used it but it's good to see a 'dead' OS walking.... maybe a 'zombie'?
Member since:
2006-03-17
I agree. This was a good article, and as far as I saw there were only one or two grammatical mistakes. When you're writing technical articles, most intelligent people will see past the typos - the ignorant ones will get stuck on petty details. President Bush can't even pronouce most words properly, should we hang people who can't spell? And for that matter, do Americans actually speak English? Its been butchered so bad, I doubt its proper to insult Britian "wit aor wustirn akzent".
Back to the article, I agree with just about everything written. I do (just for bias's sake) prefer the microkernel design simply because I've had very pleasant experiences with those systems (BeOS, Amiga, QNX) and for their time and place they performed quite responsively (moreso than any flavor of Linux I've used to date) and while they could (and did) crash, it was most often the result of trying to do something awful to the system.
But as the author pointed out, this is mostly irrelevant - software is software. APIs get broken and whether the changes are made in smaller modules or not, change happens all the time - so the weakness of the microkernel is that significant changes weave their way through the whole system. And in cases like the three OS's I mentioned above - the resources simply weren't there (QNX may be the exception) to rewrite all the affected parts of the system (BeOS's BONE network kit comes to mind).