Daily Digest — 2026-09-02

In July 1985, a small semiconductor company in Bristol, England, shipped the T414 Transputer — a 32-bit microprocessor with something no other chip had: four bidirectional serial links designed to be soldered directly to the links of other Transputers. You didn't build a Transputer system. You built a Transputer fabric. Wire four together, get four times the compute. Wire a thousand together, get a supercomputer.

Inmos was founded in 1978 with a £50 million grant from the Labour government's National Enterprise Board. Chief architect David May, working with C.A.R. Hoare's Communicating Sequential Processes (CSP) theory, designed the Transputer around a single premise: parallelism should be a hardware primitive, not a library. The instruction set had built-in send and receive opcodes. A dedicated language, Occam, expressed concurrency directly. Context switches took roughly one microsecond because they were baked into silicon.

The follow-on T800 (1987) added an on-chip floating-point unit — 1.5 MFLOPS at 20 MHz, competitive with Cray-1 vector performance per dollar. Meiko Scientific's Computing Surface strapped hundreds of T800s together and sold them to CERN, Edinburgh, and the U.S. Army. The Archimedes' rival ATW-800 workstation, the Parsytec supercomputers used by German aerospace firms, and the U.K.'s Alvey research programme all ran on Transputers.

Then came the T9000. Announced in 1991, it promised 200 MIPS, 25 MFLOPS, a superscalar pipeline, and 100 Mbit/s DS-Links routed through a companion C104 packet switch — essentially a network-on-chip years before that phrase existed. The T9000 slipped. And slipped. When it finally sampled in 1994, it ran at a fraction of the promised clock, the pipeline had catastrophic hazards, and SGS-Thomson (which had absorbed Inmos in 1989) killed the flagship configuration in 1996. Occam was orphaned. The chiplet ecosystem died with it.

Why it failed: a genuinely hard superscalar redesign collided with Thomson's post-acquisition cost cutting, workstation vendors standardized on RISC (SPARC, MIPS, PA-RISC), and the workstation-to-PC migration made "one fast processor" economically dominant over "many small ones" for a decade.

Why it works now:

• Message passing is mainstream. Go's channels, Erlang's actors, Rust's async, Kubernetes' pods — every modern concurrency model is a rediscovery of CSP. Occam got there in 1983.
• Network-on-chip is standard. Every ARM SoC uses AMBA/CHI mesh interconnects. AMD's Infinity Fabric, Intel's Foveros, and the UCIe chiplet standard (2022) are literally Transputer links with fatter pipes.
• The many-core comeback. Cerebras (900,000 cores), Tenstorrent's Grayskull, Graphcore's IPU, and Groq's LPU are all Transputer-shaped: small compute tiles with local memory and explicit inter-tile links. Graphcore was even founded in Bristol by two ex-Inmos engineers.
• Silicon photonics (Ayar Labs, Lightmatter, 2024–2026) delivers what Inmos wanted: dozens of terabit links per chip edge, making Transputer-style meshes bandwidth-competitive with monolithic dies.
• The AI workload matches the architecture. Transformer inference is embarrassingly parallel dataflow — precisely what a Transputer mesh was optimal for and what a monolithic superscalar CPU is worst at.

Modern silicon can build what David May sketched in 1983: a fabric of thousands of small, cheap tiles, each with local memory, each connected by high-speed serial links, programmed in a CSP-native language. We call the result "AI accelerator." Inmos called it Tuesday.

For about fifteen years, the conventional wisdom in the database world has been: if your data is "connected" — social networks, fraud rings, supply chains, knowledge graphs — you need a specialized graph database like Neo4j or TigerGraph. Relational databases (the SQL kind) were supposedly the wrong tool for the job, because joining tables together to trace relationships was slow and awkward compared to a purpose-built engine that stores data as nodes and edges.

This paper picks a fight with that assumption, and comes armed with benchmarks.

The author, Gene Zhang, argues something surprisingly bold: a modern columnar relational engine (the kind that stores data column-by-column instead of row-by-row, used in analytics warehouses like DuckDB, ClickHouse, or Snowflake) — when you put a graph query language on top of it — actually matches or beats native graph engines on real analytical workloads. And more importantly, it keeps working at scales where in-memory graph engines simply run out of room and crash.

The two big claims:

• Performance parity or better. On the kinds of graph queries enterprises actually run (aggregations across relationships, multi-hop traversals with filters), a columnar engine holds its own. The overhead people assumed relational systems paid turns out to be small — or negative — because columnar engines have spent two decades getting extremely good at joins.
• Scale is decisive. Native graph engines typically want the whole graph in memory. Relational systems don't. So once your dataset gets big enough, the graph engine falls over and the relational one keeps going.

The deeper philosophical claim is even spicier. The property graph model (nodes with properties, edges with properties) isn't a "truer" representation of connected data — it's just a representation, and one that imposes a real cost. Every relationship gets its own object with its own storage and indexing overhead. The paper argues this is a performance tax disguised as intuition. Relations between things, Zhang says, are perfectly well captured by tables and foreign keys; you just need a query language that doesn't make you write ugly SQL to express traversals.

The proposed compromise: keep the friendly graph query syntax (something Cypher-like) as the developer interface, but compile it down to run on a columnar relational engine underneath. Best of both worlds — expressive queries, but the mature storage and execution machinery of the SQL world.

If Zhang is right, a lot of specialized graph database deployments are solving a problem their organization already had a better tool for. That's a big "if," but the argument is well-motivated by where actual enterprise graph workloads sit: mostly analytical, mostly too big for RAM.

Lobe Separation Angle is the angular distance, in camshaft degrees, between the peak lift of the intake lobe and the peak lift of the exhaust lobe for the same cylinder. It's ground into the cam when it's machined — you can't change it without regrinding. Typical range is 106° to 116°, and this single number does more to shape your engine's character than almost anything else on the cam card.

Here's the mental model: the intake lobe opens as the exhaust lobe is closing. The angular gap between their peaks determines how much they overlap. Tighter LSA (say, 106°) pulls the lobes closer together, increasing valve overlap. Wider LSA (114°) pushes them apart, reducing overlap.

What tight LSA does:

• Big overlap creates that lumpy, cammed idle — exhaust reversion pulses back through the intake, killing manifold vacuum
• Peaky powerband, strong mid-range, falls off top and bottom
• Terrible for boosted engines — overlap pushes boost straight out the exhaust
• Loves headers and low backpressure exhaust

What wide LSA does:

• Smoother idle, better vacuum for power brakes and accessories
• Broader torque curve, better top-end pull
• Mandatory for turbo/supercharged engines — sealing the chamber during overlap keeps boost in the cylinder
• Better emissions and fuel economy

