Never break userspace
Never break userspace
Posted Feb 16, 2024 18:05 UTC (Fri) by bluca (subscriber, #118303)In reply to: Never break userspace by mb
Parent article: A turning point for CVE numbers
Or in other words, different software work differently. Or, yet again, you are moving the goal posts. Because nobody ever said "systemd works in exactly the same way as your 1980s garden variety collection of shell scripts", in fact the idea was very much the opposite. Some compat layers for the main interfaces were provided, which were always clearly documented as sub-optimal and wonky and intended for transition purposes, and after 20 years or so we'll remove them too, with ample advance notice. But nobody ever claimed that every single workflow in existence would continue unchanged after switching.
In fact, we don't even make absolute claims such as "we never break compatibility, period". From time to time we do breaking changes, and we try to announce them in advance, and for really impactful ones we try to get consensus on the mailing list first, and in rare cases we even try to help distributions migrate ahead of time to ensure the impact is nominal only - see when we dropped support for unmerged-usr last year for example - this happened in v255, and nobody noticed.
Sometimes things break accidentally, and sometimes they get fixed and sometimes they don't.
But what we most certainly don't do, is going around claiming "we never break compatibility", and I certainly don't use such a claim to start firing a bogus CVE for each commit that I backport to every stable branch I maintain.
See where the difference is?
Posted Feb 16, 2024 18:59 UTC (Fri)
by mb (subscriber, #50428)
[Link] (7 responses)
>See where the difference is?
Nope.
Posted Feb 16, 2024 19:03 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
The difference is that kernel developers have publicly committed to never breaking userspace. Systemd developers haven't. It is the disconnect between the public messaging and reality that's causing the contention. Not the changes themselves necessarily.
Posted Feb 16, 2024 19:10 UTC (Fri)
by mb (subscriber, #50428)
[Link] (3 responses)
Things like uevents, tracepoints, sysfs files, etc... were pretty much never part of that claim.
> It is the disconnect between the public messaging and reality that's causing the contention.
The disconnect between the expectation and the reality is causing the contention.
Posted Feb 16, 2024 19:21 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (2 responses)
Citation needed. That is very much not evident from any claim anybody has ever made that I have seen.
Posted Feb 16, 2024 19:41 UTC (Fri)
by mb (subscriber, #50428)
[Link] (1 responses)
Even syscalls have been removed in the past, breaking applications.
Citation: Look at the sources.
There has never been a thing like a general stability guarantee.
Posted Feb 16, 2024 20:07 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
> If a change only breaks udev or systemd and nothing else, it might make sense to do it.
I beg to differ
Posted Feb 16, 2024 19:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Where?
Okay, I know Linus says "never break user-space", and he is very strict about it. But at the end of the day, shit happens.
And there's plenty of kernel developers who *haven't* signed up to it. They just know that trying to get it past Linus is not a battle worth fighting most of the time.
There's one big example I can think of, that had a rather nasty fall-out, in the raid world. So bad, in fact, that kernels were modified to have an explicit "fail to boot" config, iirc!
Something to do with the fact that raid layout was accidentally changed. So you have pre-change kernels that will trash post-change arrays, pre-discovery kernels that will trash pre-change arrays, and post-discovery kernels that will refuse to access arrays without a "this is a pre/post-layout flag".
Sometimes that's all you can do :-(
Cheers,
Posted Feb 16, 2024 20:04 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
Never break userspace
It's exactly the same thing. Things change. Deal with it like everybody has to deal with systemd.
Never break userspace
Never break userspace
Devs try hard to not make unnecessary breakages, but if a sysfs file disappears/changes or an uevent changes, programs have to deal with it.
Has always been like that.
Never break userspace
Never break userspace
BUT these applications always were very limited in count and usually part of the OS itself.
It always has been a matter of common sense.
If a change only breaks udev or systemd and nothing else, it might make sense to do it.
Never break userspace
Never break userspace
Wol
Never break userspace