linux on The Neo-Babbage Files

So you need kill (or do something else to) something in Linux

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 15 Feb 2025 23:02:00 -0600

(Or, what if you can’t just click the bad thing with the skull until it dies?)

Sometimes you need to kill something in Linux. Sometimes it makes sense to use some sort interactive process monitor, like the process table in Plasma’s System Monitor, or top or htop or bottom or some other sort of top.¹ (Or, if you’re in an X11 environment rather than a Wayland one, you could use xkill.²)

killing with `killall`

You can often get by with killall, e.g., if you want to kill all running Firefox applications:

killall firefox

killing with `pkill`

Or you could use pkill (which has a number of options) in much the same way.

These sorts of approaches don’t always work. Sometimes (this is true in Guix³ a lot) processes are named in ways that killall or pkill don’t match.

listing processes and process ids with `ps`

You can list running processes in Linux with ps -ef, and this will show you all running processes. It’s too much, obviously, there are a lot of things going on in your system. So, you can filter it by “piping” the output of ps -ef through grep, e.g., ps -ef | grep -i emacs, which might show you something like:

emacsomancer    15188 26384  0 21:05 ?        00:00:02 /gnu/store/5vkx1cf1d2k9dj974vgd77yx0fdis284-emacs-pdf-tools-1.1.0/bin/epdfinfo
emacsomancer    23294 26384  0 21:33 ?        00:00:00 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously nil)
emacsomancer    23550  2250  0 21:34 pts/4    00:00:00 grep --color=auto -i emacs
emacsomancer    26384     1  5 19:47 ?        00:05:42 /home/emacsomancer/.guix-home/profile/bin/emacs --daemon --debug-init
emacsomancer    26513 26384  0 19:47 ?        00:00:03 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26514 26384  0 19:47 ?        00:00:02 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26515 26384  0 19:47 ?        00:00:02 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26516 26384  0 19:47 ?        00:00:01 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26517 26384  0 19:47 ?        00:00:02 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26518 26384  0 19:47 ?        00:00:02 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26519 26384  0 19:47 ?        00:00:01 /home/emacsomancer/.guix-home/profile/bin/emacs --quick --batch --load /home/emacsomancer/.emacs.d/eln-cache/30.0.93-e51375a4/el-job-child-8a892b0e-c7b5e3df.eln --eval (el-job-child--work #'org-node-parser--collect-dangerously t)
emacsomancer    26750 23962  0 19:48 tty8     00:00:00 /home/emacsomancer/.guix-home/profile/bin/emacsclient -c
emacsomancer    26761 23962  0 19:48 tty8     00:00:00 /home/emacsomancer/.guix-home/profile/bin/emacsclient -c -e (mu4e)

Since you’ve piped ps through grep, you’re missing the explanatory column headers row (because that row doesn’t contain the string “emacs” and so has been filtered out by grep), which are:

UID        PID  PPID  C STIME TTY          TIME CMD

So, then, picking one of the entries above, let’s line them up:

UID             PID    PPID  C STIME TTY      TIME     CMD
emacsomancer    26384     1  5 19:47 ?        00:05:42 /home/emacsomancer/.guix-home/profile/bin/emacs --daemon --debug-init

The UID is just the name of “user” who executed the process (probably you). The CMD is what the process actually is, which is important. The other important piece here is the PID, which is the Process ID or Processor identifier, for with this you can have your system kill (or do other things) to a very specific process (usually an application, or a process it’s spun off). The other fields aren’t relevant for us here.⁴

`kill` (or, how to kill things nicely)

With the PID, you can do various things with a process, such as kill. This could be a simple kill 26384 to kill the emacs --daemon process.

Sometimes, processes don’t want to die and a simple kill won’t work. kill is equivalent to kill -TERM or kill -15, which essentially nicely ask the process to stop. This is often good, because if the process has some sort of “exit things” it does, like saving backups of open files, it will do those things first before stopping.

But sometimes the reason you’re in the command line in the first place is because a process is hung, and so the simple kill won’t do any good.

`kill -9` (or, what if politely killing doesn’t work)

In that case you can do kill -9, which is “the unsafe way of brutally murdering a process. It’s equivalent to pulling the power cord, and may cause data corruption."⁵ This often not what you want to do, but is useful for when you need to force something to stop immediately or when it’s not responding to polite kill's. (Though kill -9 / SIGKILL won’t kill zombies, because they’re dead already and are just waiting for their parent processes to reap them.)

Advanced `pkill` (or, what if there are too many things to kill one by one?)

If you recall the ps -ef | grep -i emacs output from above, there are often a bunch of associated processes. I’ve often ended up having to try to run kill (or kill -9) on a bunch of PIDs one by one until finally the application shut down (cases where killall didn’t work for one reason or other).

We can instead use our process lister (ps -ef) with piping to pkill. E.g., like this in the case of killing all processes named “emacs”:

ps -ef | pkill -f emacs

Careful, because, especially if the “name” is short, it might be a substring of other running processes. (I.e., you probably don’t want to try something like ps -ef | pkill -f e. It would kill emacs --daemon, true, but it would also kill any other process with an e in it.)

You can check first by piping ps -ef through pgrep:

ps -ef | pgrep -l emacs # show the list of all the processes (and their names) to be killed first

to see a list of the names of the processes that would be killed (for our emacs example).

Or, if you need a bit more information, do instead:

ps -ef | pgrep -a emacs # show the list of all the processes (and their full command line, not just name) to be killed first

to see the full command line (including but not limited to the process’s name).

And, just like kill above, pkill is by default the “polite kill”. If you’re dealing with stubborn processes, you can add a -9 to order SIGKILL, e.g.:

ps -ef | pkill -9 -f emacs

(If you had a completely hung Emacs, say.)

What if you need to do something other than killing a bunch of things?

This is all well and good if all you need to do is kill, but sometimes there are other things to do.

For instance, I finally got Mullvad VPN‘s own graphical client to work on Guix,⁶ but for some reason the graphical interface split tunnelling doesn’t work for me on Guix (usually the Mullvad interface would allow you open a specific application outside of the VPN tunnel (i.e. on your regular connection)). Fortunately, Mullvad also has a command-line interface and one can add currently running applications to be excluded from the VPN tunnel (this is also useful even if your Mullvad GUI split-tunnelling is working for not having to shut down and re-open applications if you want them excluded from your VPN tunnel). But it does it by PID, e.g.:

mullvad split-tunnel add 26384

(if we were excluding the emacs --daemon PID from the above example from the VPN tunnel, say.)

One of the obvious things one might want to exclude from a VPN tunnel is a particular browser (e.g., there’s a site that doesn’t like the VPN, so you open up a second browser outside of the VPN to use to access that site).

But browsers often involve a number of processes, and I found myself having to manually run the mullvad split-tunnel add command on ten different PIDs, and check mullvad.net each time to see if that was the one I needed or not.

This is both time-consuming and frustrating and, just like kill'ing, we can instead do it at scale.

Now, the mullvad split-tunnel command itself doesn’t have a built-in facility to either add processes by name or more than one in a single shot, but we can write a loop over a list of PIDs and have the loop execute mullvad split tunnel add ... for each one.

In Bash (“the Bourne Again SHell”), if you wanted to exclude Firefox from the Mullvad VPN tunnel, you could do:

for pid in $(pgrep -u $(id -u) -f "firefox"); do mullvad split-tunnel add "$pid"; done

Just like for pkill, you can double-check before what would be added to the tunnel exclusion by doing one of:

ps -ef | pgrep -l firefox # show the list of all the processes (and their names) to be killed first
ps -ef | pgrep -a firefox # show the list of all the processes (and their full command line, not just name) to be killed first

If you’re using Fish shell (“FInally, a command line SHell for the 90s”), instead of the Bash line above, you would use:

for pid in $(pgrep -u $(id -u) -f "firefox"); mullvad split-tunnel add "$pid"; end

But what if you don’t want to remember arcane incantations?

I don’t, or, well, won’t. I can probably find it in my shell history once I’ve run it on a machine, but we can do better than that.

We can instead add a function to the shell.

For Bash, you would add to your ~/.bash_profile:

function mullvad-split-tunnel-by-name() {
  for pid in $(pgrep -u "$(id -u)" -f "$1")
  do
      mullvad split-tunnel add "$pid"
      printf "added to split tunnel: %s\n" "$(ps -p "$pid" -o command= | awk '{print $1}')"
  done
}

(You don’t need the printf bit if you don’t want, but this way you’ll see a proper list of the names of all of the excluded processes, which the mullvad split-tunnel add command doesn’t do by itself.)

Then (once your .bash_profile is source'ed)⁷, you could just enter the following in the terminal to have all firefox processes excluded from the Mullvad VPN tunnel:

mullvad-split-tunnel-by-name firefox

(You can choose a shorter name for your function than mullvad-split-tunnel-by-name of course, but for me such is fine with TAB completion.)

And similarly for other things you wanted to exclude from the VPN tunnel (e.g., mullvad-split-tunnel-by-name chromium).

For Fish, you would add a new file to your ~/.config/fish/functions/ directory (say ~/.config/fish/functions/mullvad-functions.fish) with the following content:

function mullvad-split-tunnel-by-name --description 'adds all matching instances to mullvads split tunnel'
  for pid in $(pgrep -u $(id -u) -f $argv)
      mullvad split-tunnel add "$pid"
      printf "added to split tunnel: %s\n" "$(ps -p $pid -o command= | awk '{print $1}')"
  end
end

(Again, the printf line is optional. And again you should source it or restart your shell.)

A couple of other useful mullvad split-tunnel functions

These can be defined in similar fashion to the above mullvad-split-tunnel-by-name: one for removing things from the VPN excluded list, and for one for showing what’s currently on the list by name. (since mullvad split-tunnel list just spits back a list of raw PIDs, which isn’t very helpful for identifying what’s actually being split tunnelled….)

removing processes from exclude list

Like mullvad-split-tunnel-by-name, but for removing excluded processes (i.e., re-including them in VPN tunnel):

In Bash:

function mullvad-remove-process-by-name() {
   for pid in $(pgrep -u "$(id -u)" -f "$1")
   do
       mullvad split-tunnel delete "$pid"
       printf "removed from split tunnel: %s\n" "$(ps -p "$pid" -o command= | awk '{print $1}')"
   done
}

In Fish:

function mullvad-remove-process-by-name --description 'remove all matching instances to mullvads split tunnel'
  for pid in $(pgrep -u $(id -u) -f $argv)
      mullvad split-tunnel delete "$pid"
      printf "removed from split tunnel: %s\n" "$(ps -p $pid -o command= | awk '{print $1}')"
  end
end

listing processes in exclude list by name rather than PID

Checking on what’s currently split out from the VPN tunnel: this provide a listing of processes currently excluded from the VPN tunnel by name (in a couple of options):

In Bash:

# list full command line info associated with each PID in list
function mullvad-list-excluded-processes-by-long-name() {
    mullvad_vpn_exclude_array=( $(mullvad split-tunnel list) )
    mvre='^[0-9]+$'
    printf "Processes excluded from VPN tunnel:\n\n"
    for key in "${!mullvad_vpn_exclude_array[@]}"
    do
        if  [[ ${mullvad_vpn_exclude_array[$key]} =~ $mvre ]]
        then
            printf "PID %s = %s\n" "${mullvad_vpn_exclude_array[$key]}" "$(ps -p "${mullvad_vpn_exclude_array[$key]}" -o command=)"
        fi
    done
}

# list just process name info associated with each PID in list
function mullvad-list-excluded-processes-by-short-name() {
    mullvad_vpn_exclude_array=( $(mullvad split-tunnel list) )
    mvre='^[0-9]+$'
    printf "Processes excluded from VPN tunnel:\n\n"
    for key in "${!mullvad_vpn_exclude_array[@]}"
    do
        if  [[ ${mullvad_vpn_exclude_array[$key]} =~ $mvre ]]
        then
            printf "PID %s = %s\n" "${mullvad_vpn_exclude_array[$key]}" "$(ps -p "${mullvad_vpn_exclude_array[$key]}" -o comm=)"
        fi
    done
}

Similarly for Fish:

function mullvad-list-excluded-processes-by-long-name --description 'lists excluded processes in mullvads split tunnel by long command name'
    printf "Processes excluded from VPN tunnel:\n"
    for key in $(mullvad split-tunnel list)
        if string match -qr '^[0-9]+$' -- "$key"
             printf "PID %s: %s\n" "$key" "$(ps -p $key -o command=)"
        end
    end
end

function mullvad-list-excluded-processes-by-short-name --description 'lists excluded processes in mullvads split tunnel by short process name'
    echo "Processes excluded from VPN tunnel:"
    for key in $(mullvad split-tunnel list)
        if string match -qr '^[0-9]+$' -- "$key"
             printf "PID %s: %s\n" "$key" "$(ps -p $key -o comm=)"
        end
    end
end

Beyond tunnelling and killing

These techniques — including defining various named speciality functions (in whatever shell) — could obviously be adapted for other similar cases of wanting to run a command on multiple processes sharing (all or part of) a name, whenever you find you’re tired of wasting time manually mucking about with heaps of PIDs.

For list of good Linux system top's and related, see, e.g., https://github.com/luong-komorebi/Awesome-Linux-Software#system-info--monitoring ↩︎
The Wikipedia page for xkill notes: ‘Xkill has been cited as an example of a program with a simple and appealing user interface. Its mode of operation has been summed up as “Just click the bad thing with the skull and it dies."’ ↩︎
A Scheme-based package manager+Linux distribution (Wikipedia: Guix). See elsewhere on this blog: #guix. ↩︎
The PPID is the Process ID of parent process. You can see that the PID we’re looking at here is 26384, if you look at the longer list of the output of ps -ef | grep -i emacs above, you can see that this is the PPID of a number of the other listed processes, because they were started by this emacs --daemon process. (—which itself has a PPID of 1 because I started it from the terminal myself, and that seems to count as being started by Process 1, the first process started during the booting of the system, which is usually the init system, presumably because it’s the ancestor of all other processes and “adopts” any “orphaned” or otherwise apparently unsupervised processes.) ↩︎
Quote from: https://stackoverflow.com/a/43725403/570251. -9 is equivalent to -SIGKILL, on which see here, whereas the plain kill or kill -15 is -SIGTERM, on which see here. ↩︎
A working package definition for the Mullvad VPN desktop client on Guix is here. Using Mullvad on Guix has been a longtime bugbear for me — so much so that I once wrote my frontend for it in Common Lisp: Volemad. ↩︎
I.e., source ~/.bash_profile. ↩︎

Dealing with possessed TrackPoints on later model ThinkPads

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 18 Jun 2022 19:51:00 -0600

On a new-to-me ThinkPad T440p, I’ve had the worst time with the TrackPoint.

First, the stock configuration has a horrible touchpad - which shouldn’t matter if you don’t use the touchpad, but the horribleness of it is that the physical buttons that should be on the top of the touchpad, and are on the touchpads of models preceding and following the **40 line, are not there. But one can replace it, and so I did.

The T440p is nice in that servicing the fan and other internals of the machine is a relatively easy affair compared to say an X230. Just undo two screws on the bottom of the laptop and slide off the back panel, and you have access to memory, drives, the CPU, and so on. And so swapping in a different CPU was really easy and painless.

On the other hand, changing the touchpad was a very involved affair. But it can be done.

However, still the mouse-cursor experience for the machine continued to be horrible. Firstly, there was significant “drift” of the TrackPoint. I.e., even once pressure is released, it keeps moving, for a long time.

However, this ends up being solvable via

sudo -s echo  'ACTION=="add",SUBSYSTEM=="input",ATTR{name}=="TPPS/2 IBM TrackPoint",ATTR{device/drift_time}="30"'  > /etc/udev/rules.d/10-trackpoint.rules

(If you’re trying to do this in Guix, something like:

(define %trackpoint-drift-rule
  (udev-rule
    "10-trackpoint.rules"
    (string-append "ACTION==\"add\",SUBSYSTEM==\"input\",ATTR{name}==\"TPPS/2 IBM TrackPoint\",ATTR{device/drift_time}=\"25\""))

(define %my-desktop-services
   (cons (udev-rules-service 'trackpoint-drift %trackpoint-drift-rule)
         (modify-services %desktop-services
                          ....) ; other modifications here
         ))

(operating-system
  ....
  (services
    (append
     (list
      (service openssh-service-type)
      (service cups-service-type)
      (service nix-service-type)
      ....)
     %my-desktop-services))
  ....)

instead.)

But, unfortunately, this doesn’t solve what is actually the most horrible issue: the mouse cursor sometimes, when in use, just teleports around the edges of the screen and starts randomly clicking on things.

I finally turned up some discussion of this issue (though not for the T440p specifically) at: https://bugzilla.kernel.org/show_bug.cgi?format=multiple&id=209167 (The discussion suggests that it should somehow be solved in the kernel, but that is not my experience, even running kernel 5.17.13.)

And found that adding psmouse.proto=imps to the kernel arguments and disabling the touchpad in the stock BIOS solves the “possessed mouse cursor” issue. For better or worse, it seem to make the TrackPoint be detected as a generic PS/2 mouse. Which means that drift_time can no longer be set, and I do get a little bit of drift from time to time, but it’s not too bad and certainly is far less maddening than the “possessed mouse cursor” behaviour.

For Guix, the way to implement this is something along the lines of:

(operating-system
 ...
 (kernel-arguments (cons* "modprobe.blacklist=pcspkr,snd_pcsp" "psmouse.proto=imps" "acpi_osi=Linux" %default-kernel-arguments))
 ...)

(The other kernel arguments are simply the other ones I use, and are not directly connected with this issue.)

Depending on the model of ThinkPad and/or the environment, using psmouse.proto=bare instead may work better (see discussion at: https://www.reddit.com/r/thinkpad/comments/v7vn0o/thinkpad_t440p_trackpoint_occasionally_going_crazy/icjkk0o/ ).

So, perhaps not an entirely satisfactory solution, this impish exorcism, but better than alternatives.

Guix, Nix: You are in a maze of twisty little $PATHs, some undefined

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Wed, 24 Jul 2019 00:48:00 -0600

Some notes on interactive fiction/text adventure games and PATHs in Guix, and StumpWM.

Maze no. 1

There may (likely is) some way of programmatically setting the X Windows PATH variable in Guix System (née GuixSD) via the base configuration (e.g. config.scm), but I haven’t been able to uncover anything that works. This is relevant for being able to use locally installed static binaries or local shell scripts via the window manager.

As a window-manager-specific workaround, in StumpWM, one can programmatically set PATH variables via (setf (getenv "VARIABLE_NAME") "variable-value"). Thus, if you store local static binaries and shell scripts in ~/bin, the following (which you could include in StumpWM’s init.lisp) will add that to your PATH variable:

(setf (getenv "PATH") (concat "/home/YOURUSERNAME/bin:" (getenv "PATH")))

I use this with a static Haskell binary greenclip, which adds clipboard functionality to rofi, and with shell scripts that give “pretty names” to Flatpak run commands.

For example, the literate/natural-language-based programming interactive fiction design language Inform7 (which is due to be open-sourced sometime this year) is now conveniently available as a Flatpak. But the run command after installing is flatpak run com.inform7.IDE, which is non-ideal. So I made a simple shell script named inform7 placed in ~/bin:

#!/bin/sh
flatpak run com.inform7.IDE

Maze no. 2

Nix can be installed as a standalone package manage on top of other distros, including Guix System, which is useful for be able to obtain software currently lacking in Guix System (including, ironically, Hugo, used by this blog, which is present in Nix). Packages available in Nix but not in Guix include Gargoyle, a very nice interactive fiction front-end client that supports a number of different backends, including Frotz and Glulxe. One of the benefits of Gargoyle is that it “cares about typography”. However, Nix applications by default seem to have trouble finding/seeing fonts, including system fonts, local fonts, and even fonts installed via Nix.

This can be fixed by (1) setting the FONTCONFIG_PATH and FONTCONFIG_FILE, e.g. in StumpWM this can be done with:

(setf (getenv "FONTCONFIG_PATH") "/home/YOURUSERNAME/.config/fontconfig/")
(setf (getenv "FONTCONFIG_FILE") "fonts.conf")

And (2) forcing Nix to look in the right places by manual specification in ~/.config/fontconfig/fonts.conf, adding right before the final </fontconfig> (as appropriate):

<cachedir prefix="xdg">fontconfig</cachedir>
<dir>/home/YOURUSERNAME/.local/share/fonts/</dir>
<dir>/home/YOURUSERNAME/.nix-profile/share/fonts/</dir>
<dir>/home/YOURUSERNAME/.guix-profile/share/fonts/</dir>
<dir>/usr/share/fonts</dir>

And regenerating the font cache (via fc-cache -fv) [possibly you may need to install Nix’s fontconfig package].

Semi-automated installation of Void Linux on pure ZFS with full LUKS disk encryption

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Mon, 17 Jun 2019 15:53:01 -0600

After spending too much time repeatedly trying to set up a Void Linux installation using ‘pure ZFS’ and full-disk LUKS encryption, I ended up writing up a set of BASH scripts to automate (and, effectively, document) the installation process, and prevent me from forgetting steps along the way. There’s quite a number of potential stumbling block along the way (such as grub-probe not knowing how to properly find the root drive) which I figured out ways around, as well as discovering that Void’s zfs-0.8.0 package was missing a python3 dependency which caused ZFS DKMS builds to fail.

The scripts are more or less automated if you’re installing in a particular fashion. They’ll ask for user input along the way for configuring/customising certain things. What isn’t covered is a setup with multiple vdevs or UEFI or musl, but if you want these things you’ll probably be able to patch the scripts accordingly and perhaps these options could be accommodated in a future version.

The scripts live here: https://gitlab.com/emacsomancer/full-zfs-and-full-luks-encryption-on-void-linux , where you’ll find additional instructions and information.

(I do recommend using the Ubuntu Live ISO as your installer ‘host’ for ease and reduction of the installation time: the ‘host’ for the installation doesn’t really matter: basically it’s just being used to run the initial cryptsetup for the LUKS partition and initial ZFS pool creation and the host for the Void chroot. The Ubuntu Live CD has ZFS baked in, so you don’t have to wait twice(!) for DKMS to build ZFS modules.)

Using ZFS for the entire system, from / to /home to /boot also has the advantage of not requiring you to decide how much space to allocation ahead of time. With /boot on a separate partition, I’ve sometimes encountered issues of running out of space on /boot because of maintaining multiple kernels, or else having to massively overshoot in terms of how much space to give to /boot. A full ZFS install avoids this issue, and allows for easy snapshots of the /boot directory.

ZFS is a great file-system if you care about your data. ZFS is most impressive file-system, and it has a number of other wonderful features aside from data-integrity, and once you’re used to it, you’ll want it everywhere. For instance, the ‘default’ lz4 compression is effectively ‘free’, in terms of CPU usage (minor CPU hit for dealing with compression is offset by the need to process smaller chunks of data), and can be significant: on my root dataset (dozer/ROOT/system) I’m currently getting 1.79x compression: so 22.7G of logical data is written in 13.6G, and even my dataset full of PDFs has a more modest 1.03x compression ratio, but this means I save over 3G.

ZFS 0.8.0 also brings with it native encryption. I’ve not chosen to use this at the moment, as LUKS makes a full-disk setup easier at this point, but native encryption could be used in conjunction with LUKS encryption (potentially useful if, say, you want to backup up particular ZFS datasets to a remote and not entirely trusted machine:– natively encrypted ZFS snapshots can be sent without decrypting the data).

All of these various features, such as compression and encryption can be enabled per dataset, which allows for great flexibility. After suffering bit rot, which filtered through and rendered pointless my carefully maintained versioned backups, I really don’t like trusting my data to any other file-system.

Guix: You are in a maze of lispy little passages, (map equal? ′(′all ′alike) ′(′all ′alike))

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 04 Aug 2018 21:47:00 -0500

So I finally made a serious go of running GuixSD, a GNU Linux distro which is largely built on GNU Guile Scheme (a dialect of Lisp) on one of my machines (one I had actually put together with GuixSD in mind: an X200 Thinkpad, which I Libreboot‘ed and put a Atheros Wi-Fi card in), and, to increase both the quantity and variety of Lisps involved, am trying to use with StumpWM (which is written in Common Lisp).

It’s a fascinating distro, modelled on Nix, but implemented in Guile. It’s not been exactly easy to get running (one of the videos on GuixSD from Fosdem 2017 included the line “[GuixSD] is like Gentoo for grown ups”), in part because its architecture is rather different from what I’ve experienced with other Linux distros, which use different package managers perhaps and sometimes even different libc’s, but generally follow a similar design philosophy. Rather than spreading out configuration across lots of different pieces, GuixSD seems to largely try to concentrate it in specific configuration files which are transactional in that they can be rolled back (and thus the system can be rolled back to known working states).

It is a GNU-blessed distro, and does take the FSF’s hard line (and to my eyes sometimes weird line) approach to software. So no proprietary software is included in the Guix repos, including firmware (and it runs on the linux-libre kernel). That by itself is fine, but it means the state of affairs for Guix-packaged browsers is pretty poor. No Chromium, no Firefox. IceCat 52 is essentially what’s currently available (if IceCat were up to the latest Firefox ESR 60, it might be easier) in terms of browsers which might be considered secure.

This led me to try to use the Nix installer by itself^* to try to install Firefox and Chromium. Sadly, I can’t get Nix’s Chromium to work at all on GuixSD, and while Firefox works fine, I can’t get it to see my locally installed fonts (or other fonts I’ve installed via Nix).

Hopefully at some point Next Browser will be packaged for Guix, to bring in another major component written in (Common) Lisp. And when (if?) IceCat 60 comes out, that will alleviate the pain somewhat. (I was a long-time Conkeror user, and I briefly tried it again in GuixSD, but I’m not certain of its security and uBlock Origin no long works with it, which I believe is why I stopped using it in the first place).

Other interesting Lispy pieces include mcron, a cron which accepts (as well as Vixie cron style, I think) Guile config files. The examples in Guix manual I couldn’t really get to work. But via the help-guix listserv I found that one can put simple guile scripts in ~/.config/cron/job.guile. Working out how to do a ‘run this every N minutes’ was not immediately obvious, but I figured out how to do it, e.g.:

; execute run_me every 5 minutes
(job '(next-minute (range 0 60 5)) "run_me")
; run execute_me every 2 hours
(job '(next-hour (range 0 24 2)) "execute_me")

One of the other great things about GuixSD is that its init manager, GNU Shepherd, is also written in Guile Scheme. I’ve only had a chance to play with it a little bit, but it seems very nice and it’s good to find other innovative init managers (I would mention here also runit and s6) which take very different approaches to systemd (another innovative init, or perhaps init+, but one that creates more problems than it solves in the end, in my experience).

On the Guix package manager itself: I learned the hard way that searching for packages in Guix is really only comfortable within Emacs: so do guix package -i guix-emacs and then do everything else from guix-emacs within Emacs ( M-x guix-search-by-name to search package names by regex; and M-x guix-search-by-regex to search names+descriptions by regex). The results returned by guix package -s .... in a terminal are not very browseable (though I tried valiantly for some time). But if you’re interested in Guix, you’ll likely interested in Emacs anyway.

What I’m trying to build on this machine is something with lots of Lisp. Of course the kernel is still a kernel written in C, as are lots of the other pieces like the terminal &c., but much of the user-facing things: the package manager, the windows manager, the init, the job scheduler (=cron), and (most importantly perhaps) the ‘text editor’ (read: document composer, email interface, irc interface, twitter interface, blog post interface, code editor …) are all largely written in and interacted with using some form of Lisp (Guile Scheme, Common Lisp, Emacs Lisp).

Guix is a bit like Emacs, I think. It’s an incredibly powerful tool with lots of interesting possibilities, but when you start using it you’re presented with an empty screen with little indication of what you can do. I’ll be sticking with it, I think. Now I’ve got to get to grips with StumpWM and figure out how to configure polybar…

[And if you’re curious about why Guix is pronounced like “geeks”, have a look at this post over on my linguistics blog.]

* As well as being the package managers of both of their respective distros, both the Nix and Guix package managers can be used on top of other distros. Nix doesn’t have quite the same hard line approach to software licences as Guix.