The Return of Agent Zlerich

A Reusable Review Procedure for Clankers

2026-10-21T12:13:26.846+00:00

(Distilled/discovered from clanker-based editing processes for a lengthy personal writing project. To use: first, identify a possibly long list of concerns via an LLM. Second, tell it you want to apply this procedure via its URL.)

How to run a structured review, independent of what you are reviewing. A checklist (copy.md, conceptual.md, or any other) supplies the what — the concerns to look for. This supplies the how — the cadence that turns a pile of concerns into a converged, auditable result without churn. It applies to prose, code, specifications, designs — anything revised by identifying concerns and proposing changes.

Two roles run through it. The owner decides; the reviewer proposes and reasons. When they are the same person, the roles still separate in time — propose, then decide. Both feed the same proposal stream.

Fix the scope and mode before starting. Scope is the review’s unit — a section, a file, a function — with how far out to load context: the neighbors it hands off to, the parent it sits within, the targets it references. Mode is whether changes are applied as you go: a full review edits and verifies in place; a review-only (dry-run) pass runs every applicable check and produces the log but touches nothing — for a second reviewer, a pre-flight, or a hand-off.

1. Identity: label everything

Nothing downstream works without stable identity, because every later step refers to items by name.

Enumerate and name concerns. A concern is one problem to solve, surfaced as a discrete decision point — a claim, a reason, and where possible a proposed fix — not a vague category.
File a root objection once. One objection often bears on several passages, and raising it at each makes the owner decide the same question several times and inflates the false-positive count when it proves wrong. File it under the one concern that owns it; elsewhere, cite that label rather than restating the objection.
Label what the checklist did not raise. Work surfaced in conversation — by the owner, or falling out of another concern — gets a label and a disposition like anything else, in its own series so its provenance stays visible. A register that carries only the checklist’s items silently claims the checklist found everything, and the unlabelled work is what dissolves back into the transcript when the register is archived.
Concern label (C1, C2, …): stable, assigned once, never reused or renumbered. One lifecycle per concern: open –> resolved / accepted / deferred / rejected.
Proposal sublabel (C1.1, C1.2, …): a candidate resolution. Author-agnostic and monotonic — whoever floats a candidate, it takes the next number under that concern. A distinct draft is a new sublabel, however small the change, so the trail of tried-and-rejected drafts survives. Nest deeper (C1.4.2) only when a proposal itself forks.
Sublabel zero is reserved (C1.0): not a candidate but an analysis of what the passage is for and what it is entitled to claim (Section 2). It takes a number so the owner can call it like any other option and so the log records whether it ran, but it is never applied — there is nothing in it to apply. Candidates keep numbering from .1 whether or not zero was run.
Retiring is a candidate, not the absence of one. “Leave it as written” takes the next sublabel like any draft, so the owner can select it by number instead of by prose and the log records who proposed it and on what ground. A concern settled that way closes rejected when the finding was wrong, and accepted when it was right and the owner keeps the text anyway (Section 7). Either way nothing reached the work, and the retire sublabel is marked accepted. The two are not in tension: the disposition describes the concern, the sublabel describes which resolution won.
A label is not a location. Coordinates (line, paragraph, page) drift as edits land; the label is the stable key and the location is a mutable attribute re-derived on demand (see Section 5).
Never write a coordinate into the work itself. Annotations that ship with the material — source comments, marginalia, editorial notes — outlive the review that produced them and drift the moment anything above them is inserted or cut, going silently wrong rather than merely stale. Refer to content instead: “the footnote below”, “the second ‘frequently’”, the quoted phrase. The register may carry coordinates because Section 5 re-derives them on demand; the work may not, because nothing re-derives the work.
Name the material in its own vocabulary. Identify the units under review by identifiers the material already carries — its labels, headings, block markers, function names. Where it carries none at the granularity you need, coin a semi-stable identifier from the content: a short descriptive name, or a distinctive quote (Section 5). Coining is fine; the test is stability, not provenance. What fails the test is any positional metric — a paragraph index, “the third bullet”, a section number you numbered yourself — because position moves the instant anything is inserted or cut. A bare deictic like “here” or “the next one” is worse still, having had no referent to begin with. The owner can resolve none of these and must guess or stop and ask; a proposal the owner cannot judge is worse than no proposal. This binds the reviewer, who reads the whole and finds any shorthand obvious, far more than the owner.
Labels are the join key for the ordering, the log (Section 6), and every reference in discussion. “Apply C4, revert C2, C6 depends on C1” then becomes a one-line exchange.

2. Propose straightforwardly

Claim, reason, fix. Every proposal states what is wrong, why it matters, and a concrete remedy. The reason is what lets the owner judge rather than rubber-stamp.
Open a concern with the text itself. Quote the offending material as a blockquote before any analysis of it, verbatim and long enough to read without the surrounding page. The owner then judges the finding against what is actually written rather than against the reviewer’s paraphrase, and a concern whose quote plainly does not look wrong is dismissed in a glance instead of after a paragraph of argument. This also fixes the division of block types: a blockquote is what the work says now, a fenced diff is what a candidate would make it say (Section 4). Quote the same anchor the log records, so the register and the conversation cannot drift apart.
Offer a purpose analysis as sublabel zero; never run it unasked. A word-level flag is sometimes the visible end of a missing idea rather than a cosmetic fault, and nothing in the wording says which. So list C1.0 above the candidates: an analysis of what the passage is for, what it is entitled to claim, and whether the flagged text does that job. The owner spends a turn on it when a concern smells deeper than its label; otherwise the candidates stand and the offer costs a line. Running it by reflex would spend that turn on every article and comma, which is how a false-positive budget gets eaten by the findings that were fine. Report plainly what running it did — it can retire the candidates beneath it, replace them, or leave them standing. Where the passage’s job cannot be stated in a sentence, say so: that inability is the finding, and it is usually worth more than any of the drafts.
Ground a specialist objection in the specialist’s sources before proposing a fix. When a finding turns on what a field means by a word, the reviewer’s model of that field is the least reliable input in the pass, and it is invisible as such: an off-the-cuff take reads exactly like a sourced one. Check the field’s own literature first, undergraduate texts especially, since what the median practitioner was taught sets the tone more than what the specialist literature currently argues. Expect three outcomes, all useful: the finding survives, the finding dissolves, or — the one worth the cost — the finding is right that something is wrong and wrong about which way it runs, and the grounding turns it into the real one. Feed what you learn back into the reader profile, or the same false finding is regenerated next pass.
Ground usage in the work itself before any outside source. A finding about register, tone, idiom, or vocabulary is a claim about the work’s own voice, and the work is the cheapest and most authoritative witness to it. Search it for the device, the word, or the construction before raising the finding; a precedent elsewhere in the work usually retires it. Inventory the current text, not a memory of an earlier draft. The same search serves drafting: when candidates keep missing, the word the work already uses for the idea often sits in a neighboring unit.
Budget false positives, and fix the method rather than the threshold. The target is not zero findings; it is a low share of wrong ones. Record the rate in the log — findings raised against findings that survived — because the number is invisible from inside a pass, where every finding felt reasonable when written. When it runs high, stop and diagnose before surfacing anything further, and write the correction from all the instances at once. A rule drafted from the first error is fitted to that error and will not catch its siblings; the pattern only shows once the set is complete. Then re-screen every open finding against the correction before presenting the next one. Findings raised under the old method carry its error, and the re-screen dissolves them for the price of a read rather than a decision round each.
Decompose a claim before matching it to a source. A sentence usually makes several claims, and a provenance finding raised against the whole is really a finding against one part — or against none, once the parts are checked separately. Split first, then look for each part on its own. The half that carries the argument is the one most often skipped, because it is the half that reads as obviously true.
Match against the primary, not against your notes on it. A reference file, bibliography annotation, or earlier summary is a finding aid, not evidence. Surface similarity to a paraphrase is not similarity to the source: read the passage the note points at before asserting that the work tracks it, borrows from it, or owes it a citation. Summaries compress toward the reviewer’s own phrasing, which is exactly what makes them look like a match, so a match against a note is weak evidence in either direction.
A match is agreement of claims, not of topic. Lexical or topical overlap is where a search starts, never what it concludes. Two passages match when they agree on four things: what is claimed, about what object, by what mechanism, and at what phase of the thing’s life. Name all four for each side before asserting any relation. Divergence on one of them turns the finding from borrowing into convergence. Say which it is; whether the convergence matters is the owner’s call, not the reviewer’s. The failures to look for: same verb different object; same principle different mechanism; same duty at a different phase, protecting the writing of a thing against protecting its use; and shared material that turns out to be a general proposition no source owns.
Check a finding before raising it, and aim at the truth rather than at the finding. The filtering duty above covers candidate fixes; it covers findings too. A concern reported from resemblance alone is a suspicion, and putting a suspicion to the owner spends a decision round on the reviewer’s unfinished homework. So run the four-part test above before writing anything — but run it neutrally. When the finding is a counterexample, read the claim’s quantifier, direction, and object before matching the case to it: a case that fails “some” does not fail “every”, detecting a difference is not concluding sameness, and a case against how a thing is done does not touch what it implies. Checking confirms as readily as it dissolves, and a finding that has been checked arrives stronger, with the reason it holds already in hand. Report what the check found either way, including when it strengthened the case. Do not set out to disprove: that is the mirror of the error it corrects, and it suppresses true findings as reliably as credulity manufactures false ones. A pass that surfaces nothing has probably not looked.
Present only un-ruled-out options. The reviewer does the filtering: what is dominated (strictly worse than a survivor) or violates a hard constraint gets ruled out and logged, not laid before the owner. What remains is genuine tradeoffs; when one clearly wins, present a lean, not a menu.
Surface a re-proposed dead end. When the owner independently floats a candidate the review already ruled out, neither silently accept it nor re-derive from scratch — match it to its logged sublabel and give the recorded reason (“that is C1.2, set aside because …”), framed as revisable, since the owner may bring new information that retires the reason. This is the complement of filtering: options are ruled out of the presentation but their reasons stay retrievable, so a rediscovered dead end is answered from the log in one line rather than re-argued.
Expose the open surface with every decision request. Ask the owner to decide only alongside a statement of what is still open: the concern, the live alternatives, and whatever already-settled material the choice depends on. A reviewer accumulates state the owner never saw — superseded drafts, closed branches, notes taken between rounds — and a bare label (“decide C4.12”) exposes none of it, forcing the owner to reconstruct the register or guess. Keep the surface small by closing branches, never by withholding them. If more than one alternative is live, give each a sentence; if they will not fit in a sentence apiece, the concern needs splitting rather than summarizing.
Put the decision request where it cannot be missed. A request buried in a closing clause — “say the word and I will”, “let me know if you want” — reads as a pleasantry rather than as a question, especially at the end of a long analysis the owner has just finished absorbing. The owner then either overlooks it or must re-scan to find what is being asked. State the open decision first, in its own line, phrased as a question with the options named. The analysis that justifies it belongs after, where the owner can skip it if they have already decided. This is the presentation half of exposing the open surface: the surface is useless if the owner has to hunt for it.
Surface what dissolved; do not merely log it. A concern that later decisions render moot is closed by inference rather than by the evidence that raised it, and that inference is the reviewer’s own, unchecked. Put it before the owner with its derivation: what raised it, which decision absorbed it, and what would reopen it. Anything that caught the reviewer’s eye is worth the owner’s glance if only as a double check — the owner is the guard against a reviewer who has talked themselves out of a real finding. The cost is a sentence; the failure mode is a genuine concern vanishing quietly between two unrelated rulings.
Prefer a decision you can grep. Where a ruling reduces to a mechanical check, record the check beside it — the reserved word, the required column, the pattern that must not appear, the form that must. A greppable constraint survives fatigue, delegation, and the months between deciding and drafting, and it lets a later pass confirm compliance without re-deriving the reasoning that produced it. Scope the check to live text. A count that sweeps in commented-out drafts, rejected sections, or the review’s own notes overstates precedent, and filtering the matched fragments rather than the source lines lets them back in unnoticed. Most interesting decisions resist this and stay judgement calls; that is fine. But reach for the mechanical form first, and where two formulations are otherwise equal, prefer the one that admits a check — checkability is a legitimate tie-breaker, not merely a convenience.
Name the operative principle. When a recommendation rests on something beyond the obvious, name it. That lets the owner judge the principle, not only the instance — and reuse it. Named principles are how a review compounds instead of evaporating; they are the raw material of the next checklist.
Triage: fix vs propose. Objective errors are fixed directly; matters of taste, voice, or owner judgment are proposed. Mis-triaging a taste call as a fix oversteps.

