So in my opinion, if the research community really thinks MicroKernel's are better, there would emerge a consensus on how to do it.

It is important, because what they don't tell you in a lot of these articles, is that without an agreement of how to do MicroKernel's, hardware manufacturers like Intel, won't invest the billions in hardware to speed them up.

Which is why MicroKernels can't hold a stick to Monolithic ones at the moment.

That's all well until you consider that XNU (Mac OS X) and NTOSKRN (among others Windows 7) are both NOT monolithic kernels.

Wow, Tanenbaum is pretty arrogant actually.

The only market MINIX targets is education. It's sole purpose in life is to make teaching OS internals, micro-kernel internals, and similar topics. It's small, easy-to-understand, and teachable. Nothing more.

MINIX 3 is initially targeted at the following areas:

Applications where very high reliability is required
Single-chip, small-RAM, low-power, $100 laptops for Third-World children
Embedded systems (e.g., cameras, DVD recorders, cell phones)
Applications where the GPL is too restrictive (MINIX 3 uses a BSD-type license)
Education (e.g., operating systems courses at universities)

There's virtually no software available for it.

To your 3rd point: I never saw a definition that says, all "modules" attached to a micro-kernel have to run in user mode.

To your 3rd point: I never saw a definition that says, all "modules" attached to a micro-kernel have to run in user mode.

This is a common misconception. People think the definition of a microkernel hinges on "everything must run in userland".

"This is a common misconception. People think the definition of a microkernel hinges on "everything must run in userland".

Tbh, it survives it most of the time. I had google maps crash a intel display driver yesterday ... first time I have seen a graphics driver crash take down Win 7.

For somereason the laptop had a Windows Vista Driver on a Win 7 machine ... updating seemed to fix it.

Yeah... WindowsXP works like a charm. Hardware it is then...

*hehe* not always the best technique makes the race.
Writing code for a microkernel with a clear message based interface is for most programmer a very different paradigm from what they are used to.
So, you get more guy working the old way, but it does not prove it is the better way.
BTW: Most embedded RTOSs could be seen as micro-kernels and there are a lot around. Far more then Linux installations !

allanregistos,

"If you can't provide that, then Linus' stance on microkernel is true: 'Good in paper, rarely usable in practice.' We have an evidence for this, just download Minix and install it anywhere you like, and tell us the usability experience with it."

Linus may or may not be right, but it is a fallacy to suggest that just because microkernels have a small market share, then microkernels are unusable.

The biggest reason independent operating systems out of academia don't have much to offer in general usability is because they don't receive billions of dollars in investment every single year. It's somewhat of a catch 22, but it really doesn't mean the technological underpinnings are bad, some of them may be genius.

Now I can't deny that Tanenbaum appears to be extremely jealous, but I do think he is correct when he said that non-technical attributes have far more to do with a project's success than technical merit.

(For the record, I don't know anything about Minix in particular).

"Ports to ARM and PowerPC are underway. Various programs and device drivers are being ported, and so on"

"*hehe* not always the best technique makes the race.
Writing code for a microkernel with a clear message based interface is for most programmer a very different paradigm from what they are used to.
So, you get more guy working the old way, but it does not prove it is the better way.
BTW: Most embedded RTOSs could be seen as micro-kernels and there are a lot around. Far more then Linux installations !

The single biggest issue with microkernels - slight performance hits - has pretty much been negated with today's hardware, but you get so much more in return: clean design, rock-solid stability, and incredible recovery.

But as we sadly know, the best doesn't always win. Ah, it rarely does.

Thom, I need an evidence: Give me an example of a pure, microkernel OS (not hybrid: as per Tanenbaum's design)that was in use in production systems.

If you can't provide that, then Linus' stance on microkernel is true: "Good in paper, rarely usable in practice." We have an evidence for this, just download Minix and install it anywhere you like, and tell us the usability experience with it.

I will bookmark this date, and then wait for five years or more if the Minix will become the next big thing in smart devices.

but are willing to fuck about endlessly when using Linux and thinking editing random text files is okay

just saying that you have some random crahes, except the majority of users that don't have an agenda to make Windows look bad (unlike yourself)

allanregistos,

"Can a microkernel-kernel designed OS such as Minix3 be good enough to scale to real-time demands of audio apps similar to what we found in Linux kernel with -rt patches?"

I am afraid it is out of my domain.

I know that pulse audio recently underwent a shift away from using sound card interrupts to using higher resolution sources like the APIC clock. This inevitably caused numerous problems on many systems, but never the less the goal was to get lower latencies by having the system write directly into the memory being read simultaneously a moment later by the sound card.

I don't see why any of this couldn't also be done with a micro-kernel driver. In fact I think the audio mixing for pulseaudio under linux today already occurs in a user space process using "zero-copy" memory mapping. I've never looked at it in any detail though.