Colophon

2026-07-08T00:00:00+00:00

This site is built to still work in twenty years. That constraint decided nearly every piece of it: each component has to be rebuildable offline from its source or spec, or be ignorable without taking the site down.</p>

The stack</h2>
The pages you are reading are static HTML, generated by Zola</a> from Markdown files with TOML front matter. There is no database and no application server in the read path. If every tool below disappeared, the content would still be a directory of Markdown files, plain photos in a date tree, and TOML manifests — readable with `cat</code>.</p>`
`Caddy</a> serves the built files and gets its own TLS certificates over ACME. It runs on a NixOS</a> virtual machine on a Proxmox</a> cluster in my basement, in Maine, behind a home internet connection. The whole machine is declared in a flake and is treated as cattle: only the content and photos are backed up, because everything else can be rebuilt from that one file.</p>`

Writing and posting</h2> Posts arrive one of two ways. I write a Markdown file and copy it up, or I post from my phone through Micropub</a> — an IndieWeb</a> standard for publishing to your own site from someone else's app.</p> The Micropub endpoint is a small Rust program I wrote called micropub-rs</code>. Its entire job is to accept an HTTP request and write a file. It talks to no database, holds no state, and can be deleted without the site noticing. Its dependencies are vendored into the repository so that it still compiles when the crates it was built against have long since rotted.</p> Between the file landing on disk and the page appearing here, everything is Perl 5 and systemd. systemd</code> path units watch directories; when a file appears, a Perl script runs. process-photo.pl</code> makes web and thumbnail derivatives with libvips</a>, applies the EXIF rotation and then strips the metadata, and files the photo into a date tree. build-site.pl</code> runs zola build</code> and swaps the result into place atomically, so a broken post can never replace a working site — it just fails and sends me a notification. syndicate.pl</code> posts copies to Mastodon and writes the resulting URL back into the post's front matter.</p> Perl because its backwards compatibility is close to unmatched, it ships in the base system of nearly everything, and a script written against its core modules in 2011 still runs today. Every stage runs by hand from a shell. Nothing in the pipeline requires the pipeline.</p> Photos</h2> Full-resolution originals stay private, on disk, forever. What gets published are derivatives with the identifying EXIF removed — location data from a photograph taken at my house should not be a public fact. Photos live in a dated directory tree with a small TOML file beside each one, which means the collection remains meaningful with this website deleted and no software at all.</p> The design</h2> One typeface: Inter</a>, self-hosted, subset down to the characters this site actually uses. The stylesheet is about a hundred lines. Dark mode follows your system setting and nothing else.</p> There is no JavaScript on any page. No analytics, no tracking, no cookies, no fonts or scripts fetched from anyone else's server. Nothing here watches you read it. The Content Security Policy says default-src 'self'</code>, and it is honest — there is nothing to allow.</p> Standards</h2> Pages carry microformats2</a> — h-card</code>, h-feed</code>, h-entry</code> — so machines can read them without a bespoke API. Writing, notes, and bookmarks each publish an Atom</a> feed. Subscribe with whatever you like.</p> URLs are meant to be permanent. When something moves, a redirect stays behind. Cool URIs don't change</a>.</p> Elsewhere</h2> The site's skeleton — templates, stylesheet, and the pipeline scripts — is public. The content and photographs are not in it. That is the point: the repository stays small forever, and the writing is not a build artifact.</p>



Interests
2026-07-08T00:00:00+00:00
More hobbies, projects, and interests than I have time for. Updated as things change.</p>
Grappling</strong> — BJJ since 2014. Currently focused on No Gi. Would love to own a gym one day!</p>
Homesteading</strong> — Rebuilding my house while living in it. Sustenance farming, rainwater, solar, firewood, woodworking, plus low-power sensors and IoT projects around the property. Self-sufficiency over aesthetics.</p>
Photography</strong> — Sony A7 IV, iPhone. Maine landscapes, family, whatever catches my eye. Working on shadows, lighting, composition, and posing.</p>
Homelab</strong> — Proxmox, NixOS, Kubernetes, low-power servers, networking gear, fiber between the house and barn. I run household apps here and use it to try whatever seems useful or interesting.</p>
Programming</strong> — Programming in general. Systems, tools, automation, backend work, interpreters, game experiments, weird corners of computing. Rust is in the mix, but it is not the whole story.</p>
Game Development</strong> — Mostly Roblox and Scratch with my kid, plus side experiments in Unity, Unreal, SDL, and Bevy. More interested in mechanics and underlying systems than graphics or physics.</p>
Retro Tech</strong> — Old computers, retro game systems, odd operating systems, any machine with a story. Linux since Red Hat 6 and early Slackware. Soft spot for OpenBSD, AmigaOS, and big iron.</p>
Live Music</strong> — Local bands, small venues, and camping at music festivals whenever I can make the time.</p>
Exploring</strong> — Mountains, swimming holes, coffee shops, book stores, hiking, good food, little towns, Common Ground Fair, the occasional ren faire.</p>


2026-02-20T09:15:00-05:00
2026-02-20T09:15:00-05:00
Years ago, I picked up the #bulletjournal system based on random internet comments I stumbled across.
I am not consistent, but it is the one system I keep coming back to when I need to get organized, or when life and work get chaotic.
I do not know why, but it clicks with my brain. There is something about putting pen to paper that helps me think clearly and remember things.
It feels like an intentional practice.</p>
I have not circled back in a while to see how it has evolved or what people are doing with it now.
Maybe there are other cool ideas or systems out there.</p>


