> It's about being able to reuse a recipe (dockerfile, etc.) for creating your final artifact while ALSO being able to change it -- as opposed to the "take it o

> It's about being able to reuse a recipe (dockerfile, etc.) for creating your final artifact while ALSO being able to change it -- as opposed to the "take it or leave it" case with cloning some binary blob. You must be confused. I can create and delete files on my filesystem -- changing it -- even though it is a binary blob. Perhaps you mean something else? > with cloning available but no reproducibility, when you want to only change part of a container (e.g. update a specific piece of software there), you don't know (when you re-create the container) that the other parts you didn't change are as they were before I keep hearing you say when I want to re-create the container, but I don't ever hear you say why I would want to re-create the container. > For one, you're doing all this work manually Wrong. It's less manual work. Writing a nixfile is manual work. It's hard manual work because none of the tools are interactive, and it's very distracting waiting for the computer to reply the nixfile between interations. Interactive development is superior. > if you want to revert/change something you made, you have to mess with your clone No I don't. I discard it. Do you use git rebase on your own history? Or do you create a new branch with a cleaned up history? I do the latter. > potentially putting it in some weirdo state I don't need to reinstall my operating system every day because I get confused about what is on my computer. > The can use docker diff and try to guess what the differences are -- and what the intention was, etc. Because docker diff is just a record of file changes, not of procedures followed and the intentions behind them. The intentions are recorded in the commit log. That's why docker commit allows commit messages. Procedures are only recorded if someone records them. Why would I do that if I only have to do it once? > "In a realistic example", for example, things could get much more hairy (and many more tests and changes could be needed), beyond merely forgetting to update apt before installing nvi. That's what I said, but you're missing the part where I don't have to wait hours and hours and hours while nix rebuilds my system over and over again. "Reproducibility" has enormous costs, and the value proffered can be had with better tools. > Anything that requires discipline on the human part and that could be automated is busy-work -- and error prone. You're not automating the nixscript-writing, so you haven't saved any work. You've created busy-work by reinstalling your operating system over and over again. > Yes, but that's meant for safe-keeping, like vm-snapshots. It doesn't replacing actually having a written record of what you did, what's supposed to be istalled inside, and why. No, it's exactly a written record because that's what the commit messages are for. If I want to know what's inside, there are other tools (dpkg) for taking inventory. > So again, a throwback to the manual devops age. Nonsense. For some reason you only want to count the time that your script is running from when it is finished, instead of the time and expertise needed to develop the script in the first place, that you only need to run once. If you can't understand that a sysadmin's job, whether they are writing a nixfile or they are directly interacting with a machine, is manual work, then I just can't imagine how I can be understood by you. That's insane.