So, I’ve been working on an internal Homebrew tap, and have been trying to get the automatic bottle packaging actions working. There’s a good blog post that describes the outcomes, but the Homebrew project supports internal taps on a best effort basis, so this doesn’t dig into all the issues you might encounter when setting it up internally. By far the most time consuming issue I had was getting the git clone to find git-lfs.

So I decided to build a local NAS system to store music (since I’m worried my CDs are starting to degrade), and to do Time Machine backups (last backup 2018!). Despite never having used FreeBSD before, I am planning to go with FreeBSD for this since I want to use a native well-integrated ZFS implementation. Anyway, the first issue I’ve hit is that I need RealTek network drivers, but they are not included in the installer kernel.

So, every now and then when I do something in AWS, I mess it up. One problem that I give myself every now and then is breaking SSH access to an EC2 instance. In that case, you need some sort of out-of-band access to go and fix the SSH configuration. EC2 instance user data is generally set to be a shell script that cloud-init runs once when the instance is created.

I started using Dagger this week, and if you have any sort of build and test system based on shell scripts and Dockerfiles, Dagger will be a big improvement. This post documents how to export a container image that you build in Dagger to your local Docker instance. This process is described in the Dagger documentation but I needed to go one step further and tag the image that I exported.

Normally, it’s common to configure multiple SSH keys git Git access, but there are situations where you need to use a specific key. In this case, you don’t want to let ssh just choose the first working key, you want it to use a specific SSH identity. The use case that I had was that for a certain set of source repositories, I wanted to use a particular key because that specific key was approved by a particular GitHub organization.

In the KallistiOS ecosystem, there are basically two ways to build Dreamcast programs - use the CMake toolchain support, or use the compiler wrapper scripts from the KallistiOS source tree. I was interested in the latter, but they end up depending on a large number of environment variables, which are traditionally sourced through $KOS_BASE/environ.sh. Although it’s not really a big issue to have all those environment variables, I wondered whether there was a cleaner approach.

I’ve spent some time working on a Homebrew tap for Dreamcast development tooling, and wanted to write a little about the tricks I used in creating formula to install the Dreamcast compilation toolchain. First, the Dreamcast toolchain is actually build and installed by the dc-chain package from the KallistiOS repository. dc-chain has 3 phases - download, unpack and build. The download phase is done by the download.sh script, which downloads the source archives of the toolchain components (gcc, binutils, newlib, gdb) for SH4 and ARM architectures.

Way back in the last century, I bought a Sega Dreamcast. One of the reasons that I like it (apart from some great games), was that there was a burgeoning homebrew development scene for it. I went and bought the various bits of hardware I thought I needed to get going, but ended up never doing anything, and it all sat in storage for 20 years. Recently, I unpacked everythying and decided to figure it all out.

This is probably something lots of other people have tried and burnt themselves with, but anyway, this time it’s my turn. The goal is, given an arbitrary protobuf, can we write an API that applies default values to it? Normally we would create a prototype protobuf object with the defaults and merge our current object into it, updating the prototype object with current values. However, in Go, this would erase the type information and mean we would have to do some ugly casting (it’s easy to avoid this in C++ by using templates).