7 ms·

The last statement reminds me of Linus saying we do not break user space If an application is utilizing a bug, it is not a bug but a feature

by vbcr 11y ago

MBCook 11y ago
Yeah I was kind of wondering what his take on something like this would be. On the one hand you're changing an API, which is a promise to userspace. On the other hand, no one was using it right leading to most networking apps being vulnerable to a DOS. Given the proven risk and how little the feature is used, changing the API to match what people THINK it does seems sane. I have a vague memory or Linus making a similar 'change it' decision once.
- UnoriginalGuy 11y ago
  Also according to this article it was either undocumented or extremely poorly documented depending on which doc's you look at. So maybe they're removing a feature a lot of developers either didn't know about or didn't know they COULD utilise.
- aidenn0 11y ago
  If no examples could be found of someone relying on the behavior, then a change would be okay. Otherwise the solution would be to implement a modified API. Alternatively glibc could change it, as glibc almost seems to want to break existing programs.
mkj 11y ago
Apple's general approach is "if it isn't documented, we can break it", a bit different to Linux.
- Aloha 11y ago
  I actually think it's much the same, judging from the quote from linus in the parent.
- joakleaf 11y ago
  I think, Apple's general approach is:"We can break it." Documented or not. Seems like they change stuff all the time. Especially on iOS.
  - WA 11y ago
    I agree. I think there was never a major iOS release that didn't break things in my app. Really basic stuff like a text input for example.
  - valleyer 11y ago
    Can you provide examples of non deprecated API that Apple broke?
    - interpol_p 11y ago
      The recent Swift 1.2 release brought a whole load of code breaking changes. None of Swift 1.0 was explicitly deprecated.
      - Sephiroth87 11y ago
        That's a bit different, they explicitly said Swift is a work in progress and code compatibility is not guaranteed between versions...
        Zikes 11y ago
        After 1.0 API changes really should increment the major version.
        ebbv 11y ago
        Unless you say "We're probably going to break things." when you announce it, which they did.
        cozzyd 11y ago
nardi 11y ago
I think this attitude is perfect for Linux, where many developers will not expend effort to maintain their software. On the other hand, developers for OS X and iOS are often willing to expend enormous amounts of effort to keep their apps working.
- koski 11y ago
  Interesting but raising my eyebrowns a bit because sounds a bit too black and white. Do you have time to explain more or do you have some data to back up such a claim?
raverbashing 11y ago
There was an issue when people were using memcpy with overlapping addresses (ahem Flash), but I guess that was on stdlibc https://bugzilla.redhat.com/show_bug.cgi?id=638477 https://bugzilla.redhat.com/show_bug.cgi?id=638477

The last statement reminds me of Linus saying we do not break user space If an application is utilizing a bug, it is not a bug but a feature

by vbcr 11y ago

The last statement reminds me of Linus saying we do not break user space If an application is utilizing a bug, it is not a bug but a feature

MBCook 11y ago

Yeah I was kind of wondering what his take on something like this would be. On the one hand you're changing an API, which is a promise to userspace. On the other hand, no one was using it right leading to most networking apps being vulnerable to a DOS. Given the proven risk and how little the feature is used, changing the API to match what people THINK it does seems sane. I have a vague memory or Linus making a similar 'change it' decision once.

UnoriginalGuy 11y ago
Also according to this article it was either undocumented or extremely poorly documented depending on which doc's you look at. So maybe they're removing a feature a lot of developers either didn't know about or didn't know they COULD utilise.
aidenn0 11y ago
If no examples could be found of someone relying on the behavior, then a change would be okay. Otherwise the solution would be to implement a modified API. Alternatively glibc could change it, as glibc almost seems to want to break existing programs.

mkj 11y ago

Apple's general approach is "if it isn't documented, we can break it", a bit different to Linux.

Aloha 11y ago
I actually think it's much the same, judging from the quote from linus in the parent.
joakleaf 11y ago
I think, Apple's general approach is:"We can break it." Documented or not. Seems like they change stuff all the time. Especially on iOS.
- WA 11y ago
  I agree. I think there was never a major iOS release that didn't break things in my app. Really basic stuff like a text input for example.
- valleyer 11y ago
  Can you provide examples of non deprecated API that Apple broke?
  - interpol_p 11y ago
    The recent Swift 1.2 release brought a whole load of code breaking changes. None of Swift 1.0 was explicitly deprecated.
    - Sephiroth87 11y ago
      That's a bit different, they explicitly said Swift is a work in progress and code compatibility is not guaranteed between versions...
      - Zikes 11y ago
        After 1.0 API changes really should increment the major version.
        ebbv 11y ago
        Unless you say "We're probably going to break things." when you announce it, which they did.
        cozzyd 11y ago

nardi 11y ago

I think this attitude is perfect for Linux, where many developers will not expend effort to maintain their software. On the other hand, developers for OS X and iOS are often willing to expend enormous amounts of effort to keep their apps working.

koski 11y ago
Interesting but raising my eyebrowns a bit because sounds a bit too black and white. Do you have time to explain more or do you have some data to back up such a claim?

raverbashing 11y ago

There was an issue when people were using memcpy with overlapping addresses (ahem Flash), but I guess that was on stdlibc https://bugzilla.redhat.com/show_bug.cgi?id=638477 https://bugzilla.redhat.com/show_bug.cgi?id=638477