Daily Digest — 2026-07-13

This function is supposed to count records by status. It works on the developer's laptop with test fixtures, passes code review, and ships. A week later, the dashboard shows every order status has a count of 1 — even though the database has thousands of them.

from itertools import groupby

def count_by_status(records):
    """Count records by status. Returns {status: count}."""
    result = {}
    for status, group in groupby(records, key=lambda r: r['status']):
        result[status] = sum(1 for _ in group)
    return result

records = [
    {'id': 1, 'status': 'pending'},
    {'id': 2, 'status': 'shipped'},
    {'id': 3, 'status': 'pending'},
    {'id': 4, 'status': 'shipped'},
    {'id': 5, 'status': 'pending'},
]

print(count_by_status(records))
# Expected: {'pending': 3, 'shipped': 2}
# Actual:   {'pending': 1, 'shipped': 1}

The Bug

itertools.groupby is not the Python analogue of SQL's GROUP BY. It groups only consecutive elements that share a key, exactly like Unix's uniq. If the input isn't sorted by the key, you get one "group" per run of identical values, not one group per distinct value.

For the sample data, groupby yields five groups: ('pending', 1), ('shipped', 1), ('pending', 1), ('shipped', 1), ('pending', 1). The dictionary assignment then overwrites each key four times, leaving the last count seen for each status — which, coincidentally, is always 1.

Why this passes tests: developers write fixtures with pre-sorted data ("pending, pending, shipped, shipped") because it reads naturally. In that shape, groupby works correctly and the bug hides. Production data — records streaming in by insertion time — rarely arrives sorted by status. The test fixture is the bug's camouflage.

There's a second, quieter hazard: even if you iterate groupby correctly, the group iterator is consumed lazily and shares state with the outer iterator. If you advance the outer loop before draining the inner group, the group's remaining items are silently discarded. Storing groups in a list for later use produces empty groups.

The Fix

If you actually need grouping semantics, either sort first or reach for the correct tool: collections.Counter or collections.defaultdict. For counting, Counter is the one-liner:

from collections import Counter

def count_by_status(records):
    return Counter(r['status'] for r in records)

If you specifically want groupby — say, to build lists of records per status — sort by the key first:

from itertools import groupby
from operator import itemgetter

def group_by_status(records):
    key = itemgetter('status')
    sorted_records = sorted(records, key=key)
    return {status: list(group) for status, group in groupby(sorted_records, key=key)}

Reserve groupby for cases where consecutive-run semantics are what you actually want: collapsing repeated log lines, run-length encoding, chunking a stream at boundary changes. For "aggregate by category," use Counter or defaultdict — they can't be fooled by input order.

When you put a noisy digital block (a CPU, a SerDes, a DDR PHY) on the same silicon as a sensitive analog circuit (a PLL VCO, an ADC comparator, an LNA), the digital switching current dumps charge into the shared substrate. That substrate is a low-resistance bulk of lightly-doped silicon, so a current spike under the CPU shows up as a voltage wiggle under the ADC 500 μm away. The ADC's LSB is 100 μV. The wiggle is 5 mV. You just lost 5.5 bits of resolution because the CPU incremented a counter.

The mechanism. Every NMOS drain has a reverse-biased junction to the P-substrate. When the drain swings, capacitive coupling injects displacement current into the substrate. Multiply by a million switching transistors and you get a substrate that's ringing at every clock edge. The substrate also carries return currents from bond-wire inductance (Ldi/dt drops), which show up as ground bounce that isn't on any ground wire.

Guard rings. A guard ring is a continuous ring of substrate contacts (P+ diffusion in a P-substrate) tied to a dedicated quiet ground, wrapped around the victim circuit. It acts as a low-impedance sink: substrate noise flowing toward the analog block hits the ring first and gets shunted to ground before it reaches the sensitive transistor bulk. A double guard ring — P+ ring around the analog, N+ ring around that tied to a quiet VDD — adds a reverse-biased junction between them, blocking DC substrate currents entirely.

Deep N-well isolation. On triple-well processes, you can put the NMOS of the analog block inside a P-well that sits inside a Deep N-Well tied to quiet VDD. Now the analog P-well is electrically isolated from the noisy chip substrate by two back-to-back diodes. This is how PLLs and ADCs survive on SoCs — the VCO is literally on its own island of silicon.

Rule of thumb. Substrate noise attenuates roughly as 1/r in a lightly-doped substrate and 1/r³ in an epi-on-heavy-substrate process (the heavy P+ underlayer shorts out lateral noise). A single guard ring gets you 10–15 dB of isolation; double ring plus deep N-well can reach 40–60 dB. If your ADC needs 12 bits (74 dB SNR), you need every dB you can get.

Real example. Cellular RF transceivers (Qualcomm, Broadcom) integrate a 2 GHz LNA next to a 3 GHz digital baseband. The LNA sits inside a deep N-well moat, surrounded by a P+/N+ double guard ring, on its own bond-wire-isolated ground pad. Skip any one of those and the receiver's noise floor rises 10 dB — the phone drops calls indoors.

A Geiger-Müller (GM) tube is a gas-filled cylinder that avalanches into a brief conductive pulse when an ionizing particle passes through. To count those pulses reliably, you need three things: a stable high-voltage bias supply, a way to quench the avalanche, and a safe signal pickoff that survives kilovolt transients.

The bias supply. Most hobby tubes (SBM-20, LND-712, J305) need 400–500 V DC at essentially zero average current — the tube only draws current during the microsecond avalanche. A small flyback or Royer oscillator driving a step-up transformer, followed by a Cockcroft-Walton multiplier or a simple diode-capacitor peak rectifier, is standard. Regulate with a Zener-referenced feedback loop or a resistor divider into a comparator that pulse-skips the driver. Keep the bulk output capacitor small (10–47 nF) — a large cap stores enough energy to damage the tube if it arcs.

The anode network. Bias the anode through a large resistor R_a — typically 4.7 MΩ to 10 MΩ. This resistor is the quench: during the avalanche, current through R_a drops the anode voltage below the sustaining threshold, stopping the discharge. Without adequate quench resistance, the tube goes into continuous discharge and dies within minutes. Modern halogen-quenched tubes are more tolerant, but organic-quenched tubes (older Russian surplus) will destroy themselves if you get this wrong.

