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?
That's OOP: https://xkcd.com/927/
If I understand OOP correctly, the NT compatibility promise is the idea that not only the kernel but also the userspace is standardized, backwards compatible and stable.
OOP really doesn't seem to understand how Linux works under the hood and what the issue is.
The main problem is not that e.g. installed libraries are in different paths under different distros, but that installing libraries is different between different distros, and that different versions are available.
A library package might be called libXYZ-dev in one distro and libXYZ-devel in another, and in the third distro it's not even available or available in the wrong versions. That's the real problem, and OOPs approach of splitting package distribution from the stability of the user space is completely contrary to their proposed solution.
They just assumed two contradicting goals would somehow make a coherent whole.
That author just saw Windows and didn't understand why that system works, saw Linux and didn't understand why there's fragmentation problems there and thought that applying the Windows model to Linux somehow magically works.
Edit: I just noticed that the OP and the author of the blog post have the same user name and thus likely are the same person.
I think you’ve gotten a really bad read of my article. We know the typical Linux stack has problems with libraries failing to maintain backward compatibility and even when they do, the guarantees are nowhere near as strong or long-lasting as on Windows.
The problem is ultimately cultural. My article is essentially an appeal to anyone willing and capable of building a sane userspace through a single distribution. If that distribution adopts the stack, others can copy it or diverge at their own cost.
As for separating the userspace from regular applications, the point is that the OS shouldn’t treat system packages and user packages as the same thing. That’s separation of concerns, not a contradiction.
We do? I certainly don't. Which libraries? That's likely not a generic Linux issue. That's more probably a specific issue with those specific libraries or distros.