GNU Guix 1.0.1 Released

While it might not be in the first paragraphs that the user quoted, Guix doesn’t make a secret of where it came from.

They're not "being weird about it." It's explicitly not "a Linux distro" because they intend for the kernel to be just another freely interchangeable component (as is mentioned), although I suppose there might be some residual bitterness from their work constantly being called "Linux" or "a Linux distribution" as well.

This isn't unique to Guix System, either. Debian[0] refers to itself as "a free operating system (OS) for your computer" and doesn't even mention the term Linux on its home page, until you go to the about page[1], where it is mentioned (three paragraphs in!) that "Debian systems currently use the Linux kernel or the FreeBSD kernel." The term "distribution" doesn't even appear until the very end, where it is mentioned that "Debian was begun in August 1993 by Ian Murdock, as a new distribution which would be made openly, in the spirit of Linux and GNU."

Maybe, since the term "GNU distribution" is rather unorthodox, Guix System should just market itself as a free operating system, as Debian does.

[0] https://www.debian.org/

[1] https://www.debian.org/intro/about

You've presented yourself as a great example of the unfortunate misunderstanding that has come from people mistakenly calling GNU+Linux distributions Linux distributions. You were not able to recognize that this was a GNU distribution when then they called it GNU, until they mentioned Linux which is one thing Guix distributes. Then you suddenly (mis)understood what it was, and proceeded to blame the author for confusing you by speaking correctly instead of sharing the same misunderstanding.

Advanced meaning powerful with lots of features and functionality. There's a good writeup on it here[1].

[1] https://ambrevar.xyz/guix-advance/index.html

I haven't researched Guix specifically, but if you want a package manager for macOS with these features, Nix definitely supports macOS (Nix is the inspiration for Guix). Even if Guix is supported on macOS, I'm not sure offhand if there's any compelling reason to use Guix over Nix.

As near as I can tell, the only reason Guix even exists is because the authors don't like that Nix has a custom language and prefer Guile Scheme instead.

Nix: https://nixos.org/nix/

> What is a cool thing I can do with Guix, besides have my freedom respected? Do apt or Homebrew not respect that freedom?

In the second bullet point on the home page, they tell you something cool:

> Guix supports transactional upgrades and roll-backs, unprivileged package management, and more. When used as a standalone distribution, Guix supports declarative system configuration for transparent and reproducible operating systems.

Transactional upgrades and roll-backs are pretty great. If you're not using Guix (or NixOS -- wherever I mention Guix, you can also substitute NixOS), you absolutely don't have that. To be clear, on whatever OS you're using you might have some means of recovering if an upgrade goes bad, but that's not the same as a transactional upgrade/roll-back. On Guix, when you update the packages installed on your system (whether removal, installing a new package, or changing the version of an already installed package), that happens atomically and transactionally -- if you start a system upgrade involving, say, 1000 packages, all of those 1000 packages update instantaneously at the same time.

So let's say you just did a system update, but now you want to rollback the package changes. That's both simple and guaranteed to work; the way system packages and configuration is updated is this: one symlink is changed (if you're not familiar with symlinks, you can think of them like shortcuts from Windows, or see the link at the bottom of this reply). That's it -- 1000 packages rolled back with one symlink change. Nearly instantaneous. No copying/replacing files around, triggering scripts to try to rewrite e.g. systemd configs, literally just one symlink change.

Now let's say you were mistaken about your need to roll-back, and now you want to roll-forward again: you switch that symlink again, and now you're instantaneously rolled-forward.

Admittedly, their home page for the project doesn't say anything about this symlink magic, but then you can't fault them: it's an implementation detail. The homepage should be like a sales pitch, not a document describing their architecture. The only reason I mention it is because I hope it drives home that second bullet point from their page by providing a bit of intuition of how this works:

~~~

Let's say you have a directory (let's call it "A") with some files, and you want to "update" those files atomically and transactionally. The naive thing to do would be to write to those files directly -- but then how would that be atomic and transactional? Writing to a file inherently is neither, let alone multiple files at once.

So let's not update those files in place. Let's instead create a new directory "A2" with the new file contents we desire. Now a new problem arises -- there's no way on Linux/macOS/Windows/whatever to outright replace one directory with another. I mean, sure, we could rename or delete A and then rename A2 to A, but for a brief window of time any program that tried to read a file from A would fail, so that's not atomic.

So let's reconsider part of the problem statement: we don't really care that the name "A" directly denotes a directory, we just care that a path like "A/some_file" resolves correctly. Given that insight, let's rename A to A1, and make a new symlink named "A" and point it at A1.

So quick recap, here's where we stand as our initial state:

* A1 is a directory with some files.

* A is a symlink pointing at A1.

Now let's do our update. The first half of the update process: create directory A2 with the updated contents. Now all we need to do to atomically update the files available at the path A is: update the symlink A to point at directory A2 (this is atomic on all OSes I'm aware of).

To roll-back, do the reverse.

How do we make this transactional? Easy. If we had encountered a problem while creating directory A2 and its contents, we would never switch the symlink A to point to A2, so the effective changes are guaranteed to be all-or-nothing.

~~~

Guix system updates are exactly as above, but on a system-wide level. Without getting into these implementation details, their home page precisely and concisely conveys the immediate benefit of the (admittedly verbose) logic above: you get transactional updates and roll-backs, and while I haven't gone into the particulars of how this is made possible on a system-wide scale, I hope you can see that when they say "transactional updates and roll-backs", they really, really do mean it. It's not hyperbole or empty marketing speak.

Now it's possible that you don't care about the safety afforded by transactional updates (or maybe you think you already have transactional updates, though you're mistaken if you think that), or the ability to handle system configuration with a Scheme EDSL, or the copy-left licensing, but that would just mean that you're not the target audience -- not that they failed to articulate these three selling points.

Disclaimer: I don't use or contribute to Guix, though I do use and contribute to NixOS.

Links:

https://en.wikipedia.org/wiki/Symbolic_link

What does it mean in the context of computing though?