Live data from Hacker News

The state of binary compatibility on Linux and how to address it

jangafx.com

101–110 of 145 posts

Re: The state of binary compatibility on Linux and how to address it

#101
post #47

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.

Way off topic but you just reminded me of all the time I spent playing Warlords 3 (not Warlords Battlecry 3, the original Warlords games were turn-based). One cool feature it had that I'm surprised I haven't really seen other turn-based games do is a "play by email" option similar to correspondence chess, except you're just emailing save files back and forth and the game makes importing/exporting the save files via email a bit more streamlined.

Re: The state of binary compatibility on Linux and how to address it

#102
post #99

I 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 :)

I was able to run Age of Empires 2 on Windows 11. It didn't like running on an ultrawide, but it worked well enough at smaller resolutions.

Re: The state of binary compatibility on Linux and how to address it

#103

I 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

The most annoying part to me is that Linus et all make not breaking compatibility their #1 goal (only rarely superseded by security and performance concerns) but all of the other libraries on top of the kernel don't seem to care about that at all and break things willy-nilly.

Re: The state of binary compatibility on Linux and how to address it

#104
post #90
post #86

I 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…

>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

Re: The state of binary compatibility on Linux and how to address it

#105
There’s no reason to believe that widespread Linux adoption would not irrevocably damage the experience. It would end up looking something like Android. The same thing happened to the internet. It was ruined by mass adoption. You can call this gatekeeping, but nothing positive has come from getting most of the world onto social media.

Re: The state of binary compatibility on Linux and how to address it

#106
post #90

Earlier 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 see Bazzite recommended more than Arch these days, but Arch is confusingly a very popular choice.

I wonder if Arch being the basis for SteamOS is responsible.

Re: The state of binary compatibility on Linux and how to address it

#107
post #99

I 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 :)

The 2006-engine version of Half-Life 2: Episode 1 runs on Windows 10/11 with no configuration [1], outside of getting Steam to download it. I recall installing The Elder Scrolls IV: Oblivion on a Windows 11 machine, which just needed Directx 9c to run.

[1] https://steamcommunity.com/sharedfiles/filedetails/?id=28643...

Re: The state of binary compatibility on Linux and how to address it

#108
This is a really great article about binary compatibility!

I 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

#110
post #31

Earlier 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.

But sometimes it is. And even if it's not a requirement, it might be nice to have.
Post reply on HN