Dev on diary

Project updates and SteamOS exploration

Thu, 16 Jul 2026 00:11:19 -0600

Firstly, everything mentioned in the previous post is done. I’m especially happy with the solution I came up with for build-level config in fpc-ctl:

Config within the per-project shell script is removed, excepting a pointer to the project’s JSON config file
Everything that was in the script is moved to a builds object in the config
The configmap, which maps project configuration attributes to build variables, has been extended
- When a configmap value contains ::, the right-hand side of the value is treated as an override to the value given at the project level

This has made it possible to cleanly have multiple builds (or even subprojects) defined with a single config file, all managed by fpc-ctl.

fpc-ctl and Thrasher Updates

Fri, 10 Jul 2026 21:03:33 -0600

I did some work this week on the media side of Thrasher. I intended to work on playlists, but my mind went elsewhere. Most of the changes made were little cleanups, fixes, and catches. The one new thing was making facets and people clickable in the web UI to run a query on that facet or person. This was ported over to the music side of things.

I should probably run a new build on t.fp.n so that people can take advantage of that, as well as the fact that the previous button now acts like it does on pretty much all other music players (jumps to beginning of current track unless you push it twice in two seconds).

fpc-ctl, Anubis, and Forgejo

Sat, 27 Jun 2026 16:51:32 -0600

Did a little bit of catch-up today.

Created an Anubis ruleset which allows nothing without a challenge – previously I had been using the default ruleset, which excludes known “bad” bots and challenged anything that looked like an actual browser, but allowed presumed “good” things like curl with no challenge.

I admit that a part of me wonders if this is worthwhile, but most of me thinks that making things even a touch more difficult for shitty companies is the correct thing to do.

Devmode

Mon, 22 Jun 2026 21:20:33 -0600

I started work today on playlists in Thrasher. It was mostly groundwork and UI exploration, so that isn’t what this entry is about.

This entry is about how happy I am with the new devmode feature in the fpc-ctl script. It’s a simple idea, and a borrowed one (including from Hugo, the static site generator that I use for this blog). But it’s a really good one that saves a lot of time and faffing about.

General Updates (But Mostly Thrasher)

Sun, 07 Jun 2026 22:25:46 -0600

I really fell off the updates there. Oops. While I’ve been away, I have mostly been focused on Thrasher. A couple weeks of work went into an overhaul/rewrite of the mobile UI.

There was never an intent to evern have a mobile interface, as I am horrible at UI programming generally, and I had no desire to try to make something like Thrasher work on smaller screens. But not long after getting the desktop version working, of course, I found myself wanting to be able to take it with me. So I hacked together the most minimal possible finger-friendly UI. It was seriously done in about 2 hours of initial effort, followed by maybe a day of tuning. And then it sat for months while much bigger changes were made to the service and the desktop client.

Thrasher Update

Fri, 08 May 2026 23:02:30 -0600

So much work has happened here in the past couple weeks. First I entered all my visual media into the DB and then erapped up all initially planned media handling work. returned to the music side., and a brief description of what has changed there is:

The old, multi-port, multi-Srvr architecture is gone
In its place is a single Srvr, on a single port, which is session-aware
Sessions are implemented with secure (as long as you’re using TLS), HTTP-only cookies
Users are now a required part of the system
There is now a login/authentication flow
These architecture changes introduced a race condition on the Catalog instance
- …which was resolved by having the Srvr maintain a set of extant sessions, with a Catalog for each
- …which caused a change in the Catalog, moving to cloning the DB in-memory only optionally (and not by default)
Finally, sessions usefully survive Srvr restarts, if only minimally so at the present time

And all of this work makes it possible to have things like playlists, and playback that resumes across restarts, in the not-too-distant future. It’s pretty cool.

Cleaning Day

Tue, 21 Apr 2026 10:14:19 -0600

Yesterday, following my abortive attempt to get a Forgejo runner fully operative, I did as I said I would in my previous post, and borrowed the pre-commit hook from Petrel’s repo and put it in all three of Thrasher’s repos.

This led to a pretty big number of small changes, mostly from golangci-lint but also a few from go fmt.

I didn’t do this initially, because Thrasher was – initially – a quick-and-dirty project. A proof of concept, to see if a thing I was interested in was possible. I suppose this means that it’s a real project now, as if the fact that I use it constantly didn’t already mean that.

Enabling Forgejo Runner

Sat, 18 Apr 2026 20:48:07 -0600

# get the runner image
podman pull code.forgejo.org/forgejo/runner:12

# enable rootless podman socket, if not already done
systemctl --user enable --now podman.socket

# generate initial config file
podman run --rm code.forgejo.org/forgejo/runner:12 \
  forgejo-runner generate-config > config.yml
# edit baseline config, and stow it somewhere

# shell in to temp container, with socket given as bind mount, and
# register with forgejo instance, remembering that it needs to be
# on the forgejo network
podman run --rm -it --entrypoint /bin/bash \
  -v "${XDG_RUNTIME_DIR}/podman/podman.sock:/var/run/docker.sock" \
  --network forgejo code.forgejo.org/forgejo/runner:12
$ forgejo-runner register
$ cat .runner
$ exit
# edit contents of .runner into a file on the host; in the same place
# as the config file would be a good idea

