Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. Try the same with some Windows apps and compare and contrast.
API == ABI for stability purposes, and the kernel isn't the problem, otherwise things like docker wouldn't meaningfully work at all. It's all the auxiliary libraries, much larger surface area.
The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions.
> Try the same with some Windows apps and compare and contrast.
Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't).
> It's all the auxiliary libraries, much larger surface area.
Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.
It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.)
That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.
This is where autotools helps: ./configure --static. There are also equivalents for CMake.
Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases.
Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically.
> because glibc cannot be statically linked
This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does.
> It's not as simple as "windows programs include their dependencies".
But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed.
> Windows has far better forward and backward compatibility than Linux
glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.
It's in drivers, third party kernel modules, libraries, etc.
But that doesn't make it any easier.
On desktoo GNU/Linux or GNU/NT we don't have easy stable environments, and the fight between dynamic and static linking is always won by static linking. In the GNU world, that ended with snap/flatpack/docker/rkt/containerd
I really wish userland devs would spend more time actually maintaining API/ABI stability, and less time reinventing wheels because they are not "perfect" (after whatever arbitrary marker for perfection they work with).
Stock Linux definitely has a stable userland API, though I imagine that third party driver vendors don't know how to do stable userland APIs.
> Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.
As for driver ABI compatibility, I know that almost all enterprise distributions maintain kABI compatibility for a particular release of their distribution (this is one of the selling points of such distributions). I believe there are also some community distributions with similar stability guarantees (for instance openSUSE Leap uses the same kernel as SUSE Linux Enterprise, so I would assume the same guarantee is provided).