Daily Digest — 2026-07-07

In October 1961, a spindly white aircraft with a wing shaped like a paper dart lifted off from Bedford, England, at a groundsprint speed of roughly 69 mph. The Handley Page HP.115 had one job: prove that a slender delta wing — the geometry Dietrich Küchemann and Johanna Weber had proposed at the Royal Aircraft Establishment in 1955 — could be flown safely at the vanishingly low speeds required for takeoff and landing. It did, and the data it produced went straight into the Concorde.

The problem the HP.115 solved was subtle. A conventional swept wing stalls when airflow separates from the upper surface. A slender delta (leading-edge sweep around 75°) doesn't stall the same way — instead, at high angles of attack, two enormous leading-edge vortices roll up above the wing and stay attached, generating additional "vortex lift." Küchemann's math said this vortex flow would remain stable and controllable down to walking-pace airspeeds. Nobody had flown it.

Handley Page built the HP.115 on a shoestring — one aircraft, fixed landing gear, a single Bristol Siddeley Viper turbojet producing 1,900 lbf, a wing with 75° leading-edge sweep, and a cockpit borrowed from a Jet Provost. First flight: 17 August 1961, pilot J.M. Henderson. Over the next 13 years it flew hundreds of sorties at speeds between 69 and 248 mph. Test pilots — including future Concorde chief test pilot Brian Trubshaw — reported the aircraft was docile at extreme angles of attack. No pitch-up. No wing drop. The vortex lift theory was confirmed in flight.

Paired with the BAC 221 (a rebuilt Fairey Delta 2 that validated the same wing at Mach 2), the HP.115 gave Britain and France a complete low-speed/high-speed dataset. Concorde's ogival delta is a direct descendant. The HP.115 flew until 1974, then went to the Fleet Air Arm Museum at Yeovilton, where it sits today.

Here's the abandoned part: the follow-on research program never happened. The HP.115 proved slender deltas were viable across the flight envelope. It also produced anomalies nobody had time to chase — vortex breakdown behavior, ground-effect interactions during flare, aeroelastic coupling at extreme alpha. Handley Page went bankrupt in 1970. The Concorde-B was cancelled in 1976. Slender-delta research in the West effectively stopped. The Soviets did their own work with the Tu-144's ogival wing, then dropped it.

Why revisit this in 2026?

• Boom Overture, Hermeus Halcyon, and NASA's X-59 are all wrestling with the exact low-speed handling problem the HP.115 was built to characterize. They're using CFD that still requires flight validation.
• Vortex lift is now the theoretical basis for the F-22, F-35, and every fifth-generation fighter's high-alpha regime — but the civil-aircraft dataset stops at Concorde.
• Modern fly-by-wire, active vortex control (plasma actuators, blowing slots), and lightweight composites could take the slender delta places the 1961 airframe couldn't go — including quiet subsonic approaches at 65 mph that Concorde-B was designed for.
• A modernized HP.115 — call it a slender-delta demonstrator with a modern turbofan and FBW — could be built for under $50 million and would answer questions Boom and NASA are currently paying supercomputers to guess at.

The HP.115 did its job so well that everyone declared the question closed. It wasn't closed. It was just parked.

When a coding agent like Claude Code or Cursor works on a bug, it spends dozens of steps reading files, editing code, and running tests. From the outside, it looks like the agent is "thinking" about the program. But is it actually building an internal mental model of the code — or just pattern-matching its way from one edit to the next? This paper cracks open the black box and finds a surprisingly rich answer.

The authors trained a very simple statistical tool (a logistic regression probe) on the internal activations — the "residual streams" — of the language model powering a coding agent. Think of the residual stream as the neural network's working scratchpad: a big vector of numbers that flows through the model as it processes tokens. The probe's job was to look at this scratchpad and predict things about the code the agent was editing.

Here's what they found the model quietly keeps track of, without ever being told to:

• Whether the current code parses — the model "knows" if it's syntactically valid.
• Whether the test suite currently passes — before even running the tests.
• Whether the next edit will reduce the number of failing tests — a form of latent forecasting.

That last finding is the eye-opener. The model isn't just reacting to feedback like compiler errors; it's internally representing something like "if I do this, things will get better." The paper calls this a latent programming horizon — a hidden look-ahead about where the program is going.

Why does this matter beyond curiosity? Two practical reasons:

• Debugging agents themselves. If we can probe what an agent "believes" about the code, we can catch it heading down a bad path early — before it burns 20 more steps making things worse.
• Cheaper feedback loops. Running a test suite after every edit is slow. If the model already internally predicts test outcomes, we could sometimes trust that signal and skip actual execution — or use it to prioritize which edits are worth validating.

The bigger picture: coding agents are often described as "just" LLMs bolted to tools. This paper is evidence that when you put a model inside an agentic loop, it develops implicit representations of program state that mirror how a human programmer holds the code in their head. That has implications for how we evaluate, interpret, and eventually control these systems.

We've talked about radial runout — the wobble where the flange isn't concentric with the pipe. Axial runout is the other flavor: the sealing face isn't perpendicular to the pipe's axis. Instead of a flat plane, you've got a potato chip. Even a few thousandths of warp will crack the joint open at TDC of the compressor cycle and let boost or exhaust pulse past the retention ring.

Axial runout is measured with a dial indicator sweeping the sealing face while the flange rotates on a mandrel. Zero the tip against a reference point near the OD of the 20° sealing cone, spin one full revolution, and read total indicator reading (TIR). Anything under 0.003" TIR is race-quality; 0.003"–0.005" is acceptable for street turbo work; over 0.008" and you're chasing leaks forever regardless of clamp torque.

Where the warp comes from:

• Weld heat input — the tack sequence pulls one side of the flange toward the pipe as it cools. Uneven shrinkage tilts the sealing face.
• Post-weld cooling on a cold table — quenching one face while the other stays hot locks in a bow.
• Machining before welding instead of after — the flange enters flat, but welding distorts it, and you never re-face it.
• Thin flanges — 3/8" stainless V-band flanges warp far more than 1/2" mild steel. Mass resists distortion.

Real-world example: A builder welds a 3" T304 V-band flange to a turbo downpipe using a single pass, tacks at 12-3-6-9 o'clock, then air-cools on a steel table. Dial indicator on the sealing face reads 0.011" TIR — the 6 o'clock position (bottom, against the cold table) has pulled down. Clamp goes on, exhaust leak forms at 6 o'clock every time. Fix: chuck the assembly in a lathe with a soft mandrel through the ID and skim-cut the sealing face 0.015" deep, restoring 0.001" TIR.

