5 ms·

Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is

by Jyaif 7y ago

Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.

deleted 7y ago
[deleted]
matheusmoreira 7y ago
ABI compatibility is also important. For example, the Linux kernel takes it very seriously but Linux user space generally doesn't. One of the reasons why application developers like to package dependencies together with the program in containers.
- wcoenen 7y ago
  > ABI compatibility is also important. For example, the Linux kernel takes it very seriously The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break. https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst https://github.com/torvalds/linux/blob/master/Documentation/...
  - hs86 7y ago
    I am not sure if this is good or bad. On the one hand it gives hardware vendors an incentive to contribute their drivers directly into their kernel but on the other hand most Android phones are now restricted to one old kernel version due to the lack of ongoing support from SoC vendors. I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained. Did this policy cause more harm than good?
    - matheusmoreira 7y ago
      > I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained. No, it's because the hardware manufacturers won't upstream their drivers. All they have to do is send the code licensed under GPLv2 and it will be updated and maintained. Stable ABI for drivers will result in the Windows situation: hardware vendors will just release one driver for one Windows version and one processor architecture. They don't seem to care very much so why should people optimize for their comfort? The least they could do is release free software so that the people who do care can make it work well. My laptop has a backlit keyboard with RGB LEDs. The only driver for it is a single proprietary Windows driver coupled with a buggy and slow application. I doubt these things will ever be updated. I actually emailed the manufacturer about this. I asked for technical information in order to make it work on Linux. They didn't or couldn't help me. So I reverse engineered the keyboard, made a Linux program to control the LEDs and the result was much better than the software they wrote for Windows. At least it doesn't take a full minute to start up. There is no point in making these companies comfortable. People should do the opposite: it should be as expensive as humanly possible to not release the drivers as free software. If they insist on maintaining proprietary drivers out of tree, then they should absolutely pay the maintenance cost. Kernel hackers shouldn't have to spend one second thinking about how a change will impact some crappy proprietary driver that's not even in the kernel tree.
      - hs86 7y ago
        What if they are ok with this? What if the device vendors use this lack of stable ABI to put an expiration date on their products? Android phones don't get more than 3 years of support and my fear/tinfoil theory is that the vendors abuse the good intention of the kernel devs to deprecate old devices faster.
        matheusmoreira 7y ago
        Manufacturers already do this, stable ABI or not. They can release drivers for a specific operating system and processor architecture. When those change and the driver breaks, they aren't going to spend time and money updating the driver for an old product they aren't even selling anymore. They'll just tell people to buy their new product instead.
  - matheusmoreira 7y ago
    True. I had the system call interface in mind when I made the post. I should've been more clear.
greggman2 7y ago
Many APIs are poorly designed and by design easy to use in insecure and inefficient ways. APIs also can't anticipate the future. APIs need to have a way to be deprecated and eventually discontinued.
- Crinus 7y ago
  ...and cause applications using them to stop working.
  - AnIdiotOnTheNet 7y ago
    What's more important here? Nebulous security threats or software that actually works?
    - Crinus 7y ago
      Software that actually works of course, but that only happens with stable APIs, ABIs and certainly not with removing them no matter how planned and preannounced that might be (both because most will ignore things since what they do already works and doing something different just to get the same results is most of the time a waste of time but also because in many cases the software is simply not possible to upgrade/change due to other issues, including the developer not existing anymore).
    - ThrowawayR2 7y ago
      > "What's more important here? Nebulous security threats or software that actually works?" Sounds like something would've Intel said internally before Meltdown / Spectre were discovered.
      - AnIdiotOnTheNet 7y ago
        And they were right, because despite all the cries of the sky falling from the security twonks of the world, it really hasn't been that big a deal.
sambeau 7y ago
Even stable APIs may need security fixes. I'm not convinced a world where APIs continue forever and their exploits do too would be much better than what we have. And I say that as someone who has just accidentally lost an expensive, fully-working piece of audio hardware to an ill-advised software upgrade.
- arghwhat 7y ago
  I'm fairly confident that the vast majority of functionality broken by updates have not in any way been related to security mitigations.
  - sambeau 7y ago
    That wasn't the point I was trying to make. I was trying to point out that ideally you could just leave the old API there for old software to use and build a new API for new software to use. If it wasn't for security bugs you could leave the old API untouched. Sadly, security issues prevent this and after a while it becomes uneconomical to supply even security fixes. This is why hardware that relies on software has an operational life shorter than the hardware itself has.
    - arghwhat 7y ago
      And that is exactly my point: API changes are rarely—if ever—caused by security fixes, and thus are not the cause of breakage, despite you attributing the impossibility of stable APIs to it. A fixed piece of software can have a limited lifetime for only two reasons: Dependence on ephemeral infrastructure (e.g. cloud services that disappear or change), and assumptions that fail over time (e.g. "the device will never be used after 2020" + hardcoded calendar). Only the first can be caused by API changes, and the API changes are usually always caused by voluntary product rewrite and infrastructure deprecation, not by security issues. In other words, the problems spawn from entirely voluntary and technically unnecessary actions, and you cannot claim that is caused by some unavoidable law of nature, such proliferation of security issues.
      - 7y ago
