Linux on onelegdave.dev

I Made My AI Tools Ask Permission

OneLegDave — Sat, 26 Sep 2026 20:00:00 -0700

I pay for more AI coding tools than any reasonable person should, and for a couple of months I’ve been tinkering with one question: what if they worked together, and none of them could do anything I hadn’t agreed to?

Not “agreed to” in the sense of clicking Accept four hundred times until my finger goes numb. Agreed to in the sense that the operating system itself won’t let them do anything else.

That idea now has a name, a public repository, a website, and as of tonight a first release candidate. It’s called GovernCode. It’s free, it’s open source, and it will stay that way.

One boss, a few contractors, and a building inspector

GovernCode lets you pick one AI tool to lead a project. That’s the Controller. It keeps the big picture and hands small, bounded jobs to the others, the Runners, the way a contractor hands a room to a subcontractor. Each job gets written down first: what to do, which files it may touch, how much of my usage it may burn, and what “done” means.

Every one of them runs inside a sandbox that Linux enforces. Not a polite instruction in the prompt asking the AI to behave. The kernel’s own locks (Landlock and seccomp, if you want the names) decide which folders it can read, which it can write, and where on the network it can go. If my machine can’t enforce those rules, GovernCode refuses to start any AI tool at all and tells me why. There is no “just this once” switch, on purpose, because I know myself.

When a tool wants to run something that matters, it stops and shows me exactly what will run, byte for byte. Not a friendly summary. The actual command.

The part where I nearly gave up on my own demo

The first time I tried to show it off, I spent more time clicking Allow than watching the AI work. Every npm test, every file edit, every harmless ls. It was secure the way a locked filing cabinet at the bottom of a lake is secure.

So now I can say yes once, yes for the rest of this job, or yes for this project, and the plain read-only stuff just runs. The sandbox doesn’t move an inch when I do that. It only stops asking me the same question forty times. Deleting things, git, the network, and handing work to another AI still ask every single time.

I let the AIs audit the AI babysitter

Before putting a release candidate out, I had other AI tools try to break it. They found real holes. A tool could start a background process, “finish”, and leave that process running. A cleverly placed shortcut in a folder could have widened what a later job was allowed to write. A carefully worded command could sneak past the “this is just a harmless read” check.

All of that is fixed, each fix has a test, and the sandbox now proves its rules on your machine every time it starts, including against those exact tricks. I’d rather find out from a robot at my desk than from someone’s bug report.

Local models, because quota is money

Small jobs can go to a model running on my own graphics card. It gets no tools and can’t run anything. It reads the files it’s given and proposes changes, GovernCode checks every file it wants to touch, and I review it like anyone else’s work. The first real one wrote a usage section for a README in six seconds and cost exactly zero of my subscription.

The rule I care about most

GovernCode makes building software with AI a lot more approachable. It does not make anyone less responsible for what they ship. If I accept a change, it’s mine. I read the diff, I understand the code, I run the tests. The AI can write it. Only I can answer for it.

That’s written into the project’s philosophy as rule number two, right after “you hold the controls”, and it’s staying there.

Where it stands

It’s a release candidate for Linux, for people who like poking at things from a terminal. macOS and Windows are next, together, same priority, because I’m not making either one wait for the other. I’m dual-booting my laptop with Windows tonight so I can actually test it there.

None of this would exist if Omarchy hadn’t made my computer fun again and dragged a passion I’ve had forever back out of the drawer where time had shoved it. So: thank you, DHH, and everyone behind Omarchy.

GovernCode is at governcode.com. It’s free forever. If it saves you an afternoon, there’s a coffee button. My AI crew runs on tokens. I run on coffee. Only one of us has a button.

The Droid You Are Looking For

OneLegDave — Fri, 11 Sep 2026 14:00:00 -0700

Second plugin. This one puts your Android phone on your desktop: mirrored screen, mouse and keyboard control, no root, no Samsung account, no paid tier, no separate app installed on the phone begging for permissions it doesn’t need.

Under the hood it’s scrcpy doing the actual mirroring, because scrcpy is excellent and rewriting it would be idiotic. KDE Connect is optional on top for battery status and Ring. What I built is the part that makes those two things pleasant to live with instead of a pile of terminal commands you look up every single time.

