Comment by 7bit | Hacker News Reader

Comment by 7bit | Hacker News Reader

Parent Full thread

I dtarted my Linux journey 3 weeks ago with Arch and Ansible to create a declarative system. The installing-part however was tricky, because I have a second disk with Windows and I want to use secure boot. And if I wanted to use Ansible, I would have to create a specific ISO. And then I would have to manually define the disk I want to use or run into the risk of formatting the wrong one and lose a lot of data.

Then I found NixOS, which is like Ansible, but better, because Ansible only adds information to a system, but NixOS also ensures that anything that is not declared is removed as well.

After three weeks, I realized that the effort to declaratively (or automate an imperstively) install the OS is such a lot of work that does not pay off if you're not going to install multiple systems each week or month.

How many commands does it take to actually install NixOS? You partition the disk which take 3 commands. Then you format it, which takes 3 commands. Then you mount the disks, which takes 3 commands. Then you install it, download your configuration and apply it, which is another 2-3 commands.

It takes 5 minutes vs whatever effort you put into creating a declarative installer and keeping that up to date. I also had to think of the time it would cost me to actually figure out HOW a declarative installation would work and the tools I would require. I reckon that the first 24 system would essentially be free (opposed to the 2 hours or so it would cost me to figure out declarative OS installations).

I decided that for me, it is not worth it, although I am the type of personality that just hates not automating things.

Declarative management of your OS is in terms of effort basically an inversion of imperative management.

With declarative, you frontload an enormous amount of effort:

- You have to learn your declarative framework

- Then you have to slowly build your configuration base, or copy someone else's and figure out why they did what.

- Then you have to figure out workarounds for things that aren't natively managed declaratively.

- Then you start writing your own little helper functions and modularize things. At this point, it starts getting very smooth.

From there on, adding another package or another machine is very very easy, basically adding a few lines of code. And now your system is mostly reproducible, putting you far ahead of an imperative configuration.

Compared to that, doing it imperatively you can just sort of do your thing and roll with it. This let's you do whatever you aim to achieve very quickly, but as time goes on you have to juggle so many balls in terms of tracking and remembering what you configured / what state your config is in that it quickly becomes impossible.

Declarative OS management really sticks once you accept that the first few weeks are gonna suck and the first few months are still gonna have friction. But once you get over the hump, the rewards are there to reap.

I feel like a lot of that effort could be reduced though:

> You have to learn your declarative framework

Could the framework be simplified so that you don't need to learn all of it but rather just a small part when you're only doing basic stuff?

> Then you have to slowly build your configuration base, or copy someone else's and figure out why they did what.

Couldn't pre-made configurations be made available? For example in docker it's very easy to base your image on another image from an online registry.

> Then you have to figure out workarounds for things that aren't natively managed declaratively.

This is unfortunately a consequence of the current ecosystem essentially being imperative-first, but I wouldn't consider it an intrinsic limitation of declarative systems.

> Then you start writing your own little helper functions and modularize things. At this point, it starts getting very smooth.

This is probably the part where you really need to spend a lot of effort, but I wonder if it's possible to reduce the need for these helper functions and modularization or provide them by default for at least most common cases. Then most wouldn't need to spend the effort for them because they either already exist or there would be no need for them.

The crazy bit is pretty much everything you’ve described exists. Except for the most important bit, the documentation.

> Could the framework be simplified so that you don't need to learn all of it but rather just a small part when you're only doing basic stuff?

If you just want to do 'basic stuff', declarative OS management has way too much overhead.

> Couldn't pre-made configurations be made available? For example in docker it's very easy to base your image on another image from an online registry.

Nix really is as a configuration of configurations (called modules). So yes. But no one runs the exact same OS setup or container, so eventually you will need to modify it to your specification.

> This is probably the part where you really need to spend a lot of effort, but I wonder if it's possible to reduce the need for these helper functions and modularization or provide them by default for at least most common cases

Nix already has premade helper functions for common cases via 'builtins'. As far as modularization goes, at some point you are going to want to do something custom, and if you want to apply that to multiple systems then making it a module just makes sense.

> Declarative OS management really sticks once you accept that the first few weeks are gonna suck and the first few months are still gonna have friction. But once you get over the hump, the rewards are there to reap.

Only if you don't change your mind and do not decide to try out that new cool distro that just came out 6 months later.

I like declarative management but so far I have sticked to puppet for that. Sure like with ansible puppet needs to be installed first but on the other hand you can quite easily convert/reuse a config for say debian, to ubuntu, arch or fedora. The main differences are usually package names.

Lots of people don't realize it, but you can actually use Nix for packages and package config on any distro and even macOS.

Welcome to Linux!

I agree that through the lens of “how much time do you save?”, automating a NixOS installation is not worth it. As you describe, it’s just a few interactive commands in the upstream installer.

But from the perspective of “how much effort is it to spin up a new VM for this new project / task?”, spending the extra few minutes on building the fully automated installation path is well worth it. Also consider the perspective of “how many steps does it take to recover this VM in a disaster scenario?”, where reducing the manual steps to a minimum is very helpful.

BTW, the maintenance of the installer is virtually free: The configuration I show is the configuration I use in NixOS as well, so that needs to be updated anyway. Aside from that, to rebase my installer from NixOS 24.11 to NixOS 25.05, I just changed a number. When setting up a new machine, I can either download the upstream installer and write it to a USB stick, or I can change a number, rebuild (< 2 minutes) and write to a USB stick. Really not much difference.

Yeah maybe I should have mentioned that despite my enthusiasm I haven't bothered to install NixOS on my laptop or anything! I might one day, but that will be "for the love of the game" not because I expect it to save me any time. Until then, an incredibly basic dotfiles manager is perfectly good enough.

But for setting up appliances, test machines, it's perfect. If I ran cloud VMs I'd also consider it for setting those up.

Reply on news.ycombinator.com