Slashdot Mirror
Microkernel: The Comeback?
bariswheel writes "In a paper co-authored by the Microkernel Maestro Andrew Tanenbaum, the fragility of modern kernels are addressed: "Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation. The Linux kernel has more than 2.5 million lines of code; the Windows XP kernel is more than twice as large." Consider this analogy: "Modern ships have multiple compartments within the hull; if one compartment springs a leak, only that one is flooded, not the entire hull. Current operating systems are like ships before compartmentalization was invented: Every leak can sink the ship." Clearly one argument here is security and reliability has surpassed performance in terms of priorities. Let's see if our good friend Linus chimes in here; hopefully we'll have ourselves another friendly conversation."
BeOS didn't seem slow to me. No matter what I threw at it.
When viewed as a Platonic Ideal, a microkernel architechture is a useful way to think about an OS, but most real-world applications will have to make compromises for compatibility, performance, quirky hardware, schedule, marketing glitz, and so on. That's just the way it is.
In other words, I'd rather have a microkernel than a monolithic kernel, but I would rather have a monolithic kernel that does what I need (runs my software, runs on my hardware, runs fast) that a micokernel that sits in a lab. It is more realistic to ask for a kernel that is more microkernel-like, but still does what I need.
All I ask is that the GUI is reasonably slick, the screen design doesn't actively give me hives and the mail application is pleasant. Performance? Within reason, I really couldn't care less.
ian
Comparments do interfere with efficient operation, which is why Titanic's designers only went halfway. Full watertight bulkheads and a longitudinal one would have screwed up the vistas of the great dining rooms and first class cabins. It would also have made communication between parts of the ship more difficult as watertight bulkheads tend to have a limited number of doors.
The analogy is actually quite apt: more watertight security leads to decreased usability, but a hybrid system (Titanic's) can only delay the inevitable, not prevent it, and nothing really helps when someone is lobbing high explosives at you from surprise.
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
-- Colonel Adolphus Busch
How many times have we all heard that the proper way to develop software is:
First make it work, then make it fast
Specifically:
Write it as simply and cleanly as you can,
THEN check performance,
THEN optimize, but ONLY where measurement tells you to.
Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
To a Lisp hacker, XML is S-expressions in drag.
It seems reasonable to think that a tiny microkernel built for virtualization and able to support multiple virtual os's with minimal overhead is really going to be a very attractive platform. If we then get minimal, very application specific kernels to run on top of it for specific needs, we could get an environment in which various applications (http servers, databases, network servers of other sorts, browsers) could run in secure environments which could leverage multi-processor architectures, provide for increased user security, make inter-os communications work nicely and generally be a Good Thing. Certainly that would not prohibit running complete unix/MS/??? systems from running as well. (Granting, of course, that OS vendors go along with the idea, which some of the big players may find economically threatening.)
Could be very fun stuff and make viable setups that are currently difficult or impossible to manage well.
"In the 1980s, performance counted for everything, and reliability and security were not yet on the radar" is remarkable. Not on whose radar? MVS wasn't and z/OS isn't a microkernel either, and the NCSC didn't give out B1 ratings lightly.
One thing I found interesting is the notion of running a parallel virtual machine solely to sandbox drivers you don't trust.
As always, all IMO. Insert "I think" everywhere grammatically possible.
- couldn't
DMA a mouse packet over scheduler code (which ought to be read-only at the MMU) or the MMU's page table.That is what Tannenbaum's research is asking. Can such a system be built? Does it perform? What are the tradeoffs? Does the end result offer enough benefits (reliability and security) to overcome the costs (performance)?