Yesterday (2019-10-19), I attempted to install the GNU Guix distribution on my main laptop (Thinkpad x230, second hand). I had high expectations coming from Debian Buster, and I’m sad to report, that while it’s usable, it’s not quite enjoyable.
This post will outline my experiences, in stages. What worked and what didn’t. It’s supposed to serve as a cautionary tail for anyone who is interested in trying the same path as I did – that includes my future self. That being said, I don’t want this to scare anyone away (especially if one has enough time on their hands). A few issues I have encountered and solved might even help someone, one day.
As of writing, I am still running Guix, and I plan to at least try using it for a few days to a week. I will be updating this post as I go along (hence I haven’t added it to my atom feed yet).
As already mentioned, I had been running using Debian Stable for the last few months (as I shut it down, I had an uptime of just under 60 days). But as everyone knows, the better something works, the more boring it is.
It has been a few years since my distro hopping days, and even longer since the days I liked using minimal, tiling window mangers. I have settled down using mid-weight desktop environments like XFCE and MATE, the latter being what I had on my Debian machine.
I don’t need fancy effects or a hyper-integrated desktop. My main priorities are:
Debian does all of these quite well. The packages are well prepared, the default installation has more or less sane defaults (I usually change the MATE theme to Clearlooks, set up a single panel desktop, change wallpaper, but that’s it).
What’s also worth noting is that setting this up (post-installation) takes about half an hour. Maybe I forget to install a package, but that’s quickly done too.
But then I restarted my device, and booted from a USB stick.
Anyone who has tried installing Guix before 1.0, will have to admit that the TUI installer is more comfortable. It’s not perfect, I wanted to keep my
partition, but it wasn’t quite clear on how that could be properly set up. But for the most part, the process is straightforward.
One is asked a series of questions, and finally ends up with an
configuration – that is a Scheme expression found in
that may look something like this:
(use-modules (gnu)) (use-service-modules desktop networking xorg) (operating-system (host-name "viero") (timezone "Europe/Berlin") (locale "en_UK.utf8") (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi"))) (file-systems (cons* (file-system (device (uuid "dc8f6aaf-5fce-4f72-9c46-7e4b34116768" 'btrfs)) (mount-point "/") (type "btrfs")) %base-file-systems)) (swap-devices '("/dev/sda3")) (users (cons* (user-account (name "ben") (group "users") (supplementary-groups '("audio" "netdev" "video" "wheel")) (home-directory "/home/ben")) %base-user-accounts)) (packages %base-packages) (services %base-services))
The intention is that this specifies the entire system, anything from the keyboard layout, over packages one would like to have installed (globally) to the kernel that wants the OS to use. See the Manual for more details.
The installation takes a bit, but it’s not much more or less that one would expect from any other system. When done, it prompts the user to reboot and then the new Guix system should start.
I had chosen XFCE as my desktop environment, to keep it safe, but had to use GDM as my display manager (login screen). Sadly, XFCE didn’t quite work as expected. Various bugs surprised me, such as all terminals crashing when trying to set the font to the default system font.
If one is careful, most of these could be circumvented, until one chooses to deal when the later on. So instead I decided to focus on installing the necessary packages.
One things that might surprised newcomers, is that compared to most distributions, that package manager
doesn’t have to be run as root. This is because of way that transactional package managers operate, and the fact that they allow different users to have different versions of the same package installed.
To understand this, one can take a look at how
$ ls / bin boot dev etc gnu home mnt proc root run sys tmp usr var
For the most part, it looks just like one would expect it from any other system, but a few surprising differences pop up when looking into
$ ls -F /bin sh@ $ ls -F /usr bin/ $ ls -F /usr/bin env@
Not only are these mostly empty, but all they contain is at most a symbolic link. These point towards cryptic paths such as
in the case of
. The rational behind this is that all packages are stored in
, each version in it’s own content-addressed directory. But how does the shell or any other program know where to find it’s files?
, one may ask. Understanding this is understanding the trick behind transactional package managers:
When running a command like
guix install emacs
you contact a daemon that ensures the
package will land in
. Your package managers then uses symbolic links to prepare a binary directory within your home directory
, consisting of links to these specific builds. That’s also the reason your
will look something like this:
/run/setuid-programs /home/$USER/.config/guix/current/bin /home/$USER/.guix-profile/bin /home/$USER/.guix-profile/sbin /run/current-system/profile/bin /run/current-system/profile/sbin
The advantages are that “installing”, “removing” or “upgrading” a package in your user “profile”, ends up only being a re-linking, making the process effectively transactional and un-doable. Just run
guix package --roll-pack
to “undo” an installation.
But back to my case, this part of Guix works quite well. Then again, it would be quite a disappointment if a distribution that revolves around a package manager wouldn’t do a good job in this field.
I have mentioned a few “annoyances” above, but the main problem at this point was that I was stuck next to my router. The reason for this was that Guix comes with Linux Libre
not only by default but as it’s only option. This was where I had given up the last time, but this time I knew how to install “regular” Linux(using the nonguix
). This change in
took a while to prepare, since I had to build my own Linux kernel. All in all it was rather painless though, since the procedure ends up being quite automatic.
Having have solved this, I tried to proceed in configuring a more comfortable work environment. Due to the issues with XFCE, I decided to try MATE. Guix makes the switch easy. In your configuration, one just has to replace a line with
guix system reconfigure /etc/config.scm
. Sadly I was disappointed to see that this DE was even less usable. Main issues were:
gio-launch-desktop. After a while I figured out this was related to the package
glib:binnot having have been installed.
Luckily reverting the change wasn’t difficult, so I changed back to XFCE this morning (2019-10-20). With a bit of effort, I could get XFCE to work and look more or less the way I want it to. Here’s a screenshot, though it shouldn’t be too surprising to anyone who as used XFCE before:
Other still persisting issues are: - IceCat (GNU’s Firefox) chooses to render numbers using the “ojiOne Mozilla” Font. This font doesn’t seem to have number glyphs, so it just looks like using TeX’
command. - My existing GnuPG scripts don’t work as expected, since it cannot find
, even though it is installed (this is inhibiting me from using mail, or logging in anywhere). - I can’t change the system volume, neither using
, let alone with an applet. Luckily the default volume is acceptable… - Passwords and credentials aren’t being managed correctly by the keyrings. This is probably an easy fix, but I haven’t had to think about these things for a while.
As I started this text, I don’t want to scare everyone away. It’s not only the Idea of Guix that has lead me down this path.
Debian has a very strict package admission procedure, so packages often work well. For a new package to be accepted into the stable branch, it has to pass a number of days without any bug reports. So despite having over ~50,000 packages, some are missing, temporarily or were just never added.
But all of these are small advantages, they could be installed and maintained manually anywhere else too.
What I haven’t gotten to yet, is using Guix to study, change and maybe even contribute back to projects. This includes Guix itself. The [
] command is critical in this field.
In other news, Emacs works well, except for the subsystems that are affected by what isn’t properly set up yet (eg. mail).
I hope this post could until now serve as a good outline of what to except from Guix. I will be updating it in the days to come, adding fixes and issues as I go along.