6 ms·

I believe one of the reasons Linux continues to be successful today is _because_ they keep the drivers in mainline _without_ a stable API. It is a key motivato

I believe one of the reasons Linux continues to be successful today is _because_ they keep the drivers in mainline _without_ a stable API. It is a key motivator to ensure drivers remain available and supported well into the future of Linux.

pjmlp 8y ago
Which given the way legacy AMD drivers story has been handled on Ubuntu, it is quite far from actually being so. My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Linux is successful because it is a free beer UNIX clone.
- core-questions 8y ago
  Womp womp. Most of those netbooks are unusably slow anyhow, and were when they were brand new too. Run an older kernel on there and call it a day.
  - pjmlp 8y ago
    Sorry but a DirectX 11 class dual core APU is good enough for general purpose gaming. And runnig legacy kernels? No thanks.
    - monocasa 8y ago
      Which GPU is it specifically?
      - pjmlp 8y ago
        AMD Fusion Brazos APU, Radeon HD 6250
        monocasa 8y ago
        Certainly looks supported by /dev/radeon, just not /dev/amdgpu.
        pjmlp 8y ago
        I didn't said it wasn't supported, I said: > My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos. And then there is this, "For one, AMD users can’t use applications that require OpenGL 4.3 or later without the fglrx/Catalyst drivers." https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalyst-fglrx-driver-16-04 https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalys...
        monocasa 8y ago
        OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support. I really fail to see how that has anything to do with Linux's unstable kernel driver API.
        pjmlp 8y ago
        Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.
        monocasa 8y ago
        ... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?
        pjmlp 8y ago
