7 ms·

Linux has stable userland ABI. I managed to run a gui binary from Slackware 12 (from 2007) in a chroot and it worked completely fine. It didn't have modern them

by zekica 5y ago

Linux has stable userland ABI. I managed to run a gui binary from Slackware 12 (from 2007) in a chroot and it worked completely fine. It didn't have modern theming or HiDPI support but it worked fine. Windows apps running via wine and old linux apps running via chroot or any other container (AppImage, snap or Flatpak) all work. The problem is not having specific (major) versions of old libraries in the new OS. If you manage to install them, they will work - this is difficult in most distributions.

josefx 5y ago
Unless you depend on a central service like X11 where only one version runs on the whole system and newer implementations/replacements may intentionally break things. Last time I had to run some ancient software on Linux I just spun up a Virtual Box image with the Linux version it was released for (of course all the mirrors for that where offline by then too).
- donio 5y ago
  Don't think that X11 is a great example since it has great backwards compatibility. Just about all userspace components are worse.
  - josefx 5y ago
    X11 has but does XWayland? Or desktops running on it like KDE and GNOME?
salawat 5y ago
It's trivial if you compile from source and onow how to massage the linker!
- NavinF 5y ago
  Oh the linker needs a lot more than a massage; The linker wants full service. When a user needs to run a program, but the inconsiderate lazy dev only built, packaged, and tested the program on 24 ABIs (4 versions of 6 distros) rather than 25 ABIs like he should have, this is what the user wants to see: /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a && : /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gmain.c.o): In function `g_get_worker_context': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gmain.c:5848: undefined reference to `pthread_sigmask' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gmain.c:5853: undefined reference to `pthread_sigmask' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `match_info_new': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:588: undefined reference to `pcre_fullinfo' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_match_info_next': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:734: undefined reference to `pcre_exec' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `get_matched_substring_number': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1076: undefined reference to `pcre_get_stringnumber' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1079: undefined reference to `pcre_get_stringtable_entries' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_regex_unref': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1262: undefined reference to `pcre_free' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1264: undefined reference to `pcre_free' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_regex_new': Clear as mud. Of course you could use the buggy 16 month old version from the package repo.
spijdar 5y ago
Linux has a stable "userland ABI" only so far as the kernel interface stays (with very few exceptions) stable. This means, as you've said, you can run old applications, as long as you have entire copies of the rest of the userland to go with them. (One potential problem I can see with really old Linux userlands/games is old Mesa wanting the old user mode switching drivers from Linux, that are long removed. You'd need at least newer versions of Mesa, I think, which may be impossible to achieve due to dependency hell) This comes down to arguing semantics but I don't think this really constitutes a stable "userland ABI" in the sense it's used to describe Windows. Yes, you can use containers to effectively create independent copies of old userlands and run your code in them. But you can't just run old software without matching copies of the specific libraries it expects, which themselves have a rat's nest of dependencies, necessitating having ~N complete copies of Linux userlands floating around for N programs. One way we could circumvent this problem is static linking, since they the only interface would be the kernel one, that is mostly backwards compatible. That has its own problems (e.g. inability to patch libraries independently), but is probably better than just keeping copies of the shared object files in their entirety in containers...
- legalcorrection 5y ago
  The biggest problem with this is that no one is maintaining all of those old userlands, so when you use an old userland, you are reintroducing tons of known and fixed (but not backported) bugs, including many serious security issues.
- my123 5y ago
  > One way we could circumvent this problem is static linking Out of the question for any app using the GPU. As that means statically linking with a given GPU user-mode driver version, not being able to get updates or support for any future GPU.
  - deleted 5y ago
    [deleted]
  - Shorel 5y ago
    Something that could have been avoided if static linking was more popular, the drivers would have been designed differently.
dzaima 5y ago
The kernel ABI barely matters for most things. You'd hope libc wouldn't break. What's important is window managing APIs, graphics APIs, file system structure (your program location, user config location), environment variables, preinstalled binaries, and many smaller things (acceptable keyboard shortcuts, registering to open a specific file type, opening a native "open/save file/folder" dialog, etc). Those are a lot less stable and may require using various random libraries or writing code for specific WMs/desktops. It's not fun.
- jart 5y ago
  The tragedy of the Linux desktop is that its CLI is superb and Chrome works really really well. The year of the Linux desktop happened with Android but sadly all that successful GUI stuff that Google did was never able to percolate back into the FOSS world as a WIN32 alternative. It's a sad state of affairs for Linux desktop app developers, because they've had the wind taken away from them on all possible angles. The only Linux desktop app I can personally remember using in the past year (aside from the terminal and Chrome) would probably be kcachegrind. I wish that we as a community could focus more on building outstanding TUIs (e.g. linux perf, gdb --tui, emacs) since most Linux installs are headless and it makes an app more functionally useful it can be used in a terminal via ssh.
  - pjmlp 5y ago
    The CLI is just like any other UNIX/POSIX, and as far as Android is concerned, Linux does not exist for userspace coming from Play Store, including apps written with NDK/AGK[0]. Only OEMs have the ability to directly use Linux, doing so from userspace means using what Google considers as being private APIs. Not to mention that Google could at any moment change it by Zircon, if they could so feel inclined. So Android is hardly the best that Linux could make it as desktop. [0] - Native Development Kit/Android Game Kit
    - unfocussed_mike 5y ago
      > So Android is hardly the best that Linux could make it as desktop. Chrome OS Flex might be interesting when it does, eventually, support the linux environments.
