GNU Guix Package manager & OS

guix shell is definitely one of the top features of Guix. It allows you to quickly download any program and run it. Compared to apt or such, where downloading one package is an arduous process and might just break your system because of a conflict or something else, it is quick, reliable and has no side effects on your system besides the files made by the program (which can be eliminated via the usage of --container).

The other feature that I consistently use, is profiles. My computer has several profiles, such as the emacs profile that contains all emacs-related packages, chromium profile with ungoogled chromium and ublock origin, latex that just contains TexLive, &c. It allows you to partition packages and manage them all separately as if they were on a different machine. I very rarely update my emacs profile, because there is no point; but reasonably often I add some packages to my guix-home profile. With a traditional package manager, I would have to update all of them to update one package, but now I don't have to.

The way I use profiles is primarily through manifests, which are just lists of packages. For example, my chromium manifest looks like this:

chrome.scm
(specifications->manifest '("ungoogled-chromium" "ublock-origin-chromium"))

I keep all profiles under a $HOME/profiles directory, which makes it easy to activate them at startup (by running the $PROFILE/etc/profile script; note that this requires GUIX_PROFILE to be bound to that profile).

I can run guix package -m chrome.scm -p ~/profiles/chrome to update or reinstall it. These manifests are a great way to manage packages - I both keep track and partition the packages amongst them reasonably. They also allow arbitrary Guile code execution, which offers some interesting possibilities for install-time scripts.

guix time-machine interacts with profiles nicely. If a build is broken, you can go back a few commits with guix time-machine and install a package from that commit.

It also offers rollback capabilities using the guix package interface.

Using Guix on a server is a decent experience. It's reasonably difficult to manage, but once you have it working, it works fairly well. Writing services is easy once you get the hang of it; I have about 3 custom services that modify various parts of the system. One great thing about them is that they're more or less isolated from each other.

If you're willing to put in the work to write the system definition, it's much easier to maintain compared to a standard Debian or whatnot; where you just have a mess of files, usually but not always located somewhere deep in etc. In Guix, if something is not working, there's just one place to look - the configuration file.

guix system really shines on the server. I have a single directory on my computer which contains the entire server. If I had to move it to a different machine, it'd be as easy as just installing Guix there and typing in guix system reconfigure.

I also use guix deploy so that I don't need to rsync the files over from my computer to the server, I can edit them comfortably on my computer and simply deploy them on the server. The manual states that it's intended for multiple machine deployments, but it's useful even for a single one.

Usually, the biggest problem with Guix services is that there is relatively little of them available. There's a decent amount of them covering most use-cases, but of course not all. Writing your own services is practically necessary if you're running a Guix server. Luckily it's not too difficult once you get the gist of it. I have 3 or so custom services, which are mostly just simple daemons, and those are fairly easy to write.