Live data from Hacker News

A decade of Docker containers

cacm.acm.org

91–100 of 275 posts

Re: A decade of Docker containers

#91
post #79
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?

LLMs are getting very good at packaging software using Nix.

This. I wouldn't have touched Nix when you needed someone who was really good at Nix to keep it working, but agents make it viable to use in a number of place.

Re: A decade of Docker containers

#92

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

I'm curious why. To me "We updated our library to change some things in a way that's an improvement on net but only mostly backwards compatible" seems like an extremely common instinct in software development. But in an environment where people are doing that all the time, the only way to reliably deploy software is to completely freeze all your direct and indirect dependencies at an exact version. And Docker is way better at handling that than traditional Linux package managers are.

Why do you think other tools will make a comeback?

Re: A decade of Docker containers

#93
post #80
post #28

An extremely random fact I noticed when writing the companion article [1] to this (an OCaml experience report): "Docker, Guix and NixOS (stable) all had their first releases during 2013, making that a bumper year for packaging aficionados." Now we get coding agent updates every week, but has there been a similar year since 2013 where multiple great projects all came out at the same time? [1]: https://anil.recoil.org/…

TBH I feel as if only docker belongs in that list. Guix and nix have users, sure, but not remotely like docker.

Yeah they are way better than docker for packaging

Re: A decade of Docker containers

#94

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…

You can pretty much replace "docker build" with "go build". But as long as people want to use scripting languages (like php, python etc) i guess docker is the neccessary evil.

Go is just one language, while Dockerfile gives you access to the whole universe with myriads of tools and options from early 1970s and up to the future. I don't know how you can compare or even "replace" Docker with Go; they belong to different categories.

Re: A decade of Docker containers

#95
post #5

A full decade since we took the 'it works on my machine' excuse and turned it into the industry standard architecture ('then we'll just ship your machine to production').

I see this take a lot but I'd argue what Docker did was to entice everyone to capture their build into a repeatable process (via a Dockerfile). "Ship your machine to production" isn't so bad when you have a ten-line script to recreate the machine at the push of a button.

Exactly my feeling. Docker is "works on this machine" with an executable recipe to build the machine and the application. Newer better solutions like OCI-compliant tools will gradually replace Docker, but the paradigm shift has provided a lot of lasting value.

Re: A decade of Docker containers

#96
post #73

I dont use Dockerfile. Am i slumming it?

Probably? How do you deploy?

Just pull a tarball from a signed URL, install deps, and run from systemd. Rolls out in 30 seconds, remarkably stable. Initial bootstrap of deps/paths is maybe 5 minutes.

Re: A decade of Docker containers

#97
I am so thoroughly convinced that Docker is a hacky-but-functional solution to an utterly failed userspace design.

Linux user space decided to try and share dependencies. Docker obliterates this design goal by shipping dependencies, but stuffing them into the filesystem as-if they were shared.

If you’re going to do this then a far far far simpler solution is to just link statically or ship dependencies adjacent to the binary. (Aka what windows does). Replicating a faux “shared” filesystem is a gross hack.

This is a distinctly Linux problem. Windows software doesn’t typically have this issue. Because programs ship their dependencies and then work.

Docker is one way to ship dependencies. So it’s not the worst solution in the world. But I swear it’s a bad solution. My blood boils with righteous fury anytime anyone on my team mentions they have a 15 minute docker build step. And don’t you damn dare say the fix to Docker being slow is to add more layers of complexity with hierarchical Docker images ohmygodiswear. Running a computer program does not have to be hard I promise!!

Re: A decade of Docker containers

#99
post #78

Earlier quoted context omitted.

Nix is exceptionally good at making docker containers.

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?

I use software from pretty much every language with Nix. And I package it myself too when needed. Including Python often :)
Post reply on HN