Why I Built This Site (And Why It’s Not a Blog)
I have 12 years of notes scattered across dead wikis, abandoned Notion pages, forgotten Google Docs, and a graveyard of markdown files that made sense at 2 AM but are gibberish now.
Every time I solve a hard problem—RAID recovery, VPN debugging, kernel panics—I tell myself I’ll document it. Sometimes I do. Then the documentation rots in a folder I never open again.
Six months later, the same problem happens. I know I solved it before. I can’t find the notes. I solve it from scratch. Again.
This site is my attempt to break that cycle.
What This Actually Is
This isn’t a blog in the traditional sense. I’m not publishing polished articles on a schedule. I’m not chasing SEO keywords or trying to go viral.
This is a digital garden—a term I borrowed from the IndieWeb community. It means:
Living documents. Posts get updated. The Btrfs guide I wrote in November 2025 has been revised four times as I learned more. The build swarm documentation changes every time I fix a bug.
Varying completeness. Some pages are comprehensive guides. Others are rough notes I published because “good enough now” beats “perfect never.” You’ll see the difference.
Interconnected ideas. Infrastructure, automation, and Linux internals are deeply connected. A post about EFISTUB links to the golden image guide which links to the build swarm which links back to kernel configuration. It’s a web, not a timeline.
Learning in public. I’m sharing the process, not just the results. The failures. The 3 AM debugging sessions. The “oh, that’s why it broke” moments.
The Note-Taking Journey
I’ve tried everything.
2012-2015: Text files Markdown files in Dropbox. No organization. No search. Lost half of them in a sync conflict.
2015-2018: Wikis DokuWiki, then MediaWiki, then TiddlyWiki. Each one required maintenance. Each one eventually broke. The wiki itself became a project I didn’t want to maintain.
2018-2020: Notion Beautiful. Slow. Proprietary. My notes lived on someone else’s server. When Notion had outages, I had no notes.
2020-2022: Obsidian (chaos era) Local markdown files. No sync issues. No vendor lock-in. But I made a mess. One vault with 800+ files. No structure. Tags that meant nothing. Links that went nowhere.
2022-2024: Obsidian (organized era) Three vaults, each with a purpose:
- argo-os-docs: Technical documentation for Argo OS and the build swarm
- Arcturus-Prime-technical: Project journals, session logs, debugging notes
- personal: Everything else (not public)
Daily notes. Session templates. Proper folder structure. Actually findable information.
2024-present: This site The public layer. Selected content from my vaults, cleaned up and published. The goal: if it helped me, maybe it helps someone else.
Why Public?
Three reasons.
1. Forcing Function
When I know something might be public, I write it better. I explain the why, not just the what. I include the error messages. I document the failed attempts.
Private notes are lazy. “Just run the command” with no explanation. “Fixed it somehow” with no details. Public notes have to actually make sense.
2. Searchability
I can’t grep my brain. But I can grep this site.
When I’m debugging at 2 AM and I vaguely remember solving this before, I search my own site. The answer is there, written by past me for future me.
The public part is incidental. The real audience is myself in six months.
3. Giving Back
I’ve copied commands from random blog posts thousands of times. Some anonymous sysadmin in 2014 wrote the iptables rule that saved my production server. I never thanked them. I can’t—I don’t know who they are.
This is my contribution to that ecosystem. Maybe someday, someone will copy a command from here and fix their own 2 AM crisis.
What You’ll Find Here
Technical Guides Deep dives into specific technologies. Btrfs snapshots. Gentoo binary packages. Tailscale subnet routing. OpenRC service management. These are reference material—meant to be found via search, not read in order.
The Argo OS Journey A 4-part series documenting the creation of my custom Linux distribution. Part disaster log, part technical guide, part therapy session. Start with Part 1.
Infrastructure Posts How I run my homelab. 252TB of storage across two sites. Distributed compilation clusters. Mesh networking. The lessons learned from 12 years of breaking things.
Journal Entries Shorter, rougher posts. Debugging sessions. Quick fixes. The “I just spent 3 hours on this” entries that might save someone else 3 hours.
The Tools
For the technically curious:
Content creation: Obsidian (local markdown, vim keybindings)
Static site generator: Astro (fast, flexible, good TypeScript support)
Hosting: Cloudflare Pages (free tier, global CDN)
Search: Pagefind (client-side, no tracking)
Graph visualization: Custom Cytoscape.js implementation
Source control: Git (self-hosted Gitea, mirrored to GitHub)
The whole site is a collection of markdown files that get built into static HTML. No database. No CMS. No JavaScript required to read the content.
The Philosophy
I spent too many years consuming content and not enough creating it.
Reading tutorials without practicing. Bookmarking articles I never returned to. Collecting knowledge without synthesizing it.
Writing forces understanding. If I can’t explain something clearly, I don’t actually understand it. The gaps in my knowledge become obvious when I try to fill a blank page.
This site is the output of that process. It’s not comprehensive. It’s not authoritative. It’s one person’s notes, shared in case they’re useful.
A Note on “Perfection”
Some posts here are polished. Multi-thousand-word guides with diagrams and code examples.
Others are rough. Quick notes. “Here’s what worked for me” without much context.
Both are intentional.
The perfect guide that never gets published helps no one. The rough note that goes live today might help someone tomorrow. I’d rather publish something imperfect than wait for perfect and publish nothing.
If you find errors, outdated information, or things that don’t make sense—that’s expected. This is a garden, not a museum. Things grow. Things change. Sometimes things die.
How to Use This Site
If you’re looking for something specific: Use the search. It’s client-side and fast. Most of my traffic comes from people searching for error messages.
If you’re exploring: The knowledge graph shows how posts connect. Or just browse the posts page and see what catches your eye.
If you want the full story: Start with Building Argo OS: Part 1 and follow the journey.
If something’s broken or wrong: Open an issue on GitHub or just email me. I fix things when I find out they’re broken.
The Ongoing Experiment
This site will never be “done.” That’s the point.
New problems create new posts. Old posts get updated. The garden grows.
If you’re here, you probably landed from a search engine looking for a specific fix. I hope you found it. And if you’re curious about the person behind the notes—I’m just someone who’s been running homelabs for 12 years and finally decided to write some of it down.
Welcome to the garden.
Last tended: January 2026