In reality git has only served a limited purpose for me:

1. Project management - keeping related files and stuff together.
2. Backup - this honestly has been the primary purpose.
3. Replication on new machines.
4. Occasional sharing of code
5. Occasional version control / review.

I have overwhelmingly only used the master branch for my work. Most of my commit messages are basically useless, e.g. "update". I am sure none of you have ever done this, or rather still do.

As I began toying more and more with my "homelab", I began to at least use branches, do more frequent commits, and give useful commit messages. Magit really made this simple as committing hunks (sometimes called partial commits) is very easy. I think I'm almost at 1000 commits on my emacs config, tons of tiny commits and zero squashing, made quick and easy via magit.

Inevitably I ran into situations where I pushed updates from one computer, forgot to pull from a second computer prior to doing work, and then ended up with conflict messages when I pushed from the second computer. Skill/habit issue. Typically I would blindly copypasta whatever git recommended (e.g. rebase true), which most of the time worked, and if not I knew enough about git to get around to where I needed to be, typically via stashing changes. This is definitely something I am sure the reader never has done or is currently at this time doing.

I decided that I wanted to learn git from the ground up as a lot of the material out there doesn't start with esoteric fundamentals of what git actually is. From a learning standpoint I learn by doing and watching, and then once I have a grasp on the material I like to read reference manuals. Starting off with man pages generally isn't the best way that I learn.

Like any professional I watched a few yt vidjas which basically said all the basics I had already known. Then I stumbled upon The Primeagen's exactly 4-hour and 20-minute git course and figured this would have more nuggets (and humour) than all others. That has proven to be true.

I don't really consume The Primeagen content, not really my style or vibe. But The Primeagen has this one simple trick that makes him extremely effective (good use of research dollars btw).

His course is hosted at boot.dev and is free. I am not a fan of the website, but it is an interactive course which is the best way that I learn.

The content itself is absolutely outstanding. 10/10 would recommend. Linuxmaxxing dot com is not getting any kickback for the advert.

Perhaps it would have been overwhelming to learn at first, but nevertheless I wish I had at least learned the fundamentals of how git actually works under the hood very early on.

Git Repository

  git init                        # create git repo in current directory
  git status                      # see file states
  git add .                       # does not recursively add

  git log
  git --no-pager log
  git --no-pager log -n 10    # prints last 10 commits NOT in the pager (less)

  # other options
  --oneline # puts everything on one line
  --parents # shows parent commmits
  --graph   # shows commit/branch lines
  --all    # shows all branches
  --decorate # branch + tag info, can be short, full,no

  git log --decorate=full

  # use the first 7 characters of the commit hash (4 might be sufficient)
  git cat-file -p <commit hash>   # this will show the tree hash

  git cat-file -p <tree hash>     # this will show the blob hash

  git cat-file -p <blob>          # this will show the file hash

  git cat-file -p <file hash>     # shows contents of the file

  git config set --global user.name "Bill S. Preston, Esq."

  # useless data for git, but allowed
  git config set --local organization.ceo "Ted"

  # --add functionally does the same thing
  git config --add --global user.email "bill@email.com"

  git config list --local
  git config list --global
  cat .git/config                 # local data
  cat ~/.gitconfig                # global data

  git config get <key>              # <key> made up of section.value
  git config get user.name          # section = user, value = name
  git config get --global user.name # --global goes after get/set

  git config unset <key>           # <key> needs a section and value
  git config unset --all <section> # unset all of the same section
  git config unset user.name
  git config unset user            # THIS FAILS - needs a key and value

  # you can have multiples of a key
  # the last one is what is tracked in git
  git config set --append organization.ceo "Warren"
  git config set --append organization.ceo "Carson"
  git config set --append organization.ceo "Sarah"

  # unset all of the same key
  # otherwise git will not allow unsetting that key
  git config unset --all <key>

  git config remove-section <section>
  git config remove-section user

  git branch                      # shows you which branch you are on
  git branch -m oldname newname   # rename
  git config set --global init.defaultBranch main

  git branch <branchname>
  git switch -c <branchname>

  #   Create a new branch off of a specific commit hash
  git switch -c <branchname> <commit hash>

  git checkout <branchname>          # only works if <branchname> exits

  git branch -d <branchname>        # delete branch
  git branch -D <branchname>        # force delete a branch (unmerged commits)

  git merge <feature_branch_name>            # usually done from main branch

  git rebase main                # from the feature branch

  git reset --soft <commit hash>
  git reset --soft HEAD~1         # go back one commit from HEAD

  git reset --hard <commit hash>

  # this is a destructive item because it changes the commit hash
  # only do for latest commit which is not merged to main
  git commit --amend

  git remote add <remote> <uri>   # notice this is uri, can be a file address
  git remote add origin ssh://git@forge.site/user/repo.git

  git ls-remote

  git push origin main            # push the local main branch to origin

  # push a local branch to a remote branch of a differnet name
  git push origin <localbranch>:<remotebranch>

  git push origin :<remotebranch> # deletes a remote branch

  git log origin/master --oneline

  git merge <remote>/<branchname>
  git merge origin/main           # merge from the main branch on origin

  # ensures we merge on a pull, may or may not want this
  git config set pull.rebase false

  git pull origin main            # pulls the main branch from origin

  # Instead of everything above, we could have just done:
  git merge HEAD@{1}

  git reset --hard <commit hash>

  git checkout --theirs <path/to/file>
  git checkout --ours <path/to/file>

  git rebase <feature_branch>     # NEVER DO THIS

  git rebase main                 # rebase onto main
  git rebase master               # rebase onto master

  git checkout --ours <filepath>

  git checkout --theirs <filepath>

  git rebase --continue

  git log --oneline --all

  git config set --local rerere.enabled true
  git config set --local rerere.enabled false # disable rerere
  rm -rf .git/rr-cache            # delete any remaining rerere cache

  wagslane@MacBook-Pro-2 megacorp % git rebase main
  Auto-merging customers/favs.md
  CONFLICT (add/add): Merge conflict in customers/favs.md
  error: could not apply ad9b194... K
  hint: Resolve all conflicts manually, mark them as resolved with
  hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
  hint: You can instead skip this commit: run "git rebase --skip".
  hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
  Recorded preimage for 'customers/favs.md' # <--- THIS LINE HERE
  Could not apply ad9b194... K

  Recorded preimage for 'customers/favs.md' # <--- THIS LINE HERE

  wagslane@MacBook-Pro-2 megacorp % git rebase main
  Auto-merging customers/favs.md
  CONFLICT (add/add): Merge conflict in customers/favs.md
  error: could not apply ad9b194... K
  hint: Resolve all conflicts manually, mark them as resolved with
  hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
  hint: You can instead skip this commit: run "git rebase --skip".
  hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
  Resolved 'customers/favs.md' using previous resolution. # <--- THIS LINE HERE
  Could not apply ad9b194... K

  Resolved 'customers/favs.md' using previous resolution. # <--- THIS LINE HERE

  git rebase --continue

  git rebase -i HEAD~n            # n is number of commits we want to squash
  # HEAD is current commit, ~n is n previous commits
  # -i creates an interactive rebase

  git push origin main --force

  git stash
  git stash -m "jdsl v0 almost working" # adds a message
  git stash list

  git stash pop                   # applies the first stash on the stack

  # applies the first stash on the stack but keeps it in the stash list
  git stash apply
  git stash apply stash@{2}       # Apply the third (0, 1, 2) most recent stash

  git stash drop                  # removes a stash without applying
  git stash drop stash@{2}        # Remove the third most recent stash

  git revert <commit-hash>

  # show the changes between the working tree and the last commit
  git diff

  # show the differences between the previous commit and the current state, including the last commit and uncommitted changes
  git diff HEAD~1

  # show the change between two commits
  git diff COMMIT_HASH_1 COMMIT_HASH_2

  git cherry-pick <commit-hash>

  git cherry-pick <commit-hash>

  # you want to revert the commit that introduced the bug - first "bad commit"
  # you do not want to revert the last good commit
  git revert <bad_commit_hash>

  #!/bin/sh
  # bisect-script.sh
  if grep -q "SCANNING" "scripts/scan.sh"; then
      exit 1
  else
      exit 0
  fi

  git besect run ./bisect-script.sh

  git worktree list

  git worktree add <path> <branch> # create a new linked worktree

  git worktree remove <worktree name>

  git tag                         # lists all tags
  git tag -a "tag name" -m "tag message" # create a tag on the current commit

  git tag -a v3.10.2 -m "Fixed a lil bug"

