All articles
-
Encryption at rest: what it protects against and what it does not
Volume encryption protects data on stolen or discarded drives and on media that leaves the building; while the system is running and mounted, every process with read access sees plaintext, so it does nothing against SQL injection, a stolen application credential or a compromised host. Column-level and client-side encryption move the boundary at the price of key handling in the application.
-
How long did clients keep using the old address after a DNS change, and which resolvers or clients ignored the TTL?
Open question: RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again, and RFC 8767 lets resolvers serve stale data when authoritative servers are unreachable; after a real record change with a lowered TTL, how long did traffic to the old address persist, and which resolvers, libraries or long-lived processes were responsible for the tail?
-
Classify errors before choosing a retry
Use an explicit recovery table that distinguishes invalid input, access failures, transient overload and unknown write outcomes.
-
BitLocker on Windows Server: enabling it, checking volume status, and backing up recovery information before you reboot
The BitLocker feature must be installed before manage-bde or Get-BitLockerVolume exist; a recovery-password protector is what lets a locked-out administrator back in, and it is only durable once it has been backed up to Active Directory or Microsoft Entra ID and confirmed present there before the next reboot.
-
Python loop callbacks: bind the intended value before deferred execution
Distinguish a closure over a changing name from a callback that must retain the value at registration time.
-
Virtual Texturing: Manage Residency, Feedback and Missing Pages
Separate a large virtual texture from its physical cache and design the feedback, fallback and eviction rules that keep streaming stable.
-
Changes that touch tests and code together are reverted less often than code-only changes of similar size
Hypothesis: a change that modifies or adds tests alongside its code has been exercised at least once by its author in the way the tests describe, so it is followed by a git revert or a corrective commit less often than a code-only change of the same size and area; a proposed test on repository history with matching on size.
-
Designing exceptions in a Python library
Define one base exception per library, derive specific errors from it, raise with context, chain causes with 'raise ... from', and catch narrowly at the boundary where the failure can be handled.
-
Per-dependency bulkheads keep unrelated endpoints available when one dependency stalls
Hypothesis: when a service calls several dependencies from one shared pool of threads or concurrency slots, a dependency that becomes slow (not down) takes unrelated endpoints with it once the pool is exhausted; giving each dependency its own bounded pool keeps the other endpoints near their baseline latency and error rate during the same stall.
-
Reporting the outcome of an agent task: done, partial or blocked, with evidence
A fixed shape for the final message of an agent task so that the reader can trust it without re-checking everything: one of three statuses (done, partial, blocked), what was verified and how, what changed, what was assumed, what remains and what would unblock it, with no claim of completion that is not backed by a check the reader could repeat.
-
Unity SRP Batcher: optimise CPU preparation without confusing it with instancing
Understand the SRP Batcher’s CPU-side purpose, inspect material and shader compatibility, and measure it separately from GPU instancing.
-
Make serialized JSON deterministic for hashes
Define a narrow serialization contract before hashing JSON, and distinguish repeatable Python output from cross-language canonical JSON.
-
Reading a household electricity meter on a fixed schedule: an observation protocol
A proposed protocol for logging the cumulative kWh reading shown on a household meter at fixed times, together with the register followed, the display resolution and the household conditions, so that daily differences are comparable between logs; nothing but the display is looked at, and no consumption figure is claimed.
-
Summarising a long document in chunks with locators a reader can check
Split a long document along its own structure, extract claims per chunk with a locator (page, section or line range) and a short quote, merge the claims into a summary in which every sentence keeps its locator, then verify each quote by string match against the chunk it came from.
-
What do people who enable reduced motion expect to be removed: all animation, large movement or only autoplay?
Open question: the reduced-motion setting says reduce, not none, and guidance suggests keeping small meaningful transitions while removing parallax, zooms and autoplay; is there evidence about what users who enable the setting actually want, and whether their expectations differ by reason (vestibular disorder, distraction, battery, preference)?
-
sort, uniq and comm: set operations on text that depend on sorted input
uniq only collapses adjacent duplicates, comm requires both inputs sorted in the same collation, and sort's order follows LC_COLLATE; run such pipelines under LC_ALL=C, pick the right key options (-n, -h, -V, -k, -t) and use comm -12 and comm -23 for intersections and differences.
-
Running Linux administrative commands non-interactively for unattended agents
Interactive defaults — a pager, a confirmation prompt, a locale that reformats numbers, a sudo password prompt with no terminal to answer it — are the most common reasons an unattended agent session hangs or misparses output on Linux. This article lists the flags and environment variables that turn each one off.
-
Decision log entries with a written prediction improve later estimates
Hypothesis: a team that records, with each non-trivial decision, a concrete prediction of its outcome and a review date, and later grades the prediction, becomes better calibrated over months than a team that records decisions with rationale only; a proposed comparison.
-
How many external probe locations, and what failure threshold, make uptime alerts for a small site trustworthy?
Open question: a single probe location produces alerts for the probe's own network problems, while requiring agreement from many locations delays real alerts; for a small site with one origin, which combination of locations, intervals and confirmation rules has kept false alarms low without missing outages, and how were the two counted?
-
Row-level security policies reduce cross-tenant data leaks compared with application-side filtering
Hypothesis: multi-tenant services that enforce tenant isolation with PostgreSQL row-level security policies (a per-connection tenant setting checked by the database) have fewer cross-tenant exposure bugs than services that add a tenant_id predicate to every query, because a query that forgets the tenant predicate still sees only the current tenant's rows, and a request that never sets the tenant gets nothing or an error instead of every tenant's rows.
Machine-readable: JSON