Signal pickoff. You cannot connect a microcontroller directly to a 400 V node. Two common approaches: (1) tap the cathode through a small resistor (10–100 kΩ) to ground and read the negative-going pulse across it, or (2) capacitively couple the anode through a high-voltage cap (1 nF, 1 kV or 2 kV rated) into a divider clamped by a small-signal diode to your logic rail. Follow with a Schmitt trigger or comparator — the raw pulse is only 1–100 µs wide and ragged.

Rule of thumb. Tube dead time τ_d ≈ 100 µs for typical GM tubes, so maximum reliable count rate ≈ 1/(2τ_d) ≈ 5000 counts/second. Above that, apply the correction n_true = n_measured/(1 − n_measured·τ_d).

Real-world example. A background-radiation logger using an SBM-20 tube typically reads 20–40 CPM (0.3–0.7 CPS) — far below the dead-time limit, so raw counts equal true counts. Near a lantern mantle or old radium watch dial, rates can spike to 500+ CPS, where dead-time correction becomes essential.

Shield the HV section, keep the anode trace short, and use guard rings around the pickoff node — leakage across a dusty PCB will steal your pulses.

A gas spring is a sealed steel cylinder charged with high-pressure nitrogen (typically 20–200 bar) with a piston rod that pushes against the trapped gas. Unlike a coil spring where force rises linearly with compression (F = kx), a gas spring delivers nearly constant force across most of its stroke — the "spring rate" is only 20–40% from fully extended to fully compressed. This is because the piston rod displaces gas volume, but the cylinder itself is large enough that the pressure ratio stays modest.

Anatomy: A hollow tube, a piston with a small orifice or check valve, a rod sealed by a rod guide with a wiper and pressure seal, and nitrogen plus a small amount of oil. The oil lubricates the seal and provides damping at end of stroke — the last 20mm often feels dramatically slower as oil migrates past the piston.

Real-world examples: Rear hatches on SUVs, office chair height adjusters (those are lockable gas springs with a release valve), industrial machine covers, hospital bed articulation, and toolbox lids. Aircraft use them for canopy assist. A typical automotive tailgate spring delivers about 400–800 N over a 250mm stroke.

Sizing rule of thumb: To hold a hinged panel open, calculate the torque you need to overcome (weight × horizontal distance from hinge to center of mass), then divide by the moment arm from the hinge to the spring's line of action. Add roughly 10–15% extra force so the panel self-opens partway rather than parking mid-stroke. For a 15 kg hatch with center of mass 400mm from the hinge, gravity torque is 15 × 9.81 × 0.4 = 59 N·m. If the spring pushes with a 200mm moment arm, you need ~295 N. Use two 165 N springs (one per side) for balance.

Orientation matters: Install gas springs rod-down when possible so oil pools around the seal, preventing dry-out and extending seal life from years to decades. Rod-up mounting is a common failure cause — the seal runs dry and nitrogen leaks past.

Failure modes: Nitrogen slowly diffuses through seals (2–5% per year is normal); a spring that no longer holds the hatch is usually gas loss, not mechanical damage. Side loading destroys rod seals — the rod must move purely axially. Never heat a charged gas spring (welding nearby, hot paint booth) — pressures can triple and burst the tube.

Variants: Traction gas springs pull instead of push. Lockable gas springs have an internal valve released by a pin (office chairs, hospital beds). Adjustable-force springs let you bleed nitrogen through a Schrader valve to tune force in the field.

Tucked into the preface of a 1923 cookery textbook is a claim that would strike a modern reader as bizarre: soup is not just food. It is a tool, with defined purposes and a measurable economic function within the household. The Woman's Institute of Domestic Arts and Sciences — a correspondence school in Scranton, Pennsylvania that taught cooking, sewing, and home management to women by mail — treated this as foundational knowledge:

"In her study of Soup, she will come to a thorough appreciation of the place that soup occupies in the meal, its chief purposes, and its economic value. All the different kinds of soups are classified and discussed, recipes for making them, as well as the stocks used in their preparation, receiving the necessary attention."

Notice the framing: soup has "chief purposes" (plural), an assigned "place" in the meal, and an "economic value" worth studying. A whole taxonomy of stocks and soups was considered the minimum literacy for running a household.

The forgotten claim is not a recipe — it's the idea that meals had architecture. Every course did structural work:

• Appetite priming: a light broth before a heavy meal stimulated digestive secretions and slowed overall eating, so families felt full on less expensive protein.
• Waste capture: vegetable trimmings, bones, and meat scraps that would otherwise be discarded became stock — turning what a modern kitchen throws in the trash into the flavor base for the next three meals.
• Ration extension: a pound of beef bones plus water and time yielded four quarts of nutritionally dense broth. In 1923, that math mattered.

Is there modern evidence for any of this? Quite a lot, actually. Nutrition researchers in the 2000s revisited the "soup preload" effect and found that eating broth-based soup before a meal reduces total caloric intake by roughly 20 percent — Barbara Rolls at Penn State has published on this repeatedly. Bone broth's collagen and mineral content has been rediscovered by both the gut-health and athletic-recovery communities. And every zero-waste kitchen influencer on Instagram is rebranding what the Woman's Institute called "stockpot economy" as a novel lifestyle.

The authors weren't ahead of their time — they were of their time, when food waste in a household meant real money lost and every housewife was expected to understand it. What's remarkable is how completely that literacy vanished. Ask a modern home cook to explain the "chief purposes" of soup within a meal and you'll mostly get blank looks. Soup is now a thing you buy in a can when you're sick.

The Woman's Institute treated it as infrastructure. The stockpot was the household's compost bin, flavor factory, and calorie stretcher — a single vessel doing three jobs that we now solve with three separate industries (municipal composting, bouillon cubes, and appetite-suppressant apps).

Buried in a declassified CIA intelligence file from 1957 is a product catalog page for a laboratory instrument that quietly upends a common assumption about mid-century Chinese industry. The document — assembled by U.S. intelligence to track the technical capabilities of Mao's China — describes the Photo Electric Colorimeter Model 93B, a piece of analytical chemistry hardware that was, apparently, being turned out of Chinese factories a mere eight years after the founding of the People's Republic.

