Clinton Boys

Building an OPNsense router

Sun, 19 Apr 2026 00:00:00 +0000

Building an OPNsense router

April 19, 2026

The first thing to understand when building your own router is what is usually meant by the word “router”. Your ISP will give you a (usually white) box with blinking lights which they call a router but which usually has several functions in the same package, all typically with a very low level of configurability:

A “gateway”, which sits between the wider internet (WAN) and your LAN, hands out IP addresses to your local devices via DHCP, and handles network address translation (NAT), the process that brokers between external IPs in the public internet and local ones in your LAN. More advanced gateways will also let you do things like tunnel all traffic through a VPN.
Basic “firewall-like” functions: blocking potentially harmful traffic and basic content filtering.
A Wi-Fi access point
A switch, allowing other devices to connect to it directly by Ethernet

In previous posts I wrote about how I decoupled the Wi-Fi functionality and split the network topology up with a bunch of switches and a trunk line between my house and office. My goal was to also have a router which would allow me to properly do all these more advanced networking things I had started to hear about, and to properly support the 10Gbps and VLAN functionality I had built into the network.

Router on a stick

In the previous post I wrote about the network topology I decided on, which called for a “router on a stick” in my home office. This means the router is connected to a switch somewhere in the network like any other device, not necessarily at the “bottle neck” point (i.e. directly connected to the fibre modem) where it would be in most consumer setups. The network is then segmented using VLANs in a way that traffic flows through this router in both directions on its way to and from the WAN or between LAN devices.

I wrote a lot more detail about VLANs in the previous post, so you can read about my decisions there. From the router’s perspective, it just had to support VLAN tagging to be able to support the network topology I had built out. Most consumer routers don’t, but from what I read it seemed like a very basic feature of any router’s operating system once you go one step beyond consumer.

OPNsense

So I spent some time researching what it would mean to “level up” from my ISP’s router to something better. There’s a few options, and the simplest is to buy a dedicated “routing appliance” or “gateway” like the UniFi Cloud Gateway series from Ubiquiti. These are solid options, they are very plug and play and give an Apple-style “it just works” experience. They are painfully expensive however.

I read a lot about OPNsense in various places. It’s open source, based on the venerable FreeBSD Unix-like OS, and has basically every feature you could possibly ask for when configuring your network. It is itself a fork of an older project, pfSense, which is also still in active development and it seems like there is quite a split in the homelab community regarding which is better. I went with OPNsense in the end because I read a few tutorials from folks I trusted who seemed to think it was the way to go.

OPNsense will give us a very powerful setup allowing us full control over NAT, DNS, DHCP, VLANs, firewall rules, VPNs and a lot of other things, including extremely detailed monitoring of all traffic on the network. If those things are all meaningless to you, they were mostly meaningless to me as well before I started on this journey, so hopefully I’ll be able to explain it all below!

Hardware

First, I had to decide what hardware I would use for my router. Ultimately, a router is just a computer with a very specific use case, so you can really use any computer as a router. Most ISP-provided routers are very low-powered computers with some whitelabelled, detoothed Linux operating system on them.

You can buy a small form-factor computer like a NUC, or a dedicated “routing appliance” like the ones from Protectli, but the easiest way is just to buy an old, refurbished enterprise desktop computer, preferably in a small form factor, and then install OPNsense on it.

The hardware I ultimately settled on was a Dell OptiPlex 3060 in the “small form factor” (SFF). This is significantly smaller than a “full-size” tower desktop, but bigger than the “micro form factor” computers, which are too small to take PCIe cards, and I wanted to install a 10GbE network interface card (NIC).

Specs

Intel Core i5-8400 (6-core, 8th gen)
16GB DDR4 RAM (overkill)
256GB NVMe
Intel X540-T2 dual 10GbE NIC

The first NIC I bought didn’t work. I bought a new one from Amazon but it turned out to be some cheap Chinese imitation one and not a genuine Intel one (I was buying a lot of parts at the same time so I was a bit distracted), so the Dell didn’t recognise it when I installed it. I just returned it and ended up buying a used genuine Intel one for less.

Putting the card in was very straightforward, and once it was in it was just a matter of turning the machine on and installing OPNsense.

Using refurbished consumer hardware feels a bit uncomfortable: how long is it going to last? Thankfully there’s an easy way around this: you just change your mindset and treat your router like it’s a commodity which could die at any moment and plan for that contingency. OPNsense lets you easily download the full configuration as an XML file, so if the machine does die you can just swap it out for a new one, install OPNsense, upload the XML file and you are ready to go. So the bottleneck really becomes the time it would take to order and receive a new machine and NIC, meaning one day I might be happy I kept my ISP’s router in the cupboard instead of ceremonially smashing it to pieces¹.

Installation

The actual installation of the OPNsense operating system is straightforward:

Download the installer ISO from the OPNsense page.
Flash to a USB drive on MacOS (I used dd which seems to be the standard way to do it if you’re comfortable with the terminal)
Boot (hold F12 while booting to boot from the USB drive) and follow prompts
Assign interfaces (WAN/LAN)

The only gotcha I encountered was needing to disable Secure Boot in the BIOS before installing. Secure Boot only allows bootloaders signed by a “recognised authority” to run, and FreeBSD’s, and by extension OPNsense’s, bootloader isn’t signed. Some major Linux distros (Fedora, Debian, Ubuntu, etc) get their bootloaders signed, but FreeBSD didn’t (a combination of open source resources and philosophical resistance to Microsoft’s control of a critical piece of security gatekeeping), so the machine will just refuse to boot the installer if Secure Boot is toggled on in the BIOS. Essentially you’re trading one security mechanism for another: firmware-level boot verification for an OS you chose and fully control. For a homelab router I think this is a perfectly reasonable tradeoff.

VLANs

The first thing I needed to do was configure the VLANs. Since I’d set them up on the switches, nothing would work until the router was set up to be compatible with them. The router config is quite a lot simpler than the switches, and I didn’t run into anywhere near as many issues as I did when configuring the switches. Basically you just define virtual “interfaces” for each VLAN, and give the router a dedicated IP at each interface (e.g. 192.168.20.1 on the “trusted LAN” VLAN which has ID 20).

DNS

The Domain Name System (DNS) is the way that IP addresses get translated back and forth to URLs. There are global DNS servers, which are what allow you type google.com in your browser address bar and then forward you to the IP address of Google’s servers, like a giant global phone book. In your LAN, you can also use DNS to do similar things, so instead of remembering that your Plex server is located at 192.168.20.15:32400 you can just type plex.local into your address bar.

Setting this up requires three things:

Decide what your domain will be. If you’re just going to access it from home, it can be pretty much anything so long as it doesn’t conflict with global DNS. If you want to be able to access your stuff at the same address locally and remotely, like I did, you’ll need to register a domain and then use that here. Later I will explain how to set up the external access to the same domain.
Setting up your DNS overrides in OPNsense. This is a list of things you would like the DNS to handle, and you tell the router to send them all to your reverse proxy (see next point).

A reverse proxy, like NPM, which stores the explicit mapping between domain and IP:port, as well as some other technical stuff like SSL certificates.

DHCP

Dynamic Host Configuration Protocol (DHCP) is a server hosted by your router that hands out IP address to devices that connect to it. The same sort of server sits on your ISP’s equipment in one of their networking centres and hands out a public IP to your modem.

When connecting your most commonly used devices, like always-on servers, entertainment devices, you may want to configure them with static IPs, meaning they will always be found at the same address whenever they connect. But you don’t want to do this for every single device that needs to connect to the internet - phones, laptops, internet-connected fridges. So DHCP will just give them one dynamically, and in a configurable router OS like OPNsense, you can configure the range of IPs that different interfaces can hand out over DHCP. This lets you set up a very nice correspondence between addresses on a specific subnet, e.g. the range 192.168.20.100 to 192.168.20.200, and the VLAN with ID 20. You can then use 192.168.20.1 to 192.168.20.99 for the static IPs in that VLAN.

