Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
At least skip the Reddit link and post the source...
https://parallel-minds0.github.io/An-Open-Letter-on-Linux-Compatibility/
From a quick skim, I think the author doesn't really know that much about how Linux and its various components and libraries actually work. Though it seems they are loosely proposing somebody new compatibility layer?
And what is this supposed NT compatibility promise?
The Linux kernel has maintained strict backwards compatibility at the user space level for ages.
Individual libraries are versioned and can be kept around for as long as anyone likes.
Package management and dependencies might be a bigger problem, but I would guess a manageable one?
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.