Hacker News Reader

Comment by foobiekr | Hacker News Reader

It's a shame that DLL hell was never resolved in the obvious way: deduplication of identical libraries through cryptographic hashes. Containers basically threw away any hope of sharing the bytes on disk - and more importantly _in ram_. Disk bytes are cheap, ram bytes are not, let alone TLB space, branch predictor context, and so on.

There was a middle ground possible at one point where containers actually were packaged with all of their dependencies, but a container installer would fragment this assembly into cryptographically verifiable share dependencies, but we lost that because it was hard.

View on HN

> deduplication of identical libraries through cryptographic hashes

Isn't that how the .NET CLR's global assembly cache works?

A lot of things work that way because it’s obvious to everyone except the container runtimes on Linux.

The container runtimes have to cope with Dockerfiles and similar, which know nothing about packages. To get the kind of granularity you want here, you have to do actual packaging work, which is the thing Docker sold everyone on avoiding.

If you are willing to do that kind of packaging work you can get the best of both worlds today with Nix or Guix. But containers are attractive because you can chuck whatever pathological build process your developers have evolved over the decades into a Containerfile and it'll mostly work.

> deduplication of identical libraries through cryptographic hashes

Or, maybe, adding a version string to the file name, so, if you were compiled with data structures for libFoo1 (which you found on libFoo.h provided by libFoo1-devel) you’ll link to libFoo1 and not libFoo or libFoo2.

Never use a string. What if the string is wrong? Use hashes.

If the file for version 2 or libFoo is libFoo1, it only means someone shouldn’t be naming things.

Being in the file name makes it trivial to retrieve and immediately obvious to a human reading the information.

Reply on news.ycombinator.com