Assuming you are talking about OS kernel API, what if you static link your libc? My understanding is that the linux kernel API famously does not change [0].
Linux does not have a stable userland ABI/API, it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user.
The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps).
Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical...)
Your link is about glibc, not libc in general. For example musl is perfectly fine to link statically to.
I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace".
> it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user.
But that would be the same thing on windows. If you dynamically link your executable to an old version of libcurl and run your executable on a windows with a newer version containing a breaking change, you'll be in trouble, whatever your OS.
> The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps).
Flatpak and Docker solves many other problems than kernel API. Actually, it does not solve this problem at all if you think about it because these technologies do not insulate you from the kernel (contrary to a VM).
> Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical...)
Statically linking glibc. You can perfectly statically link with any other libc. You can even code without a libc (see zig).
I think you interpreted Linus wrong. When he says "we do not break userspace" he is talking about the Kernel APIs that are exposed to the Userland.
Userland APIs would be stuff like glibc, which has a terrible track record in regards to API breakage.
I think I correctly interpreted Linus when he talked about the kernel API/ABI facing the user (developer of application).
A lot of trouble you are going to get maintaining builds are due to poor tooling, not linux.
But we are getting into semantics here. At the end of the day, I think that if you are careful with what you are doing and think a little before choosing your tools and writing code, you should get very good mileage out of your linux binaries.
I don't know enough about windows to comment on its stability but I very much doubt I could just slide my original Quake CD or 3DS max 4 install into Windows 10. But I might be wrong!
Most of the time I can run a program from the 1990s on Windows 11 just fine, you can't say the same for Linux.
The only incompatibility in Windows that happens frequently is if you try to run a program written for a newer Windows version in an older version. That will likely fail because forwards compatiblity isn't a priority. But with regards to backwards compatiblity, Microsoft goes to herculean efforts to make sure Windows programs written several decades ago will work today.
Windows programs ship with all their necessary libraries and/or link against the Microsoft c++ resist packages and you can have many different versions installed. Your MSI installer has to install the libcurl.3.dll instead of it being shared with other programs.
Docker and Flatpak fix the userland part the kernel part is already stable by "definition". Stuff may still break overtime but no more than it does on MacOS and Window. It's not broken by design anymore.
Python’s “manylinux” binary target is a good example on how to do that. We’re currently targeting “manylinux2014”, which is a decent middle ground.
Win32 API is much larger than Linux kernel API and is stable so there is quite large chance that a couple decades old software still works without recompiling or updating libraries. It has its issues with many parts of it being completely horrifying to use, but the stability is something that Microsoft has done well.