One of the things I've hated about being a part-time systems administrator is the fear of the unknown. All the little changes to config files, the different installed programs, everything required to get the system working is scattered around the disk. It creates fear around making changes, because who knows which little configuration change was required to get everything working? I understand that better organizations try to combat this with rigorous processes and documentation, with great effort.
I recently evaluated NixOS for a new server deployment. Being able to describe the entire state of the system in a single file is magical - it is so clearly The Right Way to do things. I am not a Functional Programmer but using the Nix language as just a config file is fairly straightforward. I left convinced that a simple functional language is the best way to make more complex config files, way better than Jinja2 templated YAML. (Though, functionistas, come down out of the ivory tower and make a language that looks C-family. Yeah, "it's just syntax" so why not make it easy for the proles like me to learn.)
However, I ended up giving up on NixOS for two reasons.
First, while learning the basics of Nix was easy I wasn't confident about the more complex things. Packages were missing features and I was going to have to start investing in reading and writing lots of Nix code. I couldn't continue ignoring the many intricacies of the Nix system if I wanted to be confident that I could quickly fix an issue at 2AM on a Saturday. As others have noted, there is a lack of good intermediate-level documentation apart from this great "How to Learn Nix" blog. My whole interest in Nix was being able to completely document the system so that future me or someone else could quickly understand how the system is configured. That doesn't work if you can't count on that person knowing Nix very well. Even if I invested in learning Nix it would feel like professional malpractice to dump some heavily customized Nix system on the next guy to come along.
Second, there's no LTS. That's fine if it's a dev machine, or if you have a professional full-time ops team watching package changelogs and testing upgrades. My machines need to survive with bare-minimum supervision.
I recently evaluated NixOS for a new server deployment. Being able to describe the entire state of the system in a single file is magical - it is so clearly The Right Way to do things. I am not a Functional Programmer but using the Nix language as just a config file is fairly straightforward. I left convinced that a simple functional language is the best way to make more complex config files, way better than Jinja2 templated YAML. (Though, functionistas, come down out of the ivory tower and make a language that looks C-family. Yeah, "it's just syntax" so why not make it easy for the proles like me to learn.)
However, I ended up giving up on NixOS for two reasons.
First, while learning the basics of Nix was easy I wasn't confident about the more complex things. Packages were missing features and I was going to have to start investing in reading and writing lots of Nix code. I couldn't continue ignoring the many intricacies of the Nix system if I wanted to be confident that I could quickly fix an issue at 2AM on a Saturday. As others have noted, there is a lack of good intermediate-level documentation apart from this great "How to Learn Nix" blog. My whole interest in Nix was being able to completely document the system so that future me or someone else could quickly understand how the system is configured. That doesn't work if you can't count on that person knowing Nix very well. Even if I invested in learning Nix it would feel like professional malpractice to dump some heavily customized Nix system on the next guy to come along.
Second, there's no LTS. That's fine if it's a dev machine, or if you have a professional full-time ops team watching package changelogs and testing upgrades. My machines need to survive with bare-minimum supervision.