Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 1999.

Recently I filled up the storage in my iPod and so planned to upgrade it. one. This is a process I've been through several times in the past. My routine used to be to buy the largest capacity SD card that existed at the time (usually twice the capacity of the current one) and spend around £90. Luckily, SD capacity has been growing faster than my music collection. You can buy 400G SD cards today, but I only bought a 200G one, and I only spent around £38.

As I wrote last time, I don't use iTunes: I can move music on and off it from any computer, and I choose music to listen to using a simple file manager. One drawback of this approach is I tend to listen to the same artists over and over, and large swathes of my collection lie forgotten about. The impression I get is that music managers like iTunes have various schemes to help you keep in touch with the rest of your collection, via playlists: "recently added", "stuff you listened to this time last year", or whatever.

As a first step in this direction, I decided it would be useful to build up playlists of recently modified (or added) files. I thought it would be easiest to hook this into my backup solution. In case it's of interest to anyone else, I thought I'd share my solution. The scheme I describe there is used to run a shell script to perform the syncing, which now looks (mostly) like this:

date="$(/bin/date +%Y-%m-%d)"

    grep -v deleting \
        | grep -v '/\._' \
        | grep -E '(m4a|mp3|ogg|wav|flac)$' \
        | tee -a "$plsd/$date.m3u8"

# set the attached blinkstick LED to a colour indicating "work in progress"
# systemd sets it to either red or green once the job is complete
blinkstick --index 1 --limit 10 --set-color 33c280

# sync changes from my iPod onto my NAS; feed the output of files changed
# into "make_playlists"
rsync -va --delete --no-owner --no-group --no-perms \
    --exclude=/.Spotlight-V100 --exclude=/.Trash-1000 \
    --exclude=/.Trashes --exclude=/lost+found /media/ipod/ /music/ \
    | make_playlists

# sync all generated playlists back onto the iPod
rsync -va --no-owner --no-group --no-perms \
    /home/jon/pls/ /media/ipod/playlists/

Time will tell whether this will help.


Continuing a series of blog posts about Debian packages I have adopted (Previously: smartmontools; duc), in January this year I also adopted glBSP.

I was surprised to see glBSP come up for adoption; I found out when I was installing something entirely unrelated, thanks to the how-can-i-help package. (This package is a great idea: it tells you about packages you have installed which are in danger of being removed from Debian, or have other interesting bugs filed against them. Give it a go!) glBSP is a dependency on another of my packages, WadC, so I adopted it fairly urgently.

