4 ms·

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

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.

predictabl3 3y ago
>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.

predictabl3 3y ago

>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.