Daily Digest — 2026-07-09

In July 1930, journalists, MPs, and industrialists boarded a strange aluminum carriage suspended from an overhead gantry above the LNER railway line at Milngavie, just outside Glasgow. Two four-bladed propellers — one at each end — spun up. The carriage accelerated smoothly along a 130-metre test track built parallel to existing rails. This was the Bennie Railplane, and its inventor, George Bennie, was quietly convinced he had made the steam locomotive obsolete.

Bennie, a Glasgow engineer, patented the concept in 1921. The idea was elegant: separate high-speed passenger traffic from slow freight by hanging a streamlined, propeller-driven car from an overhead rail while a second lower rail provided lateral stability. Freight kept the ground-level tracks. Passengers flew above at speeds no steam locomotive could touch. The published design target was 120 mph — twice the express speeds of the era — and independent engineers who examined the aerodynamics agreed the number was plausible.

The Milngavie prototype cost Bennie roughly £150,000 of his own money (about £12 million today). It worked. The carriage seated a dozen passengers, had wicker chairs, curtains, a lavatory, and enough acceleration to be genuinely uncomfortable. Reviews were rapturous. The Times, Flight magazine, and Pathé newsreels all covered it. Bennie negotiated seriously with the governments of Iraq (for a Baghdad–Basra route), Palestine, and later Southern Rhodesia.

Then the Depression hit. Every proposed contract evaporated. LNER, which had tolerated the test rig on its property, wanted its land back. Bennie personally bankrupted himself keeping the prototype standing. He died in 1957 having never built a revenue line. The Milngavie gantry was scrapped in 1956 for £375.

Why revisit it in 2026? Three things have changed:

• Electric ducted fans have replaced open propellers. Bennie's original hazard — spinning wooden blades near passengers — is gone. Modern EDFs used in eVTOL aircraft (Joby, Lilium) run at 90%+ efficiency and are quiet enough for urban corridors. Bolt two to a suspended pod and you have his design without the safety objection.
• Overhead structures dodge the land-acquisition death spiral. High-speed rail routinely dies because you cannot buy a straight line through populated country. A suspended railplane runs above existing rail corridors, motorways, or canals — right-of-way already owned, no new expropriation. This is exactly what Chiba's suspended monorail (still running since 1988) proves at low speed.
• Aluminum-lithium and CFRP make Bennie's aluminum carriage 60% lighter. The original weighed 8 tonnes. A modern equivalent would be under 3, cutting energy per passenger-km below any conventional rail.

The economics were never the problem. A 1932 study by consulting engineers Sir Alexander Gibb estimated the Baghdad–Basra route at £3,000 per mile of gantry versus £15,000 per mile for conventional double-track railway — and the railplane needed no tunnels, no level crossings, no signaling infrastructure. What killed it was timing: 1930 was the worst possible year in the 20th century to ask governments for infrastructure capital.

The Shanghai Maglev cost roughly $50 million per kilometre. A modern Bennie-style EDF railplane on existing corridors would be a fraction of that, at speeds competitive with regional aviation. Bennie was not wrong. He was early, and then he was broke.

When people ask whether AI coding assistants write fast code — not just correct code — the honest answer has been "we don't really know." A handful of benchmarks (EffiBench, Enamel, EvalPerf, Mercury) try to answer this by timing LLM-generated solutions against reference implementations. The trouble is, these benchmarks have consistently shown that AI-written code runs about as fast as the human-written baseline. That's either good news (the AI is competitive!) or a warning that the benchmarks aren't sensitive enough to tell the difference. This paper argues it's mostly the latter.

The authors took 1,538 tasks across those four popular benchmarks and did something surprisingly rare: they ran each task 30 times and measured the variance, not just the average. Then they scrutinized the whole measurement pipeline — how tasks are timed, what inputs get used, whether the "canonical" reference solutions are actually efficient, and whether the reported speedups are statistically real or just noise.

What they found is a bit of a mess:

• Timing noise swamps the signal. A lot of reported differences between LLM code and reference code fall within normal run-to-run variation. If you flip a coin 30 times you'll get streaks; benchmarks running once mistake those streaks for capability.
• The "gold standard" solutions aren't always golden. Some reference implementations are themselves inefficient, which makes the LLM look artificially competitive — you can't measure a speedup against a slow baseline and call it impressive.
• Test inputs are often too small. Many tasks finish in microseconds, where OS scheduling jitter dominates. You can't distinguish an O(n) from an O(n log n) solution on an input of size 10.
• Warmup, isolation, and hardware variability are handled inconsistently across benchmarks, so results don't compare cleanly across studies.

