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.mlEnglish
    1·
    1 year ago

    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?

    I’m not sure what you mean by “doomsday scenario” or a nixos channel “blowing up”.

    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

    If they require updating, you’d have to update every single dep on Arch/Alpine too.

    If you only needed to modify one dep, you’d create an overlay with that package modified and that’d be about as simple as on those other distros, perhaps even easier to manage in the long run.

    Not sure what you mean by “have those files”? What files? The package definitions? Why wouldn’t you have those in Nixpkgs?

    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

    https://github.com/ryantm/nixpkgs-update

    nor is it feasible to do this type of thing manually

    Why?

    As new features are added, so are new options needed to activate those features.

    Not necessarily. Many times a NixOS modules simply uses an RFC42-style settings option which accepts arbitrary, well, settings. I haven’t updated the dnscrypt-proxy module in ages but you can still use all newly added configuration options.

    Also, it just… doesn’t happen all that often. It’s not something you, as a user, usually need to concern yourself with. Someone else will likely bump the packages; the distro won’t just die off over night.

    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.

    Someone has already done that work. Even if they hadn’t, you could still just imperatively install the extensions. I do that on my tablet where I use GNOME.
    I also don’t manage my firefox plugins using Nix. I could, someone built support for that into home-manager but I can choose not to.