3 ms·

I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean ex

I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean exactly? I suppose all x86 processors have slightly different sets of instruction. Also, different linux kernels may have different sets of syscalls?

dezgeg 3y ago
At least for 32-bit x86 I've run into such problems. The Intel Quark platform has such an old CPU core in it that normal Ubuntu binaries wouldn't work on it (even at the the platform was relevant), as it lacks conditional move instructions unlike any other non-museum piece x86. Also Glibc drops support for old kernel versions time to time, so even statically linked stuff isn't safe when compiling modern stuff against really old kernels.
dikei 3y ago
Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU. However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a modern Linux kernel.
- PlutoIsAPlanet 3y ago
  The interface between the Kernel and Userland is stable. The interface between Userland-Userland is not, very much not, a binary compiled a decade ago, unless its statically compiled or has no dependencies, will very likely not run, and is why things such as Flatpak and Docker partially exist in the first place.
  - dikei 3y ago
    True, I was only talking about Kernel-Userland. It's also why closed-source software often include every dependencies in their installation package. And even that is sometimes not enough, like when the host's glibc is too old.
- dezgeg 3y ago
  Well, it's worth noting that Linux backward compatibility is not absolute guarantee, but rather "if feature is removed in a forest and nobody is around to hear it, then it's not a backward compatibility break". Eg. for instance the removal of a.out support: https://lwn.net/Articles/888741/ https://lwn.net/Articles/888741/ - the a.out support was almost removed, until a single user happened to notice and object. But then someone came up with a workaround and that single (known) remaining a.out user changed his code, and the a.out support was deleted.

dezgeg 3y ago

At least for 32-bit x86 I've run into such problems. The Intel Quark platform has such an old CPU core in it that normal Ubuntu binaries wouldn't work on it (even at the the platform was relevant), as it lacks conditional move instructions unlike any other non-museum piece x86. Also Glibc drops support for old kernel versions time to time, so even statically linked stuff isn't safe when compiling modern stuff against really old kernels.

dikei 3y ago

Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU. However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a modern Linux kernel.

PlutoIsAPlanet 3y ago
The interface between the Kernel and Userland is stable. The interface between Userland-Userland is not, very much not, a binary compiled a decade ago, unless its statically compiled or has no dependencies, will very likely not run, and is why things such as Flatpak and Docker partially exist in the first place.
- dikei 3y ago
  True, I was only talking about Kernel-Userland. It's also why closed-source software often include every dependencies in their installation package. And even that is sometimes not enough, like when the host's glibc is too old.
dezgeg 3y ago
Well, it's worth noting that Linux backward compatibility is not absolute guarantee, but rather "if feature is removed in a forest and nobody is around to hear it, then it's not a backward compatibility break". Eg. for instance the removal of a.out support: https://lwn.net/Articles/888741/ https://lwn.net/Articles/888741/ - the a.out support was almost removed, until a single user happened to notice and object. But then someone came up with a workaround and that single (known) remaining a.out user changed his code, and the a.out support was deleted.