Real-world example: Compare a Chevy LS3 (cam LSA around 116°) to an old-school big-block solid-roller street cam ground on a 108° LSA. The LS3 idles at 650 RPM with 18 inches of vacuum and pulls a truck. The 108° cam idles at 1000 RPM shaking the mirrors, makes 6 inches of vacuum, and needs a stall converter to move the car — but it screams from 3500 to 7000.

Rule of thumb: For a naturally aspirated street engine, start at 110°. For every 2° tighter, expect roughly 1 inch of vacuum lost at idle and 300-500 RPM shift up in the powerband. For turbo engines, don't go tighter than 114° unless you enjoy blowing boost out the tailpipe.

Duration interacts: LSA effects amplify with duration. A 220°-at-.050" cam on a 108° LSA is manageable; a 260° cam on the same 108° LSA is undrivable on the street. Cam grinders wide-out the LSA as duration grows to keep overlap in check.

This helper builds a password-reset link by substituting the user's email into a URL template. It's been running quietly in production for years. Then one Tuesday, support tickets start piling up: a handful of users can't reset their passwords, and the stack traces make no sense.

public class LinkBuilder {
    private static final String TEMPLATE =
        "https://example.com/reset?email=EMAIL_HERE&token=abc123";

    public static String buildResetLink(String userEmail) {
        // Substitute the user's email into the template.
        return TEMPLATE.replaceAll("EMAIL_HERE", userEmail);
    }

    public static void main(String[] args) {
        System.out.println(buildResetLink("[email protected]"));
        // https://example.com/[email protected]&token=abc123  ✅

        System.out.println(buildResetLink("[email protected]"));
        // java.lang.IndexOutOfBoundsException: No group 1  💥

        System.out.println(buildResetLink("weird\\[email protected]"));
        // java.lang.StringIndexOutOfBoundsException  💥
    }
}

The Bug

String.replaceAll(regex, replacement) has two layers of special-character interpretation, and most developers only remember the first one.

• The first argument is a regex. Everyone knows that.
• The second argument is not a plain string. It's a replacement pattern parsed by Matcher.appendReplacement. Inside it, $1, $2, … refer to capture groups from the regex, and \ is an escape character.

So when userEmail is [email protected], the replacement engine sees $1 and tries to substitute capture group 1 — but the regex "EMAIL_HERE" has no groups, so it throws IndexOutOfBoundsException: No group 1. A trailing backslash throws StringIndexOutOfBoundsException. And, more insidiously, if the regex did have groups, a $1 in user input would silently splice unrelated text into the URL.

This is the same class of bug as SQL injection or format-string injection: user data is being interpreted as code. The values $ and \ are perfectly legal in email local-parts (RFC 5321), so this will reach production.

The Fix

Three options, in ascending order of "how much you actually need regex":

// 1. Best: don't use regex at all. String.replace() is a plain substring replace.
return TEMPLATE.replace("EMAIL_HERE", userEmail);

// 2. If you truly need a regex pattern, quote the replacement:
return TEMPLATE.replaceAll("EMAIL_HERE", Matcher.quoteReplacement(userEmail));

// 3. Or use replaceFirst — same trap, but at least explicit about intent:
return TEMPLATE.replaceFirst(Pattern.quote("EMAIL_HERE"),
                             Matcher.quoteReplacement(userEmail));

String.replace(CharSequence, CharSequence) — note the CharSequence overload, not the char one — does a literal substring replacement with no pattern interpretation on either side. It's what almost everyone actually wants.

The naming is the trap: replaceAll sounds like "replace all occurrences" (as opposed to just the first), when it really means "regex replace all." replace sounds like it only replaces once. It's the reverse of the intuition.

A useful rule of thumb: if either argument to replaceAll comes from outside your code, one of them needs quoting. Pattern.quote for the regex, Matcher.quoteReplacement for the replacement. Or just switch to replace and sleep better.

A basic PLL locks its output at an integer multiple N of the reference: if the reference is 10 MHz and N=245, the output is 2450 MHz. Fine — until you need 2450.5 MHz. You can't get there by picking a new integer, and dropping the reference to 5 MHz to gain resolution destroys loop bandwidth and phase noise. Fractional-N synthesis is the trick: make N change over time so the average divide ratio is non-integer.

The naïve approach — divide by 245 half the time and 246 the other half to get an average of 245.5 — works, but the periodic switching creates massive fractional spurs. The phase detector sees a repeating error pattern at the switching frequency, and that pattern modulates the VCO. You get discrete tones offset from the carrier by kHz, which is fatal for RF and bad even for CPU clocks.

The solution is a delta-sigma modulator driving the divider select. Instead of a periodic pattern, the DSM produces a pseudo-random sequence of integers whose running average equals the desired fraction. A first-order DSM outputs mostly 245s with an occasional 246 to make up the deficit; a MASH 1-1-1 (three cascaded first-order stages) shapes the quantization error so it's pushed to high frequencies where the PLL loop filter attenuates it. The average is exact; the noise is out of band.

Worked example. You want 2450.5 MHz from a 10 MHz reference. Set N.frac = 245 + 0.05. Every reference cycle, the DSM chooses 245 or 246 such that after 20 cycles it's produced exactly one 246 and nineteen 245s. Average = (19·245 + 246)/20 = 245.05. Multiply by 10 MHz: 2450.5 MHz. The switching happens at ~500 kHz, but a MASH-3 shapes that noise up to megahertz, where a loop filter with 100 kHz bandwidth kills it.

Rule of thumb: loop bandwidth ≤ f_ref / 10 for stability. Loop bandwidth ≤ 1/20 of the first significant DSM noise peak, or the shaped quantization noise leaks through as phase noise on the output. Higher-order DSMs push noise further out, letting you widen the loop bandwidth for faster lock — at the cost of more digital area and potential limit cycles that need LSB dithering to break.

Real use: every cellular radio (LTE, 5G) uses fractional-N to hop channels on kHz grids from a single ~26 MHz crystal. Modern CPUs use it for per-core DVFS — each core's PLL can independently hit any frequency in ~10 MHz steps without switching references.

You've seen thermistor linearization circuits that reshape the NTC's curve in hardware. But when you have a microcontroller and an ADC, the smarter play is to leave the thermistor alone and do the math in firmware. The Steinhart-Hart equation is the gold-standard model for NTC thermistors, giving temperature accuracy of ±0.01°C over a wide range — far better than the simple Beta-parameter approximation.

The equation is:

1/T = A + B·ln(R) + C·(ln(R))³

Where T is temperature in Kelvin, R is the measured thermistor resistance in ohms, and A, B, C are coefficients specific to your thermistor. Note the missing squared term — Steinhart and Hart found empirically that it contributes almost nothing and dropped it.

