Tanenbaum-Torvalds Microkernel Debate Continues

twasserman writes "Andy Tanenbaum's recent article in the May 2006 issue of IEEE Computer restarted the longstanding Slashdot discussion about microkernels. He has posted a message on his website that responds to the various comments, describes numerous microkernel operating systems, including Minix3, and addresses his goal of building highly reliable, self-healing operating systems."

Comments

To Interject for a moment

[AKAImBatman]

Since I know that this story is going to turn into flame-fest central, I'm going to try to head things off by interjecting an intelligent conversion about some issues that are on my mind at the moment.

First and foremost, does anyone have a torrent of Minix3? Tanenbaum is a bit worried about getting slashdotted. If you've got one seeded, please share.

Now with that out of the way. I don't know if anyone else has tried it yet, but Minix3 is kind of neat. It's a complete OS that implements the Microkernel concepts that he's been expounding on for years now. The upsides are that it supports POSIX standards (mostly), can run X-Windows, and is a useful development platform. Everything is very open, and still simple enough to trudge through without getting confused by the myriads of "gotchas" most OS code-bases contain. Unfortunately, it's still a long way from a usable OS.

The biggest issue is that the system is lacking proper memory management. It currently uses static data segments which have to be predefined before the program is run. If the program goes over its data segment, it will start failing on mallocs. The result is that you often have to massively increase the data segment just to handle the peak usage. Right now I have BASH running with a segment size of about 80 megs just so I can run configure scripts. That means that every instance of BASH is taking up that much memory! There's apparently a Virtual Memory system in progress to help solve this issue, so this is (thankfully) a temporary problem.

The other big issue is a lack of threading support. I'm trying to compile GNU PThreads to cover over this deficiency, but it's been a slow process. (It keeps failing on the mctx stack configuration. I wish I understood what that was so I wouldn't have to blindly try different settings.)

On the other hand, the usermode servers do work as advertised. For example, the network stack occasionally crashes under VMWare. (I'm guessing it's the same memory problems I mentioned earlier.) Simply killing and restarting dhcpd actually does get the system back up and running. It's kind of neat, even though it does take some getting used to.

All in all, I think it's a really cool project that could go places. The key thing is that it needs attention from programmers with both the desire and time to help. Tossing lame criticisms won't help the project reach that goal. So if you're looking to help out a cool operating system that's focused on stability, security, and ease of development, come check out Minix for a bit. The worst that could happen is that you'll decide that it isn't worth investing the time and energy. And who knows? With some work, Minix might turn out to be a good alternative to QNX. :-)

Re:To Interject for a moment

[rcamans]

Whoo, there, good buddy. Actually I have seen some pretty entertaining videos of less filling / tastes great cat fights on the internet lately. Now, if someone wants to post videos of supermodels catfighting over microkernel / linus, I would then get pretty excited over the whole debate.
Wait a minute, too much information here...

Re:To Interject for a moment

[AKAImBatman]

You-betcha. I honestly think Mr. Tanenbaum is wasting his time in replying to Slashdot. If the last article proved anything, it's that the majority of responders were stuck on the whole "Linus 'won' this over a decade ago, so STFU!" (No one really 'won' the argument, but that's beside the point.)

There were a couple of good replies in there, but they all got drowned out in the noise. Soooo, I think it's a better idea to focus on how Minix might be made a viable OS rather than arguing the same nonsense all over again. As several of the posters here have already proven, they're not reading Tanenbaum's arguments anyway. So why should we expect this time be any different than the last?

Minix is already on version 3

[Anonymous Coward]

I'd like to point out that Minix is already FAR FAR *FAR* ahead of Linux in the version numbering war. Minix recently moved to version 3
And Linux seems to be stuck on version 2.6

And v3.12 (I think, I'm going from memory here) will finally support the X windowing system

Oh...maybe I should have left out that last sentence...kinda kills my argument

hey eveybody

[Anonymous Coward]

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash and gcc, and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)

Re:Still Debating

[AKAImBatman]

Forgetting something?

*Minix. This is still an educational kernel. A teaching tool. It remains unsuitable for "real world" use.

Actually, it's a start of a full-up Microkernel operating system. This isn't your grand-pappy's Minix, it's a brand new code base under the BSD license, intended to be developed out into a complete system. It's still taking baby-steps at the moment, but it's coming along quite nicely.

* NT. This is NOT a microkernel!

NT is a hybrid. It has Microkernel facilities that are constantly being used for something different in each version. Early versions of NT were apparently full Microkernels, but this was changed for performance.

* QNX Neutrino. This is the most successful microkernel ever. It deserves all the praise it gets. Yet it is still a niche product.

