[{"content":"The best home lab is not the one with the most services. It is the one whose owner can explain what is running, why it is running, and how to restore it after a long break.\nI keep the foundation deliberately small: a current operating system, a short list of long-lived services, explicit configuration files, and one place for operational notes. Every service gets a local health check and a restart policy. Every public entry point has a clear owner.\nThe most useful habit is to write down the dependency graph. A static site may depend on a local web server, which depends on a directory of generated files. A private application may depend on a tunnel, a local listener, and an outbound connection. When those relationships are documented, a failure becomes a checklist instead of a guessing game.\nBackups are tested, not merely created. A backup that has never been restored is an assumption. Once a month, I restore a small sample into a temporary directory and verify that the files are readable, the permissions are sensible, and the documented recovery command still works.\nThe result is pleasantly unremarkable: fewer moving parts, fewer surprises, and enough observability to know when something changes.\n","permalink":"https://jing-online.com/posts/building-a-small-home-lab/","summary":"A few design choices that make a small personal server easier to understand and recover.","title":"Building a Small Home Lab That Stays Boring"},{"content":"When a Linux host runs for months, the service definition becomes more important than the initial installation command. I review long-lived services with five questions.\nWhat does it listen on? Local-only listeners should bind to loopback or a private interface. Public listeners should be intentional, documented, and covered by the firewall. A quick socket listing often reveals more than a configuration file search.\nWhat user does it run as? There is rarely a good reason for a static site or a metrics endpoint to run as root. A dedicated account, a read-only content directory, and a narrow working directory make mistakes less expensive.\nWhat happens after a restart? The unit should have a clear dependency order, a bounded restart policy, and logs that explain the first failure. Restarting forever is not recovery; it can hide a broken configuration and fill a disk.\nCan it be updated safely? Pinning a known-good version, keeping a small change record, and testing configuration syntax before restarting are inexpensive safeguards. I prefer a reversible deployment directory over editing files in place.\nCan I remove it later? An installation note should say where files, users, sockets, and systemd units live. Clean removal is a useful test of whether the original installation was understood.\n","permalink":"https://jing-online.com/posts/linux-service-hygiene/","summary":"A compact service review checklist for small Linux hosts.","title":"A Short Checklist for Long-Lived Linux Services"},{"content":"A static site turns a web request into a file lookup. That sounds modest, but it removes an entire class of runtime problems: database connection pools, application processes, migrations, and session state.\nThe trade is that content must be generated before it is served. For a personal blog or project notebook, that is usually an advantage. The build becomes a reproducible artifact, and the production server only needs to deliver files.\nI like to keep the boundary visible. Source content lives in version control. The build output is generated in a clean directory. The web server points at the output, not at the source tree. A deployment is then a copy plus a service reload, and rollback means pointing the server at the previous directory.\nStatic delivery also works well with an edge cache. HTML can remain short-lived while images, stylesheets, and scripts use long cache lifetimes with fingerprinted filenames. Even without elaborate infrastructure, this gives a small site fast global delivery and a pleasantly small failure surface.\nThe important part is not the framework. It is the discipline of treating the generated site as an immutable release.\n","permalink":"https://jing-online.com/posts/static-sites-at-the-edge/","summary":"The operational advantages of generating pages ahead of time.","title":"Why Static Sites Still Feel Like a Superpower"},{"content":"Starting a project is usually easy. Returning to it after six weeks is the real test.\nI now treat maintenance as a first-class feature. Every project has a short README with the purpose, the local development command, the production entry point, and the recovery path. Configuration is kept close to the code, while credentials stay outside version control. Logs are useful only when they include enough context to answer what failed and when.\nSmall release notes are surprisingly valuable. They record the reason for a change, not just the list of files touched. That makes it easier to decide whether an update is still needed later, and it gives future debugging sessions a timeline.\nThe other important constraint is scope. A personal service should earn its operational cost. If a feature adds another database, background worker, or external dependency, it should also remove a real limitation. Otherwise it is probably a demo, not a service worth maintaining.\nThe goal is not to eliminate all failure. It is to make failure legible, recovery repeatable, and the next change smaller than the last one.\n","permalink":"https://jing-online.com/posts/maintaining-personal-projects/","summary":"A personal project becomes useful when maintenance is part of its design.","title":"The Maintenance Budget of a Personal Project"},{"content":"A quiet place for useful notes Jing Online is a personal technology notebook. It collects short essays, working notes, and lessons learned while building and maintaining small software systems.\nThe topics are deliberately practical:\nLinux services, networking, and observability Automation that removes repetitive work Static sites and lightweight self-hosting Notes on tools that are useful enough to keep This site is written for future me first. If a note helps someone else avoid an afternoon of debugging, that is a welcome bonus.\nThere is no publishing schedule. New articles appear when a project leaves behind a lesson worth keeping.\n","permalink":"https://jing-online.com/about/","summary":"\u003ch2 id=\"a-quiet-place-for-useful-notes\"\u003eA quiet place for useful notes\u003c/h2\u003e\n\u003cp\u003eJing Online is a personal technology notebook. It collects short essays, working notes, and lessons learned while building and maintaining small software systems.\u003c/p\u003e\n\u003cp\u003eThe topics are deliberately practical:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLinux services, networking, and observability\u003c/li\u003e\n\u003cli\u003eAutomation that removes repetitive work\u003c/li\u003e\n\u003cli\u003eStatic sites and lightweight self-hosting\u003c/li\u003e\n\u003cli\u003eNotes on tools that are useful enough to keep\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis site is written for future me first. If a note helps someone else avoid an afternoon of debugging, that is a welcome bonus.\u003c/p\u003e","title":"About"}]