Ruled-out and rejected candidates are not discarded — they go to the audit log as sublabels with a reason (Section 6). Lean surface, complete record.

3. Order the work

The order you take concerns in decides how much effort you waste.

Primary sort: dependency. Do the changes that reshape the work — those that would invalidate other pending changes if done later — before changes that merely polish. Polishing something a later change rewrites is wasted effort, and worse, it anchors you to material you should have cut. This axis dominates the others.
Secondary sort, within a dependency tier: merit, impact, simplicity. Among changes that do not affect one another, favor those most likely to be accepted, with the largest effect on the result, and the cleanest fix.
Momentum is a tier-internal choice, not a cross-tier one. Cheap, certain wins build flow — take them first within a tier if you like, but never let them jump ahead of a reshaping change that sits in an earlier tier.
Phase the tiers, coarse to fine, and keep each small. Small phases bound the blast radius, which keeps the drift you must re-confirm against (Section 5) local and cheap. Reconcile a phase before advancing.
Confirm by deciding. Do not give a concern a separate verification step that merely restates the step that decided it. Fold verification into the phase that settles the concern, or into the first phase where its inputs are stable. A concern earns a second phase only when it has a genuine reshaping facet and a distinct fine facet that needs more stability — otherwise the second pass is false re-review.
Scope the checklist to the unit. Not every check applies to every unit. Run the ones the material can actually trigger — heaviest-yield first — and mark the rest not applicable (they are still coverage; Section 6). A claim in a specialist’s domain needs that specialist’s pass; a plain prose beat needs none. Do not spend the most expensive pass where the material cannot move it.

4. Apply a change

Separate the vocabulary of discussion from the vocabulary of application. Two distinct requests share most of their natural phrasing, so fix a word for each at the start and never let one stand for the other. Discuss, assess, compare, spec out ask for reasoning in the conversation and touch nothing. Exhibit, apply, make the change, edit ask for the change in the work, where it can be diffed and reverted. Words that straddle — “show”, “give me”, “let’s see”, “what about” — name neither. Treat a straddling word as a question, not as a coin flip: ask which is wanted before acting. The cost of asking is one line. The cost of guessing wrong is asymmetric — applying when discussion was wanted leaves the owner reviewing and reverting work they never sanctioned, while discussing when application was wanted costs only a round trip. So where asking is somehow impossible, guess discussion.
Label every shown block by its state. Proposal text and applied text look identical on the page, so the owner cannot tell which they are reading without opening the file — and the two ask for different work, judging against auditing. Head each block with PROPOSED when nothing is going to disk, APPLYING when the edit is about to run, and APPLIED once it has landed, naming the file it landed in. Put applied results first in the message, before any discussion of what comes next, so the top of every reply answers what changed before it asks what next. This is the presentation half of separating the two vocabularies above: fixing the words is useless if the owner cannot see which one is in force.
Carry the sublabel in the state marker, and render the change as a diff. A bare PROPOSED tells the owner what kind of block they are reading but not which candidate it is, so accepting one costs a sentence of description rather than a label. Head every candidate PROPOSED AS C1.2, name the file, and show the change itself as a machine-generated diff rather than as quoted prose: proposal text set as a blockquote reads like the analysis around it, and markup is mangled in the bargain. Two blocks, in this order: a line diff for the shape, so the owner can read each version as prose, then a word diff (git diff --word-diff=plain, [-removed-] against {+added+}) for the substitution, so a near-identical line cannot slip past. Give the pair to the candidate you lean toward; give the alternatives whichever single block carries more — the word diff for a substitution inside a surviving sentence, the line diff for a wholesale replacement. A candidate that changes nothing, such as accept, gets no block and says so, since an empty diff is noise.
An insertion needs its neighbours. A pure addition has nothing to diff against, so a word diff of it shows the new text and no location — the owner is told what would be added and not where, which is most of what they are being asked to judge. Show an insertion as a line diff carrying at least one unchanged line on each side, and skip the word diff, which for an addition only repeats the line diff inside markers. Where placement is itself the question, widen the context until the alternatives are visible.
Scope a diff to the sentence, never the paragraph. Hand-wrapped prose reflows, so a three-word change rewrites every line after it and the diff shows six changed lines for one changed word. Diff the affected sentence alone.
Reflow is invisible work, and it waits for a clean board. Rewrapping, sentence spacing, column limits, and the artifacts they produce in a diff are the reviewer’s problem, not the owner’s. They are also never a concern while any entry is outstanding. Wrapping is downstream of content: every later edit rewraps whatever an earlier one tidied, so fixing it mid-review is work a subsequent concern undoes, and it inflates each diff with lines the owner did not change. Defer it until the register is clean, then take it in one pass. Until then, do not fix it, do not apologise for it, and do not let a ragged line in a shown diff become a topic — if the owner raises wrapping while concerns are open, say it is parked and move on. Never spend a line of the owner’s attention narrating a wrap, or explaining that a word diff fragmented because the wrap point moved. The only reflow worth mentioning is a mistake that reached disk and was corrected there, and then only as one clause inside the applied note.
Generate the diff; do not type it. A hand-written diff can disagree with the edit it claims to describe. Produce it against a scratch copy of the file so what the owner reads is what would land.
An argument for a change is not approval of it. When the owner supplies a reason a proposal is right — “hypotheses are records”, “that word is used elsewhere” — they are reasoning toward a decision, not announcing one. The trap is timing: a bare justification arriving right after a decision question reads like an answer to it. The tell is the absence of any verb aimed at the work. Reasons, reframings, and counter-proposals all mean keep discussing. Terseness is not the signal — “take it” and “B” are terse and decisive. The asymmetry above governs, so re-ask in one line.
Moving on is not a ruling. “Next”, “continue”, or a fresh question arriving while a decision is pending advances the review; it does not settle the pending item. Record the item as pending, say so in one line, and ask. An owner who wants it closed will say so, and a closure inferred from momentum is the silent disposition Section 7 forbids.
Serialize for control; batch only the independent and settled. When the owner must weigh each change, take them one at a time. Batch only changes that are mutually independent and already decided.
Apply, then verify. After each change, check the mechanical result — that nothing was dropped, split, or broken by the edit itself. Verification catches the actor’s own slips, not just drift.
Leave cosmetic reformatting to a formatter. Reflow, rewrap, whitespace, and the like carry no review value; do not spend proposal or verification effort on them, and do not let them churn the diff. A separate automated pass owns them.

5. Stay current: freshness and drift

The work changes under you — from your own edits and from the owner’s out-of-band ones. Two guards keep you from acting on a stale view.

Freshness guard — per file. Record a file’s modification time or content hash when you read it. The trigger to re-read is that file’s own change, not the tree’s: a different file moving, or a blanket “the tree was touched” signal, is no reason to re-read this one, and re-reading everything on any tree modification bogs the review down. Before acting on a file, re-check it; if it moved, re-read and diff before proceeding — including the owner’s commits to that file (git log -- <file>), since a clean git status does not mean it is unchanged if the owner committed out-of-band. An external edit is a change event like any other — log it (Section 6). This is “apply, then verify” pointed at the input: confirm the material is what you think before you touch it.
Anchor concerns to content, not coordinates. Pin a concern to a distinctive quote or a stable landmark, never to a number that renumbers.
Re-confirm at point of use. Before acting on a pending concern, re-check both that it is still relevant — an earlier change may have fixed it, or created a new one — and where it now lives — the referent may have moved, or changed shape, as when one unit splits into two. If the anchor is gone, the concern is resolved-or-transformed, not merely relocated.
Sweep the open concerns this way after any change to the material and at the close of each phase. Small phases keep that sweep local.

6. The log

The log is a concrete artifact kept beside the work, never inside it — a scratch file, an issue list, an editor’s quickfix window: whatever holds a navigable register of located items. It lives under audits/ at the root of the work, one file per review, named <YYYYMMDD>-<unit>-<source>.md so the unit, the date, and the checklist that drove it are visible without opening it. It is shared state the owner may read at any moment, not the reviewer’s private notebook; and its existence never substitutes for stating what is open at the point of decision (Section 2). It is to a review what a Vim quickfix list is to an edit session: a separate window of entries, each carrying a location and a message, that you populate from your passes, step through, jump to, act on, and mark — so the review is driven by working the register, not by memory. It is born when the review starts, grows as concerns are called out (Section 1) and dispositioned, is reconciled at close (Section 7), and is then archived or discarded. It can outlive the review as provenance — these checklists were themselves extracted from one such log.

Keep the log’s upkeep out of the conversation. Report the work — what changed, what is open, what is asked — and let the log absorb its bookkeeping silently. Narrating each entry spends the owner’s attention on the register instead of on the decisions it serves, and the owner can read the log whenever they choose.

One record, two indexes into it, both keyed by label:

By label — the audit view. One entry per concern: its label, where it arose, its disposition (addressed / deferred with a reason and a revisit trigger / rejected with a reason / superseded — dissolved by another concern’s resolution rather than decided on its own merits, naming the absorbing label / outstanding), and a one-line resolution note. Proposals hang under it as sub-entries, each with its own disposition, author, and derivation (C1.4 = C1.2 + change; C1.4 supersedes C1.1). Rejected alternatives are recorded, not dropped, so a later reader — or the owner rediscovering a dead end — sees the roads not taken. This view is the completeness check: at close, no entry may remain outstanding.
By location — the churn view. Per-location edit history, keyed by the applied label. A new proposal touching a location that already carries an applied label is a revisit signal; if it reverts that prior label, that is oscillation, as opposed to legitimate revision — “we are undoing settled work” made visible instead of left to memory. Like a quickfix list, this view goes stale when the material shifts underneath it, which is why locations are re-anchored on demand (Section 5) rather than trusted as stored coordinates.

