Hacker News Reader

Comment by max-privatevoid | Hacker News Reader

The damage the FHS has done to the software world is insane and container overuse is the biggest symptom of it.

As opposed to what? Every distro puts their files in a different place, making even more of a nightmare for software maintainers?

No, all software goes into subdirectories of "Program Files", instead of being strewn around in a dozen directories.

This but without the Microsoftisms, and every component directory is immutable, and maximal sharing is encouraged.

Content-addressed (or input-addressed) component stores, like Nix. If you're blindly assuming which libraries exist on the target system, you've already failed.

Part of the point of Debian and Redhat style package management was to be able to assume that if a dependency package was installed, that would provide specific libraries on the target system in a specific place.

And those assumptions often end up being wrong. There will always be differences between distros. Ensure, don't assume.

> As opposed to what?

Programs including their dependencies.

The Linux model of global shared libraries is an abject failure. It’s a failed model — and the prevalence of requiring Docker simply to launch a program is evidence of this.

Windows doesn’t have global library folders that are polluted by a million user scripts. And you can reliably launch software that’s 25 years old. It works great. Linux’s model was a nice effort but ultimately a failure.

> Windows doesn’t have global library folders that are polluted by a million user scripts.

C:\WINDOWS\SYSTEM32

It's called "DLL Hell" for a reason. It used to be very common for every program you installed to dump several libraries in that directory. It included program-specific libraries (so that directory would have a mix of internal libraries for every program you ever installed; pray there were no naming conflicts!), compiler runtime libraries like the C library (and it was not uncommon for a program to overwrite an already existing runtime DLL with an older version, breaking other programs which expected the newer version), and sometimes even operating system libraries. It got so bad that IIRC Microsoft made Windows automatically detect when an important operating system DLL had been overwritten, and restore it from a secret copy of the original DLL it had stashed elsewhere.

> It used to be very common for every program you installed to dump several libraries in that directory.

Maybe back on Windows 95? Hasn’t been the case or an issue in as long as I can remember.

> It's called "DLL Hell" for a reason.

Linux shared library hell is at least a full order of magnitude more complex, fragile, and error prone. Launching a Linux program is so outrageously unreliable that everyone uses Docker just to run a bloody program! It’s so so bad. At least in the year two thousand and twenty four.

Programs potentially duplicating dependencies at a quadratic rate is an equally abject failure. It's the other extreme of the dependency sharing spectrum. Share, but don't overshare. If two programs share a dependency, and that dependency is the exact same (by content or by its inputs, when using a pure build system), they may share the dependency. If not, you install the dependency "twice" (it's not really twice, because it's not the same dependency, so two dependencies, each installed once).

> at a quadratic rate

wat?

Worst case is linear. Every program duplicates everything it needs. Which honestly is just totally fine.

How is this quadratic?

Quadratic in the sense that, in the worst case, you have N programs sharing the same set of M dependencies, requiring N*M components worth of space. With sharing, it would only be N+M.

Ah yeah. Feels like you could argue either way!

In any case I don’t think library duplication is a meaningful issue in most cases. As evidenced by everyone using Docker which duplicates libraries!

Feels like this could be totally solved at the filesystem level with copy-on-write de-duplication. The best of both worlds!

FS deduplication solves the problem at the storage level, but not at the transfer level. The components would still be downloaded multiple times if the downloader doesn't have a way to know what has already been downloaded.

Docker's way of doing things is basically an admittance of defeat by lazy engineers. We can do better than that.

In this example the problem is caused by the dynamic linker shipping with a hard glibc dependency, so FHS doesn't really change much.

Setting LD_LIBRARY_PATH pretty much solves any FHS problem once you get past the linker.

The dynamic linker is part of glibc, so if you're shipping multiple glibcs, ship multiple dynamic linkers as well and let each application use the linker it needs.

LD_LIBRARY_PATH users deserve the death sentence.

Why? It’s just PATH for libraries.

Because it's an environment variable, and thus will have an (often undesired) effect on child processes. This information should instead be encoded into the binaries and libraries themselves, with things like DT_RUNPATH and DT_RPATH.

What is FHS?

https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...

Reply on news.ycombinator.com