Slashdot Mirror
The Great Microkernel Debate Continues
ficken writes "The great conversation about micro vs. monolithic kernel is still alive and well. Andy Tanenbaum weighs in with another article about the virtues of microkernels. From the article: 'Over the years there have been endless postings on forums such as Slashdot about how microkernels are slow, how microkernels are hard to program, how they aren't in use commercially, and a lot of other nonsense. Virtually all of these postings have come from people who don't have a clue what a microkernel is or what one can do. I think it would raise the level of discussion if people making such postings would first try a microkernel-based operating system and then make postings like "I tried an OS based on a microkernel and I observed X, Y, and Z first hand." Has a lot more credibility.'"
And now, cue thousands of replies from people who have personally created microkernels and have sensible observations to make on their validity as a base for an OS...
(crickets)
stuff |
Haven't we dealt with this before?
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Hmmm....he must be new here ;)
hilarious
And the date at the bottom of the article is "12 May 2006". The same article has been linked from slashdot before too. We really haven't argued about this for a while...
QNX. www.qnx.com. Best OS ever. Very long life support (qnx 4.x last patch was issued 17yrs after it was released). Now it is free for non-commercial use, with source.
Old articles for nerds. Stuff that mattered.
The rise of virtualization proves the validity of the microkernel concept, whereby the hypervisor now takes the place of the original "kernel" (note the similarity in block diagrams: microkernel vs. hypervisor designs). Virtual machines are now used instead of function-specific modules in the original microkernel designs, with specialized VMs for performing I/O and to host virtual appliances with just enough user-level code needed to support a particular application.
Nooface
In Search of the Post-PC Interface
NT (like OSX) has a microkernel, but the operating system isn't just the microkernel. Most of OSX (for example) actually runs on UNIX which runs as a single application of the microkernel. NT also has an enormous number of kernel-entry points which means that it too is a monlithic-kernel-based system that happens to run on a microkernel.
A real microkernel-based system will have a lot of the userland facilities designed to take advantage of message passing and will probably look more like HURD or Squeak than it will like NT or NeXT. QNX and VxWorks are the only successful microkernel-based systems that I'm aware of, and frankly both of them are losing big to Linux, so we might have to say were the only successful systems in the future...
Exactly - that makes it actually quite an insidious submission, you know... not only will we have a little shoutfest over micro kernels, we can also start complaining about dupes again and in discussions like this, it's only a matter of time before someone puts a vi vs emacs spin on it, since we haven't had that shoutfest for a while either.
:)
Not two, but three birds with one stone
I did my senior project in college on this in 1998... At that time I was looking at something from MIT called the exo-kernel and comparing it to some 2.4 version of the linux kernel. Back in 1998 the problem was mainly that nobody had invested in that particular mirco-kernel technology, unlike say mach, because it was a research project. In my conclusion, it was clear I could not do a meaningful comparison of complex applications on both OSes due to its lack of maturity. But there was one thing that was clear, the design philosophy behind the micro kernel allowed a much more flexible way to interact with the hardware.
The time it would take to design an implement a what the equivalent of driver would be were smaller. In the end it puts more flexibility into the hands of the application designer with the kernel taking care of just the bare minimum. The initial work at the time reported a 10x improvement in performance since you could customize so much of how the hardware resources were being used. This of course comes at a price, in addition to developing the application, you need to develop the drivers it uses, possibly increasing the time to write anything significant.
But in the end, flexability was key, and you can see some of the microkernel design philosophies start to seep into the linux kernel. Take a look at kernel modules for example. The code is already being abstracted out, now if it just effectively was designed to run in userspace.
My thoughts are that in the end the microkernel will win do to the fact that I can engineer a more complex OS that is cheaper to change, not because it is faster. Tis is the compromise that was made with compilers vs. machine language programming. In the end I think Tanenbaum will win, linux will become a microkernel out of necessity, and Linus as it turns out would have gotten a good grade from Dr. Tanenbaum. He just would have handed his final project in 40 years late by the time it happens.
BOFH, My model for being a sysadmin :)
Like many other "this vs. that" wars, neither micro- nor monolithic-kernel architectures are best for all tasks.
Like many other "this vs. that" wars, people will use arguments like yours as a cop-out to avoid any serious analysis of the design tradeoffs and the implications of those tradeoffs.
It is quite hollow to say that something is not the "best for all tasks," without some analysis as to when it is the best option, or which option has the most promise in the long term (such that it might be a good field of research).
Social scientists are inspired by theories; scientists are humbled by facts.
If you read the article, Tannenbaum reminds everyone of how Microsoft paid Ken Brown to write a book accusing Linus of stealing the Minix microkernel. FTFA:
Kevin Smith on Prince
QNX is relevant. Is it popular on the desktop? Not really but then you could say is BSD relevant? Is it popular on the desktop compared to Windows, MacOS/X or even Linux?
Is Linux relevant on the desktop? If you don't count duel boot machines how many Linux desktops are out there?
"Although microkernel OSs may be "nicer" from a design point of view, on the practical side the monolithical ones are serving us very well."
I have heard that argument before except it was about Unix. MS-DOS was so much faster and used less ram and drive space than Unix did.
To just dismiss microkernels because monolithic kernels are good enough is silly.
Actually Linux is starting to take some ideas from Microkernals. FUSE is a Microkernel idea. Moving more device drivers into userspace is also a very good idea. It means that security issues with a driver are less likely to root the OS or take out the OS with a crash.
Stablity and security are important aren't they?
But back to your comment yes QNX is relevant. It is relevant because it proves that you can have a small, fast, and stable microkernal OS.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
OS X, strictly speaking, is a hybrid kernel. Essentially, NeXT mashed together Carnegie Mellon's microkernel Mach with BSD (a monolithic kernel) - yielding the overwhelmingly originally named XNU kernel. (X is Not Unix). So in short - yes , OS X is a microkernel based OS, but is just as much a monolithic kernel based OS.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
I hate when people says "NT/OS X are microkernels but don't work like microkernels", or they call them "hybrid kernels"
Either you're microkernel or not. Either you run filesystems and network stacks in separated, isolated processes and address spaces, or you don't. NT and OS X don't run anything of that as a separated process, which was the whole point of having a microkernel. They run it in the same process space than everything else. Just like like linux, solaris, windows 9x. In other words, they aren't microkernels.
Yes, they have source-level design abstractions inherited from microkernels to make the design more modular. So do Linux, Solaris or any other decent monolithic kernel, even if they didn't inherited it from microkernels. Microkernel people wasted their years saying that a microkernel where needed to achieve "modularity", when the fact is that "modularity" in the design of software is not something that you can achieve only by running things in different process spaces. After 20 years they haven't realized that many parts of linux or solaris are more modular than their equivalents of minix or hurd.
- The client-server paradigm is a good one
Too vague to be a statement. "Good" is undefined.
- Microkernels are the way to go
False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expectevery application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
- Atomic group communication (broadcast) is highly useful
Perhaps. We've never used it or felt the need for it.
- Caching at the file server is definitely worth doing
True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.'
- File server replication is an idea whose time has come
Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem.
- Message passing is too primitive for application programmers to use
False.
- Synchronous (blocking) communication is easier to use than asynchronous
They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need.
- New languages are needed for writing distributed/parallel applications
`Needed', no. `Helpful', perhaps. The jury's still out.
- Distributed shared memory in one form or another is a convenient model
Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.)
How about the "CONTROVERSIAL" points? We should weigh in there, too:
- Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes)
What?
- Atomic transactions are worth the overhead
Worth the overhead to whom?
- Causal ordering for group communication is good enough
We don't use group communication, so we don't know.
- Threads should be managed by the kernel, not in user space
Better: have a decent process model and avoid this process/thread dichotomy.
Rob Pike
Dave Presotto
Ken Thompson
Phil Winterbottom
Depends. Ever hear of FUSE? It's been showing up in quite a few distros for the capabilities it buys by running outside of kernel space. It's become so important, that it has been ported to BSD, Solaris, and Mac OS X.
What does it do? Why, it's a monolithic driver that provides an interface to support userspace filesystem drivers. i.e. A microkernel in practice, if not in definition. Ergo, the grandparent's point about a slow migration.
Javascript + Nintendo DSi = DSiCade
We don't need a microkernel written in any language, especially not C. What we need is a kernel where everything is protected by being typesafe (a 'safe' kernel). Like a kernel written in Java (jxos) or .net (singularity), or limbo (inferno), or maybe D. People forget the original purpose of the "memory management unit" was for swap on mainframes and not for process protection. And anybody who has looked at the mess that is fork, mmap, etc dealing with memory protection in a monolithic system should know it's not good at process protection. It's absurd how much complexity and overhead is caused by this.
... and so on.
A 'safe' kernel sounds slow, because it is probably interpreting bytecodes and has garbage collection. But you get many performance advantages also:
1) idle thread can actually do something, by making programs take less room (compacting gc), offloading some of the work of free(), and optimizing code. So programs respond faster when you switch back to them.
2) lack of data copying. Current systems often copy a *lot* of data from calls to read(2), write(2) and friends, and attempts to reduce this with calls like sendfile or page sharing is very complicated and has a lot of overhead. With a 'safe' kernel you can just give a read-only view, or any number of other very simple methods where no copying takes place.
3) mmu can be used to optimize garbage collection. Only pages written to since the last collection need to be checked for references to new objects, which can improve performance drastically if the instructions inserted to implement a software 'memory barrier' can be removed. It can also help run a gc in parallel since it can easily know if the objects it is looking at have changed during the collection.
4) can eliminate all TLB flushes and stalls from swapping page tables
5) much faster context switch means programs can have smaller time slices, so responsiveness is improved. Meaning less latency in audio (and everything else) without special hacks like magic 'realtime' processes.
6) can run on all hardware, even when lacking memory protection
7) hardware access safer than micro or monolithic kernel, and easier to write drivers
As someone who's done operating system internals work and has written extensively for QNX, I should comment.
Down at the bottom, microkernels are about interprocess communication. The key problem is getting interprocess communication right. Botch that, from a performance or functionality standpoint, and your system will be terrible. In a world where most long-running programs now have interprocess communication, it's amazing that most operating systems still do it so badly.
For interprocess communication, the application usually needs a subroutine call, and the operating system usually gives it read and write. Pipes, sockets, and System V IPC are all queues. So clunky subroutine call systems are built on top of them. Many different clunky subroutine call systems: SOAP, JSON, XMLHttpRequest, CORBA, OpenRPC, MySQL protocol, etc. Plus all Microsoft's stuff, from OLE onward. All of this is a workaround for the mess at the bottom. The performance penalty of those kludges dwarfs that of microkernel-based interprocess communication.
I've recently been writing a web app that involves many long-running processes on a server, and I wish I had QNX messaging. I'm currently using Python, pickle, and pipes, and it is not fun. Most notably, handling all the error cases is much harder than under QNX.
Driver overhead for drivers in user-space isn't that bad. I wrote a FireWire camera driver for QNX, and when sending 640 x 480 x 24 bits x 30 FPS, it used about 3% of a Pentium III, with the uncompressed data going through QNX messaging with one frame per message. So quit worrying about copying cost.
The big problem with microkernels is that the base design is very tough. Mach is generally considered to have been botched (starting from BSD was a mistake). There have been very few good examples anyone could look at. Now that QNX source is open, developers can see how it's done. (The other big success, IBM's VM, is still proprietary.)
Incidentally, there's another key feature a microkernel needs that isn't mentioned much - the ability to load user-space applications and shared libraries during the boot process. This removes the temptation to put stuff in the kernel because it's needed during boot. For example, in QNX, there are no display drivers in the kernel, not even a text mode driver. A driver is usually in the boot image, but it runs in user space. Also, program loading ("exec") is a subroutine in a shared object, not part of the kernel. Networking, disk drivers, and such are all user-level applications but are usually part of the boot image.
Incidentally, the new head of Palm's OS development team comes from QNX, and I think we'll be seeing a more microkernel-oriented system from that direction.
For little girls, and big fuck-off boxers.
(With pardons to Eddie Izzard.)
Microsoft is to software what Budweiser is to beer.
Well, I think that writing complaints about Slashdot dupes is best done on emacs when your OS has a monolithic kernel, and on vi when using a micro kernel.
HexaByte - he's a square and a half!
"On the topic of Minix 3, itself.
It may be a fine instructional OS. Great! That's awesome. I applaud it and have no qualms promoting it in that realm. Beautiful."
Not really Minix 3 isn't trying a microkernel verison of Linux it is trying to be a more secure and reliable POSIX operating system. It uses a microkernel design to achieve things like self healing and security. Adding those features to Linux would a complete rewrite of Linux.
"If my info on GNU/Hurd was invalid, then I stand corrected. I assumed that Hurd was the microkernel with Linux (usually Debian) on top. I should have been clearer about that."
You info is wrong and no it doesn't run Linux on top, and no you can't be clearer because that statment is totally wrong.
"It's conceptually similar, in many ways, to Xen's hypervisor."
No it isn't. Xen is a hypervisor it isn't a microkernel. You could host Hurd and or Minx 3 on Xen but you can't host Xen on Minx 3 or Hurd. You don't take an OS and just run it as a service under an microkernel and a hypervisor by it's self doesn't run applications like a microkernal OS does. The only way that they are similar is that they are small compact bits of code the provide some type of abstraction of the underlining hardware.
"In both cases, Linux isn't the only OS to be hostable on Hurd."
You don't host any OS on Hurd. You can create servers that offer the same services as a specific OS. Much like Wine does under Linux.
"On the other hand, Tanenbaum isn't making apples to apples comparisons, otherwise why not take Vista to task, at the same time? Linux is nothing like Minix, so why compare the two in this way? Why not go after Solaris and others, as well?"
Did you read the article? He wasn't comparing Linux to Minix 3 at all. He didn't go after any one.
And yes he was critical of all current Operating Systems.
"Better yet, make a super cool microkernel for Linux, support Xen-style hypervisors, or something. In other words, don't just complain, do something useful, to help out."
Um.. Gee let's see he is working a POSIX operating system with the goals of making it secure and self healing.... Yea that is so useless. Just for kicks what OS or significant piece of FOSS have you written? How have you helped?
So you have written a lot with NO UNDERSTANDING of what you are talking about.
I want some new options for moderation just for posts like this. +5 Ignorant +5 Arrogant!
Before you start telling Tanenbaum what he should do to be usful you need to learn the difference between a Hypervisor and a Microkernel, the difference between Hurd and Linux, and the difference between someone with an actual education in Computer Science and yourself. Might I suggest you pick up Tanenbaum's text book? It was of great help to Linus.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Tanenbaum's misunderstood.
His real interest is in building highly reliable, self healing operating systems. The research he has been involved in happens to demonstrate that microkernels are a good candidate towards achieving that goal, certainly better than a monolithic kernel anyway. He doesn't believe in microkernels per se, but simply as a tool that will help him achieve what is a higher goal - a highly reliable, self healing operating system. Imagine not having to reboot your computer, even when running the worst written applications or device drivers.
And he tries for the flame war trifecta...NO GOOD! Oh, you hate to see that when they work so hard to prepare for the big game.
Still, two flame wars in one sentence is nothing to scoff at, which is why the artistic score will be high. However, the judges really wanted to see some sort of garbage collection vs. malloc/free or even an Intel/AMD mention. That could cost him the gold.
Let's see what the rest of the competitors have to offer.
If moderation could change anything, it would be illegal.