3 ms·

This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which

This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which does. It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install. The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok, there’s now Windows Store plus a recent-ish CLI tool that was based on one of the many unofficial package managers, but traditionally the way to install Windows application was via manual downloads and installs. So those installers would typically come bundled with any shared libraries they’d need and often have those shared libraries in the application directory. Leading to lots of duplication of libraries. You could easily do the same thing in Linux too but there’s less of a need because Linux distribution package managers are generally really good. But some 3rd party package managers do take this kind of approach, eg Nix, Snap, etc. So it’s not that Linux is “unstable” but more that people have approached the same problem on Linux in a completely different way. The fact that drag-and-drop installs work on macOS demonstrates that there isn’t really a UNIX-like limitation preventing Windows-style installs. It’s more that Linux distributions prefer a different method for application installation.

boricj 2y ago
It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to: - Bump vm.mmap_min_addr from 65536 down to 4096, a privileged operation ; - Use an a.out loader because the Linux kernel dropped support for a.out back in 2022 ; - Possibly use qemu-user if your system doesn't support 32-bit x86. That's the best-case scenario, because some of the old Atari Jaguar SDK Linux binaries are dynamically-linked a.out executables and you're basically stuck running ancient Linux kernels in a VM. It's at a point where someone at the AtariAge forums was seriously considering using my delinking black magic to port some of these old programs to modern Linux. It's quite telling when reverse-engineering an executable with Ghidra in order to export relocatable object files to relink (with some additional steps I won't get into) is even an option on the table. Sure, given enough determination and piles of hacks you can probably forcefully run any old random Linux program on modern systems, but odds are that Windows (or Wine or ReactOS) will manage to run a 32-bit x86 PE program from thirty years ago with minimal compatibility tweaks. Linux (both distributions and to a lesser degree the kernel) simply don't care about that use-case, to the point where I'd be pleasantly surprised if anyone manages to run Tux the Penguin: A Quest for Herring as-is on a modern system.
- hnlmorg 2y ago
  > It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. That’s exactly what dynamically linked executables are: user land > As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al. There are 32bit compatibility layers for Linux too but they’re. It going to be going to help if you’re running an a.out file because it’s a completely different type of executable format (ie not equivalent to a 32bit statically compiled ELF). Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. The awkward part of Linux here is that it doesn’t ship those VMs as part of its base install, but why would it because almost no one is trying to run randomly downloaded 32bit a.out files. To be clear, I’m not arguing that Linuxes backwards compatibility story is as good as Windows. It clearly isn’t. But the answer to that isn’t because Linux can’t be backwards compatible, it’s because Linux traditionally hasn’t needed to be. However all of the same tools Windows uses for it’s compatibility story are available to Linux for Linux executables too.
  - boricj 2y ago
    >> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. > That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al. In this specific case, it really is a user-land problem. I've went to the trouble of converting that specific executable into a statically linked 32-bit x86 ELF executable [1], to run as-is on modern x86 and x86_64 Linux systems. Besides rebasing it at a higher virtual address and writing about 10 lines of assembly to bridge the entrypoints, it's the same exact binary code as the original artifact. Unless you've specifically disabled or removed 32-bit x86 emulation, it'll run on a x86_64 kernel with no 32-bit userland compatibility layers installed. Just for kicks, I've also converted it into a dynamically linked executable (with some glue to bridge glibc 1.xx and glib 2.xx) and even into a x86 PE executable that can run on Windows (using more glue and MSYS2) [2]. > Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. These cases aren't equivalent. COM and MZ are 16-bit executables for MS-DOS [3], NE is for 16-bit Windows ; all can be officially run without workarounds on 32-bit x86 Windows systems (NTVDM has admittedly spotty compatibility, but the point stands). Here, we're talking about 32-bit x86 code, so COM/MZ/NE does not apply here (to my knowledge there never has been 16-bit Linux programs anyways). That Windows has 32-bit compatibility out of the box and that Linux distributions don't install 32-bit compatibility layers by default is one thing, but those on Linux only really apply to programs that at best share the same vintage as the host system (and at worst only work for the same distribution). Again, try running Tux the Penguin: A Quest for Herring as-is on a modern system (be it on a 32-bit or 64-bit installation, that part doesn't matter here), I'd gladly be proven wrong if it can be done without either a substantial rewrite+recompilation or egregious amounts of thunking a 2000's-era Linux userspace onto a 2020's-era one (no, a VM doesn't count, it has to run on the host). [1] https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html [2] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html [3] I know about 32-bit DOS extenders, but it's complicated enough as-is without bringing those into the mix.
bobsmooth 2y ago
>It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install. Is that a bad thing if it means a seamless experience for users? Storage is cheap.
- hnlmorg 2y ago
  I never suggested it was a bad thing. I was just explaining the differences. However to answer your question: Storage hasn’t always been cheap. So it used to be a bad thing. Theses days, as you rightly said, it’s less of an issue. But if you do want to focus on present day then it’s worth noting that these days FOSS does ship a lot of dependencies as part of their releases. Either via Docker containers, Nix packages, or static binaries (eg Go, Rust, etc). And they do this precisely because the storage cost is worth the convenience.

boricj 2y ago

It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to: - Bump vm.mmap_min_addr from 65536 down to 4096, a privileged operation ; - Use an a.out loader because the Linux kernel dropped support for a.out back in 2022 ; - Possibly use qemu-user if your system doesn't support 32-bit x86. That's the best-case scenario, because some of the old Atari Jaguar SDK Linux binaries are dynamically-linked a.out executables and you're basically stuck running ancient Linux kernels in a VM. It's at a point where someone at the AtariAge forums was seriously considering using my delinking black magic to port some of these old programs to modern Linux. It's quite telling when reverse-engineering an executable with Ghidra in order to export relocatable object files to relink (with some additional steps I won't get into) is even an option on the table. Sure, given enough determination and piles of hacks you can probably forcefully run any old random Linux program on modern systems, but odds are that Windows (or Wine or ReactOS) will manage to run a 32-bit x86 PE program from thirty years ago with minimal compatibility tweaks. Linux (both distributions and to a lesser degree the kernel) simply don't care about that use-case, to the point where I'd be pleasantly surprised if anyone manages to run Tux the Penguin: A Quest for Herring as-is on a modern system.

hnlmorg 2y ago
> It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. That’s exactly what dynamically linked executables are: user land > As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al. There are 32bit compatibility layers for Linux too but they’re. It going to be going to help if you’re running an a.out file because it’s a completely different type of executable format (ie not equivalent to a 32bit statically compiled ELF). Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. The awkward part of Linux here is that it doesn’t ship those VMs as part of its base install, but why would it because almost no one is trying to run randomly downloaded 32bit a.out files. To be clear, I’m not arguing that Linuxes backwards compatibility story is as good as Windows. It clearly isn’t. But the answer to that isn’t because Linux can’t be backwards compatible, it’s because Linux traditionally hasn’t needed to be. However all of the same tools Windows uses for it’s compatibility story are available to Linux for Linux executables too.
- boricj 2y ago
  >> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. > That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al. In this specific case, it really is a user-land problem. I've went to the trouble of converting that specific executable into a statically linked 32-bit x86 ELF executable [1], to run as-is on modern x86 and x86_64 Linux systems. Besides rebasing it at a higher virtual address and writing about 10 lines of assembly to bridge the entrypoints, it's the same exact binary code as the original artifact. Unless you've specifically disabled or removed 32-bit x86 emulation, it'll run on a x86_64 kernel with no 32-bit userland compatibility layers installed. Just for kicks, I've also converted it into a dynamically linked executable (with some glue to bridge glibc 1.xx and glib 2.xx) and even into a x86 PE executable that can run on Windows (using more glue and MSYS2) [2]. > Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. These cases aren't equivalent. COM and MZ are 16-bit executables for MS-DOS [3], NE is for 16-bit Windows ; all can be officially run without workarounds on 32-bit x86 Windows systems (NTVDM has admittedly spotty compatibility, but the point stands). Here, we're talking about 32-bit x86 code, so COM/MZ/NE does not apply here (to my knowledge there never has been 16-bit Linux programs anyways). That Windows has 32-bit compatibility out of the box and that Linux distributions don't install 32-bit compatibility layers by default is one thing, but those on Linux only really apply to programs that at best share the same vintage as the host system (and at worst only work for the same distribution). Again, try running Tux the Penguin: A Quest for Herring as-is on a modern system (be it on a 32-bit or 64-bit installation, that part doesn't matter here), I'd gladly be proven wrong if it can be done without either a substantial rewrite+recompilation or egregious amounts of thunking a 2000's-era Linux userspace onto a 2020's-era one (no, a VM doesn't count, it has to run on the host). [1] https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html [2] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html [3] I know about 32-bit DOS extenders, but it's complicated enough as-is without bringing those into the mix.

bobsmooth 2y ago

>It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install. Is that a bad thing if it means a seamless experience for users? Storage is cheap.

hnlmorg 2y ago
I never suggested it was a bad thing. I was just explaining the differences. However to answer your question: Storage hasn’t always been cheap. So it used to be a bad thing. Theses days, as you rightly said, it’s less of an issue. But if you do want to focus on present day then it’s worth noting that these days FOSS does ship a lot of dependencies as part of their releases. Either via Docker containers, Nix packages, or static binaries (eg Go, Rust, etc). And they do this precisely because the storage cost is worth the convenience.