[dTal]

> In Linux distros, every binary is compiled against very specific library headers such as the kernel itself, Glibc and many others. Whenever one of those change, all binaries must be recompiled to run.

This is wrong. Only kernel modules are compiled against kernel headers, and for userland programs the kernel is binary-compatible since ever.

Which is not to say that random binaries run bare on random systems, but this is a cultural rather than a technical problem (package managers insisting on having only one version of libraries, ignorance of the soname system). But with enough effort you can always get binaries to run on a system, provided you can get ahold of the libraries it expects, up to and including glibc.

>Which is why having source code available is so important

Back to front. The reason for the current situation is it's expected that the source code is available, so there's no incentive to provide stability for binaries. Why bother? It's gonna be recompiled soon anyway.

[readittwice]

Exactly. Linux keeps its ABI stable and is committed to not break userspace. Just bundling your app with all needed libraries should allow you to run your app on any distro. There are only two requirements: same machine architecture (e.g. x86_64) and the kernel should support all features used in the app. That's why Go's statically linked binaries don't break on Linux but e.g. on Mac.

I am quite excited about flatpak, should be quite useful for shipping applications to a wide variety of distro with a single binary.

[readittwice]

I need to add that even glibc is also quite stable and backwards compatible: https://abi-laboratory.pro/tracker/timeline/glibc/.

That's why some projects deliberately build their software on very old distros, since the software then works from this version on.

[pritambaral]

> glibc is also quite stable and backwards compatible

But not forwards compatible. A binary linked dynamically against with a newer glibc wouldn't run with an older glibc.