> Nix has been around for two decades. It's more appropriate to ask what was the point of creating Docker, Ansible, virtualenv, etc. when Nix already existed.

> Nix has been around for two decades. It's more appropriate to ask what was the point of creating Docker, Ansible, virtualenv, etc. when Nix already existed. I'd say that the relative popularity of the tools is an indication of how well suited they were for the things that people actually wanted to do. Nobody (exaggerating here for dramatic effect, but it probably applies to a large part of the unseen 99%: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...) wants to have fully reproducible builds and a unified language for configuring everything like Nix attempts to do, or even have an OS that attempts to centralize those concepts, like NixOS does because a lot of it is alien to them. They just want to run their PHP CRUD app in a vaguely predictable way that is less painful than what they've historically done (ship scripts through FTP, experience pain due to php.ini being different, or a system package not being present, or the system package being of a different version). Docker and other solutions like it are the closest that they can get to shipping their machine to prod, given that shipping VMs has more challenges, than just telling their clients or even their ops to just run a Docker container with some configuration. Nor do they want rootless containers, or distroless containers or Podman or any of the other fancy solutions - they just want their Ubuntu userland and their app to sort of work, most of the time. We had containers in one way or another long before Docker, for example, FreeBSD jails were pretty good. And yet, they never caught on, nor did FreeBSD outside of large corporations, because for the most part the developer experience just wasn't there. Then came along Docker and changed everything (with plenty of bumps along the way), now building and running your app is pretty simple: 1. nano Dockerfile 2. docker build -t some_image_tag . 3. docker run some_image_tag (or, you know, push the image somewhere) Now, the layers system is a mess, permissions management is a mess (hence lots of containers run as root), volumes aren't easily browsable but bind mounts are also problematic, orchestration is all over the place (Compose is nice for a single server but doesn't handle clusters, Swarm is nice for multiple servers but mostly dead, Nomad is weird because of HCL, Kubernetes is nice if it's someone else's problem but there be dragons if you can't just pay a cloud vendor to handle it for you) and it got a large amount of things wrong (e.g. "latest" tags), but it was still good enough and aligned with actually getting things done. Additionally, most developers don't get paid for ensuring that their application will run in a stable and predictable manner 5 years from now. Most developers get paid for shipping that mediocre piece of software that their boss wants them to before the end of the week and having it work well enough so the company can earn some money, before they're told to move on and do something else the next week. I'm not saying that it's how things should be, but just the way they are, at least for a lot of people who don't tackle interesting problems yet still put food on the table. That is the "tragedy of good enough" and why Nix, NixOS, jails, FreeBSD or anything else won't be as popular until vaguely low skilled developers can get easily started with them. Maybe things just need to cool down and become more stable, even Kubernetes has gotten less horrible thanks to Rancher/K3s in the last years, maybe in a decade package management and the way OSes are will be more approachable.