Firewall

Once you have the VLANs and DHCP set up, you’ll want to set up firewall rules that actually “implement” what you had in mind for the VLANs. For me, my 20 VLAN was a “trusted LAN”, so I wanted to exclude access to it from all my other VLANs (guest, IoT). The IoT VLAN (30) can only access the internet and not any of the other VLANs. And the “DMZ” VLAN (50) is also restricted to only access the internet. The AI DMZ (60) has a few additional restrictions: I want to be able to choose the specific websites on the internet it can access, to really make sure any agent I “set loose” there is tightly controlled by me. I also plan to use 80 and 81 (and maybe other 8x VLANs) in the future for VPNs.

VPN

One of the things I was most excited about with OPNsense was the ability to tunnel traffic through a VPN at the router level. I have a PrivateVPN subscription with endpoints in countries I used to live in, and I wanted to be able to route my Apple TV through one of them on demand so I could access that sweet geo-restricted homesickness-inspiring content.

OPNsense has WireGuard built in (it used to be a plugin but it’s been part of the base system since 25.x). Setting up a tunnel is straightforward: you create a “local” WireGuard instance with your client private key and tunnel address, then add an “endpoint” with the server’s public key, address, and port. Do this for each country you want to connect to, enable WireGuard, and you have your tunnels.

My first attempt immediately broke the internet for every device on the network. The problem was AllowedIPs = 0.0.0.0/0 on the endpoint, which tells OPNsense to route all traffic through the VPN tunnel, not just the Apple TV’s. The fix is to tick “Disable Routes” on the local WireGuard instance so it doesn’t override the default route, and then use policy-based routing to selectively send traffic through it.

I initially set this up with a firewall rule that matched the Apple TV’s source IP and routed it through the VPN gateway. This worked, but toggling between VPN countries — or turning VPN off entirely — meant logging into OPNsense and fiddling with firewall rules, which is not something I want to be doing every time I sit down to watch something.

The solution I eventually want to implement is to give each VPN its own VLAN: for example in my case 80 for Sydney and 81 for Tel Aviv. Each VLAN will get its own interface, DHCP range, and firewall rules that force all traffic through the corresponding WireGuard gateway. On the physical switch then, I will be able to set up three ports as access ports: one on VLAN 20 (my regular LAN with no VPN), one on 80, one on 81, and patch them to labelled ports on my patch panel. Then toggling VPN is a physical action: I move one patch cable on the front of the panel. No logging in, no firewall rules to toggle, just move the cable and the Apple TV picks up a new IP on the right VLAN.

Removing my ISP router

I had done all this with my ISP router still plugged in and sitting in its original place between the ONT and one of my new switches. But with OPNsense handling routing, NAT, DHCP, DNS, and firewall, the ISP router is now redundant. With it still in the path, you end up with “double NAT”: the ISP router translates your traffic once, then OPNsense translates it again.

In theory once everything is set up, you should be able to just remove your ISP router and plug the ONT directly into the switch. In practice, I encountered two problems. First, the ONT caches the MAC address of whatever’s plugged into it, so after swapping cables you need to power cycle the ONT and wait a minute or two for it to come back up and recognise the new device. Second, OPNsense itself can hold stale DHCP leases from the old connection — if you’re still seeing a 192.168.x.x address on the WAN interface after the swap (instead of the public IP from your ISP), releasing and renewing the lease (or flushing the lease file from the shell) should sort it out.

Once it’s done, you should see a public IP on OPNsense’s WAN interface, single NAT, and full control over your network edge.

Don’t do this of course, you are contractually obliged to return your ISP’s equipment at the end of your contract. ↩︎

lit: Version control with good vibes

Sun, 15 Feb 2026 03:52:30 -0500

`lit`

February 15, 2026

Like everyone else with a keyboard and an anxious interest in their future as a programmer, I’ve been using AI agents to write a lot of code recently. You talk to Claude or Cursor and code appears and it mostly works, you fiddle with it a bit to get it right, and you push it. I have mixed feelings about the results, about what it means for the future, and most importantly for how it makes me feel, but this post isn’t yet another one in that vein.

Using agents means things are getting faster and crazier on the code generation side, but on the code review side, the bottlenecks preventing this generated code from actually making it to production, seem to be largely intact. Even though everyone (including me last year) seems to like the analogy of LLMs being to compiled programming languages what compiled languages were to assembly code, there isn’t any tooling in place to actually make this happen.

People are not accountable for the code they generate. Their intent when generating the code is not recorded, and is lost in the vibes. It’s a particular shame because the natural language prompts encode this intent quite well: well enough for the LLM to combine it with its training set and produce the code for you.

So I had the idea for a tool, or maybe it’s better to think of it as a “thought experiment” because the workflows are still not entirely clear to me yet. It’s heavily inspired by git, and it tries to make this “the prompts are the source of truth, the code is just an artifact” thing a reality. Whether I actually want this reality, or whether it just bringing us closer to an apocalypse of meaning, is a different question altogether. But it was fun to build.

lit

lit is a version control system that treats LLM agent prompts as the source of truth for software projects. Generated code lives in a code.lock/ directory (“lockdir”) and is committed alongside prompts in git. The code generation itself is also handled by lit.

The name is a working title. It’s meant to simultaneously evoke git (its spiritual predecessor and storage layer), the word “literature” (natural language as the source of truth), and just generally “vibes”, because… you know. Unfortunately it’s also the name of a well-known web framework with 21k GitHub stars, so it’ll probably have to change.

GitHub | Spec | Demo

Here’s what a prompt looks like in lit:

markdown

 1---
 2outputs:
 3 - src/models/user.py
 4imports:
 5 - prompts/models/base.prompt.md
 6---
 7
 8# User Model
 9
10Create a SQLAlchemy model for a User with fields:
11- `email`: String(255), unique, indexed, not null
12- `hashed_password`: String(255), not null
13- `full_name`: String(255), nullable
14- `is_active`: Boolean, default True
15
16Use the Base class from @import(prompts/models/base.prompt.md).
17
18Include proper `__repr__` and a relationship to items.

The frontmatter at the top declares what files the prompt generates and what other prompts it depends on. That @import() is the key idea: lit builds a dependency DAG from the imports and generates code according to this graph: when prompt B imports prompt A, lit generates A first, then feeds A’s generated code as context when generating B.

Here’s what the structure of a lit repo looks like:

my-project/
lit.toml # Config: language, framework, model
prompts/
models/user.prompt.md # Source of truth
models/base.prompt.md
api/users.prompt.md
code.lock/
src/models/user.py # Generated artifact
src/models/base.py
src/api/users.py

Why `code.lock/`?

The key insight, if there is one, is that LLM-generated code has the same problem as dependency resolution: the output is non-deterministic and expensive to produce, so you want to pin it. So code.lock/ is generated and committed to git as an artifact. It’s a “lockdir” containing your entire codebase, and you are encouraged not to look at it, the same way you never really open your package-lock.json file or uv.lock file, and it’s not such a big deal if it gets deleted (except here regenerating it will cost actual money in the form of LLM tokens).

Using `lit`

I don’t think people are going to be editing .prompt.md files in an orderly fashion instead of iterating live with an agent. Rather, lit is for what comes after that, when code needs to be maintained by a team, reviewed, and understood months later.

There are three workflows where I think this matters.

