3 ms·

Wait wait wait. Docker has two use cases and you're conflating them. The original use case is: Project Foo uses libqxt version 7. Project Bar uses libqxt versi

Wait wait wait. Docker has two use cases and you're conflating them. The original use case is: Project Foo uses libqxt version 7. Project Bar uses libqxt version 8. They are incompatible so I'd need two development workstations (or later two LXC containers). This is slow and heavy on diskspace; docker solves that problem. This is a great use of docker. The second use case that it has morphed into is: I've decided stack management is hard and I can't tell my downstream which libraries they need because even I'm no longer sure. So I'll just bundle them all as this opaque container and distribute it that way and now literally nobody knows what versions of what software they are running in production. This is a very harmful use case of docker that is unfortunately nearly universal at this point.

jbverschoor 3y ago
> Project Foo uses libqxt version 7. Project Bar uses libqxt version 8 Pretty much fixed by asdf or any sane manager.. Also, two containers aren't slow at all, but rebuilding one completely from scratch is. The latter is a good use case. No big deal to include a commit/version number, and a list of packages / libraries used in a lock file.. The problems with docker I have are: no lock files to pin versions. No integration with other package management tools. For example, I want to install my dependencies as a step in Docker. I don't want to manually copy over the list of dependencies from my lockfiles (gemfile, package, etc). The reason why I'd want this is that it speeds up builds.
zaptheimpaler 3y ago
I don't understand how stack management without Docker is any better. As far as I can tell, the alternative without Docker is the same. A list of `apt install`s with no versions listed or no mention of dependencies at all. If you used a lockfile in a language package manager, you can use the same lockfile in the docker too.
- bandrami 3y ago
  So, as an example, 20 years ago when we started a project the devs and I (the sysadmin) would sit down and have a meeting where they would talk about what libraries they wanted to use (think CPAN or PEAR) and I would tell them what versions were compatible with our servers and those are the versions they would use for the lifetime of the project. Docker came about because devs got tired of hearing "no" to upgrades and admins got tired of saying it. But in 2023 if there was a zero day (though we didn't call them that back then) for libqxt7.2 (but not 7.0 or 8.1) I could tell you immediately if we were impacted. In 2023 I can't even tell you how many versions of OpenSSL are on my laptop right now as I type.
TeMPOraL 3y ago
Stack management is a bullshit job, and the downstream will hit the libqxt-7 vs libqxt-8 problem anyway.

jbverschoor 3y ago

> Project Foo uses libqxt version 7. Project Bar uses libqxt version 8 Pretty much fixed by asdf or any sane manager.. Also, two containers aren't slow at all, but rebuilding one completely from scratch is. The latter is a good use case. No big deal to include a commit/version number, and a list of packages / libraries used in a lock file.. The problems with docker I have are: no lock files to pin versions. No integration with other package management tools. For example, I want to install my dependencies as a step in Docker. I don't want to manually copy over the list of dependencies from my lockfiles (gemfile, package, etc). The reason why I'd want this is that it speeds up builds.

zaptheimpaler 3y ago

I don't understand how stack management without Docker is any better. As far as I can tell, the alternative without Docker is the same. A list of `apt install`s with no versions listed or no mention of dependencies at all. If you used a lockfile in a language package manager, you can use the same lockfile in the docker too.

bandrami 3y ago
So, as an example, 20 years ago when we started a project the devs and I (the sysadmin) would sit down and have a meeting where they would talk about what libraries they wanted to use (think CPAN or PEAR) and I would tell them what versions were compatible with our servers and those are the versions they would use for the lifetime of the project. Docker came about because devs got tired of hearing "no" to upgrades and admins got tired of saying it. But in 2023 if there was a zero day (though we didn't call them that back then) for libqxt7.2 (but not 7.0 or 8.1) I could tell you immediately if we were impacted. In 2023 I can't even tell you how many versions of OpenSSL are on my laptop right now as I type.

TeMPOraL 3y ago

Stack management is a bullshit job, and the downstream will hit the libqxt-7 vs libqxt-8 problem anyway.