drawkbox 7y ago
It isn't just stable APIs but part of that is consistency of signatures, methods and usage. APIs used to be cleaner and more atomic, today they seem like very leaky abstractions and breaking changes seem to be all the rage. Previously, breaking changes were seen as a serious thing as it meant the API signatures/functionality was missing and needed to be broken. Today, breaking changes is just part of the "move fast and break things" fad that developers don't even try to make a stable/consistent API anymore. Lots of the problems are that development/engineering is no longer in the hands of developers/engineering/product people or designers, it is pushed by project managers and bizdev/MBAs/marketing/finance which is backwards. Good products should be built, with lots of thought into long living APIs and limited breaking changes and maintenance, that is then marketed and sold because it is value, instead we get the exact opposite. Rarely does software today ever get to a stable phase before the platform is version two'd, and there is no time added for software quality or solid products, features and underlying systems are in constant harvest and replanting. Stable consistent APIs don't help lock-in and they don't sell books, conferences, or allow large companies more control. For larger companies to keep control they need to break standards, and regularly break their own platforms to keep people updating and invested, it sucks and is why software is so bad today.
- Crinus 7y ago
  > Stable consistent APIs don't help lock-in I do not think this is true, Windows has a lock-in on desktop explicitly because it has a stable API that allowed it to amass a huge library of software that keeps people relying on it to get that software working. For the largest majority of people, Windows' worth is its stable API (even if they do not realize it).
  - drawkbox 7y ago
    True but in terms of development platforms for Microsoft, it is constant churn. When they have a monopoly or near monopoly like Microsoft does with the desktop and Windows, less need for churn to keep people on it but lack of competitors. Azure has gone through lots of churn because of heavy competition. Maybe competition, which is good, causes all this breaking software changes but change is good as well. Software change should just be a little more stable and developer/engineer/product/designer led not just the money/marketing/oversight pushed. Unfortunately standards get wrecked when platforms are going for lock-in and control, Microsoft/Google etc are all to blame for that. It isn't the engineers pushing for that mostly. Standards at least promote some level of stable APIs, but they don't lock-in and so big fish and sharks eat them up and break them.

by Jyaif 7y ago

deleted 7y ago

[deleted]

matheusmoreira 7y ago

ABI compatibility is also important. For example, the Linux kernel takes it very seriously but Linux user space generally doesn't. One of the reasons why application developers like to package dependencies together with the program in containers.

wcoenen 7y ago
> ABI compatibility is also important. For example, the Linux kernel takes it very seriously The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break. https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst https://github.com/torvalds/linux/blob/master/Documentation/...
- hs86 7y ago
  I am not sure if this is good or bad. On the one hand it gives hardware vendors an incentive to contribute their drivers directly into their kernel but on the other hand most Android phones are now restricted to one old kernel version due to the lack of ongoing support from SoC vendors. I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained. Did this policy cause more harm than good?
  - matheusmoreira 7y ago
    > I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained. No, it's because the hardware manufacturers won't upstream their drivers. All they have to do is send the code licensed under GPLv2 and it will be updated and maintained. Stable ABI for drivers will result in the Windows situation: hardware vendors will just release one driver for one Windows version and one processor architecture. They don't seem to care very much so why should people optimize for their comfort? The least they could do is release free software so that the people who do care can make it work well. My laptop has a backlit keyboard with RGB LEDs. The only driver for it is a single proprietary Windows driver coupled with a buggy and slow application. I doubt these things will ever be updated. I actually emailed the manufacturer about this. I asked for technical information in order to make it work on Linux. They didn't or couldn't help me. So I reverse engineered the keyboard, made a Linux program to control the LEDs and the result was much better than the software they wrote for Windows. At least it doesn't take a full minute to start up. There is no point in making these companies comfortable. People should do the opposite: it should be as expensive as humanly possible to not release the drivers as free software. If they insist on maintaining proprietary drivers out of tree, then they should absolutely pay the maintenance cost. Kernel hackers shouldn't have to spend one second thinking about how a change will impact some crappy proprietary driver that's not even in the kernel tree.
    - hs86 7y ago
      What if they are ok with this? What if the device vendors use this lack of stable ABI to put an expiration date on their products? Android phones don't get more than 3 years of support and my fear/tinfoil theory is that the vendors abuse the good intention of the kernel devs to deprecate old devices faster.
      - matheusmoreira 7y ago
        Manufacturers already do this, stable ABI or not. They can release drivers for a specific operating system and processor architecture. When those change and the driver breaks, they aren't going to spend time and money updating the driver for an old product they aren't even selling anymore. They'll just tell people to buy their new product instead.
