Daily Digest — 2026-07-10

In May 1963, a small team at the RAND Corporation in Santa Monica flipped the switch on a JOHNNIAC computer running something nobody had ever built before: a fully interactive, conversational programming environment where a scientist could sit at a Model 33 teletype, type a mathematical expression, and get an answer back in under a second. It was called JOSS — the JOHNNIAC Open Shop System — and it was designed by Cliff Shaw, one of the co-authors of the first AI program (Logic Theorist, 1956) alongside Allen Newell and Herbert Simon.

JOSS wasn't a compiler. It wasn't a batch language. It was something radical for 1963: a conversational language where the user and the machine took turns. You typed Set x = 3.14. and the machine acknowledged. You typed Type x*2. and it responded 6.28 instantly. Line numbers stored programs; unnumbered commands executed immediately. Sound familiar? That's because JOSS invented the interactive REPL pattern that BASIC (1964), APL (1966), Python, and every Jupyter notebook cell you've ever run inherited directly.

The technical achievement was staggering for the hardware. JOHNNIAC was a 1953-vintage vacuum-tube machine with 4,096 words of Williams-tube memory. Shaw's team squeezed a full-precision decimal arithmetic system (nine significant digits, no binary rounding surprises — chosen because scientists expected decimal answers), a natural English-like syntax, structured control flow with if/do/step constructs, and a full multi-user time-sharing scheduler out of a machine that had less RAM than a modern smartwatch's stack pointer. By 1964, up to ten simultaneous users were sharing JOHNNIAC across RAND's engineering offices.

Then JOHNNIAC was retired in February 1966. JOSS was ported to a PDP-6 (JOSS II), then to a PDP-10. It ran productively at RAND until 1978. But here's the tragedy: JOSS never left RAND. It was internal-use software, unpublished commercially, licensed to almost nobody. Meanwhile, IBM was pushing the System/360 as the future of computing — and the System/360's design philosophy was batch job submission with punched cards. IBM sales culture actively discouraged interactive computing as wasteful of machine time. When Dartmouth's Kemeny and Kurtz built BASIC in 1964, they explicitly cited JOSS as inspiration, but simplified it (they dropped the decimal arithmetic, dropped the structured control flow) to fit on cheaper hardware. BASIC won the mindshare. JOSS's superior design — decimal math, structured constructs, elegant syntax — died in the Santa Monica microfilm archive.

Why revive it now? Three reasons converge in 2026:

• Decimal arithmetic is having a renaissance. IEEE 754-2008 standardized decimal floating-point; Python's decimal module, Java's BigDecimal, and every financial system on Earth already agree that binary floats are the wrong default for human-facing numeric work. JOSS was right in 1963.
• Notebook computing has hit a complexity wall. Jupyter's hidden state problem — cells executed out of order producing mysterious results — is exactly the failure mode JOSS's ordered, line-numbered program model prevented. JOSS's design cleanly separated immediate mode from stored program mode; modern notebooks conflate them.
• The syntax was genuinely better than what replaced it. Do part 3 for i = 1(1)10. is more readable than the FORTRAN DO 100 I=1,10 that dominated science for 30 years. LLMs generating code today would benefit from a language that reads like the specification.

The JOSS manuals still exist. RAND published them as R-366 (1964) and R-5046 (1966). Someone with a weekend and a parser generator could resurrect the language exactly — and possibly rediscover why interactive computing was better before we forgot how to design it.

Here's the setup: generative AI has made DRAM — the fast memory chips that sit next to CPUs and GPUs — absurdly expensive and hard to get. Hyperscalers like Amazon, Google, and Microsoft are hoovering up global supply to feed their AI training farms, and everyone else is feeling the squeeze. So a team from Uppsala and RISE asked a delightfully weird question: what if we stored data inside the fiber-optic cables that already run through data centers?

The idea sounds like science fiction, but it's actually an old trick dusted off for a new era. It's called a delay-line memory. Picture a long garden hose full of marbles: you push a marble in one end, and it comes out the other end a second later. While the marble is traveling through the hose, it's effectively "stored" there. Early computers in the 1940s and 50s used mercury tubes and acoustic waves to do exactly this. The authors are proposing we do the same thing with light pulses traveling through kilometers of coiled optical fiber.

