Which is why I wonder if he can actually back that up by his own assertions, instead of one sided experience of "just works". If, as Tanenbaum wrote, the MMU should just enforce the separation that encapsulation techniques intend, then that means that the techniques can fail due to buggy implementation, which again just means shifting the goal posts, as a bug is a bug. A lot of exploits rely on the userland, I suppose, and at that point the observed complexity would be increased for a microkernel system, too.

But I digress, actually I'm one of the commentators Tanenbaum mentions. I don't know if the systems should be isomorph in the end and it's just the development process, or if speed is inversely proportional to complexity, as speed is always the other measure next to correctness.

Could you clarify? That comes off as arguing against a whole model of preventing problems because an implementation of that model might have a bug. I'll add that separation kernels, strongest of this approach, were usually between 4-12Kloc with EAL6-7 verification activities performed. Two have endured years of pentesting as well. Far as MMU, there are a number of verified HW systems with several verified for security through mathematical analysis, full testing, and pentesting. Those include Rockwell Collins AAMP7G and some smart card MPU's. So, we do shift goal posts as follows:

Goal post 1 (Linus): Hundreds of sys calls. Hundreds of thousands to millions of lines of code with full read-write access to memory. Buggy drivers included. Explicity and implicit communications plus loops throughout. Unsafe language used throughout.

Goal post 2 (opponents): Handful of sys calls for fundamental abstractions. Tens of thousands of lines worst case preferrably a few thousand w/ full access to memory. Rest isolated in own memory. All communication goes through IPC or shared memory segments explicitly marked w/ kernel calls (and analyzable). Prefer safer language (eg Ada/SPARK) plus verification for kernel or trusted partitions w/ some avaiable in proprietary and FOSS.

There's a world of difference between the two goals. Linus's has been proven ridiculous in two ways: attempts by high-assurance security to secure UNIX previously discovering fundamental obstacles; the results of Linux's development processes in terms of bugs found, severity of their impact, availability loss during defects, and plentiful covert channels. Interestingly, that's the same stuff found in early attempts. One can't prevent such problem in small UNIX but will in obese Linux? Unlikely.

The other goal is supported by theory and practice. In the theory, you can only understand a system if you make it modular, localize the effects of components much as possible, analyze interactions of those components, and add in failure modes. Each of these is supported empirically with some of it even done by Linus. Otherwise, you run into both combinatorial explosion in analysis and systems' version of Butterfly effect in error propagation. Separation kernels are one, but not only, method that sticks with theory through and through while eliminating two whole classes of severe errors: kernel-mode failures in obsese software & drivers; unintended communication of logically, distinct partitions. Experience supports them as field evidence, CompSci pentesting, and NSA pentesting all showed their techniques to dramatically reduce risk as such that they didn't experience problem monolithic OS's and hypervisors did.

So, Linus is defying literally decades of experimental activity in CompSci and high-security field without citing anythign to back it up. He does this even while his own work fails to do better in reliability or security. He is, as we say in the business, talking out his ass.

"A lot of exploits rely on the userland, I suppose, and at that point the observed complexity would be increased for a microkernel system, too."

This much is true. Microkernels are one technique among many to break down and manage complexity then enforce that at some HW level on popular, insecure-by-design CPU's. Only so much one can do without unbearable performance loss. Other CPU's designed for security let one try more things, even monoliths. Thing is, one still has to layer and modularize the system with careful attention to resource sharing and interfaces. What microkernels do. ;) Dijkstra's THE was first attempt at these techniques with design and results described in p16 of this link:

http://brinch-hansen.net/papers/2001b.pdf

"But I digress, actually I'm one of the commentators Tanenbaum mentions. "

You have a talent for making vague references. He mentioned all kinds of claims, esp negative, that people made. Which ones did you make? And did anything I wrote so far help to address it? I can be more specific on whatever topic with references hopefully.

"I don't know if the systems should be isomorph in the end and it's just the development process, or if speed is inversely proportional to complexity, as speed is always the other measure next to correctness."

You're the third person in a few days to essentially wonder about that in front of me or ask me how I'd do it in a high assurance product. I've been piecing together a high-level view of a few new models in parallel. Maybe I need to focus on that more since my secure ASIC research is mostly done. From what I've learned, it's more about the logical design, breakdown, interactions, mapping to real hardware, and any information/energy flows. So, designing secure, reliable, or maintainable systems is necessarily a holistic process split between development and implementation mechanisms. Trick is finding just right set of techniques in each spot to maximize benefit.

I'm actually done with microkernels outside insecure CPU's like Intel as high-security research taught us to focus on hardware-software combos as software-only model is a fundamentally bad idea. I'm looking at tagged, capability, control-flow, crypto-protected, and language-oriented methods. Incidentally, the first machine that hit most goals we want used a combo of good architecture, safer language for OS, CPU designed for it (eg enforces bounds-checks), and HW redundancy. We know what works because systems like Burroughs B5000 already did it in the 1960's. ;) SAFE project (crash-safe.org) follows that lineage plus adds mechanisms for arbitrary security policies at CPU and compiler levels with functional programming for trusted components.

In such work, you may find the answer to your question. Or new, better questions to ask. :)