- matheusmoreira 7y ago
  True. I had the system call interface in mind when I made the post. I should've been more clear.

greggman2 7y ago

Many APIs are poorly designed and by design easy to use in insecure and inefficient ways. APIs also can't anticipate the future. APIs need to have a way to be deprecated and eventually discontinued.

Crinus 7y ago
...and cause applications using them to stop working.
- AnIdiotOnTheNet 7y ago
  What's more important here? Nebulous security threats or software that actually works?
  - Crinus 7y ago
    Software that actually works of course, but that only happens with stable APIs, ABIs and certainly not with removing them no matter how planned and preannounced that might be (both because most will ignore things since what they do already works and doing something different just to get the same results is most of the time a waste of time but also because in many cases the software is simply not possible to upgrade/change due to other issues, including the developer not existing anymore).
  - ThrowawayR2 7y ago
    > "What's more important here? Nebulous security threats or software that actually works?" Sounds like something would've Intel said internally before Meltdown / Spectre were discovered.
    - AnIdiotOnTheNet 7y ago
      And they were right, because despite all the cries of the sky falling from the security twonks of the world, it really hasn't been that big a deal.

sambeau 7y ago

Even stable APIs may need security fixes. I'm not convinced a world where APIs continue forever and their exploits do too would be much better than what we have. And I say that as someone who has just accidentally lost an expensive, fully-working piece of audio hardware to an ill-advised software upgrade.

arghwhat 7y ago
I'm fairly confident that the vast majority of functionality broken by updates have not in any way been related to security mitigations.
- sambeau 7y ago
  That wasn't the point I was trying to make. I was trying to point out that ideally you could just leave the old API there for old software to use and build a new API for new software to use. If it wasn't for security bugs you could leave the old API untouched. Sadly, security issues prevent this and after a while it becomes uneconomical to supply even security fixes. This is why hardware that relies on software has an operational life shorter than the hardware itself has.
  - arghwhat 7y ago
    And that is exactly my point: API changes are rarely—if ever—caused by security fixes, and thus are not the cause of breakage, despite you attributing the impossibility of stable APIs to it. A fixed piece of software can have a limited lifetime for only two reasons: Dependence on ephemeral infrastructure (e.g. cloud services that disappear or change), and assumptions that fail over time (e.g. "the device will never be used after 2020" + hardcoded calendar). Only the first can be caused by API changes, and the API changes are usually always caused by voluntary product rewrite and infrastructure deprecation, not by security issues. In other words, the problems spawn from entirely voluntary and technically unnecessary actions, and you cannot claim that is caused by some unavoidable law of nature, such proliferation of security issues.
    - 7y ago

drawkbox 7y ago

It isn't just stable APIs but part of that is consistency of signatures, methods and usage. APIs used to be cleaner and more atomic, today they seem like very leaky abstractions and breaking changes seem to be all the rage. Previously, breaking changes were seen as a serious thing as it meant the API signatures/functionality was missing and needed to be broken. Today, breaking changes is just part of the "move fast and break things" fad that developers don't even try to make a stable/consistent API anymore. Lots of the problems are that development/engineering is no longer in the hands of developers/engineering/product people or designers, it is pushed by project managers and bizdev/MBAs/marketing/finance which is backwards. Good products should be built, with lots of thought into long living APIs and limited breaking changes and maintenance, that is then marketed and sold because it is value, instead we get the exact opposite. Rarely does software today ever get to a stable phase before the platform is version two'd, and there is no time added for software quality or solid products, features and underlying systems are in constant harvest and replanting. Stable consistent APIs don't help lock-in and they don't sell books, conferences, or allow large companies more control. For larger companies to keep control they need to break standards, and regularly break their own platforms to keep people updating and invested, it sucks and is why software is so bad today.

Crinus 7y ago
> Stable consistent APIs don't help lock-in I do not think this is true, Windows has a lock-in on desktop explicitly because it has a stable API that allowed it to amass a huge library of software that keeps people relying on it to get that software working. For the largest majority of people, Windows' worth is its stable API (even if they do not realize it).
- drawkbox 7y ago
  True but in terms of development platforms for Microsoft, it is constant churn. When they have a monopoly or near monopoly like Microsoft does with the desktop and Windows, less need for churn to keep people on it but lack of competitors. Azure has gone through lots of churn because of heavy competition. Maybe competition, which is good, causes all this breaking software changes but change is good as well. Software change should just be a little more stable and developer/engineer/product/designer led not just the money/marketing/oversight pushed. Unfortunately standards get wrecked when platforms are going for lock-in and control, Microsoft/Google etc are all to blame for that. It isn't the engineers pushing for that mostly. Standards at least promote some level of stable APIs, but they don't lock-in and so big fish and sharks eat them up and break them.