Define old binary. The a.out and elf format haven’t changed in a very long time. If you mean something from an old system with unmet dependencies, it will run, but it will crash and warn you that some library isn’t found. It will still run up until that point tho.
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.
I can’t personally run Kobo Desktop anymore on Linux because proprietary devs are so used to Windows. Running things for literal decades that; why update their software or maintain it for longer than the couple of years when it was released if even that?
Like Linux is inherently constantly evolving and changing without any regards to how software developers feel. When using libraries that will change and break shit even with flatpaks, app images and snaps if they don’t maintain their software.
So using this argument is completely missing the point entirely when so much shit is broken on Linux because of it. Despite said software being able to run up until they throw a library error at your ass.
I mean, there is nothing stopping you from installing whatever version of the library that is required in tandem with the latest version. You could even put it somewhere other then a standard library location and start executing your binary with
LD=/my/old/library ./myoodbinary
and have it dynamically loaded at runtime.
The only time this doesn’t work is when it is something in the kernel that breaks the binary… But you can run an older kernel that has back ported fixed.
I get where you are coming from with proprietary binarys that the devs have abandon. But to me that makes all the more reason not to run that software in the first place.
Edit: also the kobo desktop Windows app runs under wine I think…
It… sorta runs. It’s a pretty badly designed program on its own (I think it runs some web stuff, but its not electron). It looks terrible on wine, some menus are broken, syncing doesn’t work, etc. In the end I just installed it on windows (which I have for VR) and then literally never used it again (calibre-web is great)
You’ll need a library that your distro doesn’t have up to date so you had to edit your apt list and then that library won’t load because it needs some other library that didn’t get updated to work with your architecture for some reason so you have to compile it yourself
The lack of binary compatibility is one of many things holding Linux back from mainstream adoption. Some say this is a good thing, but the reality is that not everything is open-source.
I was able to run the binary from a project I made in engineering school 10 years ago on a recent Ubuntu system, and all I had to do was make the freeglut library available.
Try running an old binary on Linux.
Define old binary. The a.out and elf format haven’t changed in a very long time. If you mean something from an old system with unmet dependencies, it will run, but it will crash and warn you that some library isn’t found. It will still run up until that point tho.
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.
I can’t personally run Kobo Desktop anymore on Linux because proprietary devs are so used to Windows. Running things for literal decades that; why update their software or maintain it for longer than the couple of years when it was released if even that?
Like Linux is inherently constantly evolving and changing without any regards to how software developers feel. When using libraries that will change and break shit even with flatpaks, app images and snaps if they don’t maintain their software.
So using this argument is completely missing the point entirely when so much shit is broken on Linux because of it. Despite said software being able to run up until they throw a library error at your ass.
I mean, there is nothing stopping you from installing whatever version of the library that is required in tandem with the latest version. You could even put it somewhere other then a standard library location and start executing your binary with
and have it dynamically loaded at runtime.
The only time this doesn’t work is when it is something in the kernel that breaks the binary… But you can run an older kernel that has back ported fixed.
I get where you are coming from with proprietary binarys that the devs have abandon. But to me that makes all the more reason not to run that software in the first place.
Edit: also the kobo desktop Windows app runs under wine I think…
It… sorta runs. It’s a pretty badly designed program on its own (I think it runs some web stuff, but its not electron). It looks terrible on wine, some menus are broken, syncing doesn’t work, etc. In the end I just installed it on windows (which I have for VR) and then literally never used it again (calibre-web is great)
Try running a new binary on Linux
You’ll need a library that your distro doesn’t have up to date so you had to edit your apt list and then that library won’t load because it needs some other library that didn’t get updated to work with your architecture for some reason so you have to compile it yourself
The lack of binary compatibility is one of many things holding Linux back from mainstream adoption. Some say this is a good thing, but the reality is that not everything is open-source.
Try a rolling release distro
Appimages solve for this, but are underutilized
I was able to run the binary from a project I made in engineering school 10 years ago on a recent Ubuntu system, and all I had to do was make the freeglut library available.
Do I need to if I can recompile?
Not everything is open-source.