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.