5 ms·

Windows has a stable userland API/ABI, Microsoft go above and beyond for backwards compatibility. Linux does not have a stable userland ABI/API, it's very comm

Windows has a stable userland API/ABI, Microsoft go above and beyond for backwards compatibility. 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-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...)

Arnavion 3y ago
>Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-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.
stingraycharles 3y ago
Static linking libc is very iffy indeed, it’s much better to just use a very old libc and dynamically link against that. 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.
skywal_l 3y ago
> Linux does not have a stable userland ABI/API 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 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).
- Snetry 3y ago
  > I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". 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.
  - skywal_l 3y ago
    The statement "Linux does not have a stable userland ABI/API" is about the kernel. If you are talking about glibc you are already in the Linux OS/GNU Linux (whatever it is called) domain. 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!
- Dalewyn 3y ago
  >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. 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.
  - jpc0 3y ago
    If you statically link to your dependencies or ship the dynamic libraries yourself, like you would need to do on windows, you would get the exact same experience on Linux.
the8472 3y ago
On the other hand, old software often runs better (or at all) on dosbox or wine than on windows.

Arnavion 3y ago

>Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-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.

stingraycharles 3y ago

Static linking libc is very iffy indeed, it’s much better to just use a very old libc and dynamically link against that. 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.

skywal_l 3y ago

> Linux does not have a stable userland ABI/API 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 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).

Snetry 3y ago
> I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". 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.
- skywal_l 3y ago
  The statement "Linux does not have a stable userland ABI/API" is about the kernel. If you are talking about glibc you are already in the Linux OS/GNU Linux (whatever it is called) domain. 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!
Dalewyn 3y ago
>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. 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.
- jpc0 3y ago
  If you statically link to your dependencies or ship the dynamic libraries yourself, like you would need to do on windows, you would get the exact same experience on Linux.

the8472 3y ago

On the other hand, old software often runs better (or at all) on dosbox or wine than on windows.