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