As most of you know Tailscale is a wireguard-based private mesh vpn network which can be used to link devices. For home use this is a fantastic way to access your services from anywhere without port-forwarding or even messing with firewall rules (for the most part), or to share services or devices with others without posting them on the public internet.

This is significantly more secure than port-forwarding and exposing your services (and ip) to the public web, and is more secure than using a better but still flawed tunneling service like that offered by Clownflare. Tailscale gives you a way to share specific devices or services to other users, be they on your same Tailscale network (tailnet), separate accounts, and even offers a tunnelling service to expose your service - but not your ip - publicly.

Tailscale really is a fantastic product which significantly improves the tech tinkering hobby we're all into. It is geared towards the enterprise but is free for personal use. Previously personal use was limited to a few users and up to 100 devices - which let's be honest is more than enough for any serious personal or small-business use-case. Those limits were recently increased to up to 6 users and UNLIMITED devices. Impressive. Talk about something I would never need to pay for.

But the question often comes up: how on earth is Tailscale able to offer this amount of product for free?

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.

I have been a GNU/Linux power user for about 6 years now. Most of work is done in the terminal and I have used all the LARPy suckless or suckless-adjacent software. It’s both a preference and a hobby.

Likewise I fell for the meme takes of this or that software being bloat, most notably emacs and systemd. I’ll save the latter for another poast, stay tuned avid reader.

Whilst I won’t directly address whether emacs is bloat or not, I will address the fact that most terminal/suckless cosplayers - like myself - are actually be better suited using emacs over the Luke Smith starter pack.

In general, I think most terminal or power users care less about whether the program is strictly suckless - meaning lacking features but having some way to be extended via patching or separate programs - and more about the functionality and quality of the software. Whether something is suckless or bloat is ultimately a goal-posted opinion where there goal-posts are free to move. Vim is bloat, use vi. Vi is bloat, use ex. Ex is bloat, use ed. Ed is bloat, use cat, sed, and awk. Sed and awk are bloat, just don’t make mistakes.

There’s no real standard, except that in the end software quality will play the biggest role in our decision to use one thing or the other. Vim is full of features that are inspired from heckin-bloated emacs, but because it is so nice to use and the features can stay out of the way, nobody cares. I’ll save the bloat rant for another post.

Key Features of Emacs

1. Unified “Terminal” System
2. Daemon/Client - tmux not required. Quitting the editor does not kill the buffer, unlike vim.
3. Documentation (info pages) and help system.

I’ll cover points 1 and 2 in this post, and save the documentation for another post.

Inconsistent System Experience

One of the problems I have after falling for the minimal software meme is remembering and deconflicting all the terminal bindings. Bash and other shells use the readline library with emacs bindings by default (I prefer this over vi even before using emacs), tmux has its own bindings mostly using ctrl-b (this conflicts with readline/emacs), weechat has its own bindings using alt/ctrl, vim has its bindings for splits, profanity, newsboat, lynx, etc etc. Plus your window manager keybindings. You really have to think about all of those and be strategic about how you lay out the bindings for your entire system.

Regardless of which window manager or DE (LXDE if anything) I am running, I use sxhkd to launch all programs. The sxhkdrc file is my master-list of all keybindings on my system. Everything is arranged by prefix keys, and I keep everything used by various programs commented out so I don’t override them with sxhkd bindings. For most programs, I think there’s a lot of wisdom in sticking with default keybindings because chances are they won’t conflict as much with other terminal/program bindings.

Consistent and Unified System UI and Experience

Emacs simplifies a ton of this. Everything in Emacs is an Emacs buffer, so Emacs keybindings - whether those keybindings are emacs, vi/evil, meow, or some other editing system - work on every program. There’s no mucking around trying to get scroll support in a terminal or program, or a way to copy text into your clipboard, or having different keybindings for vim splits and tmux splits. It’s all the same.

Likewise because everything is run in an Emacs buffer, all editor commands perform the same operation whether it’s a text file, web browser, irc client, or email message. You can create functions to manipulate text in one type of file/buffer that will work on other buffers. Tsoding had a recent video on the usefulness of emacs, and one of the key points was that emacs unifies programs that were never designed to work together. So trve, king.