Post-hoc formalization of vibecoding. Vibecode something freely, and once it works, write the prompt that describes the intent: what this code should do, what assumptions it makes, what “contract” it fulfills. Then run lit regenerate to verify the prompt actually reproduces the code. This command actually handles the generation of the code (integration with LLMs). Now you have a reproducible (insofar as LLMs can be) spec committed alongside the code.

This feels to me sort of like writing tests after prototyping something.

# After vibe-coding a feature that works:
vi prompts/auth/login.prompt.md # Describe the intent...
lit regenerate # Verify it reproduces.
lit diff --code # Compare generated vs hand-written
lit commit -m "Capture login intent"

Prompt-driven changes. Requirements change. Instead of asking an AI to “update this code” and hoping it gets it right, you change the prompt - the spec - and regenerate. The diff shows the change in intent, not just the change in code. Code review becomes review of requirements.

This is where the DAG becomes really useful. I added two lines to a user model prompt in the demo project and ran lit diff --summary:

=== Changes Summary ===
Prompts:
~ prompts/models/user.prompt.md (+2 -0 lines)
Impact (prompts that will regenerate):
-> prompts/models/user.prompt.md
-> prompts/models/item.prompt.md (imports user models)
-> prompts/schemas/user.prompt.md (imports user models)
-> prompts/api/users.prompt.md (imports user models, user schemas)
-> prompts/schemas/item.prompt.md (imports item models, user schemas)
-> prompts/tests/test_users.prompt.md (imports user schemas)
-> prompts/api/items.prompt.md (imports item models, user models, item schemas)
-> prompts/tests/test_items.prompt.md (imports item schemas, user schemas)
8 prompt(s) will regenerate, 4 unchanged

Prompts as documentation. A new developer reads prompts/ to understand intent, not just implementation. Each prompt file is a spec for what its generated code should do. The DAG shows how components relate.

lit debug dag # See how prompts depend on each other
cat prompts/api/users.prompt.md # Read the spec for the users endpoint

The demo

I built a complete CRUD API app using lit to demonstrate the idea. Twelve prompts generate the FastAPI application: models, schemas, API modules, test suites, database config, and package structure. Each prompt is 15–30 lines of natural language. The generated code is a working API with proper relationships, validation, pagination, soft deletes, and test coverage.

The entire application is reproducible. Clone the repo, set your API key, run lit regenerate, and you will get the same app.

Under the hood

When you run lit commit -m "message", it parses all the prompt files, builds the dependency DAG, detects which prompts changed since the last commit, computes the regeneration set (changed prompts plus their downstream dependents), and then generates according to the graph. Each prompt gets assembled into an LLM request with the project config, the generated code of its imports, and the prompt body. The LLM responds with file delimiters and lit parses the output into code.lock/.

There’s input-hash caching a la Bazel (SHA-256 of prompt content + imported code + config) so unchanged prompts are skipped. There is also basic manual patch support, because sometimes you need a one-line fix and regenerating and burning tokens is overkill. lit saves your edit as a patch and reapplies it on top of future generations.

Generation metadata is committed alongside everything else: tokens used, cost, model, a snapshot of the DAG at generation time. You can run lit cost --breakdown and see exactly what you’re spending per prompt:

=== Cost Summary ===
Total: $0.42 across 3 commits
Per-prompt breakdown:
prompts/api/users.prompt.md $0.08 (2,431 tokens)
prompts/api/items.prompt.md $0.07 (2,198 tokens)
...

Try it

bash

1git clone https://github.com/clintonboys/lit
2cd lit
3cargo install --path .
4
5export LIT_API_KEY=sk-ant-...
6mkdir my-project && cd my-project
7lit init --defaults

Or look at the demo: lit-demo-crud.

The full spec is in SPEC.md — nine sections covering the storage architecture, generation pipeline, DAG resolution, cost tracking, and design rationale.

It’s about 7,600 lines of Rust with 128 tests, and was itself largely vibe-coded with Claude. I did write the README and this blog post by hand though.

Limitiations of v1

This is a proof-of-concept that I put together in a couple of days. It works and it’s interesting but it has a few major limitations, the main one being that currently every prompt must explicitly declare the files it will generate in its YAML frontmatter:

outputs:
- src/models/user.py
- tests/test_user.py

This means the prompt author needs to know the output file paths before the LLM generates anything. It works well when you’re formalizing existing code or when you have a clear project structure in mind and are OK with prompts and the files they generate being in 1-1 correspondence. But it is a lot more rigid than how most people actually use agents to write software.

This is a deliberate trade-off to get a prototype working. Declaring outputs up front is what makes the rest of lit work cleanly: the DAG can be resolved before generation, caching can be content-addressed, and no two prompts can accidentally claim the same file.

An obvious way to address this is “two-shot generation”: a cheap first pass asks the LLM “what files would you produce for this prompt?”, and lit records the answer as a “manifest”, which is also pinned in the repo. The second pass does the actual generation against that manifest. This preserves all the benefits of knowing outputs ahead of time (DAG resolution, caching, conflict detection) while removing the burden from the prompt author.

For a tool like this to be actually used in production for large-scale code bases, maybe it would need to be aware of the AST of the code base in some way? I think that could be an interesting, but obviously much more involved, direction.

Please don’t hesitate to get in touch if you are interested in lit or you want to discuss the ideas here further: I’d love to hear from you!

Upgrading my home network to support VLANs and 10Gbps

Sat, 07 Feb 2026 00:00:00 +0000

Upgrading my home network to support VLANs and 10Gbps

February 7, 2026

After improving my Wi-Fi setup, I started to focus on a wider rehaul of my whole home network. I knew I wanted to accomplish a few things:

remove my ISP’s router and replace it with a custom router, located in my home office instead of the networking cupboard in my living room
support VLANs for better security as I slowly incorporate more home automation
support 10Gbps networking for speed and future proofing
separate my NAS storage from the compute layer by building a new server and migrating all hosted services there

The first item on the list was actually the biggest constraint for me, and it led me down the rabbit hole of discovering VLANs in the first place: I had no idea what they were and that I needed them before I started researching. Don’t worry, if you don’t know what they are either I will do my best to explain it very carefully below.

My first thought was: the fibre enters my house in my living room, so how can I have my router in the office? I figured it meant the connection would need to first go into the office, through the router, then back out to the living room across a second cable. I spent a bit of time looking into how to lay additional cables, and then realised it was going to be extremely expensive and annoying, so started trying to understand whether it was possible to use a single cable to accomplish what I wanted.

It was in this state that I turned to the r/homelab subreddit, which is a really great source of information (and photos of peoples’ gear that will make you jealous). I asked a question about how to accomplish what I wanted, and received an answer suggesting that I check out “VLANs” and “router on a stick” topology. Apparently this would give me a way to tag packets (or more accurately, frames) entering my network through the living room networking cupboard as WAN, have them automatically be forwarded to the router in the office, and then routed to the correct part of my network, which could be a device in the office, or back in the living room again.

In order to get this to work, I discovered, I would need to upgrade my switches not just from 1Gbps to 10Gbps, but they would also need to be managed: rather than just a simple switch that “splits” the network and provides additional ports, managed switches give you a lot more configurability, crucially in my case the ability to define VLANs, which will give the packet-tagging setup that will allow my topology to work.

Note

A note before we get started about the actual build order. As you will note below, I needed a VLAN-compatible router in order to change the network, so I actually did the router build and the network changes at the same time. I’ve split the posts up into two, so take a look at the next post for lots of details on my OPNsense router build and configuration.

VLANs

