Correction

#!/bin/sh
[ -f "$HOME/.profile" ] && . "$HOME/.profile"
[ -f "$HOME/.config/shell/profile" ] && . "$HOME/.config/shell/profile"
[ -f "$HOME/.bashrc" ] && . "$HOME/.bashrc"

####### GUIX SYSTEM
# Merge search-paths from multiple profiles. Order matters.
if [ -e /run/current-system/configuration.scm ]; then
    eval "$(guix package --search-paths \
-p $HOME/.config/guix/current \
-p $HOME/.guix-home/profile \
-p $HOME/.guix-profile \
-p /run/current-system/profile)"

    # Prepend setuid programs.
    export PATH=/run/setuid-programs:$PATH
fi

####### GUIX PACKAGE MANAGER
GUIX_PROFILE="$HOME/.guix-profile"
if [ -f "$GUIX_PROFILE/etc/profile" ]; then
    . "$GUIX_PROFILE/etc/profile"
    unset GUIX_PROFILE
fi

GUIX_PROFILE="$HOME/.config/guix/current"
if [ -f "$GUIX_PROFILE/etc/profile" ]; then
    . "$GUIX_PROFILE/etc/profile"
    unset GUIX_PROFILE
fi

####### GUIX HOME
[ -f "$HOME/.guix-home/setup-environment" ] && . "$HOME/.guix-home/setup-environment"

####### NIX PACKAGE MANAGER
[ -d "$HOME/.nix-profile/bin" ] && export PATH="$HOME/.nix-profile/bin:$PATH"
[ -d "/nix/var/nix/profiles/default/bin" ] && export PATH="/nix/var/nix/profiles/default/bin:$PATH"

[ -e "$HOME/.nix-profile/etc/profile.d/nix.sh" ] &&
    . "$HOME/.nix-profile/etc/profile.d/nix.sh"

[ -e "/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh" ] &&
    . "/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh"

####### Nix desktop files
[ -d "$HOME/.nix-profile/share" ] && \
    export XDG_DATA_DIRS="$HOME/.nix-profile/share${XDG_DATA_DIRS:+:$XDG_DATA_DIRS}"

####### flatpak desktop files
[ -d "$HOME/.local/share/flatpak/exports/share" ] && \
    export XDG_DATA_DIRS="$HOME/.local/share:$HOME/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"

####### Reset ~/.local/bin on guix
export PATH="$HOME/.local/bin:$PATH"

#!/bin/sh
set -e

cd "$(dirname "$0")"

guix shell \
     gcc-toolchain pkg-config make \
     libx11 libxft libxinerama fontconfig freetype \
     -- make \
     CC=gcc \
     X11INC=$(guix build libx11)/include \
     X11LIB=$(guix build libx11)/lib \
     FREETYPEINC=$(guix build freetype)/include/freetype2

guix shell \
     gcc-toolchain pkg-config make libx11 libxft libxinerama fontconfig freetype \
     -- make \
     CC=gcc \
     X11INC=$(guix build libx11)/include \
     X11LIB=$(guix build libx11)/lib \
     FREETYPEINC=$(guix build freetype)/include/freetype2 \
     PREFIX=~/.local \
     install clean

Guix has been on my radar for a number of years now. I always viewed it as an elite distro for a number of key reasons:

1. It is a GNU project and an FSF-approved distro which means it meets the Free System Distribution guidelines, meaning the distro will work perfectly on a couple dual-core thinkpads and YMMV on all other hardware. Harder and more limiting systems are always better.
2. It is source-based.
3. It is (was) rarely used in the wild. “Neofetch flex potential” as it has been called. ¹

The main selling point of both Guix System and NixOS for the average user would be the source-controlled configuration file which results in an easily “reproducible” system. I put reproducible in quotes because I don’t care so much as whether the system is technically reproducible - meaning exact binary copy down to a hash - but more a system that has all the same packages and configuration.

But I’ve been able to make any distro “reproducible” by using shell scripts and more recently ansible. My ansible roles work extremely well for me on any arch or debian derivative distro, or at least any derivative distro I would consider running. Install a couple packages, run a quick playbook, add the device to my tailnet, and then run another playbook that completely recreates my workstation setup after 15 minutes or so. There are other simpler roles I use on servers to also include alpine.

