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.
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.
https://kevincox.ca/2015/12/13/nixos-managed-system/
https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/