4 ms·

Linus's followup post later on in the thread explains his position in more detail and is a pretty good read: http://lkml.iu.edu/hypermail/linux/kernel/1710.3/0

Linus's followup post later on in the thread explains his position in more detail and is a pretty good read: http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

piker 9y ago
Interesting. > Behavioral changes happen, and maybe we don't even support some feature any more. There's a number of fields in /proc/<pid>/stat that are printed out as zeroes, simply because they don't even exist in the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced by zeroes, so that the code that used to parse the fields still works. The user might not see everything they used to see, and so behavior is clearly different, but things still _work_, even if they might no longer show sensitive (or no longer relevant) information. I'm not sure I prefer the described result. If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse.
- chii 9y ago
  > If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse. if your app didn't used to handle the 'zero' case (assuming zero was a "valid" value for said field), then the app was poorly written and would'be been broken in the first place. However, if the app _did_ handle the 'zero' case, then the app continued to work! The end user would've been none-the-wiser about the change (mostly), and some time later, the app could be upgraded to ignore those known fields. Causing a parse error would mean the app stopped working altogether. Much worse a result for the end user.
  - piker 9y ago
    I guess that depends on whether or not zeros were valid in the first instance. My post assumed they were. I agree with your point if zero would be outside of the valid range in the first instance.
  - hyperpape 9y ago
    There are many cases where continuing with invalid data is much worse than a parse error. Perhaps that's less likely in this case (hopefully your credit card payment doesn't depend on the values in /proc/<pid>/stat), but as a rule, silently continuing with meaningless data is scary.
    - deleted 9y ago
      [deleted]
    - notheguyouthink 9y ago
      Yea that's what I was thinking. If the behavior changes, what "works" entirely depends on the context of that specific application. I can understand mitigating complete failures as much as possible, but trying to trick programs into thinking that they're running the same as they were before seems.. well, scary as hell. I'm honestly not sure what's worse - breaking the application, or making it think everything is fine.
    - spdionis 9y ago
      Not when the application was to supposed to handle the invalid data anyway before. Because you had to handle the zero case before right? The idea is that in the worst case you get an error message, not an altogether crash.
      - deleted 9y ago
        [deleted]
    - cmiles74 9y ago
      If your application relies on these sort of interfaces with the kernel, then presumably you're paying attention when you upgrade the kernel.
  - hasenj 9y ago
    It sounds like a chance for logical errors to go undetected before they cause issues somewhere totally unrelated.
  - catpolice 9y ago
    Zero could be a perfectly "valid" value and still break your application if changing the function to always return zero breaks an implicit contract. Suppose the previous behavior of the function returned something you could use as an ID for some internal representation in a database that you could look up and write to. Before, the ID you got back depended on the input, but now it doesn't. And you can't tell you're not getting real IDs back anymore, so you just happily write to the database. Now you're corrupting your database because the implicit behavioral contract you were relying on was broken - I'd MUCH rather the program just crash than for it to continue "working" in a way that irrecoverably corrupts data.
  - nialv7 9y ago
    > then the app was poorly written and would'be been broken in the first place. If you present this argument to Linus, you will certainly get yelled at. Not breaking the user space means not breaking the user space even when it's broken. A couple years back glibc broke Adobe Flash because Flash used memcpy wrong. Linus was quite vocal about it.
