5 ms·

I've always wondered why Linux binaries are incompatible with each other while you double click on an exe and it'll pretty much always work.

zweifuss 4y ago
Before Windows XP (2002) "DLL Hell" used to be a real problem too. Also a lot of current EXEs need at least Windows 7 SP1 to run.
torstenvl 4y ago
It will never truly be the year of the Linux desktop until this is fixed. Even assuming the developers of the major pieces of proprietary software were willing to put in the work to port, say, Photoshop or Word, packaging the result is made intentionally asinine. It's literally easier to run old Windows binaries on a Linux than to run old Linux binaries on Linux.
- chungy 4y ago
  The problem is fixed: AppImage
  - okanat 4y ago
    Nope. They depend on fuse2 which isn't shipped with Opensuse which ships fuse3.
Denvercoder9 4y ago
Windows applications usually ship their own copy of all the libraries they use, instead of relying on the system copy of those libraries; and Microsoft is better at keeping system APIs backward-compatible (for some definition of system). Both approaches have advantages and disadvantages.
- okanat 4y ago
  MS is almost perfect in this matter. You can still run Win 2k binaries. Most proper Windows applications do ship many libraries but they are often really special purpose or actually part of the application via plugin interfaces. On Windows you don't ship the equivalent of libc, libcurl, libssl, libX.. or SDL. You don't have to deal with any of the pains in the article. Those are all in the OS and they have a stable ABI. Moreover this approach makes your binaries more secure by updating more critical points of failure (i.e. web interfaces, crypto) with the OS rather than you as the developer being forced to do so.
ozarker 4y ago
It’s easy to maintain binary compatibility if a single company owns all versions and distros of an OS.
heywire 4y ago
From a user perspective, AppImage files seem to behave similarly to an .exe on Windows.
- rathboma 4y ago
  Yes! AppImage is the best.
