Engineering
Each piece has to pass one test: could someone who has not done this work write it? If yes, it does not get published.
Updating model weights in an air-gapped environment without breaking the air gap
A complete, runnable air-gap model-update procedure — bundle manifest, detached signature, safetensors-only gate, Ollama blob mirroring, settings-table rollout and rollback — assembled from first principles because almost no vendor documents the steps between 'download the weights' and 'the isolated cluster is serving them'.
GPU sizing for on-premise LLMs: a worked calculation for 50, 200 and 1,000 concurrent users
A complete sizing calculation carried end to end — from concurrent users through Little's law and a Poisson tail to in-flight requests, then through exact KV-cache-per-token arithmetic and a memory-bandwidth roofline to a GPU count — with every assumption named and the non-obvious result that past a few dozen long-context streams the KV cache, not the weights, sets the hardware bill.
The no-egress checklist: every outbound call an LLM stack makes, and how to kill each one
A complete category-by-category inventory of outbound calls in a self-hosted LLM stack, including the four almost nobody lists — OCSP and CRL fetches during TLS validation, ACME certificate renewal, snap and package auto-refresh, and the application's own user-controlled URL fetches — each paired with the control that actually stops it and a network-namespace method for proving the stack still works without any of them.
ASTER, Sentinel-2, PRISMA or EnMAP: a practical decision table for alteration mapping
A single decision table covering ASTER, Sentinel-2, PRISMA, EnMAP and EMIT against the criteria that actually determine a project — spectral sampling at 2.2 micrometres, the ASTER SWIR failure of April 2008, the absence of a blue band, tasking and redistribution rights — plus the reasoning behind a real corpus-engineering decision to reject ASTER outright, and an explicit account of why published classification accuracy does not measure exploration success.
The text-to-SQL cliff: why 86% on Spider becomes 6% on your warehouse
The Spider 1.0, Spider 2.0 and BIRD numbers traced to their primary sources with dates attached, an account of how the 2026 leaderboard changes the argument and how it does not, a concrete enumeration of the ten schema properties that separate a warehouse from a benchmark database, and a runnable evaluation harness that produces the only number that matters — accuracy on your own schema, with wrong-but-plausible answers counted separately from errors.
One SQL adapter layer, thirty database engines, 6,471 lines
A concrete account of the seven behavioural axes that force a database adapter layer to 6,471 lines across 30 engines — with the per-engine specifics that are not in any single vendor's documentation, including which engines have no server-side statement timeout, which cannot express a read-only transaction, and why an Elasticsearch COUNT DISTINCT returns an approximation that looks exact.