-6
An Open Letter on Linux Compatibility (and Why Flatpak Isn't the Fix) (www.reddit.com)
submitted 15 hours ago by to c/linux@lemmy.world
15 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 21 points 14 hours ago (12 children)

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?

  • permalink
  • fedilink
  • source
  • hideshow 12 child comments
    •
  • [–] 6 points 14 hours ago* (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] -4 points 14 hours ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 9 points 14 hours ago

    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

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 0 points 9 hours ago (3 children)

    Your comment reduces my article to vague claims of ignorance and a basic mention of something you admittedly only glanced on. The article is much richer in depth than your comment suggests, I encourage people here to actually read it so we can have a proper discussion. I promise you that it won't disappoint even if you don't agree fully with it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 8 hours ago (2 children)

    I did read it. It's not that long.

    I still don't know what problem you are trying to resolve that doesn't already have one or more solutions.

    You listed one issue, specific to gaming and cheating, that was simple human error and miscommunication that I don't believe would be solved by what you are proposing.

    What other examples do you have? You seem to be starting with an assumption that everyone knows and agrees what the problem is without truly stating it.

    The Linux kernel, and most userspace libraries already have a contract to maintain backwards compatibility. Some developers may choose to ignore this or make mistakes and break this contract. Again I do not believe that adding some new compatibility layer will fix this.

    I'm sorry, but your article seems very hand wavy to me and doesn't have enough detail on how it would work. What you are proposing seems huge. I can't imagine enough people buying in to the idea to get it off the ground.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] -1 points 8 hours ago (1 child)

    There are many problems with existing solutions, I've already had a long discussion on this on the subreddit. and I went in more detail in the conversation. check it out if you're interested.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] -1 points 14 hours ago* (last edited 14 hours ago) (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 10 points 14 hours ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [+] [S] -7 points 14 hours ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 9 points 14 hours ago

    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.

  • permalink
  • fedilink
  • source
  • parent