Craig Weber

For hardware, I settled on Raspberry Pi 4Bs. They support up to 8GB of RAM (enough power to run the k3s master nodes) and USB 3.0 for fast external SSD I/O. The only downside of the 4Bs is that they require more power than the 3Bs, and the same multiport USB power supplies that could support a 3B cluster couldn't support a 4B cluster. To solve for this, I decided on PoE hats and a PoE switch. This halves the number of cables that need to be run to each Pi, which makes the Pi cluster that much more enjoyable and easy on the eyes.

For whatever reason, macOS Catalina and Big Sur were both tinting my external monitor pink. Some research indicated that it had to do with the color mode, notably that I needed to force RGB. MacOS's UI doesn't give the user the ability to change the color mode directly, so you have to hack around the display profile files directly.

This post and its comments from 2013 seem to be the authoritative guide on forcing RGB mode; however, these steps (and the variations found in the comments) make you do a lot of things, including disabling the System Integrity Protection (basically the stuff that prevents even the super user from changing certain files and directories), booting into recovery mode, changing boot files (which can put your system into a boot loop, as I discovered the hard way), and a number of other dangerous, arcane things.

Fortunately, I found a sequence that is much safer and easier (tested on both Big Sur and Catalina on two distinct MacBook Pros):

As I alluded to in my last post, I've finally decided to pull the trigger and build my own homelab: a personal computing environment for playing around with new tools and approaches for developing or operating software, including software that is personally useful. Read More

I've recently been working on my Raspberry Pi Kubernetes cluster. I also use Tailscale for my home VPN (because it's performant and absurdly easy to setup and configure). I wanted to run Kubernetes services on my VPN using private DNS names (e.g., foo.local) and addresses from the Tailscale address space (e.g., 100.*) as opposed to the host network address space (e.g., 192.168.*).

The new Go generics proposal and playground gives us something to play with. Here's a sketch of what a basic iterator library could look like. It's based on function types instead of interfaces; I think this gives better ergonomics than interface-based designs, especially if the proposal drops its seemingly arbitrary restrictions for method types.

I'm not sure about returning a pointer to the type as opposed to a (T, bool) tuple. In particular, I suspect this will cause unnecessary allocations, but I haven't tested at all.

I use GitHub for my work and personal projects with different profiles for each. Because it's a good security/privacy practice, each profile has its own distinct SSH key. However, this causes problems because the git CLI will always try to use the first SSH key that maps to the github.com domain even if that key has no permissions for the target repository. The other more straightforward problem with multiple accounts is that the GitHub.com browser cookie asserts that you are only logged into one account at a time.

My solutions for these problems are direnv and Firefox Containers, respectively. These use cases are straightforward applications of these technologies, so I'm not claiming any innovation here, but rather it took me a long time to identify these solutions, and I hope this saves others some time. If you're not familiar with these tools, read on for details.

There's an ongoing debate among infrastructure-as-code practitioners between configuration languages like YAML and HCL and using "real programming languages" (including domain specific programming languages) to generate configuration. The debate is going very poorly because there is a lot of confusion about the "real programming languages" position, so I want to correct some of the common points of confusion ("myths") so the conversation can focus on more substantial concerns.

Another year, another blog update. BitBucket is deprecating their Mercurial support, and while I really do appreciate Mercurial, it's just easier for me to keep everything in GitHub than trying to find another Mercurial provider. Also, GitHub seems to be improving at a pretty rapid pace. So voila, this blog is now hosted on GitHub. This includes my pet static site generator, neon which is used to generate this site. Read More

I finally got around to automating the publishing of this blog. It hasn't been a high priority, since I only post a couple of times a year, but it's always bothered me that something that is such an ideal candidate for automation hasn't been automated. Anyway, I finally did it and I want to describe the setup in case it's helpful for anyone looking to do the same.

NOTE: If you're here for the TL;DR, skip to the bottom.

A few months ago I built out some monitoring infrastructure at work using Go. I deployed it to ECS (a Docker orchestrator, functionally similar to Kubernetes), and for fun I decided to see how minimal I could make the image. I've used Alpine base images before (which weigh in at about 5 MB and usually another 5 MB for a small Go binary), but being that Go advertises itself as requiring only a Linux kernel (most programming languages depend on an interpreter, a VM, and/or system libraries--the latter abstract over kernel functionality and sometimes provide a stable interface to the kernel), I wanted to see how true or practical this was, and I wanted to better understand the things that I was taking for granted by using distros.

As a matter of context, Docker has a special base image called scratch which is empty--an application running on a scratch base image only has access to the kernel (at least to the extent that containers provide isolation).