This will hopefully be a short series about me switching away from Arch to Gentoo. This is the ‘in’ post: why, how, etc. Later will be the ‘on’ post: results, regrets, positives, etc. In between there might be a ’the fuck in’ post where I talk about the problems getting it ‘onto’ to my main machine, but I hope not. Whether or not this switch is a good idea is a life question left up to the reader.

A warning: There’s a good chance that in the first section of this post I will state some things that appears as fact. If it doesn’t have a source linked to it, that likely means it’s something I have read but not saved where I read it. I read a lot of things online but don’t save them because I never think I need to refer to them (unless I’m doing that deliberately). If you disagree with something and have a source(s) I would be delighted to read them. This warning is basically here since having any view on systemd, coding LLMs, or ‘fascism in OSS communities’ tends to attract unsolicited opinions

The Story So Far…

🎵 carry on my wayward son 🎵

I’ve been an Arch Linux user for a few years now. Before that it was Debian (but as a surplus machine to a pair of MacOS & Windows machines). I’ve also mucked around with other distros over the years (putting crunchbang! on an EeePC is something I weirdly remember). However, due to some recent happenings, my personal views don’t necessarily align with using Arch as my primary distro. Of course it does make some things easier (mainly gaming and updating) but here is where you will either a) stop reading, b) get angry at me or c) carry on with trepidation. I don’t like where systemd is heading (or has been) for a while now. In the same week 2 things happened: they allowed LLM generated code, and they allowed that pre-age-verification-compliance code. The former is an infuriating debate that won’t stop (you know my side at least) and I’ll try not to dwell on it here (it will show up again though). The latter is a worrying slide away from Linux principles of what people were warning about nearly a decade ago when systemd somehow kept being the init system of choice for nearly every distro. People more eloquent than me have written very good pieces about this, which I unfortunately never saved to link here.

A Visual Aside

Simultaneously I have been looking for a new desktop environment. I love KDE’s philosophies but the software just works in ways I don’t like. This is not a new thing though, as I’m sure the KDE/GNOME fight is with for every Linux user at one time or another. I don’t like GNOME’s gentle shift to LLMness (albeit that is yet to be proven). This whole thing was to be done during a full system refresh (there’s a slight issue in my bootloader I also want to get rid of). However, during trial some DEs I ended up switching to Niri, because it does everything I want it to in the way I want. This will become important later.

The Easy Way…

‘Out of the fire’ if you will

As a ‘sensible’ person I did explore some alternatives with the primary goal of ‘removing systemd from Arch’. What exists are 2 things that I would not be happy using, and a third that just did not work.

The Bible Failed Us (or how maybe I’m not that great)

The thing that did not work would have been the easiest solution, in the sense that it would have impact my daily life very little, was to rip out systemd from my installation and replace it with OpenRC. Heck, there’s even a page on the venerable ArchWiki with instructions on how to do this.

It did not work, I had to revert everything, and I lost about 45 minutes of my life. I (perhaps stubbornly) decided that I would wrap this whole ordeal into a full system wipe that I’ve been wanting to do.

If you have successfully done this, I would be keen to hear!

So What Does Google Say?

Artix. Even guides that say “do not follow the ArchWiki” recommend using Artix (or it’s repos at the very least). Unfortunately, Artix suffers from a slight fashy issue I am told. There is no direct evidence of this I could find but core devs stating they are in the middle and accepting of anyone echoes Framework’s “big tent” post (if you are unfamiliar with that, please search for it and why it was written). As I cannot vet these concerns either way, I do and will not trust it.

So What Does a Different Search Engine Say?

ArchBang. Huh, this was new. I love a low effort developer page. I agree with a lot of what the dev does. Unfortunately on check the repo I was hit with the Github slop warning¹. Checked for the usual suspects and sigh. Re-read some of the devs posts. They’re not quite full in with the LLM-do-everything-crowd but they use it more than I’m comfortable with. I back this up with that this is also a very hobbyist distro and not a daily-driver.

Ahh shit

The Hard Way

‘And into the frying pan’

I spend a bit of time on the “anti-LLM” side of the internet a.k.a Mastodon and sometimes I find an interesting post leading to an interesting source of information. This particular one brought to my attention that a few distros had taken strong stances on LLM code, that is outright refusing it. Of interest to me were Gentoo (obviously) and Chimera. Chimera scratches a load of certain itches but it doesn’t look too friendly with one of my daily-driver requirements: gaming. And so Gentoo entered the “maybe I should really do this” discussions in my head. I have little experience with Gentoo-running folk, except for that once guy I was friends with back in uni who spend the whole day compiling Gentoo on his laptop and had to sit in awkward places around campus (2010 was a simpler time). But also why are these 2 of interest to me? Well they don’t use systemd. Gentoo defaults to OpenRC (but does offer easy methods to use systemd), while Chimera uses dinit.

