Again, it's an explanation only a passive bystander. They're declarative, idempotent, and intended to manage infrastructure, operating systems and clusters, an

Again, it's an explanation only a passive bystander. They're declarative, idempotent, and intended to manage infrastructure, operating systems and clusters, and coordinate application delivery, key rotation and configuration. Repeatability, rollback, and version control are the basic design tenets. Sorry to hear that an OS upgrade broke your scripts once, but that's hardly the fault of configuration management tools in general or the Puppet/Ansible/Chef/Salt family in particular. As you might tell from between the lines, I have some experience with these tools in various environments. But I also see the need for another generation, mainly because of the large shift to Kubernetes application delivery. The insistence of these tools to manage the entire OS stack makes people regard them as too complex for what they need. It is my personal belief that the concept of a host is limiting the continued acceptance of this type of tools and I have been spare time experimenting with other primitives to describe state on, such as binary file archives. Playing with Nix, it is my impression that it is quite similar to other configuration management tools, a host is still the basic entity we serialize state on. State transitions are a linear graph. What people describe as problematic with configuration management in general is usually perceived complexity, and Nix seems to have the potential for more of that. But I have not used Nix in anger, or in any type of real world complex environment, and I would be very happy to learn from someone who has experience.