Hi all,
I’ve been using NixOS for a while now (About a month now) and I’ve been loving it, but I’ve had some thoughts lately.
I understand that Nix(OS)'s claim to fame is the fact that packages are reproducible. All dependencies are versioned and all packages are rollback-able (although not sandboxed). With proper maintenance (nix-collect-garbage mostly), the problem with space is mostly mitigated.
But what if a package’s dependencies are out of date? These just stay out of date with their possible security problems as well. Not just that but it’s (nearly) impossible to actually do your own manual imperative editing of packages to solve a quick problem since everything is declarative.
Not just this, but Nix uses mostly its own configuration methodology, so isn’t this a maintenance nightmare as config files change and options are added/removed? Home manager is a prime example of this potential problem.
Plus more technologies being introduced on top of it to solve problems that seem already solved? (Flakes mostly come to mind).
I have come to the realiziation that, unlike a traditional distro like Arch/Alpine which I used previously, if maintenance dies I cannot feasibly maintain it myself, since it’s mostly “magic”. The upkeep of all the configurations plus all the dependency packages, and making sure each package compiles and matches the build configuration is a nightmare. I can barely do it with my own personal projects.
Anyways that’s kinda it just expressing thoughts about it. I do love Nix(OS) and plan to continue using it. It’s amazing, and its capabilities are matched by few to none, and from a user perspective it is an extremely seamless and simple OS. It’s mostly from a maintainer perspective that I had.
The out of date problem you mention is something Nix contemplates. As of a couple hours ago, if you try to install Etcher (Balena Etcher, that is), you will get a message saying there’s an out of date dependency: Electron.
You can still try to install End of Life packages, but you have to type an instruction the ‘compiler’ tells you to type out. In other words, you have to be deliberate about installing out of date dependencies.
The other problem I understood it as “if I declaratively do this and then imperatively do that, how do I keep track of it all?”. If that is indeed what you’re asking, you’re right. That’s a problem. That’s why I try to keep everything in the config.
I’ve been using Nix now for a couple of months and the configuration file has been a great friend. Sometimes I don’t know how to configure something and I get lost and worried, but the community has helped me to fix my problems- .
I guess I could’ve worded this better but my second problem was: I would like to do everything declaratively. What do I do when a package doesn’t have its own declarative configuration options? Before it was simple because it was imperative, so I could just change the config file, but not so much in NixOS.
You can still imperatively edit configs for packages where you don’t have / aren’t using the declarative config. You’ll just have the same reproducibility issues that you’d have on other systems. In general all the declarative NixOS modules do is generate the config files you’d normally write yourself, sometimes with some extra error checking. I’ve been doing this for my neovim config because I haven’t cared to port it to the module’s way and I want it to work on systems without nix.
Gotcha yeah that makes sense, so I’ll start doing this as well.
Having a config file means a package can be done declaratively. You can just use a nix option to create the config file.
I didn’t know this before, but a lot of comments said the same! I think I’ll start doing this.
Any package can be “edited” using its
overrideDerivationfunction. You can pass new configureFlags, buildInputs, a new src, etc. It’s all additive too, so when something else about the package changes in Nixpkgs, that’ll propagate to your “edited” package too.Config files for some service at runtime and the packages themselves are two separate domains. The former is handled by NixOS. In order to “modify” the runtime configuration, you set options inside a NixOS module such as your configuration.nix. If you wanted to place a config file somewhere in
/etc/or configure a systemd service, you’d use theenvironment.etcorsystemd.servicesoptions. They’re a bit like “primitives” as they’re rather low-level in NixOS terms but so is editing a config file in an imperative distro. NixOS modules usually use these “primitives” internally to offer more abstract options.services.paperless.enableinternally sets up a systemd service viasystemd.serviceswhich runs paperless with the declared configuration for example.So I can use something like
systemd.servicesto make my own services as well? Because I’ve been wondering how to do this as well.Absolutely. Your NixOS config is also just a NixOS module. You could even have it have options if you’d like to.