Planet Guix

Automating and managing multiple Guix profiles.

Guix profiles to logically separate package sets

A recent study published in Nature Scientific Data in February 2022 gives empirical insight into the success rate of reproducing R scripts obtained from Harvard’s Dataverse:

While my first impression of Guix 1.4rc2 on NV41PZ was only days ago, the final Guix 1.4 release has happened. I thought I should give it a second try, although being at my summer house with no wired ethernet I realized this may be overly optimistic. However I am happy to say that a guided graphical installation on my new laptop went smooth without any problem. Practicing OS installations has a tendency to make problems disappear.

On the shortlist of things to try on my new laptop has been Guix. I have been using Guix on my rsnapshot-based backup server since 2018, and experimented using it on a second laptop but never on my primary daily work machine. The main difference with Guix for me, compared to Debian (or Trisquel), is that Guix follows a rolling release model, even though they prepare stable versioned installation images once in a while. It seems the trend for operating system software releases is to either following a Long-Term-Support approach or adopt a rolling approach. Historically I have found that the rolling release approach, such as following Debian testing, has lead to unreliable systems, since little focus was given to system integration stability. This probably changed in the last 10 years or so, and today add-on systems like Homebrew on macOS gives me access to modern releases of free software easily. While I am likely to stay with LTS releases of GNU/Linux on many systems, the experience with rolling Guix (with unattended-upgrades from a cron job to pull in new code continously) on my backup servers has been smooth: no need for re-installation or debugging of installations for over four years!

Installing applications in Guix with manifests

The last time I bought a laptop, I got a used Thinkpad X220 from eBay. I loved that laptop, but time marches on and old hardware eventually becomes too slow for modern development needs. After a lot of indecision, I bought a 10th generation Thinkpad X1 with an Intel Core i7-1280P CPU, 32GB RAM, and 1TB NVMe SSD. While they don’t make Thinkpads like they used to, I’m still really happy with it and glad I chose it. Despite the keyboard changes, the TrackPoint™ is still there and I don’t think I could feel good using a laptop without it. Below I will explain all the steps I took to get the Guix distribution setup nicely on it. Maybe it can help you setup your own Thinkpad X1 or some other computer that requires more than what Guix provides for all of the hardware to work.

Using channels to find more apps on Guix - including proprietary ones from the nonguix channel

We are happy to announce the release of GNU Mes 0.24.1, representing 23 commits over five months by four people.

The Guile bindings for GnuTLS has been part of GnuTLS since spring 2007 when Ludovic Courtès contributed it after some initial discussion. I have been looking into getting back to do GnuTLS coding, and during a recent GnuTLS meeting one topic was Guile bindings. It seemed like a fairly self-contained project to pick up on. It is interesting to re-read the old thread when this work was included: some of the concerns brought up there now have track record to be evaluated on. My opinion that the cost of introducing a new project per language binding today is smaller than the cost of maintaining language bindings as part of the core project. I believe the cost/benefit ratio has changed during the past 15 years: introducing a new project used to come with a significant cost but this is no longer the case, as tooling and processes for packaging have improved. I have had similar experience with Java, C# and Emacs Lisp bindings for GNU Libidn as well, where maintaining them centralized slow down the pace of updates. Andreas Metzler pointed to a similar conclusion reached by Russ Allbery.