3 ms·

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

pjc50 2y ago
As opposed to what? Every distro puts their files in a different place, making even more of a nightmare for software maintainers?
- HexDecOctBin 2y ago
  No, all software goes into subdirectories of "Program Files", instead of being strewn around in a dozen directories.
  - max-privatevoid 2y ago
    This but without the Microsoftisms, and every component directory is immutable, and maximal sharing is encouraged.
- max-privatevoid 2y ago
  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.
  - pjc50 2y ago
    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.
    - max-privatevoid 2y ago
      And those assumptions often end up being wrong. There will always be differences between distros. Ensure, don't assume.
- forrestthewoods 2y ago
  > 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.
  - cesarb 2y ago
    > 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.
    - forrestthewoods 2y ago
      > 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.
  - max-privatevoid 2y ago
    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).
forrestthewoods 2y ago
What is FHS?
- PhilipRoman 2y ago
  https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
jeroenhd 2y ago
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.
- max-privatevoid 2y ago
  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.
  - pizzalife 2y ago
    Why? It’s just PATH for libraries.
    - max-privatevoid 2y ago
      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.

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

HexDecOctBin 2y ago
No, all software goes into subdirectories of "Program Files", instead of being strewn around in a dozen directories.
- max-privatevoid 2y ago
  This but without the Microsoftisms, and every component directory is immutable, and maximal sharing is encouraged.
max-privatevoid 2y ago
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.
- pjc50 2y ago
  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.
  - max-privatevoid 2y ago
    And those assumptions often end up being wrong. There will always be differences between distros. Ensure, don't assume.
forrestthewoods 2y ago
> 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.
- cesarb 2y ago
  > 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.
  - forrestthewoods 2y ago
    > 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.
- max-privatevoid 2y ago
  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).

forrestthewoods 2y ago

What is FHS?

PhilipRoman 2y ago
https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...

jeroenhd 2y ago

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.

max-privatevoid 2y ago
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.
- pizzalife 2y ago
  Why? It’s just PATH for libraries.
  - max-privatevoid 2y ago
    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.