Welp then, Gentoo it is. For those unfamiliar, Gentoo has quite the reputation for being ‘difficult’. This is due to the fact you ‘basically’ configure it from scratch. And since I’m a paranoid person that doesn’t want to be without a primary PC for a while, I thought I’d try it out in QEmu first.

Quizzical Emu (wrong on both counts)

The Gentoo community is quite nice it seems as the Handbook for AMD64 is pretty good. As long as you actually follow it. Full disclosure: I use virt-manager to help with QEmu stuff, which is a bit of a double-edged sword. My goal here is to get Gentoo booting into Niri and get some services designed for systemd running.

Attempt 1

Following the Handbook is easy, just a lot of typing. Foolishly decided to use the dist-kernel and about an hour in (while I’m in another room) I run out of disk space.

• Lesson 1: more disk space

Attempt 2

Ok, VM drive now has 3 times the space. Find a comment saying “for your first Gentoo install maybe use the dist-kernel-bin to save on time”. Good advice. All is going well until setting up GRUB and I get a load of weird EFI related warnings. Oh right, I guess I need to use non-EFI boot drive for QEMU. That makes sense. This attempt was also hampered by me fucking up the USE flags for installkernel THREE separate times.

• Lesson 2: actually know what the system is compatible with
• Lesson 3: Measure twice, cut once

There was an attempt 2.5 where I restored a snapshot and tried again but I forgot to emerge sys-kernel/installkernel after setting the dracut USE flag. Oops

Attempt 3

Get all the way through and Gentoo boots! Big relief (I enjoy an easter egg as a celebration). Now to install Niri. Following the Gentoo wiki this is easy. I execute dbus-run-session niri --session and everything halts.

My inexperience with QEmu and lots of things now becomes a problem here. First thought is that maybe this VNC viewer isn’t capable of handling graphics. So I try configuring the display to Virtio with no 3D acceleration. Same result. This time I enable 3D acceleration and get greeted with an error saying I need to configure a GL backend. Fair enough, but in virt-manager this isn’t possible, it needs a command-line option. Eventually I find that /var/log/libvirt/qmeu/NAME_OF_VM.log stores the qemu command that virt-manager called. Try it out with the suggested fix and still nothing. Now begins the digging. I find a lot of stuff about libvirt and QEmu and OpenGL having myriad issues with myriad causes. Eventually I track down a similar problem on a Github issue for libvirt. Ultimately this works (there is some stupidity that I do applying this fix that makes it take longer than it should).

And now I have Gentoo running Niri in QEmu!

Fun Times Ahead*

Now I need to see if I can get some other things behaving nicely, specifically SDDM, a daemon I use, doas and maybe a couple of other things. I would also maybe test Steam but that’s definitely pushing the limits here. I also want to try building and managing a tool from source that has no Gentoo flavour.

I had technically set doas up during the install phase but with a very annoying config:

permit :wheel

I would rather like it to behave like how sudo defaults: 2 retries, remember rights for 5 minutes. Well the retry prompt doesn’t seem to exist but persistence does:

permit persist :wheel

Nice.

Why doas? I’ve heard good things about it (and also capsudo) so I thought I’d try it out

SDDM was also easy thanks to the docs (yet again). Tiny Niri issue but not a big deal. Now for the first daemon: jottad. I use Jottacloud as my Dropbox-replacement. As much as I have minor issues with it, it’s pretty good and the companies overall mission is good (except the lack of OSS but that’s pretty normal with cloud storage companies).

jottad

This is a little more involved. Firstly, you need to get the bins from their site. The tarball actually contains some default config and basic docs, which was very unexpected. However, it’s built around systemd. So that means writing an OpenRC script, which is weirdly tiny.

#!/bin/bash
command="/usr/bin/jottad"
pidfile="/run/${RC_SVCNAME}.pid"

After moving the bins to /usr/bin and the default config to /etc/jottad/, rc-service start jottad does…nothing. No logs. Just nothing.

Reading some docs I find this line from the OpenRC Service Script Writing Guide:

The interpreter for service scripts is #!/sbin/openrc-run. Not using this interpreter will break the use of dependencies and is not supported

Oops. I switch to that and I’m greeted with * WARNING: jottad is already starting but nothing actually happens. A quick search for this and I end up back on the Gentoo OpenRC page. I just need to run openrc to see what’s going wrong, which seems to be start-stop-daemon: --stdout and --stderr are only relevant with --background. Straightforward I guess. I add the line anddd it starts! So the complete script is as follows (extra notes in comments):

#!/sbin/openrc-run

depend() {
  need net # jottad needs to look at 127.0.0.1, I didn't try 0.0.0.0 that would make this not needed
}