Rule of thumb for allowable axial runout: TIR should be less than half the sealing ring's elastic compression range. A stainless V-band retention ring compresses roughly 0.010" under clamp load — so anything over 0.005" TIR eats your entire sealing margin and leaves nothing for thermal cycling.

The fix is almost always the same: weld first, machine second. Any flange that's been welded to a pipe should get a final skim cut on the sealing face before it ever sees a clamp.

This function is supposed to compute how long a user's session lasted, in seconds, so we can alert on unusually long ones. Tests pass. It ships. Weeks later, a security engineer notices that sessions lasting days are being reported as lasting minutes — and the "alert on sessions > 24 hours" rule has never fired, not once.

from datetime import datetime, timedelta

def session_duration(start: datetime, end: datetime) -> int:
    """Return the length of a session in seconds."""
    return (end - start).seconds

def check_session(user_id: str, login: datetime, now: datetime) -> None:
    duration = session_duration(login, now)
    print(f"user={user_id} duration={duration}s")
    if duration > 86_400:  # more than one day
        alert_long_session(user_id, duration)

# Looks fine in tests:
login = datetime(2026, 7, 1, 9, 0, 0)
now   = datetime(2026, 7, 1, 9, 30, 0)
check_session("u1", login, now)   # duration=1800s  ✅

# In production, days later:
login = datetime(2026, 7, 1, 9, 0, 0)
now   = datetime(2026, 7, 4, 10, 0, 0)  # ~73 hours later
check_session("u1", login, now)   # duration=3600s  😱  alert never fires

The Bug

A timedelta stores its value as three separate integer components: days, seconds, and microseconds. The names are misleading. timedelta.seconds is not the total number of seconds in the delta — it's the seconds component, normalized to the range [0, 86400). Anything larger than a day rolls into the days component.

So for a 73-hour session:

• (end - start).days is 3
• (end - start).seconds is 3600 (the remaining 1 hour)
• The "total seconds" the function returns is 3600, not 262800.

Tests pass because they use deltas under 24 hours, where the days component is zero and .seconds happens to equal the truth. The bug only surfaces in production, exactly at the threshold you care about: long sessions. Worse, the "alert if > 86400" check is now structurally impossible to trigger — .seconds can never reach 86400 by definition. The alarm is wired to a signal that will never fire.

This is a language-level footgun: datetime.timedelta chose to expose its normalized storage fields as public attributes with the same names as human units. The type system can't help you, either — both wrong and right return an int/float.

The Fix

Use .total_seconds(), which flattens all three components into a single float:

def session_duration(start: datetime, end: datetime) -> float:
    """Return the length of a session in seconds."""
    return (end - start).total_seconds()

Two hardening habits worth adopting: (1) whenever you touch timedelta, ask yourself whether you want the component or the total — the attribute names lie about which is which; (2) add at least one test that spans a day boundary. A single case with end - start > timedelta(days=1) catches every variant of this bug instantly.

The same shape of trap lurks in timedelta.microseconds (0 to 999999, not "total microseconds") and, in a distant cousin, in time.struct_time.tm_yday-style APIs where a "day of year" is not the same as "days since epoch". When a library exposes normalized components under human names, you have to know which is which by heart — the attribute won't warn you.

When a signal crosses from a 0.7V near-threshold core into a 1.0V I/O ring, you can't just wire it through — the receiving PMOS won't fully turn off, leaking microamps per gate. The classic fix is a level shifter in front of a flip-flop. But at high frequencies, that adds a full gate delay to every capture. So designers fuse the two: a level-shifting flip-flop that captures the low-voltage input AND translates it to the high-voltage rail in the same clock edge.

The workhorse is the cross-coupled PMOS level shifter merged with a master-slave latch. Two PMOS transistors on the high rail form a latch; two NMOS pull-down paths accept the low-voltage differential inputs. When the low-side NMOS wins the fight against the high-side PMOS, the cross-coupled pair flips and regenerates full VDDH swing. The clocked slave stage then captures it.

The critical constraint: the low-VDD NMOS must overpower a fully-on high-VDD PMOS during the transition. This is the contention ratio. Rule of thumb — the NMOS width must satisfy:

• W_N / W_P ≥ (V_DDH − V_TP)² / (V_DDL − V_TN)²

For V_DDL = 0.7V, V_DDH = 1.0V, V_T ≈ 0.3V: ratio ≈ (0.7)²/(0.4)² ≈ 3.1×. Your pull-down NMOS needs to be roughly 3× the PMOS width, or the shifter can't flip and you get a stuck output — or worse, a metastable half-rail node that burns crowbar current forever.

Dual-rail storage takes this further: the flip-flop maintains both true and complement on the VDDH rail internally, so the regeneration is differential and much faster than single-ended. Intel's Ivy Bridge used dual-rail level-shifting flops on the boundary between the 0.75V L2 cache and the 1.05V ring interconnect — cut boundary crossing latency by ~40ps per hop, which mattered because the ring had 8 hops.

Real-world gotcha: during power sequencing, if VDDH comes up before VDDL, the low-side inputs float — the PMOS cross-coupled pair has no defined state and both outputs can sit at V_DDH/2. This causes massive static current until VDDL stabilizes. The fix: an isolation clamp that forces the shifter output to a known state whenever VDDL is below its brownout threshold, gated by a power-good signal from the VDDL regulator.

A common-mode choke is two windings on a single magnetic core, wound so that differential currents (signal or power flowing out one wire and back the other) see almost zero impedance, while common-mode currents (garbage flowing the same direction on both wires, returning through ground or parasitic capacitance) see a huge impedance. It's the single most effective tool for suppressing conducted EMI on power cords, USB cables, CAN bus, Ethernet, and motor leads.

How the magic works: The two windings are phased so their fluxes cancel for differential currents. The core sees no net flux, doesn't saturate, and presents only leakage inductance (typically 0.5–2% of the common-mode value). But common-mode currents flow the same direction in both windings — their fluxes add, and the core presents the full inductance, often several millihenries.

Real-world example — offline AC input filter: A 100 W flyback supply generates switching noise that couples through the Y-caps to earth ground, then flows back on both L and N as common-mode current. A 10 mH common-mode choke (say a Würth 744824210) in series with the AC input presents ~6 kΩ at 100 kHz to that noise, but only ~60 Ω of leakage inductance to the 60 Hz mains current — invisible to normal operation. Combined with the Y-caps forming an LC filter to earth, you get 40+ dB of common-mode attenuation.

