Technically, a capability-based desktop OS makes perfect sense. In practice, the microkernel people have been polishing their kernels and about to start on userspace next year... for 30 years.

(One exception to this is QNX which was killed off by weird business decisions.)

Take a look at Genode. It‘s come quite far in that regard.

https://genode.org/

My Android devices running userspace drivers written in a mix of Java and C++ thanks to Project Treble seem like a step into the right direction.

Or the new userspace device driver model introduced by Catalina. As per WWDC, for every new user space driver API, the old kernel one will be automatically marked as legacy and removed after one OS release, with the long term roadmap to replace all the kernel API extensions.

Just like Windows 10 increases the amount of sandboxing with each bi-annual release.

Userspace drivers permit upgrading the kernel to a certain point (depending on how kernel APIs change), but your forever trapped with the bugs and vulnerabilities in the userspace blobs.

Its a step forward in kernel upgradability, but it also takes the pressure off vendors like Qualcomm and ARM to upstream their patches. I hope the kernel continues making significant changes that break out of tree, proprietary drivers.

The harder it is for these players to act in bad faith, the sooner they'll collaborate with the kernel developers and mainline their code.

As proven by every other OS with proper driver ABI, this isn't an issue.

And as proven by FOSS drivers that eventually got purged from kernel tree, having source available is meaningless if everyone just lets the code rotten to the point of being purged.

As for pressuring vendors, the source code is available, and the license allows them to never upstream, it isn't as if Joe and Jane know what that is when buying a new phone.

Windows has had multiple breaking changes to the driver ABI between Windows XP and present. There is no "proper" futureproof driver ABI, otherwise there would be a major OS using one.

In almost 40 years, there were two breaking changes from 9X to NT family, from XP to Vista.

Two. Linux? Who's counting anyway.

What if we pressure Qualcomm and ARM for 20 years but they still don't upstream anything? What about 50 years? Would you change your position?

So long as they're spending most of their cash on maintaining out of tree patchesets for the Linux kernel, that is tens to hundreds of millions a year in wasted money on their part.

