[brigade]

What you mean is: the only stable ABI in Linux is the Linux kernel’s itself.

Windows is the opposite: the only stable ABI is the dynamically linked user space ABI. So yes, it’s perfectly possible to have a stable dynamic ABI across a dynamically linked boundary.

[imtringued]

There used to be operating systems where the only stable interface was glibc.

[memefrog]

>Windows is the opposite: the only stable ABI is the dynamically linked user space ABI.

... to the kernel. So not the opposite at all. In fact exactly the same.

[brigade]

No. The userspace/kernel boundary is explicitly not stable on Windows, and binaries that try to use that interface have broken when it changed.

[Macha]

This is true for basically ever OS other than Linux, as the Golang developers learned the hard way on macOS and BSD.

[memefrog]

which is why the Linux approach is superior: it has a stable ABI that is language-agnostic.

[memefrog]

That is completely irrelevant to the discussion. The point is that both systems have very stable ABIs. Windows has a somewhat higher-level stable ABI, but as a result it is a much wider surface to keep compatible, it breaks much more often, it requires a lot more hacks to keep it stable over time (program-specific hacks kept around for decades), etc.

This is the point of difference: the layer at which each is stable. NOT whether Linux is stable.

[brigade]

The nature of stability literally is the discussion; I replied to a post that blamed the lack of a Linux equivalent to Win32 on dynamic linking. That the stable ABI you get on Linux requires you to bundle literally every dependency you have as if distros don't exist... And then still have issues because the kernel ABIs for graphics are entirely GPU dependent...

The two approaches are definitively not the same (as you claim), and the significant shortcomings of Linux's approach are why Win32 is becoming the ABI devs target even on Linux.

[memefrog]

>That the stable ABI you get on Linux requires you to bundle literally every dependency you have as if distros don't exist...

This is not true. If your target platform is a distribution then you can assume that distribution's guarantees hold true.

What you cannot do is target "GNU/Linux" broadly and assume every glibc-based system running on top of the Linux kernel has all the libraries you want to depend on.

Pick a platform and target it. That can be the kernel. That can be glibc+the kernel (hey look GNU/Linux really is useful terminology), that can be RHEL9 or it can be Debian xyz. But don't pick "Linux" then make assumptions about userspace.