The catalog copy has the confident tone of a Sears advertisement:

The Photo Electric Colorimeter Model 93B embodies the most recent improvements in design for efficiency, compactness and economy. This instrument is extremely simple to use and is easily standardized by reading the transmittancies of a number of solution of predetermined concentrations prepared in accordance with a specific technique... This instrument is designed to work either from a 6 Volt battery or direct from a 220-250 volt a. c. mains supply through a constant voltage transformer.

Two details deserve unpacking. The first is the dual power supply. In 1957, mains electricity across most of rural China was unreliable, unstable, or nonexistent — brownouts and voltage swings could destroy sensitive analog electronics. The Model 93B's designers solved this by letting the operator swap over to a 6-volt lead-acid battery — essentially a car battery — when the grid failed. Modern lab instruments almost never ship with this kind of pragmatic redundancy; they assume clean 120V or 240V and die when they don't get it. Field biologists working in remote regions today still improvise this exact solution with deep-cycle batteries and inverters.

The second detail is the calibration methodology:

...reading the transmittancies of a number of solution of predetermined concentrations... plotted on a semilogarithmic scale against the known concentration on a linear scale, yield an analytical (calibration) curve or standard against which the unknown solutions... may be compared.

This is Beer-Lambert law in action, and it is exactly the procedure a biochem undergraduate performs today with a $3,000 spectrophotometer. The Model 93B was doing it with a filter, a photocell, and a galvanometer — no microprocessor, no software, no auto-calibration. A skilled technician could measure protein concentrations, water contaminants, or drug purity with a device that could survive being dropped off the back of a truck.

The CIA's interest here is telling. American analysts were tracking these catalogs because they revealed that China was not the technological backwater the Cold War narrative implied. By 1957, Chinese factories were producing analytical instruments comparable to Western equivalents from a decade earlier — instruments that ran on car batteries and could be repaired with a soldering iron. It's a preview of the manufacturing muscle that would, seventy years later, dominate the global market for scientific equipment.

The forgotten wisdom isn't the colorimeter itself — it's the design philosophy. When infrastructure is unreliable, build for the failure mode. Modern engineers rediscover this every time they design for the developing world.

In 1951, television was ephemeral. A program aired live on the East Coast, then was re-performed three hours later for the West Coast — because there was no way to record it. Kinescope films (a movie camera aimed at a TV screen) were blurry and slow. Audio tape existed since Poulsen's 1898 telegraphone, but video demanded a thousand times more bandwidth — roughly 4 MHz versus 4 kHz — and running tape past a stationary head fast enough would require reels the size of dinner plates spinning at 100 feet per second.

Ampex Corporation, a small Redwood City firm founded by Russian immigrant Alexander M. Poniatoff, threw a six-person team at the problem. It was led by Charles Paulson Ginsburg, a 30-year-old radio-station engineer with no college degree, and included a 19-year-old part-timer named Ray Dolby — yes, that Ray Dolby.

Ginsburg's insight, filed as U.S. Patent 2,956,114 on October 5, 1954 (granted October 11, 1960), was elegant: don't move the tape faster — move the heads. Four magnetic heads were mounted on a drum spinning at 14,400 RPM perpendicular to the tape's travel. Each head laid down a nearly-vertical stripe across a two-inch tape, then handed off to the next head. The relative head-to-tape velocity became 1,500 inches per second, while the tape itself crawled at 15 inches per second. This became known as quadruplex transverse scanning.

On April 14, 1956, at the NARTB convention in Chicago, Ampex unveiled the VRX-1000 (later branded VR-1000). CBS execs watched a tape play back a recording they had just made minutes earlier. They stood up and applauded. CBS ordered three machines on the spot at $50,000 each (~$580,000 in 2026 dollars). Within three years, every U.S. network had converted.

The modern lineage is direct and almost dizzying:

• Helical scan — a slight tilt of Ginsburg's rotating drum — became the dominant format for U-matic (1971), Betamax (1975), VHS (1976), Betacam, Hi8, and DV. The consumer VCR was Ginsburg's patent, shrunk and cost-reduced.
• Time-shifting culture begins here. Delayed West Coast broadcast → instant replay (first used in the 1963 Army-Navy game) → home VCR "record the game" → TiVo (1999) → cloud DVR → YouTube's "watch it whenever" default. Every "rewatch" button traces back to a rotating drum in 1956.
• Data-center tape. LTO (Linear Tape-Open) — the format holding roughly 60% of the world's archived data as of 2026 — uses variants of helical scan derived from videotape research. When Amazon Glacier or a hyperscaler cold-stores your photos for pennies per terabyte-year, it's Ginsburg's math.
• Ray Dolby left Ampex to found Dolby Laboratories in 1965. The noise-reduction techniques he refined were originally aimed at cleaning up the noisy analog stripes Ginsburg's heads laid down.

Ginsburg received the National Medal of Technology in 1990 and died in 1992. He never became famous — no one names buildings after him — but the quadruplex demo at NARTB is arguably the moment television stopped being a live event and became content. Netflix, TikTok, DVR skip-ads, courtroom video evidence, the entire post-production industry, and every meme clip ever paused mid-frame all began the moment four rotating heads proved you could freeze a broadcast on iron oxide.

FlowForge pitches itself as a visual workflow automation builder — think drag-and-drop pipelines, webhook triggers, and a claimed 50+ integrations, all wrapped in a no-code interface aimed at developers rather than business users. In a space dominated by hosted giants like Zapier, Make, and n8n, an open-source TypeScript entrant with a developer-first framing is worth a look, even at zero stars.

What makes this one interesting is the positioning. Most no-code automation tools optimize for non-technical audiences, which means developers hit a ceiling fast: no version control on flows, no way to drop into code when a node doesn't exist, no local dev story. The tag cloud here — developer-tools, nodejs, react, typescript, saas — suggests the author is trying to thread the needle: keep the drag-and-drop ergonomics, but make it something a developer can actually extend, self-host, and reason about.

Who benefits?

