For everyone who doesn’t have several different systems to maintain, I find the advantages of nixOS to be marginal. Sure, you can argue about atomicity and all, but honestly I don’t remember ever running into a serious problem with debian either. The huge package repo is nice, but I rarely encounter an app I can’t get through apt, flatpak, or as an appimage.
At the same time, nix also has various downsides. Documentation sucks. There are two main ways to manage the system, they both pretend to be the better one, and it’s super hard to even get started. That’s not an issue with the technology, but just a lack of priority. Guix is much better on that end (but also comes with the same marginal advantages).
On the other hand, debian has a stable community, with proper processes, democratic structures etc.
This is a nice, kind of old presentation from debconf, where people discussed nix and how this could be useful in a debian context as well:
Personally I’ve found the transition to be much more than marginal. Systems are defined not by the state of the machine itself but by the config describing it which is much more transparent and manageable. Non-declarative systems are great if you’re just running small services, are changing and experimenting a lot. Or just don’t can’t if your system goes down or bloats over the year. Declarative systems save you whole lot of management headaches especially if you are working with others, or aren’t constantly reviewing your old work.
Except that things change as well in (or rather “around”) declarative systems, and you have to update your config files as well. That’s because the underlying software changes, and it has nothing to do with whether your system is declarative or not. You just need to put in the work to update your configs at a different point in time.
In nix they don’t, since they lock in files based on the commit hash. You don’t have to update unless you want to and you can always roll back to the previous stable state.
I’m interested in the topic in general, but not in explaining that declarative systems don’t solve the problem of continuously changing software (e.g., for security updates, changing landscape), and the need to update configs that goes along with it. Hope that helps!
It helps the problem by tagging the state of all your random dot files to the same source set. Any that config changes very rarely anyway. Unless you are using super bleeding edge software. Sure you have to change things still but atleast you have a well track set of what you’ve changed how you’ve changed it and what versions it’s all set to. Non-declarative systems mean you still have to do all the updating but now it’s all a much of untracked manual work unless you’re real good at documentation. Hope that helps!
For everyone who doesn’t have several different systems to maintain, I find the advantages of nixOS to be marginal. Sure, you can argue about atomicity and all, but honestly I don’t remember ever running into a serious problem with debian either. The huge package repo is nice, but I rarely encounter an app I can’t get through apt, flatpak, or as an appimage.
At the same time, nix also has various downsides. Documentation sucks. There are two main ways to manage the system, they both pretend to be the better one, and it’s super hard to even get started. That’s not an issue with the technology, but just a lack of priority. Guix is much better on that end (but also comes with the same marginal advantages).
On the other hand, debian has a stable community, with proper processes, democratic structures etc.
This is a nice, kind of old presentation from debconf, where people discussed nix and how this could be useful in a debian context as well:
https://www.youtube.com/watch?v=jGrcLEweglg
So, if you FOMO, don’t worry. Debian and other options have this on the radar and have their ways to adapt (even if slowly)
Personally I’ve found the transition to be much more than marginal. Systems are defined not by the state of the machine itself but by the config describing it which is much more transparent and manageable. Non-declarative systems are great if you’re just running small services, are changing and experimenting a lot. Or just don’t can’t if your system goes down or bloats over the year. Declarative systems save you whole lot of management headaches especially if you are working with others, or aren’t constantly reviewing your old work.
Except that things change as well in (or rather “around”) declarative systems, and you have to update your config files as well. That’s because the underlying software changes, and it has nothing to do with whether your system is declarative or not. You just need to put in the work to update your configs at a different point in time.
In nix they don’t, since they lock in files based on the commit hash. You don’t have to update unless you want to and you can always roll back to the previous stable state.
Okay, not really interested in this discussion. Of course, I can also keep running Debian 10 forever
“Not interested in discussion” posts opinion on public form. Wut.
I’m interested in the topic in general, but not in explaining that declarative systems don’t solve the problem of continuously changing software (e.g., for security updates, changing landscape), and the need to update configs that goes along with it. Hope that helps!
It helps the problem by tagging the state of all your random dot files to the same source set. Any that config changes very rarely anyway. Unless you are using super bleeding edge software. Sure you have to change things still but atleast you have a well track set of what you’ve changed how you’ve changed it and what versions it’s all set to. Non-declarative systems mean you still have to do all the updating but now it’s all a much of untracked manual work unless you’re real good at documentation. Hope that helps!