The paper proposes fixes: bigger inputs, repeated runs with proper statistical tests, verified-efficient reference solutions, and a checklist for what a credible performance benchmark should look like. It's essentially a "measurement hygiene" paper for a field that's been publishing performance claims on shaky foundations.

The broader point is one that keeps recurring in ML evaluation: if your benchmark can't distinguish signal from noise, every model looks the same. That's not proof the models are equivalent — it's proof your ruler is too short. As LLMs get better and the gaps get smaller, the quality of measurement infrastructure becomes the bottleneck for knowing whether progress is happening at all.

Surface roughness (Ra) captures the high-frequency texture left by a machining tool — the peaks and valleys spaced microns apart. But there's a second, sneakier form of surface error that Ra completely ignores: waviness. Waviness is the low-frequency undulation of the sealing surface — gentle hills and valleys spaced millimeters apart, not microns. On a V-band flange, waviness is what makes an otherwise perfectly machined surface leak.

The distinction matters because a profilometer separates the two using a cutoff wavelength (typically 0.8 mm for automotive work). Anything shorter than the cutoff is called roughness; anything longer is waviness. A flange can hit a beautiful 32 µin Ra roughness spec while still having 50 µm of waviness rolling across the sealing face — and that waviness is what the V-band clamp has to squeeze flat.

Where waviness comes from:

• Chatter — tool deflection oscillating against workpiece stiffness on a lathe leaves periodic waves matching the spindle harmonics
• Fixture flex — a flange clamped in three jaws distorts into a trilobed shape; released, it springs back with three waves per revolution
• Post-weld distortion — welding the flange to the header tube warps the sealing face after machining, creating waviness even if the finish cut was perfect
• Thermal cycling — repeated heat cycles slowly relax residual stresses, growing waviness over the flange's service life

Real-world example: A Subaru EJ25 turbo header ships with 25 µm Wt (waviness total height) on the V-band flange. After 30,000 miles of thermal cycling, that grows to 60 µm. The V-band clamp's stainless retention rings can plastically deform maybe 40 µm of waviness before load bypasses the peaks and the valleys start whistling. Result: a slow boost leak that shows up as sluggish spool with no visible cracks.

Rule of thumb: Waviness total (Wt) should stay under half the clamp's elastic deformation range — typically 25 µm for a stainless V-band, 40 µm for a soft steel gasketed joint. If your Ra is perfect but you're still leaking, chuck the flange on a profilometer with the cutoff set to 2.5 mm and look at the Wt trace. You'll usually see three or four beautiful sinusoidal waves — the fingerprint of the machining fixture that made it.

Ra tells you how the tool cut. Waviness tells you how the whole system flexed.

This function walks an array once and returns the largest element. Given {10, 25, 15, 40, 20, 35}, we expect 40. Instead, we get 35 — and the sanitizer screams about an out-of-bounds read. What's going on?

#include <stdio.h>

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int max_price(const int *prices, int n) {
    int max = prices[0];
    int i = 1;
    while (i < n) {
        max = MAX(max, prices[i++]);
    }
    return max;
}

int main(void) {
    int prices[] = {10, 25, 15, 40, 20, 35};
    printf("Max: %d\n", max_price(prices, 6));  // want 40, get 35 (and UB)
    return 0;
}

The Bug

MAX is a function-like macro, and the preprocessor doesn't know that prices[i++] has a side effect. The call expands textually to:

max = ((max) > (prices[i++]) ? (max) : (prices[i++]));

That's two occurrences of i++. Whenever the comparison chooses the second branch, i is incremented twice and a different element is what actually gets assigned to max.

Trace with {10, 25, 15, 40, 20, 35}:

• max=10, i=1 → compare against prices[1]=25, i=2. 10 > 25 false, evaluate again: read prices[2]=15, i=3. max=15. The 25 vanished.
• max=15, i=3 → compare against prices[3]=40, i=4. False, evaluate again: read prices[4]=20, i=5. max=20. The 40 vanished too.
• max=20, i=5 → compare against prices[5]=35, i=6. False, evaluate again: read prices[6] — one past the end. Undefined behavior. Assuming the read returns garbage ≤ 35, max=35.

