Daily Digest — 2026-07-11

In October 1963, Chrysler did something no automaker has done before or since: they built 55 identical bronze coupes powered by fourth-generation A-831 gas turbines, shipped them to Ghia of Italy for coachwork, and then loaned them — one at a time, three months each — to 203 randomly-selected American families to drive as daily cars. No lease fee. No fuel restrictions. Just: drive it, and tell us what breaks.

Almost nothing did.

The Engine George Huebner Jr. Spent 19 Years Perfecting

Chrysler's turbine program started in 1954 under chief engineer George Huebner Jr. By 1963 they were on their fourth generation. The A-831 produced 130 hp at 3,600 output-shaft rpm and 425 lb-ft of torque at zero rpm — a turbine's fundamental gift, because there's no clutch, no torque converter stall, and peak twist is available the instant the fuel valve opens. It used a single centrifugal compressor, a two-stage axial turbine (one gasifier, one power), and two rotating disc regenerators that recovered ~90% of exhaust heat. The rotor spun at 44,600 rpm. There were roughly 80% fewer moving parts than in a comparable piston V8. No pistons, no rings, no valves, no cooling system, no antifreeze, no distributor, no tune-ups.

It ran on diesel, JP-4, kerosene, unleaded gasoline, heating oil, peanut oil, and — in a famously staged demonstration for the President of Mexico — tequila. It started reliably at –20°F without warmup. Combustion temperatures hovered around 1,700°F, hot enough that the exhaust could be safely vented into the passenger cabin as heat.

Why Chrysler Killed It

Three killers, in order:

• NOx emissions. Constant-high-temperature combustion is efficient for pulling energy out of fuel but murderous for nitrogen oxides. The 1970 Clean Air Act's NOx standard was written for piston engines and the A-831 couldn't hit it without adding complexity that erased the turbine's part-count advantage.
• Idle economy and throttle lag. Turbines love steady state and hate stoplights. Fuel economy at idle was catastrophic; spool-up from idle took roughly 1.5 seconds — an eternity for a merging driver.
• Tooling cost. Chrysler estimated $500 million (1966 dollars) to mass-produce the A-831. The oil crisis of 1973 was seven years away and no one at Highland Park could justify it.

In 1967, to avoid paying import duty on the Ghia bodies and to eliminate liability, Chrysler dragged 46 of the 55 cars to a scrapyard in Detroit and cut them in half with torches. Nine survived. Jay Leno owns one and drives it.

Why It Works Now

Every one of the three killers dissolves in a series-hybrid architecture. Run the turbine at a single optimal speed as a range extender charging a battery, and idle economy and throttle lag both vanish — the electric motor handles transient response. Modern SCR catalysts plus staged lean combustion have solved turbine NOx for aviation APUs; the chemistry transfers directly. Ceramic hot-section components (silicon nitride, SiC-SiC composites) allow turbine inlet temperatures above 2,500°F, pushing thermal efficiency past 40%. Additive-manufactured regenerators and recuperators cost a fraction of what Chrysler's stamped-and-brazed discs did.

Capstone Turbine already sells 30–200 kW microturbine range extenders for hybrid buses. Bladon Jets built one for the Jaguar C-X75 concept in 2010. Wrightspeed retrofitted garbage trucks with turbine-hybrid drivetrains. The pieces exist. What's missing is an automaker willing to bet a platform on multi-fuel resilience — exactly the bet Huebner made in 1963, and exactly the bet that a world juggling e-fuels, biodiesel, and unreliable grid power might actually reward now.

Imagine you hired an assistant who, every single time you asked them to file an expense report, sat down and re-invented the entire expense-filing process from scratch — reading the manual, testing which buttons work, and writing themselves fresh instructions. That's roughly how many production LLM agents behave today: every request triggers a fresh burst of "think, plan, generate code, try it, fix it." It works, but it's slow, expensive, and unreliable.

This paper proposes a smarter arrangement: let the agent make its own tools ahead of time, then just use them at runtime.

The approach works in two phases:

• Offline (the workshop phase): A "tool-maker" agent explores the live environment — poking at real APIs, watching what data comes back, and noticing which steps keep repeating in standard operating procedures (SOPs). When it spots a repeated pattern, it writes a proper function for it, tests that function against labeled examples, and fixes bugs until it passes. The result is a versioned, validated tool — code that reliably does one thing well.
• Online (the runtime phase): When a real user request arrives, the agent doesn't regenerate code. It picks the pre-built tool off the shelf and calls it. This shaves latency dramatically and eliminates a whole class of "the model wrote slightly wrong code today" failures.

The clever bit is that the tool-maker grounds itself in the actual production environment rather than guessing from documentation. It sees the real schemas, real values, real edge cases. That's the difference between a tool built from a textbook and one built by someone who's actually done the job.

There's also a self-evolution angle: as new failure modes appear, the system can generate new tools or repair existing ones, rather than being frozen forever at deployment time. This addresses a common gripe with agent systems — they either get locked in at training time (brittle) or improvise at runtime (slow and inconsistent). Tool-making sits between those extremes.

For anyone building customer-facing LLM agents, the tradeoff is compelling: you spend compute upfront to bake in reliability, and you get back predictable low-latency responses. It also means your logs become far more auditable — every action maps to a named, versioned tool rather than a fresh blob of generated code.

You've spent weeks obsessing over V-band flange surface finish, waviness, form error, and parallelism. Now we hit the last major geometric tolerance in the GD&T stack: perpendicularity. This is the angular relationship between the sealing face and the flange's central axis (the bore or hub). When perpendicularity fails, the sealing face isn't parallel to the mating flange — it's cocked relative to the pipe itself.

Think of it this way: parallelism assumes two flanges reference each other. Perpendicularity references the sealing face to the datum axis of the pipe. A perfectly flat, perfectly parallel-to-itself sealing face can still be tilted 0.5° off the pipe's centerline. When you bolt two such flanges together, the pipes don't line up straight — they meet at a slight angle, and the V-band clamp has to close a wedge-shaped gap.

Why this matters for headers:

• Cocked joints induce bending moments: The clamp squeezes hardest on one side, leaving the opposite side under-loaded. Exhaust pulses at 1200°F find the weak spot instantly.
• Pipe misalignment stress: A 0.5° perpendicularity error over a 3-inch flange offsets the downstream pipe by ~0.026". Multiply across a header-to-downpipe-to-cat joint stack and you're fighting the whole exhaust system to bolt it up.
• Thermal cycling amplifies it: Cold assembly hides the wedge; hot expansion opens it into a chuffing leak.

Real-world example: A shop welds a V-band flange onto a stainless header primary. The TIG heat pulls the sealing face 0.8° off perpendicular to the tube. On the flow bench it seals fine (bolts pull the wedge closed). At 1400°F under load, the differential expansion between the loaded and unloaded sides opens a 0.005" gap on the low-load edge. Result: a screaming exhaust leak that disappears the moment you shut the engine down and let it cool.