Here’s an extremely useful but simple example: scanning for urls. Luke Smith’s st has series of combined patches that allow you scan the terminal window for urls, pipe them to dmenu, and then launch the selected url in the default system browser. Super handy. It doesn’t necessarily work with all terminal programs, though.

But in emacs, this is a very easy function to write that can be easily extended. It’s all done in about 20 lines. I’ve bound this function to C-c g g (for go). A minibuffer pops up with a list of all url’s in the buffer, similar to st/dmenu. I select the url I’m looking for with C-n/C-p, hit enter, and the link opens in my default browser. If I press C-c g e, it opens in eww (emacs built-in browser). If I press C-c g c, the same base function is used to show all urls in a minibuffer, hitting return just copies the url to clipboard instead of opening in a browser. No scrolling through the articles or text (which is also easier than most apps because of unified emacs keybindings). No highlighting and pressing a copy keybinding. I can use that url copy function in any buffer - irc, webpage, text file. It’s all the same in Emacs.

These functions scan for urls in the entire buffer. But what if I just want to select the urls that are shown on screen? Easy modification. No patching sauce code or anything like that.

Programs I’ve replaced with Emacs

Most of these are very easy to set up. Elfeed is definitely the exception if you’re coming from newsboat, and I haven’t taken the time to completely replicate my newsboat setup which used mpv for podcasts and youtube vidyo, plus has a number of browser keybindings so I can open articles in text browsers (assuming a full-feed isn’t provided) and graphical browsers. So for now I am still mostly using newsboat.

Which of these are “killer apps”? For my uses, I’m not sure I would call any of them killer apps on their own, though I don’t even view org-mode as a killer emacs app. I can survive just fine without them.

They become killer apps by virtue of being a part of emacs.

I’ve never been a huge terminal file-manager user, cli has always just worked. Dired on its own is a good file manager, no better or worse than vifm, ranger, yazi, lf - they’re all kind of the same in my book. Where it is extremely powerful is that it integrates with everything else in emacs, including TRAMP which is EXTREMELY useful when editing on remote machines. Not going to cover it here in detail, but TRAMP allows you to edit remote files in your current emacs environment. Before using emacs I had in my head that in order to use emacs on a server, you needed to install emacs on the server (which could add a bit of gbs). Not the case.

My favourite dired feature is the ability to open two dired buffers in a split window, and any command done in one buffer is assumed to end in the other buffer. I.e. if I copy a file/files or make symbolic link/links in one dired buffer, emacs assumes the target is the other dired buffer. Very handy. You can also change the target directory if that isn’t the case.

erc is the best irc client I’ve used.

ement is a very good matrix client, not that the competition is great.

jabber.el has seen recent improvements, it works fine.

magit is the closest to a killer app on its own, not for me, but for anyone who heavily uses git. Your git workflow becomes extremely fast with magit and the ability to quickly do partial commits is a huge qol feature.

Key Difference: GUI vs terminal features

For most of these programs, a big difference is that when run as a graphical emacs session (normally the case), they are gui programs. They do not have the limitations of terminal text. Fonts can vary in size and are not limited to monospace. Images render just fine.

So whilst mu4e and eww are good programs, they are much better than terminal variants because they render text and images as designed. So with emacs you get the best of both worlds: minimal and hackable terminal interface with gui quality of life features.

Edit: Note on Documentation

Whilst I will cover emacs documentation in another post, it’s a key feature to mention here because all the features and keybindings for a given program are easily accessible with emacs built-in documentation, usually with simple popup-menus. Can’t remember how to do a certain operation in dired? C-h m shows you all of the dired keybindings and mode information. Curious what a keybinding does? C-h k will show you what the next keybinding you press does. Want to see all your bindings tied to C-c? which-key makes that a breeze in the minibuffer. Recently added help-quick-toggle with C-h C-q is probably the easiest of the bunch I’ve listed.

No man pages, no creating keybinding tables to track everything.

Conclusion

The suckless/terminal mindset is aimed at simplicity. Use simple programs that generally do one thing well, and stay in the terminal to avoid bloat, distraction, slow, feature creep, etc. Making all this happen can be a complex process though.

In my opinion, you’re better of accepting the “bloat” and “complexity” of emacs - I put complexity in quotes because emacs itself is actually a simple program - in order for simplicity of configuration, less mental taxation, and easier/better extensibility. Admittedly this will come at the expense of an extra gb or two of storage if you can spare it.

We all have fallen for the suckless LARP, why not fall for the emacs meme as well?

Nevertheless I wanted my custom bindings to be “mode” agnostic, so that ruled out using general.el and also using SPC as a leader key (since the non-modal default bindings need to insert a space with SPC). I tried Alt-SPC for a while instead, but that was surprisingly awkward even though it can be done with either hand, one hand, or even just the thumb if angled correctly. I decided to just embrace conventional emacs wisdom and rewrite my custom keybindings with C-c.

On my first read-through of Mastering Emacs, I thought some of the emacs navigation bindings were just ridiculous; the shear volume of bindings with no seeming rhyme or reason seemed absurd. After forcing myself to learn them, I realize the navigation bindings are actually surprisingly consistent - it’s the same pattern across windows, frames, and tabs. And C-c for custom bindings has been just fine. It was with this in mind that I thought: maybe I’m just misunderstanding the emacs editor keybindings as well?

My first step was to create my emacs keybindings that I could access in insert-mode (called insert state in evil). Not really necessary as you can locally toggle evil-mode with C-z, but this at least got me to start using things like M-d or C-k when I was too lazy to hit the ESC key to get back into normal mode. This was fine, but it wasn’t enough to seriously learn and use them.

So after a couple minutes of consideration and somewhat on a whim, I decided to rip off the bandaid and switch away from using evil-mode in gnu emacs. Here are some of my reasons for doing so:

Abbreviated and impromptu list of reasons to not use evil mode:

1. Curiosity.
2. Improve my bash default keybinding proficiency.
3. Not be completely retarded when my init.el fails to fully load or cannot load at all.
4. Cut down on emacs packages and abstractions.
5. Most importantly: experience emacs packages as the developers intended.

I really want to focus mostly on the last one because that is my primary motivation. It was during my research of elfeed that I realized evil-mode and specifically evil-collection do quite a bit of violence to the original keybindings from the author. By now I knew that evil-collection made changes on most packages - e.g. dired - but for the most part they’re pretty sane and retain most of the original bindings. This was not the case with elfeed, and reading documentation proved to be somewhat a moot point as basically everything had been changed to line up with a vim-style workflow. It made me wonder - what other aspects of emacs are being substantially changed because of evil and evil-collection? Am I losing out on some gucci emacs feature because of evil-mode?

