Relevant to SteamOS and open-platform gaming, it proposes a different paradigm for Linux-based distributions and operating systems, one that could address compatibility issues on alternative platforms that Windows users often take for granted.
EDIT: added a QnA section that tries to answer some of the questions posed here.
Why has there been recent issues with compatibility with the userspace then? from systemd to even not so distant news of glibc failing? The article goes a bit more in depth about what needs to be done, it describes a different packaging and distribution model as well that is simpler and more convenient in design.
I think you need to be much more specific if you think anything is going to come from this. I have no idea what recent issues you are referring to.
You’re playing a bit of a fool. I’m talking about this: https://x.com/Plagman2/status/1559683905904463873 and the many examples I’ve personally seen of random “contributors” removing clearly critical infrastructure from glibc.
You picked a particularly rare example. Meaning it was a combination of unexpected use case and 10+ years of deprecation happening to coincide at the wrong time and place.
Even if you had your supposed compatibility layer in place human error or misunderstanding is still going to cause issues like this from time to time.
The DT_HASH issue was specifically NOT an api breakage. It was some apps consuming some internals without keeping track of changes. Yes, they technically broke backwards compatibility. But those apps weren’t supposed to be using that field for a long time.
It isn’t a rare example. That “one example” (which isn’t even accurate) represents one example too many, first of all. Look at the contribution history yourself: you’ll find many cases where changes broke things because the affected code was 7–10 years old.
There’s a reason Windows maintains near-total backward compatibility: a ten-year-old line of code may still be performing essential work, and there’s no inherent need to remove it. Your standards for what qualifies as acceptable deprecation are subjective, but the broader world expects software to maintain compatibility for decades.