The differences between the linux kernel and a microkernel (such as for instance QnX but there are plenty of others) is that everything is a process, and everything but that tiny kernel runs in userland.
It's the difference between 'potatoes' and 'mashed potatoes' ;)
No, you miss the point. I understand very well what a microkernel is. I'm asking you what the conceptual difference is between running a bunch of "macrokernel" systems inside a hypervisor and running a single microkernel with a bunch of processes. There is none: they are the same technology. The difference is in the label you stick on it. Which is a very poor thing to start an argument about.
(edit: I should clarify "same technology" to mean "same use of address space separation". Microkernels don't need to use virtualization technology like VT-d instructions because their separated modules don't need to think they're running on unadulterated hardware.)
> I'm asking you what the conceptual difference is between running a bunch of "macrokernel" systems inside a hypervisor and running a single microkernel with a bunch of processes. There is none: they are the same technology.
Complexity is the difference.
Hypervisors "won" because it was easier to implement; They only had to add another layer to the stack, rather than fundamentally change the structure of the OS.
The outcome is a more baroque collection of code, though. Worse truly is better.
The difference is the purpose of the system. I the prior, the purpose is to simply multiplex the hardware into multiple logical systems performing different tasks. And the later the purpose is to build a single unified system. It has more co,
Mmunication between the systems, and duplication of work is minimized. Only one process has any FS drivers in it. Another only worries about display. And more importantaly, it's more fault tolerant, if the display process goes down, all the other processes are generally built to wait on it coming back up. Whereas you cannot have a microkernel go down and not take an application process, file system process, and a network process with it..
I don't buy that at all, it's just semantics. Why can't multiple OS images be a "unified system"? That's what a web app is, after all.
And the fault tolerance argument applies both ways. That's generally the reason behind VM sharing too. One simply separates processes along lines visible to the application (i.e. memcached vs. nginx) or to the hardware (FS process vs. display process).
Potato, potato. This simply isn't something worth arguing over. And it's silly anyway, because there are no microkernels in common use that meet that kind of definition anyway. Find my a consumer device anywhere with a separate "display server", or one in which the filesystem is separated from the block device drivers. They don't exist.
(edit rather than continue the thread: X stopped being a userspace display server when DRM got merged years ago. The kernel is intimately involved in video hardware management on modern systems. I can't speak to RIM products though.)
It's the difference between 'potatoes' and 'mashed potatoes' ;)