- caf 9y ago
  If your code had actually broken with the change to a zero (for example it didn't just report 0 of some resource in use in the log, but spawned an unlimited amount of threads until it crashed or something) then you could have reported it as a kernel regression, and it would have been fixed in another way.
  - jacobush 9y ago
    True but there is more to it. Linus’s ambition is to also not break the unknown app in the basement, behind the leopard.
- jsjohnst 9y ago
  Having had to fix a number of production issues where a change happened XX days ago but the code just silently kept going rather than breaking, I’m sorta of the mind to agree with you. I’d almost rather it break hard, so then I know it’s broke and can fix it. Very nuanced situation though and as such definitely not one size fits all.
  - 35bge57dtjku 9y ago
    Isn't that just 'fail fast' behavior vs. silent ata corruption?
  - __david__ 9y ago
    That's fine when it's code that you wrote, but it would be really annoying to me as a user if htop (for example) started crashing on a kernel upgrade (instead of one the columns suddenly being zero).
    - jsjohnst 9y ago
      Completely and totally agree! Why I said it was a nuanced situation and not one size fits all.
- emodendroket 9y ago
  Perhaps, but what if the app developer is long gone, and I am a user hoping to keep using my favorite program? Apparently the original Raymond Chen article is gone but I think this quote captures it: https://news.ycombinator.com/item?id=14202707 https://news.ycombinator.com/item?id=14202707
  - saw-lau 9y ago
    This is also quoted in a Joel Spolsky's article: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... I love the 'Raymond Chen Camp's way of looking at things. xx
    - digi_owl 9y ago
      I really wish all those people chasing the "desktop Linux" mirage while breaking APIs at whim would internalize this. If they want desktop Linux to happen, they need to stop chasing eyecandy and stabilize the plumbing behavior, no matter how much that thought offends their developer pride.
      - emodendroket 9y ago
        That's really not a problem of the kernel, though, is it? Also, I think bigger challenges to desktop Linux are the degree of configurability, drivers (maybe that's better), and the fact that the GUI is never a first-class method of using the app but instead a hastily-written wrapper on top of a command line tool.
  - nix0n 9y ago
    Raymond Chen's URLs have changed but the original articles [0][1] are still available. [0]https://blogs.msdn.microsoft.com/oldnewthing/20031015-00/?p=42163 https://blogs.msdn.microsoft.com/oldnewthing/20031015-00/?p=... [1]https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=41373 https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=...
- drzaiusapelord 9y ago
  Well, it only returns numbers, so padding retired calls with zeros should really break anything other than giving the wrong data. The only other practical alternative is to return 0 bytes and most likely crash the application expecting a result. How many old school apps making invalid stat calls are engineered enough to handle odd exceptions like this? I'd say probably few to none.

piker 9y ago

Interesting. > Behavioral changes happen, and maybe we don't even support some feature any more. There's a number of fields in /proc/<pid>/stat that are printed out as zeroes, simply because they don't even exist in the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced by zeroes, so that the code that used to parse the fields still works. The user might not see everything they used to see, and so behavior is clearly different, but things still _work_, even if they might no longer show sensitive (or no longer relevant) information. I'm not sure I prefer the described result. If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse.

chii 9y ago
> If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse. if your app didn't used to handle the 'zero' case (assuming zero was a "valid" value for said field), then the app was poorly written and would'be been broken in the first place. However, if the app _did_ handle the 'zero' case, then the app continued to work! The end user would've been none-the-wiser about the change (mostly), and some time later, the app could be upgraded to ignore those known fields. Causing a parse error would mean the app stopped working altogether. Much worse a result for the end user.
- piker 9y ago
  I guess that depends on whether or not zeros were valid in the first instance. My post assumed they were. I agree with your point if zero would be outside of the valid range in the first instance.
- hyperpape 9y ago
  There are many cases where continuing with invalid data is much worse than a parse error. Perhaps that's less likely in this case (hopefully your credit card payment doesn't depend on the values in /proc/<pid>/stat), but as a rule, silently continuing with meaningless data is scary.
  - deleted 9y ago
    [deleted]
  - notheguyouthink 9y ago
    Yea that's what I was thinking. If the behavior changes, what "works" entirely depends on the context of that specific application. I can understand mitigating complete failures as much as possible, but trying to trick programs into thinking that they're running the same as they were before seems.. well, scary as hell. I'm honestly not sure what's worse - breaking the application, or making it think everything is fine.
  - spdionis 9y ago
    Not when the application was to supposed to handle the invalid data anyway before. Because you had to handle the zero case before right? The idea is that in the worst case you get an error message, not an altogether crash.
    - deleted 9y ago
      [deleted]
  - cmiles74 9y ago
    If your application relies on these sort of interfaces with the kernel, then presumably you're paying attention when you upgrade the kernel.
