And of course, you're under no obligation to listen to any of us whine, but if, on the off chance, you happen to want more people to like Linux, it seems like taking people's experiences seriously would be a good starting point.
May I ask you what hardware did you install linux on?
In case you don't think virtualization is a valid use case, this should hold true for any drivers distributed outside the kernel. It's also true for newer hardware - WiFi 6 has been a thing lately. And over the past couple years as laptops try to compete with Apple there have in fact been sound issues, though that one hasn't bit me personally.
Again, I want to stress that I'm not imputing some moral obligation for things to be different. But it is definitely a rough edge, it absolutely requires people to futz with compiling drivers, and it's something that makes some number of technical people say "screw it, this is too much of a pain in the neck."
In my opinion, investing in a proper driver architecture with a stable interface would be a massive step toward better Linux hardware support and broader adoption.
I don't think that's a fair comparison. Parallels comes with dkms module and while the process of installing involves compiling under the covers, it's just part of installation. It's not the late 90s "compile that driver yourself completely manually" situation.
If Parallels doesn't work with new kernel, that's their compatibility issue, but being able to fix the driver yourself just gives you more options. Linux -> you can fix the driver. MacOS -> you can on new macos, with annoying extra signing and other steps. (if the source for macos is even published - for parallels that's a no) Windows -> basically wait until the vendor produces an upgrade.
Parallels says for macos 12: "Productivity and integration features are not available to this VM yet." Even if you wanted to fix it manually - you can't. (https://kb.parallels.com/au/125561/)
Basically, you get the extra option to upgrade faster than your vendor is ready on Linux - if you use that path, why show it as "I had to do manual work to make things work", rather than something positive?
Both approaches have their upsides, but I've very rarely had drivers stop working between various windows release. Of course, there are exceptions to the rule here - Yes, I also have had some drivers stop working since Windows XP. But those are rare, and getting rarer as time goes on and MS locks the kernel up, preventing drivers from doing stupid things.
On Linux, the problem only exists for out-of-tree drivers, but those will break fairly frequently for all but the simplest drivers.
As I said in my sibling comment, I don't know how I feel about a stable ABI - I do fear it would make the situation worse with more out-of-tree/proprietary drivers. But it is worth keeping in mind that it does have its upsides.
Of course, MacOS being what it is, it chose the "worst of all worlds" scenario: Proprietary drivers with no ABI stability guarantee. It's not really worth discussing as a point of comparison, MacOS has the worst driver story from the lot, only saved by its intended minimal target hw support.
I don't understand. Do you think I'm lying or something? Because I'm not, and neither are these folks:
https://www.google.com/search?q=compile+new+kernel+site%3Afo...
It's a giant pain in the neck and it's caused by pretty deliberate decisions about Linux architecture.
> In my opinion, investing in a proper driver architecture with a stable interface would be a massive step toward better Linux hardware support and broader adoption.
Eh, I have mixed feelings about this. Part of what makes Linux so great is that most of its drivers are open source - which allows the devices it supports to stay supported basically forever (though bitrot certainly is a thing). And they achieved this by making maintaining out-of-tree drivers so damn painful.
A stable interface would sort of undermine this. I honestly don't know if that'd be preferable to the status quo.
That would encourage open-source or at least source-available drivers (to allow recompiling for ABI changes), but recompilation should be straightforward and possibly automatic if the API doesn't change every couple months.
This is absolutely not something one can say about windows (though at least nowadays it will try to fetch drivers from God knows where and often succeed). And Mac supports like 2 hardware devices all together, both of them manufactured by them — comparing an OS that exclusively run on specific hardware is just stupid and not made in good faith.