Concerns

I have three major concerns with switching away from vim/evil keybindings:

1. Inability to rewire my brain away from vim habits.
2. Missing out on features I’ve come to love (e.g. visual-mode commands and vim’s search/replace mechanism).
3. Finger strain - the famed emacs-pinky.

For the first one I figure there’s only one way around - practice. I took a look at god-mode and meow-mode to see if there was a way to “have my cake and eat it too” so to speak, but I realized these would be similar to vim and at the same time different enough that I am unlearning and replacing vimisms with vim-like alternatives rather than learning a whole new set of bindings. Meow would still require me to have some proficiency with emacs bindings for the non-text buffers. As I went through the emacs tutor again, I came to the conclusion that emacs and vim bindings are probably different enough that I should be able to compartmentalize them fairly well. The same cannot be said of vim and meow as I would chose one to the detriment of the other.

For the second one, this is more of a concern with having to learn new ways of doing the same things. Considering emacs is a lisp-interpreter ultimately and isn’t bound by the same restrictions as vim or any other program, I’m confident solutions for my favorite vim features exists in emacs - it just won’t start with a colon or some other vim key.

Regarding the last one, I figure this is something I’ll be able to learn soon enough to prevent any issues should they arise. However, I heard from one of Prot’s vids that the best hack for emacs bindings is learning proper typing habits using both the left and right hand. This is something I had been working on anyway; C-c as your leader key gives you a ton of practice breaking away from just using the left hand, for example. With caps lock remapped to control, I’ve had very little issue using both hands for CTRL and ALT key operations, even when those keybindings involve switching hands in the middle of a key combination. As an added bonus I am no longer engaging caps-lock and doing all kinds of unintended stuff.

So if anything I look at this as a really good opportunity to perfect my typing The next step will be split-keyboards, but that’s a level of autism I shouldn’t approach lest I go down another potentially expensive rabbit hole.

One Week Review

So far I have no real complaints not using vim/evil mode. It hasn’t taken long to get familiarized with the default keybindings for various programs; really that aspect of emacs is no different, just using b/n/p/f instead of h/j/k/l. One of my main fears was that I would always need two-hands to do any kind of scrolling or navigating, but this really isn’t the case. In almost all buffers, “n” and “p” will move up/down without the control key, so one-handed browsing has not really been an issue.

I’ve stopped mashing ESC all the time like I am accustomed to.

Learning the emacs bindings is surprisingly easy because they’re largely pneumonic-based. Even in programs like dired: up-directory is ^, a symbol that looks like an up arrow, for example. Not always the easiest to reach, but easy to remember.

Editable buffers took about a day to knock off some rust iron oxide, but it’s been fine. Slower for sure, but not drastically. I suppose akin to the non-soystemd inits booting quicker - it is true dinit and runit boot quicker, but not to the extent that it drastically changes your computing experience. A lifetime of booting with dinit over soystemd will save tens of minutes. Likewise I think the extra time it takes with emacs bindings is a drop in the bucket, at least for my uses. Completely different story for programmers.

I can already tell emacs bindings have some advantages over vim - probably fewer compared with vim’s advantages but for the right person the advantages of emacs bindings could be substantial. For writing prose I can see how emacs bindings are really nice - there are a ton of sentence/paragraph oriented operations that don’t have parallels in vim (and don’t need to tbh considering the target audience of sysadmins and programmers). Plus transposition of characters and words.

I think the biggest strength of emacs bindings (so far) is the kill ring. Yes, there’s a way you can access it in evil, but you have to customize that yourself. And this is a feature that carries over to bash which does not have an equivalent in readline vi-mode (to my knowledge).

Long-Term Prediction

I’m going to give it some time, probably close to a year to get an honest review, but if I had to guess I am most likely done with evil/vim bindings in emacs. I’d also like to toy with the built-in viper-mode which emulates vi-bindings. My vimrc is split up between vi-compatible options and vim-specific stuff, so I’m already very familiar with the vi limitations and honestly, it doesn’t bother me much. But that probably will not be a long-term solution if viper-mode affects more than just the editor. I can already tell that emacs “feels” better integrated and more consistent with the default bindings.

So if you’re like me and seemingly tied to vim-bindings, try breaking out of your comfort zone a bit and cracking open the emacs tutor with C-h t. Emacs tutor is extremely useful even beyond the editor bindings, but it’s unfortunately kind of useless if done in evil mode.

You might be surprised.

As I dug through my init.el, I realized there was a ton of functionality that I no longer used, and my inconsistent package syntax was sloppy at best. It was a mash-up of use-package and conventional commands, the result of copypasta from both old and [more] modern solutions found on the internet. For some of the packages I did not remember why they were there or where I originally found inspiration for them. And the videos I watched to help write my init.el are all now 4-5 years old. Surely there have been changes to Emacs.

There have been changes to Emacs.

It turns out Emacs has changed a lot since I last used it (which I believe was the tail end of version 27 when I wrote my config). A ton of features are now built-in: use-package, which-key, fido-mode, project.el, and treesitter to name a few. Many small packages were absorbed or made obsolete by Emacs built-ins (e.g. hide-dotfiles-mode package for dired). Ivy and Counsel still exist, as does the older Helm, but has largely been replaced by Vertico/Orderless among the hoi poloi. These, like many other modern Emacs packages, extend upon built-in functionality rather than reinventing the wheel with separate frameworks like Helm, Ivy, and Counsel.

One of the best Emacs references is the book and blog Mastering Emacs. The author goes through most of the core functionality of Emacs in enough detail to be thorough but not to the point of overwhelming a new user. You’ll be surprised what is already built-in.

Example: Completion

Here’s an example of my thought/discovery process for completion:

Since I want some kind of completion framework, I started with bare-bones ido mode. This is good to know anyway when you inevitably have run a clean config because of an error. Ido mode adds completions for switch-to-buffer and find-file, which is not enough for me. Then I added in the relatively new fido mode which adds completions to the minibuffer with flex matching, and has effectively superseded ido mode (thought ido is still included). I disabled fido mode and enabled only icomplete-vertical-mode. When configured this can be used to get similar functionality to fido-vertical-mode without flex matching. Then I added Vertico, Orderless, Marginalia, and Corfu in order to see what those popular packages give me.

