3 ms·

There's been plenty of comments describing the difference between those tools and Nix, and various descriptions and docs are a single search away, so the snide

There's been plenty of comments describing the difference between those tools and Nix, and various descriptions and docs are a single search away, so the snide comment comes off as ignorant. Most of us who use Nix came from one of those tools. I personally went from bash scripts --> Ansible --> Nix. Nix is lightyears ahead of Ansible. Since I'm familiar with these two, I'll tell you what's wrong with them: * They are imperative instead of declarative, so you have a ton of extra cognitive load figuring out the order of actions. I have thousands of lines of Nix config, change one file and it's not gonna break because something in another file was installed in the wrong order. * They are not suited for managing the entire OS, but rather a layer on top of an existing OS. NixOS manages everything from the bottom up, so there are no loose ends to break you. * They are not truly idempotent. You have to be very disciplined to keep them that way, including Ansible, despite their claims. My ansible deployments broke constantly * They don't have rollback capability. If you mess up on nix, a single command or keystroke on boot will bring you back to the last working deployment. * Their DSLs are not powerful enough of an abstraction. Nix is a fully fleshed out language so you don't have to write a bunch of boilerplate like Bash or need some special module like Ansible to make something happen. * Git support is first class. You can compose your installation from several git repos, so say you want the cutting edge version of a package, you can install the one directly from the maintainer's repo instead of the one in the nixpkgs repo * Speaking of which, Nix has more packages than any other distro. Key word here, DISTRO. Bash and Ansible aren't distros, and there is no central repo where anything you'd ever want to deploy is available and standardized and denormalized. And a Nix deployment has persistent and writable storage, not sure where you get the idea that it doesn't.

xorcist 3y ago
Ignorant, yes, but in no way snide. Each and every point listed here could have be taken verbatim from a ten year old blog post why Puppet, or later Ansible, is the new great thing. Being declarative and idempotent is the basic design idea of these tools. Managing every layer of infrastructure and the entire OS stack is also exactly what they aim for, and ironically also what many people regularly quote as why they haven't taken off more. Git support, and module versioning, is also completely on point. What is it that Nix does differently, and why? Is it a fundamentally different type of tool, such as Puppet is from plain Ruby scripts, or is it a better screwdriver? That Nix is a distribution in itself is an important difference. But how does that affect the use case? I realize the question have been asked before, but that's because not many attempts are ever made to explain where it sits in the problem space. It is not written for anyone who has experience with configuration management and infrastructure as code tooling, but instead for passive observers with the intention of bootstrapping the next hype cycle?
- colordrops 3y ago
  I explained specifically using multiple comparisons why it's different from Ansible and Puppet. Several of the guarantees made by Nix were never promised by Puppet and Ansible, such as enforced idempotency and managing the distribution from the ground up. These are fundamental differences, and not a better screwdriver. If you've ever used Puppet and Ansible, you'd know that an OS upgrade will break your scripts. I've had Puppet and Ansible break out from under me countless times. That is basically close to impossible with Nix, because the OS is not under it, it IS the OS. It fully manages anything that it deploys. Puppet and Ansible often just use external tooling like package managers or edit existing config files, which is grossly error prone. Nix IS the package manager, and it IS the config file. This is a huge difference. I understand that you can install a package from scratch and deploy entire config files using Puppet and Ansible, but this is side-stepping the underlying OS's capabilities, and this sort of discipline can only be maintained by a single experienced engineer, and not a large group of people updating the config, unlike Nix, which enforces deployment. To say that Nix is a better screw driver is like saying that you could write the same level quality and reliability of software using Bash as in Rust. Rust is just a better screw driver than bash - I suppose it's true in some technical legal sense, but most people won't agree, and it's not true in any sense that is useful or valuable.
  - xorcist 3y ago
    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.

xorcist 3y ago

Ignorant, yes, but in no way snide. Each and every point listed here could have be taken verbatim from a ten year old blog post why Puppet, or later Ansible, is the new great thing. Being declarative and idempotent is the basic design idea of these tools. Managing every layer of infrastructure and the entire OS stack is also exactly what they aim for, and ironically also what many people regularly quote as why they haven't taken off more. Git support, and module versioning, is also completely on point. What is it that Nix does differently, and why? Is it a fundamentally different type of tool, such as Puppet is from plain Ruby scripts, or is it a better screwdriver? That Nix is a distribution in itself is an important difference. But how does that affect the use case? I realize the question have been asked before, but that's because not many attempts are ever made to explain where it sits in the problem space. It is not written for anyone who has experience with configuration management and infrastructure as code tooling, but instead for passive observers with the intention of bootstrapping the next hype cycle?

colordrops 3y ago
I explained specifically using multiple comparisons why it's different from Ansible and Puppet. Several of the guarantees made by Nix were never promised by Puppet and Ansible, such as enforced idempotency and managing the distribution from the ground up. These are fundamental differences, and not a better screwdriver. If you've ever used Puppet and Ansible, you'd know that an OS upgrade will break your scripts. I've had Puppet and Ansible break out from under me countless times. That is basically close to impossible with Nix, because the OS is not under it, it IS the OS. It fully manages anything that it deploys. Puppet and Ansible often just use external tooling like package managers or edit existing config files, which is grossly error prone. Nix IS the package manager, and it IS the config file. This is a huge difference. I understand that you can install a package from scratch and deploy entire config files using Puppet and Ansible, but this is side-stepping the underlying OS's capabilities, and this sort of discipline can only be maintained by a single experienced engineer, and not a large group of people updating the config, unlike Nix, which enforces deployment. To say that Nix is a better screw driver is like saying that you could write the same level quality and reliability of software using Bash as in Rust. Rust is just a better screw driver than bash - I suppose it's true in some technical legal sense, but most people won't agree, and it's not true in any sense that is useful or valuable.
- xorcist 3y ago
  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.