Currently sitting in the Omarchy marketplace queue waiting on security review, which feels appropriate given how much of this post is about security decisions.

The thing that took the most thought

Getting a phone mirrored is not hard. Getting a phone mirrored is scrcpy and about four minutes of reading. The hard part is everything around it, and specifically one question that came up over and over in different costumes: when is this software allowed to guess?

Take phone identity. Multiple connections can point at the same physical phone. USB and Wi-Fi at the same time, IPv4 and IPv6, an address that changed when your router handed out a new lease. You want those grouped into one card, obviously, because they’re one phone.

But grouping is a claim. If I merge two connections into one card, I’m asserting they’re the same device, and if I’m wrong your input goes somewhere you didn’t intend. So merging only happens on hardware identity that Android actually reports. Matching model names never merges anything. Matching nicknames never merges anything. Two Pixels with the same nickname are two phones until the hardware says otherwise, because “they’re both called Pixel” is a coincidence, not evidence.

If Android refuses the identity query and discovery can’t work it out, the connection stays separate as an unresolved entry rather than getting quietly filed under whichever phone looks closest. An unmerged duplicate is a minor annoyance. A wrong merge sends your keystrokes to the wrong device.

Reconnecting without being creepy about it

Remembered phones reconnect automatically when discovery advertises the same identity, even if the address and port both changed. That’s genuinely convenient and it’s the behavior you want.

What it does not do is automatically pair with phones it’s never seen. It does not start a mirror session on its own. Retries are capped at once per address every 30 seconds, and you can turn the whole thing off. After a successful pairing there’s a ten minute window where discovery can finish the connection, and then it stops.

The difference matters. Reconnecting to a phone you already explicitly authorized is completing something you started. Pairing with an unknown phone because it happened to show up on the network is a decision nobody asked it to make.

Same principle as the GPU selection in my last plugin: auto mode gets to be clever, explicit choices get respected exactly as made.

Wake is not unlock

There’s a Wake/unlock button for when the phone’s asleep. It sends Android’s wake command and asks Android to show its normal unlock prompt. Then it stops and you unlock the phone yourself.

It does not submit credentials. It does not bypass a secure lock. It cannot, and it shouldn’t be able to, and I’m not interested in building the version that tries. Lock screens and capture-protected apps keep enforcing their restrictions through the mirror exactly as they should, and if that’s inconvenient in some specific app, good. That’s the lock working.

What it does not do, deliberately

No telemetry. No advertising. No cloud relay. No automatic update check. No crash upload. Nothing phones home, ever.

Runtime phone endpoints are restricted to private local-network addresses. There’s no support for pointing it at a public Internet endpoint or overriding the remote ADB server, because a phone-mirroring tool that can be aimed at an arbitrary remote host is a substantially different and worse thing than one that can only talk to your own LAN.

Automatic clipboard sharing is off. You paste with an explicit keystroke or it doesn’t happen. Pairing codes go through standard input, get cleared from the panel, and never touch disk or appear in a process command line where anything reading the process list could scoop them up.

Nothing gets installed just because you opened the panel. There are Install buttons for missing tools, and they do exactly nothing until clicked.

And it’s honest about what authorization actually means: ADB pairing gives this computer debugging access to your phone, disabling the plugin does not revoke that, and if you stop trusting a machine you need to forget it in Android’s own settings. That’s in the README rather than buried, because someone who installs this should understand what they just handed out.

The bit I’m quietly pleased with

The four-step connect guide. Desktop, Phone, Pair, Ready. Every one of those steps can fail in its own specific way and each failure gets its own specific message instead of a generic “could not connect” that leaves you guessing which of five things went wrong.

Wireless pairing on Android has a genuine trap in it: the pairing port and the connection port are different numbers, and nothing about the Android UI makes that obvious. People get it wrong constantly and then have no idea why nothing works. So the plugin calls it out directly, in bold, right where you’d hit it.

That’s not clever engineering. It’s just having actually used the thing and noticed where I personally got stuck.

omarchy plugin add https://github.com/onelegdave/omadroid --enable

Waiting on security review for the marketplace. In the meantime it installs fine straight from the repo, and every command it can run and every network endpoint it can reach is inventoried in SECURITY.md if you’d rather check before trusting it. Which, for something that gets debugging access to your phone, you probably should.