Exploring Container Runtimes with Scratch Images
2023-05-29T00:00:00+00:00
It has been a little while since I've done anything interesting with Kubernetes.
Curious about what information a Pod has available to it, I decided to take a
stab at inspecting a Pod's contents; especially what a Pod knows about itself
and the cluster.</p>
Most container images have a lot of files and may declare, or set, their own
environment variables. This would be too much to sift through just to find out
the difference between what a container image's author created and what was
added by Kubernetes at runtime.</p>
While there is documentation on what information is available</a>
from within a Kubernetes pod, there is also a lot of potential
complexity</a>
and the answer may not always be straight-foward.</p>
Essentially, I wanted an easy, minimal container that can simply run an
executable file or script. My goal was to log the filesystem tree and
environment variables. To make things a bit more complicated, I wanted to do
this from my MacOS laptop.</p>
At first, I decided to look at Buildah</a> and the scratch image</a>. It was
an interesting tool I experimented with while working at Red Hat</a> on
Quay</a>. Unfortunately, it (understandably) does not have support to run on
anything besides Linux without some work-arounds</a>.</p>
My next approach was using the infamous Packer</a> application. While I
have never used Packer, I've heard many great things and its one of those tools
that seemed to follow me through my career. While Packer appears to run on MacOS,
it does not</em> support the scratch image</a> I need to
produce a single-file container. That's okay -- the
docs looked great and I'll find some other purpose for it down the road.</p>
After realizing that I just needed the scratch "image", I was curious if I can
simply define a Dockerfile that uses it. Not only is it possible, it is
a documented Docker feature</a>! The answer was right in front of my face. So off I
went to see if this would even work.</p>
All containers, which are the meat of a Pod, keep one or more processes contained; hence the name. When you
define a container image, you need to specify some sort of entry point or
otherwise tell your runtime (e.g. Docker) what to execute. Typically, I could just throw
together a quick shell script and set that as my entrypoint; it would make the
subsequent calls to list the environment variables. I would also be able to copy
or install the tool tree</a> to print the contents of the filesystem as seen
from the container's perspective.</p>
One important thing to note about using Linux containers is that you do not have
access to anything outside of the container unless they're explicitly provided (e.g. mounted volumes and environment variables); this includes dynamically linked
libraries. In summary, if you want to echo</code> or printf()</code> within a container
then you're typically going to bundle a lot of userland</a>. This is why most
container images are large and have a lot of files.</p>
There is a fairly popular language called Go</a> which has a great feature: it can
easily statically compile
code</a> -- no additional
files are required to run its executables. It also provides its own standard
library which is packed full of useful features including logging, reading
environment variables and working with filesystem. Go can also compile cross-platform
executables, which would be pretty useful here since I am compiling Linux software
on my Mac. Quick side note:</em> Docker on Mac is really just using a Virtual
Machine running Linux in the background.</p>
Out of habit, I decided to skip Go's cross-platform compilation and instead take
advantage of a Docker feature I really appreciate called multi-stage builds</a>.
For the uninitiated, its a great way to use one image for building and another
image to run or distribute an application. In this case, I am going to use the
community golang</a></em> (the combination of go</em> and language</em>) image to compile my
program, throw away everything besides the executable, and then run it within an otherwise empty container.</p>
If this is confusing, don't worry -- I am running through this information
quickly and touching on topics that I've spent years learning. Perhaps one day it could make for a good presentation or
talk. Regardless, I believe the following two snippets will make a lot of sense
if you play around with it.</p>
Dockerfile</code></p>
# This is a multi-stage build.
#
# Useful Docs:
# - https://docs.docker.com/build/building/multi-stage/
# - https://docs.docker.com/build/building/base-images/#create-a-simple-parent-image-using-scratch
#
# The first stage, which uses the "golang" image,
# simply compiles the application and stores it in /src/kurtismullins/.
#
FROM golang
WORKDIR /src/kurtismullins/
COPY myapp.go .
RUN go build -o myapp myapp.go

#
# The second stage, based on "scratch",
# copies the executable from the previous container
# and declares that it should be run by default.
#
FROM scratch
COPY --from=0 /src/kurtismullins/myapp /usr/local/bin/myapp
CMD ["/usr/local/bin/myapp"]
</code></pre>
myapp.go</code></p>
package main

import (
	"fmt"
	"os"
)

func main() {
	// Print all Environment Variables
	fmt.Println(os.Environ())
}
</code></pre>
With those two files in the same directory, I used Docker to build and run the
container. The test was a success!</p>
$ docker build . -t myapp
$ docker run myapp
[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=af31fb5e860c HOME=/]
</code></pre>
My next steps would be to add logging of the filesystem and run this within
Kubernetes. I'll save that for another day.</p>
Food for thought: This general approach may be useful when debugging or learning more about other environments where containers are
first-class components such as AWS Lambda</a>, Google's Cloud Run</a>, or even the latest generation
of hosting services such as fly.io</a>. Those platforms have
their own requirements which may, or may not, be compatible with a minimal FROM scratch</code> image.</p>
Happy Hacking!</p>

Update (2026-03-04):</strong> Renamed the title to better reflect the content and direction of its follow-up series.</p>