Replying to @⁨0x4f1@lemmy.world⁩

I mean they sort of serve different purposes. You can build a NixOS ISO running your exact desired configuration that is good to go immediately upon install. Ansible would require post install configuration, yes it is scripted but it is additional overhead and time. I think a better alternative would be an OCI based distro with a Packer build pipeline, which could include Ansible steps higher up in the build process. But that’s more complexity that Nix wouldn’t require

Replying to @⁨0x4f1@lemmy.world⁩

i used ansible some years ago and i’m using nixos currently and you can not compare those two.

i was not fluent in ansible and i’m not fluent in nixos. yes you have to leave your comfort zone for nixos, but your get so so much more.

the jinja templates in yaml feel like a big hack if you used nixos.

would really be interesting to hear someone talk who is comfortable to use both of them.

Replying to an earlier post

from a sys admins perspective it’s painfully easy to deploy across hundreds of machines. NixOS is declaritive and immutable. you can take one system configuration of NixOS and throw the same config on as many machines as you want. packages, dotfiles, whatever are all replicated the exact same way on each machine. You can lock all the packages/apps, configs, kernels, etc to a specific version therefore a sysadmin may only need to upgrade the lot once a year. if a user some how breaks their system it’s as easy a fix as rolling back to the previous generation with a single menu option.

So basically say you have your computer and you want to replicate your exact setup to hundreds of other computers. with NixOS it’s as simple as setting up a git repo for your nixos config, pushing to it, installing nixos on every other computer then cloning your repo to all the machines and rebuilding. done. now you have hundreds of other computers that all behave and work the same way your computer does.

If something needs updating or a fix needs to be rolled out all a sysadmin has to do is fix it on one machine, push the change, pull it for every other machine and rebuild. done.

Replying to @⁨rozodru@piefed.world⁩

Or just configure all the machines to auto-update from the flake at the repo. Doing this for my VMs. I have a CI machine that builds my pinned flake from the repo tip, and about 30 other VMs check nightly if the repo tip has moved, and if so, rebuild from the new tip; which, thanks to the CI machine, means just downloading and activating a new generation, nothing compute heavy.

Replying to @⁨kubok@fedia.io⁩

From the article:

Its use of the Nix package manager means that each package is installed in its own directory with immutable and signed contents. That alone means that the setup is incredibly easy to reproduce across multiple machines, something that is an obvious benefit when dealing with different facets of a government.

Id argue an immutable distro would likely serve the same purpose but maybe its also because nixos isnt as “locked down” so itd be easier to configure for a specific purpose?

Replying to @⁨Bluefruit@lemmy.world⁩

The big draw is probably that it’s declarative, so you can define installations as code much the same way as you would do with Terraform. Instead of needing a pile of messy Ansible playbooks running custom scripts to change anything (and which can break if the target machine has an unexpected config), you’d just have one that pushes a new version of the config and runs nixos-rebuild. Rollbacks are just as easy if anything breaks. What’s not to like?

Replying to @⁨punkfungus@sh.itjust.works⁩

Right so in that way, its very reproducible. That was my understanding and I appreciate you for the more in depth explanation but is there advantage to that versus an immutable distro? Wouldn’t a immutable distro work in a similar way being reproducible among many machines?

Rollbacks can be done on immutable distros as well right? I’m just curious why Nix was the first choice and not something immutable.