> An actual civilized solution would involve a manifest of external resources, a lockfile, and a little library of instructions that the tooling could use to fe

> An actual civilized solution would involve a manifest of external resources, a lockfile, and a little library of instructions that the tooling could use to fetch or build those external resources. Sounds like you're describing Nix. I actually thought the article would be framed a bit differently when I saw the title: I think Docker and its ecosystem solve several adjacent but not intrinsically intertwined problems: - Creating repeatable or ideally reproducible runtime environments for applications (via Dockerfiles) - Isolating applications' runtime environments (filesystems, networks, etc) from one another (via the Docker container runtime) - Specifying a common distribution format for applications and their runtime environments (via Docker images) - Providing a runtime to actually run applications in (via the Docker CLI and Docker Desktop) In this context, a runtime environment consists of the application's dependencies, its configuration files, its temporary and cache files, its persistent state (usually via a volume or bind mount), its exposed ports, and so on. I would argue that Docker is often used solely for dependency management and application distribution, and for such use cases things like network and filesystem isolation just present obstacles to be worked around, and this is why developers complain about Docker's complexity.