On most machines I tried, linux had every conceivable driver ready out of the box without any configuration.
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.
I've been slowly going through sound cards (Focusrite, MOTU, Rode) during the pandemic trying to find one that my work Windows laptop will detect. All of them have worked immediately plugged into Linux.
Interesting. I have had to compile drivers for every Linux install I've done in the past three years. Ubuntu, Xubuntu, elementaryOS, Pop!_OS, etc. Maybe we can all accept that people have different experiences?
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.
I didn’t say that the contrary can’t happen - but wildly inaccurate, bad-faith claims that the account made I replied to are not ok either. Linux did come a long long way, and often used hardware will indeed just work out of the box most of the time - I think it is absolutely fair to point that out because it was not this way always — there was a time when the majority of hardware needed some tinkering.
May I ask you what hardware did you install linux on?
I'm curious what drivers you've had to compile? The only ones I've ever had to compile were GPU drivers for very very recent cards. On my current laptop, the only thing that doesn't work is the fingerprint reader (which doesn't even have a driver, makes me sad) - everything else is built into all the distros I've tried (Ubuntu, Fedora, NixOS). I am pretty curious in what places is the driver story behind?
Drivers for virtualized hardware is one big one. Parallels tools have to be recompiled for pretty much every new kernel version because Linux refuses to stabilize the kernel API. Often I have to edit the drivers by hand (example: replacing "sem" to "lock" for kernel 5.8 because apparently driver compatibility isn't as important as catering to kernel devs who don't know what a semaphore is?).
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.
> Parallels tools have to be recompiled for pretty much every new kernel version because Linux refuses to stabilize the kernel API.
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?
Not OP, but I do want to note, there is a difference compared to windows: Windows has a stable driver interface, which makes it at least possible to have drivers that are basically guaranteed to be future-proof. Linux has no such stable ABI, and frequently does breaking changes.
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 think that's a fair comparison.... 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.
I don't understand. Do you think I'm lying or something? Because I'm not, and neither are these folks:
> 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.
I think I'd be happy with a stable API, it wouldn't have to be a stable binary interface. Wanna change the internals of a struct? Totally fine. Not make binary shims for 32-bit drivers? Totally fine.
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.