3 ms·

I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running The

I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running The problem was when I had to change some obscure .ini file in /etc for a dependency to something new I was setting up. Three days later I'd realise something unrelated had stopped working and then had to figure out which change in the last many days caused this For me this is at least 100x more difficult than writing a Nix module, because I'm simply not good at documenting my changes in parallel with making them For others this might not be a problem, so then an imperative solution might be the best choice Having used Nix and NixOS for the past 6-7 years, I honestly can't imagine myself using anything than declarative configuration again - but again, it's just a good fit for me and how my mind works

onionisafruit 10mo ago
In the NixOS scenario you described, what keeps you from finding an unrelated thing stopped working three days later and having to find what changed? I’m asking because you spoke to me when you said “because I'm simply not good at documenting my changes in parallel with making them”, and I want to understand if NixOS is something I should look into. There are all kinds of things like immich that I don’t use because I don’t want the personal tech debt of maintaining them.
- oasisaimlessly 10mo ago
  Not OP, and not a very experienced with NixOS (I just use Nix for building containers), but roughly speaking: * With NixOS, you define the configuration for the entire system in one or a couple .nix files that import each other. * You can very easily put these .nix files under version control and follow a convention of never leaving the system in a state where you have uncommitted changes. * See the NixOS/infra repo for an example of managing multiple machines' configurations in a single repo: https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c159f4f7672a46906/builders/flake-module.nix https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c...
  - maccard 10mo ago
    Both of those things are true of running containers, no?
- Scandiravian 10mo ago
  I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes) Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally
  - Scandiravian 10mo ago
    I just realised I didn't answer the first question about what keeps me from discovering the issues earlier The quick answer is complexity and the amount of energy I have, since I'm mostly working on my homelab after a full work day Some things also don't run that often or I don't check up on them for some time. Like hardware acceleration for my jellyfin instance stopped working at some point because I was messing around with OpenCL and I messed up something with the Mesa drivers. Didn't discover it until I noticed the fans going ham due to the added workload
  - maccard 10mo ago
    > because you can have the entire configuration in a git repo, you can see what you've changed at what point in time That’s true of docker too.
    - Scandiravian 10mo ago
      I'm not really sure what your point is, but I'll try to take it in good faith and read it as "why doesn't docker solve the problem for it, since you can also keep those configurations in a git repo?" If any kind of apt upgrade or similar command is run in a dockerfile, it is no longer reproducible. Because of this it's necessary to keep track of which dockerfiles do that and keep track of when a build was performed; that's more out-of-band logging. With NixOS I will get the exact same system configuration if I build the same commit (barring some very exotic edge cases) Besides that, docker still needs to run on a system, which must also be maintained, so Docker only partly addresses a subset of the issue If Docker works for you and you're not facing any issues with such a setup, then that's great. NixOS is the best solution for me

onionisafruit 10mo ago

In the NixOS scenario you described, what keeps you from finding an unrelated thing stopped working three days later and having to find what changed? I’m asking because you spoke to me when you said “because I'm simply not good at documenting my changes in parallel with making them”, and I want to understand if NixOS is something I should look into. There are all kinds of things like immich that I don’t use because I don’t want the personal tech debt of maintaining them.

oasisaimlessly 10mo ago
Not OP, and not a very experienced with NixOS (I just use Nix for building containers), but roughly speaking: * With NixOS, you define the configuration for the entire system in one or a couple .nix files that import each other. * You can very easily put these .nix files under version control and follow a convention of never leaving the system in a state where you have uncommitted changes. * See the NixOS/infra repo for an example of managing multiple machines' configurations in a single repo: https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c159f4f7672a46906/builders/flake-module.nix https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c...
- maccard 10mo ago
  Both of those things are true of running containers, no?
Scandiravian 10mo ago
I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes) Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally
- Scandiravian 10mo ago
  I just realised I didn't answer the first question about what keeps me from discovering the issues earlier The quick answer is complexity and the amount of energy I have, since I'm mostly working on my homelab after a full work day Some things also don't run that often or I don't check up on them for some time. Like hardware acceleration for my jellyfin instance stopped working at some point because I was messing around with OpenCL and I messed up something with the Mesa drivers. Didn't discover it until I noticed the fans going ham due to the added workload
- maccard 10mo ago
  > because you can have the entire configuration in a git repo, you can see what you've changed at what point in time That’s true of docker too.
  - Scandiravian 10mo ago
    I'm not really sure what your point is, but I'll try to take it in good faith and read it as "why doesn't docker solve the problem for it, since you can also keep those configurations in a git repo?" If any kind of apt upgrade or similar command is run in a dockerfile, it is no longer reproducible. Because of this it's necessary to keep track of which dockerfiles do that and keep track of when a build was performed; that's more out-of-band logging. With NixOS I will get the exact same system configuration if I build the same commit (barring some very exotic edge cases) Besides that, docker still needs to run on a system, which must also be maintained, so Docker only partly addresses a subset of the issue If Docker works for you and you're not facing any issues with such a setup, then that's great. NixOS is the best solution for me