[caster_cp]

Tanenbaum said that Torvalds would not get a good grade on his course, epic. "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)"

Perfect display of how universities are good at judging people about how well they know how to "play the game" (and usually that involves conforming to whatever frame of mind your professor thinks is right).

[carlosrg]

Well, a microkernel is harder to implement than a monolithic one and from a theoretical standpoint is a better design, IMO it deserves a higher grade in an operating system design course. Let's not mythify the 1992 Linux kernel, which probably wasn't _that_ good.

[jacquesm]

A microkernel is much easier to implement than a monolithic one. Been there, done that. The hard part is to get the messaging done with zero overhead (no copying), but using paging for the mbufs you can get quite far with that.

[qznc]

A microkernel is certainly easier to build than a monolithic kernel, because it does much less. You want to compare a feature-equivalent system, so microkernel + some userland drivers etc vs monolithic kernel.

The monolithic approach is easier because you just call a function in another component or read its data structures. In a microkernel, you need to design interfaces and protocols first.

[jacquesm]

No, the monolithic approach is definitely not easier for a simple reason: there is hardly any kernel level debugging going on in a microkernel based system because the kernel is small. Everything else is userland, so you can test your new driver as just another user process. This takes the sting out of a very large chunk of frustrating debugging and gives you access to all the userland tools to home in on the bug.

And even better: a crash of your driver does not take down the whole system. So you can just keep on working.

Designing protocols and interfaces is roughly the same in either case, after all you could settle on a very simple set of messages for most interface problems, with open, close, fcntl, read and write you would be able to do the majority of interface tasks.

[digi_owl]

That makes it sounds like a certain fashionable system that sits on top of the Linux kernel is monolithic...

[Someone]

If, as Tanenbaum did, you look at it from a computer science perspective, Linux wasn't good, indeed. It was 'just' a Unix clone.

From a software engineering perspective, it left a lot to be desired, too. It basically only supported what was on Linus desk.

One could say the things Linux had going for it were a) a GPL license, b) being small, c) arriving at just the right time, and d) Linus willing to accept external input.

Whether a) is an advantage of course depends on personal preference. b) helped with d) because it made it feasible for many to download the thing; c) was luck; d) IMO was the most influential factor.

[stefantalpalaru]

> from a theoretical standpoint is a better design

What about IPC overhead?

[mcosta]

>> theoretical

In theory you can postulate the performance impact is worth. In practice the is much more in it. That is the difference between computer science and software engineering.

[vezzy-fnord]

IPC overhead was primarily an issue with the Mach kernel in particular (due to it performing elaborate checks on message ports) that later ended up unfairly stigmatizing the entire microkernel design in general.

Contemporary microkernels like L4 are much, much faster.