I recently made the switch to Void Linux and I'm really enjoying it. Void Linux is very close in nature to Arch Linux. It's a build-your-own-experience kind of distribution. I like those. For the sake of fairness, comparisons to Arch Linux will not be made going forward.

Why switch?

I like trying out new and different things. Void Linux was different enough to warrant inspection. I was curious about Void Linux the most because it's a traditional distribution (no fancy-shmancy derivations or immutable filesystems) with a few interesting twists.

What's different about Void Linux?

Off the top of my head:

• the freedom to choose between musl and libc.
• a dead simple init system called runit
• a solid package manager called xbps although the name really sucks to type (for obvious reasons); package updates are sparse so it's easy to keep up with my system
• it's easy to reason about and that boils down to the choices of programs that ship with it by default (have you seen acpid?)

Initial difficulties

I tried to install Void Linux three times with LVM on LUKS (following the exact instructions of the Void Linux wiki). I failed in every instance.

GRUB kept insisting that the /boot/efi filesystem was not a recognized filesystem even though I had used VFAT, I didn't specify the size of the file allocation tables so it was up to mkfs.vfat.

Just to be sure, I tried to use mkfs.fat -F32 but that also wouldn't work.

I gave up on encryption and used the graphical partitioning menu (which doesn't support encryption) and Void managed to install itself without a hitch.

Init with runit

Runit has turned out to be a really good fit for me. It's fundamentally really simple. It's spread across a number of programs, the manpages of which could be read in a single sitting. They're quality manuals, but in terms of examples, they leave a lot to be desired. Thankfully, despite runit being a rather niche init system, there were enough articles out there on the web for me to understand how to use it correctly.

User services are dead simple to set up. I've currently set it up such that sway, my window manager and compositor, invokes runsvdir to start all other services, including swaybg, pipewire, syncthing, etc.

I have created two scripts to manage the startup and shutdown of the compositor and different user services, the shutdown script is especially crucial because user services will hang out forever unless explicitly stopped.

Note that I'm using greetd as my login manager and seatd to manage input devices and such. I'm not using elogind... About that, let's talk systemd.

Looking back on systemd

I like systemd, it's a comprehensive solution to a seemingly simple problem. I have no issues with it, systemd is comfortable with having a large scope but I believe that the people who stand to benefit the most from systemd are desktop environments. systemd is the perfect choice for plug-and-play environments. It almost just works for almost everyone. Almost?

Desktop environments carry a lot of weight, despite the fact that some of them offer a plethora of customization features, an opinionated person such as myself would rather build something of their own. Linux has made me enjoy picking things apart which has meant that none of the desktop environments could satiate my thirst for complete control.

I was able to build my own "desktop environment" on top of systemd but it was really hard to pull off. I'd say it felt fragile but it worked and it worked really well. Eventually my own creation became cumbersome to maintain and that contributed to wanting to try out something different.

Bugs I encountered

First, I was unable to use Emacs in the first few days, I came up against a really odd bug that should have never happened. That issue luckily and inexplicably resolved itself.

Second, My screen occasionally flickers and it's really annoying. I disabled i915.enable_psr which should have eliminated the flickering according to the Arch Wiki but it doesn't seem to have made a difference.

Update (2024-11-25): I was able to fix the screen flickering by adding intel_iommu=igfx_off to GRUB_CMDLINE_LINUX_DEFAULT as suggested in the Void handbook.

That's it, Void Linux has been great otherwise.

Notes

I'm really enjoying fuzzypkg; it's a relatively simple package management fzf-based interface for xbps. I use it all the time. I went a step further and created a .desktop file for it.

I wanted to avoid elogind at all costs so to work around the lack of an XDG_RUNTIME_DIR, I resorted to pam_rundir which worked beautifully. I initially had issues logging back in after logging out where greetd would exclaim that XDG_RUNTIME_DIR was undefined. I messed around with the placement of the PAM module and found the best place for it (in the /etc/pam.d/system-login) was right after:

password   include    system-auth

Conclusion

I'm still exploring Void Linux. I've got a lot to learn. I'm really excited to be trying something new for a change. Despite leaving Arch Linux behind (for now), I still rely on the vast knowledge of the Arch Wiki accrued over two decades of lots of hard work by the community.