It Broke My GPU and I Like It Anyway

OneLegDave — Thu, 10 Sep 2026 16:00:00 -0700

In the last week Omarchy has quietly run my GPU at half power, left a 165Hz monitor sitting at 60, and been the direct cause of me deleting my own website. Genuinely rough introduction. Both of the first two got their own full autopsy, and the third one was entirely my fault but would not have happened if I hadn’t been reinstalling in the first place.

I’m still running it. I’m going to keep running it. Not out of stubbornness, and not because I’ve talked myself into pretending the problems weren’t real. Because for the first time in a long time my computer feels like mine instead of like a rental.

Thirty-nine seconds

I timed an install at thirty-nine seconds. Full desktop, Hyprland running, tiling, themed, done. Windows took over an hour on comparable hardware and spent a good chunk of that time asking me to sign into things and declining to take no for an answer.

That gap isn’t just a fun number to post. Fast installs change your relationship with the machine. When reinstalling costs you an hour of babysitting plus an evening of putting everything back, you don’t experiment. You get conservative. You leave broken things broken because fixing them might mean starting over, and starting over is a whole weekend.

When it costs thirty-nine seconds, “let me just wipe it and try that differently” stops being a threat and becomes a shrug. That single change quietly unlocks every other good thing here, because it makes being wrong cheap.

The extension surface is actually reachable

I wrote a plugin for this thing. An actual published one, a native system monitor that lives in the bar, reads telemetry straight off the kernel, and pulls every color it draws from the active theme.

I want to be clear about how unusual that is from where I’m standing, because I had zero programming experience not that long ago. On most desktops, “write your own panel widget” is a project you research for a week and then abandon. Here the plugin API was documented, the validator told me what I’d broken before anyone else had to, and installing it was one command. The distance between “I wish this existed” and “this exists and I’m using it” was days, not never.

That’s not the distro being magic. That’s a system that assumed from the start you might want to change it, versus systems built on the assumption you’d better not try.

Everything matches, because everything can

My desktop is a specific set of colors I picked. My terminal matches. My bar matches. My plugin matches, automatically, because it reads the theme rather than hardcoding anything. When I built this blog, the palette came out of my own desktop, and the banner came out of the same aesthetic.

That’s a stupid thing to care about. I care about it a lot. A machine that looks like something you chose rather than something you were assigned is a machine you actually want to sit down at, and I refuse to be embarrassed about that.

The part where it broke everything

Now the honest bit, because a post that only lists the good parts is an advert and I’m not writing one of those.

The GPU thing was genuinely bad. nvidia-powerd never gets enabled on install, so my RTX 5060 sat pinned at 50 watts instead of boosting to 100, silently, with no error and no warning, on a laptop that had been flawless for a year prior. I only found it because I got suspicious enough to check numbers instead of trusting vibes. That’s a real bug with a real cost, and it shipped.

The monitor thing was the same flavor: 165Hz panel running at 60 because the config takes whatever refresh rate the monitor advertises first rather than the highest one available. Two unrelated bugs stacked on top of each other, both invisible, both making the machine feel worse than it was in ways I couldn’t immediately articulate.

And then I reinstalled and lost my entire blog, because I’d been building it locally without a remote. Not Omarchy’s fault in any meaningful sense. But it happened because I was reinstalling, and I was reinstalling because the install is cheap, which is exactly the freedom I just spent three paragraphs praising. Cheap experiments cut both ways.

Why that’s not a contradiction

Here’s the thing though: I could actually fix all of it.

The GPU bug, I proved with a controlled experiment, masking and unmasking the daemon on two different distros until the number moved exactly where I predicted, then filed a bug report with reproduction steps clean enough that there was nothing left to argue about. The monitor bug was a config line. The lost blog got rebuilt from my own notes in fifteen minutes and now has three separate layers of backup that didn’t exist before, which is strictly better than what I had.

None of that is possible on a system that treats you as a consumer. When something’s broken on a sealed appliance, your options are wait, or accept it, or buy a different appliance. Here, every single problem was mine to dig into, understand, and either fix or report properly. Even the failures were interesting.

That’s what I actually mean by fun. Not that nothing goes wrong. Plenty goes wrong. It’s that when something does go wrong, I get to open it up and find out why, and I usually can, and sometimes the fix I send back helps someone else who would’ve hit the same wall.