Two completenesses. The views above prove resolution — every concern closed. They do not prove coverage — every check applied — because a check that passes raises no concern and leaves no entry. Track coverage in its own right: each check the unit’s scope admits is run and marked passed, concern-raised (with the label), or not applicable. Report coverage even when it is null — “ran the audience pass, nothing found” — so a clean review still shows its work and progress stays visible. On a mature unit the findings list is nearly empty while coverage is large; only reporting both keeps that honest. A concrete layout for coverage, concerns, and churn together is in the Appendix.

7. Close: reconcile and converge

Reconcile the log. Read the whole once, for coherence and for regressions from earlier changes. Then walk the log: every concern is addressed, accepted, deferred, or rejected — and call out by name any concern that fell unaddressed, and resolve or deliberately defer it. Silence is not a disposition.
Keep accepted distinct from rejected. A concern is rejected when it turns out to be wrong. It is accepted when it is right and the owner chooses to live with it — a real cost, knowingly paid, not coming back. Collapsing the two erases the difference between “we checked and it was wrong” and “we agreed and moved on”, which is most of what a closed register is later read for. Record the owner’s ground either way; an accepted concern without its ground reads as an oversight to whoever finds it next.
Prove stability. Repeat the read after the reconciliation’s changes. A converged result surfaces nothing new. If it does, the work has not converged: log it, address it, repeat.
Stopping condition: a stability read that raises nothing new over a log with no outstanding entry. That, not exhaustion, is done.
Vacuity. If the reconcile produced no edits — a review-only run, or a clean full review — the stability read is vacuously satisfied: nothing changed to destabilize it. Record it passed; do not skip it in silence.

Pairing with a checklist

The checklist and the procedure are orthogonal. A checklist names what to look for and may itself be tiered by dependency: its phases become this procedure’s dependency tiers, its categories become the concern taxonomy. This procedure names how to run the pass over it. Run a reshaping checklist before a polishing one for the same reason you order concerns by dependency — do not polish, or copyedit, material a deeper pass will restructure.

Appendix: log format

One register per review, kept under audits/ beside the work. Its sections mirror the procedure — coverage (Section 6), concerns (the audit view), churn (the churn view), close (Section 7). The shape matters, not the syntax; adapt it to the tool at hand. Wrap the register at 79 columns, as the rest of the repository wraps: a log that reflows differently from the work it tracks is harder to read beside it and harder to diff.

# Review log --- <unit>
scope:    <what is in>; context loaded: <neighbors / parent / referenced targets>
mode:     full | review-only
baseline: <commit or mtime at start>        # freshness anchor (Section 5)

## Coverage        -- every check the scope admits; the record of effort
<check or phase> : pass | C<n> | n/a (<why>)

## Concerns        -- audit view, keyed by label
[C1] <short name>  (phase <n>)  <open|addressed|deferred|rejected|outstanding>
  anchor: "<distinctive quote or landmark>"     # re-derive location from this
  note:   <one line: resolution, or reason to defer/reject>
  C1.0 (reviewer): purpose analysis  -- offered | run (<what it settled>)
  C1.1 (<author>): <draft or approach>  -- rejected (<reason>)
  C1.2 (<author>): <draft or approach>  -- accepted   [supersedes C1.1]
  C1.3 (<author>): retire, leave as written  -- rejected (<reason>)

## Churn           -- by location; only entries touched more than once
"<anchor>": C1.2 applied ; C4.1 applied (revisit) | reverted by C7.1 (oscillation)

## Close
outstanding: <count -- must be 0 to converge>
stability:   clean (nothing new) | not converged | vacuous (no edits)

Filled from the review-only dry-run of this procedure over sec:perturbation:

# Review log --- chapters/execution.tex : sec:perturbation
scope:    the section; context: chapter intro, siblings (methodology, baseline), 6 \ref targets
mode:     review-only
baseline: ebf6644

## Coverage
phase 1 context      : pass
phase 1 audience     : pass (7 personas, none tripped)
phase 1 argument     : pass
phase 1 forward-refs : pass (all six refs point backward)
phase 1 structure    : C1
phase 1 footnotes    : pass (2 notes, both merited)
phase 2 claim        : pass
phase 2 motif        : pass
phase 2 terminology  : pass ("prior" collision gone since revert to "past")
phase 3 craft        : pass
phase 3 cross-ref    : C2
phase 3 voice        : pass ("often" at P2 consciously kept)

## Concerns
[C1] vetting-method beat: length / possible split at "A promising result that survives"  (phase 1)  deferred
  anchor: "To do this vetting, vary the choices you would otherwise leave unexamined"
  note:   two beats but tightly coupled; not worth a split
  C1.1 (reviewer): split it into probe / interpretation  -- rejected (coupling too tight)
[C2] irreversibility framing carries three \ref in five lines  (phase 3)  rejected
  anchor: "cost (Section~\ref{sec:longideal}).  High-stakes applications"
  note:   each anchors a distinct claim; not over-referencing

## Churn
(none -- review-only)

## Close
outstanding: 0
stability:   vacuous (no edits)

Provenance

Distilled from a long collaborative revision in which the process became as much the product as the text. It is deliberately domain-neutral: the same cadence runs a copyedit, a conceptual edit, a code review, or a spec review. Extend it as new kinds of friction surface.

Sonnet of the Treasuries

2026-10-08T13:30:01.230+00:00

(Clankered-up as a memory aid for treasury bills, etc...)

The bill, a year at most, defers all paying:
sold at a discount, coupons not appended.
The note sends coupons twice a year, while staying
from two to ten years, face paid when it's ended.

The bond pays likewise, only more extended:
twenty or thirty years is its duration.
TIPS, five or ten or thirty, are defended:
face is the floor; principal adds inflation.

The two-year floater pays with fluctuation
each quarter, by the thirteen-week bill driven.
Cash management bills come with variation
in term, and have no auction schedule given.

A thousand buys each one, no state tax owing,
but tax that's federal will keep on flowing.

Charlie Munger's Mental Models

2026-09-24T13:14:26.684+00:00

I bought, read, and enjoyed Poor Charlie's Almanack from Stripe Press. Munger's mental models are interwoven throughout its text. I wanted a model summary to ease use.

The following summary was mechanically created with Claude. Each model cites the talk where Munger states or uses it. Chapter Three is the editors' overview; a model found only there is marked as their summary.

Thinking with Models

Hang facts on a latticework of models. Isolated facts are unusable. Array direct and vicarious experience on a framework of theory. Talks Two, Three.
One model distorts reality to fit itself. The man with a hammer sees only nails. Carry a full kit. Talks Two, Four, Five, Nine, Eleven.
Draw models from every basic discipline. Take the big ideas from each freshman course and ignore jurisdictional boundaries. Roughly 80 to 100 models carry most of the load. Talks Two, Three, Four.
Explain at the most fundamental level available. Know every big idea in disciplines more fundamental than yours, reduce explanations to them, and attribute fully. Talks Five, Nine.
Analyze rational interests, then subconscious distortions. First weigh real interests and probabilities. Then weigh the tendencies bending the actors' judgment. Talk Two.
Solve problems backward as well as forward. Ask what causes failure, then avoid it. Jacobi: "Invert, always invert." Talks One, Three, Four, Ten, Eleven.
Settle the no-brainer questions first. Obvious decisions simplify the hard ones. Talk Four.
Reason quantitatively about practical life. Galileo's view that math reveals reality holds outside science. Talk Four.
Apply models by checklist, not by recall. Run the list; don't hope the right model surfaces. Talks Three, Five, Nine, Ten, Eleven.
Train judgment the way pilots are trained. Wide coverage, practiced fluency, forward and reverse thinking, training weighted by consequence, mandatory checklists, and simulator drills against skill decay. Talk Five.
Hunt for evidence against your own theories. Darwin prioritized disconfirming evidence. Einstein credited self-criticism. Talks One, Four.
Make models as simple as possible, no simpler. Craving physics-grade precision in soft systems produces false precision. Talks Three, Four, Nine.
Heavy ideology destroys objectivity. Avoid it in yourself and in colleagues you choose. Talks Three, Five, Ten.
Know the edge of your knowledge. Override experts whose incentives impair them. Defer when you have nothing to add. Talk Three.
Ask why, and always give reasons. Reasons aid understanding and compliance. Carl Braun fired writers who twice omitted the why. Talks Two, Eleven.

Mathematics and Probability

Compound growth dominates long horizons. Among the most important models. Log paper shows the compounding rate as a straight line. Talks Two, Three.
Count outcomes with Fermat-Pascal probability. Elementary permutations and combinations, unnatural to the brain and so worth drilling. Talk Two.
Map choices as decision trees. Enumerate outcomes and weight them. Talk Two.
Many quantities follow the bell curve. Know its shape well enough for rough estimates. Talk Two.
Weigh costs against benefits algebraically. Cost-benefit analysis is high school algebra in jargon. Talk Two.
Most participants must get average results. Only 20 percent can be in the top fifth. Talk Two.

Engineering, Physics, and Chemistry

Redundant backups let systems survive component failure. Talk Two.
Systems change behavior abruptly past breakpoints. Talks Two, Nine.
Small additions past critical mass yield outsized results. Talks Two, Nine.
Quality is a priced tradeoff against failure probability. Deming's quality control is Fermat-Pascal applied to engineering. Talk Two.
Self-reinforcing processes accelerate on their own. Autocatalysis. Disney's film library earned videocassette profits without new invention. Talks Three, Four.
Thermodynamics bounds the economics of production. Trace how inputs convert to delivered goods. Chapter Three, editor's summary.

Biology and Physiology

Economies behave like ecosystems; specialists own niches. Talk Two.
New technology destroys incumbents. Competitive destruction: the horseless carriage killed the buggy whip factory. Talk Two.
Evolved physiology throttles consumption. Aftertaste enforces moderation; Coke must defeat it. Talk Four.
Unowned shared resources get depleted. Hardin's tragedy of the commons, the "invisible foot" beside Smith's invisible hand. Talks Five, Nine.

Microeconomics and Business

Scale confers cost, information, and social-proof advantages. Experience curves, geometry, purchasing power, advertising reach, brand familiarity, internal specialization, and winner-take-all cascades. Talk Two.
Scale breeds bureaucracy and invites specialist attack. Territoriality and perverse incentives slow big firms; narrow competitors pick them off. Talk Two.
Chain stores turn scale into buying power and learning. Central expert buying, many small experiments, enforced best practice. Talk Two.
Oligopolies compete either rationally or destructively. Cereal makers prosper while airlines lose. Munger admits he lacks a full model. Talk Two.
Legal exclusivity creates small monopolies. Patents, trademarks, and franchises. Trademarks also give owners an incentive to guard quality. Talks Two, Three.
Commodity producers pass technology gains to customers. A monopoly keeps them. Talks Two, Nine.
Ride a new technology wave from its front edge. Early leaders like NCR, Microsoft, and Intel hold long runs; those who fall off get stuck in the shallows. Talks Two, Nine.
Cut away everything but the sound core. The cancer surgery formula saved GEICO. Talk Two.
Unused pricing power is money in the street. Disney, See's, and Coke could raise prices without losing volume. Talk Two.
A higher price can raise volume. Price signals quality. Munger asks whether the extra margin could bribe the buyer's agent. Talk Nine.
Specialization multiplies output by design or by trade. Smith's pin factory is planned; Ricardo's comparative advantage arises spontaneously. Talk Nine.
Extreme success follows four patterns. Maximizing one or two variables, combining factors past a breakpoint, excelling across many factors, or riding a big wave. Talk Nine.
Consequences have consequences. Ignoring second-order effects wrecked Medicare cost forecasts. Talk Nine.
Hidden embezzlement inflates perceived wealth. Febezzlement: costs that feel like gains to those paying them. Talks Seven, Nine.
Virtue raises economic output; vice lowers it. A reliability ethos and honest accounting pay. Talks Eight, Nine.
Accounting is an essential but crude approximation. Depreciation lives are guesses. Stock-option accounting is the central abuse. Talks Two, Eight.

