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. chroot is 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.
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.
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>
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.
Fortunately we do have a steady influx of new people incl. those who demand shit to god damn work, finally shifting this notion.
For the time being we still have to resort to using the Windows version and Wine for old software though… But I already had the situation where the (unmaintained but working) app also had a Flatpak which was last updated many years ago and it just worked, which made me incredibly happy and hopeful. ❤️
Good thing there’s a battle-proven response if people don’t like this because it’s “not what Linux is supposed to be” or some other nonsense: If you don’t like it just fork it yourself. 😚
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.
usually the solution is recompiling it, LD_PRELOADing older libraries or using chroot. Since linus never breaks userspace this can actually provide 100% compatibility.
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
Just fyi containers use
pivot_rootnotchrootIsn’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.
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>
Yeah, ten apps on the machine should be enough for anybody.
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.
Fortunately we do have a steady influx of new people incl. those who demand shit to god damn work, finally shifting this notion.
For the time being we still have to resort to using the Windows version and Wine for old software though… But I already had the situation where the (unmaintained but working) app also had a Flatpak which was last updated many years ago and it just worked, which made me incredibly happy and hopeful. ❤️
Good thing there’s a battle-proven response if people don’t like this because it’s “not what Linux is supposed to be” or some other nonsense: If you don’t like it just fork it yourself. 😚
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.
usually the solution is recompiling it, LD_PRELOADing older libraries or using chroot. Since linus never breaks userspace this can actually provide 100% compatibility.
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.