Getting the coefficients: Datasheets often list them directly. If not, measure resistance at three temperatures spanning your range of interest (say 0°C, 25°C, 50°C), then solve the resulting 3×3 linear system for A, B, C. Online calculators (Vishay, Ametherm) will do this for you.

Circuit implementation: Wire the thermistor as the upper leg of a voltage divider with a fixed resistor R_fixed equal to the thermistor's resistance at mid-range temperature. This maximizes ADC resolution where you care most. If you have a 10 kΩ NTC and you're measuring room-temperature circuits, use a 10 kΩ 0.1% reference resistor. Feed the midpoint to your ADC.

Firmware flow:

• Read the ADC value (raw count, 0 to 2^N-1)
• Compute thermistor resistance: R = R_fixed · (ADC_max/ADC_raw − 1) — notice V_ref cancels out (ratiometric!)
• Compute lnR = ln(R)
• Compute 1/T = A + B·lnR + C·lnR³
• Invert and convert to Celsius: T_°C = 1/(1/T) − 273.15

Real-world example: A 3D printer hotend uses a 100 kΩ NTC (typically an EPCOS B57560G1104). Marlin firmware ships with lookup tables derived from Steinhart-Hart because computing the log on an 8-bit AVR is slow. On an ARM Cortex-M with an FPU, just run the equation directly — takes microseconds.

Rule of thumb: Self-heating error = I²·R·θ_JA. For a 10 kΩ thermistor with 3.3 V across the divider at 25°C, current is ~165 µA, dissipation ~270 µW. With a typical θ_JA of 150°C/W, self-heating is ~0.04°C — negligible for most work, but drop the excitation duty cycle if you're chasing millidegrees.

Conventional seismic design tries to make buildings strong enough to survive earthquake forces. Base isolation flips the problem: instead of resisting the shake, let the ground move underneath the building. A layer of flexible bearings between the foundation and the superstructure decouples the two, so ground acceleration doesn't fully transmit upward.

The physics is elegant. A rigid building has a short natural period (0.1–0.5 seconds), which sits right in the frequency band where earthquake energy is strongest. By inserting flexible isolators, you deliberately lengthen the building's natural period to 2–3 seconds — far above the dominant seismic frequencies. The building becomes a low-pass filter: it "sees" only the slow, gentle motion, while high-frequency ground shaking passes through the isolators as displacement rather than acceleration.

The three main isolator types:

• Lead-rubber bearings (LRBs): Alternating layers of rubber and steel plates around a central lead core. Rubber provides lateral flexibility; steel plates prevent vertical squish; lead core dissipates energy through plastic deformation.
• Friction pendulum bearings: A concave stainless steel dish with a sliding articulated puck. The building literally swings like a pendulum, with natural period set by the dish radius: T = 2π√(R/g).
• High-damping rubber bearings: Rubber compounds engineered with internal damping — simpler than LRBs, no lead required.

Real-world example: The Los Angeles City Hall (1928) was retrofitted with 526 base isolators after the 1994 Northridge earthquake. The 32-story building now sits on rubber-and-lead bearings that allow up to 20 inches of lateral movement. Utilities crossing the isolation plane use flexible loops. Cost was about $300 million — but the building survives design-level earthquakes with contents intact and remains operational, whereas a fixed-base retrofit would have merely prevented collapse.

Rule of thumb: For friction pendulum bearings, target period T ≈ 3 seconds. Since T = 2π√(R/g), that means R ≈ gT²/(4π²) ≈ 88 inches (2.2 m) of pendulum radius. That's why isolator dishes are big — they're literally sized so the building oscillates slowly enough to dodge the earthquake's frequency content.

What it costs you: Isolation is expensive (5–10% construction premium), requires a "moat" around the building for lateral displacement, complicates every utility crossing, and works poorly for tall buildings where wind loads dominate. It's typically justified for hospitals, data centers, museums, and emergency-response facilities — places where staying functional after the quake matters more than merely not collapsing.

Long before the Environmental Protection Agency existed (founded 1970), before the Clean Water Act (1972), and before "industrial ecology" was a phrase anyone used, the U.S. Public Health Service was already doing rigorous, itemized fieldwork on how factories poison rivers. Public Health Bulletin No. 100, published in November 1919, is a case study of tannery pollution at the Deford Leather Company in Luray, Virginia—and it reads like a modern environmental impact assessment.

The report breaks tannery waste into a taxonomy that would look at home in an EPA permit today:

Wash water from green hides
Wastes from liming vats and unhairing
Wash water from the fleshing and graining floors
Exhausted or spent tan liquors and rinse water from vats in the layaway yard
Excess tan liquors carried by the heads and bellies when removed from the tanning vats
Leakage from leaching vats and a small amount of wash water
Spent alkali and acids from bleaching vats

What's striking is not that the government cared about tannery pollution—the stench of tanneries had driven them to city outskirts for centuries—but that Hommon and Phelps were doing quantitative source apportionment. They didn't just measure the effluent pipe. They separated waste streams by process step and characterized each one, presumably so treatment could be targeted at the worst offenders rather than diluting everything into one lagoon.

Earle B. Phelps is a name worth pausing on. He co-developed the Streeter-Phelps equation in 1925, which models how dissolved oxygen depletes downstream of a pollution source as bacteria consume organic waste. It's still taught in every environmental engineering program a century later. This 1919 bulletin is Phelps' methodology in its early form—the same mind that would soon give hydrology one of its foundational equations was here counting gallons of spent lime liquor draining out of a Virginia leather works.

Was the science right? Yes. Modern tannery waste treatment still targets the exact streams Hommon listed. Chromium (which replaced vegetable tanning for most leather after WWI) added new problems, but the general principle—segregate waste streams at the source, treat each according to its chemistry—is exactly how modern effluent treatment plants are designed. The "end-of-pipe" mixing approach that dominated mid-century industry turned out to be a regression from what Phelps was already prescribing in 1919.

The forgotten wisdom here isn't a technique—it's the timeline. We tend to think of environmental regulation as a post-1960s invention driven by Silent Spring and burning rivers. But federal scientists were systematically studying industrial pollution before Prohibition, publishing under the Treasury Department, using methodology that would still pass peer review. The knowledge existed. What was missing for the next 50 years was the political will to act on it.

Buried in the preface of a modest 1920 manual on photographic composition sits one of the more honest — and paradoxical — statements ever written by an instructional author. Arthur Hammond, associate editor of American Photography magazine and a fixture of the Boston photographic scene, opens his book with what amounts to a warning that the book you are holding cannot possibly do what its title promises:

To tell a photographer how to compose his pictures is like telling a musician how to compose music, an author how to write a novel or an actor how to act a part. Such things can only grow out of the fulness and experience of life.

