> I don't think that's true. It's more like "programs written 20 years ago (against glibc 1.x) don't work on recent Linux anymore"
Technically Linux-the-kernel can run programms written 20 (and more) years just fine, it is the libraries that are the problem. However FWIW some libraries, like OpenGL, xlib and glibc do provide backwards compatibility - assuming no blatant abuse is done.
I made this test[0] in 2018 by compiling some binaries with a toolkit of mine in some ancient RedHat Linux from 1997 and they were working perfectly fine in 2018 Debian since it didn't rely on libraries that change their APIs/ABIs every time there is a new fashion. I haven't repeated it recently but i'm pretty sure a similar test with binaries from 1997 that only rely on libraries with stable ABIs will still work on my current openSUSE Tumbleweed installation, showing that more than two decades of backwards compatibility could be possible.
Technically Linux-the-kernel can run programms written 20 (and more) years just fine, it is the libraries that are the problem. However FWIW some libraries, like OpenGL, xlib and glibc do provide backwards compatibility - assuming no blatant abuse is done.
I made this test[0] in 2018 by compiling some binaries with a toolkit of mine in some ancient RedHat Linux from 1997 and they were working perfectly fine in 2018 Debian since it didn't rely on libraries that change their APIs/ABIs every time there is a new fashion. I haven't repeated it recently but i'm pretty sure a similar test with binaries from 1997 that only rely on libraries with stable ABIs will still work on my current openSUSE Tumbleweed installation, showing that more than two decades of backwards compatibility could be possible.
[0] https://i.imgur.com/YxGNB7h.png