Hacker News Reader

Comment by londons_explore | Hacker News Reader

Famously Microsoft does with Windows. That's how an exe file from 25 years ago can still run today.

Yes, but GPU architecture changes very frequently.

Shaders from 15 years ago still work, but they're compiled on-the-fly to a GPU-dependent format. I expect you don't want to have to recompile an entire c++ stdlib every time you recompile your own code.

> I expect you don't want to have to recompile an entire c++ stdlib every time you recompile your own code.

That's basically our current model, I discussed this on Twitter recently.

https://twitter.com/blelbach/status/1307396914057326592

Do they use some kind of ABI versioning?

Running 32 bit x86 code on a AMD64 machine is possible on most operating systems which supported both of these, and has probably more to do with AMD64 supporting that execution model.

Try that on Linux and you'll find most libraries no longer have the same entry points and that various data structures have changed leading to fun fun crashes...

The kernel itself has maintained (mostly) ABI compatibility though.

That's a "you're holding it wrong" problem, though. Projects like GTK or Qt never claimed they'd be backwards-compatible 26 years (Qt has specific backwards-compatibility API and ABI guarantees and are in my experience pretty diligent about it), so if you want a binary to work for a long time, you have to ship your own versions of these. Libraries like Xlib on the other hand are very stable and much more similar to the Win32 API in that respect. In theory Linux has versioning for libraries, in practice it is never used correctly and useless anyway, since distros generally only keep around one version of everything, so even if you'd link against a specific version (e.g. libfoobar.so.2.21 instead of libfoobar.so.2, which will break if you don't recompile and/or patch the source), it wouldn't exist _anyway_ after a few updates. And that's mostly because distros never promised you'd be able to run binaries built outside their packaging infrastructure anyway; it being common practice and sometimes working doesn't imply it's guaranteed to work.

Hence why C applications only linking these "basic" libraries (libc, Xlib, zlib, ...) are regarded as so stable and portable, because they're built and linked against system components which rarely change. (Keep in mind to build this kind of binary on ancient systems, otherwise glibc will make sure it won't work everywhere).

This is one of those things it feels like all the content addressable initiatives should be able to solve somehow. With near ubiquitous internet access, why can't a program ship with a list of standard library hashes it'll link against and my distro go fetch them from IPFS or whatever if they're not local.

The solution for this is now Docker, Flatpack, Snap, …

Just ship the whole environment and only rely on the stable kernel API.

This is very wasteful. On servers in the cloud that may be a reasonable approach, but there are still devices that are memory, storage, and/or network constrained enough where it's not. It's still necessary to have relatively stable interfaces such that most things can share the same version of a dependency and their still exists the ability to deduplicate the dependencies between different programs. I do agree that the current OS approaches to handle this are not great and there is room for new models, but docker containers are not a holistic solution.

The Windows Component Store (aka Side-by-Side aka WinSxS) is sort of a content-addressed store for DLLs and the like, except the content-addressing isn't facilitated by a literal cryptographic hash over the contents, but instead by the logical identity of the component (name+version but more). And, it doesn't fetch anything automatically. Writes to certain paths are just intercepted and redirected into it, while storing an association somewhere else that the app that did that (or was installed doing that) wants that particular component (or at least, that's how I think that works).

Nix basically already does this, apart from the decentralised distributed cache (there is a centralised one and you can easily set up your own, too). All references, including to dynamically linked libraries are via unique, content addressable hash -- where "content" currently still happens to be content of the build recipe and all dependencies and sources, recursively, not the built artefact. There is work on referencing artefacts by the binary output hash though, because that obviously has better security properties when you want to have a non-centralized cache; the main problem is that a lot of software still has no reproducible build.

This is what AppFS does, as well as CernVM-FS, though AppFS has more features

Reply on news.ycombinator.com