I had forgotten computers could be like that. Somewhere between work machines I don’t control and phones I’m not allowed to open, I’d drifted into treating my own hardware as something that happens to me rather than something I do things with.

Thirty-nine seconds to install, an afternoon to write a plugin, a week to find a bug nobody else had pinned down. It broke my GPU and I like it anyway.

Zero Is a Lie

OneLegDave — Sun, 06 Sep 2026 11:00:00 -0700

I wanted a system monitor in my bar that actually matched my theme instead of sitting there as a mismatched floating terminal window I had to manually position every single time I logged in. The honest first version of this project was embarrassing: wrap btop, throw it in a panel, call it done. It even shipped under that name internally. Then I actually sat with it for a week and got annoyed enough to rebuild the whole thing properly.

What exists now is System QuikView, a native Omarchy Shell plugin. No btop. No root service. No cloud account, no pip packages, nothing phoning home. It reads Linux telemetry directly off /proc and sysfs, renders it through Quickshell’s own QML, and pulls every single color it displays from whatever Omarchy theme happens to be active. Switch themes, the widget updates live, because it was never allowed to hardcode a color to begin with.

The migration path I owe past me

The installer still knows how to find and migrate that original btop-wrapper prototype: same placement, same preferences, straight upgrade path, no starting over. Small thing, but I’m glad I didn’t just delete the evidence and pretend the finished version sprang out fully formed. It didn’t. It started as duct tape around someone else’s tool and got replaced piece by piece until none of the original tape was left.

The design decision that actually took thought

Most of the surface area here is fairly mechanical: read a number, put it on a graph, color it by theme. The one part that made me stop and actually think came from GPU handling, and specifically from a question that sounds trivial until you sit with it: what does the widget show when a sensor genuinely has no reading?

The lazy answer is zero. Zero is wrong, and it’s wrong in a way that’s actively dangerous for exactly the same reason a blank medication list is dangerous. Zero degrees is not “no reading available,” it’s a specific, false, freezing-cold claim about a piece of hardware that might currently be on fire. A missing value and an actual value of zero are two completely different facts, and collapsing them into the same digit is a decision to lie every single time the sensor doesn’t answer.

So a missing sensor shows a plain dash. Not a number pretending to be data. An honest admission that nothing came back.

That same principle runs through the multi-GPU handling too. If you explicitly pick a specific GPU by name and it disconnects, the widget does not quietly fail over to whichever GPU happens to still be plugged in and keep drawing a graph like nothing happened. It shows that reading as unavailable and waits for you to notice, because silently substituting a different device’s numbers under the same label is its own kind of lie, just dressed up as helpfulness.

Auto mode gets to be smart, explicit mode does not

There’s a real tension between “just work” and “never guess wrong,” so I split it into two modes on purpose instead of picking one philosophy and forcing it everywhere.

Auto mode is allowed to be clever: prefer a dedicated GPU when one’s available and reporting, fall back to whatever else exists otherwise, and it can pick different actual devices for usage versus temperature versus VRAM if that’s genuinely what’s available. That’s a real convenience and I don’t think it’s dishonest, because nobody who picks “auto” is claiming to know or care which specific piece of silicon answers.

But the moment you pin a specific device by name, you’ve made a claim, and the widget’s job flips from being helpful to being accurate to that claim. It doesn’t get to quietly reinterpret “show me this GPU” as “show me a GPU” just because the first one went away. Same underlying data source, two completely different obligations depending on whether a human explicitly chose a specific thing or asked for the software’s best guess.

What actually shipped

Bar reading you can set to CPU, memory, GPU usage, temperature, VRAM, network speed, disk usage, or nothing but an icon. Click it, get a full dashboard: history graphs, per-process ranking by CPU then memory, temperature gauges that use the hardware’s own reported warning thresholds when it has them and fall back to a plain labeled scale when it doesn’t. Sections reorder and collapse, and that layout survives a restart instead of resetting itself every time like it’s personally offended you touched it.

Tests cover the boring-but-load-bearing stuff: no GPU present, one GPU, several GPUs, a GPU that vanishes mid-session, missing readings across the board. python3 -m unittest, a separate Node suite for the selection logic in Model.js, a QML linter, and a plugin validator Omarchy itself ships to catch structural mistakes before they become someone else’s bug report.