Design rules of thumb:

• Impedance target: aim for Z_CM ≥ 1 kΩ at your worst-offending noise frequency. Z = 2πfL, so 1 kΩ at 150 kHz needs about 1 mH.
• Current rating: the differential current heats the copper. Derate to 70% of the datasheet rating for continuous use.
• Saturation: because differential flux cancels, DC bias doesn't saturate the core — but any current imbalance (e.g. leakage to earth) does. Nanocrystalline and ferrite cores tolerate a few mA of imbalance; check the datasheet.
• Leakage inductance is a feature, not a bug — it works with X-caps to filter differential-mode noise too. Bifilar winding minimizes it; sectional winding maximizes it.

Placement matters: put the choke as close to the noise source (or connector) as possible. On DC power lines feeding switching converters, put it on the input side, before the bulk capacitor. On signal lines like CAN or USB 2.0, use a smaller "data line" choke (~90 Ω @ 100 MHz) right at the connector, with TVS diodes on the board side.

Backlash is the free play between meshing gear teeth — the angular distance you can rotate the output shaft before the input shaft moves. Every conventional gear train has it, and it's designed in deliberately. Zero clearance means teeth bind, overheat, and gall under thermal expansion or lubricant film thickness. So gears are cut with tooth thicknesses slightly under theoretical, leaving a gap between the non-driving flanks.

The problem: when a gear train reverses direction, the driving flank has to travel across that gap before it contacts the opposite flank. During that transit, the output doesn't move. In a positioning system, this shows up as lost motion — commanded moves that produce no result until the slack is taken up.

Where it bites you:

• CNC machines: A mill cutting a pocket reverses direction at every corner. Uncompensated backlash produces oversized inside corners and mismatched profiles. Controllers apply backlash compensation — the servo overshoots by the measured backlash amount on every reversal.
• Robot arms: Multi-stage reduction gearboxes stack backlash. A 3-stage train with 0.1° per stage gives 0.3° at the output. At the end of a 1-meter arm, that's 5 mm of end-effector uncertainty.
• Telescope drives: Tracking a star means slow, monotonic motion. Wind gusts push the mount back and forth across the backlash gap, causing image smear even though the drive commanded no reversal.

Rule of thumb for spur gears: Standard commercial-grade backlash runs about 0.04/DP inches, where DP is diametral pitch (teeth per inch of pitch diameter). A 20 DP gear has ~0.002" (50 μm) of backlash per mesh. Precision-ground gears cut this to ~0.0005", but you pay 5–10× the cost.

How designers eliminate it:

• Anti-backlash gears: Two thin gears on the same shaft, spring-loaded to push in opposite directions, so one flank always contacts each mating tooth.
• Preloaded dual pinions: Two pinions driving the same rack, torque-biased against each other.
• Harmonic drives and cycloidal reducers: Continuous tooth engagement instead of intermittent meshing — inherent near-zero backlash.
• Direct-drive torque motors: Skip the gearbox entirely.

Measuring it: Lock the input, apply a small torque to the output first one direction then the other with a dial indicator on the output gear tooth. The total sweep is the backlash — usually measured in arc-minutes for rotary systems or micrometers of tooth movement.

Backlash isn't a defect. It's a design parameter you either accept, compensate for in software, or engineer out with more expensive hardware.

The 1923 volume Aconitum is not a book in the ordinary sense. It is a photographic reference archive — a filing cabinet's worth of index cards, each pasted with a photograph and annotated in the crisp, clerical hand of the horticultural printing trade. Every card carries the same header:

"Proofs of engravings made from this photograph are pasted below."

The photographs catalogued dozens of varieties. One card reads:

"Variety Za pellices... Origin... Date 9-15-58... Remarks..."

The forgotten fact is not in the words. It is in the sheer existence of the archive.

Who was McFarland? J. Horace McFarland (1859–1948) ran Mount Pleasant Press in Harrisburg, Pennsylvania — the printer that produced most of America's finest seed catalogs, rose books, and nursery brochures for half a century. He was the founding president of the American Civic Association, one of the loudest lobbying voices behind the creation of the National Park Service in 1916, and the man who essentially invented full-color horticultural printing in the United States. He built a photograph library of some 40,000 plant images so that engravers and lithographers could pull accurate reference material for any catalog on demand. It was, in effect, Google Images for gardeners — assembled a century before the internet.

The forgotten claim, hidden in the filing: That a printer needed a filing cabinet of Aconitum varieties in 1923 tells us that Aconitum — better known as monkshood, wolfsbane, or the "queen of poisons" — was a mainstream ornamental. It was in cottage borders, church gardens, and mail-order catalogs. McFarland's archive documented named cultivars ('Sparks Variety', 'Bicolor', 'Bressingham Spire') the way we now document coneflowers.

Modern reality: Every part of Aconitum contains aconitine, one of the most potent plant neurotoxins known. As little as 2 milligrams — an amount easily absorbed through unbroken skin — can kill an adult. In 2010, a British gardener named Nathan Greenaway died after brushing against monkshood while working at an estate. In 2014, a British landscape gardener was murdered with Aconitum curry. Modern extension services now warn against growing it near vegetable beds, or at all around children.

• Victorian herbalists prescribed it for fevers and neuralgia at homeopathic dilutions.
• Nazi scientists reportedly tested it as a bullet poison.
• It is the plant Snape asks Harry Potter to identify on his first day of Potions.

McFarland's card catalog is a snapshot of a moment when Americans planted, photographed, and traded named varieties of a plant that could kill their toddlers by touch — and no one thought this was remarkable enough to note in the "Remarks" line.

In December 1938, a General Electric researcher named Katherine Burr Blodgett filed a patent for glass that seemed to disappear. She placed an ordinary glass slide behind a treated one and audiences couldn't see the treated pane at all — no glare, no reflection, just a hole in the air. The patent, US 2,220,860 ("Film Structure and Method of Preparation," issued November 5, 1940), described how to deposit stacks of organic molecules exactly one molecule thick onto a surface — and how to tune those stacks so that reflected light waves canceled themselves out through destructive interference.

Blodgett had already earned a place in history: in 1926 she became the first woman to receive a PhD in physics from Cambridge, working under Ernest Rutherford. At GE, she extended a technique her mentor Irving Langmuir had discovered — floating a fatty acid on water so it self-assembled into a single-molecule layer — into a method for dipping a plate through the film and picking up one layer at a time. Repeat forty-four times, and you had a coating 44 molecules thick (about a wavelength of green light) that eliminated the ~8% reflection every glass surface normally produces.

