In general, I'm a fan of statically linked binaries or shipping the libraries with the application, so I mostly agree with you. But I also can't deny there's ad

In general, I'm a fan of statically linked binaries or shipping the libraries with the application, so I mostly agree with you. But I also can't deny there's advantages to the shared-link approach as well. In short, there's upsides and downsides to both approaches and no perfect solution. In practice however, I rarely encounter issues, except for closed-source programs that don't ship their libraries. That, I think, is mostly the fault of the vendor and not the Linux system. Of course, as a user it doesn't really matter whose fault it is if your application doesn't work because you just want the damn thing to work. It does mean the problem (and solution) is mostly an educational one, rather than a technical one. You certainly can ship binary programs that should work for decades to come: the two core components (Linux kernel and GNU libc) take backwards compatibility pretty serious, more or less on equal level with Windows. You don't even need flatpack. A wrapper script with "LD_LIBRARY_PATH=. ./binary" gets you a long way (and still provides people the ability to use a system library if they want, so sort-of the best of both worlds).