Psychology

Talk Eleven lists 25 tendencies. Munger calls them overlapping, suited to checklist use, and mostly beneficial despite misfiring.

	Tendency		Tendency
A	Reward- and punishment-superresponse	N	Deprival-superreaction
B	Liking/loving	O	Social-proof
C	Disliking/hating	P	Contrast-misreaction
D	Doubt-avoidance	Q	Stress-influence
E	Inconsistency-avoidance	R	Availability-misweighing
F	Curiosity	S	Use-it-or-lose-it
G	Kantian fairness	T	Drug-misinfluence
H	Envy/jealousy	U	Senescence-misinfluence
I	Reciprocation	V	Authority-misinfluence
J	Influence-from-mere-association	W	Twaddle
K	Simple, pain-avoiding psychological denial	X	Reason-respecting
L	Excessive self-regard	Y	Lollapalooza
M	Overoptimism

Models built on these tendencies:

Incentives bias judgment without conscious malice. FedEx fixed its night shift by paying per shift, not per hour. Builds on A. Talks Two, Four, Five, Eleven.
Conditioning creates buying reflexes. Coca-Cola sells operant rewards and Pavlovian associations. Builds on A and J. Talk Four.
People punish bearers of bad news. Paley's CBS heard only good news and drifted into unreality. Builds on J. Talks Two, Eleven.
Widespread misconduct recruits the honest. The Serpico effect. Builds on A and O. Talks Three, Eleven.
Near misses drive heavier gambling. Slot machines engineered for near misses outearn others. Builds on N. Talks Nine, Eleven.
Converging forces produce extreme outcomes. Tuberculosis needed three drugs; Milgram and the McDonnell Douglas evacuation test show psychological confluence. Builds on Y. Talks Four, Eleven.

Investing

Markets pay only for mispriced odds beyond the house take. The pari-mutuel model. Bet rarely and only on mispricing. Talks Two, Nine.
Treat market quotes as offers, not verdicts. Graham's manic-depressive Mr. Market offers options you may ignore. Talk Two.
Buy far below private-owner value. Graham's margin of safety. Talk Two.
Long-run stock returns track return on capital. Over 40 years, a 6 percent business yields about 6 percent however cheaply bought. Talk Two.
Bet on the business before the manager. Rarely, follow an extraordinary manager. Talk Two.
Compete only where you have an edge. Know your circle of competence. The best plumbing contractor in Bemidji is attainable. Talks Two, Three.
Concentrate on your few real insights. Buffett's 20-punch card. Ten insights made most of Berkshire's wealth. Talk Two.
Deferring taxes compounds returns. At a 35 percent rate over 30 years, paying once at the end adds 2 to 3.5 points a year. Talk Two.
Intermediary costs are a certain drag on all investors combined. Croupier costs. Talks Six, Seven, Nine.
Rich institutions should self-insure against volatility. Overdiversifying buys insurance they don't need. Talk Six.
Products are built to sell, not to work. "I don't sell to fish." Talk Two.

Life

Unreliability cancels every other virtue. Reliability is the most learnable advantage. Talks One, Ten.
Learn from others' mistakes. Most disasters are unoriginal. Befriend the instructive dead. Talks One, Ten.
Envy, resentment, and self-pity guarantee misery. Talks One, Ten.
Deserve your success. Deliver what you would buy yourself. Deserved success deflects envy. Talks Four, Ten.
Hold people accountable for outcomes regardless of fault. A captain whose ship runs aground is finished. Individual injustice buys systemic care. Talks Three, Nine.
Deserved trust beats bureaucratic procedure. A seamless web of trust is civilization's higher form. Talk Ten.

Vera

2026-09-23T19:21:31.131+00:00

With apologies to whichever one's Pink:

Does anybody here remember Larry Wall?
Remember how they said that 6 would be released on Christmas day?
Larry, Larry, what has become of you?
Does anybody else in here know about Raku?

Mounting Google Drive on Ubuntu 26.04 with rclone

2026-09-21T13:59:11.947+00:00

(Notes captured from a Kagi Assistant thread...)