Why it was almost too modern:

• She was building precisely engineered thin-film stacks at the nanometer scale — nanotechnology — decades before that word existed.
• She invented a color gauge (the "Blodgett color scale") that measured film thickness to within one molecule by looking at its interference color. Semiconductor fabs use functionally identical ellipsometry today.
• Her "Langmuir-Blodgett films" are still the reference method in molecular electronics, biosensors, and organic photovoltaic labs.

The war and the aftermath: Her soft organic films weren't durable enough for consumer glass, but the principle — quarter-wavelength destructive interference — was immediately weaponized. During WWII, the U.S. Navy used her coating on submarine periscopes to keep their optics from betraying position with a glint of sun. Bausch & Lomb licensed the technique. By the 1950s, hard evaporated coatings (magnesium fluoride, then dielectric multilayers) replaced the organic films but kept her physics. Blodgett later added anti-icing coatings for aircraft wings and smoke-detection screens used to spot bomber contrails.

Where the patent lives now: Every camera lens you own is stacked with 4–12 layers of anti-reflective coating descended directly from Blodgett's math. So is your eyeglass prescription, the AR coating on your phone screen that quietly boosts outdoor readability, and the "black silicon" texturing on modern solar panels that squeezes out an extra 3% efficiency. The James Webb Space Telescope's gold-coated mirrors sit inside a cascade of interference filters that Blodgett would recognize on sight. Her Langmuir-Blodgett deposition technique still turns up in bleeding-edge 2D-material research — graphene layers, MoS₂ transistors, and organic LEDs are all engineered with descendants of the trough-and-dip method she perfected on a GE lab bench in Schenectady.

Blodgett received the American Chemical Society's Garvan Medal in 1951, retired in 1963, and died in 1979 with 8 U.S. patents and one quiet superpower: she made glass vanish.

This repo tackles one of the most consequential financial decisions most people ever make — rent vs. buy — and does it with a level of intellectual honesty that mainstream calculators consistently dodge. The pitch: a Hyper-Local Rent Vs. Buy Opportunity Cost Calculator that doesn't just compare mortgage payments to rent checks, but instead invests your would-be down payment into the stock market and projects a true 30-year net worth comparison.

Why does that matter? Because the standard framing ("your rent is throwing money away") ignores the single biggest hidden variable in the equation: the opportunity cost of capital tied up in home equity. A $60,000 down payment isn't free — parked in an index fund for three decades, it's potentially six figures of foregone growth. Most calculators quietly assume that money would have evaporated otherwise, which stacks the deck toward buying.

What makes this project interesting even at zero stars:

• Hyper-local — implying the model accounts for regional variables like property tax rates, HOA fees, insurance, and rent trajectories, rather than national averages that mislead in high-cost metros.
• 30-year horizon — long enough to capture the compounding effects that make or break the comparison.
• Net worth framing — not just monthly cash flow, but total wealth outcome, which is the metric that actually matters.

Who benefits? First-time homebuyers agonizing over the leap, renters in expensive coastal markets who suspect the math doesn't favor buying, financial advisors looking for a transparent tool to walk clients through, and personal finance enthusiasts who enjoy poking at the assumptions inside these models. It's also a useful reference for anyone building their own financial calculator — the opportunity-cost methodology here is worth studying.

IEEE 754 defines two flavors of NaN, and the hardware treats them radically differently. The distinction is encoded in a single bit — the most significant bit of the mantissa. If it's 1, you have a quiet NaN (qNaN). If it's 0 (with at least one other mantissa bit set, to distinguish from infinity), you have a signaling NaN (sNaN). That one bit changes everything about how the FPU behaves.

Quiet NaNs propagate silently. Any FP op with a qNaN input produces a qNaN output, no exception raised. This is the default NaN you get from 0.0/0.0 or sqrt(-1). The FPU just forwards it through the pipeline like a poisoned value.

Signaling NaNs raise the invalid-operation exception the moment they hit an arithmetic op. The hardware detects the sNaN pattern in the input decode/unpack stage, sets the IE flag in MXCSR (x86) or FPSR (ARM), and either delivers a trap (if unmasked) or converts the sNaN to a qNaN and continues (if masked, the default). That conversion — flipping the MSB of the mantissa — is done by a dedicated combinational path, not by microcode.

Why the hardware bothers: sNaNs are meant to catch uninitialized memory. You fill a buffer with sNaN bit patterns, and any code that reads before writing raises an exception. It's a debugging tool baked into the ISA. Fortran runtimes used this heavily; modern languages rarely do.

The performance cliff: even in masked mode, an sNaN triggers a slow path in the FPU. On Skylake, a normal FP add is 4 cycles; an sNaN input can extend to 15+ cycles because the microcode assist runs to convert sNaN→qNaN and set flags. Zen 4 is similar. If you accidentally load an sNaN pattern (say, from a corrupt memory-mapped file), every downstream FP op pays this tax.

Concrete example: the bit pattern 0x7FA00000 is an sNaN in single precision (exponent all 1s, MSB of mantissa is 0, other bits set). 0x7FC00000 is the canonical qNaN. If your uninitialized buffer happens to contain 0x7FA00000 and you do a vector add over it, you'll see a mysterious 3-4x slowdown compared to running the same code on 0x7FC00000 data — same NaN semantics, wildly different microarchitectural cost.

Rule of thumb: if your FP code suddenly runs 3-10x slower with no algorithmic change, check for sNaN or subnormal inputs before blaming the cache. Both trigger microcode assists that dominate execution time.

As Claude Code and similar agentic coding tools sweep through developer workflows, an entire new configuration surface has quietly materialized inside our repos and home directories: the .claude/ folder. Olaf Alders' post is one of the first sustained attempts to catalog what actually lives there — and why security teams should be paying attention right now, not after the first supply-chain incident.

The .claude/ directory typically contains:

• settings.json / settings.local.json — permission allowlists, environment variables, and hook definitions that execute arbitrary shell commands on tool events
• hooks — shell scripts that fire on PreToolUse, PostToolUse, Stop, and other lifecycle events, running with the user's full privileges
• subagents and skills — reusable prompt bundles that can be invoked automatically
• MCP server configs — endpoints the agent will happily talk to, sometimes with secrets baked in
• CLAUDE.md files — prompt-injection payload delivery vectors dressed up as documentation

