[wolletd]

I still haven't found time to work with Nix or NixOS, but I like it's concept.

At work, I'm maintaining a bunch of custom configured Linux images for our products. While building those images through Dockerfiles is pretty declarative, my pain starts with keeping the configuration of systems in the field up to date: half of the build instructions is duplicated in Ansible playbooks.

Conceptually, with Nix(OS), I could maintain a single, declarative configuration that I would use to create new images and simply push to existing machines an re-configure them.

But I don't see getting something like that production-ready in the near future. I'm currently thinking of only building base images with docker and doing all product-specific configuration through ansible.

[matrss]

> While building those images through Dockerfiles is pretty declarative [...]

There is nothing declarative about Dockerfiles, they are a list of imperative steps. Same for ansible playbooks, which are also often called declarative when they really aren't.

[h0l0cube]

They are imperative steps with aspirational idempotency, and specifically Ansible is painfully slow to boot. I've noticed that order often becomes necessary in practice, so I'm not sure if this imperative nature is avoidable.

[matrss]

Some kind of imperative base is not avoidable. In the end a declarative abstraction must map to a list of instructions to follow, that's just how computers work.

But on the abstraction level of configuring a Linux system this imperative nature can be completely hidden, as demonstrated by NixOS. E.g. you can set `services.uptime-kuma.enable = true` in a NixOS configuration and it will fetch the package, setup a systemd service for it, setup a service user, and enable and start the service, without you having to care about any kind of ordering or the specific steps themselves. You can do the same for other services, and it doesn't matter in which order they are declared.

Of course someone has to first build the abstraction, which is service-specific most of the time. Though, NixOS provides lower-level options to define these service abstractions declaratively as well (think: declaring that a user account is present, or that a systemd service is setup with some configuration), so most of the time you still don't reach the imperative base underlying NixOS.

[h0l0cube]

I think this is much of the problem. The complexities are hidden behind the abstraction, and I'd wager (naively) that most NixOS users at some point need to use an escape hatch. It makes sense that that complexity extends all the way to altering the OS itself, so that Nix has to perform less acrobatics.

[matrss]

> [...] and I'd wager (naively) that most NixOS users at some point need to use an escape hatch.

I don't think that is the case. In five years of using NixOS I never needed to reach for any of them, and I don't even know what would be available to me. Probably something about activation scripts? Again, I can't think of anything you might want to do with regard to system configuration that can't be done declaratively on NixOS.

[h0l0cube]

Fair enough. It could be that good. Is this use for commercial purposes? Do you have to interface with legacy systems or unusual stacks?

[anthk]

WIth Guix you can export these declarative files to docker coutainers, TGZ's ready to deploy everywhere (guix pack), vm's, build systems...

[russelg]

And you can do the same with Nix, not sure what your point is?

[SvenL]

Did you try using „immutable“ infrastructure? I mean instead of updating existing container, you just spawn a new one with the new configuration, add it to the load balancer and decommission the old one?

[wolletd]

Our products are hardware, I use docker to build and manage bootable images.

[siwatanejo]

its