Anything 5-10 years old or older. Chances are, it won’t work unless it’s a static binary. Linux has long had a policy of “F backwards compatibility” in the userspace, so you need to dig up the 5-10 year old libraries it needs to run. And for anything 32-bit, you also need to install the 32-bit versions of all your system libraries.
Acting like “old app won’t run” is exclusive to macOS is misleading.
Yes but most people aren’t doing this unless they are insane and finding these libraries is borderline impossible and I personally in my search have found a bunch of dead links for them. So no Linux isn’t backwards compatible to me and never will be backwards compatible because it fundamentally can’t be because even libc and it’s changes have broken stuff in the past with some Steam Linux native games I was trying to run.
Does updating from a non-LTS version of a OS what is no longer supported, to the current LTS count?
I didn’t realise it wasn’t LTS at the time, only when I wanted to update to the next LTS did I realise what I had done. Let me tell you, it wasn’t an easy fix, I had to write the StackOverflow answer myself.
Sure, but what is the point of the thread then? Of course a program will need the libraries it was linked against. The kernel has nothing to do with that really. The point was it is possible to run old binaries. Even a recent program will fail to run if its dependencies aren’t provided, that’s not an issue with older ones exclusively…
The point is, that under Windows you can take a very old program, sometimes even from the DOS era, and the chances are good, that it will run just fine. UT99 for example runs perfectly under Windows 11 despite being over 20 years older than the OS. That’s mainly because Windows ensures a relatively high degree of backwards compatibility.
Under Linux, running a five year old binary is almost impossible without 500 hacks. That is quite a different experience.
Anything 5-10 years old or older. Chances are, it won’t work unless it’s a static binary. Linux has long had a policy of “F backwards compatibility” in the userspace, so you need to dig up the 5-10 year old libraries it needs to run. And for anything 32-bit, you also need to install the 32-bit versions of all your system libraries.
Acting like “old app won’t run” is exclusive to macOS is misleading.
There’s a massive difference between saying “noooooo!!! That’s too old!!!” And saying “you don’t have the right libraries”
Also because it’s a dependency issue, won’t flatpaks fix it?
I got you fam /s
https://github.com/89luca89/distrobox
Yes but most people aren’t doing this unless they are insane and finding these libraries is borderline impossible and I personally in my search have found a bunch of dead links for them. So no Linux isn’t backwards compatible to me and never will be backwards compatible because it fundamentally can’t be because even libc and it’s changes have broken stuff in the past with some Steam Linux native games I was trying to run.
Does updating from a non-LTS version of a OS what is no longer supported, to the current LTS count?
I didn’t realise it wasn’t LTS at the time, only when I wanted to update to the next LTS did I realise what I had done. Let me tell you, it wasn’t an easy fix, I had to write the StackOverflow answer myself.
I ran UT2k4 in 2016 or so, it was dynamically linked but brought its libraries, I had to replace some IIRC but afterwards, it ran.
Dynamically linking libraries that ship with the executable is functionally identical to static linking in this case.
Sure, but what is the point of the thread then? Of course a program will need the libraries it was linked against. The kernel has nothing to do with that really. The point was it is possible to run old binaries. Even a recent program will fail to run if its dependencies aren’t provided, that’s not an issue with older ones exclusively…
The point is, that under Windows you can take a very old program, sometimes even from the DOS era, and the chances are good, that it will run just fine. UT99 for example runs perfectly under Windows 11 despite being over 20 years older than the OS. That’s mainly because Windows ensures a relatively high degree of backwards compatibility.
Under Linux, running a five year old binary is almost impossible without 500 hacks. That is quite a different experience.