Linux / tooling / infrastructure
A growing collection of practical tools, guides, automation, and systems work across Linux, macOS, networking, and developer workflows. This page is a curated index of public work, not a single product or a dump of every repository.
What this is
I use open source to make the difficult middle layers easier to reason about: the host beneath an application, the firmware beneath an operating system, and the checks that keep a configuration honest.
The repositories below are deliberately grouped by the kind of problem they solve. They include finished utilities, living documentation and focused experiments. The common thread is not a framework; it is making assumptions visible and leaving someone else with a useful starting point.
Workstreams
These are the areas where my public work is most representative. Product projects such as PRG32, Emporion and Spotted Train have their own case studies.
The Linux Server Playbook turns a fresh Ubuntu host into a documented baseline: access, firewalling, Docker, Fail2Ban, DNS and validation all belong to the same operational sequence.
OpenCore validators, configuration sanitizers and small diagnostic utilities make platform work easier to inspect, share and repeat without exposing machine-specific data.
The public guides collect the reasoning around BIOS extraction, CFG Lock, ACPI and battery behaviour. They are practical references, not claims that every machine behaves the same way.
Public repositories
A short, verified selection of repositories that explain what I build and what I care about. Each entry has a job here; none is filler.
How I work
The portfolio version is intentionally concise. The repositories contain the commands and implementation details; this is the perspective that connects them.
A server, a firmware patch or a CI check should state what it assumes and what it does not control.
The command finishing successfully is not the same thing as the system being in the intended state.
Sensitive identifiers, fragile shortcuts and machine-specific details should not be prerequisites for understanding the approach.
