As an aside, I've just started trying to move my laptop to NixOS this past week, so far it seems pretty nice. I have a Macbook as well, and I think I should be able to share the Nix stuff with that - which would be cool.
As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same thing each time - no guarentee with ansible etc that the apt repository hasn't been updated since the last install.
I think the whole Nix thing is an interesting idea, and I like the ideas behind it, I haven't played enough with it yet to dare use it in production (or on my main desktop for that matter) but it is certainly a tempting idea.
I use NixOS on my laptop as well and like it. This is where the lack of polish hurts a little because desktop environments require a lot of polish to be wired up smoothly. That being said I use GNOME and the basics just work.
But on the server is where I think Nix really shines today. The biggest thing for me is that every deploy is "clean" and can be rolled back. Systems like Ansible (and basically every other config management system) only modify the part of the system that they know about and mutate global state. This means that your service might just happen to work because of a library that just happens to be installed by another service, or even on that is still installed from a service that used to run on the system. Unless you excercise Perfect Constant Vigilance and update configs to delete things instead of just removing the config to install them your configs will soon be be broken and depend on the current state of the system. I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS.
I wrote a blog post on each of server NixOS and desktop NixOS if you want more of my thoughts.
> I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS.
Having worked with puppet for a long time, I can relate.
There is this false sense of confidence that everything is reproducible "because we had the discipline to never do manual changes and always use puppet" but in real life:
- dependencies between resources are forgotten, it worked the first time because luck in the order in which resources were applied, but would fail in from scratch applies.
- hidden dependencies that were not specified but it worked because an other resource was installed at the time.
- hell, even a failed apply could have partially installed dependencies that would make subsequent applied work.
- there's always _that time_ when you had to fix something in a hurry and manually installed a package which is now a potential hidden dependency for everything else.
Re: using nix in place of ansible/chef/puppet/salt etc.
One of things that makes it far superior to these solutions, is that while many of them try to be declarative it still an iterative hack to emulate it.
For example if you use your CM to install a package on the system, or create a file in /etc. If you remove that statement the file or package will still be there.
In NixOS it will be as if it was never there. The reason for it is that the existing CM work by modifying current OS, while NixOS rebuilds the entire OS every time you make a change (thanks to cacheing that operation doesn't take as long as it would normally do).
As for using things in production, I generally like things that are well established. So it took many years before I got the courage to propose it, but frankly I don't think it ever let me down. As I used it always act predictable, both the NixOS as well as build (as long as you pin down nixpkgs).
The only thing to worry about is if the outside environment demands a change you better know how to do it. For example application works fine, suddenly you have higher traffic and things are crapping out and maybe you need to change some settings or there was a bug in one of your dependency and a new version isn't in nixpkgs. You better know how to do those things.
The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.
As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same thing each time - no guarentee with ansible etc that the apt repository hasn't been updated since the last install.
I think the whole Nix thing is an interesting idea, and I like the ideas behind it, I haven't played enough with it yet to dare use it in production (or on my main desktop for that matter) but it is certainly a tempting idea.