rascul 4y ago
It works if whoever created the binary statically linked it or ships the deps with it. This isn't the typical experience for rpm and deb packages but it's still doable.
jeroenhd 4y ago
Windows' trick to fixing DLL conflicts is to make a huge tree of DLL hard links that basically allow any permutation of common Windows DLL versions to be used together. With many Linux distros, the expectation is that you run software from your distros maintainers which will do all the hard work of mixing and matching dependencies for you. The trouble begins when you go outside of your distribution's supported software. Some solve this by building everything from source on unsupported platforms, others will just ship their preferred distro with their binary and run the entire thing as a container. Similar to what Windows does, except less optimised for storage. The "old" way (putting the correct .so libraries next to your executable and using those) still works well but it's being replaced by static compilation in many newer projects.
badsectoracula 4y ago
"Linux" is only the kernel - i'm not trying to be pedantic, this is the actual issue actually. The kernel has a stable ABI, you can run software from the late 90s on modern kernels and it'll work, but it'll work only as long as the program either makes these calls directly or all the libraries it links to dynamically also provide a stable ABI. A "Linux distribution" or "Linux OS" or whatever people install in their computers and call "Linux" is not just the kernel though, it is the kernel and a bunch of additional software and -most importantly- libraries on top of it that provide functionality the kernel itself doesn't provide. This includes stuff like getting a desktop environment, which is often made up of -among others- several dynamic libraries that provide functionality such as opening windows, providing elements like buttons, checkboxes, inputboxes, etc and of course handling graphics and user input. Very few of these libraries however provide a stable ABI. On average, you can expect a program from the late 90s that uses the GNU C Library and X11 to work because those libraries provide stable ABIs (as long as you are not trying to abuse them and do not use undocumented features) but anything beyond becomes harder. cURL does provide a stable ABI since the 2005 and they promise not to break it, but there are very few libraries that make such promises (for many that haven't broken their ABI it seems to be more of a consequence of their development than an explicit goal). It is really up to the developers of each library to keep their ABIs stable - assuming they care of that in the first place (IME with talking with some developers, even here on Hacker News, many do not care or even seem to actively refuse to understand what the problem is in the first place). All the above means that Linux distributions come with a lot of different libraries and library versions (so even if a binary depends on libfoo and libfoo exists on the system, it will still not work if it depends on libfoo version 1 but the system has libfoo version 2 which broke compatibility with version 1) just to provide a regular desktop environment. On the other hand on Windows you get a ton of functionality out of the box - not just for making GUI applications, but also for networking, graphics, audio, video encoding and decoding, etc. Even if that stuff aren't the best in class, they're there and applications can simply depend on them. More importantly, Microsoft promises to not break the Windows API ABI and that promise has held for literal decades. In the case where an application needs more/different stuff, it doesn't need to provide everything of the above, it only needs to provide the stuff that it needs - e.g. a video encoding application can use the GUI functionality that Windows provides but still use ffmpeg for performing that encoding. While it'd be duplicating functionality that technically Windows already provides, it'd only be functionality related to encoding, not everything. So basically, Windows applications tend to pretty much always work because they can rely on Windows to both provide a lot more functionality out of the box and remain compatible than Linux applications do. Note that this is not a technical problem but a cultural problem - most Linux developers of libraries that would be the equivalent of parts of the Windows API that has remained stable over the decades do not believe that such backwards compatibility is important or even possible (assuming you can get them to accept that there is such a problem in the first place).

zweifuss 4y ago

Before Windows XP (2002) "DLL Hell" used to be a real problem too. Also a lot of current EXEs need at least Windows 7 SP1 to run.

torstenvl 4y ago

It will never truly be the year of the Linux desktop until this is fixed. Even assuming the developers of the major pieces of proprietary software were willing to put in the work to port, say, Photoshop or Word, packaging the result is made intentionally asinine. It's literally easier to run old Windows binaries on a Linux than to run old Linux binaries on Linux.

chungy 4y ago
The problem is fixed: AppImage
- okanat 4y ago
  Nope. They depend on fuse2 which isn't shipped with Opensuse which ships fuse3.

Denvercoder9 4y ago

Windows applications usually ship their own copy of all the libraries they use, instead of relying on the system copy of those libraries; and Microsoft is better at keeping system APIs backward-compatible (for some definition of system). Both approaches have advantages and disadvantages.

okanat 4y ago
MS is almost perfect in this matter. You can still run Win 2k binaries. Most proper Windows applications do ship many libraries but they are often really special purpose or actually part of the application via plugin interfaces. On Windows you don't ship the equivalent of libc, libcurl, libssl, libX.. or SDL. You don't have to deal with any of the pains in the article. Those are all in the OS and they have a stable ABI. Moreover this approach makes your binaries more secure by updating more critical points of failure (i.e. web interfaces, crypto) with the OS rather than you as the developer being forced to do so.

ozarker 4y ago

It’s easy to maintain binary compatibility if a single company owns all versions and distros of an OS.

heywire 4y ago

From a user perspective, AppImage files seem to behave similarly to an .exe on Windows.

rathboma 4y ago
Yes! AppImage is the best.

rascul 4y ago

It works if whoever created the binary statically linked it or ships the deps with it. This isn't the typical experience for rpm and deb packages but it's still doable.

jeroenhd 4y ago

Windows' trick to fixing DLL conflicts is to make a huge tree of DLL hard links that basically allow any permutation of common Windows DLL versions to be used together. With many Linux distros, the expectation is that you run software from your distros maintainers which will do all the hard work of mixing and matching dependencies for you. The trouble begins when you go outside of your distribution's supported software. Some solve this by building everything from source on unsupported platforms, others will just ship their preferred distro with their binary and run the entire thing as a container. Similar to what Windows does, except less optimised for storage. The "old" way (putting the correct .so libraries next to your executable and using those) still works well but it's being replaced by static compilation in many newer projects.

badsectoracula 4y ago

"Linux" is only the kernel - i'm not trying to be pedantic, this is the actual issue actually. The kernel has a stable ABI, you can run software from the late 90s on modern kernels and it'll work, but it'll work only as long as the program either makes these calls directly or all the libraries it links to dynamically also provide a stable ABI. A "Linux distribution" or "Linux OS" or whatever people install in their computers and call "Linux" is not just the kernel though, it is the kernel and a bunch of additional software and -most importantly- libraries on top of it that provide functionality the kernel itself doesn't provide. This includes stuff like getting a desktop environment, which is often made up of -among others- several dynamic libraries that provide functionality such as opening windows, providing elements like buttons, checkboxes, inputboxes, etc and of course handling graphics and user input. Very few of these libraries however provide a stable ABI. On average, you can expect a program from the late 90s that uses the GNU C Library and X11 to work because those libraries provide stable ABIs (as long as you are not trying to abuse them and do not use undocumented features) but anything beyond becomes harder. cURL does provide a stable ABI since the 2005 and they promise not to break it, but there are very few libraries that make such promises (for many that haven't broken their ABI it seems to be more of a consequence of their development than an explicit goal). It is really up to the developers of each library to keep their ABIs stable - assuming they care of that in the first place (IME with talking with some developers, even here on Hacker News, many do not care or even seem to actively refuse to understand what the problem is in the first place). All the above means that Linux distributions come with a lot of different libraries and library versions (so even if a binary depends on libfoo and libfoo exists on the system, it will still not work if it depends on libfoo version 1 but the system has libfoo version 2 which broke compatibility with version 1) just to provide a regular desktop environment. On the other hand on Windows you get a ton of functionality out of the box - not just for making GUI applications, but also for networking, graphics, audio, video encoding and decoding, etc. Even if that stuff aren't the best in class, they're there and applications can simply depend on them. More importantly, Microsoft promises to not break the Windows API ABI and that promise has held for literal decades. In the case where an application needs more/different stuff, it doesn't need to provide everything of the above, it only needs to provide the stuff that it needs - e.g. a video encoding application can use the GUI functionality that Windows provides but still use ffmpeg for performing that encoding. While it'd be duplicating functionality that technically Windows already provides, it'd only be functionality related to encoding, not everything. So basically, Windows applications tend to pretty much always work because they can rely on Windows to both provide a lot more functionality out of the box and remain compatible than Linux applications do. Note that this is not a technical problem but a cultural problem - most Linux developers of libraries that would be the equivalent of parts of the Windows API that has remained stable over the decades do not believe that such backwards compatibility is important or even possible (assuming you can get them to accept that there is such a problem in the first place).