5 ms·

Despite its problems, it is an approximation to a packaging standard which provides enough isolation to manage dependencies successfully. Does anyone not remem

by pekk 11y ago

Despite its problems, it is an approximation to a packaging standard which provides enough isolation to manage dependencies successfully. Does anyone not remember what it was like to fight shared library versioning conflicts? Do you want to be handling the GitHub issues attached to people screwing up that kind of thing in 2017 because their distribution or OS X package manager randomly changed?

XorNot 11y ago
Docker lets you setup a runtime environment by doing whatever is necessary to make it work, with the huge benefit that you don't wind up breaking the rest of the same system for running anything else.
- Annatar 11y ago
  > Docker lets you setup a runtime environment by doing whatever is necessary to make it work Does that not qualify as "hack-it-'till-it-works", the worst kind of computer activity, especially when one is stuck trying to reverse engineer what the guy before did? Can you think of what implications "doing whatever is necessary to make it work" has for lifecycle management?
davexunit 11y ago
>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.
creshal 11y ago
It's not like Docker is the only way to deploy and use containers. Between nspawn, LXC, the various BSD systems, and a few others I forget, we have plenty of choice for containerization. And Dockerfiles are both poor at being universal enough to serve as blueprints, and at being flexible enough to be useful by themselves.
vacri 11y ago
Docker is good for certain use-cases, but packaging isn't one of them. In addition to the other replices, the terrible labelling system is one of it's problems in relation to packaging.
Annatar 11y ago
> Does anyone not remember what it was like to fight shared library versioning conflicts? Nope, because on Solaris and illumos based systems like SmartOS, OS libraries are backwards compatible. As long as I build on an ancient version of Solaris 10, the Solaris ABI guarantees me that my applications will continue to run unmodified on the latest, ultramodern SmartOS. So no unnecessary pain.
- pekk 11y ago
  How long has the entire universe been using only Solaris and Illumos based systems like SmartOS?
  - Annatar 11y ago
    I do not know; I have been using Solaris since 1993, so that would make it 23 years. Seeing as how Solaris / illumos has code all the way from AT & T from 1979, I'd say... 37 years? I am not sure where this question is going, though.

by pekk 11y ago

XorNot 11y ago

Docker lets you setup a runtime environment by doing whatever is necessary to make it work, with the huge benefit that you don't wind up breaking the rest of the same system for running anything else.

Annatar 11y ago
> Docker lets you setup a runtime environment by doing whatever is necessary to make it work Does that not qualify as "hack-it-'till-it-works", the worst kind of computer activity, especially when one is stuck trying to reverse engineer what the guy before did? Can you think of what implications "doing whatever is necessary to make it work" has for lifecycle management?

davexunit 11y ago

>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.

creshal 11y ago

It's not like Docker is the only way to deploy and use containers. Between nspawn, LXC, the various BSD systems, and a few others I forget, we have plenty of choice for containerization. And Dockerfiles are both poor at being universal enough to serve as blueprints, and at being flexible enough to be useful by themselves.

vacri 11y ago

Docker is good for certain use-cases, but packaging isn't one of them. In addition to the other replices, the terrible labelling system is one of it's problems in relation to packaging.

Annatar 11y ago

> Does anyone not remember what it was like to fight shared library versioning conflicts? Nope, because on Solaris and illumos based systems like SmartOS, OS libraries are backwards compatible. As long as I build on an ancient version of Solaris 10, the Solaris ABI guarantees me that my applications will continue to run unmodified on the latest, ultramodern SmartOS. So no unnecessary pain.

pekk 11y ago
How long has the entire universe been using only Solaris and Illumos based systems like SmartOS?
- Annatar 11y ago
  I do not know; I have been using Solaris since 1993, so that would make it 23 years. Seeing as how Solaris / illumos has code all the way from AT & T from 1979, I'd say... 37 years? I am not sure where this question is going, though.