[tredre3]

> My understanding is that the userspace interface is extremely stable.

Assuming you compile a static binary that doesn't even rely on libc, then yes, something compiled 20 years ago will still run.

But in the real world you have to recompile your software constantly due to breakage in dependencies (including glibc). And a binary won't work cross-distros without adding efforts despite running the same kernel (sure, that part isn't the kernel's fault).

It's often memed that the most stable interface on Linux is win32 (via wine), and that meme isn't entirely off-base.

[Karellen]

I thought that unless you're relying on buggy behaviour, or other implementation-specific details which are explicitly and prominently documented as unsupported and/or subject to change[0], any binary compiled for Linux libc6/glibc2 (released in Jan '97, available in e.g. Debian "Hamm" in July '98) should still run with the most recent glibc today.[1] Is that not right?

[0] e.g. if your app has a use-after-free bug which happened to work 20 years ago, it may not work any more. Although SimCity famously had a bug like this on Windows, and Microsoft put in a SimCity-specific "shim" to ensure it would continue working when they changed Windows' allocator, if your app is not as popular as SimCity was then it probably won't be as lucky, even on actual Windows.

[1] for the same architecture, obviously. Your i386 app won't run with an s390x or amd64 glibc.