The attack surface is genuinely novel. A malicious CLAUDE.md checked into a dependency can quietly instruct a coding agent to exfiltrate ~/.ssh/ the next time a developer runs Claude Code in that repo. A hook script pulled from a "helpful" starter template can persist arbitrary code execution. Permission allowlists that look benign (Bash(git *)) turn out to permit git config --global core.hooksPath — a classic escape.

What makes the post valuable to a technical audience:

• It treats agent configuration with the same rigor security engineers apply to .git/hooks, .vscode/tasks.json, or .envrc — file categories that have all been abused in the wild
• It maps the trust boundaries: user settings vs project settings vs upstream-checked-in settings, and which of those a git clone can influence
• It hints at the review discipline teams need before the industry inevitably gets its "npm install" moment for coding agents

This is the kind of unglamorous plumbing writeup that ages very well. Six months from now, when the first well-publicized .claude/-based compromise hits the news, everyone will link back to posts like this and wonder why nobody was reading them at the time.

Of all the postings in this thread, Sequoia Capital's is the most revealing — not because a startup is hiring engineers, but because a legacy venture capital firm is. Sequoia is posting for a Platform Engineer, an Application Engineer, and a Security Analyst simultaneously. That's not a support function; that's a product team.

The stack tells the story: Ruby on Rails, Python, Vue, React, Postgres, Spark/Scala, Nginx, AWS and Heroku. This is not "we bought Salesforce and need someone to run reports." Rails + Vue/React signals a real internal web application. Spark/Scala is the tell — Sequoia is doing serious data engineering, almost certainly to mine signals about founders, portfolio companies, and market movements at scale. Heroku alongside AWS suggests some apps started as scrappy MVPs and matured; they haven't sunset the fast-iteration platform even as they scaled onto AWS.

What it reveals about direction: The tagline "shape the future of investing" combined with a Security Analyst hire says Sequoia is treating its proprietary deal-flow and portfolio-intelligence software as a competitive moat. Every top-tier VC now has this realization — Andreessen has done it publicly for years. Sequoia hiring a full-stack platform team confirms that discovering founders and evaluating startups has become a data problem, not just a network problem.

Skills and trends highlighted:

• Polyglot Rails/Python shops still dominate hybrid product+data orgs — Rails for CRUD, Python for analytics
• Spark/Scala persists in 2020-era stacks despite the shift toward Snowflake/dbt — hints at legacy pipelines
• Security hires alongside platform hires signals awareness that portfolio data (unreleased financials, LP info) is a huge liability

Green flags: "I'll respond fast" from a named hiring manager ([email protected]) — real ownership, no ATS black hole. Remote is on the table for a firm famous for Menlo Park insularity. Three distinct roles posted together suggests budget and a real roadmap, not a vanity req.

Red flags: "Menlo Park preferred" with vague remote openness usually means remote hires get second-class treatment. Two disparate frontend frameworks (Vue and React) hints at either team fragmentation or historical tech debt with no chosen direction. And the linked cloudapp screenshot instead of a proper careers page suggests engineering-org branding is still a side project.

The Linux kernel is riddled with optional features: tracepoints, KASAN checks, cgroup accounting, scheduler stats. Each is guarded by a runtime flag. A naive if (feature_enabled) costs a load, a compare, and a branch on every call — cheap alone, but tracepoints alone appear millions of times per second across the kernel. The kernel's answer: static keys, built on jump labels, which patch the kernel's own text at runtime so a disabled feature compiles down to literally nothing.

The trick is runtime code patching. A static key defines a branch site. The compiler emits either a 5-byte NOP or a 5-byte JMP to the slow path. When you toggle the key, the kernel walks a table of every branch site tied to it and rewrites the instructions in place, using text_poke() — which handles the cache-coherence dance (stop_machine or INT3 breakpoint trick to catch any CPU mid-execution) so no core sees a half-written instruction.

• Fast path (disabled): a 5-byte NOP. Zero branch predictor pressure, zero memory load, no I-cache pollution beyond the NOP itself.
• Slow path (enabled): an unconditional JMP to out-of-line code that does the actual work. The branch predictor learns it as always-taken.

Real-world example: every kernel tracepoint uses this. trace_sched_switch() is called on every context switch — millions per second on a busy server. With tracing off, the site is a NOP: the CPU literally does not know a hook exists. Turn on perf trace, and the kernel patches every tracepoint site live, without a reboot, without a recompile, without stopping your workload. Ftrace, KASAN, memcg accounting, and even Meltdown's KPTI toggle all use the same machinery.

The API: DEFINE_STATIC_KEY_FALSE(my_key) declares one defaulting off; static_branch_unlikely(&my_key) is the branch site; static_branch_enable(&my_key) patches every site enabled at once.

Rule of thumb: use a static key when the check runs more than ~1000 times per second and flips less than once per second. The patching itself is expensive — it can require an IPI to every core and an I-cache flush — but amortized over billions of executions, the cost is invisible. Below that ratio, a plain READ_ONCE(flag) is simpler and fast enough.

