GNOME in GuixSD
You would think adding GNOME is routine distro work involving a lot of packaging and bits of plumbing that’s already been done a hundred times, which is probably true! Yet, adding GNOME support turned out to be interesting in many ways: it’s a good test for GuixSD’s declarative operating system configuration framework, it’s a way to formalize how this whole software stack fits together, and it’s been an insightful journey into GNU/Linux desktop plumbing!
Of course, a lot of software needs to be packaged to begin with. This had been on-going for some time, culminating with the addition of a gnome meta-package thanks to the hard work of 宋文武 (Sou Bunnbu) and other hackers. On the way, we added an auto-updater for GNOME packages, because all these package recipes need love.
The more interesting parts were system integration. Modern GNOME/Freedesktop environments rely on a number of daemons, most of which talk over D-Bus, and extending each other’s functionality: udev, udisks, upower, colord, geoclue, and polkit, to name a few. Being able to compose all these system services was one of the driving use cases behind the design of GuixSD’s new service composition framework. With this design, we knew we were able to have fine control over the service composition graph. Challenge #1 overcome!
Since GuixSD uses the GNU Shepherd and not systemd as its init system, we needed a way to provide the “logind” functionality that systemd implements, and which allows GNOME to know about users, sessions, and seats.
So Andy Wingo courageously started by extracting logind from systemd, leading to “elogind”. At this point, we had this daemon that could keep track of logged-in users and active sessions, and which GNOME could talk to over D-Bus… provided all the relevant PAM services would use the pam_elogind module so that elogind knows when a user logs in and out, as Andy nicely explained it.
This pam_elogind thing is a typical example of a cross-cutting concern: if you use elogind, then you want all the relevant login-related PAM services (mingetty, the X login manager, commands such as su, the SSH daemon, etc.) to use pam_elogind. To achieve that, we updated our PAM service such that it could be extended with such cross-cutting modules. At last, we had proper logind support!
At this point, the brave could start using GNOME on GuixSD but would soon realize that, for example, the “power off” button wouldn’t have the desired effect, or that changing a laptop’s backlight wouldn’t work because polkit, the daemon that allows unprivileged users to perform privileged operations like that one, was missing essential policy files.
You would think you can finally change the brightness of your screen, but no! Turns out that polkit would refuse to run gnome-setting-daemon’s backlight helper program because elogind happened to fail to map PIDs to sessions. Whatever.
Of course there were still a bunch of embarrassing glitches such as GNOME suspending right after it wakes up from suspend, failure to start in QEMU, or the lack of GNOME’s favorite font. Well, it seems that all these are gone now!
About GNU Guix
GNU Guix is a functional package manager for the GNU system. The Guix System Distribution or GuixSD is an advanced distribution of the GNU system that relies on GNU Guix and respects the user's freedom.
In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native Guile modules, using extensions to the Scheme language. GuixSD offers a declarative approach to operating system configuration management, and is highly customizable and hackable.
GuixSD can be used on an i686 or x86_64 machine. It is also possible to use Guix on top of an already installed GNU/Linux system, including on mips64el and armv7.