Midnight Pub

Migrating from Arch to GUIX, or, An Exercise in Toe-Dipping


Patting myself on the back

> Larry Hardcore (Clone High):
>    See, I was into everything: weed, grass, ganga, reefer, marijuana,
> mary jane, I did it all. I even smoked pot once.

or to paraphrase:

> Tetris (Midnight.pub):
>    See, I was into everything: Gentoo, Ubuntu, Slackware, Debian, 
> Fedora, Puppy, Arch, I did it all. I even tried Linux once.

As a friend of GNU, a contributor to the EFF, a rabid follower of Cory Doctorow and RMS, a subscriber of all that is FOSS and the FSF, an all around RJ¹ - and just an insufferable person in general - I've decided that the correct, moral, ethical, right, honorable, just, fair, proper, and applaudable thing to do is move more towards GNU as my choice of OS


GUIX is a package manager that can work on top of any existing flavour of Linux, and indeed can be considered a standalone OS in itself when deployed with either the linux-libre or the hurd kernel².

It can create environments and even docker images from a desired set of packages:

guix pack -f docker gimp inkscape <other>

similar to conda. It also allows you to completely declare your desired system, complete with packages and configurations from a single specification written in Scheme (Guile)⁴, similar to NixOS.

Migrating Arch to GUIX

Arch linux is pretty bare-minimal OS, that installs only what you want without any extra bells and whistles, and since it's my OS of choice on all my machines. I decided I would uninstall all my packages that depend on "pacman" (Arch's default package manager), and install them via "guix" using the "guix-installer" package on AUR⁵ and running `sudo guix-install.sh`

A nice way to find your top-level packages which are not dependencies on others is to run

comm -23 <(pacman -Qqt | sort) <(pacman -Sqg base base-devel | sort)

From this list you can work your way through uninstalling each package `pacman -R <blah>` and installing the guix equivalent `guix install <blah>` (note: no sudo here).


There should be no difference in filesystem usage unless you forget to allow guix to download pre-built binaries. I've noticed that some kde packages don't have pre-built binaries, so these might take some time to build locally. I recommend just purging the whole KDE ecosystem if you can (bye bye sweet kdenlive).

Firefox is not available (GNU Icecat is the preferred browser), so this was a package I kept on Arch as I need Firefox. It complained about missing libraries, but you can get around this by running

LD_LIBRARY_PATH=/usr/lib firefox


Otherwise, everything is running just fine! At some point I will move to a full GUIX system, but for now, I'm content to keep my Arch packages to the bare minimum and just use GUIX whenever I need to install anything.


1: http://www.linfo.org/acronym_list.html
2: https://guix.gnu.org/en/about/
3: https://nixos.org/
4: https://www.gnu.org/software/guile/
5: https://aur.archlinux.org/packages/guix-installer


Have you taken a look at Nonguix? It seems to offer a firefox distribution.



Woah, no I hadn't...! This is the game changer here. I can actually migrate my full setup, firefox, dwarffortress and all



Thanks for sharing this ~tetris. Super interesting 👀



Welcome - I've also written my first guix package, after much tears and effort. If you're ever thinking of transitioning, let me know and I should be able to help



Just barely related (trigger: the words "friend of GNU")... and forgive me if I've posted this before (getting old...), but once upon a time I recorded song spoofs under the band name 'gdbeatles', and this ("'Till There Was GNU") was one of their hits:



I remember this (and you've got a great voice btw) (also: your song is listed on gnu.org)!

As I wrote in my own other comment in your Linux post:






You might like Bedrock Linux.


You were not kidding!

I've never seen such a system that mixes-and-matches different package managers over different systems. How the hell does it manage the libraries in the background without duplicating them?



The details of how bedrock works are interesting, although for simplicity's sake it mostly boils down to a pair of FUSE filesystems: etcfs and crossfs.


The two of them together consist of less than 5000 well-commented lines of code total, so likely worth the read.

That said, as I understand it, it does duplicate libraries when it comes to dependencies -- each package manager is entirely unaware of the other package managers running in other stratum.



Hah. My C/C++ is good, but not ahha-an-implicit-linux-struct-very-nice kind of good

Though, I wonder how hard it would be to have a background process that scans library paths for identical files, and then deduplicates them to some central bedrock-only library path?



I imagine it would be very possible, but I'm not sure just how much of a space gain you would get from it -- builds often aren't entirely reproducible and even when they are, different distros may package them with slightly different build-time configuration.

The overhead of adding a new codepath (and possibly replacing a new part of the filesystem with more FUSE) would, I suspect, heavily outweigh the benefits, although I've been wrong before.



Ah true -- I forgot how those pesky timestamps ruin everything. I still don't understand why they're needed in builds.