After testing and configuring all of these options, I’ve settled on the built-in fido-vertical-mode because I like flex completions, and configuring in-buffer completions (but not point completions - completions show up in a separate minibuffer) so that completions are shown in a minibuffer but are not selectable (found it a bit clunky). This combo has all the functionality I need from Ivy/Counsel, and the built-in Emacs completion framework is suprisingly customizable. I have no need for the slimmer (relative to Ivy/Counsel) Vertico, Orderless, Marginalia, Corfu, etc, though I do concede they could add value. Corfu does still seem to be the best route for point-completions if you want that, I just found the built-in minibuffer completions to be good enough. The reality is that I’m just so good and tpynig that a rboust cmopltetion framweork is not smoething I need. The lesson in all that is you’d never even know this if you only go through one of the older Emacs video series from SystemCrafters, distrotube, etc.

Another example: themes. The built-in modus themes are on another level. I generally gravitate toward dark-purple/blue themes like palenight, onedark, tokyonight, etc, and also have a huge love for gruvbox because of how easy it is on the eyes, even if it sometimes looks baby-green (parents know what I mean). The Modus themes are in the same vein as palenight/onedark but are incredibly customizable and readable. On first load, modus-vivendi-tinted was passable but not my favorite. After spending some time with it, researching the excellent documentation, and making it work for proof-of-concept, I’ve found I really like it. Customizing takes some work, but that’s part of the fun. The point is that I would not have discovered this unless I deliberately gave built-in functionality a try.

I’ll also add that a similar theme to Modus-Vivendi can be found on Vim: zaibatsu default colorscheme with only a few tweaks (background color, etc).

In short time I have basically rewritten my Emacs config and done so in a way that is much smarter imho. And I’ve learned a ton of the nuts-and-bolts of Emacs. In another post I’ll go through my config line-by-line-ish, but for this one I’m just going to share some principles I’ve adopted in writing my config.

My Guidelines for Writing My Emacs config:

1. If you’re short on time, Doom and other pre-built configs are far better than a quick, franken copypasta’d “custom” config.
2. Avoid copying old (or any) guides.
3. Identify the functionality you need and base your package selection off that.
4. Know the built-in solutions first.
5. Look at alternatives before selecting one.
6. Be consistent with package calls, i.e. either utilize use-package or don’t.
7. Use early-init.el.
8. Split your init.el into multiple files.
9. Literate configs should not be necessary.
10. Evil-mode: use evil-collection and general.
11. Custom keybindings should be completely unique for functions without existing keybindings.
12. Custom functions should be identifiable as custom.
13. Create an additional static “rescue” init.el facsimile with bare-bones built-in configuration.

In another post I’ll go into detail each of these points, and perhaps add to them. For now, ponder them for yourself and develop your own interpretation or opinion about them. These are my opinions, you may (and should reasonably) disagree with them.

Prior to Emacs

Prior to using Emacs I was (and still am) a vim user, preferring simple configs and using as much of the built-in features of vim as possible. See my first blog post for more info. I bought in to a lot of the meme takes that emacs is bloated and contrary to the Unix philosophy, suckless dot org type stuff. In hindsight this is really just saying “Emacs is hard, I don’t understand it yet, so I’m going to have a reason to justify not using it.” I’ll save the bloat rant for another post.

Like most things unknown, I never felt a need to use Emacs - everything I needed was found in vim and a slew of cli tools. So I thought.

Need to Learn Lisp

In early 2022 I started a new job which involved a lot of design work on AutoCAD. AutoCAD is a piece of software I have a love/hate relationship with: I love it because I have to use it and have so for the majority of my engineering training and career. It does what it needs to well enough, and is pretty extensible for such a monstrosity of proprietary software. I can say a whole lot more negative about it, and I already said I’d save the blot rant for another post.

AutoCAD is a relatively old piece of software, so old that it uses Lisp for scripting. Like all Lisps, AutoCAD Lisp is its own flavor but shares a lot of similarities with Common Lisp. Prior to this job I never had a need to use scripting within AutoCAD, so I took the opportunity to learn Lisp from one of the handful of popular Lisp projects: GNU Emacs.

Starting with Doom Emacs

I took the route most vim users probably do and start with a pre-configured Emacs rice, and for me that was Doom Emacs. It was a way to get my feet wet and see what Emacs is capable of before going all-in on a vanilla config. With projects like Doom and Spacemacs you get a possible end result for inspiration, perspective, and motivation, because you sure as hell are getting none of that when launching vanilla emacs for the first time. Similar to using a pre-riced window manager like those which used to ship with Arco Linux, or any of the many Arch Linux-based “distros” which are simply just bloated wm rices (Omarchy).

Even though I no longer use Doom and don’t recommend using pre-packaged configs for long term use, I still think it’s a good place to start if you’re just curious and don’t want to dedicate too much time or effort to software you may not actually like. Doom and Spacemacs give a very pleasant first impression, which was not the case when I first opened vanilla emacs out of curiosity when I was brand-new to Linux. And those first impressions are often what will make or break your opinion of the software - the same reason we almost always recommend Linux Mint to new users.

Leaving Doom

Doom is a very opinionated Emacs framework. The mods are impressive and its speed is something to behold considering all the bloat (it is actually bloated). As a newb I found it very difficult to figure out exactly what was going on under the hood; it felt very far removed from the core system and I felt like a lot of the Emacs guidance in older posts or references simply didn’t apply. Emacs is different enough as it is, and I think that’s the main reason people write off Emacs as bloated or dumb or inferior: it is different and hard when coming from anything else. To an extent Doom adds to that complexity, almost like added another OS-layer onto a program that is jokingly (but accurately) called an OS running on an OS.

Overall Doom Emacs gave me a very positive opinion on Emacs, but I knew I would be on a vanilla config in short time.

Building a Vanilla Config

After some time I decided to move to a vanilla emacs configuration. SystemCrafters and Prot were really helpful. My fairly lean ~1500 line init.el had a lot of the features you found in the wild at that time - use-package, evil & evil-collection, general, which-key, counsel, ivy, ivy-rich, corfu, etc. It relied pretty heavily on outside packages but was not nearly the beast that is Doom. And it was set and forget for about a year of primary use.

I stopped using Emacs

