πͺΏ
this post was submitted on 31 Jan 2026
1094 points (97.6% liked)
linuxmemes
29730 readers
918 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Linux really doesn't get bragging rights for "install[ing] old applications". Linux ironically has been somewhat better for me than Windows for running older Windows applications thanks to WINE, but when it comes to installing old Linux applications, even when I wasn't on a rolling release distro, it's been a total crapshoot.
If, for example, there's a native Linux game that hasn't been updated in a few years, my experience buying it has generally been hoping the Linux version works, it doesn't, and I'm stuck running it through WINE.
PCSX2 1.6.0, which used wxWidgets, released May 2020, and even five years after that, opening it on Linux shows you a frozen, unusable window that you have to manually kill. (citing PCSX2 because it's a use case of mine as a contributor.) IIIRC, on Windows, you can straight-up go back to versions from like 2010 and still have them work.
The linux way to handle it is with a
chroot. Used to do this back in the day to get 32bit libraries on a 64bit distro that didn't include 32bit libraries.chrootis the basis for modern containerization technologies. These days, I usually use it for bleeding edge application builds that don't have a build for my distro, yet. Distrobox makes it pretty simple. With distrobox, you can install the application you need in the OS that supports the application you want, then just map the binary into your OS.See here: https://distrobox.it/useful_tips/#export-to-the-host
Isnβt that functionally what a flatpak is?
Same concept. Flatpak is based on bubblewrap, which was based off another tool that was based on chroot.
Edit: Looks like Flatpak is working towards adopting a different (newer) feature that allows some containerization features at the user level, without requiring chroot super user level.
Just fyi containers use
pivot_rootnotchrootI'm aware. I said, "basis", not "uses".
The reason this is a problem is that devs think they need to save 10MB of RAM by dynamically linking libc instead of statically compiling it or just including the blob with the game.
Puritans on Linux are a real menace. Every time someone calls an OS install image of 3-4gb "bloated" I want to scream uncontrollably. Not statically linking stuff is part of this cultural issue.
Flatpak might solves these issues in the long run. Of course the same people therefore hate it, because it's "bloated" and "convoluted".
The core principal of GNU from which every other principal is derived is "I shouldn't need an ancient unmaintained printer driver that only works on windows 95 to use my god damned printer. I should have the source code so I can adapt it to work with my smart toaster"
If an app is open source then I've almost never encountered a situation where I can't build a working version. Its happened to me once that I remember. A synthesia clone called linthesia. Would not compile for love nor money and the provided binary was built for ubuntu 12 or something.
Linux was probably ready for the 64-bit appocalypse even before Apple for this exact reason. Anything open source will just run, on anything, because some hobbiest has wanted to use it on their favourite platform at some point. And if not, you'd be surprised how not hard it is to checkout the sourcecode from github and make your own port. Difficult, but far from impossible.
Steam games do not distribute source code, which means they break, and when they break the community can't fix them. They can't statically link glibc because that would put them in violation of the GPL (as far as I'm aware anyway). They are fundamentally second class citizens on linux because they refuse to embrace its culture. FOSS apps basically never die while there's someone to maintain them.
Its like when American companies come to Europe and realise the workers have rights and then get a reputation as scuzzballs for trying to rules lawyer those rights.
glibc is released under the LGPL, not the GPL. It is completely fine to statically link it.
EDIT: But there are some extra things you have to do: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
Okay so bundle glibc. As far as I know link systemcalls are set up to look in the working directory first
Why would statically compiling it violate the GPL?
It wouldn't; glibc is LGPL not GPL. The person you're replying to was mistaken.
You know what, that explains how they can exist on linux at all. Because from what I understand, if glibc was GPL and not LGPL, closed source software would basically be impossible to run on the platform. Which⦠maybe isn't the best outcome when you think about it. As much as I hate the Zoom VDI bridge, I don't want "using windows" to be the alternative.
and yeah, from the source you provided, I can see why they don't statically link. "If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source". So basically if they bundle glibc then they need to provide the glibc source to users on request but if they just distribute a binary linked against the system one then that's their obligations met.
Welcome to "complying with the LGPL for the terminally lazy", I'll be your host "Every early linux port of a steam game!"
My understanding of the linking rules for the GPL is that they're pretty much always broken and I'm not even sure if they're believed to be enforceable? I'm far out of my element there. I personally use MPLv2 when I want my project to be "use as you please and, if you change this code, please give your contributions back to the main project"
They missed the first character because they took the L
It should be noted that statically linking against an LGPL library does still come with some constraints. https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
You have to provide the source code for the version of the library you're linking somewhere. So basically if you ship a static linked glibc executable, you need to provide the source code for the glibc part that you included. I think the actual ideal way to distribute it would be to not statically link it and instead deliver a shared library bundled with your application.
EDIT: Statically linking libc is also a big pain in general, for exampled you lose
dlopen. It's best not to statically link it if possible. All other libraries, go for it.Not so much but that's easily fixed with an
export LD_LIBRARY_PATH=.Because you've created something that contains compiled GPL code that can't be untangled or swapped out. The licence for the Gnu C Compiler is basically designed so you can't use it to build closed source software. Its a deal with a communist devil. If you want to build a binary that contains GPL code (which is what glibc is) then you have to make everything in that binary licensed under a GPL compatible license. That's what the whole "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches" quote from Steve Balmer was in aid of. And he was correct and this was literally the system operating as intended.
Dynamic linking is some looney tunes ass "see, technically not violating the GPL" shit that corporations use to get around this.
Oh, so bundling it and adding that env will work.
From a technical standpoint, yes. From a legal standpoint:
Welcome to "what did you think was going to happen if you told for profit corporations that if they want to distribute a library in a bundle they also have to provide the source code but if they just provide it linked against an ancient version that nobody will be using in 5 years and don't even tell you which one they're 100% in compliance"?
Could they? yes. Will they? probably not, that takes too much work.
This is why steam's own linux soldier runtime environment (Which is availible from the same dropdown as proton) had to become a thing.
Also, your OS will tell you which library it can't find.
as long as you run it from the command line. On my system at least if there's a library missing it will just silently fail to launch. I love linux but it does not make it easy
Is there a site to download various .so files?
.so files are distro dependent. (This is theoretially a good thing. Means debian can distribute a stable version and Arch can distribute a so fresh the hen doesn't know its missing yet version). If you're a command line guru you can run a pacman or deb query to find out what package you have to install to add that library at a system level. But oftentimes you can't just use a different .so because the .so was built to depend on another .so and you basically have to solve a dependency chain by hand. Its a big mess that apt or pacman or even gentoo's famously obtuse emerge solves for you invisibly.
as to where to find the ancient version that binary was built for? well My goto is archive.archlinux.org but its an asshole of a process and not for the faint of heart. sometimes you just need to build the library from scratch which is BULLSHIT and I'm not unaware of that fact.
can you just go to a website and download the .so? yes actually. But it might just decide not to work. This is a problem that individual distros are meant to be solving and do so when distributing open source software. As for with steam games, I think valve solves this problem with the soldier runtime environment which I mentioned above.
This shit is the exact reason Linux doesn't just have ridiculously bad backwards compatibility but has also alienated literally everyone who isn't a developer, and why the most stable ABI on Linux is god damn Win32 through Wine. Hell, for the same reason fundamentally important things like accessibility tools keep breaking, something where the only correct answer to is this blogpost. FOSS is awesome and all, but not if it demands from you to become a developer and continuesly invest hundreds of hours just so things won't break. We should be able to habe both, free software AND good compatibility.
What you describe is in no way a strength, it's Linux' core problem. Something we have to overcome ASAP.
The Linux ABI stability is tiered, with the syscall interface promising to never change which should be enough for any application that depends on libc. Applications that depend on unstable ABIs are either poorly written (ecosystem problem, not fixable by the kernel team, they're very explicit about what isn't stable) or are inherently unstable and assume some expertise from the user. I'd say the vast majority of programs are just gonna use the kernel through libc and thus should work almost indefinitely.
But you can do that: Linux provides a ton of ways to use different versions of the same lib. The distro is there to provide a solid foundation, not be the base for every single thing you want to run. The idea is you get a core usable operating system and then do whatever you want on top of that.
What, you don't like role-playing software development & distribution as if we were still in the 90s?? π₯Ίπ₯Ί /j
But srs, most of Linux's biggest technical problems are either caused by cultural legacy or blocked by it. The distribution model being one of the most pungent examples.
Linux version of Rocket League still works but you can't connect to the servers. They stopped supporting Linux when Epic bought them in 2019. So going on 7 years and the Linux version still works fine. Just as a counterpoint.
Which reminds me. Hotline Miami has a native Linux build, yet I had to install a few more libs to get it to work. The funniest part is that this was a GOG installer, so it should have had the libs built in. If I downloaded the Windows installer and used it with Wine, I wouldn't have ran into this problem.
Another problem is with some but not all Unity games. I don't remember what the other one was, but HuniePop's Linux build would be skipping frames, and the Windows build would run just as intended.
It's then I learned to stick to Windows versions of games even if they got a Linux version. Besides, I can send these installers to actual Windows devices.
Yeah, I found quite a few games that I had to go in and specify it re-download and use Proton because the Linux native build was borked.
In a lot of cases devs will export for Linux but not test it.
usually the solution is recompiling it, LD_PRELOADing older libraries or using chroot. Since linus never breaks userspace this can actually provide 100% compatibility.