Yesterday, I installed Fedora Silverblue into a KVM-enabled qemu image from my GNU Guix desktop. I was attracted to the immutable design which is fairly similar on the surface to how GNU Guix works. Under the covers, it’s a lot different, but I thought I’d go over my initial impressions.
Fedora Silverblue is distributed with an ISO image which boots into a graphical (i.e. GTK) installer. It’s one of the shortest and easiest Linux installs I’ve done. That said, I didn’t have to worry about any sort of hardware compatibility given I was running it on virtual hardware. Because the OS runs on an immutable image, there weren’t many options in the installer with respect to choosing initial software.
When you boot in and take a look around, it looks like this:
/etc are writable.
/var. Binary directories are moved to
/usr. See also:
Here is the filesystem layout.
/usr directory is mounted read-only. The binaries there
basically come from
OSTree. There are
three ways to install software:
rpm-ostree installwhich creates a new system image atomically and requires you to reboot into it to take effect. (You can boot into previous versions). This might be what you use to install core OS components like your shell, wayland compositor, libvirt, etc.
Flatpak. I haven’t tried this one. I sort of think of it like Ubuntu snaps, which I never tried out either. I think you would use this for general consumer software like GUI chat clients, office apps, games, etc.
toolbox. This is a layer over podman (same idea as docker) that seems to have some quality of life improvements for developers or regular users that want a sandbox environment. I think the ideal scenario here is if you
git clonesome project you are working on to
~/src/myproject, you could create a toolbox for working on that project. When you run
toolbox create, you’ll get a regular fedora distribution by default. If you’re working on a python project, you
dnf install pythonand whatever else you want, and the installed things will just be local to that toolbox. I haven’t played with toolbox for more than a few minutes, but I have a few worries about getting too comfortable with a semi-ephemeral development environment. It feels like it could be a gray area between pet and cattle.
While it might be confusing to average users to have at least 3 ways
to install software, they all have their own pros and cons, so I
appreciate having the flexibility to make my choice. I think they
should change the default behavior of
rpm-ostree install in
non-server environments to run
rpm-ostree ex apply-live to avoid the
reboot. I feel like they should be able to figure out how to get
systemd to restart the services.
Since managing installed software is a large part of the operating system experience, you might wonder how these three options compare to GNU Guix. Guix is fairly similar in that it has a read-only/immutable software partition. While Silverblue uses flatpak and toolbox for library conflict resolution, Guix can install conflicts side-by-side due to the way it structures the file system. Probably best explained like this:
> which ldd /home/timmy/.guix-profile/bin/ldd > ll /home/timmy/.guix-profile/bin/ldd lrwxrwxrwx 17 root root 74 Dec 31 1969 /home/timmy/.guix-profile/bin/ldd -> /gnu/store/k2gkdpplnnvknfa1c3sdlzbvx6bs468m-clang-toolchain-12.0.1/bin/ldd > ldd /gnu/store/k2gkdpplnnvknfa1c3sdlzbvx6bs468m-clang-toolchain-12.0.1/bin/ar linux-vdso.so.1 (0x00007ffe2c7f2000) libdl.so.2 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libdl.so.2 (0x00007fc0a0dee000) libc.so.6 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 (0x00007fc0a0c31000) /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2 => /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/lib/ld-linux-x86-64.so.2 (0x00007fc0a0df5000)
ar might use glibc-2.31 but some other package could use it’s own
version. Guix is smart enough to share the same
if two packages use the same version. This way conflicts can be
resolved without containers/chroot. When you install software to
guix install, you don’t have to reboot either,
which is nice. When you do
guix system reconfigure to upgrade system
packages or system services, shepherd (Guix init system) will
I think Guix overall has a more technically elegant solution for
managing software, but Silverblue is worse-is-better and more
mainstream. I think for an ephemeral development environment,
guix shell has advantages over
toolbox, but it might really depend on
your scenario. I think Silverblue will have better container support
out of the box, so if you work with containers, Silverblue will be
easier to get started with. As of this writing, Guix only supports an
old version of docker. Separately I tried packaging podman for
Guix. It took a
couple hours on a Sunday and I was able to run an alpine image without
sudo. But that might not be an option for everyone unless you are
comfortable picking up Guile Scheme and rolling your own
packages. With Guix, you will have more luck packaging software than
trying to compile something outside of the packaging system due to the
systemd has a larger ‘compatibility list’ than GNU shepherd, and I feel you are more likely to find yourself in a “Sadly Outta Luck” situation using Guix than you would with Silverblue. If you prefer to use free software, I think Guix is a better fit due to the focus on it and aversion to software telemetry. I was thrown off a bit when Silverblue asked me if I wanted to connect a social media account during the install process. Thankfully it allows you to skip that step, but I could never imagine Guix having a prompt like that.
Long story short, while I could imagine installing Fedora Silverblue on a workstation for work, I think Guix might be a better fit for me on my personal machine where I enjoy the practice of system crafting.