I bring up ansible only to say that at this point I don’t have a “need” for Guix System or NixOS insofar as they are fantastic tools for reproducibility, roll-backs, snapshots, etc. I get get all those features from “legacy” distros with btrfs snapshots and ansible.

But that doesn’t mean I’m going to not try Guix and NixOS (well, maybe not NixOS). And more importantly it would be a mistake to believe Guix and Nix are primarily systems for easily recreating your rice. That is just a nice touch. The shells, containers, and deployment capabilities are the real selling points of Guix and Nix IMHO, which for me are not that important as I have zero issues using lxc and docker/podman for containers.

I say all of this as background to explain my perspective as a user who is perfectly happy using normie GNU/linux tools. Inertia is a thing, so even if the process of learning FHS linux, ansible, docker, etc took significantly longer than learning Guix/Nix equivalents would, I’m already at the end-point. Anything different is probably going to seem “harder” or “complicated,” and I don’t think any Guix or Nix enjoyer would describe those systems as simple or easy. So if I come across as a Guix denier at any point in this post or other related ones in the future, it’s coming from a perspective that the other solutions Just Werk™ for me at this time.

Definitions

Like Nix, Guix has its own terminology for various things. Here are a few important ones:

1. Channel:

Guix and its package collection can be extended through channels. A channel is a Git repository, public or not, containing .scm files that provide packages or services.

• I.e. software repository

2. Substitutes

Build farms that build packages from Guix continuously for some architectures, and make them available as substitutes (binaries).

• Similar to binary repositories on Gentoo.
• Compiling from source is still the fallback.

3. Nonguix

Nonguix is a software repository for the GNU Guix package manager, which packages some software which cannot be included in the official distribution for ethical or policy-related reasons.

4. Generation

• An instance of your Guix system at a given time.
• Generations are created every time you regeneration your system for the system configuration file.
• Each generation can be booted from grub, giving you the functionality of grub-btrfs on legacy distros regardless of file system.
• New generations are created each time you boot into an older generation.

Known Challenges

Like all FSF-approved distros the Achilles' heel of Guix is the inability to run proprietary software. It comes with the linux-libre kernel which removes the proprietary firmware blobs found in the mainline linux kernel. There’s a lot of misleading tribal knowledge about this on the internet, I figured my computers likely would not even boot as a result. Whilst this may be true for some machines, particularly new ones, this simply is not true for the overwhelming majority of computers. Your computer will boot fine and your graphics will function for at least rendering screens unless it is a new card. The one thing won’t have is wifi. Honestly, not the end of the world.

Don’t Talk about Nonguix

That being said I fully intended to get wifi working using the freedom-hating nonguix channel which provides both the mainline linux kernel and proprietary firmware which are likely needed for your wifi. Adding a channel in Guix is akin to adding a 3rd party repo in legacy distros.

Nonguix is like Fight Club: everybody knows about it and partakes, but nobody talks about it in official Guix fora. A bit silly, but I understand why and have become more and more FSF-aligned over time despite its flaws and characters.

Installation Prep

Before ever installing Guix System, I used the Guix package manager on a so-called foreign distro, in my case it was Devuan GNU/Linux. So I came in with some guix knowledge already. And consoomed System Crafter’s Guix vidyos which are good and still relevant.

I first installed Guix in VM, but after 20 minutes or so I decided to just live dangerously and install it on bare metal. I gained nothing of importance from installing in a VM other than knowing that Guix does not set up btrfs subvolumes by default. More on that later.

Bare Metal Weapon of Choice

In my stack of old corporate thinkpads I had an unallocated W541 and an X230 running Artix GNU/Linux. The W541 has a 4th-gen i7 processor (4-core, 8-thread) and a whopping 4 RAM slots which I filled with a number of DDR3 sticks I had laying around to get a total of 20GB. Plenty enough for compiling for this cpu.

Despite having an NVIDIA Quadro K1100M discrete graphics card, I chose the W541 over the X230 because of the beefier processor since Guix is a source-based distro by default. This computer also has an integrated graphics card, and from my research the discrete GPU is old enough that it works fine with nouveau drivers which are included in the linux-libre kernel. So for the sake of getting a bootable and functioning system that can also compile a kernel, the W541 works.

The wifi chip is also easily accessible and there likely is a linux-libre compatible chip which I can use in the future.

Installation Media & Nonguix

