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.
A decade of Docker containers
91–100 of 275 posts
Re: A decade of Docker containers
#92I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.
Why do you think other tools will make a comeback?
Re: A decade of Docker containers
#93An 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.
Re: A decade of Docker containers
#94I'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.
Re: A decade of Docker containers
#95A 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.
Re: A decade of Docker containers
#96Re: A decade of Docker containers
#97Linux 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
#98Re: A decade of Docker containers
#99Earlier 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?
Re: A decade of Docker containers
#100I now wonder if we'll end up switching it all back to VMs so the LLMs have enough room to grow and adapt.