At the time he was against microkernels it would be fair to say monolithic kernels did definitely have (and continue to have) performance advantages over microkernel architectures. Have things changed? Somewhat. Some of how OS kernels are used has changed and that has made microkernels more attractive again.

I feel the rest of your argument just feels like the jab at Linus is tacked on though because he doesn't seem to be against capabilties system. (infact the kernel has what? 3 capabilities systems?) Nor does he seem against forms of multi-level security or program shepherding. So maybe those weren't meant to be directed at him.

Either way I just wanted to say that people should give him some slack, his job isn't to please security zealots but to ship software all of us use and many of us depend on for our livelihood in a timely and reliable manner.

Linux does not have any form of capabilities (maybe Capsicum, but it's not finished). Capabilities are not POSIX capabilities, which redefined a decade-old term, but rather this [2].

The rest is just trite dismissals of the same faux pragmatism that Linus embodies. He's "not interested in the theoretical", as if there is any other? Before the now-mundane ideas became the staples of pragmatists, they were theories hidden in the research literature.

Linus is a major figurehead and his promoting of self-destructive attitudes is undesirable.

In fact, you claim he lives in the here and now. He does not. The here and now has long surpassed him and he now lives in his own realm.

[1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p...

[2] http://www.eros-os.org/essays/capintro.html

Meanwhile, systems like THE (Dijkstra), Burroughs B5500, IBM System/38, GEMSOS (Schell), RC4000 (Hansen), MULTICS, KeyKOS (Bomberger et al), and VAX VMM Security Kernel (Karger/Lipner) showed how to design and implement systems with ultra-high reliability and/or security. These lessons were mostly ignored time and time again even when they could be applied. User-mode drivers and languages with pointer/buffer/stack protection would have by themselves prevented ridiculous amounts of problems. I heard that, after around 2-3 decades, the UNIX crowd is adding some user-mode drivers. See the problem?

Note: Far as lightweight systems & adaptivity, you should see the work of Brinch Hansen, Niklaus Wirth, and Andy Tannenbaum. They applied safe, modular techniques on systems with less resources than today's. UNIX and Linus resist for both personal preference and inertia, not valid technical objections.

Linus holds the vast majority of the blame here, simply put, he is an idiot when it comes to security or looking ahead at how things will be in a couple of years. Linux is slowly entering every single aspect of our lives and this trend will only accelerate via IoT. Imagine what this means about security with Linus in charge.

We now KNOW that there are intelligent adversaries out there that spend hundreds of millions to defeat security worldwide. It is simply UNACCEPTABLE and downright MALICIOUS STUPIDITY for Linus to hold the views he does in this day and age. He's been repeatedly warned and cautioned for more than a DECADE now and he's laughed at and ignored valid criticisms from people with much more foresight than him. If this trend continues, he should be NAILED to the cross.

A security bug is NOT just a bug.

No, I shouldn't have to DISCONNECT everything that runs Linux from the Internet if I want it to have a modicum of security.

Do you have some details on this? I did not realise the situation was so bad.

So, one could say it's pretty bad even if the "many eyes" and code audits are finding/fixing a ton. Simply too many to justify if their process is any good. An recent example I found was the Saturn project throwing an automated tool at it and finding 100+ real bugs in one go.

http://saturn.stanford.edu/pages/papersindex.html

Do you have recommended reading or links so that I can get up to speed?

Here is a recent example where PaX team are called "leeches" by a maintainer: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-A...

If this sort of attitude is not stupid, I don't know what is. These people can't see the forest from the trees.

Yes, I've heard this implied before. This is effectively doing the adversary's work for them, and for free! Perfect truth is never attainable, therefore let's not do science?

To put it in more positive terms, achieving perfection is not important. What is important is a continual methodical process to keep improving, that more-than-offsets natural tendencies to deteriorate. In software engineering terms, it means not letting the project grow to a state where the exploit-discovery rate is so high. Since exploits generally affect the entire kernel, it's negligent and reckless, to be satisfied with merely keeping the bug-per-SLOC ratio constant.

Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important in eliminating the rest of the bug classes...

Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.

Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.

People should keep barking given how much depends on the project now. Plus support alternatives that take better approaches to architecture like old EROS, MINIX 3 (reliability), or GenodeOS (security/reliability). Safe native approaches like security-enhanced Oberon System or JX Operating System would also kick butt. Each achieved certain robustness properties in mere years with small teams due to good design.

UNIX and Linux took decades to get usable, still give hackers MB of opportunities for kernel attacks, and still crash my systems on occasion. Meme: "Failure to learn the lessons of the past and apply them."

My point wasn't the specific proactive mitigations, but rather Linus' attitudes creating negative perceptions.