Nice theory. It is just, that writing drivers is hard and not many people are capable of it. So for most existing driver issues, it will be much cheaper to buy new expensive hardware that might actually be somewhat supported for a while - than hiring someone to write a reliable open-source driver for it. (oh and of course, you also cannot buy the latest hardware as then there is mostly no support there yet)
I would love my whole system to be fully open source and working.
But since hardware is very closed anyway, I would rather have a couple more binary blobs on my system, that work reliable - instead of a bunch of open, but very faulty drivers. So I very much would prefer a stable Linux ABI.
Because without - I am forced to use Windows on my new Laptop, as everything runs much slower and buggier on linux - and I would like to use my laptop to work on other things - and not on the laptop itself.
There are a lot of old computers in research laboratories running Windows XP because some proprietary driver for some important piece of equipment (like a mass spectrometer) doesn't have a 64-bit version.
The closest examples so far with Linux are System76 and Purism:
https://puri.sm/products/librem-14/
This is also what makes the Surface tablets and Surface Book so great. There's a top to bottom alignment of interest in creating the best user experience and making sure the product works.
The closest thing to computing hell is when a commodity operating system is slapped onto the cheapest commodity hardware by someone who isn't concerned at all about using it, but has a list a mile long of systems to configure. There are plenty of enterprise IT-managed work laptops with no display or chipset drivers that can't hibernate, but at least they have McAfee virus scanner installed and the corporate group policy enabled.
I use my desktop OSes for my job, but could be perfectly happy with a Chromebook for most of what else I do in my life.
Yes, your type of grandma exists, but I don't know her.
Who (outside of HN readership) wants this?
I hardly doubt you are kernel developer yet you "know better". Such people always do.
By the way, Linux did well on Android because it is made there with "grandma" in mind.
Linux did well on Android because it does not suck. Mainline kernel boots hundred of models (postmarketOS). Another part mostly unchanged — browser. ChromeOS is Linux kernel and browser.
You've said hibernation is a matter ideological purity, no, it is a matter of practicality. You have to be kernel developer to understand practicality.
I've never said that.
I think this conversation is going nowhere, no reason to continue it.
This has a lot of advantages of this approach over binary drivers in that:
- The driver can be updated so it survives architectural changes (say from x86 -> amd64 -> armv7 -> aarch64 -> riscv).
- The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries.
- Bugs in the drivers can be identified and fixed by anyone (most importantly, critical security bugs).
Also, good ABIs are hard to get right. Windows had to completely rewrite their audio subsystem and the associated driver interfaces around the time of Vista to get low-latency right, for example.
But that said, the use of binary blobs exists even today (CPU microcode, various driver firmware blobs that people don't have time to reverse engineer, etc.).
Someone else also mentioned ndiswrapper, which reimplements the binary interface for supporting Windows network drivers on Linux.
So you can pick any Windows driver interface and write a Linux kernel module or a combination of a kernel module and some userspace framework that can host and utilize that driver. You might have to emulate or paravirtualize some hardware access or instructions to avoid causing conflicts, but there's nothing technical stopping you, other than it just being hard. It can also never be included in the upstream Linux kernel for the ideological reasons I already mentioned.