The macro doesn't just return the wrong answer — it walks off the array. In release builds this can silently corrupt neighbouring stack data or return whatever happened to sit past the buffer. Under ASan, it's a hard crash.

The general rule: any macro argument that appears more than once in the expansion is a landmine for side-effecting expressions. MAX(i++, j++), MAX(*p++, x), MAX(read_byte(), threshold) — all broken. The ternary variant even has a second, subtler flaw: it returns an lvalue in some compilers and forces both sides through the same conversion, which trips up type promotion.

The Fix

Use a static inline function. Each argument is evaluated exactly once by the language rules, and the compiler will inline it just as aggressively as the macro:

static inline int max_int(int a, int b) {
    return a > b ? a : b;
}

int max_price(const int *prices, int n) {
    int max = prices[0];
    for (int i = 1; i < n; i++) {
        max = max_int(max, prices[i]);
    }
    return max;
}

If you truly need a type-generic macro, GCC/Clang's statement-expression + typeof idiom caches each argument in a local, evaluating it once:

#define MAX(a, b) __extension__ ({ \
    __typeof__(a) _a = (a);        \
    __typeof__(b) _b = (b);        \
    _a > _b ? _a : _b;             \
})

C11's _Generic or C++'s templates give you a portable, side-effect-safe alternative. If your codebase is stuck on classic macros, at least name them in SHOUTY_CASE and forbid non-trivial arguments in code review — because the compiler will never warn you when you feed one in.

An inductor's core material is arguably more important than its winding. The core sets the achievable inductance density, the saturation current, the core losses, and the frequency range where the part actually behaves like an inductor. Pick wrong and your buck converter runs hot, your RF filter mysteriously loses Q, or your EMI choke stops filtering above 1 MHz.

Air-core inductors have no magnetic material — just a coil of wire. Permeability is exactly 1, so inductance per turn is tiny (you need lots of turns for even a few microhenries). But they have zero core loss, zero saturation, and perfectly linear behavior. Air-core coils dominate RF work above ~30 MHz where core losses in other materials would destroy Q. Classic use: the tank coil in a 100 MHz oscillator, wound as a self-supporting helix of tinned copper.

Iron-core (laminated silicon steel) inductors have very high permeability (μᵣ = 4000–10,000), giving enormous inductance in a small volume. Laminations break up eddy currents, but they only work up to ~1–20 kHz. Above that, hysteresis and eddy losses explode. This is 60 Hz territory: line-frequency transformers, mains chokes, audio output transformers.

Powdered iron cores (Micrometals, Magnetics Kool-Mu) are the SMPS workhorse. Iron particles are individually insulated and pressed into a toroid, giving a distributed air gap. Permeability is moderate (μᵣ = 10–100), and the distributed gap prevents saturation — inductance rolls off gracefully with DC bias instead of collapsing. Use these for 20 kHz to a few MHz: buck/boost inductors, PFC chokes, output filters.

Ferrite (covered obliquely in prior lessons) sits between: much higher frequency capability than powdered iron (up to ~100 MHz for NiZn), but sharp saturation. Great for signal chokes and small SMPS transformers; needs a physical gap for high-DC-bias applications.

Rule of thumb — pick your core by frequency:

• DC to 20 kHz: laminated silicon steel
• 20 kHz to 1 MHz with heavy DC bias: powdered iron
• 100 kHz to 10 MHz signal: MnZn ferrite
• 1 MHz to 100 MHz: NiZn ferrite
• Above 30 MHz, low-loss RF: air-core

Concrete example: Design a 100 µH inductor for a 200 kHz buck converter carrying 5 A DC with 1 A ripple. Powdered iron toroid (Micrometals T50-26, AL = 32 nH/turn²) needs N = √(100000/32) ≈ 56 turns. Check DC bias: at 5 A, the T50-26 shows ~30% inductance rolloff — still acceptable. Try the same design with a ferrite toroid without a gap and it saturates hard at 2 A. That's the powdered iron advantage.

Watch the Curie temperature too: ferrites lose their magnetic properties around 200–450°C, and even mild self-heating shifts permeability. Powdered iron degrades permanently above ~125°C — a stressed inductor slowly loses inductance over months.

Most keyed shaft connections use a parallel key — a straight rectangular bar that fits snugly in matching keyways on the shaft and hub. Torque is transmitted through the sides of the key in shear. But there's an older, cruder family of keys that works differently: taper keys and their close cousin, the gib-head key. Instead of transmitting torque through side contact, they wedge the hub onto the shaft with an interference fit.