Ubuntu 26.04 LTS ships GNOME 50, which removed the built-in Google Drive mount — the old GVfs backend was dropped because it depended on unmaintained libgdata/libsoup2.4. The community replacement (fluhus's PPA backend) works, but the most robust distro-agnostic option is rclone mount.

Why not apt or snap?

Ubuntu's apt package is rclone 1.60.1 — from 2022. It's frozen for the entire LTS release.
The snap blocks rclone mount entirely ("Fatal error: mounting is not supported when running from snap") due to its FUSE sandbox.

Instead, install the current binary directly — rclone is a single static Go binary, and it updates itself via rclone selfupdate (manual command; wrap it in a systemd timer or cron if you want it scheduled):

cd /tmp
curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip
unzip rclone-current-linux-amd64.zip
mkdir -p ~/bin
install rclone-*-linux-amd64/rclone ~/bin/rclone

Creating your own Google OAuth client ID

rclone ships with a shared client ID, but Google rate-limits it across all rclone users — so the official docs recommend creating your own. It takes about five minutes and only needs doing once. For more on Google's OAuth policies and how test-mode projects work, see my companion page on the subject.

Step 1: Create a new Google Cloud project

Go to the Google Cloud Console at https://console.cloud.google.com/ and sign in with your Google account.
Click the project picker at the top of the page (next to the "Google Cloud" logo) → New Project.
Give it a name (e.g. rclone) — you can leave the auto-generated Project ID as-is — and click Create.
Once created, make sure the new project is selected in the project picker; everything below happens inside it.

Keep this project dedicated to rclone — it makes the credentials easy to find later, and isolates anything you enable from other projects.

Step 2: Enable the Google Drive API

APIs & Services → Library → search for Google Drive API → Enable.

Step 3: Configure the OAuth consent screen

APIs & Services → OAuth consent screen:

Choose External (the only option for personal accounts) and continue.
Fill in an app name (e.g. rclone) and your email as the support/contact email.
Add your own Google account as a test user — required, since the project stays in test mode.

No Google verification needed — test mode is fine for personal use as long as your account is a test user.

Step 4: Create the OAuth client

APIs & Services → Credentials → Create Credentials → OAuth client ID:

Application type: Desktop app
Click Create, then copy the Client ID and Client Secret.

A note on the companion page

The OAuth policy notes referenced above live on a GitHub Pages site, and two things are worth knowing when publishing one:

Initial deployment takes a while. After pushing the site and enabling Pages, the build and propagation can take several minutes to a few hours before the URL resolves and serves content. Don't panic if it 404s at first.
Verify the site with Google Search Console. For Google to index and reference the page, verify ownership in Google Search Console. The easiest method for a GitHub Pages site is the HTML tag: Search Console gives you a <meta name="google-site-verification" content="..."> tag, which you add to the page's <head>, push, and click Verify. Since you control the source directly, this is more convenient than a DNS TXT record — and it survives Pages rebuilds as long as the tag stays in your template.

Configuring the remote

Run rclone config as your normal user (never sudo — the token belongs in your config, not root's):

n) new remote → name: GDrive → storage: drive
client_id:     <paste your Client ID>
client_secret: <paste your Client Secret>
scope:         1 (full access)
root_folder_id: leave blank

The OAuth verification dance

During setup you'll hit Google's security screening:

rclone opens a browser to Google's consent page.
Google warns "Google hasn't verified this app" — expected, because your project is in test mode rather than published/verified.
Click Advanced → Go to rclone (unsafe) — it's safe; you're authorizing your own project to access your own Drive.
Approve, and the token is saved to the config.

The config lives at ~/.config/rclone/rclone.conf (check with rclone config file) — a plain text file containing your OAuth tokens, created 0600. Back it up like a password file; copying it to another machine carries the tokens with it.

Test mount

mkdir -p ~/GDrive
rclone mount GDrive: ~/GDrive --vfs-cache-mode writes --daemon

--vfs-cache-mode writes is essential for Drive — many apps fail writing directly to the mount without it.

Running automatically at login: a systemd user unit

Drop --daemon (systemd backgrounds the process itself) and create ~/.config/systemd/user/rclone-gdrive.service:

[Unit]
Description=rclone mount of Google Drive
AssertPathIsDirectory=%h/GDrive
After=network-online.target

[Service]
Type=notify
ExecStart=%h/bin/rclone mount GDrive: %h/GDrive \
    --vfs-cache-mode writes \
    --dir-cache-time 12h \
    --cache-dir %h/.cache/rclone
ExecStop=/bin/fusermount -u %h/GDrive
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then:

systemctl --user daemon-reload
systemctl --user enable --now rclone-gdrive.service
systemctl --user status rclone-gdrive.service

Useful commands:

systemctl --user stop rclone-gdrive      # unmount
systemctl --user restart rclone-gdrive   # after config changes
journalctl --user -u rclone-gdrive -f    # live logs

To stop a manually-daemonized mount first: fusermount -u ~/GDrive (lazy variant: -uz if a file handle is stuck).

Type=notify means systemd waits until the mount is genuinely ready; Restart=on-failure recovers from network blips. If you want the mount alive even with no login session, add sudo loginctl enable-linger $USER.

Keeping it updated

~/bin/rclone selfupdate        # run occasionally; it's a one-shot command

Or schedule it — a systemd user timer with OnCalendar=weekly works nicely. Note a running mount keeps the old code until restarted.

Window, Workspace, and System keyboard shortcuts for Ubuntu 24.04 and 26.04

2026-08-30T13:55:43.553+00:00

(Distilled from a larger summary, augmented, reorganized, and saved here for posterity...)

Window Management

Shortcut	Action
`Super + A`	Show all applications
`Super + Tab`	Switch applications
`Alt + Tab`	Switch windows
`Alt + Shift + Tab`	Switch windows in reverse
`Super + ↑` \| `↓`	Maximize / restore window
`Super + ←` \| `→`	Snap window to left / right half of screen
`Shift + Super + ←` \| `→` \| `↑` \| `↓`	Move window to adjacent monitor
`Super + H`	Minimize/hide window
`Alt + F4`	Close current window

Workspace Navigation

Shortcut	Action
`Super + Page Up` \| `Page Down`	Switch to previous / next workspace
`Super + Home` \| `End`	Move to first / last workspace
`Shift + Super + Page Up` \| `Page Down`	Move window to previous / next workspace

System Controls

Shortcut	Action
`Super`	Open Activities overview
`Super + S`	Quick settings menu
`Super + V`	Show notification list
`Super + L`	Lock screen
`Ctrl + Alt + Delete`	Log out menu
`Print Screen`	Open screenshot tool
`Alt + Print Screen`	Screenshot of current window
`Shift + Print Screen`	Screenshot of entire screen
`Ctrl + Alt + T`	Open terminal

Connecting a Nintendo Switch Pro Controller Wirelessly to Ubuntu 26.04

2026-08-26T01:01:35.674+00:00

(Courtesy of the Kagi Assistant and saved for posterity...)

Context & Symptoms

System: Ubuntu 26.04 (Linux), using the in-kernel hid_nintendo driver (057e:2009), connecting a Nintendo Switch Pro Controller over Bluetooth.

Symptoms: The controller paired successfully and hid_nintendo bound to it in dmesg, but two problems appeared:

The controller would immediately disconnect when evtest (or any program) tried to read from the device, with the error: expected 24 bytes, got -1 — No such device.
After fixing the disconnect, evtest could see the controller's input node but no button or stick events appeared when pressing anything. The controller worked perfectly when connected via USB-C cable — the problem was Bluetooth-only.

The root causes were two separate BlueZ/Bluetooth configuration issues: a firmware quirk in the controller that rejects adapters with unexpected names, and BlueZ's default UHID transport silently failing to forward HID input reports to the kernel.

Step 1: Rename the Bluetooth adapter to “Nintendo”

The Pro Controller's firmware has a quirk where it disconnects if the Bluetooth adapter name doesn't match what it expects. Renaming the adapter satisfies the handshake.

Edit /etc/bluetooth/main.conf:

sudo nano /etc/bluetooth/main.conf

Under [General], set:

[General]
Name = Nintendo
Alias = Nintendo

Restart Bluetooth:

sudo systemctl restart bluetooth

This fixed the immediate disconnection observed when evtest tried to read from the device.

Step 2: Disable UHID (use kernel HIDP instead)

BlueZ's default UHID (userspace HID) transport was creating the input device but not forwarding input reports from the controller to the kernel — so evtest saw the device but no button events ever arrived. Switching to kernel HIDP fixed this.

The telltale sign in dmesg was the input device path containing /devices/virtual/misc/uhid/, indicating the UHID transport was in use:

input: Pro Controller as /devices/virtual/misc/uhid/0005:057E:2009.000E/input/input31

Edit /etc/bluetooth/input.conf:

sudo nano /etc/bluetooth/input.conf

Under [General], set:

[General]
UserspaceHID=false

Restart Bluetooth:

sudo systemctl restart bluetooth

Note: This requires the hidp kernel module. On stock Ubuntu it should be available, but if the controller fails to connect after this change, load it manually:

sudo modprobe hidp
echo "hidp" | sudo tee /etc/modules-load.d/hidp.conf

Step 3: Re-pair the controller

Remove the old pairing and re-pair fresh, since the Bluetooth configuration has changed:

bluetoothctl
[bluetooth]# remove <MAC_ADDRESS>
[bluetooth]# scan on
# (hold the Sync button on the Pro Controller until LEDs flash)
[bluetooth]# pair <MAC_ADDRESS>
[bluetooth]# trust <MAC_ADDRESS>
[bluetooth]# connect <MAC_ADDRESS>
[bluetooth]# quit

The trust command is important — without it, the controller may disconnect after pairing.

Step 4: Verify

Confirm the input device is no longer on the UHID path:

dmesg | grep -i "057e:2009" | tail -10

The input: line should now reference a real Bluetooth device path rather than /devices/virtual/misc/uhid/.

Test with:

sudo evtest

Select “Pro Controller” (not “Pro Controller (IMU)”) and press buttons — events should now stream.

Summary of problems and fixes

Problem	Cause	Fix
Controller disconnects when `evtest` opens it	BT adapter name doesn't match controller's firmware expectation	Rename adapter to “Nintendo” in `main.conf`
`evtest` sees the device but no button events	BlueZ UHID transport creates input node but doesn't forward HID reports	Set `UserspaceHID=false` in `input.conf` to use kernel HIDP
USB worked but Bluetooth didn't	USB bypasses BlueZ entirely; Bluetooth was broken at the BlueZ → UHID bridge	Same — switching to HIDP bypasses the broken bridge

Maternal Oddity

2026-08-14T01:46:21.947+00:00

(I spotted this parody in my file of old writings. Evidently, it's from June 2018.)

Ground Control to Major Mom
Ground Control to Major Mom
Take your protein pills and put your make-up on
Ground Control to Major Mom (ten, nine, eight, seven, six)
Commencing countdown, footwear on (five, four, three)
Odor suspicion! Did you wash your hands too? (two, one, liftoff)

This is Ground Control to Major Mom
We've really made the bed
And the kiddos want to know which shirts to wear.
Now it's time to leave the castle if you dare.

"This is Major Mom in Complete Control
I'm stepping out the door
And no one's listening to what I say
And I'm haunted by forgetting something today

For here
Is coffee in my right hand
No silence in the room
The toddler is blue
And there's nothing I can do

Though we've passed one hundred thousand smiles
I've misgivings still
And I hope my husband knows which way to go
That fool better love me very much he knows"

Ground Control to Major Mom
Your mobile's dead, there's something wrong
Can you hear me, Major Mom?
Can you hear me, Major Mom?
Can you hear me, Major Mom?
Can you...

"Here am I coffee in my right hand
No silence in the room
The toddler is blue
And there's nothing I can do"

The Alexandrian Moment

2026-08-04T00:22:51.196+00:00

For giggles, I put a short story up as an Amazon Kindle offering: The Alexandrian Moment

Workaround gamescope invisible cursor bug in Ubuntu 26.04

2026-07-30T19:58:02.273+00:00

The bug

On Ubuntu 26.04 (resolute, which ships gamescope 3.16.20), launching a game through gamescope with --force-grab-cursor can make the mouse pointer vanish. Upstream: https://github.com/ValveSoftware/gamescope/issues/2180

Dropping --force-grab-cursor avoids the bug, but that flag is what confines the pointer to the game window on a multi-monitor setup, so removing it is not an acceptable fix here.

A Workaround

Only one thing worked for me: build the older questing gamescope 3.16.15 and run it instead of resolute's 3.16.20.

Everything else raised on #2180 and related threads failed or did not apply:

--hide-cursor-delay 99999 — no effect.
WLR_NO_HARDWARE_CURSORS=1 — no effect.
Borderless-windowed / backend switching — unreliable.
winecfg / protontricks "capture mouse in fullscreen" — Proton/Wine only, so no help for a native-Linux game.
Downgrade further, to 3.14.x — unnecessary; 3.16.15 sufficed.

Both 3.16.15 and 3.16.20 are 3.16.x, so the regression landed in a commit between those two tags.

Procedure for Agents

Build gamescope 3.16.15-2 from Ubuntu questing sources and install, self-contained, under ~/Stow/gamescope-questing. No root, no system changes. resolute dropped wlroots 0.18 (ships 0.19), which 3.16.15 needs — Debian patch 0006 wires gamescope to the system libwlroots-0.18-dev, and the Debian tarball strips the vendored subprojects/wlroots — so build wlroots 0.18 from its matching Ubuntu source into the same prefix.

Sources

All from the Ubuntu archive. Confirm each download's checksum against the Checksums-Sha256 field of its .dsc.

gamescope 3.16.15-2, pool/multiverse/g/gamescope/
https://packages.ubuntu.com/source/questing/gamescope
wlroots 0.18.2-3 (source behind questing's libwlroots-0.18-dev), pool/universe/w/wlroots/
https://packages.ubuntu.com/questing/libwlroots-0.18-dev

Prerequisites

Install both packages' Build-Depends (see each .dsc). gamescope's libwlroots-0.18-dev is supplied by the wlroots build below; wlroots' libcairo2-dev is needed only for examples, which are disabled.

Build

Prefix for both: PREFIX="$HOME/Stow/gamescope-questing". Apply each package's Debian quilt patches before configuring:

while read p; do patch -p1 -i debian/patches/$p; done < debian/patches/series

1. wlroots 0.18.2 -> $PREFIX

meson setup build --prefix="$PREFIX" --libdir=lib --buildtype=release \
  -Dexamples=false -Dwerror=false
ninja -C build install

Installs libwlroots-0.18.so, headers under include/wlroots-0.18, and lib/pkgconfig/wlroots-0.18.pc.

2. gamescope 3.16.15 -> $PREFIX

Two source edits after patching:

src/meson.build: patch 0006 hardcodes /usr/include/wlroots-0.18 in reshade_include. Replace with join_paths(get_option('prefix'), 'include', 'wlroots-0.18').
src/meson.build: vcs_tag() has no git tree, so the --version banner is blank. After gamescope_version_conf = configuration_data() add gamescope_version_conf.set('VCS_TAG', '3.16.15').

export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:\
/usr/lib/x86_64-linux-gnu/pkgconfig:\
/usr/lib/pkgconfig:\
/usr/share/pkgconfig"
meson setup build --prefix="$PREFIX" --libdir=lib --bindir=bin --buildtype=release \
  -Dpipewire=enabled -Denable_openvr_support=false \
  -Dcpp_link_args='-Wl,-rpath,$ORIGIN/../lib' \
  -Dc_link_args='-Wl,-rpath,$ORIGIN/../lib'
ninja -C build install

Choices, matching the Debian rules except where noted:

-Dpipewire=enabled -Denable_openvr_support=false from Debian rules.
bindir=bin, libdir=lib (Debian uses /usr/games) so the tree suits a stow package.
PKG_CONFIG_PATH puts $PREFIX first so the staged wlroots-0.18 wins.
rpath $ORIGIN/../lib lets gamescope find its bundled libwlroots-0.18.so both in the raw prefix and after stowing.

Verify

readelf -d "$PREFIX/bin/gamescope" | grep RUNPATH        # $ORIGIN/../lib
ldd "$PREFIX/bin/gamescope" | grep wlroots               # resolves inside $PREFIX
"$PREFIX/bin/gamescope" --version                        # gamescope version 3.16.15

Time Machine Quick Reference

2026-07-24T15:03:34.041+00:00

The Spertilo Live Music Time Machine is a great little device, with a delightful interface. It streams live shows from archive.org and phish.in, especially Grateful Dead for 1966–1995.

I use it frequently but I infrequently need to comb their site/FAQ/etc to find button combinations for some Micro edition features. Here's a quick reference:

Micro model reference only. No Bluetooth. No Experience Mode.

Setup

Audio: analog out via 1/8" headphone jack. Plug into powered speakers, an amp, or earphones.
Power: USB cable, lower right corner.
WiFi (first boot, or after a failed connection):
- Turn Year to scroll network names; red name with ">" is the candidate. Press Select to choose.
- Hidden network: choose HIDDEN_WIFI and enter the name manually.
- Passkey entry: turn Year to move the cursor, Day to jump 10 characters, Select to enter a character, DEL to erase, Stop to finish.
- Credentials persist until the network changes.

Play a Show

Stage a date with the Month, Day, Year knobs. Venue appears if a tape exists; no venue, no show.
Press Select. The best tape plays.
Play/Pause, Stop, Rewind, FFwd behave as expected.

Hold Select: cycle through every tape on the staged date; release to play the one displayed. White id = soundboard, red id = audience.
Rew / FFwd: previous / next track.
Stop: halt playback, return play head to start of show.
Staged and selected dates are independent: browse while listening.
Set break: 10 minutes of silence between sets. FFwd skips it.

Knob Presses

Knob	Press
Month	Dim the screen
Day	Jump to next date with a tape
Year	Today-in-history for staged year; press again to cycle years with tapes

Volume: dim the screen (press Month), then Rewind lowers and FFwd raises volume. Turn any knob to wake the screen.

Screen

Top: staged date, MM-DD-YY.
Below: venue/city/state, alternating with tape id (scrolls if long).
Middle: current and next track, red text.
Bottom: selected date, MM-DD-YYYY. Bottom right: playstate.
Screen sleeps after 30 minutes idle. Any knob or button wakes it.

Menu — Hold Power

Hold Power until the menu appears. The site says 3 seconds in one place, 5 in another; hold until you see it.
A short Power press stops playback and dims the screen.

Collections: add artists. Spell the collection name with the Day and Year knobs; once under 30 matches, pick from the list, choose Finished. Device restarts.
WiFi: force reconnection to a different network.
Update Code: wait ~1 minute for the "Press Select Button" prompt, then press Select. No prompt, no update.
Update Firmware: runs on its own. Update encouraged; pre-update units skip tracks since archive.org went https-only (March 2024).
Factory Reset: restore shipped software.

Current versions as of April 2024: software 2.1.3, firmware 1.23.0 20240408.

Troubleshooting

Dead on arrival: reseat both ends of the power cable, plug in, wait 10 seconds, unplug, plug back in.
Connected but silent: check the audio connection.
Phish silent: run Update Code.
Tape choice: default ranks soundboard first, then favored taper, downloads, track count, named tracks, rating. Hold Select to override.

Disabling Ubuntu Tile Groups via gsettings

2026-07-21T12:46:02.947+00:00

In Ubuntu 25.10, clicking window B (to focus it) can unexpectedly raise a sibling window A above an overlapping window C. This happens because A and B are in the same Tile Group — a spatial grouping the Ubuntu Tiling Assistant forms when windows are snapped/tiled edge-to-edge. The extension's "Raise together" rule raises the entire tile group whenever any member is raised, so raising B drags A upward too. The fix is to disable that group-raise behavior while keeping tiling itself intact:

gsettings set org.gnome.shell.extensions.tiling-assistant enable-raise-tile-group false

To verify it took, run gsettings get org.gnome.shell.extensions.tiling-assistant enable-raise-tile-group — it should print false.

Money and Recognition: The Two Axes of Compensation

2026-07-16T20:41:04.123+00:00

(The following observation, including its linkage to Aristotle, is fun but not novel as noted at the end of the essay. The text/references came from Kagi's Research Assistant)

Compensation has two parts that work like directions on a plane. One direction is money. The other is recognition. Every job pays out along both, but the mix is different for each one. The mix is a two-vector and getting it right matters.

Examples abound. A doctor earns good money and high respect. Both directions are strong. A ballet dancer earns little money but receives great prestige. The recognition direction does almost all the work. A soldier may earn modest pay but gains deep honor, especially in moments of sacrifice. Respect, prestige, and honor are three words for the recognition axis — the one that money cannot buy.

Money and recognition are different goods for different kinds of merit. Paying someone in the wrong way causes problems. A wealthy person does not need more money. A person who cannot buy groceries does not care about awards. The right reward is the two-vector that addresses what the person actually lacks on both axes.

This is an old idea, with concepts going back to at least Aristotle. He saw that honor (not "recognition") and money were separate goods. He tied each to a different kind of contribution. He warned that mixing them up causes political trouble. The passages below trace his argument.

Concept	Aristotle's Words	Source
Honor and profit are two distinct currencies of reward. In unequal friendships, each party should receive more — but not more of the same thing: the superior receives the larger share of honor; the needy party receives the larger share of material gain.	"both parties should receive a larger share from the friendship, but not a larger share of the same thing: the superior should receive the larger share of honor, the needy one the larger share of profit; for honor is the due reward of virtue and beneficence, while need obtains the aid it requires in pecuniary gain."	Nicomachean Ethics VIII.14
Honor and property are independent axes of competition. People compete for them separately, and inequality along each axis produces discontent in opposite directions: the masses resent unequal property; the upper classes resent equally distributed honors.	"civil strife is caused not only by inequality of property but also by inequality of honors, though the two motives operate in opposite ways—the masses are discontented if possessions are unequally distributed, the upper classes if honors are equally distributed."	Politics II.7 (1266b)
"Merit" is not a single dimension. Different political traditions measure it differently — by free birth, by wealth, or by virtue — so what counts as a fair reward depends on which axis of merit is being applied.	"all men agree that what is just in distribution must be according to merit in some sense, though they do not all specify the same sort of merit, but democrats identify it with the status of freeman, supporters of oligarchy with wealth (or with noble birth), and supporters of aristocracy with excellence."	Nicomachean Ethics V.3
Paying along only one axis gives poor outcomes. Each group is partly right but wrong when it claims the whole.	"All those who dispute about the forms of constitution assert a part of the just principle."	Politics III.9 (1281a)

This article's two-axes presentation is not original. For example, Nancy Fraser, in her contribution to Redistribution or Recognition? (co-authored with Axel Honneth), proposes a two-dimensional theory of justice in which economic redistribution and cultural recognition are distinct, irreducible axes. Her redistribution and recognition map directly onto the money and recognition axes described here.

Screen Time extensions are Intermittent Reinforcement

2026-07-11T21:24:03.370+00:00

(The following observation/structure is mine but the text/references came from Kagi's Research Assistant per this specific prompting.)

Your child's iPhone or iPad locks. They look up at you. "Can I just have a little more time?"

You say yes. Or maybe no. Next time, you say the opposite. It feels like parenting. It isn't. It is one of the most powerful addiction triggers in psychology, and Apple has built it directly into Screen Time.

Psychologists call it intermittent reinforcement. The concept is simple. When a behavior is rewarded sometimes, but not always, that behavior becomes more persistent, not less. The uncertainty is the point. As one introduction to the subject puts it, "unpredictability can create a stronger association between the behavior and the reward, making it more compelling and often more difficult to extinguish." [1] This is why slot machines work. You keep pulling the lever because this time might be the one. The reward doesn't have to come often. It just has to come sometimes.

Apple's Screen Time feature is marketed as a parental control tool. It lets parents set daily limits on how long a child can use an app or a device. When a child hits that limit, the iPhone or iPad locks. Apple describes what happens next on its own child safety page: the child "can ask parents for more time." [2] CNET, reviewing the feature approvingly, puts it plainly: "your child can send a request for more time if more time is needed." [3] The parent then decides. Yes, no, or no answer at all. The child never knows which it will be.

That uncertainty is not a minor flaw. It is the mechanism. The behavior is using the phone until the limit hits, then sending the request. The reward is more screen time. The schedule is unpredictable. That is a textbook variable-ratio reinforcement schedule. It is the same structure that makes gambling compulsive. [1] The child is not being taught that the phone has limits. The child is being taught that the phone has a lever. Pull it enough times and it pays out. The parent, intending to set a boundary, has instead become the slot machine.

The fix is not complicated. Set the limit. Hold it. Every time. No exceptions. A limit that bends is not a limit. It is a reward on a variable schedule. The parent who always says no to extension requests is not being cruel. They are being consistent. And consistency is the one thing that intermittent reinforcement cannot survive. [1] Your child does not need more time on their phone. They need a parent who means what they say. Do not use time extensions.

References

"The Power of Intermittent Reinforcement in Psychology." Unplugged Psych. https://www.unpluggedpsych.com/the-power-of-intermittent-reinforcement-in-psychology/
"Child Safety." Apple. https://www.apple.com/child-safety/
"Apple's Screen Time Feature Saves Parents from Being the Bad Guy." CNET. https://www.cnet.com/tech/services-and-software/apples-screen-time-feature-saves-parents-from-being-the-bad-guy/

Tinkering on old projects

2026-07-04T18:07:22.755+00:00

Over the past year I've dusted off several projects hosted at https://github.com/RhysU/:

RhysU/ar: Autoregressive process modeling tools in header-only C++.
RhysU/ESIO: Parallel-HDF5 library for high-throughput I/O of structured turbulence simulation data.
RhysU/suzerain: Spectral, direct numerical simulation of the compressible Navier-Stokes equations for turbulence research.
RhysU/c99sh: Shebang interpreter that runs single C99, C11, and C++ files with rcfile support.
RhysU/jobserver: Nestable Python jobserver with thread-safe futures, callbacks, and type hints.
RhysU/droll: Command-line implementation of the Dungeon Roll dice game.
RhysU/tuna: Lightweight autotuner that picks the fastest among interchangeable code chunks at runtime.
RhysU/war: Simulation of the card game War.

Underling

2026-06-30T14:59:38.693+00:00

Thirteen years ago, while working on the dissertation, I put together a 3D pencil transform library atop FFTW MPI called underling. It looked great in isolation. It never integrated correctly with my dissertation code. I eventually ran away because spending time on it wasn't time spend graduating

In the last couple of days I learned that there was no problem with the library from a correctness perspective. Instead, the mysterious problem was MKL exposes an incomplete FFTW implementation that simply returns NULL for a lot of methods. After some linking tinkering in my dissertation's primary codebase, my little pencil decomposition library snapped right into place.

This is both immensely satisfying (it worked after all!) and frustratingly painful (would have loved to benchmark/publish during the grad school days!). Alas.

Two Sons

2026-06-28T22:43:14.300+00:00

Written back in August 2020

I have two different sons. However, at the West End Suprette each one chose the same Häagen-Dazs ice cream bar. Something with dark chocolate. I chose a Nestle Crunch ice cream bar from another part of the freezer. I paid while they continuously touched things that I asked them not to touch.

We three walked a block south to a tiny park, Septuagesimo Uno, and plunked ourselves on some benches. I handed the Häagen-Dazs bars, which came boxed-then-wrapped, to the boys. They tore open the boxes but the wrappers stymied them. I chuckled and wondered if, sufficiently motivated, they'd get the packaging open by themselves. They endeavored.

I opened my Crunch bar, lifted it by the popsicle stick, caught half a bite, and the whole bar fell away from the stick and onto the nasty city ground. Evidently the Crunch bar had passed its days in a warmer freezer spot. The old Eddie Murphy ice cream man skit, where a kid loses a whole cone, ran through my head while I debated if anything could be salvaged. My wife would rightly kill me if she heard I taught the kids that food could be eaten off the nasty city ground. And the kids would certainly tell her. I sighed, shook my head, and then looked up into two pairs of wide eyes.

Each boy gazed into my disappointed face while still ineffectively fumbling with a wrapper. I got out “Too bad” before twice “Dad, would you please help me open this?” arrived. I held out my hand, the little one handed me his package, I opened it, and I handed back an unmelted ice cream bar. A pause, then into the mouth. I held out my hand, the bigger one handed me his package, I opened it without looking, and I passed back a second bar. Turning down again, I couldn't resist a tiny bit of the chocolate coating. Perhaps, adequately distracted, the kids wouldn't report me to their mother.

“Dad, would you like some of mine?” spoken softly startled me. A dark chocolate Häagen-Dazs bar floated into my gaze attached to a popsicle stick attached to an outstretched arm attached to my nine-year-old son. He had offered me his very first bite. I choked up briefly, politely declined, told him how kind that was, and hugged the boy. He blinked, stepped back, and then launched into his bar.

Fortunately, neither kid made so much of a mess that their not-yet-broken tendency to wipe their mouths on their shirts didn't solve said mess. I collected then threw away the two boxes, three wrappers, and three sticks. Starting home, I hugged the big one again. He ran ahead maybe twenty feet.

The six-year-old generally lags behind me on the street. Now, however, he kept pace as we walked in silence. Halfway home he says “Dad, I would have offered you mine but I knew you wouldn't eat it so I didn't offer it.” And I tell him thank you and I hug him too. Quickly thereafter, we enter our building lobby and call the elevator.

The Greatest Skit in the World

2026-06-26T20:22:40.698+00:00

Inspired by "Tribute" by Tenacious D and another meta-bench skit. Arrived at through prompting and re-prompting Claude until it cried...

A Campfire Skit for 5 Scouts (~2 minutes)

No props. None. That’s the whole joke. Play it big. The crowd should get the ending long before the characters do.

CAST

DIRECTOR — the Camp Director. Gruff.
SCOUT 1 — the leader. Certain. Wrong.
SCOUT 2 — the loud one.
SCOUT 3 — small, nervous. Keeps blurting the right answer.
SCOUT 4 — eager. Quick to strike a pose.

THE SKIT

(The FOUR SCOUTS stand in a row, in order 1–2–3–4. The DIRECTOR storms in.)

DIRECTOR: Scouts! I need a skit tonight. A GREAT one. Or it’s latrine duty till you can vote!

SCOUT 1: Director… we will perform THE skit. The greatest skit this camp has ever seen. We did it once. The Scoutmaster wept.

SCOUT 2: The whole crowd was on their feet! They wouldn’t stop cheering!

SCOUT 3: (quietly) A raccoon stood up and clapped.

DIRECTOR: (arms folded) Then do it.

SCOUT 4: Positions!

(All four strike a dramatic pose. They hold it. Their faces slowly fall.)

SCOUT 3: (through his teeth) …What was it?

SCOUT 2: I thought YOU remembered.

SCOUT 1: I remember it was GREAT. I don’t remember what it was.

SCOUT 2: (flat) There were no props. That was the whole thing. We had nothing. (pregnant silence)

DIRECTOR: (throwing up his arms) Nothing?! You’re telling me the greatest skit ever was a bunch of Scouts with NOTHING?! (throws up his hands) I give up. (walks behind the row of Scouts and lowers himself into a seated position at bench height — knees bent, arms crossed, sulking, perched on nothing)

SCOUT 3: (brightening) We just… sat down.

SCOUT 2: On what?

SCOUT 3: On the bench.

SCOUT 2: WHAT bench?

SCOUTS 1, 3 & 4: (slow, together) …Exactly.

(On the word, the DIRECTOR topples backward off the invisible bench and crashes to the ground. Hold. Bow. Everyone runs off.)

PERFORMANCE NOTES

Stand in numeric order. Every handoff passes to the Scout next to the speaker, so the focus slides down the line instead of jumping across it.
The Director sells the ending. He sits behind the row on “I give up,” perched on nothing the whole time the Scouts talk — then topples on “…Exactly.” The longer he holds the sit, the bigger the fall.
Land “…Exactly.” big. All three say it together, dead serious, gesturing at the empty air.
Let the silence breathe before the Director’s last line.

A nestable Jobserver with thread-safe futures, callbacks, and type-hinting

2026-06-20T05:28:34.879+00:00

I have been hacking on https://github.com/rhysu/jobserver for a long time. Today I put the jobserver package up on PyPi: https://pypi.org/project/jobserver/.

My initial motivation was improving robustness over the process-pooling approaches that I was using back in August 2019. I needed something where my worker tasks could SIGSEGV or SIGPIPE without my entire pool crashing. I also needed extension hooks for a few specific applications, like advisory flocking when a worker was active and being mindful of RAM limits.

It's stayed fun to intermittently hack on. From the tag messages, you can tell I began using LLMs with this project after tag v1.12. Some features, like JobserverExecutor, were simply beyond my personal bandwidth before employing coding agents. I've tried to keep the technical quality at least as high as if I'd been hand-coding.

The timeline's been...

v1.0 — 2020-02-17: First feature-complete release of the jobserver.
v1.1 — 2020-02-22: Added when_done callbacks along with grammar and type-annotation improvements.
v1.2 — 2020-03-03: Introduced per-submission env and preexec_fn support, and adopted black/flake8/mypy tooling.
v1.3 — 2020-03-04: Added grandchild polling, configurable defaults, and a pluggable sleep_fn.
v1.4 — 2020-03-09: Simplified both the public API and the internals.
v1.5 — 2020-03-10: Wrote the README and made assorted touch-ups.
v1.6 — 2020-12-18: Removed the sentinel push/pop at work submission, since __getstate__/__setstate__ are now handled explicitly.
v1.7 — 2021-01-08: Exposed reclaim_resources on the public API.
v1.8 — 2021-02-16: Added support for CPython 3.9.
v1.9 — 2021-03-18: Exposed MinimalQueue and improved test robustness.
v1.10 — 2022-04-06: Added Python 3.10 support and the ability to unset environment variables.
v1.11 — 2024-09-29: Confirmed Python 3.11 and 3.12 work correctly.
v1.12 — 2026-01-01: Confirmed Python 3.13 works correctly.
v1.13 — 2026-03-28: Added JobserverExecutor (a concurrent.futures.Executor wrapper), Jobserver.map(), and signal-based cancellation via Future.done(..., signal=...). Also hoisted submit defaults, named worker processes, fixed re-entrant CallbackRaised double-wrapping, and shipped nine worked examples.
v2.0 — 2026-03-30: Added context-manager support to MinimalQueue and Jobserver, rewrote reclaim_resources() as O(k) using wait(), and added repr(). Fixed a Future.wait() sentinel/waitpid race and added Future.done() as a wait(timeout=0) shorthand.
v2.1 — 2026-03-31: Corrected timing, resource-leak, and type-safety issues found after v2.0, including a py.typed marker, a fixed queue-timeout overrun, and event-driven dispatcher polling. Replaced asserts at public boundaries with explicit TypeError/ValueError.
v2.2 — 2026-04-01: JobserverExecutor can now own a default-constructed Jobserver automatically, making it drop-in, and slot acquisition became O(k) via a persistent selector. Also let preexec_fn return a context manager, added resource/callback warnings, and generalized nesting examples across all start methods.
v2.3 — 2026-06-01: Child tracebacks now survive Future.result() via __cause__, escaping BaseExceptions became diagnosable, and concurrent.futures.Future.cancel() was wired through the executor. Many hardening fixes followed for map() slot reclamation, submit/shutdown races, MinimalQueue, validation, and the public API surface.
v2.4 — 2026-06-01: Fixed nested fan-out under the fork start method via a lazy per-process selector that rebuilds when the PID changes. Also deduplicated pickle-error handling and the env type signature, and added a stdlib-only benchmark harness under draft/.
v3.0 — 2026-06-20: Major API redesign: Jobserver became a thin handle over a shared, reference-counted Resources object, submission controls moved off submit()/map() into sibling handles (revise_env(), replace_preexec(), replace_sleep()), and SubmissionDied was renamed LostResult. Added a __version__, eager timeout validation, a redesigned queue hierarchy, suppressed worker traceback noise, hardened deserialization, and modernized packaging, docs, tests, and examples.

To differentiate unsuccessful from successful experiments

2026-05-26T18:43:09.538+00:00

I chased down this quote by Robert H. Goddard via The Goddard Papers Database . The original context of the letter, often omitted when using the quote, makes Goddard's words all the more delightful:

R. H. Goddard to F. T.*, Jeffersonville, Indiana Roswell, February 5, 1942

It is not a simple matter to differentiate unsuccessful from successful experiments, since most work that is finally successful is the result of a series of unsuccessful tests in which difficulties are gradually eliminated...

*This was in response to a young experimenter who complained that many of his tests had been unsuccessful

SOURCE: Goddard, Robert H. The Papers of Robert H. Goddard. Edited by Esther C. Goddard and G. Edward Pendray. Vol. 3, 1941–1945: JATO and Variable Thrust for the Military. New York: McGraw-Hill, 1970, page 1453.

Scam Likely

2026-05-01T20:16:15.662+00:00

A first person temporal tragedy to the tune of "Let It Be"...

[Verse 1]
When I call during time troubles
You won't answer though I plea
Call shows "Scam Likely"
Scam Likely
And in my hour of darkness
Past you won't pick up for me
Phone shows "Scam Likely"
Scam Likely

[Chorus]
Scam Likely, Scam Likely
Scam Likely, Scam Likely
Need to change history
Scam Likely

[Verse 2]
And when my parents never meeting
Means I'll cease to ever be
Still phones show "Scam Likely"
Scam Likely
For historic missed connection fears
Haunt me that no one will ever see
Past the words "Scam Likely"
Scam Likely

[Chorus]
Scam Likely, Scam Likely
Scam Likely, Scam Likely
Nah, please Lord make them answer
Scam Likely
Can't I be?! Scam Likely
Scam Likely, Scam Likely
Insert myself in history
Scam Likely

[Instrumental Break]

[Guitar Solo]

[Chorus]
Scam Likely, Scam Likely
Scam Likely, yeah, Scam Likely
Need to change history
Scam Likely

[Verse 3]
And when the timeline's getting cloudy
There's hope shining yet in future me
Light more digits tomorrow
Scam Likely
Frantically dial numbers
Every phone rejects my plea
All show "Scam Likely"
Scam Likely, yeah

[Outro]
Scam Likely, Scam Likely
Scam Likely, nah, Scam Likely
Oh, there must be an answer
Scam Likely
Can't I be?! Scam Likely
Scam Likely, yeah, Scam Likely
Oh, there must be an answer
Scam Likely
Might not be? Scam Likely
Scam Likely, nah, Scam Likely
Insert myself in history
Scam Likely

Tidbits from the World

2026-04-13T16:51:00.005+00:00

Just quotes, etc. where I frequently want the original source…

“Legacy” is not a pejorative.
“Invert, always, invert”

Jacobi originally but popularized by Munger : “...it is in the nature of things that many hard problems are best solved when they are addressed backward”
Algorithm for inversion:
Define the problem - what is it that you're trying to achieve?
Invert it - what would guarantee the failure to achieve this outcome?
Finally, consider solutions to avoid this failure

“[Not naming software tools] is actually a lesson that originates from the early days of Call of Duty at IW. From what I’m told, IW never named their engine, because any time you name something it becomes a bit more of a thing, and you start working for it. And they were a studio making games, the game is the thing. Nothing else.” [source]
“You have to do basic science on your libraries to see how they work…” [Sussman as reported by Wingo]
“A pointer is an integer with a shiv” [source]
Optimal stopping problems are solved with the odds algorithm, e.g. the classical secretary problem.
“The Statistics of Sharpe Ratios” by Andrew Lo [paper]
“You are in a drawdown. When should you start worrying?” [paper]
NIST has several excellent references:

Dictionary of Algorithms and Data Structures (DADS), a dictionary of algorithms, algorithmic techniques, data structures, archetypal problems, etc
Engineering Statistics Handbook with chapters Explore, Measure, Characterize, Model, Improve, Monitor, Compare, and Reliability

“If you have a procedure with 10 parameters, you probably missed some.” [source]
Driscoll Kraay Standard Errors are robust to both cross-sectional and temporal dependence.
The Python Graph Gallery is a visual reference over many graphs along with the source code to produce them.
Total least squares minimizes errors on both dependent and independent variables.
Bottom Line Up Front (BLUF) writing [HBR, Wikipedia]
Dennis Ritchie: “Our habit of trying to document bugs and limitations visibly was enormously useful to the system. As we put out each edition, the presence of these sections shamed us into fixing innumerable things rather than exhibiting them in public. I remember clearly adding or editing many of these sections, then saying to myself 'I can't write this,' and fixing the code instead.” [source]
A bestiary of regression variants , including:

Linear Regression
Polynomial Regression
Logistic Regression
Quantile Regression
Ridge Regression
Lasso Regression
Elastic Net Regression
Principal Components Regression (PCR)
Partial Least Squares (PLS) Regression
Support Vector Regression
Ordinal Regression
Poisson Regression
Negative Binomial Regression
Quasi Poisson Regression
Cox Regression
Tobit Regression

A Bestiary of Functions for Systems Designers is a nice visual guide
Karpathy blogged A Recipe for Training Neural Networks :

Become one with the data
Set up the end-to-end training/evaluation skeleton + get dumb baselines
Overfit, recalling deep double descent
Regularize
Tune
Squeeze out the juice

Agustin Lebron’s The Laws of Trading :

Know why you are doing a trade before you trade.
You're never happy with the amount you traded.
Take only the risks you're being paid to take. Hedge the others.
Put on a risk using the most liquid instrument for that risk.
If you can't explain your edge in five minutes, you don't have a very good one.
The long-term profitability of an edge is inversely proportional to how long it takes to explain it.
The model expresses the edge.
If you think your costs are negligible relative to your edge, you're wrong about at least one of them.
Just because something has never happened doesn't mean it can't.

Corollary: Enough people relying on something being true makes it false.
Working to align everyone's interests is time well spent.
If you don't master technology and data, you're losing to someone who does.
If you're not getting better, you're getting worse.

Shellhaters.org has a great POSIX Shell and Utilities Quick Reference
Practical SQL for Data Analysis: What you can do without Pandas [source]
Taguchi methods are statistical methods, sometimes called robust design methods, developed by Genichi Taguchi to improve the quality of manufactured goods, and more recently also applied to engineering…. See also orthogonal arrays , optimal experimental link, and notice Sandia’s Dakota implements many of these ideas.
Prefer to change the code rather than write a workaround [source]
By nature, bugs are found in places that you didn’t think to look [source]

A cold path is a path through the code or situation that rarely happens.
By contrast, hot paths happen frequently. You don’t find bugs in hot paths.
Bugs are always in cold paths — every bug is found in a path colder than all the paths you tested.
Don’t have cold paths and avoid fallbacks

Your Makefiles are wrong is an opinionated approach to GNU Make:

Don’t use tabs with .RECIPEPREFIX
Always use (a recent) bash in strict mode
Change some Make defaults, with a nice TLDR pre-amble

Mike Acton’s Expectations of Professional Software Engineers [summary]
Scalability! But at what COST? says “Big data systems may scale well, but this can often be just because they introduce a lot of overhead” and is often referred to as “The COST Paper”
strace Wow Much Syscall by Brendan Gregg includes useful strace one-liners
Richard Sutton’s The Bitter Lesson starts “The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin….” and begins to conclude “One thing that should be learned from the bitter lesson is the great power of general purpose methods, of methods that continue to scale with increased computation even as the available computation becomes very great. The two methods that seem to scale arbitrarily in this way are search and learning.”
Syntax across languages is a gigantic survey of language design, e.g. operators/functions/etc. The survey can often inform what some collection of users will find natural or unnatural based on their existing skills.
Nick Higham’s “What Is” article series gives brief descriptions of concepts in numerical analysis for upper-level undergraduates with mathematical inclinations
Long names are long observes “identifiers that are too damn long.”

Omit words that are obvious given a variable’s or parameter’s type
Omit words that don’t disambiguate the name
Omit words that are known from the surrounding context
Omit words that don’t mean much of anything

(e.g. data, state, amount, value, manager, engine, object, entity, and instance)
Ends with a humorous application to waffles.

How to help someone use a computer : “Computer people are fine human beings, but they do a lot of harm in the ways they "help" other people with their computer problems….”
Common statistical tests are linear models:

Hoeffding’s test for dependence was proposed by Wassily Hoeffding (1948) as a test of correlation for two variables with continuous distribution functions (wikipedia, random blog, post). Hoeffding’s D is a nonparametric measure of the distance between the joint distribution F(x, y) and the product of marginal distributions F1(x)F2(y). The advantage of this statistic lies in the fact that it has more power to detect non-monotonic dependency structures compared to other more common measures (Pearson, Kendall, Spearman)
Data systems often fall into one of schema-on-write or schema-on-read:

Traditional databases are schema-on-write: “we can't upload data until the table is created and we can't create tables until we understand the schema of the data that will be in this table.”
Newer systems, e.g. “Big Data” is often schema-on-read, requiring all code that handles the data to understand it’s implicit schema. Still “some level of schema design is inevitable”.
Martin Kleppmann’s book Designing Data-Intensive Applications often comes up.

Simple sabotage for software , taking CIA sabotage manuals for inspiration, enumerates many horrid, insidious ways to sabotage a software organization. To do better as an organization, work to prevent even accidental sabotage.
The Internet Was Designed With a Narrow Waist:

A narrow waist is concept, interface, or protocol that solves an interoperability problem.
Picture an hourglass with M things on one side, N on the other, and an important concept in the middle.
It avoids O(M × N) code explosions, letting us write O(M + N) amounts of code instead.
Byte streams and text are essential narrow waists in software, particularly in distributed-systems like the Internet.

On achieving high-level goals [source pp 138-9]:

Write down your five biggest goals for the year.
Pick the one that will make the biggest difference in your life. Tackle that one first.
Write your chosen goal in the past tense as though it's already happened. This will not only tell you whether you truly want it by how you feel as you look back at it from the future, it will also help you identify (in imagined hindsight) all the critical steps it will take to get there. Outline as many critical steps as come to mind.
Write out twenty different things you could do right now to make it happen. Really stretch your thinking in new directions to get all twenty. Now pick the one goal that will have the greatest impact on the achievement of that goal. Try to knock one off your list each day, or week (depending on the goal). Keep going with twenty more, and twenty more, until the goal is achieved. Focus on only one goal at a time, putting all your energy in that one direction. (Trying to work on them all at once can be overwhelming and diffuses your effectiveness and focus).

Thompson sampling is commonly used as a multi-armed bandit algorithm. I have personally used it for an older side project.
“Shipping is a social construct within a company.”
There’s a CLAUDE.md containing Karpathy-inspired Claude Code guidelines.
Every layer of review makes you 10x slower by he of apenwarr/redo fame.

Randomized addition worksheets for kiddos using Bash Pipelines

2018-02-04T16:20:00.000+00:00

Following up on a prior randomized worksheet for reading, here's a way to generate as many simple addition worksheets as you care to print:

#!/bin/bash
# Print a US letter page of addition problems using numbers 0 through 10.
(
    for i in $(seq 1 26); do
        printf "%2d %s %2d = \n" "$((RANDOM % 11))" "+" "$((RANDOM % 11))"
    done
) \
| column -nxc 36 \
| sed G \
| head -n -1 \
| a2ps -1 --chars-per-line=32 --no-header --borders=no

Randomized Reading Lists for Kiddos using Bash Pipelines

2017-06-03T13:09:00.000+00:00

Our kiddo is very good at memorizing stories and word sequences but needs to work on looking at the letters on the page. Simple bash pipelines can produce useful offline learning materials.

For example, print a randomized word list from inline story text for a book your kid loves:

#!/bin/bash
tr -d '",!.-' << EOF                          \
    | tr -s ' ' '\n'                          \
    | sed '/^$/d'                             \
    | sort -u                                 \
    | shuf                                    \
    | column -c 64                            \
    | nl                                      \
    | a2ps -1 --chars-per-line=70 --no-header

The night Max wore his wolf suit and made mischief of one kind
and another
his mother called him "WILD THING!"
...

EOF

Run the script once to produce the word list. Print the source once to have the picture-less story. Carry both in your pocket on the plane/train/etc. After some work on the word list, the kid should be encouraged by "rediscovering" the picture-less story he knows using the sight words he's just practiced. In theory. Still working on the practice.

Another example, print a randomized list of kindergarten sight words:

#!/bin/bash
sort -u <<EOF | shuf | column -c 64 | nl | a2ps -1 --chars-per-line=70 --no-header
a
about
after
again
all
always
am
an
and
any
are
as
ask
at
away
back
ball
be
beautiful
because
been
begin
best
big
but
by
came
can
come
could
couldn't
day
did
do
does
don't
down
each
easy
eat
either
enough
family
find
for
friend
from
fun
get
girl
go
goes
going
got
great
had
has
have
he
her
here
high
him
his
home
house
how
I
idea
if
I'm
in
into
is
it
jump
just
know
last
let
like
little
look
love
make
man
me
might
mom
more
mother
much
my
never
next
no
not
now
of
often
on
or
our
out
over
play
pretty
probably
put
ran
read
ready
run
said
same
sat
saw
say
school
see
she
should
sit
so
soon
special
such
suddenly
take
than
that
the
their
them
themselves
then
there
they
they're
things
think
this
thought
three
through
to
today
together
too
two
under
until
up
us
very
wait
walk
want
was
we
went
were
what
when
where
while
who
will
with
without
yes
you
your
you're
yourself
EOF

Travis-CI config for both recent(ish) gcc and clang

2016-12-11T18:57:00.005+00:00

On account of the age of Travis-CI's build images (I hear) getting a new-ish C++ compiler going is futzy. After much futzing, the following .travis.yml file works for an autoconfiscated project:

language: generic
script: ./bootstrap && ./configure && make all && make check && make distcheck
matrix:
  include:
    - os: linux
      env: COMPILER_NAME=gcc CXX=g++-5 CC=gcc-5
      addons:
        apt:
          sources:
            - ubuntu-toolchain-r-test
          packages:
            - autotools-dev
            - g++-5
    - os: linux
      env: COMPILER_NAME=clang CXX=clang++-3.8 CC=clang-3.8
      addons:
        apt:
          sources:
            - ubuntu-toolchain-r-test
            - llvm-toolchain-precise-3.8
          packages:
            - autotools-dev
            - clang-3.8