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.
Annotations carry metadata that consumers can interpret
Annotations attach non-identifying metadata to Kubernetes objects. They can record provenance, ownership notes, or information consumed by a tool. Standard label selectors do not select objects by annotation values, but that does not make annotations inert. A controller, admission component, or deployment tool can interpret a documented annotation and change behavior accordingly. Know the consumer before deciding that a metadata edit is harmless.
...
Disk schedulers order I/O to move the head efficiently
blk-mq provides CPU- or node-local software staging queues and hardware dispatch queues. Scheduling and merging can occur before dispatch, while driver and device behavior also affect service. Software submission order does not guarantee completion order. A scheduler can influence how competing requests enter the device without controlling every later decision in the storage stack.
...
Structured logs make their query contract explicit
Structured logging assigns stable meaning to fields instead of asking each query to infer everything from message text. A record might contain an event name, request identifier, numeric duration, severity, and a human-readable message. Free text remains useful and can also be searched or parsed. The practical gain is that routine questions can use a documented schema whose meaning survives changes to explanatory wording.
...
A charset tells the reader how the bytes become characters
Character encoding connects bytes to characters. In text/plain; charset=utf-8, the charset parameter names that connection; changing the parameter does not change the payload. Reliable text delivery requires agreement between the producer’s actual encoding and the consumer’s decoding rules, not simply the appearance of the word UTF-8 in a configuration file.
...
Postmortems are for learning, not blame
After an incident, a postmortem should explain what happened, what people knew at the time, and which changes could reduce future harm. Blamelessness makes candid reporting safer. It does not guarantee that an incident cannot recur, remove ownership, or turn every explanation into an established fact. Learning requires both an honest account and evidence that useful follow-up actually happened.
...
Command substitution puts one command's output into another line
Command substitution captures a command’s standard output and inserts the resulting text into a surrounding expression. The familiar $(command) form is useful for a timestamp, a computed label, or another small textual value. It is not a transparent channel for arbitrary bytes or a reliable way to transport a list of filenames. Its newline handling, execution environment, and exit status are part of the interface you need to understand.
...
An access log separates client outcomes from upstream attempts
An nginx access log records request information when logging runs at the end of processing. The selected fields can distinguish what the client requested, which URI ultimately handled it, what response was sent, and what happened during upstream attempts. Keep these observations separate: one status, duration, or path cannot explain the whole request.
...
Incident response needs a timeline
During an incident, memory is unreliable, and clocks can disagree too. A timeline — who was paged, what was observed, what was tried, when the change landed — is what makes a response recordable and later reviewable.
Times and actors are transcribed from the inert source fixture. The shared date and UTC offset are display shorthand; underlying entries require full timestamps. Vertical spacing is schematic, not elapsed-time scale. A planned effect is not shown as a confirmed fix; no validator or incident system was run. Write as it happens Memory is the least reliable instrument in an incident, so record while the alert is fresh. Capture the timestamp of the first alert, the initial symptoms, each action tried and its observable result, and the moment the fix actually took effect. That running record is what keeps a team from repeating a failed fix during the response, and what later makes an honest postmortem possible instead of a plausible story. Make the timeline a live document from the minute the page fires: note the tool that alerted, the metric, the suspected and the confirmed cause, and record ‘same as before, did not help’ rather than silently re-trying.
...
