except windows binaries are actually forward compatible.
even with the most popular distros, for example if you tried to take a typical gui program from say, ubuntu 22, and run it on ubuntu 24, it won’t work. even worse for other distros.
However this bit from the readme is hilariously on brand for Linux:
"To use alien, you will need several other programs. Alien is a perl
program, and requires perl version 5.004 or greater. If you use slackware,
make sure you get perl 5.004, the perl 5.003 in slackware does not work
with alien!
To convert packages to or from rpms, you need the Red Hat Package Manager;
get it from Red Hat’s ftp site. If your distribution (eg, Red Hat)
provides a rpm-build package, you will need it as well to generate rpms.
If you want to convert packages into debian packages, you will need the
dpkg, dpkg-dev, and debhelper (version 3 or above) packages, which are
available on http://packages.debian.org"
Seriously, give me some examples. I’m genuinely curious because I’ve run into this problem like… once, ten years ago. Twice, if you count trying to run Heroes of Might and Magic III for Linux that came out in like… 1999, and I eventually got that to work too (I needed an emulator) and I’ve been an almost exclusive Linux user since 2001.
I said disingenuous because my lived experience is like “wtf is this guy doing wrong?” and so you REALLY come across like you’re just trashing Linux and talking out of your ass.
I’m not trying to be insulting, just giving you feedback about how you’re coming across.
Well first we need to establish what you would accept as proof… what counts as not being forward compatible to you exactly? For example system libraries such as libpng, openssl or ffmpeg change versions and/or APIs between major distro releases, this inherently makes the old binaries no longer compatible by default. Is that such scenario acceptable to you as proof? Because I can list countless examples of those even just with one library being the issue, and there’s so many more that fail with multiple.
I’m not trying to trash Linux or act like I don’t know what I’m talking about, I just disagree that most older programs work without any issues, especially GUI programs that rely on ever-changing system library versions, for the reasons I stated.
Give me an example or two of a GUI program that you’d want to run, that doesn’t have a maintained version that will run fine in a modern environment, that you’re actually frustrated because you can’t run it.
We can bitch about how dependency systems work all day. I want to try to install something with a sane use case and see what we’re on about, since this is literally a scenario I have barely run into. I gather that for me to run into it, I would have to practically go looking for it. Which to me, sounds like a very specific problem for a very specific subset of users, not a general problem worth paint brushing the entire ecosystem with.
I don’t agree with the prerequisite of “doesn’t have a maintained version” because I don’t feel like that makes a difference with the premise of specifically running older software, whether it has a new version available or not.
But anyways… I will try to adhere to that anyways, and use Ubuntu as an example as that’s what I use.
7yuv: This and every Qt4 app for example no longer runs because Ubuntu 20.04 and above (and probably many other distros) does not provide it anymore. 7yuv is still available for download, but has not been updated, and does not run on my current 22.04 box.
Dia: Same story here. No longer developed. The remaining binary deb package was built for Ubuntu 12.04 and no longer runs due to a dependency on libpng12 (the current version is 16). Yes I could possibly recompile from source if the API hasn’t changed, but the discussion was specifically about running older binaries.
Got 7yuv running on Linux Mint in under 15 minutes. If you consider using Docker to be cheating, consider me a cheater, but I stand by my statement that this is a niche problem affecting a niche group of users, there are even easy solutions.
I don’t think it can even be called cheating because the discussion was about forward compatibility. Using a container to house old libraries is something completely different in my opinion and I think it defeats the whole point of the word “compatibility” in my argument. Many users would not know how to do this nor want to. Where do you draw the line? CPU emulation?
We can disagree on this and that’s fine. I just still don’t consider it “highly disingenuous”, but maybe a difference of opinion.
except windows binaries are actually forward compatible.
even with the most popular distros, for example if you tried to take a typical gui program from say, ubuntu 22, and run it on ubuntu 24, it won’t work. even worse for other distros.
Also Linux’s package ecosystem are not cross compatible.
https://blog.hiler.eu/win32-the-only-stable-abi/
Bro do you even alien?
I didn’t know about alien, that is pretty cool.
However this bit from the readme is hilariously on brand for Linux:
"To use alien, you will need several other programs. Alien is a perl program, and requires perl version 5.004 or greater. If you use slackware, make sure you get perl 5.004, the perl 5.003 in slackware does not work with alien!
To convert packages to or from rpms, you need the Red Hat Package Manager; get it from Red Hat’s ftp site. If your distribution (eg, Red Hat) provides a rpm-build package, you will need it as well to generate rpms.
If you want to convert packages into debian packages, you will need the dpkg, dpkg-dev, and debhelper (version 3 or above) packages, which are available on http://packages.debian.org"
Highly disingenuous comment. I run older and newer software side by side in Linux all the time. It mostly just works.
Are you using snap or something?
Nope, but for as many programs that you claim still work, I can show you even more that don’t. I wouldn’t consider that disingenuous.
Seriously, give me some examples. I’m genuinely curious because I’ve run into this problem like… once, ten years ago. Twice, if you count trying to run Heroes of Might and Magic III for Linux that came out in like… 1999, and I eventually got that to work too (I needed an emulator) and I’ve been an almost exclusive Linux user since 2001.
I said disingenuous because my lived experience is like “wtf is this guy doing wrong?” and so you REALLY come across like you’re just trashing Linux and talking out of your ass.
I’m not trying to be insulting, just giving you feedback about how you’re coming across.
Well first we need to establish what you would accept as proof… what counts as not being forward compatible to you exactly? For example system libraries such as libpng, openssl or ffmpeg change versions and/or APIs between major distro releases, this inherently makes the old binaries no longer compatible by default. Is that such scenario acceptable to you as proof? Because I can list countless examples of those even just with one library being the issue, and there’s so many more that fail with multiple.
I’m not trying to trash Linux or act like I don’t know what I’m talking about, I just disagree that most older programs work without any issues, especially GUI programs that rely on ever-changing system library versions, for the reasons I stated.
Give me an example or two of a GUI program that you’d want to run, that doesn’t have a maintained version that will run fine in a modern environment, that you’re actually frustrated because you can’t run it.
We can bitch about how dependency systems work all day. I want to try to install something with a sane use case and see what we’re on about, since this is literally a scenario I have barely run into. I gather that for me to run into it, I would have to practically go looking for it. Which to me, sounds like a very specific problem for a very specific subset of users, not a general problem worth paint brushing the entire ecosystem with.
I don’t agree with the prerequisite of “doesn’t have a maintained version” because I don’t feel like that makes a difference with the premise of specifically running older software, whether it has a new version available or not.
But anyways… I will try to adhere to that anyways, and use Ubuntu as an example as that’s what I use.
7yuv: This and every Qt4 app for example no longer runs because Ubuntu 20.04 and above (and probably many other distros) does not provide it anymore. 7yuv is still available for download, but has not been updated, and does not run on my current 22.04 box.
Dia: Same story here. No longer developed. The remaining binary deb package was built for Ubuntu 12.04 and no longer runs due to a dependency on libpng12 (the current version is 16). Yes I could possibly recompile from source if the API hasn’t changed, but the discussion was specifically about running older binaries.
Got 7yuv running on Linux Mint in under 15 minutes. If you consider using Docker to be cheating, consider me a cheater, but I stand by my statement that this is a niche problem affecting a niche group of users, there are even easy solutions.
I don’t think it can even be called cheating because the discussion was about forward compatibility. Using a container to house old libraries is something completely different in my opinion and I think it defeats the whole point of the word “compatibility” in my argument. Many users would not know how to do this nor want to. Where do you draw the line? CPU emulation?
We can disagree on this and that’s fine. I just still don’t consider it “highly disingenuous”, but maybe a difference of opinion.