Not to mention accordingly to highly scientific calculations "damn near" every Dockerfile runs `apt-get update` as a first step, so the, you know, core valuation is questionable from the outset.

There is value in making things "more reproducible" even if you don't achieve "total reproducibility". Even just having a basic layer of extra isolation from the host system (even when updating everything at will without pinned versions) can be enough to motivate the tool's usage. There are varying degrees of reasonable pragmatism in different situations. Heck some people even decide not to use containers at all, and some of those even have well-motivated reasons for this choice!

(And will this stuff even still run on chips 10-20 years from now anyway? Is there maybe a practical limit to reproducibility?)

>And will this stuff even still run on chips 10-20 years from now anyway?

NixOS Con Paris had a talk running a decade+ old version of Firefox, complete with Flash.

True, but bare metal systems also receive those updates on a regular basis, and containers need security updates too. Unless you're willing to throw it all out and use NixOS you're not going to solve that problem. And if you do, you're opting into far more work since you've just thrown out every standard package management solution and install or setup instructions you were previously relying on and you've just became a pain in the ass to your coworkers and ops teams who haven't drank that koolaid with you.

Personally, I've never once ran into an issue where updating Debian packages in a Docker image impacted my daily life. I'm sure there's some anecdotes and greater than zero potential for it but it just doesn't seem like a major issue anywhere. Docker and Dockerfiles are a practical and low-friction means of getting install steps documented and it's generally a step up over what is normally done. I'm not going to let perfect be the enemy of good and will gladly deal with a Dockerfile that updates its packages first over a markdown file that does nothing.

>Unless you're willing to throw it all out and use NixOS you're not going to solve that problem.

Well, I have been running NixOS systems for nearly a decade, and now have it deployed across 3 cpu archs in 3 continents. :) Tailscale also uses NixOS in prod, etc.

Not to mention, NixOS means: no docker hub/repo, all you need is a dumb blob store, no container signing, no complicated tooling for BOM or source provination, or tooling for version dep analysis. Much of the entire Golang/K8s devops-startup-chasing/adjacent ecosystem is obliviated by first-order Nix features. You don't have to think about container bloat, or container optimization, storage on nodes is cheaper; it's really hard to name an area that isn't strictly better other than "yes, you have to learn more than running an imperative bash script and capturing the tar filesystem". But, maybe there's good reasons for that. I've personally also sheparded probably half a dozen or more users into full-time contributors, so I know it's not impossible.

When Tvix hits with their NAR alternative, a number of other benefits are just going to start appearing for Nix users that try to adopt it. Much, much faster path downloads, significantly more on-disk de-duplication "for free", much better options for potential P2P replication, etc.