4 ms·

Huh? Running against a different set of shared libraries? - it has nothing to do with "backward" compatibility - it has nothing to do with Linux. If you chang

Huh? Running against a different set of shared libraries? - it has nothing to do with "backward" compatibility - it has nothing to do with Linux. If you change shared libraries with incompatible versions software will break on windows and bsd as well

loopz 6y ago
It's time to remind people again that "Linux" isn't one OS. At best it's kernel source that you get to compile for different architectures. There are distributions ("distros") that package up different sets of kernel, kernel parameters, modules, libraries, utilities, config and glue-scripts, though none of them actually claim backwards or cross-binary compatibility, unless for their own (ie. within major RHELS versions). It could be nice to not have to worry about all that compatibility and even some upgrade-issues that inevitably ensue. Though the costs can quickly outweigh the benefits, ie. as in the awfulness of "snap" and similar. Windows do have compatibility and emulation layers, though some older software may still have some issues, it often works. Security-wise it's a good idea to keep patches and upgrades fresh.
onli 6y ago
That has everything to do with backwards compatibility. You have one piece of software made for an old linux target that does not run anymore on modern Linux. Heck, most of the Feral games don't run on my Linux because they rely on shared libs that my system does not have, and those aren't even old! And it's only Linux that has that problem in that dimension. Windows just kept everything around. Other systems don't evolve as much as Linux has, and they do not have the distribution differences that kill compatibility on Linux. AppImage is great and solves that problem. It should be used more.
- throwaway91914 6y ago
  You don't understand the definition of backward compatibility. There are examples of binaries written against a UNIX kernel from 30 years ago that run just fine. If you start adding dependencies on libraries you are choosing to have one of these problems: - use dynamic libraries and refuse to cooperate with maintainers and things will break, rightfully so - use dynamic libraries and the OS keep them around forever and it will become a security dumpster fire over time (and also will never scale down to embedded systems and phones) - use dynamic libraries and ship them in a tarball and it will become a security dumpster fire over time - use static libraries and it will become a security dumpster fire over time, plus it's even more difficult to tell what libraries are used - use dynamic libraries and ship them with docker or appimage or similar and it will become a security dumpster fire over time, plus you have unnecessary complexity - use dynamic libraries and package your stuff properly. Target LTS releases. Most good distributions will guarantee 5 years of stability of all the dependencies without version changes. Plus you get free backported security fixes and free testing. > And it's only Linux that has that problem in that dimension Not at all. > AppImage is great and solves that problem. It should be used more. Not at all.

loopz 6y ago

It's time to remind people again that "Linux" isn't one OS. At best it's kernel source that you get to compile for different architectures. There are distributions ("distros") that package up different sets of kernel, kernel parameters, modules, libraries, utilities, config and glue-scripts, though none of them actually claim backwards or cross-binary compatibility, unless for their own (ie. within major RHELS versions). It could be nice to not have to worry about all that compatibility and even some upgrade-issues that inevitably ensue. Though the costs can quickly outweigh the benefits, ie. as in the awfulness of "snap" and similar. Windows do have compatibility and emulation layers, though some older software may still have some issues, it often works. Security-wise it's a good idea to keep patches and upgrades fresh.

onli 6y ago

That has everything to do with backwards compatibility. You have one piece of software made for an old linux target that does not run anymore on modern Linux. Heck, most of the Feral games don't run on my Linux because they rely on shared libs that my system does not have, and those aren't even old! And it's only Linux that has that problem in that dimension. Windows just kept everything around. Other systems don't evolve as much as Linux has, and they do not have the distribution differences that kill compatibility on Linux. AppImage is great and solves that problem. It should be used more.

throwaway91914 6y ago
You don't understand the definition of backward compatibility. There are examples of binaries written against a UNIX kernel from 30 years ago that run just fine. If you start adding dependencies on libraries you are choosing to have one of these problems: - use dynamic libraries and refuse to cooperate with maintainers and things will break, rightfully so - use dynamic libraries and the OS keep them around forever and it will become a security dumpster fire over time (and also will never scale down to embedded systems and phones) - use dynamic libraries and ship them in a tarball and it will become a security dumpster fire over time - use static libraries and it will become a security dumpster fire over time, plus it's even more difficult to tell what libraries are used - use dynamic libraries and ship them with docker or appimage or similar and it will become a security dumpster fire over time, plus you have unnecessary complexity - use dynamic libraries and package your stuff properly. Target LTS releases. Most good distributions will guarantee 5 years of stability of all the dependencies without version changes. Plus you get free backported security fixes and free testing. > And it's only Linux that has that problem in that dimension Not at all. > AppImage is great and solves that problem. It should be used more. Not at all.