command="/usr/bin/jottad"
pidfile="/run/${RC_SVCNAME}.pid"
command_args="stdoutlog"                # tell jottad to use stdout for logs
output_log="/var/log/${RC_SVCNAME}.log" # need to put logs somewhere
error_log="/var/log/${RC_SVCNAME}.err"  # need to put errors somewhere
command_background=true                 # from error message above
command_user="root:jottad"              # uhh this might be wrong but I'll deal with that later

Unfortunately I now need a way to handle updates. That will come later once I’m fully Gentoo’d (that sounds gross).

To test jottad I kinda need to install a browser (Jottacloud uses token auth and copy/paste in QEmu ain’t there), and since I’ll be doing that anyway I might as well and install Librewolf (but the bin version, I don’t feel like waiting for several hours). But first…

fuzzel

Let’s get some more of my ’normal’ functions going here. I use fuzzel as my launcher because I ran into a lot of issues with the other one I was using (that I forget the name of) and I just decided “simple is best”. And here is where I learned about “unmasking”. Conceptually it makes sense, but practically it would be really nice if there was an easy way to see why and when a package was masked. The wiki to the rescue.

Librewolf

Man, that Gentoo wiki really is something. It’d be better than the ArchWiki iff more people used Gentoo I think. Anyway the Librewolf page is pretty good. And it works.

Running out of things tricky to test now. Everything else I use is pretty standard, except maybe my dotfile management.

chezmoi

Oh, it’s in Guru. No biggy. Easy. I guess this didn’t deserve it’s own section.

Steam

From the steamed hams

Again, the wiki entry steps in clutch with it’s slightly-poorly-worded paragraph about ‘pure Wayland systems with a global -X flag’ (guess what I did). Alas, emerge still blocks me due to dbus having it’s ABI_X86 flag set to 64. A quick search to validate if I was correct and I was halfway right. Instead of setting the ABI_X86 USE, I just needed to sigh enable the X USE flag for it. Now I can install steam-launcher…

…Why is it compiling llvm?… This was the only surprising thing to happen and it’s because I didn’t actually check what was being pulled in.

4 episodes of One Piece later and we’re done. Well, after a restart really. I’m not going to try and get WINE or Proton working just here, because a) it will take a while and b) testing it will be a bit of a pain. But I can do something…

I think that’s that then…

Conclusion

Am I ready to make this on my main PC? Maybe still with the dist-kernel. But in that case maybe I should practice with the source kernel in QEmu (albeit that will take many hours to compile). I do have an unused laptop (“unused” meaning it has Proxmox on it but it’s been dormant for a couple of months) that would make a great weekend project and a real testbed (i.e. test full functionality by plugging it into my setup and using it for a couple of hours/days).

The setting up of various USE flags and licenses etc. is really cool, BUT bringing a system back to working after a catastrophic failure would be no mean feat. I’m not really sure what the best approach to backing up and restoring alllll those files would be. I think that before I start the full system wipe, I need to resolve that. And also investigate some sort of ‘rollback’ management. The ability to completely break your system by accident is high. This scares me a bit, mainly because I don’t want to spend 5+ hours setting things up from scratch if I fuck something up. And well I totally forgot about when the profile updates. That I have no idea about. I just need to pay attention to the eselect news list outputs.

As I alluded to back at the start of this, I’m also in the middle of changing my display environment and entire workflow (this includes switching to vertical tabs and still migrating to helix from vim). There are still some things that need to worked on there, but most of those things are effectively trivial. This is the first time in 16 years I’ve done without a ‘Quake-style’ terminal and that takes a bit of work to undo. I still also have a bunch of other things I need to do, such as restoring my web services.

If, somehow, you’ve made it this far and are also curious about trialling Gentoo: do it! Maybe just use this post as inspiration and not a source of truth.

Some Other Miscellaneous Learnings

1. Mirrors can sometimes be borked. I need to see if there’s a way to reduce the timeout. I wish there was a mirror-ranking system that could be done once a week or even daily. Maybe I need to use the rsync versions instead
2. Searching for packages can be a bit of mess, perhaps there’s a way to make this easier…
3. There is a lot more manual work than I anticipated, but mostly coming from other places (see package management). It’s interesting, there’s some really easy solutions you could do but they would take away from the spirit of Gentoo. I just wish the some more critical information was more readily available
4. Setting up packages take a lot longer than you expect, even when everything is working properly. Find some other things to do while you wait

I’m sure I learned some other things while doing this (I know I did) but I think these are the main things to consider when switching to Gentoo. It’s not the groundbreaking learning experience I’ve seen people say online, but it’s certainly not a passive experience.

This was mostly written while having Soulless’s “Shiny In Purity” on repeat. Cracking album, give it a spin