Linux
Servers I actually run: systemd, SSH, storage, networking, and the commands that fix things at 3am.
Field notes from shipping real systems: more than 700 articles at TechEarl, every one written from work that reached production.
I write TechEarl, a single-author developer publication with more than 700 articles on Linux, DevOps, databases, application security, networking, WordPress, and AI engineering.
Every article starts as something I had to make work on a real server, for a real site, with real traffic. The command was run, the config was deployed, the fix held. Each piece carries its publish date and gets revised when the tool changes, so what you read is what currently works, not what worked in 2019.
Servers I actually run: systemd, SSH, storage, networking, and the commands that fix things at 3am.
CI/CD, Docker, deployment, monitoring, and the boring reliability work that keeps sites up.
Application and server hardening, malware cleanup, and what real attacks on real sites look like.
MySQL, PostgreSQL, Elasticsearch, and Redis: schema, performance, backups, and recovery.
Running WordPress at scale, plugin and theme internals, WP-CLI, and cleaning up after compromises.
DNS, Tor, VPNs, proxies, and the diagnostics I use when the network is the problem.
LLM applications, batch APIs, cost control, agents, and evaluation, from building them for production.
Node, browser scripting, and the tooling around modern front ends.
Modern PHP, Composer, and the language underneath most of the web I maintain.
Layout, typography, and the parts of CSS that changed while nobody was looking.
Patterns that work across engines, with the edge cases spelled out.
One-page references for yt-dlp, torrc, regex, and other tools I reach for constantly.
Ranked by readers, from TechEarl's analytics, as of 13 September 2026. Tor, yt-dlp, and the cheat sheets carry the site; the pattern is that people arrive with a specific job and want the exact command.
Refreshed automatically from TechEarl each morning, so this list only changes when something new has actually gone out.
From the systems on the work page and from the platforms I run as CTO. If a command or a config appears in an article, I ran it on a box I was responsible for before I wrote it down.
Tools change. yt-dlp flags, Tor bridge types, and WordPress internals all moved in the last year. Every article shows when it was published and when it was last revised, and the year in a title means the piece was checked against that year's release.
It gets fixed in the open. Corrections are made in the article itself, and readers who catch a mistake get credit for it. The fastest way to report one is the contact page.
The cheat sheets if you have a job to do right now, the security section if you run WordPress in production, and the AI engineering pieces if you are paying an LLM bill and would like it smaller.