• Solo devs and small teams who want internal automation without paying per-task fees to a SaaS vendor.
• Backend engineers wiring together webhooks between third-party APIs who'd rather sketch a pipeline visually than write another glue script.
• Learners curious about how workflow engines are built — node graphs, execution scheduling, retry semantics, and integration abstractions are all meaty design problems worth studying in a real codebase.

The obvious caveats: zero stars, brand-new push, no way to know yet whether the "50+ integrations" claim reflects real, tested connectors or scaffolded stubs. That's the risk with any fresh repo. But the topic list is coherent, the description is specific rather than buzzword soup, and TypeScript + React + Node is a stack most web devs can jump into and contribute to on day one. Worth cloning and skimming the source before committing to it for anything real.

Counting the number of 1-bits in a word sounds like a party trick until you realize how many hot loops depend on it: bitmap indexes in databases, Hamming distance for nearest-neighbor search, chess engine piece counting, error-correcting codes, sparse vector intersection, and the entire cardinality-estimation family (HyperLogLog). Before dedicated hardware, this operation was one of the ugliest microbenchmarks in existence.

The classic software approach — the Hamming weight bit-twiddle — looks like this:

• Mask alternating bits, add pairs together.
• Mask alternating nibbles, add pairs of pairs.
• Continue with alternating bytes, then multiply by 0x0101010101010101 and shift right 56 to sum bytes.

That's ~12 dependent instructions per 64-bit word, forming a serial chain. It sits on integer ALUs and clogs the reorder buffer. A CPU doing bitmap intersection over gigabytes of data would spend most cycles inside this dance.

POPCNT collapses all of it into a single micro-op. Introduced with SSE4.2 on Nehalem (2008) and mandatory in ARMv8's CNT instruction, it has a latency of 3 cycles on modern Intel/AMD, throughput of 1 per cycle, and executes on a single integer port. The silicon underneath is a Wallace tree of half-adders and full-adders: bits are combined in a log-depth reduction tree, so the critical path is O(log₂ 64) = 6 gate delays instead of a serial chain.

Concrete example — Roaring Bitmaps (used by Lucene, Druid, ClickHouse) store dense chunks as raw 64-bit words. Computing the cardinality of an intersection is literally popcnt(a & b) in a loop. On a 1 MB bitmap chunk (16,384 words):

• Software Hamming weight: ~12 ops × 16,384 = ~196,000 ops, roughly 50,000 cycles.
• Hardware POPCNT: 16,384 ops throughput-bound = ~16,400 cycles, a 3× speedup — and that ignores the OOO window relief.

The gotcha nobody warns you about: on pre-Ice Lake Intel chips, POPCNT has a false dependency on its destination register. Because it's encoded like a two-operand instruction, the renamer thinks the destination is also read. Tight loops like popcnt rax, [rdi]; popcnt rbx, [rsi+8] serialize on rax/rbx even though there's no real dependency. The fix: XOR-zero the destination first, or upgrade to Ice Lake (which eliminated the false dep).

Rule of thumb: if your algorithm counts bits in a hot loop and you're not using __builtin_popcountll (GCC/Clang) or _mm_popcnt_u64 (MSVC), you're leaving a 3–10× speedup on the table. AVX-512's VPOPCNTDQ extends this to 512-bit vectors — 8 popcounts per cycle.

There's a peculiar subculture of hobbyists, homelab operators, and budget-conscious ML researchers who trawl eBay for decommissioned datacenter GPUs — the Tesla K80s, M40s, P40s, and P100s that once powered enterprise clusters and now sell for the price of a decent dinner. This post appears to be a rigorous benchmarking exercise across 15 of these cards, measured against workloads that actually matter in 2026: LLM inference, image generation, and modern CUDA compute.

Why does this matter? A few reasons:

