Original, source-backed articles about running small systems, static sites, HTTP, DNS, TLS, and operations.
Posts are original articles written for this site. Each one is script-free, source-backed, and tied to the same operational reality the rest of the site records: how a small, static, publicly served system is built, secured, and kept honest.
Writeback separates buffered visibility from storage completion
Buffered file I/O can pass through a language buffer, the kernel page cache, and the storage stack at different times. Modified cache pages need writeback so their data reaches the backing filesystem and device. This separation can combine work and improve throughput, but it means that another reader seeing new bytes is not, by itself, evidence that a crash-safe storage boundary has completed.
...
Immutable assets and fingerprints
A fingerprinted asset puts a digest of its bytes into its URL. Changing a stylesheet produces a different address, so a page can request the new representation without depending on every existing cache expiring simultaneously. The useful guarantee comes from the publishing process: once an address is released, its contents must remain consistent with that digest.
...
Swap trades residency for reclaim cost
Swap gives Linux a backing store for eligible memory pages that need not remain resident. It can preserve cold data while RAM serves active work, but it does not make the machine’s working set fit at RAM speed. The useful question is whether reclaim frees space without repeatedly stalling important tasks. Swap occupancy, swap traffic, and application progress answer different parts of that question.
...
zram squeezes swap into RAM
When memory tightens, cold pages would go to a slow disk. zram keeps them in compressed RAM instead, trading a little CPU for much more headroom.
A compressed block device in memory zram is a block device that lives in RAM and stores compressed data instead of talking to a real disk. When the kernel swaps a page into it, the page is compressed and kept in memory, so the memory gain comes from shrinking the pages rather than moving them to slow storage. Because the device is memory-backed, it answers reads and writes far faster than a disk-backed swap, but the space it provides is limited by how compressible the pages are and by how much memory you are willing to trade for the swap.
...
A signal has a disposition, a mask, and delivery rules
Signals notify processes or threads of events using kernel-defined delivery rules. A signal’s disposition selects a default action, an installed handler, or ignoring it where permitted. A thread’s mask can block delivery of eligible signals while they remain pending. Separating disposition, masking, and pending state is essential when a program appears to miss repeated notifications or fails to stop as expected.
...
sysctl tunes the running kernel
On Linux, sysctl exposes selected kernel parameters through /proc/sys. It can inspect the running state, and an authorized write can change that state without rebooting. A configuration file is a separate instruction to a loader. Confusing these two layers produces a familiar incident: the desired value is on disk, but the kernel is doing something else.
...
Logrotate applies a rotation policy when it runs
Logrotate evaluates configuration when invoked, rotates eligible logs, and applies the selected retention and compression actions. A timer or another scheduler determines when that evaluation happens. The tool does not continuously cap file size, and renaming a log does not automatically redirect an application’s open descriptor. A working setup combines evaluation frequency, file policy, and the writer’s actual reopening behavior.
...
Named config files favor clarity
Configuration that is easy to find, read, and diff is more than a preference; it is how a change stays reviewable. Naming a file with a clear convention is the first step to environment-specific, single-source config.
A file is a record of intent A named, versioned config file is a record of intent: the deployed values become explicit, reviewable, and reproducible just like code. When the file lives with the project, a change gets history, a blame, and a pull request, so anyone can answer ‘what actually shipped and who changed it’. A clear naming convention (app.conf for application knobs, app.env for environment shape) makes each file’s purpose obvious at a glance, and keeps the settings from being scattered into ad-hoc flags nobody can find.
...
