I Love Arch, but GNU Guix Is My New Distro

> A rolling release seems at odds with the stability granted by reproducible builds.

GuixSD and NixOS aren't subject to some of difficulties of traditional rolling release Linux distributions.

You are exposed to upstream behavior changes and upstream bugs more or less as soon as they arrive, just like on Arch Linux or something like that. But most of the other risks and maintenance burdens of ‘running a rolling release’ aren't borne by GuixSD and NixOS users.

This is not so much due to the reproducibility of Nix builds as to the hermeticity and statelessness of Nix and Guix builds.

The hermeticity means that you don't have to worry about ABI breakages in the same way, since packages that need incompatible versions of the same library will each find their respective version of that dependency sitting safely isolated from one another in the package store. This spares you from a few maintenance burdens:

• installation of new packages causing/requiring upgrades of ‘unrelated’ packages because they share some dependency with the new one (this one affects standalone package managers like Homebrew as well as rolling releases of entire operating systems like Arch)

• having to upgrade before installing new things, every time you update your package sources

• having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan )

The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly.

For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’.

It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable.

But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.

Oh! On this interpretation, the GP comment is basically missing an instance of the definite article there:

> And usually you only have package maintainers doing this, not the actual developers.

It's not super unusual for the maintainers of some program's packages in several distros to also be core developers of the project, but yeah, that's a good point.

> Plus the entire thing is in flux right now between flakes, home-manager, and a desire to kill nix-env.

This is my big gripe with Nix. There are so many things that are almost ready, or almost integrated, and advanced users are typically already using them. It makes it feel like next year will always be a better time to recommend Nix to newbies.

And a lot of the more ambitious contributions to Nix and Nixpkgs that are really, really exciting as a user tend to sit in pull request limbo for a very long time, sometimes dying on the vine. Guix doesn't seem to have that problem yet, but I don't follow it as closely.

It's painful to feel sort of totally married to it but also like I can't whole-heartedly recommend picking it up to most people I know who might enjoy it once they got going.

so after so many posts this is the only one that expresses your point clearly. notice how it does not contain any FUD

to the said point, this is definitely a VALID security concern. FSF needs to make these concerns clear. you seem to be very invested in this matter. have you raised these concerns with them?

EDIT: having thought about it some more. doesnt isolating blobs to ROMs restrict the problems to ROMs? i mean non-RYF certified hardware already has this problem. the strategy might them be to focus efforts on opening up ROMs. note that this is simply a question. i am not an expert in this field but i am trying to form an informed opinion

That's not true. If distros package closed source firmware updates the manufacturer has the ability to provide updates to people's computer via that system. I mean, that's the whole point and in a trustworthy environment that's a good thing. Maybe have a look at https://wiki.debian.org/Microcode#CPU_microcode_non-freeness (I'm not sure whether I'm just misinterpreting your comment or whether there is a knowledge gap, just to make sure we talk about the same thing :) ).

> By withholding that information they are effectively eliminating the choice, and restricting users' freedom.

You are mixing up agency and software freedom, it's clear that you won't see eye to eye with the FSF as long as you do so.

I'm not even vigorously defending not showing the note about existing firmware updates, if Guix really does so. I'd prefer a note. Just what it would mean and how problematic closed firmware would be seemed like it needed a clarification here.