glBSP is a node-building tool for Doom maps. A Map in Doom is defined in a handful of different lumps of data. The top-level, canonical data structures are relatively simple: THINGS is a list of things (type, coordinates, angle facing); VERTEXES is a list of points for geometry (X/Y coordinates); SECTORS define regions (light level, floor height and texture,…), etc. Map authoring tools can build these lumps of data relatively easily. (I've done it myself: I generate them all in liquorice, that I should write more about one day.)

During gameplay, Doom needs to answer questions such as: the player is at location (X,Y) and has made a noise. Can Monster Z hear that noise? Or: the player is at location (X,Y) at facing Z°, what walls need to be drawn? These decisions needed to be made very quickly on the target hardware of 1993 (a 486 CPU) in order to maintain the desired frame-rate (35fps). To facilitate this, various additional data structures are derived from the canonical lumps. glBSP is one of a class of tools called node builders that calculate these extra lumps. The name "node-builder" comes from one of the lumps (NODES), which encodes a binary-space partition of the map geometry (and that's where "BSP" comes from).

If you would be interested to know more about these algorithms (and they are fascinating, honest!), I recommend picking up Fabien Sanglard's forthcoming book "Game Engine Black Book: DOOM". You can pre-order an ebook from Google Play here. It will be available as a physical book (and ebook) via Amazon on publication date, which will be December 10, marking Doom's 25th anniversary.

The glBSP package could do with some work to bring it up to the modern standards and conventions of Debian packages. I haven't bothered to do that, because I'm planning to replace it with another node-builder. glBSP is effectively abandoned upstream. There are loads of other node builders that could be included: glBSP and Eureka author Andrew Apted started a new one called AJBSP, and my long-time friend Kim Roar Foldøy Hauge has one called zokumbsp. The best candidate as an all-round useful node-builder is probably ZDBSP, which was originally developed as an internal node-builder for the ZDoom engine, and was designed for speed. It also copes well with some torture-test maps, such as WadC's "choz.wl", which brought glBSP to its knees. I've submitted a package of ZDBSP to Debian and I'm waiting to see if it is accepted by the FTP masters. After that, we could consider removing glBSP.



`duc`'s GUI view

duc's GUI view

Continuing a series of blog posts about Debian packages I have adopted (starting with smartmontools), in January this year I adopted duc ("Dude, where are my bytes?")

duc is a tool to record and visualise disk space usage. Recording and visualising are performed separately, meaning the latter is very fast. There are several visualisers available. The three most interesting ones are

  • duc ui, a text terminal/ncurses-based heirarchical browser
  • duc gui, a GUI/X11 application
  • duc cgi, a CGI for access with a web browser

The GUI and CGI resemble the fantastic Filelight KDE tool, which I've always preferred to the similar tools available for GNOME, Windows or macOS. (duc itself works fine on macOS). The CGI could be deployed on my NAS, but I haven't set it up yet.

Indexing is performed via duc index <path> and seems very quick when compared to something like du -sh. The index is stored in a local database.

I adopted duc in sad circumstances after the prior maintainer decided to step down, in response to a discussion we had about a feature request for the Debian package. This wasn't the outcome I wanted, but it's a package I use regularly on several machines so I stepped up to adopt it.


I don't do much Debian stuff these days (too busy) but I have adopted some packages over the last year. This has happened if a package that I rely on is lacking person-power and was at risk of being removed from Debian. I thought I should write about some of them. First up, smartmontools.

smartmontools let you query the "Self-Monitoring, Analysis and Reporting Technology" (S.M.A.R.T.) information in your computer's storage devices (hard discs and solid-state equivalents), as well as issue S.M.A.R.T. commands to them, such as instructing them to execute self-tests.

I rescued smartmontools for the Debian release in 2015, but I thought that was a one-off. Since I've just done it again I'm now considering it something I (co-)maintain1.

S.M.A.R.T. can, in theory, give you advance warning about a disc that is "not well" and could stop working. In practice, it isn't very good at predicting disc failures2 — which might explain why the package hasn't received more attention — but it can still be useful: last year it helped me to detect an issue with excessive drive-head parking I was experiencing on one of my drives.

old and destructive, and I think it should be the exception rather than the norm. Unfortunately it's still baked into a lot of our processes, policies and tools.

disk drive population]( (PDF). In Proceedings of 5th USENIX Conference on File and Storage Technologies (FAST 2007), San Jose, CA, February 2007.

  1. Personally I think the notion of single-maintainers for packages is

  2. E. Pinheiro, W.-D. Weber, and L. A. Barroso. [Failure trends in a large


I do a lot of my work in a virtual machine running Red Hat Enterprise Linux. In order to distinguish the terminal windows that are running shells within the VM from the ones running on my laptop's natively, I configure the shell prompt to look different.

For my other systems, I use my punctual prompt system, but for this VM I thought it would be more fun to have something a bit more on-brand.

A Red Hat prompt

Here's a bashrc snippet to achieve this:

export PS1="\[\e[31m\]$hat\[\e[0m\]"

I ended up switching to zsh for my shell in this VM because of a bash bug exposed by trying this out. You shouldn't hit it for the snippet above, but I originally specified the red colour using 256 color escape codes, and this caused width-error bugs when long lines wrapped. zsh doesn't have the same bug, but it can be avoided in bash anyway by using the much older 8 colour escape codes, as above.


Older posts are available on the all posts page.