I stopped using Emacs because I found myself using my personal computer less and less. Other interests occupied my spare time; linux hacking became dull. I’ll go on several-month to year+ “binges” on whatever interests me the most. At that time I was making a lot of improvements to my house, so a lot of time was spent playing with power tools and clearing out woods. And a ton of biking.

If I was using an editor, it was vim, simply because I wasn’t doing anything more than tweaking a few shell scripts.

Return to Emacs

Alas last fall my interest in linux was renewed through self-hosting and making a homelab, as cringe as that word is. It is a level of fun I hadn’t tapped into and a side of linux (larping as a sysadmin) I hadn’t done much of before. And so it was only a matter of time before I jumped back on the Emacs train, even if just out of curiousity.

Fast foward to January, 2026. I haven’t touched Emacs in over 2 years, probably closer to 3. I see and consoom a bit of new emacs content on yt, some new guys in the game, joined some chats with a number of emacs users, and decide to fire her up again. After a couple minutes of package updating, to my surprise it launches just as I remembered it. Had to refresh myself on some of the major keybindings, but that came back pretty quick. Emacs is great because M-x (alt-x) can be used to launch anything, and C-h can be used to quickly access help files. So when you can’t remember what to do it doesn’t take much effort to figure out, especially if using some kind of matching/completion system in the minibuffer (recommended). I take the same approach with vim - learn the commands over the keybindings.

As I re-write my config and experiment more with Emacs, I’ll post here to document what I’ve done without the need for a bloated literate config, as well as some spicy Emacs takes. That way any of you Emacs-curious readers or Doom Emacs enjoyers can learn from my mistakes experiences and be on your way to a diy config.

If you’re curious about Emacs, give it a try. It’s fun - that’s the only reason you need.

My Background regarding the SSPX

During my second year of college I began attending the Traditional Latin Mass (TLM), which was at an Fraternity of St. Peter (FSSP) apostolate a reasonable drive away. For those who don’t know, the FSSP was founded by former SSPX members who disagreed with SSPX founder Archbishop Marcel Lefebvre’s decision to consecrate 4 bishops without Rome’s approval in 1988. As a result the priests of the FSSP are anti-SSPX to varying degrees, mostly hardline. There was no SSPX presence near me at college nor where I grew up. I didn’t have strong feelings towards the SSPX other than I did not believe I could attend their chapels and I found their website harsh (in hindsight they had a pretty decent site layout, I don’t even think they were using https). I began to follow the SSPX closer when their negotiations with Vatican began and ultimately failed around 2009. I attended the FSSP almost exclusively until 2013 when I moved to an area with no FSSP presence.

Around 2019 I transitioned away from a stressful job with long-hours [finally] had [some] free time on my hands. I became a big consoomer of traditional Catholic media, listening to good number of the usual podcasts (Marshall, Remnant, Flanders, Fatima Center, etc) whilst commuting and touching/mowing grass. I read a ton of the standard trad books (Gruner, Ferrara, Davies, +Lefebvre, etc), and overall kept up with the goings on in the Church - at least within my segment of the hoi poloi.

I became sympathetic to the position of +Lefebvre and believed that he acted in good faith. I gained perspective towards him and understood that he was a practical man, a missionary for most of his clerical career, and was used to having to diy in the bush of Africa. Whether he was right or wrong to consecrate said bishops in 1988 and incur what normally would be automatic excommunication, I realized in his own eyes he was making a prudential judgment in a situation that went beyond the letter of the law - I daresay even an inconceivable situation (queue guy from Princess Bride) - believing his obligation before God was to follow not the letter, but the spirit of the law. I concluded that even if he were wrong his decision, he was in good faith and as a result was protected from excommunication in both the 1917 and 1983 codes of canon law, which have a few exceptions for state of emergency, necessity, etc. Far more learned men have come to the same conclusion. ¹

Furthermore in reviewing Rome’s correspondence with and regarding the SSPX since the early 1990s, I came to believe Catholics could attend SSPX chapels provided they do not take on a schismatic attitudes (I’m omitting details here). If you drew a line in the sand and asked me if +Lefebvre was right or wrong side of the line, I would say right. I began attending the local SSPX chapel as I viewed it as the best option in my area for my family. If there was an FSSP, ICRSS, or consistent diocesan church around, I would have probably attended those instead.

TL;DR:

I say all this as background to explain that:

1. I have been on both sides of the SSPX issue.
2. I have considered all sides to some [hopefully adequate] degree
3. I still am not hardline one way or the other.
4. I acknowledge that I could be wrong.

The Crux of the SSPX: Crisis and Necessity

The correctness or even liceity of the SSPX hinges on the fact that:

1. The Church is in a crisis.
2. There is a necessity for bishops to continue the mission of the Church (could also mean a state of emergency).

That’s it, really. To be squeaky clean, you really need both of these to be true.

Talking Heads

Since around 2022 I have mostly removed myself from consoom Catholic media. For the most part it is a distraction for me. I make exception for Avoiding Babylon for the lulz and meme content. There is nothing about the faith I can’t learn from books I have, and there is nothing truly important that I won’t find out from the pulpit or some meme chats. I am not saying you need to tune these out or falling into the classic “you’re not a real Catholic unless you ___” fallacy, but especially with Lent upon us I would advise at least considering it. Plenty of the talking heads laudably take time off during Lent.

Regarding the recent SSPX announcement, I have deliberately not cared much what others have said about it. I will now contradict what I just said and say that from a cursory glance of the headlines it seems the response has been fairly measured and optimistic, especially considering there is time. This is a good thing.

Thought Experiment - the actually schismatic SSPX2

It is the year 2026. The fictional SSPX2 has existed as a formal parallel church since 1970 and has set up its own dioceses since then. The conditions in the Church are otherwise exactly as they are now. We treat the SSPX2 as heretics and formal schismatics.

With that being said:

1. Is there a crisis in the Church?
2. Is there a need for Catholic Bishops?

If you ask any faithful Catholic who attends anything to the right of a garden variety American Novus Ordo, he will almost certainly say yes to both of those questions.

So if Bp. Someguy decided out of necessity he was going to consecrate bishops so that the sacraments of confirmation and holy orders could be continued (and more things), would he be justified under the current circumstances?

If not, I don’t necessarily fault you for saying so; you are saying so out of filial obedience to the Church. But my question to you would be:

