Midnight Pub

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

~tetris

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

Background

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).

Caveats

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

Afterthoughts

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.

[References]

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

dog

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

https://gitlab.com/nonguix/nonguix
reply

tetris

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

reply

xiu

Thanks for sharing this ~tetris. Super interesting 👀

reply

tetris

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

reply

inquiry

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:

sound
lyrics
reply

tetris

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:

I THOUGHT YOU WERE ALREADY ON TEAM GOOD!
reply

inquiry

Thanks!

reply

contrarian

You might like Bedrock Linux.

reply

tetris
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?

reply

dog

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.

https://github.com/bedrocklinux/bedrocklinux-userland/tree/master/src/etcfs
https://github.com/bedrocklinux/bedrocklinux-userland/tree/master/src/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.

reply

tetris

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?

reply

dog

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.

reply

tetris

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

reply