A taper key has a slope on its top surface — typically 1:100 (1 mm rise per 100 mm length). The shaft keyway is cut flat and parallel to the shaft axis; the hub keyway is cut with the same 1:100 taper. When the key is driven in from the end, it wedges between the flat shaft keyway floor and the tapered hub keyway roof, jamming the hub eccentrically against the shaft. Friction — not shear — carries most of the torque.

A gib-head key is a taper key with a hooked, protruding head at the large end. The head sticks out beyond the hub face so you can drive a wedge or drift behind it to extract the key. Without the gib head, you'd have to punch the key through from the small end — which only works if the shaft is accessible on both sides of the hub.

Where you find them: old flat-belt line shafts in machine shops, large industrial flywheels, water pump impellers on ag equipment, sugar mill rollers, and marine propeller couplings. Any place where a hub is installed once, expected to stay put through vibration and reversing loads, and doesn't need to be repositioned angularly with precision.

The tradeoff: Because the wedging action lifts the hub off-axis, taper-keyed hubs run with a measurable eccentricity — typically 0.05–0.15 mm of runout. That's fine for a 60 RPM line shaft but ruinous for a 3600 RPM electric motor. This is why parallel keys with setscrews dominate modern motor shafts: they preserve concentricity.

Rule of thumb — extraction force: The force needed to drive out a taper key is roughly:

F ≈ μ × N × (1 + 1/tan θ)

Where μ is the friction coefficient (~0.15 for steel-on-steel), N is the normal clamping force, and θ is the taper angle. For a 1:100 taper (θ ≈ 0.57°), 1/tan θ ≈ 100, so extraction force is roughly 100× the friction force alone. This is why gib heads exist — you cannot just tap these out.

Failure mode: Repeated reversing torque can walk a taper key loose. Once it lifts even slightly, the hub rocks, the keyway hammers, and the shaft is destroyed. Modern designs use setscrews through the hub into the key as insurance.

The excerpt I was handed of Gardner Dexter Hiscox's famous 10,000-formula compendium doesn't actually contain any formulas — it contains only the Google Books preamble bolted onto the front of the scan. But that preamble is itself now a forgotten artifact, a message-in-a-bottle from the early digitization era that reads very strangely in 2026.

Hiscox's Henley's Formulas was the household internet of its day: ten thousand recipes for making shoe polish, silvering mirrors, tempering steel, curing hams, dyeing feathers, faking mahogany, and mixing patent medicines. It was the book a machinist, a druggist, and a farmer's wife might all own. When Google scanned it around 2007–2010, they wrapped it in this notice:

Refrain from automated querying: Do not send automated queries of any sort to Google's system. If you are conducting research on machine translation, optical character recognition or other areas where access to a large amount of text is helpful, please contact us.

Read that again. In the year Henley's was scanned, "areas where access to a large amount of text is helpful" was a niche worth calling out by name — a specialty of academic labs. The notice imagines a polite researcher writing in to ask for a corpus. It could not imagine that within fifteen years, the entire contents of scanned libraries would be treated as training feedstock, that trillion-parameter models would ingest Hiscox's shoe polish recipes alongside Shakespeare, and that a language model would be summarizing this very preamble back to a user in 2026.

The preamble also contains a small, wistful claim that has aged well:

Public domain books are our gateways to the past, representing a wealth of history, culture and knowledge that's often difficult to discover.

This is the actual forgotten knowledge. In 1914, Hiscox assumed his readers needed formulas because commercial products were expensive, adulterated, or unavailable. By 1980, nobody made their own shoe polish. By 2010, Google worried people wouldn't discover books like Hiscox's at all. By 2026, we've come full circle: makers, homesteaders, and hobbyists are once again mining Hiscox for lost recipes — how to blue steel without modern chemicals, how to make ink from oak galls, how to silver a mirror with sugar and silver nitrate — because supply chains feel fragile and self-sufficiency feels valuable again.

The book was a peer-to-peer knowledge network before that phrase existed. The digitization preamble is a snapshot of the last moment humans thought of "text" as something a person reads rather than something a machine eats. Both are worth preserving — and both are already being forgotten in different ways.

Buried in a dry 1970 CIA budget memo — a request from the National Photographic Interpretation Center (NPIC) to the Deputy Director of Central Intelligence for more contract money — is a description of a machine that, in retrospect, was doing computer vision two decades before the term became commonplace.