If you’re absolutely set on having wifi working during installation, you will need to use a nonguix ISO. The latest official nonguix ISO is from 2022, though from vidyos it seems like there were more recent images from 2024 which are no-longer on the gitlab. Whilst this is a very minimal base system and the installer itself probably has not changed, 0/10 WOULD NOT RECOMMEND using a 4-year-old ISO.

For starters it is using Guix 1.4, a version behind the current 1.5 which brought major changes to the package manager. It probably also still references the old, slow GNU Savannah channel which Guix used to be hosted on. Guix is now on codeberg which is a significantly faster channel. Aside from that you probably don’t need me to explain why using an iso that old is probably a bad idea.

System Crafters used to publish their own nonguix iso on their github. The community has since moved to codeberg and no longer publishes custom Guix ISOs. My guess is due to codeberg limitations.

You can also generate your own nonguix iso image on any system with the Guix package manager installed. Instructions are provided on the nonguix gitlab. Keep in mind this compiles an iso, so expect around an hour. I have not verified how well this works or if there are any gotchas with this method, though an unnamed friend may or may not have had issues with this until finally conquering.

I chose to use the official GNU Guix ISO over ethernet and add the nonguix channel later. If your system boots the linux-libre kernel - which you should know based on the ISO booting or not - it is a simple enough process to just add the nonguix channel after installation. You can even add the nonguix channel during installation via ssh, see Thanos Apollo’s Guix Installation video for how that can be done.

Official ISO Issues

There are two flavors of the official Guix iso: standard and latest. At the time of this post the standard ISO is from January, 2026, so I knew going it that I would basically be pulling the entire system with this ISO.

There is additionally a latest ISO which should be a weekly build.

Both are direct downloads, I could not find any torrent links.

There are issues with both of these though. The latest official ISO only includes a gpg signature file. No sha256 or sha512 hash. The latest ISO includes neither a gpg signature nor hash. This is unacceptable.

Since I still like to live a bit dangerously, I was fine with signature verification of the standard ISO, but I would not recommend using the latest ISO unless you like to curl | sh your entire operating system.

Guix Installation

There are several videos running through a Guix installation, tony_btw’s shows a cli install per the Guix Reference Manual. This is honestly one of the more straightforward cli installs out there.

I opted to go the graphical/tui route as I value ease and reproducibility of installation. I was more curious how sane the defaults were, and when I choose a distro for long-term use I will not choose one that requires a bunch of cli nursing and a handbook to install. It’s just not worth my time, I want something I can mindlessly install to get back up and running as quickly as possible.

Let me tell you that the Guix tui installer is fantastic, up there with the MX Linux gui installer as my favorites.

Encryption

Guix by default uses true Full-Disk encryption save the EFI system partition with GPT partition tables. From what I understand this is only possible (or more consistent) with the older LUKS1 encryption vs the newer LUKS2 which generally requires an un-encrypted /boot. LUKS2 with un-encrypted /boot is the default on Debian where an encrypted /boot installation will fail from within the tui installer. I generally prefer an encrypted boot if possible and convenient. Of course it’s always possible from the cli.

Btrfs Snapshots, /boot, & Encryption

This is not an issues on Guix, but on legacy distros using btrfs snapshots for roll-backs, an un-encrypted boot partition can bite you if your initramfs gets corrupted or significantly differs from the installed kernel. For instance if you’re on arch where there are only two officially supported kernels and want to restore an old btrfs snapshot, it probably will not boot as the kernels on the snapshot could be completely different kernels. You would need to chroot from an iso or boot into the snapshot from grub, regenerate initramfs, and modify the btrfs root subvolume name to point to the actual root subvolume and not the btrfs snapshot you’re booted in. It potentially becomes messy and could render your /boot unrecoverable without a usb chroot.

So on legacy systems with encryption and btrfs, encrypted /boot is always preferred as the /boot partition is included in the btrfs root snapshot.

File Systems

On the VM I installed btrfs which included zero btrfs subvolumes. My initial strategy was to use btrfs snapshots to have restorable backups even if I garbage-collect (prune) my Guix system. Not having subvolumes makes this impossible without the cli installer.

As I thought about it though, btrfs snapshots offer you absolutely nothing on a Guix system. Btrfs snapshots are incremental, so on a legacy distro each snapshot references the previous snapshot and adds/removes packages as appropriate. This works because the packages/files are installed in the same place just with different timestamps and/or versions.