Installed like any other Omarchy plugin:

omarchy plugin add https://github.com/onelegdave/system-quikview.git --enable

First one of these I’ve actually finished and put out publicly rather than leaving half-built in a folder labeled “someday.” The btop wrapper would have shipped faster. It also would have kept lying to me about GPU temperature the first time a sensor didn’t answer, and I’d rather have spent the extra week than ship a monitor I can’t actually trust the numbers on.

Half a GPU

OneLegDave — Wed, 02 Sep 2026 14:00:00 -0700

I bought a laptop with an RTX 5060 in it a year ago. It has been, until recently, completely unremarkable — no weird crashes, no thermal bullshit, no gremlins. A full year of just fucking working. Then I put Omarchy on it, and in under a week I owned a laptop with half an RTX 5060 in it, and didn’t know.

Here’s the thing about a hobbled GPU: it doesn’t announce itself. It doesn’t throw an error. It just quietly does less work than it’s capable of, while you sit there thinking “huh, this feels a bit sluggish for the hardware” and blaming everything except the actual cause, because the actual cause is invisible unless you go looking for it with a multimeter’s worth of paranoia.

The vibe was off, fast

This is the part that annoys me most in hindsight: this is a machine with a full year of clean behavior on record. Same laptop, same silicon, same everything, running perfectly fine on a previous install for twelve straight months. Then a new distro goes on, and within days something feels off. The correct instinct there is obvious — suspect the thing you just changed, not the hardware that’s been flawless for a year. I did not have this instinct on day one. I had it by about day four, after several days of increasingly irritated vague dissatisfaction.

New distro, new install, everything looking gorgeous, performance feeling… fine. Not bad. Just fine. Games ran. Renders rendered. Nothing was on fire. Which is exactly the problem with a silent performance regression — there’s no crash to point at, no log line screaming for attention, just a persistent, low-grade sense that something’s leaving performance on the table and you can’t fucking prove it. So you sit there for days quietly resenting your own laptop like an idiot, forgetting it had been perfect for a year right up until you changed the one thing you changed less than a week ago.

So I did what any reasonable person does when they can’t prove a feeling: I went and got numbers.

nvidia-smi while gaming. Power draw sitting at a suspiciously round 50 watts, pinned there like a coward. Not “50 watts because the game is light on the GPU.” Fifty watts flat, under a load that should have been begging for more.

For context: this is a laptop 5060, and 50W is roughly its baseline TGP — the floor, not the ceiling. These chips are supposed to boost well above that under load. Sitting exactly at the floor, permanently, isn’t “conservative,” it’s “someone forgot to flip a fucking switch.”

Proving it wasn’t in my head

Here’s where it stopped being a vibe and became an actual investigation, because “the GPU feels capped” is not a bug report anyone can act on, including me.

I had the same physical laptop running CachyOS not long before this, for that entire clean year. Different distro, different config, identical silicon, a full year of prior history saying this hardware has zero problems. So I had something no bug report ever gets: a perfect A/B test on the same chip.

Booted CachyOS. Same game, same settings, same everything. nvidia-smi again.

85 to 93 watts, 78 to 80°C under load. Same chip. Same cooler. Same room temperature. Nearly double the power draw, just from being a different pile of software sitting on top of it.

So it wasn’t the silicon. It wasn’t age. It wasn’t thermal throttling. It wasn’t my imagination, my expectations, or a shit game engine. It was Omarchy specifically doing something — or rather, not doing something — that CachyOS was doing right, and that this exact laptop had apparently been quietly capable of for a year without complaint.

Finding the leash

The actual culprit, once I went hunting: nvidia-powerd, a background service Nvidia ships specifically to manage Dynamic Boost — the mechanism that lets the GPU actually claim higher power states under load instead of sitting at its conservative default. CachyOS enables it automatically on install. Omarchy just… doesn’t. No warning, no prompt, no “hey, you might want this.” It simply isn’t part of the install, so the GPU spends its entire life politely capped at whatever the silicon defaults to out of the box, and nobody bothers to tell you.