When you’re learning something complicated and (to me at least) new like networking, it can take a while to understand that there is a single term for something that you need. If you don’t know the word, you can spend ages poking in the wrong directions, but once you learn it you suddenly realise that your problem has been solved for decades and is so common that it has an industry standard name. The CAT6 cable between my home and garden office carries a trunk link: a single physical connection between two managed switches, configured to carry traffic from multiple VLANs simultaneously. Each frame travelling along the cable is tagged with its VLAN ID using the 802.1Q standard, so the switch at either end knows which VLAN it belongs to and can forward it accordingly.

A “VLAN” then requires several different things working in tandem:

switches which know how to tag and untag frames and transfer them around the network
a router/firewall which knows which IPs correspond to which VLANs, and can set rules for communication between them (e.g. VLAN $x$ cannot access devices on VLAN $y$)
a table like the one below, which probably sits in the network designer’s head, or their documentation system of choice, which decides which devices get assigned to which VLANs

	Trunk
	1	Management
	10	WAN
	20	Trusted LAN
	30	Untrusted IoT
	40	Guest LAN
	50	DMZ
	60	AI DMZ

After quite a bit of research I settled on the seven VLANs in the table above. The numbers are the actual tags used when things are going around the network, but you can also use a very common and genius mnemonic of setting the devices in each VLAN to receive (static or through DHCP) IPs from the subnet 192.168.{$ID}.0/24. (Unfortunately this doesn’t hold up so well in IPv6 land where IP addresses are like sand).

Management VLAN (1)

The management VLAN will just have my router, and my three core managed switches, which all have a nice web UI for management. After a lot of research I ended up buying the following switches.

Type	Switch	1Gbps	Multigig RJ45	10Gbps SFP+
Managed	2x Zyxel XGS 1250-12	8	3	1
Managed	MikroTik CRS305-1G-4S+IN	1	—	4
Unmanaged	TP-Link TL-SG1005P (PoE)	5	—	—
Unmanaged	TP-Link TL-SG1008MP (PoE)	8	—	—

This setup gives me a combined total of 30 x 1Gbps RJ45 Ethernet ports (of which 13 are PoE), 6 x “multigig” RJ45 Ethernet ports, which support 1/2.5/5/10Gbps, and 6 x 10Gbps SFP+ ports. So that’s 42 ports in total, and I have an additional 3 dumb 1Gbps switches with 5 ports each from my old setup if I ever need them. So I don’t think I’ll be buying a switch again in the near future.

The Zyxels were great buys. They’re sturdy, good quality, with a simple management interface that gives you exactly what you need and nothing more: it seems like if you are a “prosumer” and you want a managed switch, you pretty much need two features: VLANs and link aggregation (LAGG), which lets you combine multiple physical Ethernet links into a single virtual link for additional bandwidth and redundancy.

You can see above my VLAN configuration for the Zyxel switch in my living room. The first port has my Apple TV connected (VLAN 20) and the second my Hive hub (VLAN 30). Port 10 has the trunk line connected, and Port 9 is connected to the ISP’s ONT for the WAN link. If you look at the switch configuration screenshot above, green means untagged and orange means tagged, which I was mentally thinking about the wrong way around for a while at the start, leading to some problems (see below for some more details).

The MikroTik, which I used to add more 10Gbps ports in my office where I have all my 10Gbps capable devices, is a lot more capable and consequently a lot harder to figure out how to use. It even has a CLI!

SFP+ was new to me. It’s a different interface to RJ45 (which is used synonymously with “Ethernet” by most folks) and it’s a bit more flexible but trickier to use so hasn’t gained as much exposure and usage, except in 10Gbps and beyond where its benefits start to outweigh its drawbacks. I’ll write some more in a future post about how I set up the SFP+ ports with the right modules and fibre optics.

WAN VLAN (10)

I defined a VLAN for my WAN traffic. Like I showed in the diagrams above, this lets WAN traffic travel along the same trunk as LAN traffic in either direction, and be handled correctly by OPNsense (more on how to set this up in OPNsense in a future post).

Trusted VLAN (20)

All the main devices in my house that I want to be able access the main LAN, and that I trust, are assigned IPs in this VLAN. This includes my and my wife’s laptops, the NAS, our Apple TV and in the future the Proxmox server I want to build. The main Wi-Fi network used by all our phones and computers is set up through the UniFi controller to be assigned to this VLAN as well.

IoT VLAN (30)

Our Hive Hub, which controls the thermostat in our house, as well as some cheap AliExpress IoT stuff (another thermostat to control my office heater, some smart switches and plugs) is no longer on the same network as all our trusted devices. These sit in their own VLAN, which has access to the internet but not “sideways” to the trusted LAN. I had to set up a second WiFi network with a different SSID on this VLAN, and make sure the connection to the PoE switch that connects to the APs (port 8 in the image above) is also a trunk line carrying the 20, 30 and 40 VLANs (see below).

Guest VLAN (40)

Similarly, there’s no reason guests need to access the files and media we store on our LAN devices. So I set up an additional Wi-Fi network in this VLAN that guests can access. Like the IoT VLAN, it can access the Internet but has no access to our trusted devices. It also has a bandwidth limit.

DMZ and AI DMZ VLANs (50 and 60)

The last two VLANs are even more “tightly secured”. Here I have very tight firewall rules defined because services here can be accessed from the Internet: it’s where this site is served from. I also wanted very fine, port-level control over a second VLAN for AI agents, and to have these separated from my regular DMZ. Again, more about this in the next post.

Lessons learned

Setting up VLANs is a notoriously frustrating process. There were several times in the process where I locked myself out of the network by misconfiguring the Wi-Fi network that my laptop was using to access the switches. If I had known what I was doing upfront, there are ways to avoid this, but most important is to work through a physical connection to the switch wherever possible, and to design your network over multiple iterations on paper (or draw.io) before actually configuring anything.

The main lockout incident happened while configuring the living room Zyxel switch. I changed the VLAN tags on Port 8 (which connected to the PoE switch feeding my APs), which immediately killed the Wi-Fi. I then tried accessing the switch via a different port, but that port was on VLAN 20 while switch management was still on VLAN 1, with no routing between them.

A power cycle didn’t help because the config had already been saved. I tried accessing the living room switch from the office switch, but hit the same VLAN 1 vs VLAN 20 routing problem across the trunk. Eventually the resolution required a factory reset of the living room switch (holding the physical reset button), reconfiguring from scratch, and being careful to set up management access on VLAN 20 before changing port assignments.

There was also a second lockout around the trunk link between the two switches. The living room switch had VLAN 1 set to untagged on the trunk port instead of tagged (like I mentioned above I was thinking about VLAN tagging/untagging the wrong way around), which broke management access across switches. I had to plug into the switch and fix the trunk tagging.

The pattern was always the same: changing a port’s VLAN assignment while connected through that port (or a dependent path), then losing the ability to reach the switch management interface to undo the change. So it’s important to always maintain a known-good management path before touching VLAN configs, and work through a direct physical connection to the switch you’re modifying.

The finished product

Below is a simplified diagram of my new setup, colour-coded to show the VLAN setup. You can compare it to the diagram of my old setup in the introduction post to see how much of an improvement this is, and that it accomplishes all the goals I set out at the start of this post. It took quite a bit of frustration and effort to get it working, but it is supremely satisfying now it’s all up and running.

In future posts I will go into a lot more detail about the router setup, the 10Gbps side of the networking (the thicker lines in the diagram above represent links which are 10Gbps), and the biggest part of the setup: the new Proxmox server I am planning to build to host all my applications and services.

Upgrading my Wi-Fi network

Sat, 31 Jan 2026 00:00:00 +0000

Upgrading my Wi-Fi network

January 31, 2026

The first step in improving my home network had to be fixing my dreadful Wi-Fi setup. My ISP-provided router was nowhere near powerful enough to reach the back end of my house, let alone the garden or the home office.