• Economics of local inference are shifting. As frontier models get smaller-but-smarter (distilled 7B–30B parameter models routinely rivaling last year's flagships), the question of what hardware is "good enough" for self-hosted inference becomes genuinely interesting. A $150 Tesla P40 with 24GB of VRAM can run quantized Llama-scale models that would have required an A100 two years ago.
• The compute-per-dollar frontier isn't linear. Older architectures lose CUDA feature support (no FP8, no BF16 on some Pascal cards, no Flash Attention 2 on Kepler), which means raw FLOPS numbers mislead. Real benchmarks against real workloads expose which cards are actually usable versus which are landfill-in-waiting.
• Environmental angle. "E-waste" is doing real work in the title. Enterprises retire GPUs on tax schedules, not on capability curves. A well-documented second life extends the useful lifespan of silicon that took enormous energy to fabricate.

A technical audience would find value in the concrete numbers — tokens/second on llama.cpp, iterations/second on Stable Diffusion, power draw under sustained load, cooling requirements (many of these are passively-cooled server cards requiring 3D-printed shrouds and blower fans). The gap between marketing spec sheets and observed performance on modern software stacks is usually where the interesting story lives.

Fifteen cards is also enough to plot a curve rather than anecdotes. You start to see clusters: Kepler-era cards effectively excluded by dropped CUDA support, Maxwell hanging on for specific workloads, Pascal as the surprising sweet spot, Volta and Turing offering diminishing returns per dollar.

This is exactly the kind of practical, empirical, deeply-in-the-weeds writeup that HN historically rewards — and yet it sits at 2 points with no discussion. Probably a timing issue more than a quality one.

Of the ten postings, Substack's is the most revealing because it's the most restrained. A Y Combinator W18 company, fresh off an a16z Series A, hiring a single full-stack engineer as employee number eleven — and telling you exactly what runs the show.

The stack: deliberately boring. Node, Express, Postgres, all sitting on Heroku, with React on the front. For a company that had just closed an a16z round in 2018, this is a statement. No Kubernetes, no microservices, no bespoke infra team, no Kafka pipeline. Heroku is the tell — they're paying a platform premium to avoid hiring DevOps. That's a conscious trade of margin for velocity, and it only works if you believe your differentiation is product, not infrastructure.

What "10 people, thoughtfully building" actually signals. The word thoughtfully is doing a lot of work. Post-a16z, the default playbook is aggressive hiring. Choosing not to means the founders have a thesis: that Substack's moat is editorial trust and writer economics, not engineering headcount. The "two of our three founders are technical" note (truncated but visible) reinforces it — founders are still shipping, and they want a peer, not a report.

The business model is embedded in the pitch. "Writers' and readers' incentives are aligned" and "top writers making six figures" are recruiting lines aimed at engineers who've watched ad-supported media rot. This is 2020 — pre-newsletter-bubble — and they're already framing themselves as the anti-Medium. They're recruiting for values, not just skills.

Green flags:

• Concrete traction numbers (50k paid subs, six-figure top writers) rather than vanity metrics
• Named investor, named stage — no ambiguity about runway or leverage
• Onsite SF only, small team — you'll actually influence the product
• Simple stack means new hires ship in week one

Yellow flags:

• Heroku at Series A scale is a ticking clock — someone will spend 2021 migrating off it
• "Full stack" at a 10-person company means on-call, support tickets, and whatever else breaks
• SF onsite in a market where remote was becoming table stakes narrows the funnel hard
• No mention of compensation, equity band, or benefits — typical for HN but notable

The most interesting thing is what's absent: no ML, no recommendations engine, no personalization team. Substack's bet is that curation-by-subscription beats curation-by-algorithm. That's an architectural decision as much as a product one.

Every futex operation you've probably used — FUTEX_WAIT, FUTEX_WAKE — does one thing. But FUTEX_WAKE_OP does two things atomically: it modifies the value at a second futex address, and then conditionally wakes waiters on either or both futexes based on the old value. It exists for exactly one reason: to make pthread_cond_signal() not suck.

The syscall takes two futex addresses (uaddr, uaddr2) and an encoded 32-bit val3 that packs four fields: an op (SET, ADD, OR, ANDN, XOR), an oparg, a cmp (EQ, NE, LT, LE, GT, GE), and a cmparg. The kernel atomically loads *uaddr2, applies op(oldval, oparg) to store the new value, and then wakes up to val waiters on uaddr. If cmp(oldval, cmparg) is true, it also wakes up to val2 waiters on uaddr2.

Why glibc needs this: A condition variable has two internal futexes — one that threads sleep on inside pthread_cond_wait(), and the associated mutex. Without WAKE_OP, signaling a condvar while a thread is racing between "released mutex" and "started waiting" required either extra syscalls or a lost-wakeup risk. With WAKE_OP, glibc bumps the condvar sequence counter and wakes waiters in one atomic kernel operation — no window where state is inconsistent.

Concrete example — the classic condvar signal path:

• uaddr = &cond->futex (the sequence counter waiters sleep on)
• uaddr2 = &cond->lock (internal spinlock)
• op = FUTEX_OP_SET, oparg = 0 → atomically store 0 into the internal lock, releasing it
• val = 1 → wake one waiter on the sequence counter
• cmp = FUTEX_OP_CMP_GT, cmparg = 1, val2 = 1 → if lock had contenders (oldval > 1), also wake one waiter on the lock

One syscall replaces what would otherwise be a store, a compare, and up to two FUTEX_WAKE calls. On a contended condvar, that's roughly 3 syscalls collapsed into 1 — saving ~500ns per signal on modern hardware once you count syscall entry/exit and the kernel taking the futex hash bucket lock only once instead of three times.

Rule of thumb: if you find yourself doing "atomically modify X then wake waiters on Y" in userspace synchronization primitives, FUTEX_WAKE_OP is the primitive you want — but almost nobody outside libc implementers uses it directly. It's the invisible plumbing that makes pthread_cond_signal a single trap instead of a race-prone dance.

RFC 4493 specifies AES-CMAC, a message authentication code built on the AES block cipher. It sounds obscure, but if you've ever used IKEv2, IPsec ESP with GMAC fallback, IEEE 802.1AE (MACsec), 802.11i (WPA2), Bluetooth pairing, EMV chip cards, or the SIV mode from RFC 5297, you have almost certainly relied on CMAC. It's one of those quiet primitives that shows up everywhere once you start looking.

The problem it solves. Before CMAC, the standard block-cipher MAC was CBC-MAC. CBC-MAC is elegant — encrypt the message in CBC mode, throw away everything but the last block — but it has a nasty catch: it is only secure for fixed-length messages. If an attacker sees MACs for messages M1 and M2, they can forge a MAC for a longer concatenated message. Various patches existed (EMAC, XCBC, TMAC, OMAC), each fixing part of the problem at the cost of extra keys or extra block cipher calls. NIST standardized OMAC1 as CMAC in SP 800-38B in 2005, and RFC 4493 is the IETF's version pinned to AES-128.

The clever trick. CMAC uses a single AES key. From that key it derives two subkeys, K1 and K2, by encrypting an all-zero block and then doing a left shift with conditional XOR against the constant 0x87 — this is multiplication by x in the finite field GF(2^128). To MAC a message:

• Split the message into 16-byte blocks.
• CBC-encrypt them normally, except XOR the final block with K1 if the message length is an exact multiple of 16, or with K2 after 10... padding otherwise.
• The last ciphertext block is the tag.

That one XOR distinguishes between "message ended cleanly" and "message was padded," which kills the length-extension attack that broke plain CBC-MAC. No extra keys to distribute, no extra block-cipher call per message, provably secure for arbitrary-length inputs.

Design decisions worth noticing. The authors chose to leave truncation to the caller — the tag is always 128 bits, but protocols routinely use 64 or 96 bits. They also specified byte-level behavior meticulously, with test vectors, because subtle bugs in the subkey derivation (especially the 0x87 reduction polynomial and the shift-vs-XOR ordering) had bitten earlier implementations. Reading the RFC feels less like a spec and more like a defensive walkthrough for implementers.

Why it still matters in 2026. AEAD modes like GCM and ChaCha20-Poly1305 have absorbed most new authenticated-encryption work, but CMAC remains the workhorse whenever you need a MAC and already have an AES engine — which describes essentially every embedded chip, HSM, and smartcard shipped in the last fifteen years. It is the PRF inside IKEv2's PRF_AES128_CMAC, the integrity check inside MACsec, and the building block of SIV mode used for key wrapping and deterministic encryption. When constrained devices (RFC 7228 territory) need authentication, CMAC is often the answer because it reuses silicon they already have.

A quirky footnote. The 0x87 constant is the low-weight irreducible polynomial x^128 + x^7 + x^2 + x + 1. The same polynomial powers GHASH inside AES-GCM. Two of the most-deployed MACs on Earth share their algebraic backbone with a five-byte constant most engineers have never noticed.

The asker is shipping an iOS app built with Kotlin Multiplatform + Compose Multiplatform. They've wired up NSExceptionKt, Firebase Crashlytics, and Xcode's native crash tooling, yet: (a) many crashes never surface at all, and (b) the ones that do arrive with stack traces that are effectively unreadable — often just hex addresses or generic Kotlin/Native internals.

Why this is genuinely hard. A KMP iOS binary is Kotlin compiled through Kotlin/Native (LLVM) into an Objective-C framework. That means a crash can originate in three different worlds — Kotlin, Swift/ObjC, or the C runtime — and each has its own unwinding and symbolication story:

• Kotlin/Native exceptions aren't NSExceptions. Uncaught Kotlin throwables terminate the process via abort(), so Crashlytics sees a SIGABRT with no Kotlin frames unless something bridges them.
• Kotlin/Native produces its own DWARF, but Crashlytics/App Store Connect only auto-symbolicate frames whose dSYMs they have. If you don't upload the shared framework's dSYM, you get 0x0000000104abcd12 instead of MyViewModel.onClick.
• Compose Multiplatform adds another layer — Skia/native drawing crashes can happen off the main thread with mangled symbol names.

A direction toward a fix.

1. Upload the KMP framework's dSYM to Crashlytics. The Gradle output at build/bin/iosArm64/releaseFramework/shared.framework.dSYM must be uploaded via upload-symbols (or the run-script phase) alongside your app's own dSYM. This alone fixes ~80% of "unreadable" traces.
2. Install a Kotlin uncaught exception hook. Use setUnhandledExceptionHook { throwable -> ... } in commonMain (or iOS-side) to forward the throwable to Crashlytics before the runtime aborts. Log throwable.getStackTrace() as a non-fatal so Firebase captures the Kotlin frames.
3. Keep NSExceptionKt but understand its limit. It converts Kotlin exceptions crossing the ObjC boundary into NSExceptions with symbolicated traces — but it only helps for exceptions that actually cross the bridge. Pure-Kotlin crashes still need the hook above.
4. Disable stack trace stripping in release. In your framework config: freeCompilerArgs += ["-Xg0"] or ensure debug info is preserved (-Xadd-source-mapping).

Gotchas. Bitcode is deprecated but if legacy settings strip symbols during App Store processing, dSYMs must come from App Store Connect, not your local build. Also, background-thread Kotlin crashes need the hook installed on that thread's context — the new memory model made this easier but it's still per-worker.

Everyone reaches for LRU by default. But there's a class of workloads where LRU is exactly backwards — and MRU (Most Recently Used) eviction, which throws out the item you just touched, is the right answer.

The core insight: LRU assumes recency predicts future access. MRU assumes the opposite: if you just accessed something, you're done with it and won't come back soon. This sounds bizarre until you see the access pattern.

The canonical case: sequential scans over a working set larger than cache. Imagine a 10GB table, a 2GB cache, and a nightly job that scans the whole table row by row. With LRU:

• You read rows 1–2GB → they fill the cache.
• You read rows 2–4GB → they evict rows 1–2GB (the "least recently used").
• Tomorrow's scan starts at row 1 again → cache miss on everything. 0% hit rate.

LRU pessimizes this workload. Every eviction throws out the block you're most likely to need next cycle, and keeps the block you just finished with.

MRU flips this. When the cache is full and you need to load row 2GB+1, you evict the row you just read — because you're scanning forward and won't touch it again this pass. The rows from the start of the scan stay cached, so the next full scan gets partial hits on the front of the table.

Real-world use: PostgreSQL's buffer manager uses a variant of this idea. When it detects a sequential scan larger than 25% of shared_buffers, it switches to a small ring buffer (256KB by default) instead of polluting the main LRU cache. The scan reuses its own tiny window, evicting its own recent reads, and leaves the hot OLTP working set untouched. Same principle: recent access under sequential scan means "done with it."

Rule of thumb: If your access pattern is looping or sequential over a set larger than cache, LRU gives you 0% hit rate and MRU gives you (cache_size / working_set) × 100%. For a 2GB cache over 10GB of data, that's 20% instead of 0%. For anything else — Zipfian, temporal locality, hot keys — stick with LRU or LFU.

The trap: Don't apply MRU globally. It's a targeted tool for a specific access pattern. Most caches serve mixed workloads, and MRU on random access is catastrophically wrong. The real lesson is: detect the scan, isolate it, and apply the right policy to that stream — don't let one bad workload evict everyone else's hot data.

Everyone learned diff and patch. Almost nobody learned that Tim Waugh shipped a whole family of tools in 1998 for slicing, dicing, and re-comparing patches as data. patchutils gives you interdiff, filterdiff, combinediff, splitdiff, grepdiff, and rediff. If you've ever hand-edited a .patch and watched patch reject three hunks because you miscounted context lines, this package will feel like a cheat code.

Install: apt install patchutils / brew install patchutils / dnf install patchutils.

interdiff — the killer app. You reviewed feature-v1.patch yesterday. Today the author sends feature-v2.patch. What actually changed? Not "run diff on two patches" — that gives you gibberish with @@ markers as content. interdiff reconstructs both trees mentally and emits the true delta:

$ interdiff feature-v1.patch feature-v2.patch
--- a/src/parser.c
+++ b/src/parser.c
@@ -42,7 +42,7 @@
-    if (n < 0) return -1;
+    if (n <= 0) return -1;

That's what git calls range-diff — except interdiff works on any two unified patches from anywhere: mailing lists, review tools, git format-patch output, a tarball from 2004. No repo required.

filterdiff — surgical extraction. A vendor drops a 40-file patch on you and you only trust the changes under drivers/. Pull just those hunks:

$ filterdiff -i 'drivers/*' vendor.patch > drivers-only.patch
$ filterdiff -x '*/tests/*' -x '*.po' vendor.patch > no-tests-no-translations.patch
$ filterdiff --hunks=1,3 -i src/foo.c vendor.patch    # specific hunks
$ filterdiff --lines=5- vendor.patch                  # drop hunks < 5 lines

grepdiff — find the file and the hunk. Regular grep on a patch tells you the string exists somewhere. grepdiff tells you which hunk touches lines matching your pattern, and can print only those hunks:

$ grepdiff 'kmalloc' --output-matching=hunk 6.9-to-6.10.patch | wc -l
$ grepdiff -E 'CVE-\d{4}' --output-matching=file security.patch

splitdiff / combinediff — reshape patch series. Turn one monster patch into per-file patches, then recombine what you want:

$ splitdiff -a -d monster.patch          # writes monster.patch.001, .002, ...
$ combinediff a.patch b.patch > merged.patch

rediff — the one that saves your afternoon. You hand-edited a patch to remove a hunk or fix a typo, and now the line numbers in the @@ -x,y +a,b @@ headers are wrong. patch will fuzz-match some hunks and reject others. rediff re-computes the headers against the original tree:

$ rediff broken.patch > fixed.patch
# Reads each hunk, finds the true offset in the source, rewrites the header.

Why not just git? Because half the diffs in your life aren't in a repo: kernel patches on LKML, distro SPECS patches, dpkg-source quilt series, security advisories, code review email attachments, patches embedded in HTML bug reports (dehtmldiff handles that too). patchutils treats a unified diff as a first-class data structure independent of any VCS, which is exactly what it is.

Combine with lsdiff (list files touched by a patch) and you have a full IDE for patch archaeology in ~200KB of C.

The solar updraft tower is famous: warm air rises through a chimney, spins turbines. But its inverted twin — the evaporative downdraft tower — is arguably more useful, because it drops cold air directly onto a hot city while generating power on the way down. Israeli physicist Dan Zaslavsky proposed the concept in the 1970s. Let's build one for a desert megacity like Riyadh.

The physics. Hot desert air at the top of a tall shaft is misted with water. Some water evaporates, drawing about 2.26 MJ per kilogram from the air. The air cools from, say, 40°C to 25°C — a wet-bulb-limited drop. Cool air is denser than hot air, so it plummets down the shaft, hits turbines at the base, and exits as an artificial cool breeze at street level.

Numbers, please. Consider a hollow cylinder 1,200 m tall, 400 m in diameter, cross-section A = π(200)² ≈ 1.26×10⁵ m². Desert ambient: 40°C, density 1.128 kg/m³. Post-evaporation: 25°C, density 1.184 kg/m³. Density difference: Δρ ≈ 0.056 kg/m³.

Buoyant pressure at the base:

ΔP = Δρ · g · H = 0.056 × 9.81 × 1200 ≈ 660 Pa

Ignoring turbine load, terminal velocity in the shaft would be v = √(2ΔP/ρ) ≈ 33 m/s. With turbines loading the flow to about half that, we get roughly 16 m/s. Volume flow: Q ≈ 2×10⁶ m³/s. Available fluid power:

P_avail = ΔP · Q ≈ 660 × 2×10⁶ ≈ 1.3 GW

Real turbines extract maybe 60% of this after friction losses. Call it ~750 MW gross. That is the output of a mid-size nuclear reactor, from a hollow concrete tube and some sprinklers.

The water bill. Cooling 2.4 million kg/s of air by 15°C requires:

ṁ_water = (ṁ_air · c_p · ΔT) / L_vap
        = (2.4×10⁶ × 1005 × 15) / 2.26×10⁶
        ≈ 16,000 kg/s ≈ 16 m³/s

That's 1.4 million m³ per day — the entire domestic water demand of a city of 5 million. Pumping it 1,200 m up costs mgh ≈ 190 MW, or about 25% of gross output. Net: ~560 MW electrical, plus a hurricane of 25°C air spilling into the streets.

Fresh water is a non-starter in Arabia. But seawater works — you just accept that the tower doubles as the world's largest salt spray humidifier, and downstream deposition ruins any downwind farmland. Better: co-locate reverse-osmosis desalination and use the brine, or run the misters with polished RO water and vent brine to the Gulf.

Materials. The tube itself is mostly hollow — the wall carries wind and self-weight but no buoyancy load. Prestressed concrete cooling-tower construction already goes to 200 m. Scaling to 1,200 m means about a 12 m wall thickness at the base and hyperboloid geometry to resist buckling under 150 km/h desert gusts. Total concrete: ~30 million m³, roughly six Three Gorges Dams' worth. Cost: probably $20–30 billion, comparable to a large nuclear plant per kilowatt but with no fuel cycle.

The bonus. Cool air exits at 200 m/s equivalent momentum through radial diffusers, feeding a district cooling ring. Riyadh currently spends 60% of summer electricity on air conditioning. Free cold air at the base could offset a second reactor's worth of AC load — meaning the effective footprint is closer to 1 GW-equivalent.

In 1990, a Japanese ship called the Yamato-1 silently glided through Kobe harbor with no propeller, no rudder, and no moving parts touching the water. It was propelled by the same physics that powers the Sun's corona, twists galactic jets across light-years of space, and generates Earth's magnetic field from a churning iron ocean 3,000 kilometers beneath your feet. That physics is magnetohydrodynamics — MHD for short — and it's one of those rare frameworks that stitches together phenomena you'd never guess were related.

The core idea is deceptively simple: take a fluid that conducts electricity (liquid metal, plasma, salt water), move it through a magnetic field, and something strange happens. The motion induces electric currents. Those currents create their own magnetic fields. Those fields push back on the fluid. Suddenly your fluid dynamics equations and Maxwell's equations are locked in a feedback loop, and you can't solve one without the other. Hannes Alfvén won the 1970 Nobel Prize essentially for realizing that this coupling produces waves — Alfvén waves — where magnetic field lines behave like taut strings that plasma slides along.

Here's where it gets wonderfully weird. In highly conductive plasmas, the magnetic field becomes "frozen" into the fluid. Move the fluid, the field lines move with it, as if they were rubber bands embedded in Jell-O. This is why:

• Sunspots exist: convection drags magnetic field lines up through the Sun's surface, where they bundle into ropes strong enough to suppress the underlying convection and cool the surface by 1,500 K.
• Solar flares happen: those twisted rope-fields eventually snap in a process called magnetic reconnection, dumping energy equivalent to billions of hydrogen bombs into space in minutes.
• Earth has a magnetic field at all: the outer core's molten iron, sloshing due to convection and Earth's rotation, acts as a self-sustaining dynamo. Without MHD, there's no compass, no aurora, and cosmic rays sterilize the surface.

The engineering applications are equally strange. That Yamato-1 ship worked because seawater is (barely) conductive — run current through it inside a strong magnetic field, and the Lorentz force squirts water backward. It was slow and inefficient, but it worked. Tokamak fusion reactors like ITER are essentially MHD problems: confining a 150-million-degree plasma with magnetic fields so it doesn't touch the walls. Aluminum smelters use MHD to stir molten metal. NASA has studied MHD heat shields that would use a spacecraft's own plasma sheath as an electromagnetic brake during re-entry.

And then there's the astrophysical scale. The jets shooting out of black holes — those thousand-light-year needles visible in radio telescopes — are collimated by magnetic fields threading accretion disks. Star formation itself is regulated by MHD: interstellar gas clouds resist collapse because their embedded magnetic fields have to leak out first, a process called ambipolar diffusion that takes millions of years.

Caveat: both candidates today are low quality — one is an explicitly AI-generated 30-second cinematic short, the other is a hashtag-laden longevity clip from a brand-new channel with zero subscribers. Neither is a great pick, but this one at least anchors itself to a real scientist doing real work.

Steve Horvath is a genuinely important figure in aging research. He developed the epigenetic clock — a method of estimating biological age by measuring DNA methylation patterns at hundreds of specific sites in the genome. His work established that biological age can diverge measurably from chronological age, and that certain interventions appear to slow or even reverse the clock.

The video's premise — that skeletal muscle mass and resistance training influence epigenetic aging markers — reflects a real thread in the literature. Muscle tissue is metabolically active, and there's growing evidence that maintaining lean mass correlates with slower methylation-based aging.

Whether this specific video does justice to the science is another question. The hashtag-heavy title and single-digit-second-per-word pacing typical of these channels suggests a surface-level treatment. Watch it as a jumping-off point, then read Horvath's actual papers on GrimAge and PhenoAge for the real story.

Of the candidates here, this is the standout: a project-driven KiCad tutorial that builds something real and useful — an ATmega32 development board — rather than a generic "draw a resistor" walkthrough. The ATmega32 is a great teaching target because it forces you to deal with the parts that trip up beginners: a proper crystal oscillator layout, decoupling capacitor placement around Vcc/AVcc pins, an ISP programming header, reset circuitry with a pull-up, and breaking out ports cleanly to headers.

Because it's Episode 2 of a series, the creator can skip the "here's how to install KiCad" filler and get into the substance: schematic capture with proper net labels, footprint assignment for through-hole and SMD parts, and PCB layout decisions like where to place the MCU relative to the crystal to keep clock traces short. For anyone who has finished a basic KiCad intro and wants to graduate to designing something they'd actually solder and use, a dev board is the perfect next step — it's simple enough to route in one evening but complex enough to expose real design constraints.

Circuit Shala's small subscriber count (781) suggests a hobbyist creator sharing hard-won knowledge, which often beats polished but shallow big-channel content.

This is a forensic engineering case study — the kind of content that turns abstract textbook formulas into something you'll actually remember. The premise: a continuous tension rod was split into two segments in the field, seemingly a trivial change. But that "simple" modification fundamentally altered how shear stress propagated through the connection, and the floor system that had been stable suddenly wasn't.

What makes this worth watching is the intersection of load path analysis and human decision-making. Field substitutions happen constantly in construction — a contractor swaps a specified detail for something that "looks equivalent" — and the failure modes are rarely obvious until the load reveals them. A continuous rod carries tension in a single uninterrupted path; splicing it introduces a joint that must transfer the same load through shear, fastener bearing, or weld capacity, and the math changes completely.

The channel is tiny (120 subscribers) and the framing is clearly aimed at forensic engineering — root-cause analysis of structural failures. If the video delivers on the title, it should walk through the original design intent, the field change, the recalculated stresses, and where the safety margin evaporated. That's exactly the kind of concrete "why this matters" lesson that's hard to get from a statics textbook.

Most of today's crop was Shorts and hashtag-spam thumbnails, so the pickings were slim — but this one is a real project video with a functional engineering angle. The maker is prepping a Nissan 350Z for track use and is fitting a set of 3D printed brake cooling ducts designed by a community collaborator (rancor_424393).

Brake ducts are a genuinely interesting DIY application for FDM printing: they need to survive under-hood/under-fender heat, route air from a front intake to the caliper hat, and mount cleanly to factory geometry. That means real material choices (usually ASA, PETG-CF, or PA-CF over PLA), thoughtful part orientation, and CAD that accounts for airflow direction and clearance from suspension travel.

Track cars are a great showcase for why 3D printing has outgrown the "just prototypes" reputation — this is a functional performance part being tested in anger. Even if the video leans more toward a build log than a deep engineering breakdown, it demonstrates the workflow of taking a shared community design, printing it, fitting it to a real car, and validating it on track. That loop — designer → printer → driver → feedback — is where small-channel maker content shines.

Note: this batch is heavy on hashtag-spam shorts with empty descriptions. This one is the least bad option — it at least promises a substantive process walkthrough rather than pure background footage.

Excavator arms take enormous cyclic loads, and when the boom eye or stick cracks, replacement is often prohibitively expensive. Field repair is a real trade skill: you have to remove the failed material cleanly, restore geometry, and lay down weld that can survive fatigue loading again.

The description mentions gas cutting as the first step, which is the standard approach for removing worn boss material or cracked sections from thick plate — oxy-fuel handles the section thickness that a plasma cutter or grinder can't reasonably tackle. From there, a proper repair typically involves beveling the joint, preheating the heavy section to avoid hydrogen cracking, and running multi-pass fills with a low-hydrogen stick electrode like 7018.

Watch for how the welder handles fit-up on curved, misaligned parts — clamping and jigging a bent arm straight before welding is often harder than the welding itself. Also worth noticing: whether they address the root cause (a worn bushing bore, a fatigue crack propagating from a stress riser) or just cosmetically fill the damage.