On Guix and Nix, upgraded packages are stored in a completely different locations and are just symlinked to the appropriate place is the system or user path. As far as I know btrfs would have no way of identifying these as the same package since they are in completely different folders, which means you probably gain zero incremental benefits. So whether you are using btrfs snapshots or Guix generations, it probably makes no difference, the same amount of space exists on disk. This is probably why grub-btrfs is not included in otherwise massive nix package repo.

Further, to roll-back using btrfs you must restore and reboot the system, while Guix can roll back in real-time using guix system roll-back without reboot.

So as far as I can tell there is zero upside to using btrfs snapshots and only downside considering installation complexity. Additionally if you have both btrfs snapshots and generations, you are effectively saving the same packages multiple times, taking up more disk space which I imagine can be precious on Guix and Nix.

So why choose btrfs? Compression, copy-on-write, and data integrity features.

For this install I chose the default ext4 on a 500gb drive, and depending on how much space I have after transferring my /home folder over and keeping a couple months of generations, I may re-evaluated switching to btrfs for the compression benefits which are not insignificant.

Substitutes

You’ll want to enable substitutes during installation. It’s a long process regardless, but substitutes will insure installation takes under an hour. Speed is a weakness of Guix unfortunately, but keep in mind it was a source-based distro for a number of years. Substitutes are secondary. If a substitute server does not have the binary, it will be built from source. That being said I would say around 80% of the packages installed were from binary substitutes, and most of the compiled programs were small anyway. I haven’t looked in detail but I imagine Guix is selective as to which packages even make it to substitute.

Desktops

Guix includes a few desktop environments and window managers, I opted for XFCE as that is my go-to on all systems as a fallback.

Post-Install

Moving /etc/config.scm

I kept the default /etc/config.scm file generated by the installer. Whilst I could have modified it at this point, I really wanted to experience default Guix before I go-a-ricing. Additionally my plan was to copy the system config.scm for modifications, leaving the original one intact at /etc/config.scm.

Tony directly edits /etc/config.scm to install packages and services in his guide. This works, but you miss out out version controlling your config file. Instead I would recommend leaving the default config.scm as is and copying it to a folder of your choosing where you can add it to git. It can be anywhere. I chose ~/.config/guix/config.scm.

Adding nonguix

The instructions for adding the nonguix channel are straightforward.

Make sure you add the nonguix channel in a channels.scm file:

