There is no distinction between system and program libraries in Linux. We used to pretend there was one before usrmigration, but that was never good to take seriously. The distro as packager model ensures that everything is mixed together in the filesystem and is actively hostile to external packaging. Vendoring dependencies or static linking improves compatibility by choosing known working versions, but decreases in…
> adding an application (not just a program binary) is as easy as extracting a package into a folder and integrates with the rest of the system I have fond memories of installed Warlords Battle Cry 3, Warcraft 3, AOE2 etc. directories on flash drives, distributed to 20+ kids in high school (all using the same key). Good days.
The state of binary compatibility on Linux and how to address it
101–110 of 145 posts
Re: The state of binary compatibility on Linux and how to address it
#102I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi
As if a windows game from 2006 is going to run on windows 11 :)
Re: The state of binary compatibility on Linux and how to address it
#103I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi
Re: The state of binary compatibility on Linux and how to address it
#104I think the problem is that people treat Linux as OS instead of just a kernel. You should assume every Linux distro is a different OS so when you are shipping your app for Linux you're actually shipping your app for Debian, Fedora, Ubuntu etc
That's the sane way to tackle it. If you're the vendor, just target the top N (whatever value of N you can cope with). I don't mean disrespect towards people running Alpine (hi), Arch, or Gentoo, but you wouldn't be running these distros if you aren't ready to handle their quirks. TFA mostly talks about binary compat. Even if you can get away with statically linking everything , you still have to cope with the mess t…
You'd think so, but you'd be surprised how many gamers switching from Windows to Linux get recommended Arch and Manjaro
Re: The state of binary compatibility on Linux and how to address it
#105Re: The state of binary compatibility on Linux and how to address it
#106Earlier quoted context omitted.
That's the sane way to tackle it. If you're the vendor, just target the top N (whatever value of N you can cope with). I don't mean disrespect towards people running Alpine (hi), Arch, or Gentoo, but you wouldn't be running these distros if you aren't ready to handle their quirks. TFA mostly talks about binary compat. Even if you can get away with statically linking everything , you still have to cope with the mess t…
>I don't mean disrespect towards people running Alpine (hi), Arch, or Gentoo, but you wouldn't be running these distros if you aren't ready to handle their quirks. You'd think so, but you'd be surprised how many gamers switching from Windows to Linux get recommended Arch and Manjaro
I wonder if Arch being the basis for SteamOS is responsible.
Re: The state of binary compatibility on Linux and how to address it
#107I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi
As if a windows game from 2006 is going to run on windows 11 :)
[1] https://steamcommunity.com/sharedfiles/filedetails/?id=28643...
Re: The state of binary compatibility on Linux and how to address it
#108I disagree with their idea for fixing it by splitting up glibc. I think it's a bad idea because it doesn't actually fix the problems that lead to compat breakage, and it's bad because it's harder than it seems.
They cite these compat bugs as part of their reasoning for why glibc should be split up:
- https://sourceware.org/bugzilla/show_bug.cgi?id=29456
- https://sourceware.org/bugzilla/show_bug.cgi?id=32653
- https://sourceware.org/bugzilla/show_bug.cgi?id=32786
I don't see how a single one of these would be fixed by splitting up glibc. If their proposed libdl or libthread were updated and had one of these regressions, it would cause just as much of a bug as if a monolithic libc updates with one of these regressions.
So, splitting up glibc wouldn't fix the issue.
Also, splitting up glibc would be super nasty because of how the threading, loading, and syscall parts of libc are coupled (some syscalls are implemented with deep threading awareness, like the setxid calls, threads need to know about the loader and vice-versa, and other issues).
I think the problem here is how releases are cut. In an ideal world, glibc devs would have caught all three of those bugs before shipping 2.41. Big corpos like Microsoft manage that by having a binary compatibility team that runs All The Apps on every new version of the OS. I'm guessing that glibc doesn't have (as much of) that kind of process.
Re: The state of binary compatibility on Linux and how to address it
#109Re: The state of binary compatibility on Linux and how to address it
#110Earlier quoted context omitted.
And please, statically linking everything is NOT a solution -- the only reason I can run some games from 20 years ago still on my recent Linux is because they didn't decide to stupidly statically link everything, so I at least _can_ replace the libraries with hooks that make the games work with newer versions.
Software running for 20 years is not always a reasonable requirement.