- hasenj 9y ago
  It sounds like a chance for logical errors to go undetected before they cause issues somewhere totally unrelated.
- catpolice 9y ago
  Zero could be a perfectly "valid" value and still break your application if changing the function to always return zero breaks an implicit contract. Suppose the previous behavior of the function returned something you could use as an ID for some internal representation in a database that you could look up and write to. Before, the ID you got back depended on the input, but now it doesn't. And you can't tell you're not getting real IDs back anymore, so you just happily write to the database. Now you're corrupting your database because the implicit behavioral contract you were relying on was broken - I'd MUCH rather the program just crash than for it to continue "working" in a way that irrecoverably corrupts data.
- nialv7 9y ago
  > then the app was poorly written and would'be been broken in the first place. If you present this argument to Linus, you will certainly get yelled at. Not breaking the user space means not breaking the user space even when it's broken. A couple years back glibc broke Adobe Flash because Flash used memcpy wrong. Linus was quite vocal about it.
caf 9y ago
If your code had actually broken with the change to a zero (for example it didn't just report 0 of some resource in use in the log, but spawned an unlimited amount of threads until it crashed or something) then you could have reported it as a kernel regression, and it would have been fixed in another way.
- jacobush 9y ago
  True but there is more to it. Linus’s ambition is to also not break the unknown app in the basement, behind the leopard.
jsjohnst 9y ago
Having had to fix a number of production issues where a change happened XX days ago but the code just silently kept going rather than breaking, I’m sorta of the mind to agree with you. I’d almost rather it break hard, so then I know it’s broke and can fix it. Very nuanced situation though and as such definitely not one size fits all.
- 35bge57dtjku 9y ago
  Isn't that just 'fail fast' behavior vs. silent ata corruption?
- __david__ 9y ago
  That's fine when it's code that you wrote, but it would be really annoying to me as a user if htop (for example) started crashing on a kernel upgrade (instead of one the columns suddenly being zero).
  - jsjohnst 9y ago
    Completely and totally agree! Why I said it was a nuanced situation and not one size fits all.
emodendroket 9y ago
Perhaps, but what if the app developer is long gone, and I am a user hoping to keep using my favorite program? Apparently the original Raymond Chen article is gone but I think this quote captures it: https://news.ycombinator.com/item?id=14202707 https://news.ycombinator.com/item?id=14202707
- saw-lau 9y ago
  This is also quoted in a Joel Spolsky's article: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... I love the 'Raymond Chen Camp's way of looking at things. xx
  - digi_owl 9y ago
    I really wish all those people chasing the "desktop Linux" mirage while breaking APIs at whim would internalize this. If they want desktop Linux to happen, they need to stop chasing eyecandy and stabilize the plumbing behavior, no matter how much that thought offends their developer pride.
    - emodendroket 9y ago
      That's really not a problem of the kernel, though, is it? Also, I think bigger challenges to desktop Linux are the degree of configurability, drivers (maybe that's better), and the fact that the GUI is never a first-class method of using the app but instead a hastily-written wrapper on top of a command line tool.
- nix0n 9y ago
  Raymond Chen's URLs have changed but the original articles [0][1] are still available. [0]https://blogs.msdn.microsoft.com/oldnewthing/20031015-00/?p=42163 https://blogs.msdn.microsoft.com/oldnewthing/20031015-00/?p=... [1]https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=41373 https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=...
drzaiusapelord 9y ago
Well, it only returns numbers, so padding retired calls with zeros should really break anything other than giving the wrong data. The only other practical alternative is to return 0 bytes and most likely crash the application expecting a result. How many old school apps making invalid stat calls are engineered enough to handle odd exceptions like this? I'd say probably few to none.