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”.
<rant>
How dare we have different versions of the same lib! Where will we end up, like MS Windows? Where I can boot up apps as old as myself? Outrageous! Not my precious mibibytes!).
</rant>
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.
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.
I really think its just not that common. There are ways to do this for the few and not pollute the OS for the many. Steam does it for their use case. If it were a more common of a need, then I would expect distro maintainers to take care of it. The same way they did for 32bit libraries back in the day. When is the last time you had to install a 32bit distro along side your 64bit distro so you could run 32bit applications? Sometimes I need a bleeding edge build of an application. I run a stable distro. So build the application myself or install a quick chroot These days there is distrobox that makes it even easier. There are solutions. Easy from my perspective. That’s why I think, if this was such a common need, distro maintainers would provide a simple solution (automatically done for you).
This hasn’t been a problem for a decade or two, but I see drive costs inflate immensely, I wonder how it will impact how “bloat” is processed. Not everyone has infinite access to storage. BTRFS and other fs dedup features may be an acceptable work around, but I don’t know flatpacks structure enough to know if they can benefit from it.
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”.
<rant> How dare we have different versions of the same lib! Where will we end up, like MS Windows? Where I can boot up apps as old as myself? Outrageous! Not my precious mibibytes!). </rant>
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.
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.
I really think its just not that common. There are ways to do this for the few and not pollute the OS for the many. Steam does it for their use case. If it were a more common of a need, then I would expect distro maintainers to take care of it. The same way they did for 32bit libraries back in the day. When is the last time you had to install a 32bit distro along side your 64bit distro so you could run 32bit applications? Sometimes I need a bleeding edge build of an application. I run a stable distro. So build the application myself or install a quick chroot These days there is distrobox that makes it even easier. There are solutions. Easy from my perspective. That’s why I think, if this was such a common need, distro maintainers would provide a simple solution (automatically done for you).
This hasn’t been a problem for a decade or two, but I see drive costs inflate immensely, I wonder how it will impact how “bloat” is processed. Not everyone has infinite access to storage. BTRFS and other fs dedup features may be an acceptable work around, but I don’t know flatpacks structure enough to know if they can benefit from it.