(cons* (channel
        (name 'nonguix)
        (url "https://gitlab.com/nonguix/nonguix")
        ;; Enable signature verification:
        (introduction
         (make-channel-introduction
          "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
          (openpgp-fingerprint
           "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"))))
       %default-channels)

~/.config/guix/channels.scm is a good place for this.

One thing you’ll want to do is add the nonguix substitute server. The instructions are clear enough, but the code block included will conflict somewhat with the default (services ...) block in /etc/config.scm

Here is the default (services ...) block in /etc/config.scm after an XFCE installation.

(services
 (append (list (service xfce-desktop-service-type)
               (service openssh-service-type)
               (set-xorg-configuration
                (xorg-configuration (keyboard-layout keyboard-layout))))
         ;; This is the default list of services we are appending to.
         %desktop-services))

And here is what nonguix provides:

(services (modify-services %desktop-services
           (guix-service-type config => (guix-configuration
             (inherit config)
             (substitute-urls
              (append (list "https://substitutes.nonguix.org")
                %default-substitute-urls))
             (authorized-keys
              (append (list (local-file "./signing-key.pub"))
                %default-authorized-guix-keys))))))

Crystal clear, right? Not going to get into the weeds of scheme here, but defining services beginning with append and then later modify-services is not the cleanest approach.

Instead I borrowed what is done on a default base Guix installation (no desktop) and use cons* to add elements to a list rather than use append which concatenates lists.

This:

(services
 (append (list (service xfce-desktop-service-type)
               (service openssh-service-type)
         %desktop-services))

Is functionally equivalent to

(services
 (cons* (service xfce-desktop-service-type)
        (service openssh-service-type)
        %desktop-services))

In both cases we are adding two services to desktop-services which exists by default on the system.

The difference is we can directly pass (modify-services ...) in the (cons* ...) block, wheres it would have to be a list in order to include it in the (append ...) block.

Here’s what I ended up with:

 (services (cons* (service xfce-desktop-service-type)
                  (service gnome-keyring-service-type)
                  (service nix-service-type)
                  tailscale-service

                  (modify-services
                   %desktop-services
                   (guix-service-type config =>
                                      (guix-configuration
                                       (inherit config)
                                       (substitute-urls
                                        (append
                                         (list "https://substitutes.nonguix.org")
                                         %default-substitute-urls))
                                       (authorized-keys
                                        (append
                                         (list
                                          (local-file
                                           "./signing-key.pub"))
                                         %default-authorized-guix-keys)))))))

Then just change the location of signing-key.pub to a file location of your choosing. I chose ~/.config/guix/nonguix.pub. You can find the contents for this key file here.

Per nonguix instructions:

Guix System will only use the substitution server after it has been reconfigured. The substitution server will therefore by default not be used the first time you run guix system reconfigure after adding the substitution server. It is therefore recommended to explicitly specify the use of the substitution server the first time you reconfigure your system:

sudo guix archive --authorize < signing-key.pub
sudo guix system reconfigure ~/.config/home/config.scm \
--substitute-urls='https://ci.guix.gnu.org \
https://bordeaux.guix.gnu.org https://substitutes.nonguix.org'

Just be sure to put the proper location of config.scm for your system.

Adding the non-libre Linux Kernel and Firmware

Add the following to config.scm:

(use-modules
    ...
    (nongnu packages linux)
    (nongnu system linux-initrd)
    ...
    )
...

(operating-system
  ...
 (kernel linux-lts)
 (initrd microcode-initrd)
 (firmware (list linux-firmware))
 ...
 )

Then run:

sudo guix system reconfigure ~/.config/guix/config.scm

And you will begin pulling the binary linux-lts kernel (assuming the latest build exists, if not it will be source) and linux firmware. After rebooting you should have working wifi.

Notice I have also added a nix service and tailscale service. The nix service is provided by Guix.

The tailscale service is a module I created with tailscale installed from nix. You can additionally find guix channels to install tailscale.

Profiles

System Profile

Now is a good time to mention profiles. By default you have a system profile and a user profile. When you add software to config.scm and run:

sudo guix system reconfigure ~/.config/guix/config.scm

(substituting your file location), you are revising your system profile. Any packages installed will be installed to the system profile. The default path for executable files installed to your system profile is:

/run/current-system/profile/bin

Running guix install <package> as root (or with sudo) installs that <package> to your system profile.

There are certain packages you might want in your system profile, for instance desktop environments and system services, but most software should not be installed in your system profile, whether that is installed via sudo guix install or defined in config.scm.

User Profile

Software installed via guix install <package> will be installed to your user profile located at:

~/.guix-profile/bin

In general, do not install software this way. Not that it is bad or wrong, it just doesn’t get you anything beneficial.

Instead, use Guix Home.

Home Profile / Guix Home

Guix Home is akin to NixOS home-manager except it is also a profile and parallels your system configuration. A default home configuration file is located at ~/guix-home-config.scm. Once again I recommend making a copy of this file and placing it in a convenient place, and keeping the original saved. I chose ~/.config/guix/home/home-config.scm. Add packages to this file in a similar manner to config.scm, and update your home profile by running:

guix home reconfigure ~/.config/guix/home/home-config.scm

What is the advantage of this? You have all the same generational features of your Guix system, just with your home profile. Removing a package is done by simple removing it from home-config.scm. Your configuration can also become modular which is what I intend to do. In this way your home-config.scm and related modules are your source of truth as to what is installed on your system, not whatever happens to be in ~/.guix-profile/bin which you installed by guix install <package>.

There’s a ton more to say about Guix Home but for now I’m pretty much just using it to install packages.

Installing software

There is very little included at first, frustratingly so at times. For instance the clear command is not included and needs to be installed using the ncurses package.

At a minimum you will need to add the appropriate package module and package name to the respective sections of your home config file. There are multiple ways of doing this depending on if you are using a modularized configuration or not. The default guix-home-config.scm file is modular which you may or may not want to immediately use. I would recommend starting from scratch at first, so keep a copy of the default file and then make your own in a more simple format.

Here’s an example for installing emacs, emacs-guix, and ncurses packages:

(use-modules
  (gnu home)
  (gnu home services)
  (gnu packages)
  (gnu packages emacs)
  (gnu packages emacs-xyz)
  (gnu packages ncurses))

(home-environment
  (packages
    (list
     emacs
     emacs-guix
     ncurses)))

emacs-guix is a fantastic way to manage your Guix system. It is extremely useful for searching for packages, much quicker than guix search <package>.

You’ll need the location item from guix search <package>, for example:

guix search emacs-guix

name: emacs-guix
version: 0.6.1
...
location: gnu/packages/emacs-xyz.scm:8355:2
...

This location is simply the folder structure of the Guix git repo, and emacs-xyz is the guile scheme module which includes emacs-guix. Add emacs-xyz to (use-modules ...) and you’ll now have that module loaded. Add emacs-guix to your package list and guix home will install emacs-guix from the emacs-xyz scheme module.

Pretty much everything in Guix follows this format. If we look the config.scm section above which installed the kernel and firmware from nonguix, notice how the modules were in the nongnu folder (channel), not the default gnu channel.

For more information on a modularized configuration, see the Guix Reference Manual and System Crafters video

To be Continued

At this point I have a Guix system running the mainline linux-lts kernel, functioning wifi, the XFCE desktop, with some packages installed in my home profile, and quite a bit more that I’ll save for another post. For me this is the minimum viable product, I would be perfectly happy living in XFCE. In my next post I’ll go through what I’ve done to modify my desktop setup, install suckless software, copy over (and subsequently modify) my dotfiles, and the successes and failures I’ve had in the process.

Things don’t always Just Werk™ on Guix, for instance after writing this post and installing hugo from nonguix, hugo is not rendering the page at all. So add that to the list of things to troubleshoot. But, once the troubleshooting is done, everything is documented in a file and I’m sure Guix will at least be just as usable as any other distro. I’m just doing my best to enjoy the journey of getting there.

Historically I’ve put Linux Mint on my wife’s computer, but when setting up a new (used) laptop several months ago I decided to go with CachyOS. The laptop had plenty of resources, and I wanted something that would be a quick and reproducible setup that had btrfs & snapshots configured out of the box. Not to mention the eye-candy is nice, maybe that’s just default KDE these days.

My only issue is this: my wife knows goose egg about arch linux. I do not enable automatic upgrades on arch linux for obvious reasons, but I found myself forgetting to run updates on her computer every couple of weeks. In one case there was the classic archlinux keyring issue that comes once or twice a year, not a big deal. But if I was not around that is something she unfortunately would not be able to rectify.

So I decided to look at moving her computer back to something Debian-based so I could unattended-upgrades and chill without thinking much of it. If I were to suddenly die, it would be an easier machine to manage and find solutions for, at least until Debian drops the current version from lts support.

Whilst I could have just installed Linux Mint or LMDE, that’s now how we do things at linuxmaxxing dot com. So I decided I would distro-hop on an unused laptop for the first time in over 5 years to properly retest Debian. Not sure if it counts as a proper hop since I’m very familiar with Debian and still run it on a ton of servers and containers.

My Last Experience with Debian on the Desktop

The last Debian version I used on the desktop was Buster (Debian 10). I was never much of a desktop environment user outside of LXDE and XFCE, and I remember at that time KDE and Gnome were having rapid development so the versions on Buster were not only out of date but missing features, and buggy on the KDE side IIRC. Not surprising, but it didn’t phase me. The only real complaint I had was not having a number of the Luke Smith starter pack in the Debian repos.

Installing Devuan in 2026

Because I fell for the “muh init freedom” meme a long time ago, I prefer to not run systemd. Tons to say about that of course, but to keep it simple my overall perspective (which also applies beyond just GNU/Linux) is to hedge all sides and not put all your eggs in one basket. Even if I were a systemdmaxxer I would want projects like Artix, Devuan, Gentoo, Alpine, etc to continue to succeed even as a proof of concept that GNU/Linux can still function without systemd. This approach bypasses all the “bloat” or “unix philosophy” arguments for something much more pragmatic and practical IMHO. More on that in another post.

I’ve loved using openrc, I used runit for a while, and hadn’t really messed much with sysvinit since back in the day I really didn’t tinker much. So Devuan with sysvinit made sense as a learning experience. I’ll cover Devuan in more detail in another post.

From here on out I may refer to installing Debian, just know it was actually Devuan. It practically makes no difference, Devuan is extremely similar to Debian, much closer than Artix is to Arch. In fact all of the sysvinit scripts used by Devuan are included in Debian. Don’t believe me? Check out /etc/init.d/ on your Debian server.

I like Debian’s netinstaller. It’s a good balance between minimal 1337 installers and something that’s relatively easy if you know your way around. I installed with encrypted btrfs subvolumes which requires a bit of tribal knowledge which will yet again be covered in another post.

What does “Stable” actually mean?

Stable means exactly one thing: no updates. The opposite of updatemaxxing. That’s it.

All you’re getting are Security updates which are patched by the Debian security team. After the roughly 6-month testing freeze prior to a stable release, bugs are fixed/patched by the Debian team to ensure the pinned package versions are as bug-free as possible. It is not 100%, there will be bugs that are discovered that do not get resolved until the next stable release. But I’ve found this to be few and far between, it is just features you will be missing out on.

This gets at a major ideological point of departure from Arch linux: Debian packages are often heavily modified compared to upstream. I’ll save Debian vs Arch for another post.

What are some advantages of “stable” packages?

1. No updates.
2. Minimized possibility of updates breaking stuff (not 100% eliminated, there was a Debian 12 point release which had issues).
3. Small file downloads. If you update Arch every week or two, you will be pulling in at least 1 GB of updates, 2+ for most users. This adds up if you are bandwidth or space limited.

Are there packages we don’t care about upgrading?

Absolutely. I could not care less about running the latest kernel, in fact I am still running the latest version 5 LTS kernel offered in artix linux. I am not a programmer or developer, so I don’t care about any of the language libraries. Even so, for what programming I have to do, it is all stuff that really hasn’t changed much: C, shell, elisp/scheme. Python is probably the most dynamic.

There is so much on my system that I don’t care about upgrading, by far outweighing what I do care about.

BUT EVERYTHING IS OUT OF DATE!

So trve, king. But here’s a question: 2 years ago, was your GNU/Linux system completely unusable, or was it just as usable as it is today?

If you’re a KDE or Gnome user, this argument held water a several years ago. But ever since around 2023 / Debian 12 Bookworm I can’t recall any massive changes to either of those projects. Maybe wayland support. Likewise there have not been major changes to the linux kernel since version 6 which was included in Debian 12. Drew from Just a Guy Linux maintains that Debian 12 was a major release from Debian standpoint because of how many features it added from large projects, but ever since that not much has changed. I tend to agree.

Unless you’ve got a new computer, your desktop experience probably hasn’t changed much since Debian 12. And with the rise of vibed projects there have even been deliberate regressions in forks. Calibre and vim comes to mind.

In some cases out of date packages are an advantage. Take Nvidia for example, the lastest driver you can get in any Debian variant is 550; stable and sid (unstable) are both at 550. Peculiar choice, I would prefer 560-580. But it ensures that all nvidia cards (save brand new ones) are fully supported, unlike Arch which went right along with Nvidia’s decision to drop legacy cards from their drivers after 580.

HOW CAN I GET THE NEWER SOFTWARES THOUGH?

Astute question dear reader. Answer:

1. Backports
2. Extrepo
3. Nix/Guix
4. Legacy universal packaging formats

Backports

This is the most well-known method of getting version updates to software in the Debian repos. The key concept here is things that are already in Debian repos for your release. If it’s in testing but not in stable, you probably aren’t going to find it in backports.

Extrepo: the Mostly-Official Unofficial Third Party Repo

The extrepo package is new (for me) to the Debian repos and includes a fairly large collection of third-party repositories. Don’t Break Debian is a longstanding Debian mantra meaning don’t add ppas or other third-party repositories that could conflict or break existing software. Extrepo is like a middle ground between ppas and official repos. They are vetted repos which are built to work on Debian, but are not official. When you add a repository with extrepo, it creates an additional sources file in /etc/apt/sources.list.d/ which apt uses to pull software and updates.

I am surprised extrepo is not that well-known. I am using extrepo to get librewolf, Signal (soygnal), and tailscale, but there are a ton of other free and proprietary packages available from upstream providers on extrepo.

Nix/Guix Package Managers

My brother in Christ tony_btw recently put out a tier list which had Debian solidly in the meh category. His reasons were reasonable: not user-forward, seriously out of date development packages. I definitely agree Debian is not user friendly as a desktop distro unless you know what you’re doing, but if not now that was certainly true with arch and gentoo from years ago. Nothing you can’t overcome. It provides a moderately satisfying flex on newbs FWIW.

If you’re a developer, I think nix and/or guix package managers are a must have regardless of distro. The env shells and local build environments simply are game changers that you don’t even get with up-to-date distros like arch or gentoo. I don’t even care much about reproducibility since I’m very comfortable with ansible, the env shells are the killer feature for me beyond just larger package repos.

I use nix for a handful of packages I can’t find in the Debian repos. I never liked flatpak, AppImage is ok but is not guaranteed to be auto-updating and requires creating/adding your own desktop files, man pages, etc. Nix and Guix just werk (once you know what you’re doing) if you can spare the couple GB of extra storage.

So at this point I don’t even really care how big, small, new, or old Debian’s repos are - which now include many packages I wanted but were not available in Buster. So if I were a dev, I would rather rate a distro on how easy it is to install nix packages. Nix-bin is in the Debian repos and works great. On Devuan I simply had to write a sysvinit script for the daemon which was not difficult. But even then the daemon is not necessary, you can manually run it whenever you need to make changes to nix. Guix includes a sysvinit daemon, but the package selection is much smaller, so rather than running both, I keep everything additional I need on nix.

Debian is good for Emacs

Not strictly necessary, but there are many GNU elpa packages in the official Debian repos. Why is this nice? These packages will be pinned with the version of emacs in Debian repos. You won’t run into the problem of Debian’s emacs package being a version behind the newest stable emacs - which will shortly happen when emacs 31 is released. Once that happens the gnu elpa packages may be modified for version 31 which could introduce breaking changes if still on emacs 30 unless you’ve addressed that possibility in your config (e.g. pinning packages with use-package). Whilst I look forward to emacs 31, I don’t really care much about it, version 30 has been great and I haven’t seen any must-have features in version 31.

vterm is available so zero compilation is required. The latest version of jabber.el with OMEMO support is in Debian backports, again zero compilation required. There are also a number of emacs packages built around Debian and apt. debian-el provides modes and interfaces to apt for use in emacs, also available in Debian repos. Next to GNU Guix SD and maybe NixOS, Debian is probably the best distro for emaxxers.

Other features

I’ve always liked the apt-cacher-ng package. Since most of my servers and containers at home are running Debian, I run apt-cacher-ng on an lxc to keep a cache of all packages installed and point all my machines to that cache. That way updates are pulled from the upstream repo on the first run from whichever machine updates first, and then all other machines pull the same update from the apt-cacher-ng lxc over the LAN. Nice to have when you’re bandwidth limited and want to minimize hits to the repo servers, but also nice because you can clear the apt cache on your machine and know you still have the ability to revert packages from apt-cacher-ng. This also gives you the ability to update machines which are blocked from the internet.

I also like the aptitude package for researching packages from the terminal. It is an apt wrapper but also has a tui menu which contains all the metadata for each packages. Think of it as synaptic package manager for the terminal. This was a feature I missed when I first moved off Debian for arch-based distros. A nice to have, not a necessity.

Because of how Debian packages, you end up with a greater number of packages but the overall install size is smaller than Arch. This is because Debian breaks up source and development packages from binaries.

Conclusion

I have my ansible playbooks dialed so that it mirrors my setup from Artix onto Debian/Devuan. From an operator standpoint there is no difference. I can get updated software that I care about from various sources, particularly Nix for those things not in Debian backports or extrepo. The question I have to ask myself is this: what do I actually get from running Artix/Arch? Do I have a compelling reason to run Artix/Arch over Debian/devuan? Not really, it would boil down to init preferences, e.g. Artix fully supports openrc (PID1, openrc-specific scripts) whereas openrc on Devuan is just a substitute for sysvinit’s service manager, PID1 is still sysvinit and the vast majority of init scripts are sysvinit from Debian upstream. And Artix has dinit which is a really nice “minimal systemd” init system.

If I were choosing between Artix/Arch and Debian unstable, I would choose Artix. Debian stable/oldstable is the reason to run Debian IMHO.

Will I be ditching Artix entirely? Absolutely not, the installation I’ve used will stay on the same laptop and I will continue to be as active as I can in forums and contributing to AURIS. But I will be giving Devuan a solid run to learn the ins and outs of sysvinit and see if it could work for me in all edge cases.

Of course this will all change when I get around to installing GNU Guix System Distribution.

Now all I have left is to install a Debian-based distro on my wife’s computer which is why I went down this rabbit hole to begin with. I’ll get around to that eventually too.