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.
This is rarely the case as we usually don’t keep older patch versions or whatever. Most packages will just be updated “in-place”. We might keep a few major versions of some major packages though if some other packages have a hard dependency on some older API/ABI. When that happens and an old major version goes EOL/has security issues, it’s marked as insecure and you’d have to explicitly opt into using it by allowing its version in your config.
You can do your own declarative “editing” of packages: Overrides allow you to override any dependency of a package and receive a package where that dependency is the other thing you put in.
Overlays allow you to “edit” packages in the context of a package set where the package’s dependants in the set also receive the “edited” package as their dependency.
It’s fairly normal to have an overlay in your config to customise a few packages to your liking. Anything that needs
youtube-dlgetsyt-dlpwith the youtube-dl executable alias in mine for example: https://github.com/Atemu/nixos-config/blob/b79f42793a709db083cf53867f85d5d46e41eb69/overlays.nix#L29-L33. Stuff like that.Also note that, if a package is broken, it’s usually best to fix it upstream rather than patching around upstream in your own config. The package being unbroken for every NixOS user instead of just yourself is one PR away; it’s super easy to contribute to Nixpkgs.
In NixOS, this doesn’t happen very often. Most options have been there for years and go unchanged for years aswell. At least in terms of API; they might do different things internally to achieve the options’ goal but you don’t need to care about that; you just state your intent. There are many ways to install i.e. systemd-boot to your ESP but you only care that it’s installed, not how.
When a breaking change happens in the options’ API, you’ll know about it at eval time. It’ll show you an error stating that e.g. the option has been renamed to so and so and perhaps the semantics changed. Many times it’ll just be an eval warning even, stating that the option has been renamed and has been set to your old option’s value but you should move over because this fall-back will be removed in the next release.
Note that if you don’t like breaking changes coming in willy-nilly, the stable channel (23.05 currently) would be for you: It restricts such option changes and you only have to change your config to accommodate option changes twice a year when a new release comes out. As I said though, breaking changes don’t happen very often for your average NixOS config even on the unstable channel. This isn’t really as much of an issue as you might think.
Can’t really speak for home-manager as my use of it is quite limited and it’s a nix-community project, not a NixOS one (different quality standards).
That’s just because you don’t have experience packaging or maintaining Nix packages yet. If you didn’t know how to package Arch/Alpine packages, you would be just as screwed if maintenance was dropped.
Once you’ve done a few patches to packages or even packaged something yourself, this “magic” will become more and more disenchanted.
Not quite sure what you mean here. Could you point out some concrete examples of that?
Sorry for the late reply. In the 2 weeks I’ve still kept using it and I learned a lot! But a lot of my musings still stand, at least in my mind, but after thinking a little longer, a lot of the thoughts I had also apply to other distros as well.
To answer what you asked in final, a good hypothetical that might answer it is something like GNOME. If the nixos channel blew up in a doomsday scenario, I’d be stuck maintaining my packages myself, right? And I use the doomsday scenario, because the problems here apply for self-made packages as well, but it’s easier for me and maybe others to wrap their head around the problem I’m getting at. So with GNOME, I’d have to update every single dependency manually in my nix files. With something like Arch/Alpine I could just have those files, and they have these really neat scripts where I can just bump the version, and it’ll download, set the hash up, and bump the version all for me. With Nix there are no such tools. I can’t just automate the process, nor is it feasible to do this type of thing manually. As new features are added, so are new options needed to activate those features. And yes, although in this scenario, I would probably just opt to not add these options and set it up myself, when making a package for the general public this isn’t the case. If GNOME adds a feature (idk why I picked GNOME I haven’t used it in like 5 years) to have extensions managed by the package manager, I’d have to add an option for what extensions are needed and all that. And this is a lot of work, at least as far as I know. The extensions would also have to be packaged.