We have all done it if you work long enough. I blew up my Debian Linux system with an incredibly stupid mistake breaking the whole system. It is actually one of the questions I have when interviewing someone. “What is the worst mistake you’ve ever made?” And if they admit one, the follow up question, “What did you learn?”

I renamed my /usr directory to /usr-root with a mv /usr /usr-root as the root user. I knew I was treading on dangerous ground so I fortunately had two ssh console sessions up and both running as root. The goal was to migrate the /usr to separate storage to recover space for the very full root disk.

After years of managing Linux systems - from my Dell Wyse 3040 Proxmox cluster to various VMs and containers - I’ve accumulated a collection of command-line tools that I reach for constantly. These aren’t exotic utilities, but rather the practical tools that help me figure out what’s actually happening when systems misbehave.

Most of these came from those “why is this server slow?” moments where you need to quickly diagnose CPU, memory, storage, or network issues. Here’s what I actually use and why.

After running this Jekyll-based website for a couple years (since July of 2023), I’ve learned valuable lessons about optimizing Jekyll sites for GitHub Pages. This blog initially started as a consolidation of several blog websites I’d published over the years. This is Part 1 of a two-part series covering the foundational optimizations that have made the biggest difference for my homelab blog.

I hate time tracking. Seriously. Most time tracking tools require you to remember to start timers, categorize work, and generally interrupt your flow to feed some system that’s probably going to be wrong anyway. But when you’re freelancing or need to report hours on projects, you’re stuck with it.

So I built a Python tool that generates timesheets from git commit history - because your commits are already there, they’re timestamped, and they actually reflect when you were working on stuff.