Spivak 5y ago
Linux has a stable ABI but only if you don’t include all userspace libs isn’t really that much of a guarantee. Sure it means you can run ancient distros on newer kernels provided they don’t depend too much on the specifics of X11 or OpenGL but that’s not great unless we’re happy with “oh this software works on Ubuntu 14.04 so we’ll just ship all of a Ubuntu 14.04 userspace with the app.” (looking at you Steam Runtime)
Wowfunhappy 5y ago
Does this work seamlessly alongside other apps on your machine? By which I mean: • Does copy-and-paste work? • Does the file picker dialog default to a logical location, or does it start out in some weird directory? • If you click on a URL, does it open in your default web browser? • Can you screen-share the application from Zoom? I'd also be curious whether there's a performance impact beyond disk usage. Basically, I'm wondering if the UX is substantially better than using a VM. VMs are great for backwards compatibility, but the UX sucks, because apps don't exist in a vacuum. If chroot does work seamlessly for GUI apps, that strikes me as a perfectly reasonable backwards-compatibility solution, and better than what Windows does in some ways. Heck, distros should consider automating this when users try to launch old software. Edit: I also wonder how much of this problem would go away if Linux devs were willing to ship statically-compiled binaries. (Or mostly-statically-compiled binaries, since I know including e.g. gpu libraries is problematic.)
- stormbrew 5y ago
  Assuming the GP was using x11, then yeah it's very likely almost all of those things worked fine (depending on how they structured the chroot to include their homedir). The only one that probably doesn't is the URL->browser one, just because the chroot probably wouldn't have access to run the browser directly, even if the right MIME-type/xdg config files were present in the chroot. X11 as a protocol if anything is probably more backwards compatible than windows has ever been, and most of the extensions that enable the things you're asking about have been available for decades. ABI and libc aside xclock from 1996 probably still works on ubuntu 22.04. > Heck, distros should consider automating this when users try to launch old apps, if at all possible. This is more or less what snap and flatpak are trying to do.
  - Wowfunhappy 5y ago
    Isn't the Linux world (slowly) moving away from x11, though? (If you can't tell, I'm not a Linux user, I was many years ago and I'd like to go back some day. These types of library compatibility issues are a major part of what's keeping me away—I want to know that most apps from 15 years ago will still work, and most of the apps I have today will still work in another 15 years.)
est31 5y ago
> Linux has stable userland ABI. I managed to run a gui binary from Slackware 12 (from 2007) in a chroot The key word is chroot here, and managed. Sure, a technology enthusiast might manage to run binaries from 2007 on a chroot, as in, after having invested hours of work to find an outdated copy of an entire distro and then wasting gigabytes of hard drive space on making it work. But this doesn't help the average linux gamer who just wants their downloaded game from 5 years ago to still work. Nor does it help the ISV vendor who wants to sell GUI software that can be used on modern linuxes as well.
- jcelerier 5y ago
  > after having invested hours of work to find an outdated copy of an entire distro you mean docker run -it debian/eol:potato /bin/bash ? (debian potato was released in 2000 for the curious)
  - okanat 5y ago
    Docker is saying chroot but differently. It doesn't help with the normie users.
    - jcelerier 5y ago
      sure but it's not hours either - one could reasonably whip a small GUI with dialog box like window's compatibility one where you can run a particular software in whatever distro of yore
  - kelnos 5y ago
    I think you're missing the point. This is all still a terrible user experience for the stated consumer: a relatively non-technical person who found an old game binary and just wants to run it. The only acceptable user experience for this sort of thing is "double click on the icon and it just runs".
    - jcelerier 5y ago
      > The only acceptable user experience for this sort of thing is "double click on the icon and it just runs". maybe, but absolutely no OS provides this as of today.
zajio1am 5y ago
> The problem is not having specific (major) versions of old libraries in the new OS. If you manage to install them, they will work - this is difficult in most distributions. My experience was that often it is the opposite problem. Games came with bundled libraries of old versions (e.g. libSDL) that do not work properly with the rest of the OS. When they are forced to use system versions of libraries, they started to work.
rob_c 5y ago
Yeah have to agree there is always a vocal group of non devs who hate when they have to install a 3rd party compat library to run something from 10 years ago. To them this means it's broken when in reality this is bloat for the other 90% of the distro userbase so isn't in a default install for good reason. (Not to mention some clunky apps dropping back to old support when they see qt3 even when they support say qt5 in their UI...)

