3 ms·

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

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.

kaba0 5y ago
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?
roblabla 5y ago
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?
- torstenvl 5y ago
  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.
  - roblabla 5y ago
    Thanks for the answer, that's really informative! > 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.
    - torstenvl 5y ago
      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.
  - viraptor 5y ago
    > 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/ 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?

kaba0 5y ago

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?

roblabla 5y ago

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?

torstenvl 5y ago
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.
- roblabla 5y ago
  Thanks for the answer, that's really informative! > 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.
  - torstenvl 5y ago
    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.
- viraptor 5y ago
  > 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/ 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?