Suppose I'm just interested in desktop applications. Linux is already treated as a lost cause. That's what gets me because at the moment, the microkernels don't seem like an alternative in my case. If I'm not yet convinced by the opponents, I'm looking for facts, not anecdotes or authority. I can kind of understand the downsides of a free for all memory model, but Shapiro's rebuttal is lacking a bit of substance and doesn't quantify anything with a meaningful measure, probably because a model that shows the downsides might seem like a waste of time. That's him as a researcher putting the burden on Linus. That's not quite what I meant with shifting the goal post, though. Smaller steps are easier to take obviously, so shifting in that direction is helpful, but it also means adding more goals. I think, security and development speed are at odds here, too. I'd rather see them all cooperate (to my benefit, basically for free).

"Suppose I'm just interested in desktop applications. Linux is already treated as a lost cause. That's what gets me because at the moment, the microkernels don't seem like an alternative in my case. If I'm not yet convinced by the opponents, I'm looking for facts, not anecdotes or authority. "

Ahh, OK. Well, I'm guessing you probably used Windows/DOS desktops back in the 1990's, right? They were OK for apps but architecturally terrible. That meant they crashed a lot, slogged down under heavy load, and so on. UNIX and Linux didn't do much better outside of SGI's machines. Hell, were barely usable. You'll appreciate what this microkernel-based, concurrency-oriented desktop is doing if you remember those days:

https://youtu.be/BsVydyC8ZGQ?t=16m8s

Note: I couldn't even drag videos without them skipping back then. They do that in the demo while other stuff is playing. Too bad Microsoft had a monopoly and Jobs turned them down for Darwin in Next (later became Mac OS X).

An early great one that's in all kinds of stuff is QNX microkernel. It did a POSIX-compatible implementation w/ microkernel, fast message-passing, and hard real-time. Later showed off its capabilities with a desktop on a floppy with GUI, web browser, etc. Users, including Animats (Nagle) here, said you could be doing day-to-day stuff with big compiles in background with no hit to responsiveness due to its great scheduler. Once Blackberry bought it, they deployed it in the Playbook. If you used an iPad of the time (circa iPad2), then you'll be very impressed with the alternative's performance and responsiveness.

https://www.youtube.com/watch?v=vI1VgedbMUY

Note: I couldn't find the original demo showing it outperform iPad on most stuff. Several fan-made ones did but were boring. I'll spare you. Important part was alternating between web browser, (either a game or video here), and Need for Speed game with no apparent slowdown. Much like BeOS demo. These are despite Apple having a severe lead on them across the board. The results appear to be directly from QNX as its desktop prototype & embedded solutions had same properties.

Far as old school, the world still runs on IBM's mainframes for transaction processing and batches especially. Now days, they also run thousands of Linux VM's. Shapiro's EROS on x86 was modeled after KeyKOS: a capability-based microkernel system aimed at mainframes. It performed well enough to do the job plus virtualized IBM OS's, VMS, and UNIX. Allowed fine-grained separation, high-security enforcement, and persistence of all apps' state via checkpointing built into the VM. Core functionality supporting all that took 20Kloc.

https://www.cis.upenn.edu/~KeyKOS/

Latest entrants are MINIX 3 and GenodeOS, focused on reliability & security respectively. Each have something like 2-3 people working on them for only a few years doing a significant amount clean-slate. Thanks to architecture, MINIX 3 already achieved reliability that it took UNIX's decades to pull off. GenodeOS is alpha-grade usable on desktop right now while already deployed in embedded. Similar architecture in OKL4 microkernel is in 1+ billion phones mostly isolating basebands but sometimes virtualizing Symbian, Windows Mobile, or Android. Might be in your phone invisibly doing its job. Green Hills INTEGRITY or a variant of it is doing same in Samsung Galaxies via KNOX. Feel free to try any of those products to see how your performance, etc doesn't magically go away despite constant microkernel activity. ;)

So, hopefully these convey the experience of using a microkernel vs monolithic UNIX or mainframe stuff even if you're not personally using one. I hope seeing BeOS and Blackberry's QNX system scream on limited hardware will show you advantages or disadvantages aren't theoretical: the stuff works well enough sometimes faster than competition. I can only imagine how much easier to use, reliable, upgradeable, and performance my desktop would be had a billion dollars worth of labor been put into such architectures instead of UNIX/Linux. Especially given what small teams did with them.

"but Shapiro's rebuttal is lacking a bit of substance and doesn't quantify anything with a meaningful measure"

I gave you a link with tons of substance supported by research prototypes including Shapiro's like EROS. They theorized, built stuff to test, modified when differed from expectations, rinse, repeat. Whether the specific memory predictions come out true or not is barely relevant. What matters is "Will it perform well enough with the reliability, security, and maintenance advantages it claimed?" There was enough data in that link to prove that out several times over. I added examples for desktops and tablets in this comment. Now it's up to Linus to prove BeOS and Playbook users were experiencing a mass hallucination when those boxes were faster, more stable, and more usable than Linux-based systems. :)

Combo of cheap hardware, legacy effects, and lock-in to software killed off all desktop competition except projects that virtualize stuff compatible with major players. That's why you are stuck with Linux, QubesOS, maybe GenodeOS eventually, etc. Economics and social factors, not technical. "Worse is Better."

List of UNIX alternatives for you to investigate to see what superior attributes it could include or explicitly rejects:

https://news.ycombinator.com/item?id=10957020

Have fun with those. Especially Genera. Just imagine, with or without LISP, what developing and deploying on machines like that would be like. Still nothing that can do all of that.