In a previous apartment, I had used a basic mesh system for a similar reason: the apartment was long and narrow, and the Wi-Fi didn’t really reach the far end, so I used a simple mesh system to boost the signal to the other end of the house. There are two types of mesh: the simplest, most “plug and play” versions are basically just signal relay systems. They don’t need ethernet connections, and so long as you place each one within the range of the next one, you can get a half-decent mesh purely through Wi-Fi, without worrying about running Ethernet cables through your house.

I wanted a much more robust system though, and my research led me to “wired Ethernet backhaul” as being the best way to implement a mesh system. This is how it’s actually done in large offices or public Wi-Fi networks. Wired Ethernet backhaul means that each access point (AP) is directly wired to the network with an Ethernet cable. There is then some centralised controller software which manages the network, allowing for seamless roaming between APs.

If you spend a bit of time reading about APs, you will definitely read about Ubiquiti and their UniFi range. It seems like they are positioned as the Apple of home networking equipment: everything is very nicely designed, with a “just works” experience on top of a “prosumer” level of configurability and features. Most people pair their UniFi APs with one of their “cloud gateways”, which are designed to replace your ISP router and provide much better firewall options and configurability, as well as hosting the controller application for the Wi-Fi mesh network. Because I wanted to build my own router (see some later posts for lots of details on that), I needed to find a way to host the controller application myself.

After quite a bit of research I settled on three UniFi U6+ APs. Three seemed like it would be enough to cover my house, garden and office (two in the house, one in the office), and I figured if I needed more I could always buy more. Crucially, these models support Power over Ethernet (PoE), meaning they can get their power and network from a single ethernet cable, making it all a lot neater. They’re designed to be ceiling-mounted, but they work well enough and look decent enough just sitting around the house.

I was very lucky that the person we bought the house from had wired Ethernet to two important locations. There’s a “drop” going from one of the upstairs bedrooms (in the picture above) down into the cupboard in the living room which has become a designated networking cupboard, with two cables terminated in nice sockets in the wall. So I could just plug an AP directly into the wall with a single ethernet cable and it works, provided the other end of that cable is connected to a PoE-capable switch, which I also had to buy. I added another AP downstairs plugged directly into the switch.

The biggest gift of all the previous owners left us with is a CAT6 cable buried in a trench in the garden which connects the home office to the networking cupboard. Another, smaller PoE switch in the home office then allowed me to install the final AP there. I’ll say a bit more about the specific switches I chose in the next post.

My final step was to install the UniFi controller app. As I mentioned above, it was important for me to be able to self-host it rather than get locked into a UniFi gateway. It was actually very straightforward to run through Docker on my Synology NAS, which is connected via Ethernet to the same network as the APs. Once the container was running, I just logged in, set it up using the wizard, and then “adopted” the APs and I was done!

The only minor snag I hit was quite educational. When I was debugging one of the APs not adopting properly, I noticed it was receiving a strange IP address that was not the default one it shipped with. It took me a good hour to figure out that my Hive hub was running its own DHCP server and handing out a different IP address to the AP, making it undiscoverable at its default IP. Once I turned the Hive hub off everything worked fine, and once the AP was adopted I just turned it back on again. This was a good introduction to DHCP for me, as well as some network diagnostic tools that I ended up using much more heavily as I headed deeper down the rabbit hole.

My next step was a complete redesign of my home network and replacing the ISP router with a custom build, you can read about that here.

Waratah: introduction and plan

Tue, 27 Jan 2026 00:00:00 +0000

Waratah

January 27, 2026

We bought our first home last summer, and after the initial moving in, setting up, redecorating and making ourselves feel at home, winter rolled around: the perfect season for spending a lot of time at home tinkering with computers. I ended up diving deep into a project I have wanted to do for years but never felt I could justify in a rented house: building a proper home networking setup myself.

I spent quite a lot of time over the last couple of months diving into this rabbit hole, and ended up reading a lot of blogs about homelabs: a sort of environment you set up at home to allow you to play around with interesting technologies you want to learn about, and self-hosting: using your own hardware to serve applications and services for your personal use.

This write-up is an attempt to give back to the community which I learnt so much from by reading detailed write-ups about people’s setups. My setup does involve a homelab, but it is also a full build of a “production” home networking setup that serves my whole house: my wife and kids and all our devices, our “smart home” gear, guests, media, backups, and in the future more and more self-hosted services to try and fight back against the encroachment of The Cloud on our lives.

Old setup

Here’s a schematic of our old network, before I started working on changes.

I live in London, and my ISP is Community Fibre. We are currently on a 1Gbps symmetric connection with them, which has a static public IP (note: I signed up for this almost three years ago, apparently this is not the case for new subscribers to their 1Gbps plans, you will get put behind CGNAT) and has pretty much always been reliable and achieves the line rate consistently in both upload and download (1Gbps will top out at around 940Mbps, or 117MB/s, due to various overheads). They provide an ONT into which the fibre connection terminates. This then connected to the router that they provided, which also functioned as the sole Wi-Fi access point. I connected the stuff I need in my living room directly to the router: Apple TV, Hive hub to control the heating system in my house, and then connected up a simple unmanaged switch for the three CAT6 cable runs the previous owner had installed through the walls: one out to the home office at the end of the garden, which goes through a trench, and two upstairs into nicely terminated wall connectors, which I wasn’t using (yet).

In the office, which is about 15 metres away from the house, I plugged the other end of that cable into another unmanaged switch, and into that went my laptops and my Synology DS220+ NAS. The NAS hosted a fairly basic media setup, including Plex, and was the target of Time Machine backups from my Mac.

Shortcomings

This setup worked OK for some things, but there were quite a few limitations.

Very poor Wi-Fi coverage. We have a two-storey Victorian terrace house with thick brick walls. The ISP router worked fine in the living room and master bedroom directly above it, but the back of the house had very patchy coverage, the garden almost none, and the office none at all. Combined with the fact that our street is a 4G dead zone, this was often a point of frustration.
No real control of routing. I have always struggled with the limited configurability of ISP-provided routers. I’d like to be able to configure firewalls, manage DNS and DHCP myself (don’t know what that means? Neither did I until I started digging!), and have real monitoring and logs and visibility into the network.
Flat network. I would like the ability to segment my network to be confident that any IoT devices I might purchase don’t have access to my main LAN. I’d also like to be able to self-host my website through a DMZ.
Limited to 1Gbps. I would like to future-proof my setup and support 10Gbps speeds for LAN, and in the future WAN.
No separate NAS storage from self-hosted compute. The only way I can host services is as Docker containers inside Synology’s DSM operating system. I’d like to expand what I can host, and also separate the storage layer from the compute layer for a more robust and modular architecture.
Lack of power. The Synology NAS has been reliable for almost five years now, and I am going to keep using it for storage for the next few years at least, but it does have a dated and fairly weak CPU and a paltry 6GB of RAM, so doesn’t really give me a playground for proper virtualisation or home automation.

Plan

I spent a lot of time researching how to improve my setup, and I came up with the following plan, broadly split into four parts:

Build a mesh Wi-Fi network with wired ethernet backhaul.
Replace the ISP router with a self-built router running OPNsense.
Upgrade the entire network to support 10Gbps networking and VLANs.
Build a dedicated server to run Proxmox VE to host all my apps.

Some other things that were important to accomplish in the project:

Build out a solid, trustworthy backup system (Time Machine is just not good enough)
Use infrastructure as code wherever possible
Proper monitoring of the whole system
Gear in the home office
Everything nicely rackmounted, neat and tidy cable management

