GNU Guix Package manager & OS
I have been using GNU Guix for about a year now. I use the Guix System OS on my second laptop and the server this website is on, but I also use the package manager on my main Debian laptop.
1. Guix shell
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
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
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
It also offers rollback capabilities using the
guix package interface.
3. GuixSD on a server
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
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.