4 ms·

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

by msla 6y ago

NCommander 6y ago
No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features. I've been down that road, there's nothing good to say about it.
- megameter 6y ago
  The actual form of backwards compatibility in Linux is "gcc still builds the C and bash still runs the shell script". Which is nice in that most every distro carries around a gazillion packages of obscure old code that still builds, but it also means that binaries are heavily disrespected, and the development environment is and forever remains centered around the GNU toolchain.
- asveikau 6y ago
  > Godhelp you if your application tries to use weird ALSA or even worse, OSS features. What's a weird ALSA or OSS feature? What do you expect in its place? OSS as an API was really dead simple. open, ioctl, read or write... That interface is still working fine on FreeBSD. There is an OSS to ALSA compatibility driver. I'm sure whatever you're expecting (pulseaudio? yech.) can fake being an ALSA device enough to fool anyone.
- msla 6y ago
  I have plenty of experience which says otherwise, both for Windows breaking compatibility and Linux keeping it.
asveikau 6y ago
Are you aware that the original binary format of Linux was not ELF? Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.
- msla 6y ago
  > Are you aware that the original binary format of Linux was not ELF? Yes, and having an a.out interpreter is just another dependency. > Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc. It's a library. libc is versioned like everything else.
  - asveikau 6y ago
    Nobody is distributing that library anymore. Whereas an equivalently aged binary on Windows will load today without extra dependencies. I would think that the kernel would have dropped binfmt_aout by now, but I just looked and it's still there. Wonder if any distros build it.
    - chungy 6y ago
      > Nobody is distributing that library anymore. There exist plenty of archives of old Linux distributions. "Nobody" turns out to be quite a lot of people/servers. > Whereas an equivalently aged binary on Windows will load today without extra dependencies. I wouldn't go so far. The 64-bit port of Windows dropped support for all 16-bit applications, whereas they still run flawlessly through Wine.

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

by msla 6y ago

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

NCommander 6y ago

No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features. I've been down that road, there's nothing good to say about it.

megameter 6y ago
The actual form of backwards compatibility in Linux is "gcc still builds the C and bash still runs the shell script". Which is nice in that most every distro carries around a gazillion packages of obscure old code that still builds, but it also means that binaries are heavily disrespected, and the development environment is and forever remains centered around the GNU toolchain.
asveikau 6y ago
> Godhelp you if your application tries to use weird ALSA or even worse, OSS features. What's a weird ALSA or OSS feature? What do you expect in its place? OSS as an API was really dead simple. open, ioctl, read or write... That interface is still working fine on FreeBSD. There is an OSS to ALSA compatibility driver. I'm sure whatever you're expecting (pulseaudio? yech.) can fake being an ALSA device enough to fool anyone.
msla 6y ago
I have plenty of experience which says otherwise, both for Windows breaking compatibility and Linux keeping it.

asveikau 6y ago

Are you aware that the original binary format of Linux was not ELF? Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

msla 6y ago
> Are you aware that the original binary format of Linux was not ELF? Yes, and having an a.out interpreter is just another dependency. > Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc. It's a library. libc is versioned like everything else.
- asveikau 6y ago
  Nobody is distributing that library anymore. Whereas an equivalently aged binary on Windows will load today without extra dependencies. I would think that the kernel would have dropped binfmt_aout by now, but I just looked and it's still there. Wonder if any distros build it.
  - chungy 6y ago
    > Nobody is distributing that library anymore. There exist plenty of archives of old Linux distributions. "Nobody" turns out to be quite a lot of people/servers. > Whereas an equivalently aged binary on Windows will load today without extra dependencies. I wouldn't go so far. The 64-bit port of Windows dropped support for all 16-bit applications, whereas they still run flawlessly through Wine.