The device was called the Target Indexing Device (TID), and the memo describes its purpose plainly:

This equipment will provide NPIC with the capability of rapidly and automatically scanning [film] in order to specify targets that are cloud covered or cloud free; or to determine percentage of cloud cover on a frame-by-frame basis.

In other words: a mechanical film-transport system that pulled reconnaissance imagery past optical sensors at 100 feet per minute and produced, automatically, a per-frame cloud-cover percentage. That is exactly the task that a modern satellite pipeline — Landsat's Fmask, Sentinel-2's cloud probability layer, Planet Labs' scene filters — performs today with convolutional neural networks. In 1970 the CIA was doing it with analog photometry, a film gate, and a "frame sensor" at the top of the film path that could detect frame boundaries and tie coordinates to ephemeris data.

The memo also reveals an unglamorous engineering headache that modern image pipelines never have to think about:

The original negative and/or duplicate negative copies can be accommodated with this sensor location; however, to process duplicate positive copies of the imagery using this sensor would require the film to be run emulsion side down. Operating in this mode results in scratches on the film due to the soft emulsion and the high speed (100 ft. per minute) of the device.

That is the reason additional funds were being requested — to add a second sensor so positive prints could be scanned without dragging their emulsion across the transport. It is a striking reminder that early automated image analysis wasn't limited by algorithms so much as by the physical fragility of the medium being analyzed.

Was this ahead of its time? Absolutely. The idea of automatic scene triage — "don't waste an analyst's time on a cloudy frame" — is the entire premise behind the cloud-mask products that every Earth-observation company ships today. What has changed is only the substrate: silver-halide emulsion became CCDs, mechanical film transports became solid-state readouts, and analog photometers became softmax layers. The problem — throw away the cloudy frames before a human ever sees them — is identical.

The other lost detail worth savoring: someone in 1970 had to write a formal cost-plus-fixed-fee contract amendment, routed through the Executive Director-Comptroller, because the emulsion on duplicate positives kept getting scratched. Modern MLOps engineers who complain about GPU quotas should read this memo and count their blessings.

In 1874, a 29-year-old French telegraph clerk named Jean-Maurice-Émile Baudot — self-taught, working nights at the Paris Post Office — filed a patent that quietly invented character encoding, digital multiplexing, and the very idea of a fixed-length binary symbol. His U.S. patent, US 388,244, was granted in 1888 for a "Printing-Telegraph." Almost everything about it feels a century ahead of its time.

The problem Baudot solved was crushingly practical. In 1874, the Morse-based telegraph was choking Europe. Skilled operators were expensive, and each wire could carry only one message at a time. Morse itself used variable-length codes (dot, dash, gaps), which meant machines couldn't easily automate reception. Baudot rewrote the rules.

The invention did three radical things at once:

• A fixed-length 5-bit binary code. Every letter, digit, and punctuation mark was represented by exactly five on/off pulses — 32 combinations, extended to 64 via a "shift" character. This is identical in spirit to ASCII (1963) and UTF-8 (1992): fixed-width symbols out of a fixed alphabet.
• Time-division multiplexing. A rotating distributor cycled through 4–6 keyboards, sampling each in turn and interleaving their bits down a single wire. This is TDM — the exact scheme used by T-carrier lines, GSM voice channels, and every synchronous digital link since.
• A five-key chorded keyboard. Operators pressed a chord of five keys (like piano fingering) to enter each character. The machine synchronized with a metronome-like buzzer, forcing operators into lockstep with the distributor — the world's first clock-synchronous data entry.

Baudot's system launched on the Paris–Bordeaux line in 1877. By 1900 it had displaced Morse across most of Europe. Donald Murray refined the code in 1901 into what became ITA2 — the encoding used by Telex networks worldwide until the 1980s. When engineers designed ASCII in 1963, they explicitly cited ITA2 as the ancestor. When Unicode extended ASCII in 1991, it inherited the same architectural DNA: fixed-width code points from a finite alphabet.

The word "baud" — the unit of signaling rate you saw on every 300, 1200, 9600, and 56k modem — was named after him at a 1927 telecom conference. Every time you see "115200 baud" on a serial console today, you're honoring an 1874 patent.