- monocasa 8y ago
  You still have the source to the old drivers. It's just not a priority for others to support anymore, but you have the means to go add that support yourself, or pay a third party to do it for you. Contrast with when windows changed the video driver architecture in Vista, and the only option you had was to pound sand.
  - pjmlp 8y ago
    I skipped Vista, however my XP drivers were fully supported on the upgrade to 7.
    - iforgotpassword 8y ago
      Some xp drivers work on 7, most don't. Also unlike user space, you cannot run 32 bit drivers on 64 bit windows, so unless you were running 32 bit win7 you needed 64 bit xp drivers, which were rare. Are you sure you explicitly installed xp drivers and didn't just happen to have hardware where windows shipped matching drivers or could download them from the windows driver database? (Or downloaded an installer bundle from the manufacturer's website that just contained drivers for all supported platforms..)
  - bunderbunder 8y ago
    Seems like a pretty easy cost/benefit analysis to me: I can either spend thousands of dollars worth of my time on updating the driver, or I can pay someone else thousands of dollars to do it. Or I can spend a fraction of that on a new video card. Seems like the only solution for Vista users is the only solution I'd ever have gone with, anyway.
    - monocasa 8y ago
      Sure the cost/benefit works out the same for you (which is why no one has done the work), but that's different from the full set of options available to you in both cases.
      - bunderbunder 8y ago
nasoieu 8y ago
Linux on the desktop would have succeeded with a stable driver API. Having hardware with closed source drivers supported could have being a walk in the park for OEMs. Bad 3D, wireless, etc. support is what killed Linux. OEMs would have probably made more and better drivers if they didn't have to make changes to them every few months or go through the effort of releasing and mainlining the source.
- btilly 8y ago
  This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits. Any operating system that wishes stability therefore has to put barriers between themselves and the driver. And, preferably, should use drivers that they can audit themselves rather than trusting OEMs. As an example of this outside of the open source world, the biggest reason why Windows used to have a reputation for BSODs is that they were dependent on third party drivers. Windows made it harder for third parties to take down their OS, shipped tools to audit drivers for bugs, and forced OEMs to clean up their act. (Which they didn't do voluntarily.)
  - nasoieu 8y ago
    It's better to have buggy, incomplete drivers than no drivers at all.
    - iforgotpassword 8y ago
      This is your opinion. I prefer using hardware with stable drivers, working reliably.
      - jonny_eh 8y ago
        That's why I use a Mac. Seems like a good solution is to have the OS and HW manufacturer to be one and the same.
agumonkey 8y ago
So we should have two numbers, actual kernel, whole tree. I am quite convinced that if they kept it that way it was because some unplanned property caused worse driver status with an API; too many delays, improper usage I don't know. If there's no solid reason, then I'd be happy to have split codebases.

pjmlp 8y ago

Which given the way legacy AMD drivers story has been handled on Ubuntu, it is quite far from actually being so. My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Linux is successful because it is a free beer UNIX clone.

core-questions 8y ago
Womp womp. Most of those netbooks are unusably slow anyhow, and were when they were brand new too. Run an older kernel on there and call it a day.
- pjmlp 8y ago
  Sorry but a DirectX 11 class dual core APU is good enough for general purpose gaming. And runnig legacy kernels? No thanks.
  - monocasa 8y ago
    Which GPU is it specifically?
    - pjmlp 8y ago
      AMD Fusion Brazos APU, Radeon HD 6250
      - monocasa 8y ago
        Certainly looks supported by /dev/radeon, just not /dev/amdgpu.
        pjmlp 8y ago
        I didn't said it wasn't supported, I said: > My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos. And then there is this, "For one, AMD users can’t use applications that require OpenGL 4.3 or later without the fglrx/Catalyst drivers." https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalyst-fglrx-driver-16-04 https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalys...
        monocasa 8y ago
        OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support. I really fail to see how that has anything to do with Linux's unstable kernel driver API.
        pjmlp 8y ago
        Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.
        monocasa 8y ago
        ... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?
        pjmlp 8y ago
monocasa 8y ago
You still have the source to the old drivers. It's just not a priority for others to support anymore, but you have the means to go add that support yourself, or pay a third party to do it for you. Contrast with when windows changed the video driver architecture in Vista, and the only option you had was to pound sand.
- pjmlp 8y ago
  I skipped Vista, however my XP drivers were fully supported on the upgrade to 7.
  - iforgotpassword 8y ago
    Some xp drivers work on 7, most don't. Also unlike user space, you cannot run 32 bit drivers on 64 bit windows, so unless you were running 32 bit win7 you needed 64 bit xp drivers, which were rare. Are you sure you explicitly installed xp drivers and didn't just happen to have hardware where windows shipped matching drivers or could download them from the windows driver database? (Or downloaded an installer bundle from the manufacturer's website that just contained drivers for all supported platforms..)
- bunderbunder 8y ago
  Seems like a pretty easy cost/benefit analysis to me: I can either spend thousands of dollars worth of my time on updating the driver, or I can pay someone else thousands of dollars to do it. Or I can spend a fraction of that on a new video card. Seems like the only solution for Vista users is the only solution I'd ever have gone with, anyway.
  - monocasa 8y ago
    Sure the cost/benefit works out the same for you (which is why no one has done the work), but that's different from the full set of options available to you in both cases.
    - bunderbunder 8y ago

nasoieu 8y ago

Linux on the desktop would have succeeded with a stable driver API. Having hardware with closed source drivers supported could have being a walk in the park for OEMs. Bad 3D, wireless, etc. support is what killed Linux. OEMs would have probably made more and better drivers if they didn't have to make changes to them every few months or go through the effort of releasing and mainlining the source.

btilly 8y ago
This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits. Any operating system that wishes stability therefore has to put barriers between themselves and the driver. And, preferably, should use drivers that they can audit themselves rather than trusting OEMs. As an example of this outside of the open source world, the biggest reason why Windows used to have a reputation for BSODs is that they were dependent on third party drivers. Windows made it harder for third parties to take down their OS, shipped tools to audit drivers for bugs, and forced OEMs to clean up their act. (Which they didn't do voluntarily.)
- nasoieu 8y ago
  It's better to have buggy, incomplete drivers than no drivers at all.
  - iforgotpassword 8y ago
    This is your opinion. I prefer using hardware with stable drivers, working reliably.
    - jonny_eh 8y ago
      That's why I use a Mac. Seems like a good solution is to have the OS and HW manufacturer to be one and the same.

agumonkey 8y ago

So we should have two numbers, actual kernel, whole tree. I am quite convinced that if they kept it that way it was because some unplanned property caused worse driver status with an API; too many delays, improper usage I don't know. If there's no solid reason, then I'd be happy to have split codebases.