I decided to call the project Waratah, after one of my favourite Australian native flowers (it’s a long-standing tradition of mine to name my projects after Australian stuff). I also decided that the different components of the network (switches, servers, APs, etc) will be named after different villages in the Blue Mountains in New South Wales, Australia, where I grew up.

You can keep reading about the first step in this project here.

Angophora

Sun, 30 Mar 2025 02:12:30 -0500

Angophora

March 30, 2025

Angophora is a new blog I started this week to share some writing that doesn’t naturally fit on this technically-slanted personal website, or on my “digital garden” Mt. Solitary. I’m hoping to post things at quite a regular cadence here: links to interesting things I’ve found, reviews, thoughts, basically anything that comes to mind. Feel free to take a look.

Technical notes

There’s not a lot to share in terms of how the new site was created that I haven’t already written about on one of the other project pages on this site relating to static websites. I chose a very simple Hugo theme called hugo-flex and deployed with Vercel. I added a custom font and a simple GoatCounter script, and the whole thing took me about ten minutes. My fifteen-year-old self writing raw HTML on GeoCities would be amazed.

GreenChainer

Wed, 19 Mar 2025 02:12:30 -0500

GreenChainer

March 19, 2025

GreenChainer is a web application that I built a proof-of-concept for recently, inspired by the Green Chain Walk in South London, where I live. I spend a lot of time walking, and one of the greatest things about this part of the city is the immense amount of green spaces, which have been famously “stitched” together in the Green Chain Walk, a fantastic 80 kilometre network of signposted routes connecting many of them together. This got me thinking: could I build an application that would automatically generate “green chain” routes between a given start and end point, of a given length?

To implement this idea, I needed to stitch a bunch of components together.

A map to display the user’s chosen search location, green spaces, and the eventual route.
A geocoding API, to convert a text-based location search string like “New York City” into coordinates to centre the map around.
An API to find green spaces within a given radius of the searched location.
A routing API which supports walking routes.
A routing algorithm which creates the “chain” route through various green spaces nearby the searched location. I figured from the start that this step would require the most thought.

I then had to throw all of these things together in a web application and deploy it somewhere. You can read below for the details of what I used to put everything together.

The map

I have some experience using OpenStreetMap (OSM), one of the greatest projects of the open internet alongside Wikipedia. It’s a free, open source map of the entire world that anyone is free to contribute to. It doesn’t have the richness of proprietary mapping services like Google Maps or Apple Maps, but in many parts of the world it is absolutely competitive with them, and it’s completely free and open! So choosing it as the map layer for this project was a no-brainer. You can hook it into Java/TypeScript using Leaflet, a nice mature library that supports many different mapping services, including OSM.

Geocoding

Geocoding is an interesting problem: I wrote a bit about my first experiences with it here when I was trying to do something a bit more complicated. The use case here is quite simple: just a search bar that the user can enter in text (which I will assume is specific enough and doesn’t ned to be “disambiguated”) and have an API return coordinates.

I used Nominatim, a geocoding services based on OSM which offers a generous free API for simple applications like what I am building here, provided you adhere to their usage policy. It works very nicely provided you are clear enough with your search query.

Fetching green spaces

Green spaces, like parks, commons, woodland etc, have special metadata within the OSM map. There is an additional API, called Overpass, which provides search functionality for OSM. So for the use case I needed, you can provide coordinates and a radius, and have the API return a list of “points of interest” of certain types within that area. For the initial version of the application I use the API to search exclusively for places labeled “park” on the map, but this could be easily extended to the many other different types of “green spaces” that OSM allows for.

Routing API

Once we have a location and a list of green spaces, we need to build an interesting route between them. For this we need a routing API - something that takes in a start and end location and returns a route between them that satisfies certain criteria. Usually this will be the “shortest route”, and in this case I want that shortest route to follow walking routes and not just roads that can be driven. I used OpenRouteService (ORS), which is related to the OSM “ecosystem” and provides a generous free tier, though you do need to pay if your requests exceed a certain monthly quota or you will get blocked.

Routing algorithm

Because there is no “greenest route” option in ORS (that’s why I’m trying to make this project!) we will need a custom algorithm to build our “green chain”. I devised a pretty simple POC algorithm here, which has as inputs the desired start and end points, as well as a list of green spaces in the radius and a desired walk length, and then checks for candidate “waypoints” from the list of green spaces until it finds a chained route between them that it thinks, based on a heuristic, will be close to the desired total length.

This is definitely the most unfinished (and of course, the most interesting and important) part of the project. It doesn’t work anywhere near as well as I would like it to, and I’m hoping to find some time to improve it in the coming months.

Building the application

This is a single-page application so it felt like a natural fit for React to me. I split the code into “frontend” and “backend”, with a fairly simple React application in the frontend showing a map component, and then various boxes on the left hand side for the different phases of the UX flow:

Enter a location and a radius, and press search to find green spaces within that radius around the location
Choose a green space from the list as your start and end point
Choose a desired route length
View the route on the map and a summary of the route

Deploying with Vercel

I have used Vercel quite a bit now — this site is deployed there, along with a few other projects of mine. I hadn’t use its “serverless functions” feature before though: essentially it gives you a very simple way to deploy a monorepo of frontend together with backend APIs it communicates with, without having to manage a separate deployment for the backend or worry about actual servers. It works fantastically well and was really easy to set up.

A word about “vibe coding”

I leaned heavily into AI coding tools for this project, mostly to see what they are capable of and understand if they really live up to the (rather incredible) amounts of hype that they are receiving at the moment. I used Cursor, together with the Anthropic API running mostly Claude Sonnet 3.7, which I have found gives the best results for code at the moment. I spent about $15USD on API tokens and about four hours altogether getting this up and running, and mostly operated on the “vibe coding” principle of letting the LLM write pretty much all of the code, including the configurations for the Vercel deployment. It did a pretty decent job of everything except the single part of this project which could be considered new or original: the routing algorithm that should make interesting “green chain” routes through public green spaces. So it seems like writing that part of the application is on me, and rightly so.

The routing algorithm still needs work: the routes it produces are often a bit “unnatural”: sometimes they cross over themselves, sometimes they avoid very obvious waypoints in favour of a main road. I think getting interesting, “naturally green” routes out of the application will be a proper challenge that will require adding additional things like entry and exit points for parks, and much more directionality information to the algorithm.

It is however very nice to have something tangible that exists after such a short time, and I think that this is the best use case for LLMs right now. I would have no idea how to use them to get a routing algorithm that works like I would expect from the finished, polished version of the product I am trying to build here. But they were able to get a “minimal viable” version (depending on how you define viable) in a fraction of the time it would have taken me to create it from scratch by hand. That’s definitely valuable, but it’s still not something that can replace getting your hands dirty and doing the actual work.

How will LLMs take our jobs?

Sun, 16 Mar 2025 21:21:46 -0500

How will LLMs take our jobs?

March 16, 2025

It’s a pretty inescapable take these days in tech circles: if you don’t want to get left behind, you need to be using LLMs, and become well-versed in how dramatically they can improve your productivity as a developer. Besides their utility as “next generation” search engines and replacements for online knowledge bases like StackOverflow, according to many, it is now possible, or will soon be possible, depending on how you look at it, to use these models to generate large portions of production codebases.

LLMs at work

Of course, as of today at least, we are still not at the stage where large amounts of production code is being generated by LLMs. There’s still a few legal and ethical hurdles to overcome before the cat is really out of the bag there I think: since any company that actually values its own intellectual property will not allow its employees to upload source code into third party servers, the ability for companies to train and serve their own LLMs, built around rapidly improving open source models, will have to progress significantly.

