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 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.
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 removed 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.
I think making hay out of this problem when it’s a niche case nothing burger, especially in a thread full of linux hate, is… Call it what ever you want but…
As I said earlier, I wasn’t trying to be insulting, you were coming across in a certain way in the context you were posting in.
Linux has always been a DIY operating system, for very good reason. The compatibility decisions you’re talking about were made for very good reasons. There’s an easy solution, anyone having this problem (SUPER rare for most users) can reach out and use.
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 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.
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 removed 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.
I think making hay out of this problem when it’s a niche case nothing burger, especially in a thread full of linux hate, is… Call it what ever you want but…
As I said earlier, I wasn’t trying to be insulting, you were coming across in a certain way in the context you were posting in.
Linux has always been a DIY operating system, for very good reason. The compatibility decisions you’re talking about were made for very good reasons. There’s an easy solution, anyone having this problem (SUPER rare for most users) can reach out and use.