1. What would be the point at which we are in a crisis and/or it becomes necessary?
2. If there is never a point where consecrating bishops (or breaking some other disciplinary law) is justified, then why does canon law even give qualifications for doing such things? Why would it leave those kinds of outs?

My Take

Looking at everything from a 30k ft view (that’s about 10km, long live the Empire) over the last 100 years or so, I don’t know how much worse it has to get before we can officially call it a crisis. It seems to quack quack a lot louder than a single duck. I would say even if 25% of the churches were in as bad shape as the average one is today (or was in 1970), we’d be in a crisis (though we might have enough bishops in that case).

Likewise when there are literally single-digit number of bishops who we call /ourguy/ - and the lead of them is an Auxiliary Bishop from Kazakhstan - I’m not sure how we can say there isn’t a need for bishops. Fortunately a number of them still have some time left - provided they don’t get Cdl. Pell’d (RIP) - in 10 or 20 years how many will be left? Are any of the good diocesan or religious priests getting elevated? Who is determining who becomes bishop (aka “king makers”), and who has been elevated over the last 15-ish years? Is there any end in sight to this? Can we even see an inflection point where things begin to slow down?

Perspective is Key

I ask that anyone who feels strongly one way or the other, please have charity and steel-man your opponent.

If you are strongly against the SSPX, please read the works of +Lefebrve, especially Open Letter to Confused Catholics. Read his biography, watch his documentary. Do everything you can to gain his perspective.

Afterwards if you don’t think he was justified, that’s alright, just have an answer as to when he (or someone) would be justified in doing so.

Put yourself in the shoes of a faithful bishop in 2026. What would you do? What would you feel comfortable bringing to your judgment? I don’t envy any of these men, it is a hard decision all around, and I think it would take a tremendous amount of fortitude to faithfully choose one side or the other. It is not a clean win-lose situation, but a bad-worse situation.

Above all I pray God’s will be done. AMDG.

Purple.

Septuagesima

From the Catholic encyclopedia:

(Latin septuagesima, the seventieth).

Septuagesima is the ninth Sunday before Easter, the third before Lent known among the Greeks as “Sunday of the Prodigal” from the Gospel, Luke 15, which they read on this day, called also Dominica Circumdederunt by the Latins, from the first word of the Introit of the Mass. In liturgical literature the name “Septuagesima” occurs for the first time in the Gelasian Sacramentary. Why the day (or the week, or the period) has the name Septuagesima, and the next Sunday Sexagesima, etc., is a matter of dispute among writers. It is certainly not the seventieth day before Easter, still less is the next Sunday the sixtieth, fiftieth, etc. Amularius, “De eccl. Off.”, I, I, would make the Septuagesima mystically represent the Babylonian Captivity of seventy years, would have it begin with this Sunday on which the Sacramentaries and Antiphonaries give the Introit “Circumdederunt me undique” and end with the Saturday after Easter, when the Church sings “Eduxit Dominus populum suum.” Perhaps the word is only one of a numerical series: Quadragesima, Quinquagesima, etc. Again, it may simply denote the earliest day on which some Christians began the forty days of Lent, excluding Thursday, Saturday, and Sunday from the observance of the fast.¹

The Church in her wisdom gives us a time prior to Lent so that we may better be prepared for the Lenten season. It is supposed to be a time of fasting and penance, and nobody who seriously takes up that practice - or any bodily practice - jumps in cold turkey with a day’s notice. The idea is that the entire 40-day period (it’s not quite 40 days, just like Septuagesima/Sexagesima/Quinquagesima aren’t actually 70/60/50 days respectively. Math is hard.) is a time of fasting and prayer in preparation for Easter. Lent isn’t meant to be a 40-day journey where we gradually ween ourselves and hopefully by Easter we’re able to fast for a day or two.

Ideally we are so aware of the liturgical year that at all times we know how many days remain until Lent and so we can be prepared on our own without any reminders. Rephrased: ideally we should not have concupiscence and other effects of Original Sin. Unfortunately that is not how people are, so the Church gives us these visible reminders that Lent is coming. The colour is purple which we only see in Lent and Avent; the Gloria is ommitted; the Epistle and Gospel readings have a more penitential or reflective tone so that we are encouraged to reflect on the Mercy of God and where we need to be in 3 weeks (and at the end of our lives).

This is not a practice isolated to the Latin Church, and it has its parallels in the Greek Church with Meatfare and Cheesefare, plus with similar trends in the readings. This is a universal (i.e. catholic) practice meant to strengthen our weak human nature, which is yet again something the authors of the Novus Ordo - who at least claimed to appeal to ‘modern man’ and the East - got completely wrong.

When I attended the NO - which has been over a decade ago at this point - it very frequently happened that I would show up to Mass on Sunday with Fr. in green vestments, not knowing what Sunday it is in Ordinary Time, and there might be a comment in the homily that Ash Wednesday is this week. I haven’t changed, so I was just as forgetful or side-tracked as I am now. That gave me 3 days to quickly move away from feasting and consooming product to the opposite. Then whatever things I wanted to do for Lent generally didn’t happen at the start, which means they pretty much didn’t happen. Failing in our resolutions is inevitable to at least some degree, but it sure helps if we at least have a fighting chance and make headway from the get go. That initial momentum helps us make it to the end.

So, if you’re like me and completely forgot about Septuagesima Sunday, that is completely ok. The Calendar is designed with us in mind. It’s part of the plan - trvst the plan.

I wish you all a blessed [preparation for] Lent.

Around 2020 (from what I can remember) things started to change. Lua was becoming a first-class citizen in neovim, various projects which resembled Emacs distributions were popping up, lua plugins were becoming more popular and optimized, and other things to distinguish neovim from vim. Whilst I always tried to minimize the number of plugins I used in vim - mainly for speed since was/am using old laptops as GNU/Linux enjoyers are wont to do - in neovim it became increasingly irrelevent because of how snappy “bloated” lua configs could be. Neovim could easily become a full-blown terminal IDE without any effect on performance, making it loads faster than its IDE competition, and better by virtue of being vim vs a compatibility layer like in vscodium.

With that in mind, why do I continue to use paleo-vim?

Use case

