4 ms·

I don't understand. Having a stable api is also good for researchers / amateurs as well?

by mda 8y ago

bayindirh 8y ago
API and ABI stability look nice on paper, and really useful in some circumstances, however, it creates two problems, so Linus opposes it (and I take Linus' side). First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it. Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc. Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!
- ebg13 8y ago
  > First of all, it allows hardware vendors to be lazy. This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.
  - bayindirh 8y ago
    Since the lines I want to quote are too long, I'll just snip the core parts. > ...no choice to replace because it's a chip embedded in your phone... My comment wasn't targeted at the embedded usage scenarios only. There are professional and consumer devices (hand-vein readers, printers from certain manufacturers, high end and high-speed scanners), which advertise Linux support on their boxes and documentation, but only provide binaries and modules for some archaic Linux distributions. This situation is hurting both sides of the equation. Some of these devices are very nice, expensive devices I'd (and many would) buy, but their non-existent Linux support keeps the users away from them. Their change in attitude will not probably change the stance in the long run due to trust issues. The problems are not only at kernel level either. Some of these devices run translation layer binaries in userspace, and these binaries are written without following the standard coding practices in Linux. As a result, an ordinary library update breaks the binary for good. Again, the manufacturer does nothing because it has no incentive to do so, and my expensive device becomes a paperweight. > Let the driver that works just fine keep working just fine! Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? Why Microsoft is constantly changing driver models ever so slightly, and every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.? > ...just because you decided to break something that was working just fine before you made your change. While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. Kernel changes shall not break or change userspace behavior. Hence, nothing is broken on purpose in the kernel. The evolution makes things change, and we shouldn't stop this change if we want Linux to be a cutting-edge operating system and platform.
    - ebg13 8y ago
      > My comment wasn't targeted at the embedded usage scenarios only. I know, but I think that the Linux kernel developers should update their views on the impact of ignoring the embedded scenario. > Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? No. Preserve the old methods so that things that used to work keep working. Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then. Windows 7 hardware drivers from 10 years ago still work in Windows 10 too. New functionality doesn't need to break old functionality. > Why Microsoft is constantly changing driver models ever so slightly They mostly don't. See above. > every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.? Bug fixes. Almost never interface changes. > While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. You just said userspace. What is userspace? If I can't update my kernel because it means that my camera will stop working because I only have the one binary blob for it, then the kernel has broken _my_ userspace. But that scenario is explicitly ignored because the userspace rule doesn't apply to drivers. The Linux kernel pushes GPL virality further than it should go by effectively mandating that one of three things must happen: 1) you give them your driver code or 2) you keep doing work to re-certify and re-release your driver (but you could just mainline your driver code, hint hint!) or 3) billions of people go fuck themselves Mobile device vendors choose 3 because it makes them more money by obsoleting the devices more quickly. It's time to recognize that fact.

I don't understand. Having a stable api is also good for researchers / amateurs as well?

by mda 8y ago

I don't understand. Having a stable api is also good for researchers / amateurs as well?

API and ABI stability look nice on paper, and really useful in some circumstances, however, it creates two problems, so Linus opposes it (and I take Linus' side). First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it. Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc. Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!

ebg13 8y ago
> First of all, it allows hardware vendors to be lazy. This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.
- bayindirh 8y ago
  Since the lines I want to quote are too long, I'll just snip the core parts. > ...no choice to replace because it's a chip embedded in your phone... My comment wasn't targeted at the embedded usage scenarios only. There are professional and consumer devices (hand-vein readers, printers from certain manufacturers, high end and high-speed scanners), which advertise Linux support on their boxes and documentation, but only provide binaries and modules for some archaic Linux distributions. This situation is hurting both sides of the equation. Some of these devices are very nice, expensive devices I'd (and many would) buy, but their non-existent Linux support keeps the users away from them. Their change in attitude will not probably change the stance in the long run due to trust issues. The problems are not only at kernel level either. Some of these devices run translation layer binaries in userspace, and these binaries are written without following the standard coding practices in Linux. As a result, an ordinary library update breaks the binary for good. Again, the manufacturer does nothing because it has no incentive to do so, and my expensive device becomes a paperweight. > Let the driver that works just fine keep working just fine! Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? Why Microsoft is constantly changing driver models ever so slightly, and every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.? > ...just because you decided to break something that was working just fine before you made your change. While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. Kernel changes shall not break or change userspace behavior. Hence, nothing is broken on purpose in the kernel. The evolution makes things change, and we shouldn't stop this change if we want Linux to be a cutting-edge operating system and platform.
  - ebg13 8y ago
    > My comment wasn't targeted at the embedded usage scenarios only. I know, but I think that the Linux kernel developers should update their views on the impact of ignoring the embedded scenario. > Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? No. Preserve the old methods so that things that used to work keep working. Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then. Windows 7 hardware drivers from 10 years ago still work in Windows 10 too. New functionality doesn't need to break old functionality. > Why Microsoft is constantly changing driver models ever so slightly They mostly don't. See above. > every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.? Bug fixes. Almost never interface changes. > While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. You just said userspace. What is userspace? If I can't update my kernel because it means that my camera will stop working because I only have the one binary blob for it, then the kernel has broken _my_ userspace. But that scenario is explicitly ignored because the userspace rule doesn't apply to drivers. The Linux kernel pushes GPL virality further than it should go by effectively mandating that one of three things must happen: 1) you give them your driver code or 2) you keep doing work to re-certify and re-release your driver (but you could just mainline your driver code, hint hint!) or 3) billions of people go fuck themselves Mobile device vendors choose 3 because it makes them more money by obsoleting the devices more quickly. It's time to recognize that fact.