4 ms·

This is a fantastic explanation! I've been thinking about software/binary compatibility lately. I think even before crossing the CPU arch barrier you mention, w

This is a fantastic explanation! I've been thinking about software/binary compatibility lately. I think even before crossing the CPU arch barrier you mention, we could cross the OS barrier. Windows apps are generally mutually compatible. Within Linux is dicier. I've found some rules of thumb (compile on the oldest version you wish to support), with some cross-distro compat. Some things like MUSL and manylinux are nice! I would love to see all OS barriers to compatibility knocked down. Or at least be able to make a single "Linux" binary. The CPU type barrier is obviously larger, but I think the OS one shouldn't exist. Maybe we would need standard abstractions for things the OS provides like file system, date/time, allocator, threads, networking. The things programming languages abstract over in their std libs, but at an OS/compile level.

ElectricalUnion 9mo ago
jart Cosmopolitan. It combines a polyglot format (the αcτµαlly pδrταblε εxεcµταblε is simultaneously a Windows Portable Executable and a Thompson Shell script) and a polymorphic libc that works in all major OSes under both amd64 and arm64. It's a single binary.
- trollbridge 9mo ago
  And produces binaries that are smaller than a typical single-OS build.
thewebguyd 9mo ago
> Or at least be able to make a single "Linux" binary. Isn't this what Flatpak/Snap/AppImage try to solve? Though lately they may not even be necessary. There's a lot less difference between distros now than there used to be in the past. All the majors seemed to have coalesced around the same userland stack, largely thanks to SystemD. If you ship something for Ubuntu LTS, there's a really good chance it'll also work on Fedora, Debian, Arch out of the box.