What's genuinely startling is how modern the assumptions are. Baudot's system already contained: synchronous clocking, framing bits, symbol tables, multiplexing, and the notion that text is data — a stream of discrete symbols rather than an analog waveform. Alec Reeves's 1938 PCM patent gets credit for "inventing digital," but Baudot was doing binary character transmission 64 years earlier. The only missing piece was electronics; the logic was already there, executed in brass, springs, and a spinning distributor.

The SMS 160-character limit? That constant traces through GSM's 7-bit default alphabet, which traces through ASCII, which traces through ITA2, which traces directly to US 388,244. When your phone silently packs an emoji into UTF-8 bytes and squeezes them through a TDMA slot, it is executing — in silicon — the architecture a Paris night-shift clerk sketched with a fountain pen in 1874.

Personal-JobPilot is an ambitious solo project that tackles one of the most tedious rituals of modern life: the job hunt. It's a fully local, autonomous agent that scans the big three applicant-tracking systems — Greenhouse, Lever, and Ashby — and then does something most job-search tools don't dare attempt: it actually applies for you, using Playwright to drive the browser.

What sets it apart from the sea of "AI job hunter" SaaS products is the local-first architecture. Instead of shipping your resume and search history to some third-party API, it runs a local Gemma-4 27B model through Ollama to:

• Score job postings against your profile
• Generate ATS-friendly, tailored resumes on demand
• Make submission decisions without a cloud round-trip

The design implies a thoughtful stack: a scraper layer for the three ATS platforms, a scoring pipeline feeding the local LLM, a resume templating engine, and a Playwright automation layer for form-filling. Running a 27B parameter model on a single laptop is not trivial — it suggests the author is optimizing for privacy and control over convenience.

Who might find this useful:

• Active job seekers tired of retyping the same information into 50 different portals
• Privacy-conscious engineers who don't want a SaaS reading their career history
• Local-LLM enthusiasts looking for a practical, high-value Ollama use case beyond chat demos
• Playwright learners studying real-world browser automation against dynamic, JS-heavy forms

The obvious caveats: auto-applying can burn bridges if the resume tailoring is sloppy, and each ATS is a moving target with anti-bot defenses. But as a proof of concept for what a self-hosted career agent looks like, it's a compelling read.

You've seen SIMD load 8 floats in one instruction — VMOVUPS pulls a contiguous 32-byte chunk in a single micro-op. Then AVX2 introduced VGATHERDPS: give it a base pointer and a vector of 8 indices, and it loads 8 floats from 8 potentially unrelated addresses into one register. On paper, it's the missing piece for sparse workloads: indexed lookups, hash tables, mesh traversal. In practice, it's one of the most disappointing instructions in the ISA.

The problem is that SIMD is a lie about the load pipeline. A contiguous load hits one cache line, uses one AGU, one load port, one TLB entry. A gather with 8 different indices needs, in the worst case, 8 separate AGU computations, 8 TLB lookups, 8 cache tag checks, and 8 data-array reads. The CPU has 2 or 3 load ports total. So a gather doesn't magically parallelize — it serializes across load ports, one lane per cycle at best.

The microarchitecture handles this by cracking the gather into micro-ops in the scheduler. On Haswell (the first AVX2 CPU), VGATHERDPS ymm decoded into 20+ uops and took ~20 cycles even when all 8 addresses hit L1. Skylake improved it to ~15 cycles. Ice Lake and Zen 4 got it down to ~10. Compare that to a manual loop of 8 scalar loads: also ~8 cycles when everything is in L1, and the scalar version can be reordered around other work.

The hidden killers:

• Cache line collisions. If two indices land on the same 64-byte line, some implementations detect this and coalesce; others just do the work twice.
• Bank conflicts. Two lanes hitting the same L1 bank stall each other (see: cache banks lesson).
• TLB pressure. Eight indices that span eight pages = eight TLB lookups. If any miss, the gather stalls waiting for the page walker.
• Partial faults. If lane 3's address faults, the CPU has to unwind the whole gather — with mask preservation for the lanes that already succeeded.

Rule of thumb: A gather is worth it only when the alternative is worse than 8 scalar loads plus insert-into-vector overhead. Roughly: if your indices are dense (>50% cache-line reuse), gather wins. If they're truly random across memory, scalar loops are usually faster because they don't waste micro-op slots.

Real example: Intel's own MKL sparse-matrix routines avoided VGATHERDPS entirely on Haswell — hand-rolled scalar-load-and-insert sequences were ~2x faster. It took until Skylake-X (AVX-512's VGATHERDPS zmm with hardware coalescing) for gather to become genuinely worth using on sparse workloads.

