4 ms·

You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions. There is sig

You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions. There is significant backward-compatibility with Windows binaries, and it is intentional. It provides for a much better ROI for applications that need to be around for more than a couple of years.

eikenberry 8y ago
With something like AppImages you get pretty much eternal backwards compatibility. The kernel _never_ breaks backwards compatibility with userland, and the AppImage pulls in all other dependencies.
- bennofs 8y ago
  Not if you need to communicate with other user space services, such as: * systray icons/application indicators * newer fontconfig versions support new config options which results in fonts being broken for apps that use older versions * I think there is some issue around glibc locales handling if you use a different glibc * systemd/logind/... DBus apis Those were just some external interfaces that came to my mind. I'm sure there are many more.
tathougies 8y ago
> You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions. This has nothing to do with the OS. A statically linked linux executable will likely run on any kernel from version 1 to version 4. The issue here is dynamic linking, and windows DLL hell has a name for a reason
- TimJYoung 8y ago
  I'm referring to the Windows system APIs, which do not require any sort of special treatment for any executable that is linked against them. This includes everything that is included with Windows, from networking to file handling to crypto to UI. Which libraries are you including in your description of a statically-linked binary on Linux ? Finally, Windows DLL hell hasn't been a thing since the early 2000s, and even then, it was primarily only an issue with applications dumping shared libraries into the Windows system directories.

eikenberry 8y ago

With something like AppImages you get pretty much eternal backwards compatibility. The kernel _never_ breaks backwards compatibility with userland, and the AppImage pulls in all other dependencies.

bennofs 8y ago
Not if you need to communicate with other user space services, such as: * systray icons/application indicators * newer fontconfig versions support new config options which results in fonts being broken for apps that use older versions * I think there is some issue around glibc locales handling if you use a different glibc * systemd/logind/... DBus apis Those were just some external interfaces that came to my mind. I'm sure there are many more.

tathougies 8y ago

> You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions. This has nothing to do with the OS. A statically linked linux executable will likely run on any kernel from version 1 to version 4. The issue here is dynamic linking, and windows DLL hell has a name for a reason

TimJYoung 8y ago
I'm referring to the Windows system APIs, which do not require any sort of special treatment for any executable that is linked against them. This includes everything that is included with Windows, from networking to file handling to crypto to UI. Which libraries are you including in your description of a statically-linked binary on Linux ? Finally, Windows DLL hell hasn't been a thing since the early 2000s, and even then, it was primarily only an issue with applications dumping shared libraries into the Windows system directories.