251–260 of 275 posts
Earlier quoted context omitted.
It is mateirially different compared to "maintaining" the line 'RUN apt-get -y install foobar'
Is it though? If the way that I’m going to edit those files is by typing the same natural language command into Claude code, and the edit operation to maintain it takes 20 seconds instead of 10, to me that seems pretty materially the same
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').
(coauthor of the article here) Well, before Docker I used to work on Xen and that possible future of massive block devices assembled using Vagrant and Packer has thankfully been avoided... One thing that's hard to capture in the article -- but that permeated the early Dockercons -- is the (positive) disruption Docker had in how IT shops were run. Before that going to production was a giant effort, and 'shipping your…
Earlier quoted context omitted.
The first half of my career was spent shipping video games. There is no such thing as shipping a game in Docker. Not even on Linux. You depend on minimum version of glibc and then ship your damn dependencies. The more recent half of my career has been more focused on ML and now robotics. Python ML is absolute clusterfuck. It is close to getting resolved with UV and Pixi. The trick there is to include your damn depend…
What's your take on WASM/WASI?
Part of it is ignorance. I write a lot of C++. They support C++…. but with all kinds of restrictions wrt to memory and threading?
Doesn’t seem like a particularly interesting angle to me.
Didn't Vagrant/Vagrantfiles precede Docker? Unclear why that would be the key to its success if so.
Vagrant was a layer over virtualization, with hypervisors like virtualbox, kvm or vmware. The article mention virtualization and virtual machines several times, e.g. "unlike the virtual machine experience (which involved installing an entire operating system)". For instance, deploying a complex Python application was hell, for lack of proper packaging. Using Vagrant was easy, but the image was huge (full system) and…
Earlier quoted context omitted.
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…
You can write any software you want without worrying about depending on a specific set of system dependencies. I like software that "just works", and making something that will give you inscrutable linking or dependency errors if the OS isn't set up just so is a practice I think should go away.
Earlier quoted context omitted.
> the Dockerfile has continued because of its flexibility I wish we had standardized on something other than shell commands, though. Puppet or terraform or something more declarative would have been such a better alternative to “everyone cargo cults ‘RUN apt-get upgrade’ onto the top of their dockerfiles”. Like, the layer/stage/caching behavior is fine. I just wish the actual execution parts had been standardized usi…
Dockerfile has the flexibility to do what you want though, no? Use a base image with terraform or puppet or opentofu or whatever pre-installed, then your Dockerfile can just run the right command to apply some declarative config file from the build context. And if you want something weird that's not supported by your particular tool of choice, you have the escape hatch of running arbitrary commands in the Dockerfile.…
Earlier quoted context omitted.
But they’re roughly the same paradigm as docker, right? My understanding of the Nix approach is that it’s still reproducing most of a user land/filesystem in a captive/separate/sandbox environment. Like, docker is using namespaces for more stuff, Nix has a heavier emphasis on reproducibility/determinism, but … they’re both still throwing in the towel on deploying directly on the underlying OS’s userland (unless you g…
> But they’re roughly the same paradigm as docker, right? Absolutely not. Nix and Guix are package managers that (very simplified) model the build process of software as pure functions mapping dependencies and source code as inputs to a resulting build as their output. Docker is something entirely different. > they’re both still throwing in the towel on deploying directly on the underlying OS’s userland The existence…
The rest of your endorsement of NixOS is well taken, but this is a silly distinction to draw. Dockerfiles and nix package definitions are extremely similar. The fact that docker images are distributed with a heavier emphasis on opaque binary build step caching, and nix expressions have a heavier emphasis on code-level determinism/purity is accidental. The output of both is some form of a copy of a Linux user space “in a box” (via squashfs and namespaces for Docker, and via path hacks and symlinks for Nix). Zoom out even a little and they look extremely alike.
Earlier quoted context omitted.
> 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.
There is some truth to it, however in production it is simple: There is a working deployment or not. Therefore I would rephrase your remarks as upside: let others continue scratch their head while others deploy working code to PROD. I am glad there is a solution like Docker - with all it flaws. Nothing is flawless, there is always just yet another sub-optimal solution weighting out the others by a large margin.
> let others continue scratch their head while others deploy working code to PROD.
You make it sound like when docker build arrived on the scene, a cross-language hermetic build tool was still a research project. That’s just untrue.
Earlier quoted context omitted.
> You can pretty much replace "docker build" with "go build". Interesting. How does go build my python app?
It obviously means you dont use a scripting language, instead use a real langauge with a compiler.
Real languages don't let errors go silently unnoticed.
Earlier quoted context omitted.
Why is docker used by far the most, then?
Laziness
easy but powerful, it's not just packaging, it's also a very basic deployment system too. (docker ps) and said better allowed a relatively foolproof cross-platform develop-deploy loop.