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!
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!