The code of the packages is the documentation. So the newcomers better start learning Nix language and reading the paper about how Nix works under the hood before they get started! /s
But seriously, I used NixOs for about 2 years almost 10 years ago and while it was/is fascinating when you have everything setup, getting there and maintaining everything across so many packages that each have their own way of configuring them took hundreds of hours. I’m back on Arch using a custom tool I wrote to fully manage my configs, packages, dotfiles etc.
The way I remember it is that there is no consistency across Nix packages and it all feels like a giant puzzle for people who enjoy spending time configuring more than actually using the computer. And I say that as someone who actually enjoyed getting into that when I had unlimited time.
But to be fair, Nix is not the only answer to that. There are lots of tools for just dotfiles but you can also build something using e.g. ansible to manage everything.
All my computers have their config in a git repo. That includes users, packages, services, dotfiles, /etc configs and so on. I used ansible before writing my own tool. I can install Arch from scratch and only need to partition, run one script and then apply my config on first boot using my tool to have my system restored. I know it’s not as declarative and absolute/reproducible as Nix, but it works and it’s way less painful than my last attempt at giving NixOS a go.
Either my Ansible knowledge is too limited which is entirely possible, or you can’t do stuff there that’s possible with Nix. Let’s stay go with my example that you have something that requires changes in PAM. So you write an Ansible file installing the package (which is distribution-specific, so you’re losing one advantage you had over NixOS), enable the service and add your entries to the respective PAM file (e.g. login because you want to enable user authentication against kanidm on your machine). The ordering in these files matter. Sure you have insertbefore and insertafter for lineinfile and blockinfile, but this basically requires you to know the rest of the file in advance… not a problem if your system is always the same, but you don’t have the flexibility and composability that Nix offers.
I’d say, from my experience with Ansible, that it can absolutely do all of that. Might be able to use a single task for the package install, if the distro supports the generic package module. There’s also a pamd module that would likely cover your needs there. If not, it would still be possible with a custom module or some Xinfile fuckery (if it can be fine programmatically, it can be done in Ansible, more niche things may require writing code, however).
It would not be as terse though. Really wish there was a good middle ground.
I dunno man. I spent way less time configuring my machines on NixOS because it just works. But in fairness, that is after I have spent a lot of time learning it (compared to classic systems that is, not a lot compared to NixOS maintainers who write way better module than I do). Now that there is a foundation, I just run the updates. It’s almost scarily stable. And the ability to group related settings together is such a bliss because you no longer wonder about “what did I do to enable X”, just open the file, it’s all in one place. Stuff that could be three completely different things (e.g. a service specific config file, a PAM entry and the service activation itself in effectively 5 lines. Want to do something for multiple services? Just map over their list. Etc
I happily used Arch for 15 years and after trying NixOS on a decommissioned machine for one day I switched over everything as fast as possible. And I did try out Ansible on Arch, so it’s not like I didn’t try management via a tool. But using a system like NixOS just solves sooo many potential issues.
It obviously comes with downsides, for example there is no quick configuration change. Changing something small requires another evaluation. Still worth it
Documentation? For Nix? Yeah right.
The code of the packages is the documentation. So the newcomers better start learning Nix language and reading the paper about how Nix works under the hood before they get started! /s
But seriously, I used NixOs for about 2 years almost 10 years ago and while it was/is fascinating when you have everything setup, getting there and maintaining everything across so many packages that each have their own way of configuring them took hundreds of hours. I’m back on Arch using a custom tool I wrote to fully manage my configs, packages, dotfiles etc.
The way I remember it is that there is no consistency across Nix packages and it all feels like a giant puzzle for people who enjoy spending time configuring more than actually using the computer. And I say that as someone who actually enjoyed getting into that when I had unlimited time.
Okay, but when I figure it out on my desktop I just copy paste the exact snippet to my laptop and it just works.
Do you think I can remember the steps I took to fix my issue with Ubuntu? I don’t remember what file I modified and where I put some config file.
But to be fair, Nix is not the only answer to that. There are lots of tools for just dotfiles but you can also build something using e.g. ansible to manage everything.
All my computers have their config in a git repo. That includes users, packages, services, dotfiles, /etc configs and so on. I used ansible before writing my own tool. I can install Arch from scratch and only need to partition, run one script and then apply my config on first boot using my tool to have my system restored. I know it’s not as declarative and absolute/reproducible as Nix, but it works and it’s way less painful than my last attempt at giving NixOS a go.
Either my Ansible knowledge is too limited which is entirely possible, or you can’t do stuff there that’s possible with Nix. Let’s stay go with my example that you have something that requires changes in PAM. So you write an Ansible file installing the package (which is distribution-specific, so you’re losing one advantage you had over NixOS), enable the service and add your entries to the respective PAM file (e.g. login because you want to enable user authentication against kanidm on your machine). The ordering in these files matter. Sure you have
insertbeforeandinsertafterforlineinfileandblockinfile, but this basically requires you to know the rest of the file in advance… not a problem if your system is always the same, but you don’t have the flexibility and composability that Nix offers.I’d say, from my experience with Ansible, that it can absolutely do all of that. Might be able to use a single task for the package install, if the distro supports the generic
packagemodule. There’s also a pamd module that would likely cover your needs there. If not, it would still be possible with a custom module or some Xinfile fuckery (if it can be fine programmatically, it can be done in Ansible, more niche things may require writing code, however).It would not be as terse though. Really wish there was a good middle ground.
I dunno man. I spent way less time configuring my machines on NixOS because it just works. But in fairness, that is after I have spent a lot of time learning it (compared to classic systems that is, not a lot compared to NixOS maintainers who write way better module than I do). Now that there is a foundation, I just run the updates. It’s almost scarily stable. And the ability to group related settings together is such a bliss because you no longer wonder about “what did I do to enable X”, just open the file, it’s all in one place. Stuff that could be three completely different things (e.g. a service specific config file, a PAM entry and the service activation itself in effectively 5 lines. Want to do something for multiple services? Just map over their list. Etc
I happily used Arch for 15 years and after trying NixOS on a decommissioned machine for one day I switched over everything as fast as possible. And I did try out Ansible on Arch, so it’s not like I didn’t try management via a tool. But using a system like NixOS just solves sooo many potential issues.
It obviously comes with downsides, for example there is no quick configuration change. Changing something small requires another evaluation. Still worth it
Did you know that the suffix for nix documentation files is, coincidentally, .nix?