3 ms·

Disagree but not because of philosophical reasons like “I want to fix my driver and know what it is doing”, but actually practical reasons — tons of companies m

by xt00 4y ago

Disagree but not because of philosophical reasons like “I want to fix my driver and know what it is doing”, but actually practical reasons — tons of companies make a driver plus hardware and end up semi abandoning it.. but some people in the community with open source drivers will often fix it.. then after some time people end up realizing the way they fixed it is better than the original driver and now the companies actually benefit from that new driver. So you end up with a win win for people and companies. So in general closed source drivers end up sucking compared to open source drivers except for very rare situations.. and even after massive battles with say nvidia they are starting to realize they will end up benefiting from working with the open source community rather than against them..

Nextgrid 4y ago
On the topic of open-source vs closed-source drivers: Maintaining an open-source kernel driver is extremely complex and not user-friendly for the individual, so the complexity level is in practice similar to doing black-box reverse-engineering on a closed-source Windows driver, in both cases you need significant resources. If you need to have a team of experienced kernel developers to maintain a driver continuously, that same team will be able to reverse-engineer & reimplement the closed-source driver just as well should it become necessary. On the topic of lack of stable ABI under Linux, I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents, so in practice I feel like the downside of drivers being closed-source in Windows is less of a problem because in practice you're less likely to have to modify it. Distributing drivers is also a massive difference between the two models. With Windows, if someone builds a driver, that binary can be installed by any Windows user on a modern kernel (depending on what "level" of the ABI they're building against, the same driver can work all the way back to Windows 7). Once built, any Windows user can just install the binary, where as with Linux the built binary will only work for that very specific kernel version. The user-experience is definitely much better.
- jraph 4y ago
  > On the topic of lack of stable ABI under Linux, I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents, so in practice I feel like the downside of drivers being closed-source in Windows is less of a problem because in practice you're less likely to have to modify it. I recently helped a friend with her Mac and her "old" Wacom tablet. She now has to download an old version of the drivers for the tablet to work, with some manual configuration to do related to security. It took us long to figure out, and actually she wasn't figuring it out on her own. Plus, how long will she be able to use her tablet on Mac, since the driver is not maintained anymore? I plugged the tablet on my Linux computer and it worked out of the box without doing anything. I trust this tablet will still work on Linux for a very long time. I trust the stability of the Windows ABI more than the Mac one, but on Windows you would still have to install some old unmaintained binary that could have security issues to make this tablet work. Do you have an actual example of an open source Linux driver that stops working when the closed Windows one still works? Are there many of these examples? How many against the opposite situation? > Distributing drivers is also a massive difference between the two models. With Windows, if someone builds a driver, that binary can be installed by any Windows user on a modern kernel (depending on what "level" of the ABI they're building against, the same driver can work all the way back to Windows 7). Once built, any Windows user can just install the binary, where as with Linux the built binary will only work for that very specific kernel version. The user-experience is definitely much better. What actually happens on Linux most of the time is that the driver comes with the kernel and the user does not need to install anything. This is unbeatable. > Maintaining an open-source kernel driver is extremely complex and not user-friendly for the individual, so the complexity level is in practice similar to doing black-box reverse-engineering on a closed-source Windows driver, in both cases you need significant resources. I'm very surprised. Fixing API breakage to make an open source work again seems way easier than reverse engineering the whole thing.
- worthless-trash 4y ago
  > I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents. Just to be clear, if you mean kernel drivers I find this -very- difficult to believe. There are linux kernel drivers I'd love to see die that will never die. If you're talking about 'downloads from some guys website', you may have a viable example but this is not the common case. Code lasts -way- too long. For example the ISA BUS is still supported, aint no win10 drivers for ISA soundcards.
squarefoot 4y ago
This a hundred times. Windows drivers are fine until the day the piece of iron they manage becomes obsolete, which often happens to still modern and perfectly functional hardware. It's not uncommon to see hardware that isn't supported anymore by Windows since years working perfectly under Linux. I should have ditched most of my audio cards ages ago if I didn't use them with Linux.

by xt00 4y ago

Nextgrid 4y ago

On the topic of open-source vs closed-source drivers: Maintaining an open-source kernel driver is extremely complex and not user-friendly for the individual, so the complexity level is in practice similar to doing black-box reverse-engineering on a closed-source Windows driver, in both cases you need significant resources. If you need to have a team of experienced kernel developers to maintain a driver continuously, that same team will be able to reverse-engineer & reimplement the closed-source driver just as well should it become necessary. On the topic of lack of stable ABI under Linux, I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents, so in practice I feel like the downside of drivers being closed-source in Windows is less of a problem because in practice you're less likely to have to modify it. Distributing drivers is also a massive difference between the two models. With Windows, if someone builds a driver, that binary can be installed by any Windows user on a modern kernel (depending on what "level" of the ABI they're building against, the same driver can work all the way back to Windows 7). Once built, any Windows user can just install the binary, where as with Linux the built binary will only work for that very specific kernel version. The user-experience is definitely much better.

jraph 4y ago
> On the topic of lack of stable ABI under Linux, I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents, so in practice I feel like the downside of drivers being closed-source in Windows is less of a problem because in practice you're less likely to have to modify it. I recently helped a friend with her Mac and her "old" Wacom tablet. She now has to download an old version of the drivers for the tablet to work, with some manual configuration to do related to security. It took us long to figure out, and actually she wasn't figuring it out on her own. Plus, how long will she be able to use her tablet on Mac, since the driver is not maintained anymore? I plugged the tablet on my Linux computer and it worked out of the box without doing anything. I trust this tablet will still work on Linux for a very long time. I trust the stability of the Windows ABI more than the Mac one, but on Windows you would still have to install some old unmaintained binary that could have security issues to make this tablet work. Do you have an actual example of an open source Linux driver that stops working when the closed Windows one still works? Are there many of these examples? How many against the opposite situation? > Distributing drivers is also a massive difference between the two models. With Windows, if someone builds a driver, that binary can be installed by any Windows user on a modern kernel (depending on what "level" of the ABI they're building against, the same driver can work all the way back to Windows 7). Once built, any Windows user can just install the binary, where as with Linux the built binary will only work for that very specific kernel version. The user-experience is definitely much better. What actually happens on Linux most of the time is that the driver comes with the kernel and the user does not need to install anything. This is unbeatable. > Maintaining an open-source kernel driver is extremely complex and not user-friendly for the individual, so the complexity level is in practice similar to doing black-box reverse-engineering on a closed-source Windows driver, in both cases you need significant resources. I'm very surprised. Fixing API breakage to make an open source work again seems way easier than reverse engineering the whole thing.
worthless-trash 4y ago
> I find that closed-source Windows drivers have a much longer shelf-life than their Linux equivalents. Just to be clear, if you mean kernel drivers I find this -very- difficult to believe. There are linux kernel drivers I'd love to see die that will never die. If you're talking about 'downloads from some guys website', you may have a viable example but this is not the common case. Code lasts -way- too long. For example the ISA BUS is still supported, aint no win10 drivers for ISA soundcards.

squarefoot 4y ago

This a hundred times. Windows drivers are fine until the day the piece of iron they manage becomes obsolete, which often happens to still modern and perfectly functional hardware. It's not uncommon to see hardware that isn't supported anymore by Windows since years working perfectly under Linux. I should have ditched most of my audio cards ages ago if I didn't use them with Linux.