I would hardly call QNX a "niche" product. Running on everything from your car engine to Kiosk PCs (yes, that stupid iOpener ran it too), it's an extremely powerful and versatile operating system. Its Microkernel architecture even gives it the ability to be heavily customized for the needs of the application. Don't need networking? So don't run the server! Need a GUI? Just add the Graphics server to the startup.

Microkernels haven't failed. However, you may notice that nearly all the popular Operating Systems we use today were all developed back in the late 80's and early 90's. The real problem is that there hasn't been a need to develop new OSes until now. Now that Security and Stability are more difficult pressing issues than performance, we can go back to the drawing board and start designing new OSes to meet our needs for the next decade and a half.

Re:Plug central

[podperson]

You can't seriously believe that running MINIX is going to magically give you expertise that lets you talk about operating system kernel design.

It's apparent from this thread that one needs no expertise whatsoever to talk about operating system kernel design, so running MINIX should if anything overqualify you.

Re:So when did we forget...

[qbwiz]

Sure it has a monolithic kernel. It's just that it also has a microkernel, too.

The truth about microkernels

[Animats]

The real truth about microkernels is about like this:

• Getting the architecture of a microkernel right is really hard. There are some very subtle issues in how interprocess communication interacts with scheduling. If these are botched, performance under load will be terrible. QNX got the performance part right. Mach got it wrong. Early Minix didn't address this issue. See this article in Wikipedia. Other big issues include the mechanism by which one process finds another, and how mutually mistrustful processes interact. If you botch the basic design decisions, your microkernel will suck. Guaranteed.
• Most academic attempts at microkernels have been duds. One can argue over why, but it's the commercial ones, like QNX, VM, and KeyKos that work well, while the academic ones, like Mach, EROS, and the Hurd have been disappointing.
• Security models really matter. And they're hard. Multics got this right. KeyKos got this right. QNX is no better than UNIX in this area. Designers must work through "A can't do X, but A can trick B into doing X" issues.
• Trying to turn a monolithic kernel into a microkernel doesn't work well. Mach, which started life as BSD UNIX, ran into this problem, which is why MacOS X isn't based on the microkernel version of Mach.
• Drivers in user space have real advantages. Not only is the protection and restartability better, but because they have access to all the regular user program facilities, drivers for more modern devices are much easier. Things like Firewire and USB device discovery and hot-plugging reconfiguration are far easier at the user level, where you have threads, can block, and can call other programs. The old "top half and bottom half" driver approach doesn't generalize well to today's more dynamic configurations. Monolithic kernels have had to add kernel threads and dynamic loading of modules to handle all this, resulting in kernel bloat. Of course, a big advantage of less-privileged drivers is blame management - you can tell whether the OS or the driver is at fault.
• Startup requires more attention. A microkernel often doesn't contain the drivers needed to get itself started. So the startup and booting process is more complex. QNX has a boot loader which loads the kernel and any desired set of programs as part of the boot image. This gets the console driver and disk driver in at startup, without having to make them part of the kernel.
• The performance penalty is real, but not that big There's a performance penalty associated with the extra interprocess communication. It's usually not that big, but there are areas where it's a problem. If it takes one interprocess call for each graphics operation, for example, performance will be terrible. NT 3.51 had a nice solution to this problem, designed by Dave Cutler. (NT 4 and later have a more monolithic kernel, but that had to do more with making NT bug-compatible with Windows 95 than with performance problems.)
• I/O channels would help IBM mainframe channels, which have an MMU between the peripheral and main memory, are better suited to a microkernel architecture than the "bus" model the microcomputer world uses. In the mainframe world, the kernel can put program in direct communication with the hardware without giving it the ability to write all over memory. So there's little penalty for having drivers in user space. Which is why VM for IBM mainframes has been doing this for decades.
• If you get it right, the kernel doesn't change much over time. This is the big win, and why microkernels become more stable over time. In the QNX world, USB and Firewire support were added with no changes to the kernel. (I wrote a FireWire camera driver for QNX, so I'm sure of this.) The IBM VM kernel has changed little in decades.

So that's what you need to know about microkernels.

Re:So when did we forget...

[monkeyGrease]

> Why can't we just all get along?

Have you read the article? Tanenbaum basicly starts out by saying this is not a 'fight', but a technical discussion. Communication and debate is an important part of research and development. That's what is being attempted here, at least at face by Tanenbaum. There may be antagonism behind the scenes, or bias in presentation, but that is just human. The primary intent is to advance the state of the art, not fight.

All this 'what's the point' or 'we have this now' type of talk really bugs me. Everything can always be improved, or at least that is the attitude I'd like to stick with.

> When did we collectively forget that everything has its place

Another key component of research and development is to question everything. Not throw everything away and always start over, but to at least question it. Just because monolithic kernels rule the desktop now does does prove that monolithic kernels are inherently the best desktop solution.

In effect it is sometimes good to not even recognize a notion of 'everything has its place'.