Eventually the community will write their own drivers (as has happened with Mali) and the respective vendor will have a reckoning internally (like what happened with AMD's GPU driver) whereby those advocating for wasting money on out of tree code leave the organization with egg on their face for bilking the company out of significant R&D cash.

It is very hard to claim that its worth it to develop a proprietary driver when a comparable performance driver already exists for your hardware in-tree. The in-tree driver will almost certainly be easier to use & break less often than out of tree code that the kernel devs don't think or care about breaking.

> QNX which was killed off

Are you sure? The latest version is only ~2 years old, and they still seem to be hiring: https://bb.wd3.myworkdayjobs.com/QNX

I was in the automotive industry. 10 years ago every infotainment System I had seen was either built on QNX or windows CE. When I left the industry later all systems I interacted with had moved to Linux. Why? Driver and off the shelf application support was a big reason. For QNX every driver had been ported, which is a huge task for something like a modern GPU.

It looks like the desktop version of QNX was killed off in 2014 although they stopped promoting it much earlier.

There are some in-car infotainment systems and dashboards running on QNX. It's a fairly pleasant system to work with.

And Minix which runs inside every Intel CPU.

High-assurance security did do work on secure browsers. One prototype inspired Chrome's model. Here's an old thread where I listed some:

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

One or more might be integrated into seL4. Alternatively, components in something like IBOS might be done with higher assurance like seL4 or Muen.

To see what seL4 can do in practice in a desktop/workstation/server context, I suggest you take a look at Genode. Particularly, their recent dynamic system images.

You can run Linux under L4, as mentioned in the post. I understand this is a common thing to do on phones with Qualcomm chips, using OKL4. But that isn't to protect you from malicious software; it's to protect malicious software from you. Qubes is a similar system with more praiseworthy aims, but not using L4 as the hypervisor.

Running a web browser directly on a microkernel is a reasonable thing to do, and it's likely that Fuchsia will end up doing it, but it will involve a lot of work.

The performance expectations of JS generally do not have anything to do with the operating system, but as explained in the post, when it comes to fundamental OS services, seL4 is more than an order of magnitude faster than even other microkernels, much less FreeBSD, Linux, or Microsoft Windows.

Microkernels generally need higher performance for those things because operations such as read(), which involve just a system call on a monolithic kernel, with context switches into and out of the kernel, involve a full context switch to a separate server process and back on a microkernel.

>...when it comes to fundamental OS services, seL4 is more than an order of magnitude faster than even other microkernels, much less FreeBSD, Linux, or Microsoft Windows.

This seems to imply that seL4 is faster than FreeBSD, Linux, Windows is this what was intended to be conveyed?

Yes, but most of what you do on a computer isn't bottlenecked on the kernel—less still on a microkernel. So this doesn't necessarily mean the computer will feel faster or finish computing sooner.

Questions about performance are often complicated affairs that involve considering all factors including hardware, software, data operated on, etc to get meaningful answers.

That said I don't think data exists to show that SeL4 is faster than mainstream OS kernels just much faster than research microkernels which have always been much much slower than mainstream monolithic kernels.

In fact one would reasonably suppose that it would be measurably slower due to increased overhead. This may well be well worth it but this doesn't mean we ought to engage in speculation not backed by data.

No, research microkernels are generally much faster than mainstream OS kernels when you measure the operations that are implemented by both, because the crucial question for microkernel viability is whether they can be made to be fast enough; that's been true for 30 years. So an immense amount of microkernel research has focused on that one thing. You can run lmbench on your Linux laptop and get some numbers you can compare with published L4 numbers on similar hardware.

The way that microkernels are sometimes slower is, as I said above, on operations that monolithic kernels implement internally, but microkernels leave to userspace processes. For example, ping-pong IPC is something you can measure on L4, and reliably get orders of magnitude better performance than on Linux. But creating a file isn't, because L4 itself doesn't have files—you can implement them in userspace, and that can be done with varying degrees of extra overhead. It might still come out about even with Linux (I think I've seen some results to that effect) but it probably won't be orders of magnitude faster.

The part of your comment I agree with is that measuring performance is complicated.

Can you point to benchmarks of software performing an actual useful task on both a mainstream OS and SeL4 for an apt comparison?

No, I don't know of any. But that's not relevant to what I'm claiming, which is a much narrower claim.

>seL4 is more than an order of magnitude faster than even other microkernels, much less FreeBSD, Linux, or Microsoft Windows

Seems to be a pretty broad claim without anything to back it up.

At this point you are exhausting the presumption of good faith in two ways.

First, by omitting the immediately previous qualifier from your quote: "when it comes to fundamental OS services, seL4 is more than an order of magnitude faster...". This omission turns my correct claim into a plausibly false one, one which I have specifically disclaimed, in detail, in three separate comments in this thread already, in order to avoid the kind of confusion that could reasonably produce reactions like yours. The "benchmarks of software performing an actual useful task on both a mainstream OS and SeL4" you ask for are relevant to the plausibly false claim, but not to the correct claim I was actually making.

Second, you falsely claim that I am saying things without anything to back them up. This would be a legitimate criticism if I were talking about performance numbers for some kind of trade secret software, but in fact (with the exception of Microsoft Windows) all of the operating systems discussed here (seL4, FreeBSD, Linux, plausibly Fiasco.OC and Mach) are open source and have abundant published benchmarks, including many in the seL4 papers published by the dude whose blog post we are discussing. There is a very great deal of freely available evidence.

In short, you are lying about what I am saying, and you are lying about the available evidence for evaluating its veracity. Therefore I think the presumption of good faith on your part in this conversation can be soundly dismissed.

I asked you what you thought were meaningful benchmarks illustrating your point

I'm not lying about what you said. I even copied the longer section of your quote in the prior post aside from the entire thread being right above on my device and yours.

I'm also not lying about the availability of evidence to prove your claim just asking you to provide a link to such.

You spoke with authority and then get upset and wave your hands about yelling LIAR when asked for supporting links.

Perhaps begin again respectfully or cease discussing.