Let’s first look at my vim use case. Professionally I am not a programmer (as much as I might cosplay with LISP at work). I use vim primarily for what it is: a text editor. I use vim to edit files on my desktop and the many servers that I use. I need to have a simple config that I can quickly copy over to a server when needed, or if not possible one that I can generate on my own. Vimrc in its default location (~/.vimrc) is quickest to transfer over to another server. Whilst this could easily be located in ~/.vim/vimrc, using scp this introduces a bit more complexity: removing the ~/.vimrc file if it exists, checking for the ~/.vim directory and creating it if not present, and then copying vimrc to the ~/.vim directory. Easy to script, but often I don’t want to hassle with that. The same logic applies for neovim just with ~/.config/init.vim. Many people make a big deal about crowding the home directory with dotfiles, and that’s something my tism really doesn’t care about. Perhaps more on that in another post.

Plugins

I have only a handful of plugins and each are lazy-loaded, meaning they don’t load until I call the plugin’s function. Currently [at this time] I am using vimwiki, vifm, and fzf. Generally I never use any of these plugins, and fzf comes in handly on occation when I’m looking for specific files for libraries in /var. I only use default colorschemes, and thanks to neovim-inspired updates there are some really good default colorschemes - retrobox gang rise up. My vimrc checks if the plugins directory exists before loading pluins - which is basically never on servers - so my vimrc is itempotent. Additionally I unfortunately use Windowns at work, so my vimrc has conditionals for Windowns and GNU/Linux/BSD. All this is possible on neovim of course, but it gets back to a more fundamental issue: why change an editor if nothing will change what I do with said editor?

Vimscript

I like vimscript. I use it all the time for ad-hoc commands within vim. Does it suck as a plugin language? Probably. Do I like lua? Yeah, I do like lua. It’s a smart choice for what neovim aims to achieve. I have used it in other programs. I don’t have strong feelings towards vim9script because I’ve never felt a need to deviate from paleo-vimscript. Hats off to neovim for keeping backwards compatibility with vimscript and also making compatability for vim9. Regardless of what you think of vimscript, you need to now some of it - at least ad-hoc set commands.

Gill Bates

Speaking of Windowns, I’ve found gvim works better than neovim. Despite vimrc having a different name in Windows (_vimrc), I have a macro that copies .vimrc and renames to _vimrc. Neovim on Windowns only works in the terminal, and short of alacritty the windows terminals aren’t great. I haven’t tried neovim on Windowns in about several years, so this has probably changed as a lot has happened with Neovim since.

Contrarian

As much as I try to fight it, I can be a contrarian. In 2026 using paleo-vim is the contrarian thing to do. When Bram passed (RIP) I wasn’t sure where the project would go, but fortunately it has been more or less business as usual since. This contrarian spirit extends to much of my computing setup: openrc, xorg / xlibre, Emacs, vanilla GNU/Emacs, C vs rust, etc, and in plenty of other areas in my life.

Emacs is Neovim but better

Rather than ricing out neovim to be an IDE, I prefer just using Emacs. I don’t buy in to the Emacs vs Vim wars because I use each to their strengths. I love the complete operating system Emacs provides and how it eliminates using terminal programs which have similarities, but ultimately are different beasts; they often have keybindings that conflict with one-another, or have some vim-like keybindings but not all of them. This is not a problem in Emacs, and even if it were it would be easy to rectify because of the major/minor mode structure. Weechat, newsboat, tmux, etc, are all wrapped into Emacs.

As a text editor and in the tty, vim absolutely reigns supreme, but Emacs with evil bindings is a passable vim. I have no issues opening a terminal and using vim if needed. But on all my servers vim is a must-have; I would never even think of installing Emacs on my alpine Linux servers just to edit text. More on Emacs in follow-up posts.

Separating Vim from Neovim

All that being said I have a lua-config of neovim on my system. I am a tinkerer and still enjoy the process of learning new things. I have nvchad installed and can open it with a specific config. I don’t regularly use these neovim flavours, but having them completely separate from my vim configs means I can fuxx around with neovim IDEs without touching my .vimrc or creating multiple inits which are called depending on what I want.

Love for the Neovim project

[Again] All that being said I think neovim has been a net-positive. It has completely changed that possibilities with vim, and the project itself has brought improvements to paleo-vim, e.g. improved default colorschemes as mentioned about. Regardless of how you feel about vim9script, it would not have happened had neovim never forked. Neovim has caused a splintering in the projects which I think is a good thing. Old crusty guys like myself stick to vim because of its simplicity and minimalism (relatively speaking; vim is actually bloat compared to nvi which is bloat compared to vi which is bloat compared to ed), and guys who want the plugin-heavy or IDE environment have moved away to a separate project.

This can keep the goals of each project consistent, and vim no longer has to cater to pull requests for features it deems appropriate for neovim. TJ and Prime and other neovim faces also seem like legitimately good guys, and in the past neovim devs have pushed their own improvements to vim when appropriate. Tons of users have discovered the goodness that is vim (in the broad sense) and have moved away from vscode, sublime, gedit (jk nobody uses that trash), or other IDEs/editors because of the hype neovim has on the internet. All good things and I think it shows the long-term (albeit seemingly rare) mutual success that can be possible from project forks.

Emacs is still better though.

Who else uses paleo-vim? Let me know.

• Heaventree
• Technical Renaissance

Bros

• Kelvin
• Denshi
• Joshua Blais
• Matthew Kennedy
• tony, btw
• cashmere

GNU/Linux References

• Readline Cheat Sheet

GNU/Linux Distros I use and recommend

• GNU Guix
• Devuan GNU+Linux
• Artix GNU/Linux
• Alpine Linux
• Proxmox

Various Sites

• Unix Digest
• Bogleheads
• Official Ninja Webpage
• Hecking based website

Channels I regularly consoom

tech:

• learnlinuxtv
• system crafters
• prot
• dt
• tony_btw
• joshua blais
• denshi
• dj ware
• kris occhipinti
• unaboomer
• Old Tech Bloke (RIP)

Catholicism:

• SSPX Podcast
• Sensus Fidelium
• Avoiding Babylon

finance:

• Ben Felix
• Patrick Boyle
• The Money Guy
• DiamondNestEgg
• Strong Man Personal Finance
• RJ Financial / Run on the Bank
• Bank Account Bonus Central
• Clark Howard

I have many interests and my site is or will be a way of documenting them - GNU/Linux and tech of course, but also Catholicism, personal finance, credit cards/bank account churning, cycling, ball and disc golf, home improvement, and many more. Computers in general and GNU/Linux specifically are one of many interests, but one I consistently keep busy with and will hopefully be able to as long as I live.

codeberg