Guix: first impressions

I have a VPS that I use mostly as a mail server, running on Nixos. Two weeks ago, I decided to relocate it from Hetzner to BinaryLane in an effort to use local companies.

It was a good opportunity to migrate it to Guix.

Here are my first impressions of Guix.

Disclaimer: This is not a thorough review of Guix, or a full comparison of Guix vs. Nixos. These are my very first impressions of Guix, which only consists of a few hours of usage. Take it with a grain of salt.

Regarding my experience with Nixos, I have been daily driving Nixos and Nix-darwin for a couple of years, but never packaged my own software or created my own derivations from scratch. I would not consider myself an advanced user of Nixos.

Installation: nothing to Report

Binary Lane was quite helpful here. It has a BYO linux distribution option allowing you to use an ISO image hosted online directly. You simply select the BYO option and point it to the ISO image from the Guix manual. A few minutes later, I had Guix running on the box.

I don’t know if this feature “point to a hosted ISO image” is something available with most VPS providers, but I was pleasantly surprised. It just worked. On Hetzner, I used NixOS anywhere to get started. It was a lot more involved and required more ’nix’ knowledge.

The installation was uneventful, the documentation was very easy to follow. Which leads us to the next point.

The documentation is very approachable

I read most of the “manual” and it is very readable. The contributors behind the documentation put a lot of efforts into it, and it shows.

Declarative distros such as Nixos and Guix come with inherent extra complexity compared to an classic distribution.

Nixos is infamous for its lack of documentation which creates challenges for newcomers. On the other end, I found that the Guix documentation does a fantastic job at easing the learning curve. It is clear and easy to follow.

The progression is clear

As you start, you are encouraged to use Guix in an imperative manner, such as `guix install emacs`. When used imperatively, it is more or less like any classic package manager.

It might feel like it defeats the purpose of using a declarative distro, but it allows you to build confidence and use your system from day one.

Later when you are ready to use the declarative package management, you can use “guix package –export-manifest” to easily migrate.

Nix can also be used in a similar fashion, but I don’t believe the migration is as simple.

Again, the documentation does a great job on accompanying you.

The CLI seems more coherent

Nix CLI is complicated. There are multiple generations of the CLI currently in use.

For example, `nix shell` and `nix-shell` are two valid, distincts binaries.

Guix CLI is much more consistent and the naming is, in my opinion, clearer.

The filesystem configuration is built in, as well as remote deployment

The disks and filesystem management is built-in in vanilla Guix. With Nixos, I use `disko`. I don’t believe it’s a built-in functionality.

Having the declaration of your filesystem built-in the without having to bring dependencies is a nice touch. It is an inherent part of your machine configuration, it’s great to see it as a first class citizen.

The same goes remote deployment. In Nixos, I used the excellent deploy-rs from serokell. Guix has it built in via `guix deploy` (still experimental). I use remote deployment a lot and I was happy to see it built in Guix itself, one less decision and dependency.

Guix pack is exciting

The command `guix pack` is a very exciting. It allows you to create a software bundle tarball that can used on non-Guix systems.

I can see myself hosting a bundle of my “core” tools, such as my emacs with its configuration, alongside a few core utilities. If I ever find myself on someone’s else computer, I could download the bundle and have access to a minimal configuration without altering the host’s machine.

It is possible to package your bundle with flakes in Nixos, to use on any nix-enabled systems. I am unsure if there is a ’nix-agnostic’ way of bundling your software.

A welcoming community

While the Guix community is still fairly small, it is genuinely welcoming and caring. The IRC channel is patient with newcomers and very helpful.

It seems slower (?)

It is hard to compare 1:1 as I downgraded the size of my VPS, but it does seems slower when compared to Nixos. Building Exim from source was excruciating slow.

You can use substitute servers to avoid building everything from source. Subsitute servers act as build farms, where built software if cached. If you need a package, you can get it pre-built from the subsitute servers.

It makes Guix system reconfigure much faster, but unfortunately the official server I use was down yesterday. It might be a case of bad luck, but incidents seem frequent when I looked at their uptime. It is, after all, a small community of volunteers.

You can create your own subsitute servers. In the future I might use my homelab as one. It is much more performant than my VPS and it could resolve the issue altogether.

There was project of creating peer-to-peer subsitute servers, but it seems on ice right now.

The number of packages available is much lower

Out of the box, the number of system packages available is limited compared to Nixos. Guix embrace the GNU philosophy and does not propose or encourage the use of proprietary softwares.

It doesn’t mean you can’t have them: Guix will happily let you bring your own if you wish or need to, simply by adding a non-official channel. There are channels out there offering closed source packages.

It is a misconception that Guix forbids the use of proprietary software; that is not the case.

You can also create your own package.

Creating your own package

From reading the documentation, ‘packagers’ (the term used for people wrapping software into Guix packages) are well looked after. There is an entire chapter dedicated to packaging software. The Guix CLI comes with a bunch of utilities to help packagers.

This is nice to see.

I don’t know if Nixos makes packagers’ life easy - I never tried to make my own packages beyond an overlay here and there.

Guix does make me want to participate; I feel encouraged to dive into packaging.

Kudos to the Guix’s contributors

I’m genuinely impressed with the documentation of Guix. Kudos to all contributors.

Contrary to my first encounter with Nix, I do want to go deeper with Guix. With Nix, more often than I care to admit, I was completely lost. When I first started, I relied a lot on Vimjoyer’s amazing Youtube channel as the “documentation”, as well as thiscute.world’s blog. Later, I would go to the nix’s source directly to try to make sense of it all.

I need to underline the fact that I came to Guix with more experience than when I first started to use Nixos. If I went from Guix to Nix today, I probably would find Nix easier than when I first used it.

I never tried to go through the Nixos documentation beyond the installation. Part of it is entirely on me. Part of it is how obtuse the documentation is.

I love Nixos. The benefits far outweigh the hurdles. I don’t want to denigrate it or give the impression that it is not that great. It’s an incredible piece of software.

I may not have put enough efforts in grokking nix but I never had the desire to go deep with it.

From my naive, first experience with Guix however, I actually want to grok it. It feels like it could be the endgame for me, and I have made the decision to go all-in on Guix.

I will blog about my progress here.