Closer to home though, I read a lot of tech blogs and comments on HackerNews and Lobsters, and am seeing a constant stream of posts and write-ups of people using LLMs to complete side projects. Since proprietary models are usually being used here (Claude, ChatGPT, etc), these sorts of projects can give us a glimpse at what may be the future of coding at work. The consensus seems to be that rather than a side project being some sort of idea you have, then spend a couple of hours on, maybe learn a few things, but quickly get distracted by life or a new side project, you can now just chuck your idea into the model and after a couple of hours of iterating you have a working project.

To me, this all seems to point to the fact that we are currently in the middle of a significant paradigm shift, akin to the transition from writing assembly to compiled programming languages. A potential future is unfolding before our eyes in which programmers don’t write in programming languages anymore, but write in natural language, and generative AI handles the gruntwork of actually writing the code, the same way a compiler translates your C code into machine instructions. (It’s worth noting that this workflow of “greenfield” projects is not really that similar to how most “at work” coding is done, where most tasks require changes to established “legacy” codebases rather than churning out thousands of tokens of new code).

This begs the question: what of the future of our livelihoods as programmers? Is a future of writing prompts and wrangling with LLMs something that you could concievably continue to call “engineering”? Will there be a time that software becomes so commodified that this job so many of us love will cease to exist, at least the way we have come to know it over the past half a century?

I think there are still an awful lot of unknowns at this point, we are probably at or close to the peak of the hype cycle so it’s very hard to see the future in between all the bullshit, invented use cases, marketing speak and VC money. But I think it’s at least possible to identify several possible scenarios, which I’ll go into in a bit of detail below, noting that any possible future from this point is probably going to be some linear combination of them and not any single definite path.

Give up

If you don’t like the look of where these changes are taking us, you can always go and learn a new skill set which you are betting is immune to them: gardening, carpentry, plumbing, psychotherapy, construction. This has been a desirable path for many burnt out tech folks over the years, even before the latest AI hype wave, as it can be exhausting to keep up with the latest changes, keep yourself current and relevant, particularly as you get older, and as the hype waves become more and more depressing in terms of the vision they present for our collective future as a species. Presumably this path will be attractive to those who have already reached financial independence through their career in technology and have the privilege to switch off and go and build chairs or milk cows (or both).

Join ’em

If you can’t give up, like most people with families and mortgages and other obligations in the real world can’t, or you don’t want to, you can always try to be one of the folks creating the models and the value from the models. Surely this is a career path with its peak still to come. It is currently extremely lucrative but there will be more and more jobs in these kind of roles in the coming decade. Good luck sorting the real, interesting and challenging opportunities from the hype though, and note that the learning curve here is very high, the base skills required very different from your average tech job (maths, stats, ML, GPU computing) and that it’s currently an extremely competitive market attracting the best of the best talent.

Climb the ladder

Another option for folks with the right dispositions is to spend more effort trying to climb the ladder into management positions, since presumably these will be immune for longer to any disruptive changes caused by the commodification of the actual “code generation” process.

I like the description that Nate Silver gives in this post, where the “market value $V$ of [a knowledge worker is] dictated by the function” $V= G\times S \times P$, where $G$ is general intelligence, $S$ is domain knowledge and $P$ is “soft” skills — communication, management of people, and so on. They are “multiplicative … because any of [them] are potentially limiting factors [on the others]”. So in a world where the first two multiplicands are devalued, the third becomes a lot more valuable. Presumably those “further up the ladder” will benefit more from this shift, since they are (at least ostensibly) there because of their high values of $P$.

Cross your fingers

You could also cross your fingers and hope it pans out differently — particularly if, like me you find the vision of the future spruiked by the most bullish LLM proponents a little ghoulish and offensive to our collective humanity. After all, there’s still only a very small chance (in my opinion at least) that the current technologies get us to the coveted AGI goal, which would truly be a world-changing technological revolution surpassing the Industrial Revolution or the invention and adoption of the internet. So there are three subpaths here:

AI winter

Hope this hype wave leads to another “AI winter”, like it has before, in which case traditional tech could remain the way it is for another boom/bust cycle or two. Each passing day that generative AI companies burn millions in cash without an actual profitable business model make this scenario incrementally more likely. On the other hand, each improvement in LLM capabilities, reduction in cost, and scale breakthrough make it less likely. There are a lot of people waiting to see how all this is going to pan out.

AI “summer”

I’m not sure of a better name for this scenario. But it’s interesting to note that in the “LLMs are just one level of abstraction further up, like moving from assembly to compiled languages” analogy I mentioned in the introduction, there are a lot more programmers making a living today writing Python and Javascript than ever made a living writing x86 instructions. Maybe this change “democratises” programming and software, and opens up a whole host of new opportunities while keeping the “old guard” employed as the “brokerage” layer between the old and the new (see “Linux greybeards” as the example from the previous generation).

Long-shot

Be part of one of the efforts trying to get to AGI with a different approach (“agents”, semantics, quantum, something else entirely). Of course you need to pick which of these approaches you think has the highest likelihood of success, and then have it succeed, which is a sort of startup-like trajectory that will not sound appealing to the risk-averse. It also requires unconventional skillsets similar to the “join ’em” scenario above.

Make sourdough

Finally, you could bet on the “human-made becomes artisanal” path: where software and technology untouched by generative AI develops a premium image and a path for continued employment for talented “old school” developers willing to put in the effort and resist the hype. Presumably when all our food is made by robots, rich folks with a nostalgic bent will pay top dollar for food made by actual human chefs: perhaps the same will turn out to be true for software.

Conclusion

I don’t know how any of this is going to play out, so it’s hard to decide myself which of the above scenarios to invest efforts in to ensure an interesting career with the potential for growth, learning and fulfillment. For now I am trying to keep my options open, to make sure I am keeping up with this very fast-changing field and at least theoretically remaining able to “pivot” if I see things going in a certain direction I think is more definite.

I said a few times above that thinking about the LLM future depresses me: I suppose this is mostly because I really like playing around with computers and using them to build interesting things, and these models feel like they are going to ruin a bit of that fun. I like the feeling of being creative and inventive, and these models give us the illusion that a computer can do that for us, when really all it is doing is garbling together some high-dimensional average of what other people have done before. In this environment, the premium for creativity and “truly new” ideas will presumably become even higher, as anything that can be generated by this averaging process becomes commoditised. So if I have to focus on one thing, it will be this: trying to remain creative and original, and not succumbing to the urge to use LLMs to do that kind of work for me. I think this strategy, alongside continuing to keep up with developments in the space, learning how to use whichever tools gain wide adoption and maintaining a solid understanding of the strengths and weaknesses of this current wave of AI, leaves as many of the potential paths above open as possible during this uncertain and turbulent time.

My setup (2025)

Sat, 04 Jan 2025 11:21:46 -0500

My setup

January 2025

In this post I answer the interview questions from uses this — again. This is an updated version of this post which I wrote in 2021, and is now the fifth time I have answered these questions. I have enjoyed reading uses this for many years and I like having a little archive of my own setups — you can see the five times I have done this exercise here.

Who are you and what do you do?

I’m an Australian mathematician and programmer living in London. I’m currently working at Via. Outside of work, I enjoy reading, writing, listening to and making music, and spending time with my family.

What hardware do you use?

I have two 14" MacBook Pros from 2021 with the M1 Pro “Apple Silicon” processor — one from work, and one for my personal use. I never mix the two, never sign into personal accounts (iCloud, email, whatever) on my work computer, and vice versa. The M1 MacBook Pro is definitely the best computer I’ve ever owned — I wrote up a bit more about why I love it here. At my desk at home, I have my work computer hooked up to a 27" Lenovo monitor, and my personal computer to the side for playing music through a Behringer UR-22 audio interface and some cheap but decent Samson BT3 studio monitors, which I also use in my spare time to record music, when I get the chance. My recording setup is simple: alongside the UR-22 I use Shure SM58 and 57 microphones and a Yamaha P-121 digital piano. It’s a basic setup but it works for the basic stuff I do.