I didn’t want to believe a missing background daemon was really the whole fucking story, so I did the only thing that would actually settle it: I broke the working install on purpose. Masked nvidia-powerd on CachyOS, the one that had been running fine for a year.

Power draw dropped to exactly 50 watts. Same number, same ceiling, same everything as Omarchy.

Then I went back to Omarchy and forced the daemon on by hand.

100 watts. Unlocked, on command, on the exact install that had spent less than a week quietly ripping me off while I sat there blaming a laptop that had done nothing wrong for a year.

That’s as close to a controlled experiment as you get outside an actual lab: flip one service off, lose the performance. Flip it on, get it back. Do it in both directions, on both distros, and watch the number move exactly where you told it to. At that point it’s not a theory anymore, it’s just a fact you’ve now personally reproduced four times.

The compounding bug that made it so much worse

While I was in there, I found a second, completely unrelated problem stacked right on top, because apparently the universe wanted this diagnosis to be as fucking annoying as possible.

My external monitor does 165Hz. Omarchy had it running at 60Hz. Not because of the wattage nonsense — because its config picks whatever refresh rate the monitor advertises first in its own list, rather than the highest one available, and apparently this monitor’s firmware lists 60Hz before 165Hz for reasons known only to whoever wrote its EDID data at 2am on a Friday and never thought about it again.

So for a good chunk of that week I was troubleshooting “why does everything feel underpowered” while actually looking at two completely independent bugs at once — a genuinely underpowered GPU, and a display quietly running at over a third of its actual refresh rate. Neither one caused the other. Both made the machine feel like garbage, which was extra insulting given it had been flawless for a year before this install existed. Untangling “is this the wattage or is this the refresh rate” took longer than either fix did once I’d actually separated the two idiots living in the same house.

Filing the report

Once I had reproducible numbers in both directions, I wrote it up properly and filed it against Omarchy’s own tracker on GitHub. Exact steps to reproduce, exact wattage numbers, the masking test, all of it — not “this feels slow,” but “do X, get 50W, do Y, get 100W, here’s the log,” cross-linked to the existing discussion thread so nobody has to go hunting for context.

A bug report that says “performance seems bad” gets ignored, correctly, because it’s unfalsifiable and everyone who’s ever run a helpdesk has learned to tune it the fuck out. A bug report that says “here is a lever, here is what happens when you pull it, twice, in both directions” gets fixed, because there’s nothing left to argue with.

The actual takeaway

Modern hardware doesn’t fail loud anymore. It fails by quietly doing less than it’s capable of and daring you to notice, and it can do it in under a week flat if you let it. When a machine that’s been rock solid for a year suddenly feels off right after you changed exactly one thing, trust that math immediately. Don’t spend four days doubting a laptop that’s earned better than that.

Check anyway. Pull the lever. Watch the number move.

Whoopsie

OneLegDave — Tue, 01 Sep 2026 17:30:00 -0700

So I built this whole site the other day. Hugo, PaperMod, a custom stylesheet with colours I sampled straight out of the banner image, a hero banner that behaves itself when you shrink the window. Took hours. Committed it to git twice, felt very pleased with myself, went to bed.

Then I reinstalled my distro.

You already know how this ends.

The part where I find out

Fresh install, home directory looked fine. My notes vault was there. Pictures were there. Downloads, full of the usual crap, also there. My Projects folder was sitting right where I left it, containing exactly two things, both belonging to a different project entirely.

No blog.

I ran a find across the entire filesystem for the project directory, because denial is a process and I wanted to watch it return nothing before I’d accept it. It returned nothing. Beautiful. Very quick about it, too.

Then I remembered the migration snapshots on my server. Three of them, taken at various points when I’ve moved this laptop between distros like a man who cannot commit to anything. Surely one of those had it.

The most recent one, taken right before this reinstall, contained: Desktop, Documents, my shell config, my terminal config, and Pictures. No Projects. Fantastic. Really glad I saved my colour scheme.

The one before that did have a Projects folder. My heart did a thing. I opened it. Same two unrelated projects, no blog — because that snapshot predates the blog by weeks. So the site was born and died in the gap between two backups, which is a hell of a way to go.

“But you used git”

I did use git. Two clean commits, nice descriptive messages, branch named main like a well-adjusted adult who has his shit together.

