3 ms·

The Linux model of global shared libraries is an objective failure. Everyone is forced to hack around this bad and broken design by using tools like Docker.

davexunit 2y ago
It's not the "Linux model". It's an antiquated distro model that has been superseded by distros like Guix and NixOS that have shown you can still have an understandable dependency graph of your entire system without resorting to opaque binary blobs with Docker.
- forrestthewoods 2y ago
  [flagged]
  - davexunit 2y ago
    I use Guix. Have a nice day.
- pjmlp 2y ago
  When will AWS, Azure, GCP adopt such great distros?
  - davexunit 2y ago
    I know this is not a good faith question but I did devops for many years and the state of the tooling and culture is so atrocious that I don't know if they will ever catch on. They're all lost in a swamp of YAML and Dockerfiles, a decade or more behind the rest of the industry in terms of software engineering knowledge. No one ever had any clue when I tried to talk to them about functional and immutable package management.
    - pjmlp 2y ago
      It is a remark in form of question, pointing out that Nix/Guix are 3l1t3, and will never achieve the adoption scale of Red-Hat, Debian, Arch, SusSE, Alpine, or the hyperscalers own distributions.
      - davexunit 2y ago
        I don't think Nix or Guix are particularly "3l1t3". They are less mainstream, but they have users of varying technical backgrounds.
c0l0 2y ago
And what is it that makes the *inside* of all (read: almost all) these nice and working Docker/container images tick? Distributions using a "model of global shared libraries".
- int_19h 2y ago
  Except that it's usually completely wasted on a Docker container. You could as well just statically link everything (and people do that).
- forrestthewoods 2y ago
  Uhh no? If you have to run 5 different docker images each with their own “global shared library” set you clearly no longer have system wide globals. You have an island of deps potentially per program or possible a few islands for a few sets of programs. Which, once again, completely defeats the entire purpose of the Linux global shared library model. It would have been much much much simpler for each program to have linked statically or to expect programs to include their dependencies (like Windows). Containers should not exist. The fact that they exist is a design failure.
  - davexunit 2y ago
    Static linking is acceptable when you can update a version of a library in one place and it will trigger rebuilds of all dependent software, ensuring things like security updates are delivered system-wide with confidence. The Windows every-app-is-an-island model makes you reliant on every app developer for updates to the entire dependency graph, which in practice means you have a hodge podge of vulnerable stuff.
yjftsjthsd-h 2y ago
It's okay, docker is also an failure, because it relies and random parties to package things up into container images and then keep the result up to date. Given the number of Dockerfiles I've seen that do charming things like include random binary artifacts and pinned versions that will probably never be checked for security updates, I tend to prefer the distro packages.
- woodruffw 2y ago
  That's a "catastrophic success," not a failure. I wish people would interrogate this more deeply: why do we see so many Dockerfiles with random binary artifacts? Why do people download mystery meat binaries from GitHub releases? Why is curl-pipe-to-bash such a popular pattern? The answer to the questions is that, with few exceptions, distributions are harder to package for, both in first- and third-party contexts. They offer fewer resources for learning how to package, and those resources that do exist are largely geared towards slow and stable foundational packaging (read: C and C++ libraries, stable desktop applications) and not the world of random (but popular) tools on GitHub. Distribution packaging processes (including human processes) similarly reflect this reality. On one level, this is great: like you, I strongly prefer a distro package when it's available, because I know what I'm going to get. But on another level, it's manifestly not satisfying user demand, and users are instead doing whatever it takes to accomplish the task at hand. That seems unlikely to change for the better anytime soon.
oneshtein 2y ago
It means that Everyone is now the maintainer of his own distro fork.

davexunit 2y ago

It's not the "Linux model". It's an antiquated distro model that has been superseded by distros like Guix and NixOS that have shown you can still have an understandable dependency graph of your entire system without resorting to opaque binary blobs with Docker.

forrestthewoods 2y ago
[flagged]
- davexunit 2y ago
  I use Guix. Have a nice day.
pjmlp 2y ago
When will AWS, Azure, GCP adopt such great distros?
- davexunit 2y ago
  I know this is not a good faith question but I did devops for many years and the state of the tooling and culture is so atrocious that I don't know if they will ever catch on. They're all lost in a swamp of YAML and Dockerfiles, a decade or more behind the rest of the industry in terms of software engineering knowledge. No one ever had any clue when I tried to talk to them about functional and immutable package management.
  - pjmlp 2y ago
    It is a remark in form of question, pointing out that Nix/Guix are 3l1t3, and will never achieve the adoption scale of Red-Hat, Debian, Arch, SusSE, Alpine, or the hyperscalers own distributions.
    - davexunit 2y ago
      I don't think Nix or Guix are particularly "3l1t3". They are less mainstream, but they have users of varying technical backgrounds.

c0l0 2y ago

And what is it that makes the *inside* of all (read: almost all) these nice and working Docker/container images tick? Distributions using a "model of global shared libraries".

int_19h 2y ago
Except that it's usually completely wasted on a Docker container. You could as well just statically link everything (and people do that).
forrestthewoods 2y ago
Uhh no? If you have to run 5 different docker images each with their own “global shared library” set you clearly no longer have system wide globals. You have an island of deps potentially per program or possible a few islands for a few sets of programs. Which, once again, completely defeats the entire purpose of the Linux global shared library model. It would have been much much much simpler for each program to have linked statically or to expect programs to include their dependencies (like Windows). Containers should not exist. The fact that they exist is a design failure.
- davexunit 2y ago
  Static linking is acceptable when you can update a version of a library in one place and it will trigger rebuilds of all dependent software, ensuring things like security updates are delivered system-wide with confidence. The Windows every-app-is-an-island model makes you reliant on every app developer for updates to the entire dependency graph, which in practice means you have a hodge podge of vulnerable stuff.

yjftsjthsd-h 2y ago

It's okay, docker is also an failure, because it relies and random parties to package things up into container images and then keep the result up to date. Given the number of Dockerfiles I've seen that do charming things like include random binary artifacts and pinned versions that will probably never be checked for security updates, I tend to prefer the distro packages.

woodruffw 2y ago
That's a "catastrophic success," not a failure. I wish people would interrogate this more deeply: why do we see so many Dockerfiles with random binary artifacts? Why do people download mystery meat binaries from GitHub releases? Why is curl-pipe-to-bash such a popular pattern? The answer to the questions is that, with few exceptions, distributions are harder to package for, both in first- and third-party contexts. They offer fewer resources for learning how to package, and those resources that do exist are largely geared towards slow and stable foundational packaging (read: C and C++ libraries, stable desktop applications) and not the world of random (but popular) tools on GitHub. Distribution packaging processes (including human processes) similarly reflect this reality. On one level, this is great: like you, I strongly prefer a distro package when it's available, because I know what I'm going to get. But on another level, it's manifestly not satisfying user demand, and users are instead doing whatever it takes to accomplish the task at hand. That seems unlikely to change for the better anytime soon.

oneshtein 2y ago

It means that Everyone is now the maintainer of his own distro fork.