Also on my desk is my trusty NAS — a Synology server with lots of storage which functions as a backup and media server for my household.

I have an iPhone 14 Pro, which I use to take all my photos these days (though many of the older photos on this site were taken with an Olympus E-PM1). An 11" iPad Air gets used when I’m making and recording music, or for video calls to relatives in far-away lands. I listen to music through AirPods Pro, which I also have in my ears most of the day for remote meetings at work. My home stereo which gets a lot of use is a half-decent Sonyo receiver hooked up to some Wharfedale speakers, a fairly basic record player and an Apple TV. I also have an Apple Watch.

And what software?

I use emacs to edit almost all of my text files, which is the majority of what I do with my personal computer these days (writing code is also editing text files). I use org mode and org agenda to manage all my tasks, to dos and notes, with the excellent Beorg app on iOS to handle everything through my phone. See here for a detailed write-up about my org-mode setup. All my files and photos are backed up at least three times — you can read about my backup solution here.

I browse the web in Safari and listen to music in Apple Music, where I have a huge amount of custom playlists I’ve put a lot of work into and am very happy with. For recording music I use Logic Pro.

I also use a bunch of utilities to keep my computer sane: f.lux so my eyes don’t get burnt out, Alfred to launch applications, Divvy to move windows around using keyboard commands and mclock to keep two time zones in my menu bar.

On my phone, apart from the obvious stuff like Messages, Whatsapp (ugh), Mail, Photos, Telegram and Phone, my homescreen consists of Calendar, (Apple) Music, a bunch of navigation apps, Safari, Files, beorg for my todo lists and tasks (though I am also venturing back to Things lately), and iAWriter for editing Markdown on the go. I deleted all my social media accounts years ago, so I also have Apple Books and the Kindle app for reading on my phone.

What would be your dream setup?

This has been the same since I first wrote it in 2015. An infinitely fast and thin laptop computer, with infinite battery and high-speed internet access everywhere. Perfectly comfortable headphones I can wear all day, and a completely lossless music collection. Apart from that I’m pretty happy with how things are at the moment: slowly but surely getting better, just like me.

Hugo migration

Wed, 01 Jan 2025 03:52:30 -0500

Migrating my personal site to Hugo

January 1, 2025

As foreshadowed in my recent post reflecting on ten years of running my personal website, I recently migrated the site to Hugo after many years of blogging with Jekyll¹. I used the Liftoff theme by Will Holmes as my starting point, and ended up making a large number of customisations — mostly in the CSS, but also some changes a bit deeper in the templating structure, to get back to a similar look and feel that I had in my old site.

There were quite a few reasons for the change:

Something new. I enjoy constantly reshaping, rewriting and rebuilding things I have made. It means I am continuously polishing and improving this site, shaving off little things that shouldn’t be there, going over all the copy again, and just generally spending time honing something — sanding it — which is a very calming and enjoyable pastime for me.
Portfolio. This was the big one. My old Jekyll theme (which was a heavily customised fork of a very old version of the Minimal Mistakes theme by Michael Rose) didn’t have a built-in portfolio section, and I didn’t really feel like sinking time into learning enough Jekyll to shoehorn one in myself. My new site has a shiny portfolio section, with pride of place in the top navigation bar, showcasing a bunch of projects I have managed to finish (or half finish) in some form over the years.
Dark mode. It seems like you can’t have a techy personal website these days without a fancy switch that toggles between light and dark mode, defaulting to the setting of the user’s browser. The Liftoff theme came with this built in, so all I had to do was tweak the exact theme colours to my liking. I ended up using the same background colour for dark mode that I have used for five years over at Mt Solitary, my digital garden.
Hugo. I chose Jekyll ten years ago, but Hugo feels a lot more modern, is significantly faster, and doesn’t have the Ruby dependency, which always gave me trouble. I also have used Hugo to successfully build other websites in the last few years so I’ve built up a bit of experience and comfort with it. It just feels a lot lighter and more future-proof.
Reading time indication. Another nice little feature of the theme I built around was a built-in reading time indication for posts. Of course this would have been easy to add myself, but it was nice that it came out of the box.
Tags. There is also built-in support for tags (called “categories”) in Liftoff, which means you automatically get pages like these.
Vercel. I had already done this in my ten-year revamp of the Jekyll site, but deployment is now done through Vercel instead of GitHub Pages. Vercel is a bit more flexible, offers a nice interface for managing multiple projects at once, and offers a very generous free “hobbyist” plan for personal project sites like mine.

Here’s a picture of the two sites side-by-side. On the left, the new Hugo site (in light mode), on the right, the old Jekyll site (now archived here). You can see the overall design is quite similar.

As for the list of things I lost in the migration:

In the old site I had an author information sidebar on each post, which included email, LinkedIn and GitHub links, and a profile picture on the non-article pages.
Feature images are now smaller and do not spread to the full width of the window.
Text on large screens has gone from 560px to 900px wide.
There are no longer year groupings in the blog section.

I think most of these are actually desirable changes — I prefer the slightly wider look and I had got a bit sick of looking at my face all the time. If people want to see what I look like, they can click through to my LinkedIn or GitHub profiles from the about page and see it there.

I did the migration very manually, copying pages over one by one and fixing up things that needed to be fixed. A few times during the migration of over fifty pages (and over 60,000 words!), I thought about trying to automate some of the migration, but in the end I found it a much more meditative process to go over everything manually. It also let me catch a few decade-old typos. For each page, the things I had to change were

front matter and feature image
mathematics typesetting
internal links

The things I had to tweak globally were

theme colours
web fonts
mathematics typesetting
Goatcounter support
completely rejigged the navigation bar
changed the “feature image” to be more like I had on my old site, including an image caption
migrate some posts to a “project” format instead of a “post” format

I enjoyed this project, it really forced me to take a deep look at my online presence and rethink how I want it to look for the decade to come. The end result is something that feels really suited to me, and I’m very happy with it.

Footnotes

Hugo and Jekyll are both “static site generators” (SSGs). If you don’t know what that means, unfortunately this post will probably not mean a whole lot to you. ↩︎

Clinton Boys

Building an OPNsense router

Building an OPNsense router

Router on a stick

OPNsense

Hardware

Installation

VLANs

DNS

DHCP

Firewall

VPN

Removing my ISP router

lit: Version control with good vibes

lit

lit

Why code.lock/?

Using lit

The demo

Under the hood

Try it

Limitiations of v1

Upgrading my home network to support VLANs and 10Gbps

Upgrading my home network to support VLANs and 10Gbps

VLANs

Lessons learned

The finished product

Upgrading my Wi-Fi network

Upgrading my Wi-Fi network

Waratah: introduction and plan

Waratah

Old setup

Shortcomings

Plan

Angophora

Angophora

Technical notes

GreenChainer

GreenChainer

The map

Geocoding

Fetching green spaces

Routing API

Routing algorithm

Building the application

Deploying with Vercel

A word about “vibe coding”

How will LLMs take our jobs?

How will LLMs take our jobs?

LLMs at work

Give up

Join ’em

Climb the ladder

Cross your fingers

AI winter

AI “summer”

Long-shot

Make sourdough

Conclusion

My setup (2025)

My setup

Who are you and what do you do?

What hardware do you use?

And what software?

What would be your dream setup?

Hugo migration

Migrating my personal site to Hugo

Footnotes

`lit`

Why `code.lock/`?

Using `lit`