I disagree that Minix is conceptually interesting. It's a half-way house between monolithic kernels and microkernels with the disadvantages of both and none of the advantages.

I'm a big fan of microkernels, I think Tanenbaum had it right in his spat with Linus but at the same time Minix' implementation is very far from what could have been a fantastic little OS.

How is it a half-way house? Genuinely interested and curious, not snarking.

Because it is 'not quite a microkernel'. For instance, many things that would be processes in a real microkernel are built-ins in Minix. Which makes them impossible to replace at runtime, nor can the kernel function without them. I get it, these are hard problems to solve especially when bootstrapping but it saddled Minix with a bunch of heritage that it has not been able to shake.

Posix compliance on the one side and running a true microkernel on the other is a hard problem, and after all the real goal of Minix was not to 'be the best microkernel' but to simply provide an OS for study purposes to students at VU and other universities.

If you want to see what an ideal microkernel looks like take a look at the QnX architecture, that's much closer.

>Posix compliance on the one side and running a true microkernel on the other is a hard problem

>If you want to see what an ideal microkernel looks like take a look at the QnX architecture, that's much closer.

Have you looked at Genode + seL4?

Yes, it's been a while though (a decade?), since I last looked at it. I will have another look to re-familiarize myself and to see what they've been up to, thank you for the pointer.

> For instance, many things that would be processes in a real microkernel are built-ins in Minix

Can you give some examples?

Just one example: the Minix kernel is 'root aware' which makes it hard - or even impossible - to switch out the root file system while the OS is running. The same goes for the process scheduler/interrupt handler which is a 'hard' part that can never be upgraded while the system is running, and is responsible for a fair amount of latency on the way from interrupt to the actual handler in the device driver (and not the stub). Device drivers that can not handle interrupts directly are going to be (much) slower than device drivers than can handle the interrupts themselves.

By the way, my Minix knowledge is somewhat dated, I always thought that it had huge potential if the 'holy houses that Andrew built' would have been allowed to be pushed over, even if that would come at the price of POSIX compatibility, which as far as I'm concerned is overrated if it is the thing that holds us back from having an ultra reliable field upgradeable operating system. The big problem with POSIX is 'fork', it more or less assumes that you're looking at UNIX and fork was a kludge all along that just happened to solve a couple of nasty little problems that have to do with file descriptors. It's one of those 'leaky abstractions' that end up haunting you forever if you do not address them immediately and decisively. But because POSIX compliance is what got Minix established in the first place it became very hard to let go of that. Plan 9 suffers from the same issue by the way.

https://en.wikipedia.org/wiki/Fork_(system_call)

I'm all for reliability over performance, unfortunately the rest of the world seems to disagree with me.