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.

  • Atemu@lemmy.ml
    1·
    1 year ago

    Any package can be “edited” using its overrideDerivation function. 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 the environment.etc or systemd.services options. 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.enable internally sets up a systemd service via systemd.services which runs paperless with the declared configuration for example.