by zekica 5y ago

josefx 5y ago

Unless you depend on a central service like X11 where only one version runs on the whole system and newer implementations/replacements may intentionally break things. Last time I had to run some ancient software on Linux I just spun up a Virtual Box image with the Linux version it was released for (of course all the mirrors for that where offline by then too).

donio 5y ago
Don't think that X11 is a great example since it has great backwards compatibility. Just about all userspace components are worse.
- josefx 5y ago
  X11 has but does XWayland? Or desktops running on it like KDE and GNOME?

salawat 5y ago

It's trivial if you compile from source and onow how to massage the linker!

NavinF 5y ago
Oh the linker needs a lot more than a massage; The linker wants full service. When a user needs to run a program, but the inconsiderate lazy dev only built, packaged, and tested the program on 24 ABIs (4 versions of 6 distros) rather than 25 ABIs like he should have, this is what the user wants to see: /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a && : /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gmain.c.o): In function `g_get_worker_context': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gmain.c:5848: undefined reference to `pthread_sigmask' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gmain.c:5853: undefined reference to `pthread_sigmask' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `match_info_new': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:588: undefined reference to `pcre_fullinfo' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_match_info_next': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:734: undefined reference to `pcre_exec' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `get_matched_substring_number': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1076: undefined reference to `pcre_get_stringnumber' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1079: undefined reference to `pcre_get_stringtable_entries' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_regex_unref': /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1262: undefined reference to `pcre_free' /data/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1264: undefined reference to `pcre_free' /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function `g_regex_new': Clear as mud. Of course you could use the buggy 16 month old version from the package repo.

spijdar 5y ago

Linux has a stable "userland ABI" only so far as the kernel interface stays (with very few exceptions) stable. This means, as you've said, you can run old applications, as long as you have entire copies of the rest of the userland to go with them. (One potential problem I can see with really old Linux userlands/games is old Mesa wanting the old user mode switching drivers from Linux, that are long removed. You'd need at least newer versions of Mesa, I think, which may be impossible to achieve due to dependency hell) This comes down to arguing semantics but I don't think this really constitutes a stable "userland ABI" in the sense it's used to describe Windows. Yes, you can use containers to effectively create independent copies of old userlands and run your code in them. But you can't just run old software without matching copies of the specific libraries it expects, which themselves have a rat's nest of dependencies, necessitating having ~N complete copies of Linux userlands floating around for N programs. One way we could circumvent this problem is static linking, since they the only interface would be the kernel one, that is mostly backwards compatible. That has its own problems (e.g. inability to patch libraries independently), but is probably better than just keeping copies of the shared object files in their entirety in containers...

legalcorrection 5y ago
The biggest problem with this is that no one is maintaining all of those old userlands, so when you use an old userland, you are reintroducing tons of known and fixed (but not backported) bugs, including many serious security issues.
my123 5y ago
> One way we could circumvent this problem is static linking Out of the question for any app using the GPU. As that means statically linking with a given GPU user-mode driver version, not being able to get updates or support for any future GPU.
- deleted 5y ago
  [deleted]
- Shorel 5y ago
  Something that could have been avoided if static linking was more popular, the drivers would have been designed differently.

dzaima 5y ago

The kernel ABI barely matters for most things. You'd hope libc wouldn't break. What's important is window managing APIs, graphics APIs, file system structure (your program location, user config location), environment variables, preinstalled binaries, and many smaller things (acceptable keyboard shortcuts, registering to open a specific file type, opening a native "open/save file/folder" dialog, etc). Those are a lot less stable and may require using various random libraries or writing code for specific WMs/desktops. It's not fun.

jart 5y ago
The tragedy of the Linux desktop is that its CLI is superb and Chrome works really really well. The year of the Linux desktop happened with Android but sadly all that successful GUI stuff that Google did was never able to percolate back into the FOSS world as a WIN32 alternative. It's a sad state of affairs for Linux desktop app developers, because they've had the wind taken away from them on all possible angles. The only Linux desktop app I can personally remember using in the past year (aside from the terminal and Chrome) would probably be kcachegrind. I wish that we as a community could focus more on building outstanding TUIs (e.g. linux perf, gdb --tui, emacs) since most Linux installs are headless and it makes an app more functionally useful it can be used in a terminal via ssh.
- pjmlp 5y ago
  The CLI is just like any other UNIX/POSIX, and as far as Android is concerned, Linux does not exist for userspace coming from Play Store, including apps written with NDK/AGK[0]. Only OEMs have the ability to directly use Linux, doing so from userspace means using what Google considers as being private APIs. Not to mention that Google could at any moment change it by Zircon, if they could so feel inclined. So Android is hardly the best that Linux could make it as desktop. [0] - Native Development Kit/Android Game Kit
  - unfocussed_mike 5y ago
    > So Android is hardly the best that Linux could make it as desktop. Chrome OS Flex might be interesting when it does, eventually, support the linux environments.

Spivak 5y ago

Linux has a stable ABI but only if you don’t include all userspace libs isn’t really that much of a guarantee. Sure it means you can run ancient distros on newer kernels provided they don’t depend too much on the specifics of X11 or OpenGL but that’s not great unless we’re happy with “oh this software works on Ubuntu 14.04 so we’ll just ship all of a Ubuntu 14.04 userspace with the app.” (looking at you Steam Runtime)

Wowfunhappy 5y ago

Does this work seamlessly alongside other apps on your machine? By which I mean: • Does copy-and-paste work? • Does the file picker dialog default to a logical location, or does it start out in some weird directory? • If you click on a URL, does it open in your default web browser? • Can you screen-share the application from Zoom? I'd also be curious whether there's a performance impact beyond disk usage. Basically, I'm wondering if the UX is substantially better than using a VM. VMs are great for backwards compatibility, but the UX sucks, because apps don't exist in a vacuum. If chroot does work seamlessly for GUI apps, that strikes me as a perfectly reasonable backwards-compatibility solution, and better than what Windows does in some ways. Heck, distros should consider automating this when users try to launch old software. Edit: I also wonder how much of this problem would go away if Linux devs were willing to ship statically-compiled binaries. (Or mostly-statically-compiled binaries, since I know including e.g. gpu libraries is problematic.)

stormbrew 5y ago
Assuming the GP was using x11, then yeah it's very likely almost all of those things worked fine (depending on how they structured the chroot to include their homedir). The only one that probably doesn't is the URL->browser one, just because the chroot probably wouldn't have access to run the browser directly, even if the right MIME-type/xdg config files were present in the chroot. X11 as a protocol if anything is probably more backwards compatible than windows has ever been, and most of the extensions that enable the things you're asking about have been available for decades. ABI and libc aside xclock from 1996 probably still works on ubuntu 22.04. > Heck, distros should consider automating this when users try to launch old apps, if at all possible. This is more or less what snap and flatpak are trying to do.
- Wowfunhappy 5y ago
  Isn't the Linux world (slowly) moving away from x11, though? (If you can't tell, I'm not a Linux user, I was many years ago and I'd like to go back some day. These types of library compatibility issues are a major part of what's keeping me away—I want to know that most apps from 15 years ago will still work, and most of the apps I have today will still work in another 15 years.)

est31 5y ago

> Linux has stable userland ABI. I managed to run a gui binary from Slackware 12 (from 2007) in a chroot The key word is chroot here, and managed. Sure, a technology enthusiast might manage to run binaries from 2007 on a chroot, as in, after having invested hours of work to find an outdated copy of an entire distro and then wasting gigabytes of hard drive space on making it work. But this doesn't help the average linux gamer who just wants their downloaded game from 5 years ago to still work. Nor does it help the ISV vendor who wants to sell GUI software that can be used on modern linuxes as well.

jcelerier 5y ago
> after having invested hours of work to find an outdated copy of an entire distro you mean docker run -it debian/eol:potato /bin/bash ? (debian potato was released in 2000 for the curious)
- okanat 5y ago
  Docker is saying chroot but differently. It doesn't help with the normie users.
  - jcelerier 5y ago
    sure but it's not hours either - one could reasonably whip a small GUI with dialog box like window's compatibility one where you can run a particular software in whatever distro of yore
- kelnos 5y ago
  I think you're missing the point. This is all still a terrible user experience for the stated consumer: a relatively non-technical person who found an old game binary and just wants to run it. The only acceptable user experience for this sort of thing is "double click on the icon and it just runs".
  - jcelerier 5y ago
    > The only acceptable user experience for this sort of thing is "double click on the icon and it just runs". maybe, but absolutely no OS provides this as of today.

zajio1am 5y ago

> The problem is not having specific (major) versions of old libraries in the new OS. If you manage to install them, they will work - this is difficult in most distributions. My experience was that often it is the opposite problem. Games came with bundled libraries of old versions (e.g. libSDL) that do not work properly with the rest of the OS. When they are forced to use system versions of libraries, they started to work.

rob_c 5y ago

Yeah have to agree there is always a vocal group of non devs who hate when they have to install a 3rd party compat library to run something from 10 years ago. To them this means it's broken when in reality this is bloat for the other 90% of the distro userbase so isn't in a default install for good reason. (Not to mention some clunky apps dropping back to old support when they see qt3 even when they support say qt5 in their UI...)