Linus is not saying that microkernels are architecturally bad. He concedes that it is an architecturally superior idea but it is not a panacea when it comes to OS design. It merely shifts inefficiency outside the kernel.
This is what he actually said on Slashdot (my emphasis added):
> I think microkernels are stupid. They push the problem space into communication, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix. They also lead to horrible extra complexity as you then have to fight the microkernel model, and make up new ways to avoid the extra communication latencies etc. Hurd is a great example of this kind of suckiness, where people made up whole new memory mapping models just because the normal "just make a quick system call within the same context" model had been broken by the microkernel model.
But does it run efficiently and quickly?
I'd aruge: not slow enough not to be worth the benefits of userspace everything, the ability to have a completely distributed system, and not slow enough not to make the interaces with the kernel not wonderful. I much like how plan 9 skips the whole RPC and syscall nonsense and does almost straight file IO and socket communication for everything.
It is like Java vs C - it isn't slow enough not to take the niceties in some circumstances. High performance computing might like the Linux kernel, but as a developer who wants working applications that are really easy to interface with OS features, Plan 9 has that nailed.
I don't know where to start.
That looks like the definition of a theorerically superior idea to me.
On the contrary, good engineers are not dogmatists. They're open to new ideas and strive for simplicity, which means striving for unified approaches based on empirical reasoning. See Newton.
Software engineering is about creating something for humans while working with other humans. It is a science that is primarily constrained by human nature.
Physics is about describing reality. It is a science that is primarily constrained by reality.
In software engineering, it is always better to choose a flawed technical solution that leads to less friction among humans. Because less friction among humans is the entire point of software engineering.
Your contrast of science and engineering is horribly naive.
In science, we use Ockham's Razor regarding explaining phenomena; in engineering we use Ockham's razor regarding implementing requirements. Both follow the same logical, empirical process, and both strive for the same result: as simple as possible, but no simpler.
This has nothing to do with the engineering 'KISS' principle which desires simpler architectures because they are easier to understand and thereby to debug and maintain. The point is to avoid astronaut architecture, which is what you get when you chase theoretical ideas rather practical solutions. Linus's whole point is that microkernels are a prime example of astronaut architecture.
1991 called. They told you to keep waiting.
If you have to write way more code to hack around the message passing performance, you haven't simplified anything.
If performance were not a concern, message-passing could be simpler.
The irony is that it's Torvalds who is leaping to wild and unjustified generalizations.
"Occam’s razor has been interpreted in two quite different ways. The first interpretation (simplicity is a goal in itself) is essentially correct, but is at heart a preference for more comprehensible models. The second interpretation (simplicity leads to greater accuracy) is much more problematic. A critical review of the theoretical arguments for and against it shows that it is unfounded as a universal principle, and demonstrably false. A review of empirical evidence shows that it also fails as a practical heuristic."
http://reference.kfupm.edu.sa/content/r/o/the_role_of_occam_...
They do not follow the same logical processes. Science begins with observations and uses inductive reasoning to create theories. Engineering starts with formal rules and proven facts, and uses deductive reasoning to prove the correctness of a particular solution.
(there's actually 2 main approaches to engineering: the science/proof/theory based one and the empirical one that also uses science/proofs/theory but as a scaffolding and as a compass to realize we don't waste resources trying to do something "really" impossible)
Back on point, In grad school, we read the Tenenbaum-Torvalds debates in OS class to get an idea of the current state of research. Tenenbaum's point, among other things, was that microkernels were an unsolved problem. Granted they pushed the problem space into communication, and you had to contend with latencies....but that was the whole prize, to solve this brand new problem space. Whereas big bad monolithic OSes were a solved problem. We know they could be done. As far as a CS researcher was concerned, there was no meat in that space...it was mostly implementation detail and optimizing. Whereas microkernels, despite being a cleaner, more elegant approach to OS design, clearly had tons of issues to be solved, and whoever took a stab at them would push the state of the art forward. That is the point => to find a superior technical solution, not minimizing friction among humans.
If it actually works, sure. Unfortunately, due to uncontrolled hipsterism most technologies touted as "technically superior" don't actually work. It's very easy to throw up a demo or a benchmark. It's very easy to write a paper that shows how amazing what you wrote happens to be. Integrating something into a production stack that doesn't cause more problems than it solves is really hard. And it very rarely happens.
So yeah, while you're still at the office at midnight trying to track down what exactly in your stack exploded ... I'm sleeping ... because I decided to go with something that's proven, rather than the latest and greatest.
> we should build the OS in PHP
Bonus points for trolling.
Linux is nice and practical, but try working with it as a systems programmer sometime. It's full of hacks and arbitrary complexity and all manner of nonsense that persists year after year.
Until they don't. You don't know what who is going to come up with next.
When someone comes to you with an inelegant hack that makes her database benchmark run 20% faster, you can either accept it and sacrifice some of your elegance, or your can reject it on elegance grounds and sacrifice some of your relevance.
> ... tons of issues to be solved, and whoever took a stab at them would push the state of the art forward. That is the point => to find a superior technical solution, not minimizing friction among humans.
You are talking from the perspective of computer science research, whereas he is talking about software engineering in practice. There's a difference there, imho.
Wrong. The "problem" is designing an operating system that is reliable, fast, fault-tolerant, user-friendly, maintainable, etc etc.
"microkernels" are just one example of a proposed solution to solve this problem - a design that despite the fanatical support of rabid academics like Tenenbaum has been shown to be a poor choice due to the complexity involved in implementation.
CS has lots of similarities with physics, yes. But the devil is in the differences.
Think of it this way:
If Newton had been trying to solve problems that included objects moving near the speed of light, not caring for what that would imply, he would have failed miserably.
Computer scientists were trying to use microkernels to solve problems that required performance, without caring for performance, and failed miserably.
Microkernel research was useful, Linux actually implements a lot of concepts devised to improve microkernel performance. It just happens that these concepts work even better when applied to a monolithic/modular kernel. Though luck for microkernelists...
I like and use patterns, but rarely according to 'textbook' implementations, and I always felt that the patterns literature never went deep enough into Alexander's fundamental principles, which I think you've paraphrased so well here.
Less friction among humans is the entire point of software engineering.
Should be on a banner over every CS department and software publishing house in the world.
Are you trying to imply that Newton was somehow an effective software engineer?