Hacker News Reader

Comment by zekica | Hacker News Reader

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.

View on HN

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...

Functional package managers like Nix and Guix can reproduce an exact build of a program, including it's dependency tree (build time and runtime), and package that into a container, which can be shipped as an executable image (stripped down to just the neccesary runtime deps). Nix Flakes in particular allow you to define an entrypoint, making the build+run process nearly as painless as "docker run $x"

> 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.

Something that could have been avoided if static linking was more popular, the drivers would have been designed differently.

> 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.

isn't that why windows can run old applications though ? every game used to come bundled with their own copy of everything down to the C & C++ runtime (and that's why they still can run)

No, not really. Win32, the bit that you use to actually put a window on the screen, is a system library that is simply backwards compatible forever. You don't distribute Win32 with your applications. Go ahead and try to find a copy of USER32.DLL distributed with your old applications; you won't find it.

The hipsters these days go straight to WinUI. Microsoft's yet another half baked UI library.

The main reason Windows can still run stuff is because it has Visual Studio Redistributable packages at the OS Level. So got some software that needs VS's C++ symbols from 2008? Usually comes as part of the installation process, but you probably already have it installed.

Base system libraries like glibc, OpenGL, Vulkan, libasound, etc. all provide a stable userland ABI.

What doesn't work is relying on random other libraries to be present, but you will run into the same problem if you rely on whatever some other program dumped into system32 on windows. You also can't link against a newer glibc/etc. and then expect to run on older versions - that is not inherently different on Windows either but the SDK does let you target older versions from modern toolchains (whith limitations), something that GNU unfortunately does not care to provide so you have to make your own (or search for one).

Glibc, libasound and other key libraries have poor compatibility history, which can be seen from their sonames:

libc.so.6 libasound.so.2 libfreetype.so.6 libX11.so.6

Each glibc/ALSA soname bump can spell death to entire generation of binary software.

In theory, you can link libX11, openssl and other important libraries statically, but many developers don't do it, because of weird concerns about "security", "compatibility" etc.

Compare it to Windows, where libraries like kernel32, user32 and gdi32 remained stable for decades and statically linking to them is unnecessary by design.

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.

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.

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.

The year of the Linux desktop did not happen and will not happen, if we consider the actual GNU+systemd+curl+gstreamer+freetype+Wayland/Xorg+Gtk/Qt+.... as the desktop layer. None of those projects have shared goal of actually making a useful system with stable API / ABI. Moreover, there is already quite a bit competition inside like Qt vs GTK.

What made Android successful is Google seeing that mess and creating an entirely new operating system, from kernel to especially userspace. Android in a way turns Linux into a system that is much closer to a microkernel based OS. The binder IPC on the kernel side resembles the message passing systems of microkernels and almost all communication, except a couple of system stuff, passes through it. From allocating display buffers to "Share" buttons all of them uses this system. It has nothing to do with classical desktop system nor the Unix "way" of doing things, which is oversimplifying the system layer to the point of almost uselessness.

While the build system of AOSP and Android apps gives me shivers, the OS works beautifully and it can be continuously upgraded and be kept secure, if greedy SoC and device manufacturers released driver updates.

https://c.tenor.com/srlLdtb35fkAAAAC/starwars-anakin.gif

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

> 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.

Another Pyhric victory where Linux runs in a container WSL style and desktop is a browser.

I guess, but I am weirdly fine with this if the desktop can see everything it needs from the container.

Another proof that only POSIX matters.

We can use [anbox](https://anbox.io/).

> You'd hope libc wouldn't break.

glibc is quite good about ABI compatibility - not any worse than Win32.

X11 also has a stable protocol. Even with Wayland there is Xwayland for backwards compatibility.

OpenGL and Vulkan have stable ABIs.

Your program location doesn't matter - unless you are installed via the package manager (in which case the package specifies the location) you can load everything relative to the binary.

User config location is gained a new standard for where you should put things to not mess up the home directory but that does not break anything. Old programs can still write to ~/.yourfancydotfile.

Evenvironment variables only matter if you wrote your program for them to matter.

Preinstalled libraries are irrelevant - ship your own like you have to do on windows for anything that is not part of the base system.

Acceptable keyboars shortcuts and standard dialogs are integration concerns and not strictly needed. Not saying that you shouldn't provide DE-integration where that makes sense but that can be done on top of sane fallbacks. Also, there is now a cross-DE API for standard file dialogs: xdg-desktop-portals

.desktop files have been standardized for a long time so you should not have problems registering file types - it is of course up to the DE to manage the default and that is a good thing.

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.)

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.

X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically for just opening a file/folder open/save dialog). X11 itself doesn't provide that much beyond opening & managing windows (and the copy&paste mess it provides is, well, a mess.)

Sure, but the question wasn't "will a file dialog open at all" it was "will it open in a weird place". If the app was using gtk and you're running it in a chroot with period-appropriate gtk that gtk file open dialog will probably open just fine, and then it's a matter of if you bind mounted your homedir and /etc into the chroot so it'd know where to go. From there it'll open in approximately as weird (or un-weird) a place as it did in 2007. Like, this isn't a problem almost specifically because x11 isn't trying to do anything very clever here. There's no OpenFileDialog along with an OpenFileDialogEx and OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going. If your program had a file dialog then, it has one now. It's probably just ugly.

As for copy/paste, it is a bit of a mess but it's a mess that works pretty well for this kind of situation. If the copyer and paster windows are in the same x11 context and use the same (widely used) protocol over x11 window properties, they will be able to copy and paste with each other regardless of if they're running natively, in a chroot, in a vm, or on a remote machine.

Incidentally I really miss having the second "select/middle click" copy/paste context when I'm using windows or a mac. It's really frickin' useful and by far more useful than almost any other middle mouse button uses I've ever seen in any non-game. But then I also miss having normal copy/paste in the common linux gui terminal emulators so...

You can now provide a DE-agnostic way to get the "native" file dialogs via xdg-desktop-portal. Granted that is faily new.

> and the copy&paste mess it provides is, well, a mess.

Still much better than any windowing system that only has a single paste buffer.

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.)

Things are moving to wayland, but x11 is never going to go completely away. Xwayland provides an xserver that can be used within wayland.

Some of the things you listed as problems would be problems anyways in wayland, because they have to do with the fact that wayland doesn't, for example, give unrestricted access to every single program's image buffer from any program (for good reason).

> for good reason

For reasons that do not apply to all use cases like local applications that already have full access to ~/.

I don't really agree. There's a lot of information on my screen at any given moment that's not usefully represented on disk.

Even if they use Wayland, XWayland works flawlessly with X11 applications in my experience, and Plasma/GNOME/etc all load XWayland support by default.

> 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.

> 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)

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".

> 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.

Docker is saying chroot but differently. It doesn't help with the normie users.

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

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)

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).

Don't think that X11 is a great example since it has great backwards compatibility. Just about all userspace components are worse.

X11 has but does XWayland? Or desktops running on it like KDE and GNOME?

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...)

> 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.

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

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.

Reply on news.ycombinator.com