The BitMEX posting is fascinating precisely because of what it doesn't say. There's no stack, no role list, no benefits pitch — just a defensive-sounding explainer about the business model itself. That's the tell.

1. The stack is conspicuously absent. For an HN "Who is Hiring" post, omitting the tech stack is unusual. Most listings in this same thread (Wanderlog, Thoughtexchange, Treasury Prime) lead with TypeScript, Node, React, cloud-native Ubuntu, etc. BitMEX skips it entirely, which suggests either (a) they don't want to advertise their internals (likely, given they run a matching engine handling real money), or (b) they're hiring across so many stacks that leading with one would mislead. Their engine is famously written in kdb+/q — a niche APL-derivative used in high-frequency finance. That's not a stack you casually recruit for on HN.

2. The stage signal is loud. "Over half a million open accounts, of which approximately 100,000 belong to active users" — a 20% activation rate is the headline metric they chose to lead with. That's a company optimizing for perceived scale to attract talent, not one bragging about growth velocity. They're mature, profitable, and defending market position rather than land-grabbing.

3. The framing is defensive. "What is BitMEX — and why do we exist?" followed immediately by "We are not a spot exchange" reads like a regulatory disclaimer bolted onto a recruiting pitch. In March 2020, BitMEX was already under CFTC scrutiny (the indictment came six months later). This posting is written by people who spend a lot of time explaining to regulators, journalists, and prospective hires what they are and aren't.

4. "San Francisco | VISA | On-Site" — the visa sponsorship offer is a green flag for candidates, but the SF + onsite requirement in a crypto derivatives shop is striking. BitMEX is HQ'd in Seychelles for regulatory reasons; an SF office implies they wanted US engineering talent without US regulatory exposure to the exchange itself. That's a specific, deliberate structure.

Red flags:

• No role specificity — "we're hiring" without saying what suggests low-volume, referral-heavy recruiting
• No mention of the product's regulatory posture or where the entity is based
• Zero information about team, culture, or engineering practices

Green flags: Visa sponsorship, established revenue, and a genuinely hard technical problem (matching engine at scale, adversarial security environment).

On Linux, fork(), pthread_create(), and vfork() are all thin wrappers around one syscall: clone(). The difference between "a new process" and "a new thread" isn't architectural — it's just which bits you set in the flags argument. The kernel calls every schedulable entity a task, represented by a task_struct, and clone() decides which resources the new task shares with the parent versus copies.

The flag bits are a menu of shared resources:

• CLONE_VM — share the address space (same page tables). Without this, the child gets a COW copy.
• CLONE_FS — share filesystem info (cwd, umask, root).
• CLONE_FILES — share the file descriptor table. Closing fd 5 in one thread closes it in all.
• CLONE_SIGHAND — share signal handler dispositions (but not masks — those are per-task).
• CLONE_THREAD — put the new task in the same thread group (same TGID, same getpid()).
• CLONE_PARENT_SETTID / CLONE_CHILD_CLEARTID — write the TID to a user address on create/exit. This is how glibc implements pthread_join() via a futex on that word.
• CLONE_SETTLS — install a new TLS descriptor (loads FS_BASE on x86-64).

Rule of thumb: a POSIX thread is roughly CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SETTLS | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID. A fork() passes only SIGCHLD — nothing shared. A vfork() passes CLONE_VM | CLONE_VFORK | SIGCHLD — share memory, but suspend the parent until child execs.

Real-world example: the "share fd table but not memory" combination (CLONE_FILES without CLONE_VM) is exactly what container runtimes use when spawning a helper that needs to inherit specific sockets but must have its own address space. It's also what Chrome's zygote uses to share the connection to the browser process across renderer forks without a full IPC handshake.

The oddity most engineers hit: CLONE_THREAD requires CLONE_SIGHAND requires CLONE_VM. You cannot have "threads in the same thread group but separate memory." The kernel enforces this because signal delivery to a thread group assumes shared handlers, which assumes shared memory to hold them. This is why pthread_create without CLONE_VM is nonsensical — the whole abstraction collapses.

A subtle consequence: gettid() returns the kernel TID (unique per task), but getpid() returns the TGID (shared across all threads in a group). This is why /proc/<pid>/task/<tid>/ exists — one directory per task inside the thread group.