Rule of thumb: Perpendicularity tolerance for a V-band sealing face should be ≤0.05 mm per 25 mm of flange diameter (roughly 0.002" per inch), referenced to the pipe bore as datum A. For a 3" (76 mm) flange, that's a total perpendicularity zone of ~0.15 mm, or about 0.11° of angular tilt. Beyond that, the clamp's self-centering wedge action stops compensating and starts fighting you.

Measurement trick: Chuck the flange bore in a lathe or mount on a precision arbor, then sweep the sealing face with a dial indicator while rotating. Total indicator reading (TIR) divided by the sweep diameter gives you tangent of the perpendicularity error. It's the same setup used to check brake rotor lateral runout.

This function rounds each line item on an invoice to two decimal places, then sums the rounded amounts. Every input in the test case ends in .005, so you'd expect every item to round up to .01 and the total to be 6.03. Instead, QA files a bug: the invoice shows 6.01, and two of the three line items round down.

function computeInvoice(items) {
  let total = 0;
  const lines = items.map(item => {
    const rounded = Number(item.amount.toFixed(2));
    total += rounded;
    return { name: item.name, amount: rounded };
  });
  return { lines, total: Number(total.toFixed(2)) };
}

const items = [
  { name: "A", amount: 1.005 },
  { name: "B", amount: 2.005 },
  { name: "C", amount: 3.005 },
];

console.log(computeInvoice(items));
// Expected: A=1.01, B=2.01, C=3.01, total=6.03
// Actual:   A=1.00, B=2.00, C=3.01, total=6.01

The Bug

Number.toFixed(2) doesn't round the literal 1.005 — it rounds whatever 1.005 is actually stored as in IEEE-754 double precision, which is almost never exactly 1.005.

• 1.005 stores as 1.00499999999999989... → rounds down to 1.00
• 2.005 stores as 2.00499999999999989... → rounds down to 2.00
• 3.005 stores as 3.00500000000000012... → rounds up to 3.01

Half your items round the "wrong" way, the total drifts from the sum of the printed lines, and accountants notice within a day. Worse, the pattern isn't intuitive: (0.15).toFixed(1) returns "0.1" (stores as 0.1499...), but (0.35).toFixed(1) returns "0.4" (stores as 0.35000000000000003). It's a pseudo-random distribution driven entirely by which decimals happen to be exactly representable in binary.

On top of that, browsers and Node used to disagree on ties, and the ECMAScript spec allows implementations to pick either of two adjacent representable results. So even code that "works on my machine" may silently break in a different runtime version.

The Fix

Two workable strategies. First — and the one every finance team eventually settles on — store money as integer cents and only format for display:

function computeInvoice(items) {
  let totalCents = 0;
  const lines = items.map(item => {
    const cents = Math.round(item.amountCents);
    totalCents += cents;
    return { name: item.name, amount: (cents / 100).toFixed(2) };
  });
  return { lines, total: (totalCents / 100).toFixed(2) };
}

Second, if you can't rewrite the data model, round with an epsilon nudge before Math.round sees the value:

function roundHalfUp(n, digits) {
  const shift = 10 ** digits;
  return Math.round((n + Number.EPSILON) * shift) / shift;
}

The Number.EPSILON addition pushes values that "should" be exactly at a .5 boundary just above it, so half-up rounding produces the arithmetic answer humans expect. It's imperfect at extreme magnitudes (near Number.MAX_SAFE_INTEGER, epsilon is smaller than one ulp of your value), but it fixes the invoice.

Better still: reach for decimal.js, big.js, or the emerging Decimal proposal for anything that will ever be summed and audited. .toFixed() is a display function that superficially looks like a math function, and every product that treats it as the latter eventually ships a bug that costs someone real money.

CMOS is a wonderful thing until you try to run it at 10 GHz. The problem is fundamental: CMOS is rail-to-rail. Every gate swings its output from 0 V to VDD and back, dumping CV²f watts of energy per switch and waiting for a big PMOS to drag a heavy capacitance up to the supply. At multi-GHz speeds, you can't afford either. Current-Mode Logic (CML) is the answer, and it's how nearly every SerDes, high-speed clock buffer, and optical driver in your datacenter actually works.

The core idea is a differential pair with a tail current source. Two NMOS transistors share a fixed current I_SS (typically 1–4 mA), and their sources tie to a current sink. Two resistors R_L pull their drains up to VDD. The differential input steers all of I_SS into one branch or the other — never both, never neither. The output swings between VDD and VDD − I_SS·R_L, typically only 300–400 mV peak-to-peak per side.

That small swing is the whole trick. Less voltage swing means less charge to move (Q = CV), which means faster edges for the same current. The transistors also stay in saturation the entire time — they never enter cutoff or triode — so there's no slow subthreshold turn-on delay. It's like a runner who never comes to a full stop between sprints.

Real-world example: The clock buffers inside an Intel Xeon's on-die serial links, and every 25/50/100G Ethernet PHY, use CML. A CML XOR (used as a phase detector in CDR loops) is just two stacked differential pairs sharing a tail current — three transistor stages tall, and it runs cleanly at 25 GHz on 7nm.

Rule of thumb — CML power: Static power is simply P = I_SS × VDD, and it's constant regardless of frequency. A 2 mA tail on a 1.0 V rail burns 2 mW whether the gate switches at 1 Hz or 10 GHz. Compare that to CMOS: at 10 GHz with 20 fF load and 1 V swing, CMOS burns C·V²·f = 20 fF × 1 V² × 10 GHz = 200 μW dynamic per gate. Sounds like CMOS wins — until you realize CMOS can't reach 10 GHz in the first place at reasonable process nodes without prohibitive buffer chains.

The tradeoffs are real: CML burns power when idle, needs bias circuitry, requires matched differential routing, and consumes headroom (you need VDD > V_swing + V_DS,sat + V_tail, roughly 800 mV minimum). But when you need to move a bit every 40 picoseconds, it's the only game in town.

When you build a multi-output flyback or forward converter, only one output gets tight regulation from the feedback loop. The others droop or rise with load — often ±10% cross-regulation at best. Adding a linear post-regulator burns efficiency; adding a second buck controller adds cost and layout headaches. The elegant middle ground is a magnetic amplifier post-regulator: a saturable reactor in series with the auxiliary output rectifier that acts as a controlled switch.

The core idea: a small square-loop toroid (typically amorphous or nanocrystalline, like Metglas 2714A) sits between the transformer secondary and the output diode. During each switching cycle, the core absorbs volt-seconds until it saturates. Once saturated, its inductance collapses and current flows freely to the output. The delay time before saturation determines how much of the pulse reaches the load — effectively PWM without a transistor.

Control comes from a reset winding (or the same winding driven backward during the off-time). A small NPN transistor pulls reset current based on output voltage error. More reset current drives the core further into negative flux, so it takes longer to saturate on the next cycle, delivering less energy. Less reset current means faster saturation and more delivered power.

Real-world example: A 200 kHz forward converter has a tightly regulated +5 V main output and a loosely coupled +12 V auxiliary for fan and op-amp rails. Without post-regulation, the +12 V swings from 10.8 V (full load) to 13.6 V (light load). Adding a Metglas MP1305P4A core with 8 turns primary and 20 turns reset, plus a TL431/optocoupler-free discrete error amp, holds +12 V within ±1% across the full load range. Efficiency stays above 92% because the mag-amp dissipates almost nothing — it either blocks (high impedance, no current) or conducts (low impedance, no voltage).

Rule of thumb for core sizing: The required volt-second product is V_sec × t_blocking,max, where t_blocking is the maximum delay you need (usually 30-50% of the on-time). Pick a core where N × A_e × 2B_sat ≥ V_sec × t_blocking. For a 12 V secondary pulse at 200 kHz needing 1 μs of blocking, that's 12 μV·s — a tiny core (A_e ≈ 0.05 cm², B_sat ≈ 0.55 T) with 5-10 turns handles it easily.

Watch out for: core losses at high frequency (keep flux swing modest), reset winding leakage inductance ringing (add a small RC snubber), and the fact that mag-amps only work for bucking — they can subtract volt-seconds but never add them, so the unregulated rail must always be higher than the target.

A wave spring is a flat wire coiled edgewise into a helix, with waves (peaks and valleys) pressed into each turn. When compressed, the waves flatten, storing energy just like a coil spring — but in a fraction of the axial length. Swap a coil spring for a wave spring of equal force, and you typically save 50% of the working height. That's why they show up wherever a designer needs preload but has run out of room.

Common types:

• Single-turn — one wavy ring, used as a light preload washer under a bearing or seal.
• Multi-turn (crest-to-crest) — stacked waves nest peak-to-peak, giving higher force in the same envelope.
• Nested — multiple wave spring layers wound in parallel for very high loads.
• Linear (interlaced) — a single continuous coil with waves, giving smoother load/deflection than stacked types.

Where you'll see them: preloading ball bearings in electric motors (removes axial play, kills noise), taking up thermal expansion in aluminum housings, holding clutch plates against a pressure plate, backing mechanical seals in pumps, and inside quick-disconnect couplings. Anywhere a Belleville washer is too stiff and a coil spring is too tall, a wave spring fits.

The force rule of thumb for a crest-to-crest multi-turn wave spring (rectangular wire):

P ≈ (K · E · t³ · f · N) / (D_m³ · b · N_t⁴)

where P is load, E is modulus, t is wire thickness, b is wire width, f is deflection, N is number of waves per turn, N_t is number of turns, D_m is mean diameter, and K is a geometry constant (~3.88 for typical designs). The key takeaway from that formula: force scales with t³ and drops with N_t⁴. Doubling the number of turns cuts force by 16×, which is why designers pick the fewest turns that still give the needed travel.

Design gotchas:

• Wave springs need a bore or shaft to ride on — they don't self-center. Radial clearance is typically 1–2% of diameter.
• Waves must nest correctly in multi-turn types; installing one flipped kills the load rating.
• Deflection should stay below ~80% of free-height-minus-solid to avoid taking a permanent set.
• They handle static and low-cycle loads well but fatigue faster than coil springs at high cycle counts — check the S-N curve if you're above 10⁶ cycles.

Concrete example: A NEMA 23 servo motor uses a single-turn wave spring under the rear bearing outer race. It provides ~30 N of preload in a 2 mm axial space — a coil spring giving the same force would need ~10 mm, forcing a longer, heavier motor.

In 1919, as American factories were being reshaped by Taylorism, stopwatches, and the first generation of precision measuring instruments, John Lord Bacon and his co-editor Edward R. Markham published the third edition of a working textbook for blacksmiths and heat-treaters. In their preface, tucked between announcements of new gauges and modern methods, they left a warning that reads today like a shot fired directly at the automation debates of our own century.

The introduction of heat measuring and hardness testing instruments, together with various other modern appliances, and up to date systems of doing work have made necessary a broader knowledge of heat-treating methods than was formerly the case: for after all the most important factor is the man doing the work.

Notice the argument's shape. Bacon does not dismiss the new pyrometers and Rockwell testers arriving in shops around 1919 — he embraces them. But he inverts the expected conclusion. More instruments, he says, do not reduce the demand on human skill. They increase it. A worker who once judged steel by color alone now had to reconcile his eye against a thermocouple, understand what the instrument was measuring, and know when to trust it.

Was Bacon right? A century of research suggests he was well ahead of his time. Modern work on what Lisanne Bainbridge called the "ironies of automation" (1983) argues almost exactly this: automating a process does not eliminate the human operator but transforms their role into something harder — a supervisor of instruments who must intervene precisely when the automated system fails. Studies of aircraft cockpits, radiology reading rooms, and even self-driving cars keep rediscovering the point Bacon made in a chapter on hot iron.

The forge shop of 1919 offers an unusually clean case. Consider what "the man doing the work" actually needed to know:

• How the true color of hot steel differs under gaslight, sunlight, and the shadow of a shop wall — because a pyrometer only reads one spot.
• Whether a hardness tester's indentation was giving a valid reading on a decarburized surface, or lying about the metal beneath.
• When a piece was "soaking" evenly versus merely surface-hot — a judgment the instruments of 1919 could not make for him.

The dedication of the book — "TO ALL WHO WOULD ATTAIN, WITHOUT WHOSE ASSISTANCE IT WOULD NEVER HAVE BEEN WRITTEN" — is aimed squarely at working smiths, not managers. Bacon was defending a piece of practical wisdom that the coming century of scientific management would spend enormous energy trying to erase: that tacit craft knowledge is not a residue to be measured away, but the substrate on which measurement itself becomes useful.

When you next hear a claim that AI or automation will "eliminate" a skilled trade, it is worth remembering a Chicago forge instructor who watched the first pyrometers arrive in his shop and concluded, quietly, that they would make his craftsmen more important, not less.

In 1948, a Philadelphia grocery-chain executive walked into the dean's office at Drexel Institute of Technology and asked whether anyone could invent a way to automatically read product information at checkout. The dean declined the project. But a graduate student named Bernard Silver overheard the conversation and mentioned it to his friend Norman Joseph Woodland, a 27-year-old instructor who had spent WWII working on the Manhattan Project.

Woodland became obsessed. He cashed out his stock, moved to his grandfather's Miami Beach apartment, and started thinking. The breakthrough — as he told it for the rest of his life — came on the beach. He idly drew four fingers through the sand, then pulled them toward him, leaving parallel grooves. He suddenly realized: Morse code, but stretched vertically. Dots become narrow bars; dashes become wide bars. A machine that could read the varying widths could decode any number.

He and Silver filed U.S. Patent 2,612,994, "Classifying Apparatus and Method," on October 20, 1949. It was granted October 7, 1952. But the drawings didn't show today's familiar rectangle of stripes. Woodland worried a linear code would be unreadable if the label were rotated, so the patent's primary figure was a "bull's-eye" pattern — concentric circles of varying thickness — that could be scanned from any angle.

The mechanism was equally ambitious for 1949: a 500-watt incandescent bulb shining through the label onto an RCA 935 photomultiplier tube (borrowed from movie-projector sound systems). The reflected light pattern would be decoded into digits.

The problem was that the world had no infrastructure to use it. Reading the code required a coherent light source bright enough to overcome ambient noise, plus computing fast enough to decode a moving signal. Neither existed at consumer prices. Woodland and Silver sold the patent to Philco in 1962 for $15,000. Silver died in 1963, age 38, before ever seeing his invention scanned.

The barcode sat unused for 25 years. What finally rescued it was a stack of enabling technologies arriving at once: the helium-neon laser (cheap coherent light), the integrated circuit (cheap decoding), and a 1971 grocery-industry committee that chose a linear format called the Universal Product Code. On June 26, 1974, in a Marsh Supermarket in Troy, Ohio, a 10-pack of Wrigley's Juicy Fruit gum became the first product ever scanned at retail. That pack now sits in the Smithsonian.

The modern legacy is enormous and almost invisible:

• Retail and logistics: Every grocery scan, every Amazon warehouse pick, every FedEx tracking event descends directly from Woodland's Morse-code-in-sand idea.
• Pharmaceutical safety: Serialized barcodes now track individual drug packages from factory to patient, cutting counterfeiting.
• QR codes: Denso Wave's 1994 invention is a 2D descendant — Woodland's insight (light/dark elements encoding digits) generalized to a matrix. The pandemic-era menu QR code is his patent's grandchild.
• Boarding passes and event tickets: Almost all use PDF417 or Aztec — again, 2D barcodes.
• Vision-based robotics: Fiducial markers (AprilTags, ArUco) used in AR, drones, and factory robots are essentially barcodes for machines to locate themselves in space.

Woodland was awarded the National Medal of Technology in 1992 — 43 years after filing. Silver's family received nothing beyond the original $15,000. IBM, which hired Woodland in 1951 and helped develop the UPC, quietly refused to buy back the patent, and the pair's employer collected the royalties instead.

The patent's most surprising quality isn't what it invented — it's how early it was. The barcode was ready in 1952. The world took a quarter-century to catch up to a graduate student's fingers in the sand.

tiny-systems/http-module is a Go-based HTTP building block designed to slot into the broader tiny-systems ecosystem — a workflow engine that treats individual capabilities as pluggable modules orchestrated through Kubernetes. This particular module handles HTTP concerns: acting as an HTTP client for outbound requests, an HTTP server for inbound traffic, and serving as a webhook receiver that can trigger downstream flows.

What makes it interesting is the architectural bet behind it. Rather than shipping a monolithic workflow engine, tiny-systems is decomposing common integration primitives (HTTP, queues, transforms) into individually deployable Go modules that a Kubernetes operator can wire together at runtime. The topic tags — api-gateway, kubernetes-operator, workflow-engine, webhook — hint at ambitions that overlap with tools like Temporal, n8n, and Argo Workflows, but with a Go-and-Kubernetes-native flavor instead of the usual Node.js or Python stacks.

A few reasons it deserves a look:

• Composable design: Studying how the module exposes its HTTP capabilities to a parent orchestrator is a nice case study in plugin architecture for Go services.
• Kubernetes-native workflows: If you've wrestled with running n8n or Node-RED inside a cluster, seeing a Go-first alternative built around a Kubernetes operator is refreshing.
• Small enough to read: Zero-star repos in this space are usually early enough that the code is still comprehensible end-to-end — a rare chance to understand a workflow engine's internals before it grows layers of abstraction.

Who benefits? Platform engineers building internal integration platforms, Go developers curious about operator patterns, and anyone evaluating lightweight alternatives to heavier workflow engines for webhook-driven automation.

AES-NI is one of the strangest things in a modern CPU: a set of six instructions (AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST, AESIMC) that each collapse an entire round of AES — SubBytes, ShiftRows, MixColumns, AddRoundKey — into a single micro-op. Intel added them in Westmere (2010), ARM followed with ARMv8 crypto extensions. What was once ~15 cycles/byte in software is now ~0.6 cycles/byte, faster than a memory copy.

The magic isn't clever microcode. It's a hard-wired combinational block: 16 parallel S-box lookups, a fixed byte permutation network, and a GF(2^8) matrix multiplier, all inside one execution port. Because the S-box is implemented as combinational logic (not a table lookup), it's constant-time by construction — no cache-timing side channel like software AES suffered from. This is why OpenSSL removed its bitsliced fallback on AES-NI CPUs: the hardware is both faster and safer.

The interesting design detail is pipelining. On Skylake, AESENC has 4-cycle latency but 1-cycle throughput on port 0. AES-CBC encryption is inherently serial (each block depends on the previous ciphertext), so it runs at 4 cycles/block = 0.25 cycles/byte × 16. But AES-CTR mode has no such dependency — you can have 4 independent counter blocks in flight, and throughput hits 1 cycle/block = 0.0625 cycles/byte. This is why every modern TLS stack switched from CBC to GCM (which uses CTR internally): the hardware fundamentally rewards parallelizable modes.

Real-world example: A 10 GbE line rate is 1.25 GB/s. Software AES on a 3 GHz core (~15 cycles/byte) tops out at 200 MB/s — you'd need 6+ cores to saturate the NIC. AES-NI in GCM mode does 3 GB/s per core, so a single core handles line-rate encryption with headroom to spare. This is why kernel TLS (kTLS) exists: the crypto is essentially free.

Rule of thumb: AES-NI throughput ≈ (clock speed) / (16 × instruction throughput). For a 3 GHz Skylake in CTR/GCM mode: 3×10^9 / 16 ≈ 3 GB/s per core. If your measured throughput is much lower, you're bottlenecked on mode serialization (CBC), key schedule reloads, or memory bandwidth — not the AES unit itself.

Companion instructions PCLMULQDQ (carryless multiply) accelerate GHASH the same way, which is why GCM authentication isn't the bottleneck it used to be.

This is the original I.J. Good paper from 1965 — the one that introduced the phrase "intelligence explosion" into the technical lexicon. Six decades before Bostrom, before Yudkowsky, before every AI safety essay of the 2020s, a British statistician and former Bletchley Park cryptanalyst who worked alongside Alan Turing sketched the entire recursive self-improvement argument in a few crisp pages.

The famous passage is worth reading in its original form:

"Let an ultraintelligent machine be defined as a machine that can far surpass all the intellectual activities of any man however clever. Since the design of machines is one of these intellectual activities, an ultraintelligent machine could design even better machines; there would then unquestionably be an 'intelligence explosion,' and the intelligence of man would be left far behind. Thus the first ultraintelligent machine is the last invention that man need ever make."

Why this deserves attention from a technical audience in 2026:

• Primary source discipline. Most engineers have only encountered this argument through third- and fourth-hand summaries. Reading Good directly reveals how much of modern AI risk discourse is a restatement (or dilution) of a 60-year-old argument, and how much has genuinely advanced.
• Historical texture. Good was writing in an era when "machine intelligence" mostly meant chess programs and pattern classifiers. His willingness to reason past that horizon — to ask what happens after parity — is a masterclass in taking speculative technical arguments seriously without getting lost in them.
• Surprising nuance. The paper isn't just the intelligence-explosion soundbite. Good spends real time on subgoal formation, the economics of building such a machine, information-theoretic bounds on learning, and the ethical apparatus needed. Some of it reads as remarkably contemporary; some of it reads as a period piece — and the gap between the two is instructive.
• Context for current debates. When people argue whether current LLM scaling curves imply an intelligence explosion, they are arguing about a hypothesis Good formalized in 1965. Knowing what he actually claimed — and what he assumed — sharpens the argument.

Hosted on Mark Liberman's Language Log page at Penn, it's a clean PDF scan of the original chapter from Advances in Computers, Vol. 6. Thirty minutes of reading; a much longer half-life in your thinking.

The most revealing thing about Notion's posting (ID: 22665940) isn't what it says about tech — it's who wrote it. The founder himself, Ivan Zhao, is manning the recruiting post. That single fact tells you more about Notion's stage in early 2020 than any org chart could.

The pitch, not the stack: Notice what's missing. There is no tech stack. No "React/TypeScript/Postgres." Instead, Zhao delivers a manifesto: "create the general purpose work tool for a post-file, post-MS Office world." He frames competitors dismissively — Google Docs and Dropbox Paper are "multiplayer WordPerfect"; SaaS apps are "forms + a table + some buttons." This is deliberate. Notion is selling vision to engineers who could work anywhere, betting that ambition beats comp packages.

The stage signal: Hiring across Engineer, Designer, Sales, Marketing, PM, Support in a single post means every function is understaffed. That's classic Series-B-to-C territory — product-market fit is proven, revenue is real, and now they need to scale every org simultaneously. The SF-only, onsite-only stance in an era when remote was already gaining traction reveals Zhao's bet that in-person collaboration was still a moat for creative product work.

What the framing highlights:

• Design-led engineering culture — putting "Designer" second in the role list (before Sales) is a tell about internal hierarchy.
• Founder-mode recruiting — the CEO reading HN comments is a proxy for how flat the org still is.
• Category creation, not feature competition — the "post-file" language positions them against a paradigm, not a product.

Green flags: Direct founder engagement, coherent thesis, willingness to name competitors by weakness rather than dodge them. The self-aware joke about knowledge-worker tools being "the hot startup topic of the 90s" signals intellectual honesty about how hard the problem is.

Red flags: The onsite-SF rigidity would age poorly within months (this posting is from March 2020, right as COVID hit). No mention of comp, equity, benefits, or seniority levels means candidates self-select on belief — great for culture, terrible for compensation transparency. The lack of any technical detail also means engineers can't evaluate whether the codebase matches the marketing.

You already know splice() moves data between two file descriptors by shuffling pipe buffer pointers instead of copying bytes. But splice() requires one end to already be a pipe. What if the source is a plain char* in your process? That's where vmsplice() comes in — it "splices" user-space memory into a pipe without a copy, by mapping your pages directly into the pipe's buffer ring.

The mechanism is subtle. A Linux pipe is a ring of up to 16 struct pipe_buffer entries, each pointing at a struct page. Normally the kernel allocates those pages. With vmsplice(fd, iov, nr, SPLICE_F_GIFT), the kernel instead calls get_user_pages() on your buffer, pins the physical pages, and installs them directly into pipe_buffer slots. No memcpy. The reader on the other end of the pipe sees your bytes by reading the same physical RAM you wrote.

The "gift" is literal. With SPLICE_F_GIFT set, you are transferring ownership of those pages to the kernel. Your virtual address still maps them, but if you write to that memory before the reader consumes it, you corrupt the reader's data. The kernel doesn't COW-protect gift pages — that would defeat the zero-copy point. Worse: pages must be page-aligned and page-sized. A misaligned buffer silently falls back to a copy.

Real-world example: the vmsplice-based log shipper pattern. A logging daemon mmap()s a huge anonymous region, writes structured records into 4KB-aligned slabs, then vmsplice()s completed slabs into a pipe connected to a compressor process via splice()-to-socket. Throughput hits ~40 GB/s on a single core because the log bytes never touch the CPU cache after the initial write — the compressor reads them straight from the same physical pages. Compare to a naive write(pipe_fd, buf, len): the kernel copy_from_user()s every byte, capping you around 6 GB/s per core.

Rule of thumb: vmsplice wins when your buffer is ≥64KB, page-aligned, and you won't touch it again until the reader signals consumption. Below 64KB, the get_user_pages() overhead (page table walk + refcount + pipe_buffer setup) exceeds the copy cost of just calling write().

The security footnote: CVE-2022-0847 ("Dirty Pipe") exploited a bug where vmsplice'd pipe_buffer flags leaked between operations, letting an unprivileged user overwrite read-only files by splicing into a pipe whose stale PIPE_BUF_FLAG_CAN_MERGE flag pointed at a page-cache page. One uninitialized flag = arbitrary root file write.

Trickle is one of those beautifully simple algorithms that quietly powers a huge swath of the Internet of Things. Born from research on wireless sensor networks at Berkeley in the mid-2000s, RFC 6206 codified it as a general-purpose polite gossip mechanism: a way for nodes in a lossy, low-power mesh network to stay consistent about shared state without drowning each other (or their batteries) in traffic.

The problem. Imagine a mesh of thousands of battery-powered sensors, each needing to agree on things like routing tables, firmware versions, or configuration. Periodic broadcasts waste energy when nothing has changed. But when something does change, you need fast propagation. Traditional flooding sends O(N) messages per update; polling wastes bandwidth in steady state. Wireless links are lossy, nodes sleep unpredictably, and there's no central authority.

The insight. Trickle borrows from human etiquette: if you're at a dinner party and someone else already made your point, stay quiet. If nobody has said the thing that needs saying, speak up — but wait a random moment first so you don't talk over someone else with the same idea. Consistency is contagious; inconsistency triggers louder chatter.

The mechanics. Each node maintains three variables:

• I — the current interval length, bounded by [Imin, Imax]
• t — a random transmission time within [I/2, I)
• c — a counter of "consistent" messages heard this interval

At time t, the node transmits only if c < k (the redundancy constant, often 1). When I expires, the interval doubles up to Imax. Whenever a node hears something inconsistent (a newer version, a disagreement), it resets I back to Imin, springing the network into rapid propagation.

Why this is clever. In a stable network, intervals grow exponentially — nodes chatter less and less, saving battery indefinitely. The moment reality diverges, the whole neighborhood snaps back to fast communication. Load is essentially independent of density: whether there are 5 or 500 neighbors, the number of transmissions per interval stays near k, because everyone else suppresses. This is a rare case where a distributed algorithm gets better as the network scales.

Where you actually use it. Trickle is the transport heartbeat of RPL (RFC 6550), the IPv6 routing protocol for low-power lossy networks that runs on Thread, Wi-SUN, and countless industrial mesh deployments. It underpins MPL (Multicast Protocol for Low-Power Networks). Smart meters, connected lightbulbs, Google Nest's Thread border routers, and vast smart-agriculture deployments all use Trickle-driven RPL to keep their routing DAGs consistent. If you own a smart bulb, an algorithm you've never heard of is politely negotiating routes on your behalf right now.

A quirky detail: the randomization window [I/2, I) — not [0, I) — is deliberate. Starting at I/2 guarantees a listening period before every potential transmission, so suppression actually works. Early versions used [0, I) and suffered from short-listen problems where nodes transmitted before they had a chance to hear peers, causing redundant broadcasts. The fix is a two-word change in the spec and a paper's worth of insight behind it.

The asker has a PCIe device with a BAR mapped write-combine (WC) into userspace. They issue a burst of memcpy writes with no explicit fence, then call munmap. Question: does munmap guarantee the CPU's WC buffers drain to the device? And what about abrupt process exit without a clean unmap?

This is a fun question because it sits at the intersection of three separate memory-ordering domains: the CPU's WC store buffers, the kernel's TLB/mapping teardown, and the PCIe fabric's posted-write ordering. Each has its own rules and none of them explicitly document munmap as a flushing operation.

Why it's interesting: WC memory is weakly ordered on x86 — stores can sit in the line-fill buffers indefinitely until something evicts them. The Intel SDM says WC buffers drain on serializing instructions (MFENCE, SFENCE, locked ops, CPUID) or on a strongly-ordered store to any other location. So the real question is: does the munmap path incidentally execute any of those before tearing the mapping down?

The likely answer is yes, but not because munmap promises it. Look at what munmap actually does in the kernel:

• Takes mmap_lock (a rwsem — has atomic ops)
• Calls unmap_region → zap_pte_range, which uses locked cmpxchg to clear PTEs
• Issues a TLB flush (INVLPG or IPI-driven flush — both serializing)

Any one of those atomic/serializing ops will drain WC buffers on the CPU that executes them. If the writing thread is the one calling munmap, you're fine. But WC buffers are per-CPU, so if the writes happened on CPU A and munmap runs on CPU B (unlikely in single-threaded code, common in multithreaded), CPU A's buffers won't flush from CPU B's serializing ops. The TLB shootdown IPI eventually forces CPU A into the kernel, which does drain them — but this is emergent behavior, not a documented guarantee.

Process termination: The exit path calls exit_mmap, which walks the same teardown path. Same emergent flushing occurs. Additionally, when the process is scheduled out for the last time, the context switch itself involves MOV CR3 (serializing) which drains WC.

The gotcha: "Eventually drains" is not the same as "drains before the device sees the transaction as complete." PCIe posted writes have their own ordering — even after WC flushes to the root complex, the device may not have observed them until a subsequent read (from the same BAR) forces the root complex to drain its write queues. If the driver needs completion semantics, an SFENCE plus a read-back of a device register is the only portable pattern.

Recommendation: Don't rely on munmap as a flush primitive. Add an explicit _mm_sfence() before munmap, and if you need to know the device saw the writes, do an MMIO read afterward.

Classical LRU caches have a known weakness: a single burst of one-shot reads (a scan, a crawler, a report) evicts your hot working set. Pure LFU has the opposite problem: it clings to items that were popular last week but are dead today. W-TinyLFU, the admission policy behind Caffeine (Java) and used by Ristretto (Go) and parts of Redis, solves both by splitting the cache into two regions and gating promotions with a frequency sketch.

The structure has three parts:

• Window cache (~1%): a small LRU that catches recency. Every new item lands here first.
• Main cache (~99%): a Segmented LRU (SLRU) with a probation and protected segment. This holds the frequency-favored items.
• TinyLFU sketch: a Count-Min sketch with a periodic aging step (halve all counters every N inserts) that estimates access frequency cheaply.

When an item is evicted from the window, it doesn't die immediately. It challenges the LRU victim of the main cache's probation segment. TinyLFU asks: "Which of these two has been accessed more often recently?" The winner stays; the loser is evicted. This is the admission filter — the main cache never accepts a newcomer unless it has proven itself more valuable than what it would displace.

Real example: A CDN edge serving mixed traffic — 95% requests hit a hot set of ~10K URLs, plus a background crawler sweeping millions of URLs once each. Under LRU, the crawler's scan evicts the hot set every few minutes, tanking hit rate to ~40%. Under W-TinyLFU, crawler URLs enter the window, get evicted quickly, and fail the frequency contest against the hot URLs in probation. Hit rate stays near 92%. Caffeine benchmarks routinely show W-TinyLFU beating LRU by 10–40 percentage points on scan-heavy workloads, with near-optimal (Belady) performance on Zipf distributions.

Rule of thumb: Size the window at 1% of the cache for standard workloads. If your workload is recency-heavy (news feeds, chat), Caffeine's adaptive variant will hill-climb the window ratio up to ~20% automatically. The frequency sketch needs roughly 8× cache-size counters at 4 bits each — so a 1M-entry cache costs ~4 MB of sketch overhead, which is negligible.

The trap to avoid: don't reach for W-TinyLFU when a plain LRU is fine. If your working set fits in cache, LRU is simpler and equivalent. W-TinyLFU pays off when your workload has a long tail plus scans — that's when the admission filter earns its keep.

XML didn't die — it just went into hiding. It's in every Maven POM, every Android manifest, every SVG, every .docx and .xlsx (they're zipped XML), every SOAP endpoint your bank still exposes, every RSS/Atom feed, every .NET config, every GPX track from your watch, every XLIFF translation dump. And what does everyone reach for? grep '<version>', which promptly breaks on attribute variants, namespaces, multi-line elements, or entity-escaped angle brackets.

xmlstarlet has been sitting in every distro's repos since 2002. It's a single C binary that speaks XPath 1.0, XSLT, C14N canonicalization, DTD/XSD/RelaxNG validation, and pretty-printing. Five subcommands cover it: sel, ed, fo, val, c14n, plus pyx to convert XML to a line-based format your existing awk pipelines can eat.

Extract every dependency from a Maven POM (note the namespace binding — this is where xmllint --xpath falls apart):

xmlstarlet sel -N m=http://maven.apache.org/POM/4.0.0 \
  -t -m "//m:dependency" \
  -v "concat(m:groupId,':',m:artifactId,':',m:version)" -n pom.xml

Edit in place — bump a project version, no sed regex terror:

xmlstarlet ed -L -N m=http://maven.apache.org/POM/4.0.0 \
  -u "/m:project/m:version" -v "2.0.0" pom.xml

List every permission an Android APK asks for:

xmlstarlet sel -t -v "//uses-permission/@android:name" -n AndroidManifest.xml

Pull titles from an RSS feed as a one-liner:

curl -s https://xkcd.com/rss.xml \
  | xmlstarlet sel -t -m "//item" -v "title" -o " | " -v "link" -n

Add or delete nodes — insert a new dependency, then delete all <scope>test</scope> ones:

xmlstarlet ed -L \
  -s "/project/dependencies" -t elem -n dependency -v "" \
  -s "/project/dependencies/dependency[last()]" -t elem -n groupId -v "org.junit" \
  pom.xml

xmlstarlet ed -L -d "//dependency[scope='test']" pom.xml

Format ugly single-line XML (indent 2, preserve CDATA):

xmlstarlet fo -s 2 minified.xml

Validate against a schema, exit non-zero on failure — perfect for CI:

xmlstarlet val -e -s schema.xsd data.xml

The escape hatch: pyx. When XPath isn't ergonomic, convert to Sean McGrath's PYX line format — one element per line, prefixed with (, ), -, A — and pipe to awk:

xmlstarlet pyx big.xml | awk '/^-/ {print}' | sort | uniq -c

Why not xmllint --xpath? It's stripped-down: no clean namespace binding (you fight it with *[local-name()='foo']), no editing at all, no template loops, no formatted output with newlines between matches. xmlstarlet's -t -m -v -o -n template DSL is genuinely the jq equivalent for XML — you build the output shape declaratively.

Why not regex? Because <price currency="USD">5.00</price> and <price currency='USD' >5.00</price> mean the same thing to XML but different things to your regex, and someone will eventually commit the second form. XPath doesn't care about whitespace, attribute order, quote style, entity encoding, or namespace prefix aliasing. Regex cares about all of them, silently.

Install: apt install xmlstarlet, brew install xmlstarlet, dnf install xmlstarlet. Binary is ~200 KB. Zero runtime dependencies beyond libxml2, which is already on your machine.

Trees are hydraulic magicians. A coast redwood lifts water 115 meters using nothing but sunlight and physics — no pumps, no moving parts, no electrical grid. So here's the question: could we build an engineered "capillary tree" that hoists water up a mountainside, powered only by evaporation at the top? Farmers in dry uplands would love this. Let's stress-test it.

How trees actually do it. The mechanism is the cohesion-tension theory. Water evaporating from leaf stomata pulls on the water column below via hydrogen bonding. Because water has a tensile strength of roughly -30 MPa in narrow tubes (yes, negative pressure — water under tension), the column doesn't cavitate as long as the xylem vessels are narrow (~20–100 μm) and defect-free. Each meter of lift costs ~10 kPa of hydrostatic head, so 100 m needs 1 MPa. Trees run at -2 to -3 MPa routinely.

The engineered version. Picture a 500-meter tower on a mountainside, ending at a plateau farm. Inside: millions of hydrophilic nanocapillaries — say, anodized aluminum oxide (AAO) membranes with 50 nm pores, or bundled hollow polyimide fibers. At the top, a "canopy" of nanoporous ceramic exposed to dry mountain air evaporates water. At the bottom, a reservoir feeds the wicks.

The lift calculation. Jurin's law gives capillary rise: h = 2γcosθ / (ρgr). For water (γ = 0.072 N/m), full wetting (cosθ ≈ 1), and a 50 nm radius pore:

h = (2 × 0.072) / (1000 × 9.81 × 50e-9)
  = 0.144 / 4.9e-4
  ≈ 294 meters

Drop to 25 nm pores and you hit ~590 m. Nanopores easily generate the pressure to lift water 500 m. That part is free.

The flow rate is where it gets ugly. Poiseuille's law: Q = πr⁴ΔP / (8ηL). For one 25 nm pore, 500 m tall, ΔP = 5 MPa:

Q = π(25e-9)⁴ × 5e6 / (8 × 1e-3 × 500)
  ≈ 3.1 × 10⁻²² m³/s per pore

That's attoliters per second. To irrigate a modest 1-hectare plateau farm needing 10,000 L/day (~0.12 L/s), we need ~4 × 10²⁰ pores operating in parallel. At 10¹² pores/m² (realistic for AAO), that's 400 million m² of membrane surface — a folded/rolled bundle roughly 400 m² in cross-section if we stack 1 mm-thick membrane layers. Doable, but expensive.

Evaporation drives the whole thing. At the canopy, we need enough dry air to pull water out. Evaporating 0.12 L/s requires ~290 kW of latent heat, drawn from ambient air and solar radiation. A 500 m² sunlit canopy at 500 W/m² gives 250 kW — right at the edge. Add a wind-exposed radiator fin and you're fine.

The killer: embolism. Trees lose xylem vessels constantly to cavitation and rebuild them overnight with root pressure. Our tower can't self-heal. A single micron-sized air bubble in a capillary breaks the water column permanently. We'd need redundant parallel channels (trees have millions), plus a nightly low-pressure refill cycle from a small solar pump — cheating, but only slightly.

Cost of the "free" lift: A conventional pump moving 10,000 L/day up 500 m needs ~570 Wh/day — about 12¢. The capillary tower saves that electricity but costs millions in nanomembrane. It's the reverse-Ponzi of hydraulics: physically elegant, economically bonkers.

Inside a modern jet engine's turbine section, temperatures routinely exceed 1,400°C (2,550°F). That's hotter than the melting point of the metal the blades are made from. And yet those blades — spinning at more than 10,000 RPM under stresses equivalent to hanging a small car off each one — don't just survive. They do it for tens of thousands of flight hours. This is the quiet miracle of the superalloy.

Superalloys are a class of metals — usually nickel, cobalt, or iron-nickel based — engineered specifically to laugh at conditions that would reduce ordinary steel to a puddle. Their superpower isn't just melting point (nickel's is only 1,455°C), but creep resistance: the ability to hold their shape under crushing loads at temperatures where atoms would normally start sliding past each other like sand.

The trick lies in a bit of atomic-scale architecture called the gamma prime (γ') phase. Picture a nickel matrix (the "gamma" phase) shot through with billions of tiny, coherently-aligned cuboidal precipitates of Ni₃(Al,Ti). These precipitates are ordered, meaning their atoms sit in fixed positions — and when dislocations (the microscopic defects that let metals deform) try to move through them, they get pinned. The alloy essentially becomes a self-reinforcing scaffold at the atomic level.

It gets weirder. Modern turbine blades aren't cast the way you might imagine metal parts being cast. They're grown as single crystals — one continuous grain of metal, with no grain boundaries at all. Why? Because grain boundaries are exactly where creep failure begins at high temperature. A blade cast conventionally has thousands of grains; a single-crystal blade has one. Manufacturers like Rolls-Royce and Pratt & Whitney use a technique with a spiral "selector" mold that ensures only a single crystal orientation propagates upward as the molten alloy solidifies.

Then there's the cooling. Turbine blades are hollow, laced with intricate serpentine channels through which relatively cool air (a mere 600°C or so) is bled from the compressor. This air seeps out through hundreds of tiny laser-drilled holes across the blade's surface, forming a thin film that shields the metal from the combustion gases. The blade is, in effect, running above its own melting point — and only survives because it's constantly being sweated on by its own transpiration cooling system.

You've encountered superalloys without knowing it. The Space Shuttle Main Engine turbopumps were superalloy. Your gas turbine power plant's blades are superalloy. Nuclear reactor internals, F1 exhaust manifolds, medical implants, and the exhaust nozzles of rocket engines all lean on them. And that Inconel that overclockers whisper about? Same family.

This is the seventieth installment of C-Monster's live essay series, marking the 10-year retrospective of Roland Emmerich's Independence Day: Resurgence (2016). Ten years on, the sequel to one of the most beloved blockbusters of the 1990s remains a fascinating case study in what happens when a legacy sequel misjudges its own franchise.

What makes this worth watching over a typical review is the live-observation format. C-Monster walks through the film in real time, letting the viewer see the craft decisions — the CGI-heavy spectacle replacing the practical model work of the original, the shift from character-driven ensemble writing to plot mechanics, the absence of Will Smith reshaping the entire tonal balance. Long-form live discussions like this tend to surface the kinds of structural observations that short YouTube essays skip past.

Fair warning: the candidate pool here was thin. The other options were hashtag spam, a mislabeled trailer repost, and a logo-history compilation. This is the strongest of the four, but a live stream from a very small channel is going to be loose and conversational rather than tightly edited — set expectations accordingly.

Most of today's candidates are Shorts, hashtag-spam clips, or emoji-heavy kid projects. This one stands out because it tackles a genuinely educational analog electronics topic: building a discrete-transistor audio power amplifier around the classic TIP3055 NPN power transistor.

The TIP3055 is a workhorse of hobbyist audio — a TO-218 15A/60V bipolar transistor that has been used in DIY amplifiers for decades. A push-pull or paralleled TIP3055 stage is a great way to learn the fundamentals of Class A/B biasing, quiescent current adjustment, thermal considerations, and the role of emitter resistors in current sharing between paired output devices. Unlike modern Class-D chip amps, a discrete transistor amp forces you to actually think about DC operating points, coupling capacitors, and how the input stage drives the output pair.

Running on a 12V supply keeps the project accessible and safe for benchtop experimentation, while still producing meaningful output into a speaker load. The included volume control (input attenuator) and single-ended supply topology make this a good jumping-off point for anyone wanting to graduate from breadboarded 555 circuits into small-signal and power analog design.

Caveat: the channel's description is thin, so the depth of theory explanation is uncertain — but even watched as a build-along, wiring up a discrete power amp beats most of today's other options.

Of today's crop, this is the only entry that actually promises to teach engineering rather than showcase renders or spec sheets. The B-2 Spirit is a genuinely fascinating case study in aerospace design — a tailless flying wing that pushed aerodynamic, structural, and stealth engineering into territory no production aircraft had occupied before.

The video description promises to explain why the B-2 has no tail, how the flying wing planform reduces radar cross-section, and the trade-offs that come with it. These are meaty topics: without a vertical stabilizer, yaw stability has to be handled by differential drag from split rudders (the "beavertail" surfaces near the wingtips), and the entire airframe must rely on fly-by-wire computers making constant corrections to remain flyable. The lack of a tail is what gives the B-2 its low observability from every angle — but it also means the aircraft is aerodynamically unstable by design.

For a channel with only 135 subscribers, a focused explainer on a single aircraft's design philosophy is exactly the kind of small-creator engineering content worth surfacing. It's not a compilation, not a spec-sheet flyby, and not clickbait — it's a targeted look at one of the most unusual airframes ever built.

Caveat: the rest of today's list was unusually weak (AI-generated concepts, hypercar spec walkarounds, shorts). This is comfortably the strongest candidate but the channel is unproven, so temper expectations on production depth.

Honestly, this batch of candidates is thin — most are YouTube Shorts, hashtag-spam titles, or a series of tiny "explainer" videos from a 4-subscriber channel pitching a pinball kit rather than teaching anything. Woodstep Workshop is the standout because it actually shows a full build from start to finish rather than marketing a product or flashing background footage over music.

The premise is simple but genuinely useful for anyone thinking about introducing woodworking to younger makers: can a beginner (specifically a kid) actually complete a real woodworking project unaided? The video walks through every stage — measuring, marking, cutting, drilling, and assembly — which are exactly the foundational skills that get glossed over in slicker channels. Watching a novice work through those steps highlights the friction points experienced makers forget about: how to hold a square correctly, how to keep a drill perpendicular, how to sequence cuts so you don't ruin a workpiece.

At just 20 subscribers, this is a tiny channel that likely deserves more attention. If you teach kids, run a scout troop, or want a low-stakes weekend project to do with a family member, this is a practical primer. It's not going to teach you dovetails, but it does something arguably more valuable: it demystifies the first project.

Most of today's crop is factory promo footage and hashtag-spam roll-forming clips, but this one actually teaches something. It's a Finite Element Analysis of a sheet metal bend performed in ANSYS Mechanical, using a 30° V-die — the geometry most press brake operators encounter but rarely get to see the internal stress behavior of.

What makes FEA valuable for metalworkers is that it visualizes what happens inside the material during forming: where plastic strain concentrates, how springback develops as the punch retracts, and where the neutral axis actually sits under a sharp die angle. If you've ever wondered why your bend allowance charts don't quite match reality, or why a tight inside radius cracks on higher-tensile steel, an FEA walkthrough shows the physics directly rather than describing it abstractly.

Ahmad Hiwa's channel is brand new (1 subscriber at time of posting), so expect a rough presentation, but the underlying simulation work is the kind of thing engineering students and shop-floor folks curious about the "why" behind their tooling choices should find useful. A single die-angle simulation is a small slice, but it's a real slice — not a music-video montage of machines running.