3 ms·

For user experience reasons that seems like a extremely sensible principle. But doesn't this make fixing some security issues impossible?

dangoor 9y ago
Linus calls out the fact that there are some times in which breakage is unavoidable, but that should only be after trying very hard to avoid breakage.
- Bartweiss 9y ago
  I do think there's an enormous difference between breaking changes of the form "hey, this is important and it's going to break shit, we can't find an alternative, be prepared" and "oops, we broke it, good luck!" Rare, planned breaking changes are a reasonable answer to improving security and usability. Python 2 -> 3 and the Mac PowerPC switch both seem like examples: they caused real inconvenience, but they were very clearly announced and had real benefits. Sporadically screwing over users, though, really is unforgivable. Last time I updated Windows it escalated a minor graphics card issue from "automatically recovers" to "kills your session to collect error data". It's like the patch author comes into my house once a week and unplugs my machine, just for their own amusement.
masklinn 9y ago
From the followup message Kalleboo linked to: > There have been exceptions, but they are few and far between, and they generally have some major and fundamental reasons for having happened, that were basically entirely unavoidable, and people _tried_hard_ to avoid them. Maybe we can't practically support the hardware any more after it is decades old and nobody uses it with modern kernels any more. Maybe there's a serious security issue with how we did things, and people actually depended on that fundamentally broken model. Maybe there was some fundamental other breakage that just _had_ to have a flag day for very core and fundamental reasons. > And notice that this is very much about breaking peoples environments. So breaking userland is possible if there is literally no other way, but 1. it's the "nuclear option "of kernel changes 2. it will be acknowledged as breaking users's environments
- wang_li 9y ago
  A number of years ago some dillhole became annoyed that strings in the kernel inconsistently capitalized null, sometimes it was "null" sometimes "NULL". So they submitted a patch to make them consistent. This broke the iscsi userland. As far as I know, it was never reverted.
detaro 9y ago
In the mail the quote is from, he lists security issues that can't fixed otherwise as one of the reasons exceptions happen.
emeraldd 9y ago
That's one of the specific exceptions he mentions. 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. i.e. the kernel may not do what it did before but your tool shouldn't crash. It may not have all the info you used to see though ... Edit: fix styling

dangoor 9y ago

Linus calls out the fact that there are some times in which breakage is unavoidable, but that should only be after trying very hard to avoid breakage.

Bartweiss 9y ago
I do think there's an enormous difference between breaking changes of the form "hey, this is important and it's going to break shit, we can't find an alternative, be prepared" and "oops, we broke it, good luck!" Rare, planned breaking changes are a reasonable answer to improving security and usability. Python 2 -> 3 and the Mac PowerPC switch both seem like examples: they caused real inconvenience, but they were very clearly announced and had real benefits. Sporadically screwing over users, though, really is unforgivable. Last time I updated Windows it escalated a minor graphics card issue from "automatically recovers" to "kills your session to collect error data". It's like the patch author comes into my house once a week and unplugs my machine, just for their own amusement.

masklinn 9y ago

From the followup message Kalleboo linked to: > There have been exceptions, but they are few and far between, and they generally have some major and fundamental reasons for having happened, that were basically entirely unavoidable, and people _tried_hard_ to avoid them. Maybe we can't practically support the hardware any more after it is decades old and nobody uses it with modern kernels any more. Maybe there's a serious security issue with how we did things, and people actually depended on that fundamentally broken model. Maybe there was some fundamental other breakage that just _had_ to have a flag day for very core and fundamental reasons. > And notice that this is very much about breaking peoples environments. So breaking userland is possible if there is literally no other way, but 1. it's the "nuclear option "of kernel changes 2. it will be acknowledged as breaking users's environments

wang_li 9y ago
A number of years ago some dillhole became annoyed that strings in the kernel inconsistently capitalized null, sometimes it was "null" sometimes "NULL". So they submitted a patch to make them consistent. This broke the iscsi userland. As far as I know, it was never reverted.

detaro 9y ago

In the mail the quote is from, he lists security issues that can't fixed otherwise as one of the reasons exceptions happen.

emeraldd 9y ago

That's one of the specific exceptions he mentions. 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. i.e. the kernel may not do what it did before but your tool shouldn't crash. It may not have all the info you used to see though ... Edit: fix styling