The key insight is that light in a fiber travels at a finite speed — roughly 200,000 km/s in glass. So a 10 km spool of fiber holds any bit you shove into it for about 50 microseconds before it comes out the other side. Loop the output back to the input (a "recirculating" delay line), refresh the signal with a small optical amplifier, and you have a memory bank that stores data as literal photons in flight.

What makes this newly practical:

• Immutable data is the perfect fit. Delay lines are terrible at random access — you have to wait for your bit to come around. But large language model weights are read constantly and almost never written. You're just streaming them past compute units in a fixed loop.
• Fiber is cheap and abundant. Data centers already run miles of it. Adding more spools is trivial compared to fabricating cutting-edge DRAM.
• Density scales with length, not silicon lithography. You're not bound by the same physics that's making DRAM scaling stall.

The paper works through the architecture: how you'd wire fiber memory into a hyperscale system, how to handle refresh and error correction, how bandwidth and latency compare to HBM (the high-bandwidth memory used in AI accelerators). It won't replace DRAM for scratch space or activations — those need random access — but for the massive, mostly-read weight matrices that dominate AI memory footprints, streaming them through fiber loops could be genuinely competitive.

We've spent a lot of time picking apart individual flange geometry errors — flatness, roundness, waviness, roughness, runout in three directions. But in the real world, these deviations don't show up alone. A flange has some radial runout, some axial warp, some waviness, and some surface roughness — all at once. Form error is the umbrella metric that combines them into a single number describing how far the actual sealing surface deviates from the ideal 20° cone.

Formally, form error is the total zone thickness containing every measured point on the surface — the gap between two coaxial ideal cones that just barely enclose the real surface. If your flange's points all sit within a 0.05 mm band between two perfect cones, form error is 0.05 mm. It captures runout, waviness, and roughness in one shot because it doesn't care what kind of deviation caused a point to sit high or low — only that it does.

Why this matters for V-band sealing: A V-band clamp closes with roughly uniform radial force. That force has to plastically deform the flange faces just enough to bridge the peaks and valleys of form error. If form error exceeds the clamp's available deformation budget — typically 0.03–0.08 mm for stainless flanges at spec torque — the joint leaks. Individual metrics can each pass inspection while their sum fails.

