6 ms·

> you do not break interface for downstream users, no matter how wrongly you may think they are using the interface How does Linux manage to never break its AP

> you do not break interface for downstream users, no matter how wrongly you may think they are using the interface How does Linux manage to never break its API? For example in the event of a refactoring.

emodendroket 9y ago
I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.
- chrisseaton 9y ago
  How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?
  - grigjd3 9y ago
    You trivialize the broken usage.
    - deleted 9y ago
      [deleted]
  - magnetic 9y ago
    The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract. You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.
    - emodendroket 9y ago
      Well, sometimes, but the Windows philosophy is probably to introduce a shim so that an app relying on the broken functionality still works.
      - magnetic 9y ago
        If you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though. It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.
        emodendroket 9y ago
        Sure, it's not a strategy without costs and Microsoft goes to an extreme. But there's probably a middle way in there; if you're aware that tons of programs now depend on the buggy behavior you probably want to deal with it. But if you're working on Windows or the Linux kernel the tolerance for breaks is probably much lower.
    - curveship 9y ago
      That's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.
      - oinkush 9y ago
        That sounds insane. Is it written somewhere besides a sporadic Linus rant? (e.g. somewhere here https://www.kernel.org/doc/html/latest/ https://www.kernel.org/doc/html/latest/ etc.)
      - caf 9y ago
        In other words, the ABI you have is the ABI that got used, not the ABI you thought you were building.
  - ori_b 9y ago
    Introduce a new API.
  - digi_owl 9y ago
    That is a situation they work towards never happening, by never leaving a behavior change in the wild long enough for such a situation to develop. If you look closely at the kernel code it is easy to find two or more syscalls that have names and behaviors that are very similar, but where one is recommended above all the others.This is because the older syscall(s) were found to be flawed. But rather than break existing software, they introduce a new syscall that fixes said flaws and leave the old one intact and recommend that in the future software use the new syscall.
martiuk 9y ago
Certain parts of the API once able to respond with a value now just spit out '0', it means that whatever application that used it just continue to work even though that part is deprecated.

emodendroket 9y ago

I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.

chrisseaton 9y ago
How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?
- grigjd3 9y ago
  You trivialize the broken usage.
  - deleted 9y ago
    [deleted]
- magnetic 9y ago
  The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract. You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.
  - emodendroket 9y ago
    Well, sometimes, but the Windows philosophy is probably to introduce a shim so that an app relying on the broken functionality still works.
    - magnetic 9y ago
      If you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though. It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.
      - emodendroket 9y ago
        Sure, it's not a strategy without costs and Microsoft goes to an extreme. But there's probably a middle way in there; if you're aware that tons of programs now depend on the buggy behavior you probably want to deal with it. But if you're working on Windows or the Linux kernel the tolerance for breaks is probably much lower.
  - curveship 9y ago
    That's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.
    - oinkush 9y ago
      That sounds insane. Is it written somewhere besides a sporadic Linus rant? (e.g. somewhere here https://www.kernel.org/doc/html/latest/ https://www.kernel.org/doc/html/latest/ etc.)
    - caf 9y ago
      In other words, the ABI you have is the ABI that got used, not the ABI you thought you were building.
- ori_b 9y ago
  Introduce a new API.
- digi_owl 9y ago
  That is a situation they work towards never happening, by never leaving a behavior change in the wild long enough for such a situation to develop. If you look closely at the kernel code it is easy to find two or more syscalls that have names and behaviors that are very similar, but where one is recommended above all the others.This is because the older syscall(s) were found to be flawed. But rather than break existing software, they introduce a new syscall that fixes said flaws and leave the old one intact and recommend that in the future software use the new syscall.

martiuk 9y ago

Certain parts of the API once able to respond with a value now just spit out '0', it means that whatever application that used it just continue to work even though that part is deprecated.