R. Riley Holmes

I’ve been meaning to upgrade my home network based on some of the lessons I’ve learned deploying NixOS on a VPS. I’ve got a few of these little ProDesk machines that I got on eBay a while back. They’re great if you want some lightweight processes running 24/7. But they were still running Ubuntu! Oof! Time for an overhaul. 1: Deploy Over Network with deploy-rs Based on my experience with a DigitalOcean VPS I knew I wanted to use the deploy-rs model on a local node. Here’s the basic idea: ...

I’ve mentioned the insane power of NixOS’ QEMU-based integration tests. If you're wondering why you (yes, you!) should care at all about this random Linux distro, expand this carat for my summary. For those not in the know, a **NixOS configuration** is a data structure that fully determines a Linux system, from the kernel to the users and the systemd processes. It's a highly reproducible artifact backed by the largest open-source package repo in existence. You can: Put it in version control and use it for your daily driver to make hardware migrations painless Deploy to bare metal VPS with low-resource “build-then-push” tooling Build Docker/OCI containers from it to appease corporate goons Run it in CI/CD pipelines Share it with teammates for identical dev environments Parameterize it to define a cluster of nodes The integration test framework lets you define virtualized nodes with pass/fail conditions on the behavior of the components therein. Furthermore the nodes can be embedded within an arbitrary network topology to test the overall system-of-systems behavior. With the tests defined, they’re wrapped into the very notion of validity for your configuration(s). ...

I’ve consulted several groups helping to optimize their AI agent workflows. This is part of a series on basic agent architecture to help clarify core mental models and avoid costly design mistakes. With model capabilities going parabolic, attention is turning to the control plane (or “harness” - the orchestration layer between your code and your model) as the next bottleneck. It seems to be a source of low-hanging fruits as well as contention from the model providers who have very good reasons to force you to use theirs. ...

I’ve been hesitant to chime in on AI agent architectures other than to say they’re not there yet. The hard takeoff of OpenClaw (an always-on AI assistant with countless integrations out of the box) and Moltbook (a social network for people’s AI assistants to chat) created a compelling public spectacle that clearly indicates growing momentum behind LLM-powered abstractions. Always wary of getting caught up in hype, I’d like to chime in again and try to tease out some common threads behind some of the most interesting and successful experiments. In doing so, I’ll suggest a potential way forward that I’d like to explore. ...

There’s a lot going on in the Nix ecosystem. If you haven’t slogged through the thesis then it might seem downright opaque. This is my attempt at an easy explainer for newcomers. The Tool and the Language Let’s bootstrap ourselves with some circular facts. Nix is a tool for building (or “packaging”) software components using instructions expressed in the Nix language. The Nix language is even able to package the Nix tool (which is mostly written in C++), thus closing the epistemological loop. ...

In the marketplace of developer skills, there’s a certain category that I’m long-term bearish on. They don’t warrant investing free time trying to level up. Devs should limit their exposure to the minimum necessary to do their job. I’m talking about tools like Docker, Kubernetes, and the intricate managed hosting platforms of Azure and AWS. These are tools that help manage social problems caused by scaling organizations to thousands of engineers existing complexity laziness or desire to throw money at a problem rather than solve it While they do solve real technical problems, I’ll argue here that there’s superior tooling for most use cases outside of big tech and legacy systems. ...

Allow me to weave you a tale of progressively stronger decoupling in Elixir. I am working on a library that involves access to graph data, informed by a schema or model. Just to get things rolling I started out with a convention of holding graph nodes in a map: map_graph = %{"node1" => %{"class_id" => "class1", "data" => %{ "testProp" => "value" }} %{"node2" => %{"class_id" => "class1", "data" => %{ "testProp" => "value2" }}} node = map_graph["node1"] value = node["data"]["testProp"] It’s quick, dirty, and gets the job done for proof-of-concept purposes. Clearly it’s inadequate for other data access patterns we’d like to be able to support. We can write transformation routines against this structure, but they won’t be able to work with anything else. ...

Judging by the activity of marketing hypemen and growth hackers, it seems “Agents” are a Big Important Thing. I can’t scroll 2 posts on social media without being offered a course or a low-code service. As usual, the grifters are trailing the edge by a few years. If you try to pin down a definition, it seems to boil down to “a distributed, fault-tolerant software system… with LLM calls”. So that means we just need to throw Claude on the BEAM. Easy enough! For those willing to read some Elixir code I direct you to a pair of excellent blog posts from 2023: ...

The inordinate usefulness of Nix really sinks in when you realize that it allows you to define a single piece of unified infrastructure for handling all the different parts of the software lifecycle. Furthermore, this infrastructure doesn’t even need to be project-specific. For a given class of projects, the “holy grail” Nix flake template defines all the following: All the dependencies, pinned in the flake.lock and updatable with nix flake update. A dev environment accessible with nix develop. A package derivation that encapsulates the build process in a nix build command. A module that exposes the app as a configurable system-level service that can be leveraged in integration checks with nix flake check. With these things in place, activities that traditionally create overhead for developers (environment and deployment) are abstracted and standardized. And even though other tools solve similar problems, none of them achieve the universality of the Nix model. That’s because the most natural and complete description of software packaging is as pure functions over store paths. But in this post I’m focusing on convenience. The correctness of Nix, and the fact that correctness leads to convenience, are topics for a different post. ...

While my instinct is to use Phoenix for everything, I had to admit it’s overkill for a personal website. I’m not here to flex complex backend integrations or live features. I’ve heard good things about Hugo, so maybe it’s time to try it. I will describe how Nix and deploy-rs allowed me to get framed out and deployed in one short and painless sitting! A quick google search yielded a serviceable flake for a Hugo dev environment. So I just ran nix develop, hugo new site and then had a Claude agent throw in some placeholder content. 5 minutes later I had something serving on localhost. ...