# start container with socket (w/usermapping), config file, and runner
podman run -d \
  --entrypoint '["/bin/forgejo-runner", "--config", "/data/config.yml", "daemon"]' \
  -v /PATH/TO/RUNNERFILE:/data/.runner -v /PATH/TO/CONFIG:/data/config.yml \
  -v "${XDG_RUNTIME_DIR}/podman/podman.sock:/var/run/docker.sock:U" \
  --name fjrunner --network forgejo code.forgejo.org/forgejo/runner:12

This got me to a state with a working runner, which tried to execute a work flow, but it failed to checkout the code. The failure definitely has something to do with the fact that both my Forgejo instance and my runner are containers. They share a network in podman, and they can communicate with each other (else runner registration wouldn’t have worked), but then the image on the runner fails to be able to resolve the Forgejo container.

Devlog: Unbreak Day

Wed, 15 Apr 2026 20:01:01 -0600

A couple weeks ago I migrated myself off Github and onto self-hosted Forgejo. Today I took care of a lot of the consequences of that. I’ll spare you the details, because it was just the same issue presenting itself differently across mutliple project repos, namely:

Golang names packages by their repository URLs.

This is great as long as your code lives at Github, forever. It’s less great when you decide to move everything from one place to another. And yes, I know that you can alias packages; I did that once before, back when I first started writing non-toy software in Go, which was also around the time that I migrated to Github, because it finally felt safe to use as a stable platform.

Intro to Thrasher

Mon, 13 Apr 2026 22:36:20 -0600

Since restarting this blog, I haven’t just also restarted work on old projects. I actually have a new one, which is quite far along. In fact I use it pretty much every day, sometimes for hours at a time.

It’s called Thrasher – after the curved-billed thrashers who frequent my yard, and the brown thrasher which is the state bird of my home state, but don’t tell the curved-bills that last part – and it’s my media catalogue and music player.

Forgejo and Anubis

Thu, 02 Apr 2026 19:00:51 -0600

Over the past few days I’ve read about, explored, and then set up a local Forgejo instance as a self-hosted Github alternative. I’ve also deployed the Anubis scraper-blocking proxy in front of all my websites.

This is all a result of AI scraping. My decision to leave Github after many years is because Microsoft announced that even private activity would be used to train their Copilot bot. Meanwhile the rapacious global scraping (and ignoring of robots.txt) by other companies' bots led to my decision to implement Anubis.

Digging Up Carrot

Sat, 28 Mar 2026 17:18:37 -0600

According to timestamps, I last worked on Carrot in 2022. That feels about right, given how much reminding-myself I had to do in order to make good changes to the code.

Also, irritatingly, I clearly left off at the halfway point of a refactor, where I was decoupling the lexer and parser into standalone modules. I had done the lexer, I had not done a thing to the parser. Arguably they don’t need to be separate at all, but I tend to think that strong separation of concerns is always a good thing, even when the end product is likely to appear monolithic.

Roget22 Is Back Again

Fri, 27 Mar 2026 09:47:43 -0600

Well, after about a year of inactivity (partially my fault, partially not) I’m back to the Roget 22 project. If you don’t remember what this is about, I can hardly blame you; here’s the post where I explained things .

I’m not going to make any big predictions or lay out a lot in the way of plans right now, but I did just re-read my last batch up devlog entries, and some things have changed from my thinking at that point. So here’s a list of what’s happening:

Roget22 Dev Diary 0003

Sun, 24 Nov 2024 11:16:54 -0700

Sometimes when you work on something long enough you get tunnel vision. This is a pretty well-known phenomenon, and I had a particularly intense episode of it around the Roget22 project – but I now see a clearer, easier path to making things happen.

Yes, compared to what I last wrote.

I don’t think the why of it is particularly difficult to describe or understand. Many years of dealing with bottomlessly problematic source material led to the following assumptions:

Roget22 Dev Diary 0002

Sun, 17 Nov 2024 22:57:04 -0700

I almost started scanning today, but I didn’t. Instead I sat down and started working on the hairiest problem not caused by PG’s edits over the years: references.

In a modern paper edition of Roget’s, references to other headwords look something like TERM 584.2 to indicate that for other terms similar in meaning to TERM, refer to sense 2 of headword 584.

This is largely inherited from Roget’s original design of argument &c 476, read as “for more terms like this meaning of ‘argument’, see headword 476”. But there are also variants like manifest &c (be evidence of) 467 where the reader is pointed into a specific sense of a headword by use of another term, because early editions did not number the senses within a headword.

Roget22 is back (Dev Diary 0001)

Sat, 26 Oct 2024 12:51:12 -0600

One of my longest-running projects is about to come out of dormancy, again. The thing that would eventually get the name “Roget22” started in, I believe, 2004, when I stumbled on the OCR’d text of the 1921 edition of Roget’s Thesaurus on the Project Gutenberg site.

For the unfamiliar, I point you toward the wiki entry for Project Gutenberg (hereafter “PG”).

According to the credits in the file, the original OCR job had been done in 1984 at MICRA Corp. However, it turns out that MICRA is still around, and their own website contradicts this on a few grounds: