4 ms·

>Despite its problems, it is an approximation to a packaging standard which provides enough isolation to manage dependencies successfully. Docker is ultimately

>Despite its problems, it is an approximation to a packaging standard which provides enough isolation to manage dependencies successfully. Docker is ultimately a non-solution that papers over the problems of traditional system package managers, language-specific package managers, and the myriad of software (mostly Java) that no one actually knows how to build from source. Containers do not compose. There are many runtime environments to consider, and Docker can't handle anything but containers. You need to use some other software to manage the host system at the very least. Furthermore, the container images have no useful provenance for users to inspect. It's a security nightmare. Functional package management is the real solution here. Software like GNU Guix and Nix solve real problems. They remove global state (/usr), enable reproducible builds, allow unprivileged package management, support transactional upgrades and roll backs, deduplicate software system-wide for all users, handle full-system configuration in a declarative way, eliminate the need to trust any particular provider of binaries, and more. >Does anyone not remember what it was like to fight shared library versioning conflicts? Using Docker to solve this problem is like using a sledgehammer to drive a nail.

eropple 11y ago
> Docker is ultimately a non-solution that papers over the problems of traditional system package managers, language-specific package managers, and the myriad of software (mostly Java) that no one actually knows how to build from source. It's interesting that you saythis--I would say almost the exact opposite here: most of the Java applications are the best-behaved on systems I deal with, both in terms of execution (it's in the Maven repo) and in terms of process control (cgroups are nice for, like, a Ruby app, but here I've got -Xmx). The poorly behaved ones seem to be ones that don't use standard tools, and maybe I've been lucky but for me that's all third-party and mostly open-source stuff; a lot of new-hotness stuff (Kafka, I am looking at you, I love you but you are a pain in the behind to deploy) can't just be run straight out of the Maven repository with a bash script or whatever. About the only place I use containerization at all (and I don't use Docker, for reasons I've described elsewhere around here) is for Ruby or Python applications where otherwise I do end up with stuff thrown all over the place and multiple versions of the runtime fighting for supremacy. I'd love to use Guix/Nix, but it's a hard fight to win in a corporate environment. > Using Docker to solve this problem is like using a sledgehammer to drive a nail. I wish to upvote this eleven times. I can but do so only once.
- thinkpad20 11y ago
  > I'd love to use Guix/Nix, but it's a hard fight to win in a corporate environment. I don't know how large or flexible your organization is, but I've been driving hard at my company (which is a bit shy of 100 employees) for using nix, and it's working. When I started advocating for it there was no small amount of skepticism, but we started off just using it for a very small and specific use case, and from there it has slowly but steadily gained acceptance from other developers (most of whom have no particular interest in FP) as a real solution to innumerable problems that we have w.r.t. package management. If you're interested in Guix/Nix, I'd encourage trying to get permission to use it to solve a specific problem.
  - eropple 11y ago
    I'm a consultant. While I can push for a lot if it's conventional, but I have to pick my battles. That's not one I feel I can win.

eropple 11y ago

> Docker is ultimately a non-solution that papers over the problems of traditional system package managers, language-specific package managers, and the myriad of software (mostly Java) that no one actually knows how to build from source. It's interesting that you saythis--I would say almost the exact opposite here: most of the Java applications are the best-behaved on systems I deal with, both in terms of execution (it's in the Maven repo) and in terms of process control (cgroups are nice for, like, a Ruby app, but here I've got -Xmx). The poorly behaved ones seem to be ones that don't use standard tools, and maybe I've been lucky but for me that's all third-party and mostly open-source stuff; a lot of new-hotness stuff (Kafka, I am looking at you, I love you but you are a pain in the behind to deploy) can't just be run straight out of the Maven repository with a bash script or whatever. About the only place I use containerization at all (and I don't use Docker, for reasons I've described elsewhere around here) is for Ruby or Python applications where otherwise I do end up with stuff thrown all over the place and multiple versions of the runtime fighting for supremacy. I'd love to use Guix/Nix, but it's a hard fight to win in a corporate environment. > Using Docker to solve this problem is like using a sledgehammer to drive a nail. I wish to upvote this eleven times. I can but do so only once.

thinkpad20 11y ago
> I'd love to use Guix/Nix, but it's a hard fight to win in a corporate environment. I don't know how large or flexible your organization is, but I've been driving hard at my company (which is a bit shy of 100 employees) for using nix, and it's working. When I started advocating for it there was no small amount of skepticism, but we started off just using it for a very small and specific use case, and from there it has slowly but steadily gained acceptance from other developers (most of whom have no particular interest in FP) as a real solution to innumerable problems that we have w.r.t. package management. If you're interested in Guix/Nix, I'd encourage trying to get permission to use it to solve a specific problem.
- eropple 11y ago
  I'm a consultant. While I can push for a lot if it's conventional, but I have to pick my battles. That's not one I feel I can win.