I’ve spent too much of this weekend writing Ansible to make all my Raspberry Pis similar.

This might say more than I’d wish about my nerd level, and about how many tiny computers I have laying around.

I’ve been using Just for a while as a task runner. It’s similar to Make, but optimized for developer ergonomics with a vastly simpler syntax and a wonderful CLI. I’d also been using Mise for other environment management things, such as installing specific versions of Python and NPM and other tools in a project directory.

Someone introduced me to Mise’s own newish task runner, and it just might win me over from Just for most things:

1. Instead of using 2 tools, I can use 1.
2. Just still feels nicer to me, perhaps because I’m more used to it, but Mise is good enough that I don’t think I’d miss the extra features.
3. Mise lets you write tasks in separate files, which lets any editor handle them well without having to support justfile syntax, but still shares a CLI with inline tasks.

I like it.

I wanted to experiment with Forgejo’s Actions as a DIY alternative to GitHub Actions, using a nearby Raspberry Pi as a build server. I also wanted to deviate slightly from their Runner installation process by executing the Runner and rootless Podman as a regular, non-privileged user and without using the system-level systemctl. It was pretty easy once I wrapped my head around it.

1. Set up the runner user. Since I was using Podman, not Docker, I didn’t have to add it to the docker group. As root:

root# useradd --create-home forgejo-runner

This created user number 1001 on my system. Remember that number later when it’s time to configure systemd.

2. Allow that user to run commands via systemctl without logging in and launching them manually:

root# loginctl enable-linger forgejo-runner

3. Use machinectl instead of su to become the forgejo-runner user. Without this, most systemd commands will fail with the Failed to connect to bus: No medium found message. I’m certain there’s a way to get su or sudo to play nicely with dbus but I had more interesting problems to solve today than this.

root# apt install systemd-container
root# machinectl shell forgejo-runner@

4. Run podman-system-service as the forgejo-runner user:

$ systemctl --user enable podman.socket
$ systemctl --user start podman.socket

5. Run the forgejo-runner program as the forgejo-runner user. I lightly modified the standard forgejo-runner.service file:

$ cat > .config/systemd/user/forgejo-runner.service <<EOHD
[Unit]
Description=Forgejo Runner
Documentation=https://forgejo.org/docs/latest/admin/actions/
After=podman.socket

[Service]
ExecStart=/usr/local/bin/forgejo-runner daemon
ExecReload=/bin/kill -s HUP $MAINPID
# 1001 is the forgejo-runner user's UID
Environment="DOCKER_HOST=unix:///run/user/1001/podman/podman.sock"

# This user and working directory must already exist
WorkingDirectory=/home/forgejo-runner
Restart=on-failure
TimeoutSec=0
RestartSec=10

[Install]
WantedBy=default.target
EOHD
$ systemctl --user daemon-reload
$ systemctl --user enable forgejo-runner.service
$ systemctl --user start forgejo-runner.service

I rebooted my RPi to make sure it would start on its own and it did. Yay! Now I can run Forgejo Actions on my little server and everything works as documented.

AWS WAF now uses /64s instead of /128s for IPv6 rate-limit bucketing. That’s a huge and welcome improvement!

It astounds me that in 2024 there’s no canonical way to select which CSS to use for a web browser on a phone screen. You have to guess at how many CSS pixels wide your target device is. If next year’s device is any larger than a hardcoded threshold, they may get your desktop layout instead.

I know there are people who’ve made their careers out of memorizing all the edge cases of this monstrosity. Those are lifetimes lost to toil because no one can agree on an official way to look nice on a cell phone, or the one true way to center an image. It’s madness.

My Raspberry Pi 4 started running hot when I moved it from a freestanding case to a fanless server rack. I’d often SSH in and see idling it at 65C or warmer, with log messages showing it had been thermally throttled. That’s not great.

I just bought a Argon Fan HAT. I installed it and fired up a large Rust compile with 4 concurrent jobs. 20 minutes later and the RPi averaged about 54C with no throttling.

Get your Pi a fan. It wants one very much.

So we were all talking about Palm Pilots, and someone mentioned that they’re available dirt cheap off eBay.

Sigh. I didn’t need this, but it arrived today anyway.

Frankly, a lot of the IIIxe’s assets hold up well. One hardware button press and the relevant app is open and ready half a second later. My fingers remember how to write Graffifi. No notifications, except calendar event reminders I configured. I’ve used less productive devices all too recently.

I have a 32" monitor and a 27" monitor on my desk. Don’t ask. But although they’re different sizes, they both have the same native 3840x2160 resolutions. The 27" just has smaller pixels.

This is fine 99% of the time. When I’m working away with different windows open on each screen, all is peachy. It’s only slightly annoying that the menu bar on one screen is a tiny bit larger than on the other, but I’m tough. I can live with that.

What I can’t tolerate is that it’s impossible to exactly line up graphics across the 2 monitors. If I flick my mouse cursor from one to the other at the top of the screen – I have the physical screen tops aligned at the exact same height – it flies smoothly over the gap. If I try the experiment near the bottom, the cursor jumps in altitude as it crosses the border because “2000 pixels down from the top” is a farther distance in inches on a 32" monitor than on a 27" screen. And if I dare drag a window from one screen to the other, its position and size change as it crosses over. This will not do.

A friend recently nudged me to look at BetterDisplay Pro, and my life is better for it. It has exactly one feature I care about: the ability to enter a custom screen resolution, which I can then select from the normal Displays system setting. I did these things in order:

• Installed BetterDisplay Pro.
• Looked up my monitors’ specs. One has pixels .1554mm square. The other’s are .1810mm square.
• Computed a new resolution for the smaller monitor. I was running the larger monitor at a virtual resolution of 2560x1440 because at full res I’d need a telescope to read this text. I multiplied those numbers by .1554/.1810 to get a new resolution of 2196x1236.
• Added that to BetterDisplay Pro as a custom scaled resolution.
• Opened Displays and selected the new resolution.
• Dragged windows back and forth between the 2 in unadulterated joy as they’re now the same physical size on both monitors, and both the tops and bottoms of windows exactly line up as they cross over.

Wow, wow, wow. After many long months of mortal anguish, that annoyance is completely gone. My monitors play nicely together as I always wished they would.

Note: Yes, now there’s a slightly different nit, in that it slightly irks me that my resolution has a very strange non-integer scaling factor of 180:103. I don’t care. I can live with it. macOS still sends a 3840x2160 signal to the displays, and the pixels are so tiny that I can’t visibly tell it’s not running at native resolution. Of course, that non-integer scaling might slow the display down very slightly, but this is on an M1 Max system and why pay for the TFLOPS if you’re not going to use them? It’s totally worth the tradeoff.

I think I’m going to upgrade my personal MacBook Air to Sequoia tonight. YOLO!

What sadist invented this captcha?