A decade of Docker containers

Post by jjmarr » Sun, Mar 08, 2026, 6:59 AM UTC

silverstream wrote: post #189

forrestthewoods wrote: post #170

Earlier quoted context omitted.

> This nuance is something that only the nix model started to capture at all. Unpopular opinion, loosely held: the whole attempt to share any dependencies at all is the source of evil. If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data? Which could plausible be deduped at the filesys…

Node.js basically tried this — every package gets its own copy of every dependency in node_modules. Worked great until you had 400MB of duplicated lodash copies and the memes started. pnpm fixed it exactly the way you describe though: content-addressable store with hardlinks. Every package version exists once on disk, projects just link to it. So the "dedup at filesystem level" approach does work, it just took the ec…

Post by hrmtst93837 » Sun, Mar 08, 2026, 7:22 AM UTC

mihaelm wrote: post #23

the__alchemist wrote: post #3

I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through registries and management through runtimes, a lot of operational headaches just go away when using a container orchestrator. Not to mention better utilization of hardware since containers are more lightweight than VMs.

Post by saghm » Sun, Mar 08, 2026, 7:32 AM UTC

gnull wrote: post #123

Spivak wrote: post #78

Earlier quoted context omitted.

Yes but then you're committed to using Nix which doesn't work so well the moment you need some software not packaged by Nix. Want to throw a requirements.txt in there? No no, why would you even ask that? Meanwhile docker says yeah sure just run pip install, why should I care?

Packaging for nix is exceptionally easy once you learn it. And once something is packaged, it's solved for all, it's not going to randomly break. If you care about getting it to work with minimal effort right now more thar about it being sustainable later, then sure.

Post by JodieBenitez » Sun, Mar 08, 2026, 7:45 AM UTC

eudamoniac wrote: post #173

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up t…

Post by _the_inflator » Sun, Mar 08, 2026, 8:54 AM UTC

kccqzy wrote: post #120

bmitch3020 wrote: post #26

I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…

> But the Dockerfile has continued because of its flexibility. The flip side is that the world still hasn’t settled on a language-neutral build tool that works for all languages. Therefore we resort to running arbitrary commands to invoke language-specific package managers. In an alternate timeline where everyone uses Nix or Bazel or some such, docker build would be laughed out of the window.