Here’s the thing about a local git repo that nobody enjoys learning the hard way: the entire history lives in a .git folder inside the project directory. Delete the project, delete the history. Git isn’t a backup. Git is a very good undo button that lives in the same building as the thing it’s undoing. Push it somewhere else or it’s just a diary you keep in the glovebox of a car you’re about to set on fire.

Setting up a remote was literally on my todo list from that session. It was item two. I got to item zero.

The banner image went too, since that was sitting in Downloads, and Downloads is where files go to be deleted by a man doing a spring clean at midnight who is absolutely certain he doesn’t need any of this.

What actually protected me: fuck all

Let’s be honest about the failure. It wasn’t bad luck. My server has a genuinely decent backup setup — Restic running twice, once to an external drive and once offsite to Backblaze B2, 7 daily / 4 weekly / 12 monthly retention, integrity checks, failure notifications straight to my phone. It’s good. I’m proud of it. I’d show it to people at parties if I went to parties.

It backs up /srv/appdata, /srv/sync, /srv/backup, and my compose files. All of which live on the server.

The laptop was contributing precisely fuck all to that. Every “backup” of my laptop was me, by hand, going “hmm, I should probably copy some folders before I nuke this thing,” and then copying whichever folders I happened to think of in that moment. Which is exactly why I have a pristine copy of my terminal theme and no copy of my actual work.

Manual backups back up whatever you remembered. Not whatever mattered. Those are very different lists and you only find out how different at the worst possible moment.

The fix

The elegant bit is that I didn’t need any new tooling. Syncthing was already running on both machines, already talking to each other, already doing its job for other folders. So:

My Projects folder is now a synced Syncthing folder, landing at /srv/sync/projects on the server. That path is already inside both Restic jobs. So the moment a file hits Projects on the laptop, it replicates to the server, and the next Restic run sweeps it into the local repo and B2. Nothing to configure in the backup scripts. It just inherited the entire chain.

Staggered file versioning is on at both ends, because plain Syncthing is a mirror, not a backup — delete a file here and it will cheerfully, instantly delete it there, like an over-eager intern. Versioning means the server keeps the old copy in .stversions instead of enthusiastically helping me destroy my own work.

One gotcha, and it cost me a genuinely confusing five minutes: Syncthing on my server runs in Docker, with /srv/sync mounted as /var/syncthing/data inside the container. So when I typed the host path into the web UI, it threw mkdir /srv/sync: permission denied and refused to start the folder. It wasn’t a permissions problem at all — that path simply does not exist from inside the container. You have to give it the container path. Obvious in hindsight. Deeply fucking irritating at the time.

And finally, the thing I should have done first, before any of the rest of it: a bare git repo on the server, sitting inside a path Restic already backs up. git push now sends my history somewhere that isn’t this laptop, which is the entire point of a remote and something I will not be forgetting again.

Rebuilding

Here’s the one genuinely smart thing I did last session: at the end of it, I wrote the whole setup up properly. Every CSS variable with its hex value. The full config file. The exact ImageMagick command. The layout override trick and why it works. All of it in my notes vault, which — being a synced folder — survived without a scratch.

Rebuild took about fifteen minutes. Install Hugo, scaffold the site, add the theme submodule, paste three files in, done.

The thing that took hours the first time was never the typing. It was the working out — the hunting through theme files, the trial and error, the six attempts at centering a div. Working out doesn’t need to be redone if you wrote it down. Typing is cheap. Figuring it out again is not.

The only real casualty was the banner. I had to re-source it, and the copy I got back is 1855px wide instead of the original 3710px. Not the end of the world — I dropped the CSS max-width to match, so it isn’t being upscaled and going soft on big monitors. Half the resolution, none of the blur. You’d never know unless I told you, which I just did, because apparently I can’t help myself.

The lesson, such as it is

Backups you have to remember to run are not backups. They’re a hobby you do occasionally, and the gap between “when I last felt like it” and “right now” is precisely where your work goes to die.

Automate it or accept that you’re going to lose something eventually. There’s no third option where you’re just really diligent about it forever, no matter how much you’d like there to be. I thought I was that guy. I was not that guy.

Anyway. Site’s back. It’s now backed up three separate ways, which feels like wild overkill until you remember I’m the same idiot who deleted it in the first place.