It is, but the point of not defining a Linux ABI is to avoid proprietary, binary blob drivers and instead force drivers to exist in the upstream Linux kernel where they can be maintained by the kernel developers and freely distributed.
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.
"The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries."
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 will never be a year of the Linux desktop if ideological purity (of a highly questionable ideology in the first place) continues to stay in the way of practicality. Grandma doesn't care if her network driver doesn't give her the whatever number of software freedoms as defined by RMS and honestly neither do I.
It's easy to criticize the chosen trade-offs, but I would argue that Linux would actually be in worse shape today if it had taken the driver ABI approach and encouraged proprietary drivers. Many drivers originally upstreamed in the 32-bit x86 era would no longer be usable on amd64 had they been 32-bit proprietary drivers, and a good number of 64-bit proprietary drivers would be useless on ARM platforms like the Raspberry Pi.
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.
None of the issues mentioned are about some theoretical ideological purity, they're all about very practical pragmatic concerns. There are a lot of open source software that put some ideological purity above all other concerns, but the Linux kernel is certainly not among them - if anything they're among the most "flexible" when it comes to GPL compliance.
If you really care about user experience, I recommend seeking out products made by companies that are vertically integrated, like Apple, because they have the power to curate the components of their products for maximum compatibility and support.
The closest examples so far with Linux are System76 and Purism:
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.
Grandma doesn't care about the year of Linux on the Desktop either because she probably just uses a macbook to manage the server farms that are running on Linux and won't need to hibernate.
Honestly how old is "grandma" in 2021? Grandma is probably 60-70 years old, and likely grew up in the "space age" of computers. She likely has a Facebook and uses an Android phone. Grandma should take some time to learn the Linux way, she'll be a better computer user for it.
Why should she? Grandma primarily uses Facebook, Instagram, and Facetime. Grandma doesn't have a goal to become a better computer user in general terms. Linux gives effectively 0 value to her over any other OS. And negative value in a number of various ways. Driver support among them.
At this point, I wonder if Grandma wants a desktop at all. Maybe Grandma just wants a tablet, perhaps with a keyboard. Tablet OSes don't really hibernate, but they use a lot less battery and have software designed to come back from a cold boot quickly.
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.
Or she doesn't care about computers and just wants to call her friends via Skype in a pandemic. Why would she care about becoming a better computer user?
Yes, your type of grandma exists, but I don't know her.
Kernel is one of the best parts about Linux on desktop. It works. I've recently tried Windows, annoyed by hibernate, few seconds to wake up but sleep is instantaneous.
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 don't miss that. But it was better than the alternative at the time...
"Ok, there are at least three versions of the Linksco WG8211, all with different wireless chipsets. The box is identical except for the UPC sub-label - you want the one ending in -02. Some of the -01 boxes might work, but no guarantees, and the -03 definitely doesn't have support yet. You can't tell by the PCI ID, but if you poke this particular register, you can get the sub-version, which should tell you which chipset they're using - if they haven't changed it again."
Wireless cards on Linux, back in the early days of 802.11, were brutal to get working properly, mostly due to lack of drivers. The NDISwrapper was gross and sometimes hard to configure, but it also meant you had a snowball's chance in hell of getting a random wireless adapter working on Linux.
AMD tried something similar and the Kernel maintainers rejected the patch. At least that's how I understood it. I think this is a HN post about it: https://news.ycombinator.com/item?id=13142285