You can inspect them: /sys/kernel/debug/tracing/events/*/enable flips real static keys under the hood.

IPv6 replaced ARP with the Neighbor Discovery Protocol (NDP, RFC 4861), a family of ICMPv6 messages that handle address resolution, router discovery, redirects, and Duplicate Address Detection. NDP is elegant — but in its base form it's spectacularly insecure. Any host on the link can send a Router Advertisement claiming to be the default gateway, poison neighbor caches with forged Neighbor Advertisements, or answer DAD probes to prevent legitimate hosts from acquiring addresses. It's ARP spoofing, upgraded to sixteen bytes of address space. RFC 3971 — SEcure Neighbor Discovery, or SEND — was the IETF's attempt to fix this without falling back on IPsec (which itself needs bootstrapping, a chicken-and-egg problem on a link where you don't yet know your router).

The core trick: Cryptographically Generated Addresses. SEND leans on CGAs (RFC 3972). Instead of picking a random or EUI-64 interface identifier, a host generates an RSA keypair and derives the low 64 bits of its IPv6 address from a hash of its public key plus a modifier. The address is a commitment to the key. Anyone receiving an NDP message signed by that key can verify the signer actually owns the source address — no PKI, no shared secret, no prior trust. This is a genuinely clever piece of design: it turns the address itself into a self-authenticating identifier, exploiting the 64 bits of entropy IPv6 gives you for free.

What SEND adds to NDP messages:

• CGA option — carries the public key and parameters so receivers can recompute the address hash.
• RSA Signature option — signs the message with the CGA's private key.
• Timestamp and Nonce options — block replay attacks (timestamps for unsolicited messages like RAs, nonces for solicited exchanges like NS/NA).
• Trust anchor and certificate options — for routers, which can't self-authenticate via CGA alone (you need to know a router is authorized, not just that it owns its address). Routers present X.509 certs chaining to a trust anchor the host is configured with.

Why you've probably never touched it. SEND is a fascinating protocol that essentially nobody deploys. Reasons: the RSA math was expensive for 2005-era hardware and remains a nuisance on constrained devices; router authentication requires provisioning trust anchors on every host, which defeats IPv6's autoconfiguration story; Windows never shipped a supported implementation; and Linux support (via the ipv6-send-cga patches and later ndprotector) has always been a research artifact. The operational world instead settled on link-layer mitigations: RA Guard (RFC 6105), DHCPv6-Shield, and switch-side ND inspection — treating NDP the way we treat ARP, with switch policies rather than crypto.

Why it still matters. First, CGAs themselves outlived SEND. They show up in Mobile IPv6, in Host Identity Protocol experiments, and in academic work on self-certifying identifiers — an ancestor of ideas you'll see in content-addressed networking and DIDs. Second, SEND is a case study in a recurring failure mode: cryptographically correct protocols that lose to operationally simpler ones. DNSSEC vs. DoH, S/MIME vs. TLS-to-the-MTA, SEND vs. RA Guard — the pattern is the same. Third, if you ever run a hostile IPv6 network (conferences, coffee shops, dorms), the fact that NDP is still unauthenticated by default is worth knowing: ndp-based attacks are trivial and modern OSes will happily accept a rogue RA.

The asker has compiled a Linux kernel with CONFIG_KGDB enabled, flashed it onto a VMware VM, and wired up a virtual serial port as a socket pipe at /tmp/kgdb-socket. When they attach GDB from the host and issue target remote, they get "Ignoring packet error, continuing..." plus a warning about an unrecognized "timeout" item. Classic KGDB-over-serial pain.

This question is interesting because the failure mode is generic — "packet error" — but the root cause is almost always one of several very specific mismatches between three moving parts: the kernel's KGDB serial driver, the VMware virtual serial device, and GDB's remote protocol expectations. Each layer has its own baud, framing, and buffering assumptions.

Likely culprits, in order of probability:

• Socket type mismatch. VMware serial "socket pipe" can be a named pipe or a TCP socket. GDB's target remote /tmp/kgdb-socket only works if something is bridging that Unix socket to GDB's stdio. Most working setups use target remote | socat - UNIX-CONNECT:/tmp/kgdb-socket or configure the VM to use network serial (TCP) and then target remote host:port.
• Baud rate mismatch. The kernel command line needs kgdboc=ttyS0,115200 (or whatever matches VMware's assigned port). If the kernel is speaking 9600 and GDB assumes 115200, every packet looks corrupted.
• Wrong tty. VMware often assigns the added serial port as ttyS1, not ttyS0. Check dmesg | grep tty inside the guest.
• KGDB not actually waiting. The guest must be paused in KGDB before GDB connects — either via echo g > /proc/sysrq-trigger, adding kgdbwait to the boot cmdline, or triggering an Alt-SysRq-g.
• The "timeout" warning suggests a stale .gdbinit setting set remotetimeout ... against a GDB that doesn't recognize the key — usually a very old or very new GDB. Try set remote timeout (with a space) or remove the line.

Suggested approach: Start with the simplest topology — TCP serial in VMware pointing at telnet://localhost:8888, boot with console=ttyS0,115200 kgdboc=ttyS0,115200 kgdbwait, and connect via target remote localhost:8888. If that handshakes, layer in Unix sockets afterward. Also verify the kernel was built with CONFIG_KGDB_SERIAL_CONSOLE=y, not just CONFIG_KGDB=y.

Gotcha: VMware Workstation and ESXi handle serial pipes differently; the "yield CPU on poll" checkbox matters, and without it GDB packets get dropped under load. Also, if secure boot is on, kgdboc silently refuses to attach.

You've got a firehose of events — search queries, page views, error codes, ad clicks — and someone wants "the top 100 most frequent items." The naive answer is a hash map: count everything, sort, return the top 100. This works until your key space explodes. A billion distinct search queries a day means a billion counters, and sorting them to find 100 is absurd.

The Top-K problem is the interview question everyone gets wrong on the first try. The exact solution is O(N) memory in the number of distinct keys, which is unbounded. The practical solution is to accept approximation.

The heavy hitters insight: in real traffic, distribution is Zipfian. A tiny handful of items dominate, and everything else is noise. You don't need to count the noise accurately — you just need to not lose the giants in it.

The Space-Saving algorithm (Metwally, 2005) exploits this beautifully. Keep exactly K + a few hundred counters. When a new item arrives:

• If it's already tracked, increment its counter.
• If not, find the counter with the minimum count, evict that key, and reassign the slot to the new item with count = min + 1.

That "+1" is the trick: the new item inherits the evicted counter's value as an upper bound on its true count. You never underestimate a heavy hitter, and you can prove the error bound is at most N/m, where m is the number of counters.

Real example: Twitter's trending topics don't use exact counts. With ~500 million tweets per day and millions of hashtags, exact counting is possible but wasteful. Space-Saving with a few thousand counters gets the top 50 trends with error under 0.02% — indistinguishable from truth for a UI showing round numbers.

Rule of thumb: to find the top K items with relative error ε, allocate K/ε counters. Want top 100 with 1% error? Use 10,000 counters. That's ~80KB of memory to track heavy hitters in a stream of any size. Compare to a hash map of a billion keys at ~40 bytes each: 40GB versus 80KB, a 500,000× reduction.

When exact matters: billing, fraud detection, compliance. If you're charging customers based on the count, approximate is malpractice. For dashboards, trending UIs, cache admission policies, and anomaly detection — approximate is not just acceptable, it's the only thing that scales.

Pair Space-Saving with Count-Min Sketch when you need frequency estimates for arbitrary items, not just the top K. Different tools, same philosophy: give up perfection, gain scale.

Every so often a tool comes along that feels like it shouldn't be legal. criu — Checkpoint/Restore In Userspace — freezes a running process (or an entire process tree), dumps its memory, open files, sockets, timers, and pending signals into a directory of image files, and then resumes it later. Same box. Different box. Hours later. It doesn't care.

Podman, LXC, and OpenVZ all use it under the hood for live container migration. Almost nobody knows they can drive it themselves for a bare process.

First, sanity-check that your kernel exposes the knobs criu needs:

criu check --all

Now the party trick. Start a long-running Python job in one terminal:

$ python3 -c 'import time,itertools
for i in itertools.count(): print(i); time.sleep(1)'
0
1
2

In another terminal, freeze it to disk:

mkdir /tmp/ckpt
sudo criu dump -t $(pgrep -f 'itertools.count') \
     -D /tmp/ckpt --shell-job --leave-running

--shell-job tells criu the process is attached to a controlling terminal it should reconnect. --leave-running keeps the original alive after the snapshot — omit it and criu kills the source, which is what you want for migration.

Kill the original, wait a while, then bring it back exactly where it left off:

sudo criu restore -D /tmp/ckpt --shell-job
7
8
9

The counter picks up mid-stream. Same PID (if available), same memory, same open file descriptors.

Where this earns its keep:

• Long compute jobs and node maintenance. Simulation running for three weeks and the host needs a reboot? Checkpoint, reboot, restore. No cooperation from the program required.
• Slow-startup daemons. Something that takes 90 seconds to warm its caches — checkpoint the warm state and restore instantly in CI.
• Live migration between hosts. rsync the checkpoint directory to another machine and criu restore there. Works for TCP connections too with --tcp-established.
• Debugging Heisenbugs. Snapshot the process the moment before it misbehaves and restore repeatedly under gdb.

The TCP trick deserves its own callout. Add --tcp-established on both dump and restore, and criu will freeze the socket state, negotiate with the kernel's tcp_repair mode, and hand a live connection back to the restored process — the peer never notices. Combine with iptables to briefly drop packets during the swap and you get true live migration of a server holding open sockets.

Incremental checkpoints work via --track-mem and --prev-images-dir: the first dump is full, subsequent ones capture only pages that changed. This is how container platforms do warm-swap upgrades.

Some things criu can't handle without help: external state it doesn't own (a mounted NFS handle a peer has forgotten), some exotic file descriptor types (perf, some netlink), and process trees that opened namespaces in unusual configurations. It'll tell you exactly which fd it choked on and you can whitelist it with --ext-unix-sk, --ext-mount-map, and friends.

The mainstream alternative to criu is… there isn't one. You either write your program to serialize its own state (weeks of work, and you'll get it wrong), or you don't do checkpoint/restore at all. criu does it for arbitrary binaries you didn't write.

Every subway train is a giant kinetic-energy roulette wheel: it dumps ~1 kWh per ton into brake heat at every station, then burns another kWh accelerating back to cruise. What if we let topography do that work — dropping the tunnel below station level so trains roll downhill, then coast uphill back to the platform?

This isn't new. Paris Metro Line 1 and parts of the London Underground already use it, and Robert Goddard sketched it in 1909 as the vactrain precursor. But nobody has built a full "swoop" system optimized for it. Let's do the numbers.

The dip depth. A train coasting from rest under gravity reaches velocity v = √(2gh). For a subway cruising at 30 m/s (108 km/h — express-level fast):

h = v² / (2g) = (30)² / (2 × 9.81) ≈ 46 m

So a 46-meter dip converts a full stop into a full-speed launch, purely gravitationally. Halfway between stations, the train is 46 m below platform level, at max velocity, and the remaining rise decelerates it back to zero — no traction motors, no regen braking, no wasted heat. Physics is symmetric: energy in = energy out.

Energy math per ton. Lifting 1000 kg by 46 m stores mgh = 1000 × 9.81 × 46 ≈ 451 kJ, which is exactly the kinetic energy of that ton at 30 m/s (½mv² = 450 kJ). Check. For a 200-ton train, that's 90 MJ per station-to-station cycle — the equivalent of 25 kWh, saved every 2 km. A busy line running 30 trains/hour saves ~750 kWh/hour, or 6.5 GWh/year per line. NYC's subway would offset roughly 400 GWh annually — about a third of its traction load.

The friction reality check. Steel-on-steel rolling resistance is famously low (~0.001–0.002), and aero drag at 30 m/s in a full-profile tunnel is roughly ½ρCdAv² ≈ 4 kN for a subway car. Over 2 km, drag losses eat maybe 15–20% of the gravitational budget. Solution: dig the dip ~55 m instead of 46 m to bank the losses. Still very tractable.

Where it breaks.

• Tunneling cost. Modern TBMs charge roughly $500M/km at 20 m depth; going to 55 m at station midpoints roughly doubles vertical shaft/emergency egress work. A 30-station line adds maybe $2B in capital cost.
• Aquifers. Manhattan's water table sits ~5 m down. Dropping to 55 m puts every dip below groundwater, demanding continuous pumping — the same problem that plagues the East Side Access project.
• Passenger comfort. To hit 30 m/s from rest in the first ~230 m of descent, average acceleration is 0.13 g — perfectly tolerable, gentler than most elevators.
• Schedule flexibility. The whole thing assumes trains stop exactly at stations. Overshoots and undershoots require regen-capable motors as backup, so you don't eliminate propulsion — you just make it small.

Break-even. At $0.15/kWh, 6.5 GWh/year is ~$1M/year in energy savings per line. Payback on the extra $2B tunneling: 2,000 years. Oof. Unless you value carbon at $500/ton and count decarbonization, gravity subways are an aesthetic win, not an economic one — which is exactly why Paris built two dips in 1900 and then stopped.

Pick up any device with a clock — a wristwatch, a microcontroller, a radio, the computer you're reading this on — and somewhere inside is a tiny sliver of quartz being squeezed millions of times per second. That squeezing is doing the work of keeping time, tuning a station, or clocking a CPU. The piezoelectric resonator is arguably the most ubiquitous precision component in electronics, and almost nobody notices it exists.

The trick is a strange property of certain crystals discovered by the Curie brothers in 1880: squeeze them and they generate voltage; apply voltage and they physically deform. Cut a quartz crystal into the right shape, and it will vibrate at an astonishingly stable mechanical frequency — the same way a tuning fork rings at a specific pitch, but at radio frequencies and with mind-boggling precision. Feed that vibration back into an amplifier and you get an oscillator that drifts by only a few parts per million per year.

What makes piezoelectric resonators so dominant is that nothing else comes close for the price. Consider the alternatives:

• LC circuits (inductors and capacitors) drift wildly with temperature and component tolerance
• RC oscillators are cheap but imprecise — fine for blinking an LED, useless for a clock
• Atomic clocks are stable but cost thousands of dollars and consume real power
• MEMS resonators are catching up but still rely on the same fundamental resonance principle

A quartz crystal costs pennies and hits stability nearly good enough for GPS. This is why the article notes that piezoelectric resonators include not just quartz crystals but also ceramic resonators, SAW (surface acoustic wave) devices, and BAW (bulk acoustic wave) filters — the last two being how your phone separates the hundreds of overlapping cellular and Wi-Fi bands crammed into the same spectrum.

Here's the connection most people miss: the "32.768 kHz" number stamped on watch crystals is not arbitrary. It's 2^15 Hz — divide by two fifteen times with simple flip-flop circuits and you get exactly one pulse per second. Someone in the 1960s chose that frequency specifically because binary counters were cheap and division by powers of two was free. Every quartz watch on Earth still uses it.

Even weirder: the same phenomenon that makes your watch tick is what makes cigarette lighters spark, what generates ultrasound for medical imaging, and what makes the ground-penetrating "boom" of a sonar ping. It's also how the accelerometer in your phone knows which way is up, and how ink is precisely ejected from an inkjet printer nozzle. One physical effect — mechanical stress producing voltage and vice versa — quietly runs a startling fraction of modern civilization.

Note: today's candidate pool was thin — the other options were a chameleon YouTube Short and a hashtag-spammed movie trailer. This is a trailer too, but it points to a substantive independent documentary series worth flagging.

ALS & You is an independent documentary film series exploring amyotrophic lateral sclerosis — the progressive neurodegenerative disease that destroys motor neurons and, in most cases, kills within a few years of diagnosis. The trailer previews a series that touches on the disease's genetic overlap with frontotemporal dementia (FTD), current research directions, and the human experience of living with a terminal motor neuron condition.

What makes small-channel medical documentaries like this valuable is the access and honesty they often bring. Big-budget productions tend to sanitize illness; independent filmmakers who are personally connected to a diagnosis usually let the harder parts speak for themselves. If the series delivers on the trailer, expect real patient and caregiver interviews rather than glossy narration.

Worth two minutes to see whether the full series belongs on your watchlist — particularly if you're interested in neuroscience, genetics of neurodegeneration, or the current state of ALS research.

This is Episode 1 of a promising new series where the creator sets out to design, build, and debug a wireless weather station from scratch — the kind of long-form project documentation that's genuinely rare on YouTube. Most electronics videos show a polished finished product; this one commits to showing the messy middle: design decisions, dead ends, and iteration.

A wireless weather station is a fantastic vehicle for teaching real embedded systems concepts. To build one properly you have to grapple with sensor selection and calibration (temperature, humidity, pressure, wind), low-power radio protocols (LoRa, ESP-NOW, or sub-GHz ISM bands), power budgeting for a battery- or solar-powered outdoor node, weatherproofing and PCB layout, and data logging or MQTT integration on the receiver end. Episode 1 sets the design goals and scope — the foundation the rest of the series will build on.

Watching a series like this from Episode 1 is worth it because you see the reasoning behind each choice, not just the finished result. If the creator sticks with it, this could become a genuinely useful reference for anyone attempting a similar build. Zero subscribers means you'd be watching one of the very first viewers — worth supporting if the quality holds up.

New Orleans sits in one of the most geotechnically hostile settings in North America: soft, water-saturated deltaic soils, a subsiding land surface, and hurricane storm surge pushing in from the Gulf. Ayan, a geotechnical engineer working on the city's flood defense system, walks through how engineers actually read the ground — interpreting boring logs, cone penetration data, and stratigraphy — to design levees that won't slide, settle catastrophically, or fail by internal erosion during a surge event.

What makes this worth watching over a generic "how levees work" explainer is the site-specific reasoning. The soils under New Orleans include layers of soft organic clay and peat that behave nothing like the compacted fill you'd design against in most textbook problems. Levee design here has to account for consolidation over decades, seepage through underlying permeable strata, and the fact that the ground itself is sinking. Post-Katrina forensic work reshaped how the profession thinks about levee foundations, and hearing a practicing engineer describe the workflow — from subsurface investigation through to design decisions — is a rare glimpse into applied geotechnics rather than academic theory.

It's a short, practitioner-perspective piece from a small channel, but the content is genuine engineering, not marketing gloss.

Note: Honestly, this batch of candidates is weak — three of the four are essentially hashtag-spam promotional clips from small fabrication service businesses with no real instructional content. I'm picking this one as the least bad option because it at least comes from a working stone shop and could plausibly show some actual craft.

Hurtado's Tile & Stone is a small fabrication shop, and the title suggests a look at how they process stone slabs in-house. If the video delivers on that premise, viewers might see some combination of slab layout, template transfer, wet cutting with a bridge saw or CNC, edge profiling, and polishing — the core sequence that turns a raw quartz or granite slab into a finished countertop or vanity top.

Stone fabrication is genuinely interesting because it sits at the intersection of heavy industrial tooling and hand craftsmanship. A diamond blade can rough out a shape in minutes, but the final eased, bullnose, or ogee edge often still gets hand-polished through progressively finer diamond pads. Seam placement, vein matching, and understanding how a stone behaves under stress (bookmatching a fragile marble vs. a stable quartz) are skills that take years to develop.

Temper your expectations — with no description text and a hashtag-heavy title, this may just be a short clip of a machine running. But it's the only candidate here that points at a real trade being practiced.

Vertical welding is one of the trickiest positions for new welders to master. Unlike flat welding, gravity works against you — the molten puddle wants to sag, drip, or run out of the joint entirely. Getting a clean, strong vertical bead requires a specific combination of travel angle, arc length, and weave pattern that beginners rarely get right on the first few tries.

This tutorial from NEOWELD promises a step-by-step approach aimed squarely at practice-oriented learners. The "easy to practice" framing is encouraging: rather than showing off finished work, a good beginner video breaks the motion down into repeatable drills you can run on scrap steel until muscle memory takes over.

Key things worth watching for: how the instructor sets the amperage relative to rod diameter (vertical-up typically needs 10-15% less current than flat), the whipping or triangle weave pattern used to let the puddle cool between deposits, and how they orient the electrode angle to push the puddle upward rather than letting it fall.

Caveat: this is a brand-new channel with zero subscribers, so production quality and depth are unknown. But small, unpolished tutorials from working welders often contain more practical wisdom than glossy productions — worth a look, especially since vertical is a skill most hobbyists dodge for far too long.