This is a remarkable admission from a working professional trying to sell a $3.50 hardcover (roughly $60 today). But Hammond does not stop there. He immediately doubles back with an equally forceful counter-claim:

Yet the musician must learn harmony and counterpoint, the novelist must know the rules of grammar and the proper use of words, the actor must study elocution, and all of these are more or less exact sciences which can be taught.

What Hammond articulated in two sentences is a distinction that modern pedagogy — particularly in creative fields — has spent a century rediscovering and forgetting again. He drew a sharp line between craft (teachable, rule-based, drillable) and art (emergent, experiential, unteachable). The rules of thirds, leading lines, negative space, and tonal balance are counterpoint. The photograph itself is the symphony.

This is not a minor point. In 1920, photography was still fighting for recognition as a legitimate art form rather than a mechanical curiosity. The Pictorialist movement — of which Hammond was a foot soldier — was arguing that a camera could produce Art with a capital A. To concede in your opening paragraph that the artistic part cannot be taught was, commercially, close to malpractice. Yet Hammond understood something that today's flood of "10 rules for better photos" YouTube tutorials tends to obscure: learning the rules is necessary but not sufficient.

Modern cognitive science has largely vindicated him. Research on expert performance (Ericsson's deliberate practice work, and later critiques by Hambrick and others) shows that deliberate drilling of sub-skills reliably produces competence, but the leap to genuine creative output requires something that looks a lot like Hammond's "fulness and experience of life" — vast domain immersion, taste developed through exposure, and the ineffable ability to know which rule to break.

The forgotten piece here is not a lost technique but a lost humility. Instructional writing today — from coding bootcamps to MasterClass — tends to promise transformation. Hammond promised only the grammar. The novel was still up to you.

In November 1937, a Bell Labs mathematician named George Stibitz took two flashlight bulbs, a dry-cell battery, a tobacco tin, and a few surplus telephone relays home to his kitchen. On the table, he wired up a device that added two binary digits and lit a bulb for the sum. He called it the Model K — K for "kitchen."

Nobody at Bell Labs was impressed. Nobody except one manager, who realized a relay-based calculator might handle the exhausting complex-number arithmetic (multiplying a+bi by c+di) that Bell engineers ran for hours to design filters and long-distance networks.

By January 1940, Stibitz and switching engineer Samuel Williams had built the Complex Number Calculator — later renamed the Model I — from about 450 telephone relays. It weighed a quarter-ton, filled a lab, and multiplied two complex numbers in under a minute. Patent US 2,668,661, "Complex Computer," was filed April 19, 1941, and finally issued February 9, 1954 — a thirteen-year delay caused by wartime secrecy and postwar backlog.

Dartmouth, September 11, 1940

That afternoon, Stibitz set up a teletype machine at a meeting of the American Mathematical Society at Dartmouth College. The Complex Number Calculator sat 250 miles away, in the Bell Labs building at 463 West Street, Manhattan. A leased telephone line connected them.

Attendees — including John Mauchly (later ENIAC), Norbert Wiener, and John von Neumann — typed complex-number problems on the teletype. The machine in New York solved them and typed the answers back within seconds.

This was the first remote-access computation in history. Nobody in the room saw the machine. They sent a request over a wire, and a distant computer returned a result. Today we call that a client-server session, an SSH tunnel, a REST call, or a query against a cloud GPU. In 1940, it didn't have a name.

What the patent quietly established

• Binary arithmetic in hardware. Model K used base-2; Model I used a hybrid excess-3 code. Either way, it broke from the desk-calculator tradition of decimal wheels — years before ENIAC.
• Error-detecting codes. Later Bell Labs "Model" machines (II through VI) added self-checking arithmetic — the direct ancestor of ECC memory, TCP checksums, and every parity bit still guarding your RAM.
• Remote I/O as a first-class concept. The teletype-plus-phone-line architecture separated the terminal from the compute. Every mainframe timesharing system of the 1960s, every dial-up BBS, every SSH session, every browser talking to a cloud region is a lineal descendant.

Why it was almost forgotten

Stibitz's machines were electromechanical, not electronic. When ENIAC's 18,000 vacuum tubes lit up in 1945, relay computers looked like typewriters next to a jet engine. Patent 2,668,661 sat in the examiner's queue for thirteen years and finally issued into a world that had moved on. Stibitz himself left Bell Labs, became a Dartmouth professor, and later applied computing to biomedical modeling.

But the architectural insight — that computation and its user need not share a room — proved more durable than any specific technology. Cloud computing didn't invent remote execution; it just made the bandwidth cheap enough to do it a billion times a second. The idea has been running on somebody's wire since a teletype clacked at Dartmouth on a September afternoon in 1940 — 86 years ago this week.

mdview is a lightweight desktop Markdown viewer and WYSIWYG editor built on Rust + Tauri 2, delivering a single small binary that runs natively on Linux, macOS, and Windows. It aims squarely at the sweet spot between heavy Electron editors (Obsidian, Typora clones) and bare terminal tools like glow or bat — you get a real GUI without the 200MB memory footprint.

The feature list punches well above its weight for a zero-star repo:

• GitHub Flavored Markdown — tables, task lists, strikethrough, fenced code all render correctly out of the box
• KaTeX for math typesetting — a must for anyone writing technical notes or academic drafts
• Mermaid diagrams — flowcharts and sequence diagrams inline, no external tooling
• Live reload — edit externally in your favorite editor and watch changes propagate instantly
• Safe saves — atomic write pattern to avoid corrupting files on crashes or power loss
• Offline-first — no telemetry, no cloud sync, no login

The Tauri 2 foundation is particularly interesting. Tauri ships the OS's native webview instead of bundling Chromium, which is why the resulting binary stays tiny compared to Electron alternatives. For a Markdown viewer — a task that is fundamentally rendering HTML — this architecture is a near-perfect fit.

Who would benefit? Note-takers, technical writers, and README-tinkerers who want a proper preview alongside their editor without launching a browser tab or spinning up a static site generator. Developers on low-RAM machines or older laptops will especially appreciate the small footprint. And anyone documenting engineering work with math or diagrams gets first-class KaTeX + Mermaid rendering without configuring plugins.

It's early (zero stars, fresh push) so expect rough edges, but the scope is disciplined and the tech choices are sound.

The uop cache stores decoded micro-ops in fixed-size lines, each tied to a 32-byte aligned window of the original x86 instruction stream. On Intel Skylake through Golden Cove, each uop cache line holds up to 6 uops corresponding to instructions within one 32-byte fetch window. But here's the subtle part: the uop cache line only stores uops from the branch target onward within that window. If you jump into the middle of a 32-byte block, the uops before your entry point are simply absent from that line — and cannot be reused later, even if execution eventually flows through them.

This creates a wasteful asymmetry. Consider a hot function whose first instruction sits at offset 20 within a 32-byte window. When you CALL that function, the uop cache builds a line starting at offset 20, covering maybe 3 uops in the remaining 12 bytes. The first 20 bytes of that window — even if they contain valid decoded instructions from some other code path — get no representation in this line. If a different caller later branches to offset 4 of the same window, that's a separate uop cache line, competing for the same set with the offset-20 line.

Real-world example: A tight loop with an unaligned entry point (say, address 0x4013, offset 19 into its 32-byte window) can consume 2–3 uop cache ways just to represent the loop body, because the loop-back edge and any interior branch targets each anchor their own partial-line entries. The same loop aligned to a 32-byte boundary might fit in a single way. On Intel's 8-way DSB (Decoded Stream Buffer), losing 2 extra ways per hot function measurably increases eviction pressure across other hot code.

Rule of thumb: Each unique branch target within a 32-byte window costs you one uop cache way in that set. If a hot function has N distinct entry points into the same 32-byte block (via fallthrough, jumps, and call targets), budget N ways of DSB capacity for it. Modern linkers align function entries to 16 or 32 bytes precisely to avoid this — GCC's -falign-functions=32 and Intel's recommended 32-byte alignment for hot loops both target this exact behavior.

The pathological case: a computed jump table where targets land at arbitrary offsets inside shared 32-byte windows. Each target burns its own DSB line, and the pre-target bytes get re-decoded on every fall-through path that needs them — effectively duplicating decode work the uop cache was supposed to eliminate.

Every developer who has ever SSH'd into a minimal container, dropped into a recovery shell, or fired up sh instead of bash has hit the same infuriating wall: you press the up arrow expecting your last command, and instead the terminal spits out ^[[A. You press left to fix a typo and get ^[[D. Then you sheepishly retype the whole line.

This post looks like it actually explains why that happens — which is a rabbit hole that goes surprisingly deep. The short answer touches on:

• Escape sequences — arrow keys don't send a single byte. They send ESC followed by [A, [B, [C, [D. The terminal emulator agreed on this convention decades ago via ANSI/VT100.
• Line editing lives in the shell, not the terminal — bash uses readline, zsh uses ZLE, and both interpret those escape sequences to move the cursor or walk history. Plain POSIX sh (dash, ash, busybox sh) often has no line editor at all, so the raw sequence just gets echoed.
• Terminfo and $TERM — if the terminal identifies itself as something the remote system doesn't have a terminfo entry for (hello, TERM=xterm-kitty on an old Alpine box), key bindings silently break.
• rlwrap — the classic escape hatch. Wrap any REPL that lacks line editing (rlwrap sqlite3, rlwrap python2, rlwrap sh) and you get history, editing, and completion for free.

This is exactly the kind of foundational plumbing knowledge that everyone touches but almost nobody sits down to actually learn. It's one of those articles where after reading it, a dozen unrelated frustrations across your career suddenly click into place — why docker exec -it alpine sh is miserable, why your Dockerfile's RUN steps behave oddly, why ssh into a stripped-down box feels time-warped to 1985.

Emma Juettner's blog has a track record of taking small "wait, why does that happen?" observations and unpacking them with genuine curiosity rather than the surface-level answer. This slipped through with a single upvote and no comments, which is a shame — it's the kind of post that should live in a bookmark folder titled "explain this to the junior next week."

Of the ten postings, MUFG's is the most revealing because it's a Japanese megabank quietly trying to hire like a startup, and the framing gives away exactly how their internal politics are shifting.

What the posting actually says (and doesn't): There is no tech stack listed. No languages, no cloud vendor, no frameworks. Instead, the pitch is aspirational — "building a platform supporting the pace of evolution of financial technology, to unlock new businesses." That vagueness is itself the tell. When a bank posts on HN without naming a single technology, it means either (a) they haven't picked one yet, or (b) the hiring manager knows that naming Java 8 and WebSphere would kill applications instantly. Both interpretations point to a greenfield-ish platform group operating inside a legacy institution.

Stage and direction: The phrase "modern broadly skilled and security-minded engineers" is code for full-stack polyglots who won't file a ticket to get a database created. The emphasis on "security-minded" isn't decorative — for a regulated bank, it signals they want engineers who can self-serve within compliance guardrails rather than depend on a separate InfoSec throw-it-over-the-wall team. This is the DevSecOps pattern FAANGs adopted a decade ago finally reaching Tier-1 banking.

The remote framing is the loudest signal:

• REMOTE "is fine" — grudging language, not enthusiastic
• Only "in certain hub areas" — NYC, SF, LA, Charlotte, Tempe, Dallas
• Must attend team meetings "at least weekly" in person "after location-based work restarts"

Translation: this was written mid-pandemic (the thread is from early 2020) by a manager who expects the office to come back and is treating remote as a temporary accommodation. The hub list also maps precisely to MUFG/UnionBank's existing US footprint — they're not opening new markets, they're loosening commute radius.

Green flags: Posting on HN at all (most Tier-1 banks won't), willingness to consider remote, and framing the role around platform-building rather than ticket-closing.

Red flags: No compensation band, no team size, no named tech, "my group" phrasing suggests a single champion inside a bureaucracy — meaning if that manager leaves, the culture reverts. The weekly-in-person requirement will filter out the strongest remote candidates who by 2020 already had unconditional-remote offers from Stripe, GitLab, and Elastic.

For two decades, Linux managed page reclaim with a pair of lists per memory zone: active and inactive. On memory pressure, kswapd scanned the inactive list looking for cold pages. Accessed pages got promoted to active; unaccessed ones got evicted. Simple, but broken at scale: with 100+ GB of RAM, the scanner touched millions of PTEs sampling access bits, and the two-bucket resolution was too coarse to tell "used 5 minutes ago" from "used 5 hours ago." Result: hot pages evicted, cold pages retained, and reclaim latency spikes visible in tail latencies.

MGLRU (merged in Linux 6.1, 2022) replaces the two lists with a generational structure: typically 4 generations per memory type (anon/file), giving 8 buckets instead of 2. Each page has a small gen counter encoded in page->flags. On access, the page is promoted to the youngest generation; during reclaim, the oldest generation is evicted first. The key trick is bulk aging: instead of scanning individual pages, MGLRU walks page tables in sequence and uses the CPU's Accessed bit across whole PTE ranges at once, exploiting spatial locality in the mm_struct.

Concrete example. Meta reported using MGLRU on their web tier: a 512GB fleet running memcached-style workloads. Under old LRU, refault rate (pages evicted then re-read from disk within seconds) hit 8-12% during traffic spikes. With MGLRU, refaults dropped below 2% because the finer-grained aging correctly identified the working set. Same workload, same hardware, ~15% p99 latency improvement. Android also enabled MGLRU by default in 13+ because it reduced swap thrashing on 4GB phones.

The rule of thumb. Reclaim overhead in the old LRU scales roughly as O(RSS / working_set_size) — the more your working set fits, the more time you waste scanning warm pages. MGLRU's bulk PTE walk drops the constant factor by ~10x: instead of one ptep_test_and_clear_young() per candidate, one walk clears the A-bit across 512 PTEs (one 2MB region) at a time. On a 128GB machine, aging a full pass drops from ~300ms to ~30ms.

Tuning knobs (all under /sys/kernel/mm/lru_gen/): enabled toggles it; min_ttl_ms sets the minimum age before a page can be evicted (useful to prevent thrashing); the debugfs interface /sys/kernel/debug/lru_gen lets you force aging or eviction for testing. Watch /proc/vmstat's pgsteal_* and pgrefill_* counters — if refills exceed steals by wide margins, your working set exceeds RAM regardless of algorithm.

For thirty years, if you wanted to build an email client, you had two miserable choices: IMAP, a stateful, line-oriented protocol from 1986 that mutates its own grammar based on server capabilities, or POP3, which barely counts as email at all. Every mobile mail app on Earth spent enormous engineering effort papering over IMAP's quirks: no batching, no push (without the IDLE hack), no efficient sync, ambiguous UTF-8 handling, and a wire format that requires a bespoke parser. RFC 8620 is Neil Jenkins and Chris Newman's answer: throw out the wire protocol entirely, keep the data model, and build something a JavaScript developer could implement in an afternoon.

JMAP is the generic half of the spec — it defines the transport and object-manipulation semantics that email (RFC 8621), contacts, and calendars all layer on top of. The core idea: everything is a JSON object with an id, and clients talk to the server by POSTing batches of "method calls" to a single HTTPS endpoint. A method call is a tuple: [name, arguments, client-tag]. The server executes them in order and returns a matching list of responses.

Several design decisions are worth studying:

• Result references. The killer feature. A later call in the batch can reference the output of an earlier one using a JSON Pointer (RFC 6901) into the previous response. So "get my inbox, then get the first 20 messages in it, then get the thread each belongs to" is one HTTP request, not three round trips. This alone makes JMAP dramatically faster than IMAP on high-latency mobile networks.
• State strings and /changes. Every object type has an opaque state token. To sync, you send your last-known state and get back exactly which IDs were created, updated, or destroyed since then. No more IMAP's "compare UIDVALIDITY, then fetch flags for every UID, then diff." Sync becomes O(changes), not O(mailbox).
• Push via EventSource or WebSockets. No more IMAP IDLE with its one-connection-per-folder tax. A single push channel notifies you of state changes across every account.
• Uploads are separate. Binary blobs go through a dedicated upload endpoint and are referenced by blob ID in subsequent method calls, keeping the JSON layer clean.
• Capabilities are namespaced URIs. Extensions live at URIs like urn:ietf:params:jmap:mail, so vendors can add features without colliding — a direct lesson learned from IMAP's flat capability soup.

The backstory is telling. Jenkins is CTO of Fastmail, which had been running a proprietary JSON-over-HTTP protocol internally since roughly 2014 because IMAP simply could not deliver the responsiveness their web and mobile clients needed. Standardization took years, in part because the IETF EXTRA working group had to fight the instinct to just "fix IMAP again" (they'd done it many times — IMAP4rev1, then LEMONADE, then IMAP4rev2). JMAP won by not pretending to be IMAP at all.

Adoption in 2026 is quietly growing: Fastmail, Topicbox, Stalwart, Cyrus, and Apache James all speak JMAP; the JMAP for Calendars spec (RFC 8984 data model, RFC 8620 transport) is starting to displace CalDAV in new deployments; and there's a Contacts spec too. Gmail and Outlook still don't support it, which is JMAP's biggest problem — but every indie mail provider you'd actually want to use does.

Classic Paxos agrees on one value. But real systems—replicated logs, state machines, databases—need to agree on a continuous stream of values. Running full Paxos per value means two round trips of messages (Prepare/Promise, then Accept/Accepted) for every single decision. At 10ms cross-datacenter latency, that's 40ms per operation before you even touch disk. Multi-Paxos fixes this by recognizing a simple truth: if the same node keeps proposing, you don't need to re-run the Prepare phase every time.

The core insight: The Prepare phase exists to establish a proposer as the authority for a ballot number. Once a proposer wins Prepare for ballot b, it can use that same ballot for all future slots in the log until someone else runs a higher-ballot Prepare. So Multi-Paxos elects a stable leader, and that leader skips Prepare on every subsequent proposal—reducing the steady-state cost from 2 round trips to 1 round trip per decision.

How it works in practice:

• A node runs Prepare once for a ballot number, covering all log slots from position N onward.
• Acceptors promise not to accept lower-ballot proposals for any slot ≥ N.
• The leader now issues Accept messages directly for each new slot—no Prepare needed.
• If the leader dies, a new leader runs Prepare with a higher ballot and takes over.

Real-world example: Google's Chubby lock service uses Multi-Paxos. A single master handles all writes; replicas accept its proposals directly. When the master fails, a new election runs the expensive Prepare phase, but during normal operation—which is 99%+ of the time—every write is a single round trip. Spanner's Paxos groups work the same way: one leader per shard amortizes consensus across millions of transactions.

The rule of thumb: Multi-Paxos cuts steady-state message complexity from 4n messages per decision (Prepare+Promise+Accept+Accepted across n acceptors) to 2n messages (Accept+Accepted only). At a 5-node cluster with 10ms RTT, that's the difference between 40ms and 20ms per commit—a 2× throughput ceiling improvement, before batching.

The catch: Multi-Paxos requires a stable leader, which means you need a failure detector, leader election, and lease management. Split-brain scenarios where two nodes both think they're leader are handled by ballot ordering—the higher ballot wins, and the loser's in-flight proposals get rejected. But if leadership churns constantly, you pay Prepare costs repeatedly, and performance collapses toward single-decree Paxos.

Everyone reaches for iconv when a file arrives in the wrong encoding. Fewer people know that ICU — the Unicode library shipped with essentially every modern OS — comes with its own CLI, uconv, that does everything iconv does and transliteration between scripts, Unicode normalization forms, case folding, and arbitrary composable transform chains. It's usually one apt install icu-devtools away (brew install icu4c on macOS puts it in the keg).

The killer feature is the -x flag, which applies an ICU transform ID — or a whole pipeline of them separated by semicolons. Start with encoding conversion:

# The iconv equivalent — nothing special yet
uconv -f UTF-16BE -t UTF-8 windows-export.txt > clean.txt

Now the part iconv can't do. Transliterate between scripts using the CLDR transliteration tables:

$ echo "Ελληνικά" | uconv -x "Greek-Latin"
Ellēniká

$ echo "Москва" | uconv -x "Cyrillic-Latin"
Moskva

$ echo "北京欢迎你" | uconv -x "Han-Latin"
běi jīng huān yíng nǐ

$ echo "こんにちは" | uconv -x "Hiragana-Latin"
konnichiha

Yes, that's automatic Pinyin generation from Han characters, from a tool that's been on your box since you installed anything that links libicu. Need ASCII-safe filenames from user-supplied names in any script?

$ echo "café — Straße — Ω" | uconv -x "Any-Latin; Latin-ASCII"
cafe -- Strasse -- O

Two transforms, chained. The first normalizes any script to Latin; the second flattens Latin-with-diacritics to plain ASCII. If you want more control, do it manually with normalization plus a Unicode character-class filter:

# Decompose, drop combining marks, recompose
$ echo "café naïve résumé" | uconv -x "NFD; [:Nonspacing Mark:] Remove; NFC"
cafe naive resume

The [:Nonspacing Mark:] is a real Unicode property filter — you can use any of them ([:Punctuation:], [:Digit:], [:Emoji:]). Combine with the built-in case transforms:

$ echo "HELLO — WORLD" | uconv -x "Lower; [:Punctuation:] Remove"
hello  world

# Normalize URLs / cache keys
$ echo "  Café Society!  " | uconv -x "NFKC; Lower; Latin-ASCII" | tr -s ' '
 cafe society!

The normalization forms (NFC, NFD, NFKC, NFKD) matter more than most developers realize — a file named café.txt from macOS Finder (NFD, e + combining acute) will not string-compare equal to café.txt from a Linux terminal (NFC, single precomposed é). uconv -x NFC makes this go away.

You can write transforms inline with the CLDR rule syntax too — useful for one-off munging:

$ echo "hello world" | uconv -x "::Lower; [aeiou] > '*';"
h*ll* w*rld

List every transform your ICU version knows about:

$ uconv -L | head
Accents-Any
Amharic-Latin/BGN
Any-Accents
Any-Publishing
Arabic-Latin
Arabic-Latin/BGN
...

There are hundreds. Fullwidth-Halfwidth flattens those East Asian full-width ASCII characters that show up in copy-pasted spreadsheets. Any-Publishing converts -- to em-dashes and "..." to smart quotes. Any-Hex/Unicode gives you \u00e9-style escapes on demand.

Where iconv tops out at "byte sequence A becomes byte sequence B," uconv gives you the full Unicode processing pipeline as CLI text filter. If you've ever hand-rolled a Python script to strip diacritics or normalize weird input, delete it.

The hydraulic ram pump is one of engineering's most delightful anachronisms: invented by Joseph Michel Montgolfier in 1796, it uses water hammer — the shockwave from suddenly stopping a moving column of water — to punch a fraction of its input up to a much higher elevation. No electricity. No fuel. Two moving valves. They still run today in Nepalese villages after 40 years of service.

The trick: let water flow down a "drive pipe" until momentum builds, slam a waste valve shut, and the resulting pressure spike (hundreds of kPa in milliseconds) forces a small slug of water through a check valve into a pressurized delivery line. Repeat 60–120 times a minute.

The physics of one ram. Energy conservation gives us the ceiling: Q_out × H_out = η × Q_in × H_in, where η is roughly 0.6 for a well-tuned brass ram. So with a drive head of 10 m and a lift head of 100 m (a 10× ratio, well within the practical envelope of 5–25×), you deliver 6% of your input flow to the top.

Now stack them. Picture an Andean valley: a glacial stream at 1500 m elevation with 500 L/s of flow. We want to irrigate a plateau at 4500 m — a 3000 m lift. No transmission lines, no fuel drops. Just cast-iron rams every 300 m of vertical rise, each fed by a tributary or side channel diverted around the previous stage:

• Stage 1 (1500 → 1800 m): 500 L/s drive at 30 m head lifts 500 × 30/300 × 0.6 = 30 L/s to 1800 m.
• Stage 2 (1800 → 2400 m): the 30 L/s joins a smaller tributary providing another 200 L/s drive. Ram delivers ~14 L/s to 2400 m.
• Stage 3 (2400 → 3200 m): fed by 100 L/s of local snowmelt plus stage 2 output. Delivers ~7 L/s.
• Stage 4 (3200 → 4500 m): the final push, dependent on whatever headwater exists. Realistic yield: 1–2 L/s at the plateau.

That's ~130,000 L/day of clean water raised 3 km with zero grid input — enough to drip-irrigate 5 hectares of high-altitude potato terraces, or supply 600 people at WHO minimum.

The materials problem. Stage 4's delivery pipe sees 4500 − 3200 = 1300 m of static head between pump strokes and a transient water-hammer spike of maybe 2× that. Peak pressure: ~26 MPa. Schedule 80 steel handles it, but the pipe wall must be ~15 mm thick — around 55 kg per meter. For 300 m of vertical run, that's 17 tonnes of steel per stage, mule-packed in sections.

Why not just one giant ram? Because a single-stage 3000 m lift needs a drive pipe kilometers long to develop coherent water-hammer momentum, and the pressure spike scales as ΔP = ρ·c·Δv ≈ 1000 × 1400 × 2 = 2.8 MPa per m/s of velocity change. Slamming a 5 m/s column would produce 14 MPa transients — survivable — but the acoustic wave travel time down a 3 km pipe is 2+ seconds, ruining the pump cycle. Physics forces you to stage it.

Losses that don't show up on the napkin: air entrainment during the recoil stroke, valve wear from cavitation on the low-pressure side, and winter freeze in the pressure vessel. Nepal's rams average 2% annual failure rate — trivial for something with no motor.

In 2005, the US Navy leased a Swedish submarine — and it promptly humiliated them. During war games off the coast of California, the tiny HSwMS Gotland repeatedly "sank" the nuclear-powered aircraft carrier USS Ronald Reagan, slipping past its destroyer screen, its sonar net, and its ASW helicopters to surface photographs of the carrier's hull as trophies. The Reagan is a 100,000-ton floating city with a crew of 5,000. The Gotland is a 1,600-ton diesel-electric boat with a crew of 25. How?

The answer sits at the intersection of two technologies you would not expect to meet: a 19th-century Scottish minister's heat engine and modern stealth submarine warfare.

Every submarine faces the same brutal tradeoff. Nuclear boats can stay underwater for months but their reactors are noisy — cooling pumps, steam turbines, reduction gears. Diesel-electric boats are whisper-quiet when running on batteries, but they have to "snorkel" every day or two to run their diesels and recharge — the moment they poke a mast above the waves, radar and infrared sensors can find them.

The Gotland-class solved this in 1996 by bolting on a pair of Kockums v4-275R Stirling engines. Stirling engines are external combustion — they don't ingest air like a diesel, they just need a temperature differential. The Gotlands burn liquid oxygen and diesel fuel in a sealed combustion chamber to heat one side of the engine; seawater cools the other. The result:

• The sub can sit submerged for two weeks straight without snorkeling
• It runs almost silently — no explosions, no reciprocating pistons hammering at a crankshaft
• The exhaust dissolves harmlessly into seawater at depth

This is called Air-Independent Propulsion (AIP), and the Gotlands were the first production submarines in the world to have it. Robert Stirling patented his engine in 1816 as a safer alternative to explosion-prone steam boilers in Scottish quarries. Two centuries later, his design — beloved by hobbyists for running on the heat of a hand — turned out to be the ideal way to hide a warship.

The reason the US Navy leased the Gotland for two full years (2005–2007) is that they couldn't figure out how to detect it in their own exercises. American ASW doctrine had been optimized for hunting loud Soviet nuclear boats during the Cold War. A quiet, cheap, Stirling-powered diesel submarine represented a category of threat the Navy had let atrophy — and every rising naval power (China, Russia, Japan, Germany, South Korea) was now buying AIP boats.

The lease was, essentially, the US Navy paying Sweden to teach it how to lose.

Most Tucson residents have never heard of Up With People, yet it may be the city's largest cultural export. This mini-documentary from the UWPIAA (the alumni association's own channel) digs into the origins of a genuinely strange piece of 20th-century Americana: a globe-trotting youth performance troupe founded in the 1960s that grew out of the Moral Re-Armament movement, toured Cold War Europe, headlined multiple Super Bowl halftime shows, and quietly headquartered itself in the Arizona desert.

The film focuses on the 2017 cast's Tucson run, but uses that as an entry point to explain what the organization actually is — how it recruits young performers from dozens of countries, how the touring model works, and why a program with that kind of reach remains almost invisible to the city that hosts it. Because it's produced by alumni rather than a marketing team, you get more candor about the group's odd history and its cultural footprint than a promotional piece would offer.

It's a rare look at an institution that shaped thousands of lives across generations but rarely gets serious documentary treatment. Worth watching if you're interested in the mechanics of touring performance groups, mid-century American cultural diplomacy, or hidden-in-plain-sight local history.

This demo sits at a genuinely interesting intersection: Binarized Neural Networks (BNNs) running on an Altera DE10-Standard FPGA to classify hand-drawn sketches in real time. BNNs are a fascinating optimization for edge AI — instead of using 32-bit floating point weights, they constrain weights and activations to just +1 or -1. That single design choice lets multiply-accumulate operations collapse into XNOR and popcount, which FPGAs execute with almost no resource cost.

What makes this worth watching beyond the "look, AI on hardware" novelty is the concrete demonstration of an edge AI accelerator pipeline: capturing sketch input, feeding it through a custom hardware inference engine, and getting classification results without a CPU in the critical path. For anyone learning FPGA design, this is a useful case study in how you'd map a real ML workload onto programmable logic — and how binarization makes previously-impractical models fit onto mid-range dev boards.

The creator has just 5 subscribers, so this is genuinely early work from someone building in the open. Expect a rough presentation, but the underlying project (a working BNN accelerator with a live demo) is more substantial than most tutorial content from much larger channels. Good watch if you're curious about quantization, hardware acceleration, or the DE10-Standard as a platform for HPS+FPGA experiments.

Most heat-exchanger content on YouTube stops at the animation stage: two fluids, counter-flow arrows, done. This video from a tiny industrial-operations channel goes further by pairing the working principle of a plate heat exchanger with the two maintenance tasks that actually determine whether a PHE keeps working in the field: plate cleaning and gasket replacement.

PHEs are everywhere in process plants — dairy pasteurization, chemical cooling loops, and especially Zero Liquid Discharge (ZLD) systems, which the description explicitly calls out. Their advantage over shell-and-tube designs is enormous surface area in a compact frame, but that same tight geometry means they foul quickly and the elastomer gaskets between every plate are a constant failure point. Understanding how to disassemble the plate pack, chemically clean the corrugated plates without warping them, and reseat gaskets correctly (orientation matters — a flipped gasket cross-contaminates the two fluid circuits) is genuinely useful knowledge for anyone working in process engineering or plant maintenance.

The video is in Hindi, which limits the audience, but for viewers who can follow along it offers the kind of hands-on operational content that English-language engineering channels rarely produce — real equipment, real maintenance, not a stock 3D render.

Taper jigs are one of those shop-made tools that separate hobbyist table saw work from furniture-grade results. Cutting a taper on a table saw without a jig is genuinely dangerous — the workpiece isn't parallel to the fence, so it wants to bind and kick back. A well-built jig turns that hazardous cut into a repeatable, precise operation, which is why every serious woodworker eventually builds one.

What makes this video worth watching is the context: Linus is building it for an actual furniture project, not as a standalone tutorial. That framing tends to produce better jigs, because the design decisions — clamping location, adjustment range, reference edge — are driven by the real cuts they'll need to make rather than generic requirements. You get to see the tradeoffs a working maker actually navigates.

At under 1k subscribers, Crafted By Linus is exactly the kind of small channel where you often see more honest, less over-produced shop work. Expect to learn about registering the workpiece against an adjustable fence, the geometry of setting a taper angle, and the hold-down details that keep fingers away from the blade. If you've ever wanted to taper table legs or chair stiles, this is foundational shop infrastructure.

Slim pickings this week — the feed is heavy on hashtag-spam shorts and silent lathe loops. This project video from a brand-new channel (literally zero subscribers at time of posting) is the standout because it commits to a defined, finished object rather than just showing a spindle spinning.

Turning a sphere on a manual or CNC lathe is a genuinely instructive exercise. Unlike cylindrical or tapered work, a true ball requires either a dedicated ball-turning attachment, careful use of the compound slide swept through an arc, or CAM toolpaths that blend across the equator without leaving a visible seam. Doing it in stainless steel raises the difficulty further — 304 and 316 work-harden fast, chatter easily on interrupted cuts, and demand slow speeds with heavy positive-rake tooling. Adding a brass component (presumably an inlaid "8" or a hemisphere joint) introduces the classic dissimilar-metal challenge of dialing feeds and speeds between a gummy, hard alloy and a free-machining one within the same setup.

If the creator actually walks through the geometry and toolpath choices, this is a nice worked example of precision turning fundamentals. Worth a look to support a new channel doing real project work rather than clip farming.