I tried NixOS once and the overall impression was: it's magic. I mean, you know, when you are installing tools on relatively "clean" distro, like Arch, there usually something fails, and you have to try this and that, tweak something, and it is good old "linux way".<p>And NixOS is something so elegant and beautiful, so mathematically "right", that I subconsciously expect that it wouldn't actually work, and yet it does. I tell it what I want to get (relatively marginal configuration, btw) and it configures installation just right. I break something and it rolls back without a problem.<p>So the main question I've had ever since: why this stuff isn't popular enough yet.
I'm a mechanical/software engineer, but I set up our company's web and continuous integration servers using Ansible. The experience overall was excellent, and everything worked mostly as advertised. A couple pain points I had were:<p>* If I removed something from the Ansible configuration, it stayed on the server unless I explicitly removed it manually. This created hidden dependencies. I solved this problem by creating a brand new server and running Ansible on it from scratch every so often. I have considered setting up CI for our Ansible configs by using Vagrant to recreate our server architecture, running Ansible on the virtual machines, and ensuring everything works.<p>* Our continuous integration setup requires Ansible to be installed on the CI server, so it can automatically deploy to staging using the same playbook (Ansible configuration) we use for deployment. Our staging server is the same as our CI server, and it was actually a pain to set up deploying locally as root. Also, I feel like allowing the CI software to use root is a security hole.<p>I also spent some time with NixOS a year ago, and I was very impressed with how it manages packages. The first problem I mentioned with Ansible seems like it wouldn't happen with NixOS, since not including a package in an environment means it won't be present. Second, it also seems that you could use Nix's declarative configuration language in restricted environments, which wouldn't necessarily require root, instead of having to install system-wide packages for a particular deployment. I am not sure how easy this is in practice.<p>Currently, I am using Arch Linux, and I installed the nix package manager to play with some more. In the future, we might be provisioning AWS servers in real-time to run simulations given to us by customers (we make simulation software), and in that case I am going to investigate NixOS more.
This kind of discussion seems irrelevant once you move to the immutable deployment model. A new deployment means a new server that the load balancer switches to. Discard the old server. Obviously this doesn't work as well if you are not on the cloud or otherwise not operating in a cloud-friendly (don't write to the filesystem unless it is something like ceph) way. But I have no idea why people are still updating cloud servers instead of replacing them.
I have yet to find a single VPS provider that offers explicit support for NixOS [1]. As much as I like the idea of NixOS, it's difficult to evaluate its utility when I cannot easily spin up a NixOS-powered VPS and kick the tires. There does not seem to be any support for NixOS on DigitalOcean [2], and the instructions I came across for Linode look daunting enough that I am unlikely to even try [3].<p>[1]: <a href="https://nixos.org/wiki/Hosting_providers_%26_NixOs" rel="nofollow">https://nixos.org/wiki/Hosting_providers_%26_NixOs</a><p>[2]: <a href="http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/4349028-support-nixos-image" rel="nofollow">http://digitalocean.uservoice.com/forums/136585-digitalocean...</a><p>[3]: <a href="https://nixos.org/wiki/Install_NixOS_on_Linode" rel="nofollow">https://nixos.org/wiki/Install_NixOS_on_Linode</a>
FYI: NixOS source is hosted on github: <a href="https://github.com/NixOS/nixpkgs" rel="nofollow">https://github.com/NixOS/nixpkgs</a>
Package management is great, and Nix is neat, but Nix isn't the entropy-eliminating panacea the author makes it out to be.<p>Just like every other package manager, from rpm to dpkg, Nix is responsible only for the aspects of the filesystem that it's specified to be responsible for. It's not going to remove garbage left behind by users or poorly-written post-install scripts, and it's not going to automatically undo other non-filesystem-related state changes on package removals. And the practical reality is that not everything on a system can be a native package anyway.
Please forgive me if I have trouble taking advice from someone who has set up "tens" of servers and doesn't appear to understand the current set of orchestration tools.<p>Don't get me wrong, Nix sounds great, but this is a poor article from an inexperienced sysadmin who is unable to really point out the pros and cons.