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. 😚
Fortunately we do have a steady influx of new people incl. those who demand shit to god damn work, finally shifting this notion.
What the hell is going on in this thread? Linux has been being actively developed by people who want “shit to god damn work” forever. What are the concrete examples of things that don’t work? Old games? Is that the problem here? These things that were developed for the locked in Windows ecosystem since time immemorial and never ran on Linux and now, through all of the work of the Linux ecosystem, do, by some miracle, run on Linux. It’s amazing that these things work at all: they were never intended to!
What the hell is going on in this thread? Linux has been being actively developed by people who want “shit to god damn work” forever.
Yes and no. Yes as in “you can fix it” (if you’re a programmer), but no in terms of “everything is set up so binaries will still run in 20 years as-is”. Dependency hell, missing library versions, binaries being linked against old glibc versions you can’t provide… all of these are known issues, and devs are often being discouraged from compiling tools in a way that makes them work forever (since that makes the app bigger and potentially consume more memory). And better don’t tell someone who’s blind (and used Linux before) what’s quoted above, they’ll either laugh at you or get really angry. It’s also one of the reasons I’m angry (I’m able to see, but I hate this hypocrisy in the community). Linux on desktop utterly alienated disabled people, simply because stuff like screenreaders keep breaking.
Running 20 year old binaries is not the primary use case and it is very manageable if you actually want to do that. I’ve been amazed at some completely ancient programs that I’ve been able to run, but I don’t see any reason a 20 year old binary should “just work”, that kind of support is a bit silly. Instead maybe we should encourage abandonware to not be abandonware? If you’re not going to support your project, and that project is important to people, provide the source. I don’t blame the Linux developers for that kind of thing at all.
devs are often being discouraged from compiling tools in a way that makes them work forever (since that makes the app bigger and potentially consume more memory)
This is simply not true. If you want your program to be a core part of a distribution, yes, you must follow that distribution’s packaging and linking guidelines: I’m not sure what else a dev would expect. There is no requirement that your program be part of a distribution’s core. Dynamic linking isn’t some huge burden holding everyone back and I have absolutely no idea why anyone would pretend it is. If you want to static link go for it? There is literally nothing stopping you.
Linux desktop isn’t actively working against disabled people, don’t be obtuse. There is so much work being done for literally no money by volunteers and they are unable to prioritize accessibility. That’s unfortunate but it’s not some sort of hypocritical alienation. That also has likely very little to do with the Linux kernel ABI stability like you claimed earlier.
But this idea that “finally we have people that want Linux to work” is infuriating. Do you have any idea how much of an uphill battle it has been to just get WiFi working on Linux? That isn’t because the volunteer community is lazy and doesn’t want things to work: that’s because literally every company is hostile to the open source community to the point of sometimes deliberately changing things just to screw us over. The entitlement in that statement is truly infuriating.
Running 20 year old binaries is not the primary use case and it is very manageable if you actually want to do that. I’ve been amazed at some completely ancient programs that I’ve been able to run, but I don’t see any reason a 20 year old binary should “just work”, that kind of support is a bit silly. Instead maybe we should encourage abandonware to not be abandonware? If you’re not going to support your project, and that project is important to people, provide the source. I don’t blame the Linux developers for that kind of thing at all.
I see your point. What I think though is that it’s particularly hard on Linux to fix programs, especially if you are not a developer (which is always the perspective I try to see things from). Most notable architectural difference here between f.e. Windows and Linux would be how you’re able to simply throw a library into the same folder as the executable on Windows for it to use it (an action every common user can do and fully understand). On Linux you hypothetically can work with LD_PRELOAD, but (assuming someone already wrote a tutorial and points to the file for you to grab) even that already requires more knowledge about some system concepts.
Of course software not becoming abandonware would be best, but that’s not really something we can expect to happen. Even if Europe would make the absolutely banger move and enforce open-sourcing upon abandonment of software after a few years, it would still require a developer to fix issues. The architecture of the OS should be set up so it’s as easy as possible to make something run, using concepts (like file management) as many people as possible are familiar with.
devs are often being discouraged from compiling tools in a way that makes them work forever (since that makes the app bigger and potentially consume more memory)
This is simply not true.
We might be in different bubbles in this case. Please be aware I’m talking about the very loud toxic minority (hopefully it’s a minority…) who constantly shit about how things aren’t following “KISS” close enough, that your app or distro is bloated, etc. It feels like if I was collecting all statements against Flatpak, systemd, even just static linking that boil down to “it’s bloated! It’s not KISS! Bad!” (so not well-reasoned criticism) I read or hear, including around my local hackspace or on events, I could fill whole books.
Linux desktop isn’t actively working against disabled people, don’t be obtuse.
Not actively, no. The issue here is rather that, for way too long, we didn’t care enough. We had things working comparatively nicely one or two decades ago, but in more recent history the support deteriorated to such a degree the Linux desktop has become, to a huge degree, inaccessible to blind people (mostly due to issues with Wayland). I didn’t save those blogposts or statements to show in discussions like these, but the takeaway from all of them is that “It used to work for me many years ago, but if I want a system that respects me today I’m forced to use Mac”. But of course you’re also right, it’s slowly getting better!
(Correct me if I’m wrong, not a native speaker: “being alienated” doesn’t inherently imply malicious intent of doing so, does it?)
But this idea that “finally we have people that want Linux to work” is infuriating. Do you have any idea how much of an uphill battle it has been to just get WiFi working on Linux? That isn’t because the volunteer community is lazy and doesn’t want things to work: that’s because literally every company is hostile to the open source community to the point of sometimes deliberately changing things just to screw us over. The entitlement in that statement is truly infuriating.
Sorry, I was really pissed off yesterday evening by earlier comments in the chain implying it’s good to “filter out people” and got carried away. This one is completely on me.
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).
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.
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.
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.
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”.
<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. 😚
What the hell is going on in this thread? Linux has been being actively developed by people who want “shit to god damn work” forever. What are the concrete examples of things that don’t work? Old games? Is that the problem here? These things that were developed for the locked in Windows ecosystem since time immemorial and never ran on Linux and now, through all of the work of the Linux ecosystem, do, by some miracle, run on Linux. It’s amazing that these things work at all: they were never intended to!
Yes and no. Yes as in “you can fix it” (if you’re a programmer), but no in terms of “everything is set up so binaries will still run in 20 years as-is”. Dependency hell, missing library versions, binaries being linked against old glibc versions you can’t provide… all of these are known issues, and devs are often being discouraged from compiling tools in a way that makes them work forever (since that makes the app bigger and potentially consume more memory). And better don’t tell someone who’s blind (and used Linux before) what’s quoted above, they’ll either laugh at you or get really angry. It’s also one of the reasons I’m angry (I’m able to see, but I hate this hypocrisy in the community). Linux on desktop utterly alienated disabled people, simply because stuff like screenreaders keep breaking.
Running 20 year old binaries is not the primary use case and it is very manageable if you actually want to do that. I’ve been amazed at some completely ancient programs that I’ve been able to run, but I don’t see any reason a 20 year old binary should “just work”, that kind of support is a bit silly. Instead maybe we should encourage abandonware to not be abandonware? If you’re not going to support your project, and that project is important to people, provide the source. I don’t blame the Linux developers for that kind of thing at all.
This is simply not true. If you want your program to be a core part of a distribution, yes, you must follow that distribution’s packaging and linking guidelines: I’m not sure what else a dev would expect. There is no requirement that your program be part of a distribution’s core. Dynamic linking isn’t some huge burden holding everyone back and I have absolutely no idea why anyone would pretend it is. If you want to static link go for it? There is literally nothing stopping you.
Linux desktop isn’t actively working against disabled people, don’t be obtuse. There is so much work being done for literally no money by volunteers and they are unable to prioritize accessibility. That’s unfortunate but it’s not some sort of hypocritical alienation. That also has likely very little to do with the Linux kernel ABI stability like you claimed earlier.
But this idea that “finally we have people that want Linux to work” is infuriating. Do you have any idea how much of an uphill battle it has been to just get WiFi working on Linux? That isn’t because the volunteer community is lazy and doesn’t want things to work: that’s because literally every company is hostile to the open source community to the point of sometimes deliberately changing things just to screw us over. The entitlement in that statement is truly infuriating.
deleted by creator
I see your point. What I think though is that it’s particularly hard on Linux to fix programs, especially if you are not a developer (which is always the perspective I try to see things from). Most notable architectural difference here between f.e. Windows and Linux would be how you’re able to simply throw a library into the same folder as the executable on Windows for it to use it (an action every common user can do and fully understand). On Linux you hypothetically can work with LD_PRELOAD, but (assuming someone already wrote a tutorial and points to the file for you to grab) even that already requires more knowledge about some system concepts.
Of course software not becoming abandonware would be best, but that’s not really something we can expect to happen. Even if Europe would make the absolutely banger move and enforce open-sourcing upon abandonment of software after a few years, it would still require a developer to fix issues. The architecture of the OS should be set up so it’s as easy as possible to make something run, using concepts (like file management) as many people as possible are familiar with.
We might be in different bubbles in this case. Please be aware I’m talking about the very loud toxic minority (hopefully it’s a minority…) who constantly shit about how things aren’t following “KISS” close enough, that your app or distro is bloated, etc. It feels like if I was collecting all statements against Flatpak, systemd, even just static linking that boil down to “it’s bloated! It’s not KISS! Bad!” (so not well-reasoned criticism) I read or hear, including around my local hackspace or on events, I could fill whole books.
Not actively, no. The issue here is rather that, for way too long, we didn’t care enough. We had things working comparatively nicely one or two decades ago, but in more recent history the support deteriorated to such a degree the Linux desktop has become, to a huge degree, inaccessible to blind people (mostly due to issues with Wayland). I didn’t save those blogposts or statements to show in discussions like these, but the takeaway from all of them is that “It used to work for me many years ago, but if I want a system that respects me today I’m forced to use Mac”. But of course you’re also right, it’s slowly getting better! (Correct me if I’m wrong, not a native speaker: “being alienated” doesn’t inherently imply malicious intent of doing so, does it?)
Sorry, I was really pissed off yesterday evening by earlier comments in the chain implying it’s good to “filter out people” and got carried away. This one is completely on me.
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).
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.
Yeah, ten apps on the machine should be enough for anybody.
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.
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.
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.