Hacker News Reader

Comment by __david__ | Hacker News Reader

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

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.

> 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.

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.

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.

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.

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.

If your application relies on these sort of interfaces with the kernel, then presumably you're paying attention when you upgrade the kernel.

It sounds like a chance for logical errors to go undetected before they cause issues somewhere totally unrelated.

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.

> 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.

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.

True but there is more to it. Linus’s ambition is to also not break the unknown app in the basement, behind the leopard.

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.

Isn't that just 'fail fast' behavior vs. silent ata corruption?

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).

Completely and totally agree! Why I said it was a nuanced situation and not one size fits all.

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

This is also quoted in a Joel Spolsky's article:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

I love the 'Raymond Chen Camp's way of looking at things. xx

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.

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.

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=...

[1]https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=...

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.

Reply on news.ycombinator.com