4 ms·

That is sad and wish it could be a joke. But there are days I think the same... today I cannot not even run zsnes without problems on most of distros (Arch/Ubun

by lerax 6y ago

That is sad and wish it could be a joke. But there are days I think the same... today I cannot not even run zsnes without problems on most of distros (Arch/Ubuntu/Etc). Linux backward compatibility it's so terrible.

weare138 6y ago
But this isn't just a Linux problem though. Backwards compatibility sucks on Windows and MacOS too. At least Windows tries to give you some janky backwards compatibility options, with questionable results. MacOS just deprecates API's, drops support for older versions of MacOS and tells their users to go buy new stuff.
- AnIdiotOnTheNet 6y ago
  > But this isn't just a Linux problem though. Backwards compatibility sucks on Windows and MacOS too. It sucks a hell of a lot less than Linux's backwards compatibility. Hell, Linux has better compatibility with Windows software than it does its own older software!
  - weare138 6y ago
    I've administered Windows networks. Windows backwards compatibility sucks and the fact most Windows legacy software runs better under Wine on a different OS is a testament to that. Almost none of the current OS's are good at backwards compatibility. It's not just a Linux problem. Hell Apple doesn't even try.
    - AnIdiotOnTheNet 6y ago
      Yeah, Windows backwards compatibility has been getting worse, but consider the following: You are given a binary for a GUI application, compiled in 2001. You drop the binary on your system and run it. If it is a Windows application, it has a much better chance of working fine on both Windows and Linux than it does on Linux alone if it is a Linux application!
      - michaelmrose 6y ago
        What about if you have the code?
        AnIdiotOnTheNet 6y ago
        Then you still have to get the development environment right, a task so simple it totally isn't a popular usecase for containers (/s), and fix any incompatibilities in the APIs since 2001 and now. In other words: it's at least as big a pain in the ass as getting the old binary working.
- gridlockd 6y ago
  Mac: "We're dropping some legacy struff, go buy the new thing" GNU/Linux: "We're changing the size of a struct, go recompile from source" Windows: "After long deliberation, we have decided that 16-bit application support will be an optional feature that users have to install manually"

by lerax 6y ago

weare138 6y ago

But this isn't just a Linux problem though. Backwards compatibility sucks on Windows and MacOS too. At least Windows tries to give you some janky backwards compatibility options, with questionable results. MacOS just deprecates API's, drops support for older versions of MacOS and tells their users to go buy new stuff.

AnIdiotOnTheNet 6y ago
> But this isn't just a Linux problem though. Backwards compatibility sucks on Windows and MacOS too. It sucks a hell of a lot less than Linux's backwards compatibility. Hell, Linux has better compatibility with Windows software than it does its own older software!
- weare138 6y ago
  I've administered Windows networks. Windows backwards compatibility sucks and the fact most Windows legacy software runs better under Wine on a different OS is a testament to that. Almost none of the current OS's are good at backwards compatibility. It's not just a Linux problem. Hell Apple doesn't even try.
  - AnIdiotOnTheNet 6y ago
    Yeah, Windows backwards compatibility has been getting worse, but consider the following: You are given a binary for a GUI application, compiled in 2001. You drop the binary on your system and run it. If it is a Windows application, it has a much better chance of working fine on both Windows and Linux than it does on Linux alone if it is a Linux application!
    - michaelmrose 6y ago
      What about if you have the code?
      - AnIdiotOnTheNet 6y ago
        Then you still have to get the development environment right, a task so simple it totally isn't a popular usecase for containers (/s), and fix any incompatibilities in the APIs since 2001 and now. In other words: it's at least as big a pain in the ass as getting the old binary working.
gridlockd 6y ago
Mac: "We're dropping some legacy struff, go buy the new thing" GNU/Linux: "We're changing the size of a struct, go recompile from source" Windows: "After long deliberation, we have decided that 16-bit application support will be an optional feature that users have to install manually"