Rule of thumb: Total form error should stay under 0.05 mm (0.002") across the full sealing circumference for reliable boost retention up to 40 psi. Above 0.08 mm, expect audible leaks under load. Multiply by 1.5× for turbo-hot-side flanges that see thermal cycling — the joint has to survive both cold-clamp and hot-expanded states.

Real example: A Garrett G30 turbo swap where the fabricator's downpipe flange measured 0.02 mm radial runout, 0.03 mm flatness, and 32 Ra finish — all individually within spec. Combined form error came out to 0.09 mm because the deviations stacked in the same clock position. The joint whistled at 25 psi until the flange was re-faced on a lathe, bringing form error down to 0.04 mm.

Measurement: Modern CMMs report form error directly by fitting a least-squares cone to the point cloud and computing the maximum ± deviation. For shop-floor checks, a dial indicator sweep across the cone face gives a rough proxy — total indicator reading (TIR) approximates form error within about 20%.

This scheduler tracks a fixed-size roster of jobs. Empty slots are marked undefined, so the array indices stay meaningful (slot 0, slot 1, slot 2…). Persist to disk, load back, keep going. What could go wrong?

function saveRoster(jobs) {
  localStorage.setItem("roster", JSON.stringify(jobs));
}

function loadRoster() {
  const raw = localStorage.getItem("roster");
  return raw ? JSON.parse(raw) : [];
}

function runRoster(jobs) {
  for (const job of jobs) {
    if (job === undefined) continue;   // skip cleared slots
    console.log(`Running job ${job.id}: ${job.name}`);
  }
}

// Boot up, clear slot 1, save, reload, run.
let roster = [
  { id: 1, name: "reindex" },
  undefined,                            // slot cleared earlier
  { id: 3, name: "backup"  },
];

saveRoster(roster);
roster = loadRoster();
runRoster(roster);
// TypeError: Cannot read properties of null (reading 'id')

The Bug

JSON has no undefined. When JSON.stringify hits an undefined inside an object, it silently drops the key. But arrays are different — dropping a slot would shift every subsequent index, silently corrupting data. So the spec chose the lesser evil: undefined in an array is emitted as null.

JSON.stringify({ a: undefined, b: 2 })   // '{"b":2}'         key vanishes
JSON.stringify([undefined, 2])           // '[null,2]'        becomes null

The round-trip is lossy but asymmetric. Your in-memory array had undefined at index 1. After save-and-load, index 1 is null. The check job === undefined is false for null (strict equality), so continue never fires. The loop falls through and tries to read null.id. Crash.

What makes it fiendish: the bug hides across a persistence boundary. Every unit test that skips serialization passes. The array's length is preserved, the shape looks identical in the debugger, and even a console.log of the restored array shows [{…}, null, {…}] — which reads like "yeah, obviously null." The distinction between "no value assigned yet" (undefined) and "explicitly nothing" (null) survives inside a single process and evaporates the moment JSON touches it.

Other silently-dropped values compound the trap: functions, Symbols, and BigInt throw or vanish too. Inside objects they disappear; inside arrays functions and symbols also become null, while BigInt throws outright.

The Fix

Pick one canonical "empty" sentinel and check for it defensively. In practice, treat null and undefined as interchangeable at any deserialization boundary — the == null loose-equality check catches both:

function runRoster(jobs) {
  for (const job of jobs) {
    if (job == null) continue;         // catches null AND undefined
    console.log(`Running job ${job.id}: ${job.name}`);
  }
}

If you actually need to preserve the difference (some slots were never assigned, others were explicitly cleared), JSON can't carry that — use a tagged representation like { cleared: true }, or serialize to a format that encodes undefined (structured clone via IndexedDB, MessagePack, or a custom replacer/reviver pair).

The general rule: JSON is not a mirror of your JavaScript value graph. It's a lossy projection into a smaller type system, and the losses aren't symmetric between arrays and objects.

Once a wire gets long enough, its delay stops being linear in length and starts being quadratic. That's because a wire has distributed resistance (R) and capacitance (C), and the Elmore delay of an RC line is roughly 0.5 × r × c × L², where r and c are resistance and capacitance per micron. Double the length, and delay goes up 4×. On a modern SoC, an unbuffered wire across the die can take tens of nanoseconds — utterly unusable at gigahertz.

Two knobs fight this: wire sizing (make the wire wider) and repeater insertion (chop the wire into segments with inverters/buffers between them).

Wire sizing lowers r (wider metal has less resistance per length) but raises c (more sidewall and area capacitance). The r×c product only improves modestly, and you burn precious routing tracks. Useful on critical global nets, but expensive.

Repeater insertion is the real hammer. If you place N repeaters along a wire of length L, each segment is L/N, and the total delay becomes roughly N × (buffer_delay + 0.5 × r × c × (L/N)²). Now delay is linear in L for a properly chosen N. The optimal repeater spacing is set by a classic result — Bakoglu's equation — that balances buffer intrinsic delay against wire RC per segment:

• Optimal segment length: L_opt ≈ √(2 × R_buf × C_buf / (r × c))
• Rule of thumb on a modern process: repeaters every 500 μm to 2 mm on global signals.

Concrete example: A clock enable signal has to travel 5 mm across a die. With r = 0.1 Ω/μm and c = 0.2 fF/μm, unbuffered delay is 0.5 × 0.1 × 0.2e-15 × (5000)² = 250 ps just for the wire — plus slew degradation that murders the receiving flip-flop's setup margin. Insert 4 repeaters, and each segment is 1 mm; wire delay per segment drops to 10 ps, and total end-to-end (including ~30 ps per buffer) becomes ~160 ps with clean edges. That's why every place-and-route tool runs a buffer insertion pass after global routing — a large SoC can have hundreds of thousands of inserted repeaters, sometimes 10-15% of the total gate count.

Two gotchas: repeaters cost power (they switch every cycle the signal toggles) and area (they need standard-cell rows underneath long wires, which is why routing channels can't just be empty). And inverting repeaters flip polarity, so tools always insert them in even counts — or add a final inverter to fix parity.

You already know ferrite beads look like frequency-selective resistors. But two subtle effects sink real designs: DC bias current desaturation and placement-induced resonance. Both turn your "quiet rail" into a noise amplifier.

The DC bias trap. A ferrite bead's datasheet impedance (say, 600 Ω at 100 MHz) is measured at zero DC current. Push rated current through it and the ferrite core partially saturates. Permeability drops, and impedance can collapse by 50–80%. A BLM18PG601SN1 rated 600 Ω at 100 MHz drops to about 200 Ω when carrying 1.5 A. If you sized the bead for a 500 mA load and then upgraded to a 1.2 A microcontroller, your filtering is now a fraction of what SPICE predicted.

Rule of thumb: derate ferrite bead impedance by 50% at 50% of rated DC current. Pick beads rated for at least 2× your steady-state load current.

The resonance trap. A ferrite bead is inductive below its impedance peak. Put it in series with a decoupling capacitor and you've built an LC tank. Q can hit 5–10, meaning the tank amplifies noise at its resonant frequency — typically 100 kHz to 2 MHz — right where switching regulators dump their fundamental ripple. Bench measurements often show +6 to +12 dB peaking at the LC corner.

Concrete example: powering a PLL from a switcher. You have a 3.3 V buck regulator (1 MHz switching) feeding a sensitive fractional-N PLL. You add a 600 Ω @ 100 MHz bead (≈1 µH at low frequency) plus a 10 µF ceramic cap. Resonant frequency:

f = 1 / (2π√(LC)) = 1 / (2π√(1e-6 × 10e-6)) ≈ 50 kHz

That's below the buck's 1 MHz fundamental — safe. But if you used a 1 µF cap instead, f = 160 kHz, still low. Use 100 nF? f = 500 kHz — now you're peaking dangerously close to the switcher's second harmonic.

Damping the tank. Three options:

• Add a small series resistor (0.1–1 Ω) with the capacitor to lower Q.
• Use a bulk electrolytic (with real ESR, 100 mΩ range) in parallel with the ceramic — the ESR damps the resonance for free.
• Choose the bead's impedance peak to be well above the noise you're filtering, so you're always in the resistive region.

Placement matters too: put the bead upstream of the decoupling network, not between two cap banks. Beads inside the return-current loop of a fast digital load can inject ground bounce into adjacent analog rails.

A Belleville washer (also called a conical spring washer or disc spring) is a shallow cone of hardened steel that acts as a stiff, compact spring. Under axial load it flattens elastically; when the load is released, it springs back. Unlike a helical spring, it fits inside the same envelope as an ordinary flat washer but stores meaningful energy and maintains preload after thermal cycling, gasket relaxation, or bolt creep.

Why engineers reach for them:

• Maintaining bolt preload. A high-strength bolt loses clamping force when gaskets compress, aluminum flanges creep, or joints thermally cycle. A Belleville stack under the nut acts as a mechanical accumulator — as the joint shortens by a few thousandths, the disc springs relax slightly and keep pushing.
• High force in a tiny space. A single 25 mm OD disc can deliver several kilonewtons over a deflection of under a millimeter. Try that with a coil spring.
• Tunable stiffness. Stack them in series (alternating cup direction: >< ><) to double deflection at the same load. Stack them in parallel (nested same-direction: >>>>) to double load at the same deflection. Mix them to hit almost any spring rate.

Real-world example: The head bolts on a diesel engine often ride on Belleville stacks. As the aluminum head expands more than the steel block on hot startup, the bolts would over-stress; as it cools, they'd lose clamp and blow the head gasket. The washers absorb the elongation swing and hold clamp force within a working band.

Rule of thumb — the "h/t ratio": The behavior of a Belleville washer is governed by the ratio of its cone height h to its material thickness t.

• h/t ≈ 0.4 → nearly linear spring, like a stiff coil.
• h/t ≈ 1.4 → nearly constant force across a wide deflection range — ideal for maintaining preload.
• h/t ≈ 2.8 → the washer snaps through (bistable). Used for over-center detents and pressure relief.

Quick sizing check: For a stack of n discs in series carrying load F at deflection δ each, total travel is n·δ and total load stays F. So if you need 0.5 mm of travel to compensate for gasket creep and each washer gives 0.15 mm before flattening, you need at least 4 in series. Never compress a Belleville flat in service — you'll set it permanently and lose the preload function.

Gotcha: Belleville washers are directional. Assembling one backwards under a bolt turns your spring into a flat washer. Always specify orientation in the assembly drawing.

Buried in the table of contents of a September 1917 agricultural bulletin — sandwiched between abstracts on hot-water seed treatments and pea germination — sits a single line that hints at a discovery decades ahead of its time:

"800. The Resistance of Wheat to Cold in Relation to its Sugar Content; Investigations carried out in Sweden."

The International Review of the Science and Practice of Agriculture was the monthly bulletin of the International Institute of Agriculture in Rome — a pre-League-of-Nations body founded in 1905 that later folded into the FAO. Its job was to distill agricultural research from around the world into abstracts for working scientists and ministries. The Swedish study it summarized in the middle of World War I made a claim that sounds almost folksy: sweeter wheat survives colder winters.

They were right — and the mechanism they were circling in 1917 wouldn't be fully articulated in molecular terms for another sixty years.

Modern plant physiology confirms it clearly. When wheat and other winter cereals are exposed to falling autumn temperatures, they undergo cold acclimation: starch reserves are enzymatically broken down into soluble sugars — sucrose, fructose, raffinose — that accumulate in the cytoplasm of every living cell. These sugars do three things at once:

• Depress the freezing point of cell sap, so ice forms later and less catastrophically.
• Stabilize cell membranes by hydrogen-bonding to phospholipid heads, replacing water molecules that would otherwise leave gaps during dehydration stress.
• Protect proteins from unfolding during the freeze-thaw cycle, acting essentially as a natural cryoprotectant — the same principle behind the glycerol we use to bank cells at –80°C.

The Swedish researchers had no way to see any of this. They didn't have differential scanning calorimetry, membrane biochemistry, or the concept of a compatible solute. What they had was a correlation: measure the sugar content of a wheat cultivar in November, then count how many plants were alive in March. The correlation held. They published it.

Farmers had known for centuries that some winter wheats were hardier than others, but the why was mysterious — attributed variously to "vigor," "constitution," or the phase of the moon at sowing. A team in Sweden, working in a country where a bad winter could ruin a crop, quietly reframed the question as chemistry.

The modern echo is direct. Every commercial winter wheat variety grown from Kansas to Ukraine is bred, in part, on cold tolerance metrics that ultimately trace back to soluble sugar accumulation. Climate-resilience research groups in 2026 are still publishing on the same axis — now measuring specific transporter genes (like TaSUT1) that shuttle sucrose into vacuoles during frost hardening. The 1917 abstract was, in retrospect, one of the earliest whispers of what we now call plant cryobiology.

Among the declassified CIA Reading Room documents sits a March 1965 technical proposal from Corning Glass Works' Electronic Products Division in Raleigh, North Carolina. The stated objective:

"Investigation of Improved Screens for Rear Projection Viewers."

What makes it fascinating isn't the mission — the CIA had insatiable appetite for better ways to view microfilm and reconnaissance imagery — but the shopping list of exotic materials Corning proposed to evaluate. Under "Materials Approach to the Problem," the table of contents catalogs:

"1. Passive Screens — a. Photosensitive Glass. b. Heterogeneous Materials. c. Polarizing Materials. d. Opal Glasses. e. MULTIFORM Glasses. f. Fiber Optics. g. Porous Vycor. 2. Hybrid Screens"

Read that again. In 1965 — the year Gordon Moore first wrote down Moore's Law, when American living rooms were dominated by cathode-ray tubes — Corning was pitching the CIA on fiber-optic display faceplates as a serious candidate for image viewing.

The list is a hidden history of Corning's forgotten glass technologies:

• Photosensitive glass (marketed as Fotoform) was Corning's remarkable material that could be exposed to UV through a mask and then chemically etched into intricate patterns — essentially photolithography for bulk glass, invented by Stanley Donald Stookey in the 1940s.
• MULTIFORM was Corning's proprietary sintered-glass process: glass powder pressed into molds and heat-fused into complex shapes impossible to blow or cast. It was, in effect, 3D-printed glass fifty years before hobbyists heard the term.
• Porous Vycor — 96% silica glass with nanoscale interconnected pores — is still used today in chromatography and as a substrate for optical sensors, but its consumer visibility has vanished.
• Fiber optic faceplates for displays did become real. They're inside every image-intensifier tube in night-vision goggles, and they were used to flatten the curved faces of early CRTs for reconnaissance readers — very likely a direct descendant of proposals like this one.

The proposal predates commercially available LCDs by roughly a decade and plasma displays by longer. Yet Corning, sitting on a catalog of glass materials most people have never heard of, was already sketching the material science of high-resolution flat displays for a customer who needed to see satellite film clearly enough to count vehicles.

Modern readers know Corning best for Gorilla Glass on their phones — a material also born from Stookey's mid-century experiments. What's forgotten is that the same lab produced photo-etchable glass, sintered glass shapes, and nano-porous silica, and that a Cold War intelligence agency was funding exploration of how to combine them into what we would now recognize as display technology.

In October 1943, a Viennese-born architect with no formal training in electronics filed a British patent that would end up inside the Voyager probes, every geostationary television satellite, and the ground stations still tracking spacecraft near Jupiter today. His name was Rudolf Kompfner, the patent was GB 588,335 (with US counterpart US 2,653,270), and the device was the traveling-wave tube, or TWT.

Kompfner (1909–1977) had trained as an architect at the Vienna University of Technology and was designing buildings when the rise of the Nazis pushed him to Britain in 1934. He was interned briefly in 1940 as an "enemy alien," then released and assigned to Admiralty radar research at the University of Birmingham — the same lab that had produced the cavity magnetron. Working alone in a basement with borrowed glassblowing gear, this architect asked a question the physicists had missed: what if, instead of shoving electrons through a resonant cavity like a klystron, you let an electron beam and a radio wave travel side by side, slowing the wave just enough that they moved at the same speed?

The answer, sketched in Kompfner's 1942 notebooks and patented in 1943, was elegant. Wrap a fine wire into a helix down the center of an evacuated glass tube. Fire an electron beam straight through the middle of the helix. A weak RF signal injected at one end of the helix winds around and around at close to the beam's velocity. Because they travel together, the electrons and the wave interact continuously — the beam pumps energy into the wave along the entire length of the tube. Out the other end comes an amplified signal ten thousand times stronger, over a bandwidth klystrons couldn't touch.

Kompfner joined Bell Labs in 1951, where John R. Pierce refined the theory and coined the acronym TWT. Within a decade the tube was being flown on Telstar (1962), the first active communications satellite. It has never left orbit since.

What's astonishing is the modern relevance. In 2026, TWTs — now called TWTAs, "traveling-wave tube amplifiers" — still dominate high-power microwave amplification in space:

• Voyager 1 and Voyager 2, launched 1977, still transmit through their original TWTs from beyond the heliopause — 48 years of continuous vacuum-tube operation.
• Nearly every geostationary broadcast, weather, and military satellite carries a TWTA in its downlink chain.
• NASA's Europa Clipper (launched 2024) and the Mars Sample Return relay both rely on TWTAs for their high-gain links.
• The Deep Space Network's 34- and 70-meter dishes use ground-based TWTs to whisper commands to spacecraft billions of kilometers away.
• Even as gallium-nitride solid-state amplifiers eat into LEO comsat markets (Starlink, Kuiper), the higher-power slots above ~200 W still belong to TWTs — because helices don't care about heat the way transistors do.

Kompfner's insight — that a slow-wave structure could couple continuously to a drifting electron beam — also seeded a whole family of devices: backward-wave oscillators, gyrotrons that heat fusion plasmas at ITER, and the free-electron lasers producing X-ray pulses at SLAC and the European XFEL. Every one of them descends from an architect's basement sketch made while the Blitz was still on.

The patent office indexed GB 588,335 under "electron discharge devices." A better label would have been: the amplifier that made the space age audible.

Billed simply as "A private Play Store for you," Drebin451 is an intriguing little project from the Commit451 group — the same folks behind a handful of well-regarded Android open-source libraries (LabCoat for GitLab, Reptar, and others). The name is a nod to Frank Drebin from The Naked Gun, which fits the group's tradition of playful project naming while hinting at something a bit sneakier: your own personal app distribution channel.

The concept is compelling. Rather than relying on Google Play, F-Droid, or sideloading APKs one by one, a "private Play Store" implies a self-hosted or personal repository where you curate the apps available for install on your devices. This is the kind of tool that has quiet but real appeal in a few communities:

• Android developers who want a lightweight way to distribute internal builds to a small group of testers without dealing with Play Console review cycles.
• Homelab and self-hosting enthusiasts who already run their own Nextcloud, Jellyfin, and Vaultwarden instances and would love to add app distribution to the stack.
• Privacy-conscious users who want to keep a curated collection of trusted APKs (patched apps, older versions, sideloaded FOSS builds) available across their own devices without a third-party middleman.
• Small teams and families who share a set of custom or niche apps and want a clean install experience rather than passing APK files around.

Because the repo is fresh and undescribed beyond that one-liner, it's very much in the "watch this space" category. But Commit451's track record of shipping polished Android tooling means this isn't a throwaway experiment — it's worth bookmarking to see where it lands. Even if you never install it, the source is likely to be an educational read on APK signing, repository indexing, and Android package management.

SIMD code lives and dies by data layout. Your vectors arrived from memory in one shape, but the math you want to do needs them in another. That's where the permute/shuffle unit earns its keep — and where naive code quietly burns cycles.

Every SIMD ISA has a family of these ops: x86's PSHUFB, VPERMD, VPERMPS, VPERM2F128; ARM's TBL/TBX; NEON's VZIP/VUZP. They all move lanes around inside (or between) vector registers, guided by an index vector or an immediate mask.

The catch: not all permutes are equal. There are three tiers on modern x86:

• In-lane shuffles (PSHUFD, SHUFPS): stay within a 128-bit lane. 1 cycle latency, throughput 1/cycle on port 5 (Intel) or ports 1/2 (AMD Zen 4).
• Cross-lane permutes (VPERMD, VPERMPS on 256-bit): traverse the 128-bit lane boundary. 3 cycles latency, still port 5 only — the wiring to swap between lanes physically costs more silicon and time.
• 512-bit two-source permutes (VPERMT2D): read two source vectors plus an index. 3–5 cycles latency, throughput often 1 per 2 cycles because the crossbar is enormous.

Why the lane boundary matters: AVX2 was bolted onto AVX by widening most 128-bit ops to two independent 128-bit halves. Real 256-bit crossbar wiring only exists for the explicit cross-lane instructions. That's why PSHUFB can't shuffle byte 0 of the low lane into the high lane — the wires aren't there.

Concrete example — matrix transpose: A 4×4 float transpose using _mm_shuffle_ps + _mm_unpacklo/hi_ps takes 8 in-lane shuffles at 1c each = ~8 cycles. Extend to 8×8 with AVX2 and you must use VPERM2F128 for the lane-crossing step; each of those is 3 cycles. The transpose cost roughly triples per doubling of width, not doubles — that's the port-5 bottleneck plus cross-lane latency compounding.

Port pressure rule of thumb: On Intel Skylake through Golden Cove, every shuffle competes for port 5. If your loop does 4 shuffles per iteration, port 5 caps you at 4 cycles/iteration regardless of how much math the other ports could handle. Check with perf stat -e uops_dispatched_port.port_5 — if it's near 100%, you're shuffle-bound, and no amount of FMA cleverness will save you.

Design workaround: Precompute layouts. Store data in structure-of-arrays form so lanes align naturally with the operation, and reserve permutes for the unavoidable reduction step.

This 2020 post has aged into something more interesting than it was at publication. Rick Carlino walks through using Kiwix — the offline reader originally built for downloading Wikipedia to remote schools — to keep a local copy of Stack Overflow on your machine. In 2020, this was a neat hack for people with bad internet or a taste for self-reliance. In 2026, it reads like a survival guide.

The context has shifted for a few reasons worth naming:

• Stack Overflow's traffic collapse. Question volume has been in freefall since ChatGPT arrived, and the site has monetized its corpus through AI licensing deals. The community-generated archive that made SO valuable is increasingly a museum piece — and museums close.
• LLM answers hallucinate; SO answers link to a working accepted answer with 47 upvotes. Having a grep-able, timestamped local copy of expert-vetted Q&A is a useful ground-truth companion to any coding assistant.
• Kiwix ZIM files are compact. The full SO dump (questions + answers, no comments) fits in roughly 100GB — trivial on modern storage. You can carry the accumulated wisdom of a decade of working programmers on a thumb drive.

The technical setup is refreshingly boring: download the ZIM archive from the Kiwix library, point kiwix-serve at it, browse via localhost. No accounts, no telemetry, no rate limits, no "sign in to see this answer." The post also covers scripting periodic updates and integrating with editors.

For a technical audience, the interesting question the article implicitly raises is: what other reference corpora should you be archiving right now? MDN, the Python docs, cppreference, Postgres docs, and man pages all have ZIM equivalents. As the open web gets increasingly walled off, paywalled, or AI-summarized into unreliability, keeping a personal offline mirror of the canonical references stops being a prepper move and starts being basic professional hygiene — the same way you keep local git clones instead of relying on GitHub being up.

It's also a nice reminder that Kiwix, a small nonprofit project, quietly built the exact infrastructure needed for this moment years before anyone knew they'd want it.

Of the ten postings, PostHog's is the most revealing because it's a naked snapshot of a company at a very specific inflection point: YC W20 graduate, first engineering hire, remote-first, open source, ~1.7k GitHub stars. Every one of those signals means something.

The stack: Django + React + Helm. Django is a boring, deliberate choice for a product analytics company — Segment and Mixpanel-class tooling usually reaches for a JVM or Go backend to handle event ingestion volume. Picking Django says PostHog is optimizing for iteration speed over ingestion throughput, which is exactly right for a pre-PMF startup. The helm chart requirement is the tell: they're shipping a self-hostable product that customers deploy into their own Kubernetes clusters. That's a very specific go-to-market — "own your data" positioning against SaaS-only competitors like Amplitude and Mixpanel.

What the posting reveals:

• Stage: "First engineering hire" after a YC batch means the founders have been coding solo. Product exists, has traction (HN launch reference), but engineering leverage is about to be constrained.
• Direction: The "b2b HN launch since 2012" framing is a dog whistle to developer-tool builders. They're competing on distribution through developers, not enterprise sales.
• Challenge: Django won't scale for event ingestion past a certain point. Whoever takes this job will be rewriting hot paths in 18 months — probably Kafka or ClickHouse in front of Postgres.

Skills highlighted: full-stack + Kubernetes/Helm is the modern "founding engineer" archetype. Not a specialist — a generalist who can ship a feature end-to-end and also operate the infra customers install it on. This posting is a proxy for a broader 2020 trend: the collapse of the frontend/backend/devops split at early-stage startups.

Green flags: Open source (contributions are portfolio), remote-anywhere (no visa theater), direct founder email ([email protected]), honest about being early. Red flags: "First engineering hire" at a YC company means you're the ops team, the on-call, the code reviewer, and the interviewer for hires two through ten. Comp isn't listed, which for a fresh seed is usually code for "mostly equity."

When you read() from a socket and write() to a file, the bytes make a round trip through userspace: kernel → user buffer → kernel → disk. Two copies, two syscalls, and your L1 cache gets trashed by data you never actually look at. splice() is the kernel's answer: move data between two file descriptors without ever mapping it into your address space.

The trick is that splice doesn't move bytes — it moves pipe buffer references. A Linux pipe is not a byte stream; it's a ring of up to 16 struct pipe_buffer entries, each pointing to a page (or fragment) of kernel memory with an offset and length. When you splice from a socket into a pipe, the kernel takes the socket's sk_buff pages and hands their references to the pipe. When you splice from the pipe to a file, the filesystem reads directly from those same pages. Zero copies. The data never leaves kernel space.

The catch: one end of every splice() must be a pipe. You cannot splice socket→file directly — you need a pipe as the intermediary. This is why high-performance proxies like HAProxy and nginx allocate a pipe per connection just to shovel bytes through it:

• splice(socket_fd, NULL, pipe[1], NULL, 65536, SPLICE_F_MOVE | SPLICE_F_MORE)
• splice(pipe[0], NULL, file_fd, NULL, 65536, SPLICE_F_MOVE | SPLICE_F_MORE)

Real-world example: nginx's sendfile directive uses splice under the hood for HTTP file serving. Benchmark on a 10Gbps link serving a 1GB file: read()+write() loop pegs one CPU at 100% pushing ~3 GB/s. Splice does the same workload at ~30% CPU — saturating the NIC. The wins come from (1) no user-space copy, (2) no page fault on the user buffer, (3) no cache pollution — the CPU never touches the payload.

The pipe buffer limit rule of thumb: a pipe holds 16 pages = 64KB by default (raise with fcntl(F_SETPIPE_SZ) up to /proc/sys/fs/pipe-max-size, usually 1MB). If your splice source produces faster than the sink can drain, the pipe fills and splice blocks. So splice's throughput ceiling per pipe is pipe_size / round_trip_latency. A 1MB pipe with a 10µs sink latency gives you 100 GB/s of headroom — plenty. A 64KB pipe with 1ms disk writes gives you 64 MB/s — often the actual bottleneck.

Gotcha: SPLICE_F_MOVE is advisory — the kernel silently falls back to copying if the source pages can't be stolen (e.g., they're still referenced elsewhere, or the filesystem doesn't support page stealing). Check /proc/<pid>/io to verify you're actually zero-copy.