Daily Digest — 2026-05-13

This function strips every occurrence of a character from a string in place. It compiled cleanly, passed unit tests on the developer's laptop, and shipped to a fleet of newer servers — where it started producing garbled output. What's wrong?

#include <string.h>
#include <stdio.h>

/* Remove every occurrence of c from s, in place. */
void remove_char(char *s, char c) {
    size_t len = strlen(s);
    for (size_t i = 0; i < len; i++) {
        if (s[i] == c) {
            /* shift the tail left by one, including the '\0' */
            memcpy(&s[i], &s[i + 1], len - i);
            len--;
            i--;
        }
    }
}

int main(void) {
    char buf[] = "hello world";
    remove_char(buf, 'l');
    printf("[%s]\n", buf);   /* expected: [heo word] */
    return 0;
}

The Bug

The source and destination passed to memcpy overlap: we're copying &s[i+1] down to &s[i], a one-byte slide. Section 7.24.2.1 of the C standard is explicit: if the regions overlap, behavior is undefined. Not "implementation-defined," not "works if you're careful" — undefined.

For decades this code appeared to work because glibc's memcpy was a byte-by-byte forward loop, which happens to do the right thing when copying down by one. Developers wrote production code on this accident. Then glibc grew SIMD implementations (SSE, AVX, ERMS-optimized rep movsb) that read a 16- or 32-byte chunk from the source before writing it to the destination. With a one-byte overlap, the second chunk's source bytes have already been overwritten by the first chunk's write. The output becomes mojibake — or, with bigger overlaps, repeats a block of source bytes verbatim.

It gets worse. The compiler is allowed to assume the regions don't overlap. GCC and Clang can vectorize, reorder, or replace the call entirely under that assumption. Sanitizers like UBSan and Valgrind's memcheck will flag the overlap, but only if you run them.

The fix is the function that exists precisely for this case: memmove. It detects overlap and chooses copy direction (or buffers internally) to produce the result as if the source were copied to a temporary first.

void remove_char(char *s, char c) {
    size_t len = strlen(s);
    for (size_t i = 0; i < len; i++) {
        if (s[i] == c) {
            memmove(&s[i], &s[i + 1], len - i);
            len--;
            i--;
        }
    }
}

Two related traps lurk nearby. First, strcpy(dst, dst + 1) has the same defect — the C library's string functions also forbid overlap unless their name says otherwise (memmove is the lone exception in the classic set). Second, this whole algorithm is O(n²); a single-pass read/write cursor would be both correct and faster:

void remove_char(char *s, char c) {
    char *w = s;
    for (char *r = s; *r; r++)
        if (*r != c) *w++ = *r;
    *w = '\0';
}

The two-cursor version is overlap-safe by construction: w never gets ahead of r, so each byte is read before it's overwritten. No memcpy, no memmove, no UB.

Rule of thumb: if the source and destination of a mem-family call could possibly touch the same bytes, reach for memmove. The performance gap on modern glibc is negligible; the correctness gap is infinite.

Every ADC, DAC, voltage regulator, and brown-out detector needs a reference voltage that doesn't drift with temperature or supply variation. A resistor divider won't do — it tracks the supply. A Zener diode is too noisy and varies with temperature. The clever trick used in nearly every analog chip since 1971 is the bandgap reference, which generates ~1.25V by canceling two opposing temperature coefficients against each other.

The physics: a forward-biased PN junction's voltage V_BE drops about −2 mV/°C as temperature rises (it's "complementary to absolute temperature," or CTAT). Meanwhile, the difference between two junctions running at different current densities — ΔV_BE — increases with temperature at +0.087 mV/°C per decade of current ratio (proportional to absolute temperature, or PTAT). Both come from the same Boltzmann statistics, just with opposite signs.

The Brokaw cell — the canonical implementation — sums these:

• One transistor Q1 with emitter area A at current I
• Another transistor Q2 with emitter area nA (typically n=8) at the same current
• The current density ratio creates ΔV_BE = (kT/q)·ln(n) across a resistor
• An op-amp forces both collector currents equal via feedback
• The output sums V_BE(Q1) + K·ΔV_BE, where K is set by the resistor ratio

Pick K so the slopes cancel: K · 0.087 mV/°C · ln(8) ≈ 2 mV/°C, which gives K ≈ 11. The result lands at approximately the silicon bandgap energy at 0K — 1.205V — hence the name. Real designs trim resistors to hit 1.225V where the curve is flattest.

Real-world example: The Texas Instruments REF200 and the LM4040 are pure bandgap references. But more importantly, every microcontroller you've used has one inside. The ATmega328P (Arduino Uno) has an internal 1.1V bandgap you can route to the ADC as analogReference(INTERNAL). Its spec: 1.0V to 1.2V across parts, but ±3% over −40°C to +85°C for a single chip after calibration. That stability lets battery-powered devices measure their own supply voltage by comparing V_CC to the bandgap.

Rule of thumb: An untrimmed bandgap drifts about 50–100 ppm/°C (5–10 mV across 100°C). A trimmed and curvature-compensated bandgap hits 10 ppm/°C — competitive with a discrete precision reference. But bandgaps need startup circuits: there's a degenerate equilibrium at zero current the op-amp is happy to sit in forever, so a tiny "kick" transistor injects current at power-up to nudge the loop into its real operating point.

Every dimension on a drawing carries a tolerance — the allowable deviation from nominal. A shaft called out as Ø10.00 ±0.05 mm can legitimately measure anywhere from 9.95 to 10.05 mm and still pass inspection. When parts assemble in series, those individual tolerances accumulate. Ignore the math and you'll ship assemblies that bind, rattle, or refuse to mate.

Worst-case (arithmetic) stack: Add nominals; add tolerances. Five blocks each 20.0 ±0.1 mm stacked end-to-end give a total of 100.0 ±0.5 mm. This is the conservative method — it guarantees fit even if every part is at its worst extreme simultaneously. Use it for safety-critical interfaces, low-volume builds, and anywhere a failure means rework.

Statistical (RSS) stack: Real parts cluster near nominal; all five being at the extreme limit at once is vanishingly rare. Root-Sum-Square treats tolerances as standard deviations: T_total = √(T₁² + T₂² + ... + T_n²). For the same five blocks: √(5 × 0.1²) = 0.224 mm. That's less than half the worst-case envelope. RSS is appropriate for high-volume production where process capability (Cpk) is known and a small reject rate is acceptable.

Real-world example: A bearing-shaft assembly. The housing bore is Ø52.00 +0.030/-0.000, the bearing OD is Ø52.00 +0.000/-0.013, and the shoulder depth tolerance is ±0.05 mm. Worst case, the bearing has 0.043 mm of radial clearance instead of the intended light press fit — the inner race spins under load, galls the shaft, and the unit fails in service. Engineers caught this kind of stack-up failure in early jet engine accessory drives; modern GD&T (geometric dimensioning and tolerancing) exists largely to prevent it.

Rules of thumb:

• Tight tolerances cost money exponentially. A ±0.5 mm feature is cheap; ±0.005 mm needs grinding and inspection.
• If a worst-case stack fails, don't tighten every tolerance — find the one dimension contributing most and tighten only that.
• Use datums intelligently. Stacking from a single reference face beats chaining dimensions part-to-part.
• Always check both maximum material condition (MMC) and least material condition (LMC) — interference fails at MMC, clearance fails at LMC.
• For ten or more components in series, RSS is essentially mandatory; worst-case becomes absurdly pessimistic.

Software engineers will recognize the pattern: tolerance stack-up is the mechanical analog of floating-point error accumulation in long computations. Each operation is "correct" within its specified precision, but compose enough of them and the result drifts outside acceptable bounds.

Tucked between a cure for "Bad Appetite" and an "Aperient Mixture" sits one of the more surprisingly defensible folk remedies of the Edwardian era. Under the heading Asthma, the anonymous compiler lays out a complete regimen:

Asthma. Live chiefly on Boiled Carrots or Leeks. Take pint New Milk night and morning. Boil in two quarts of water for half hour one packet Hyssop, Liquorice Root, Horehound and Vervain, strain and when cold add two ounces Vinegar, half ounce Tincture of Lobelia, and half pound Honey. Take wineglassful freely.

The book itself is a curiosity of door-to-door publishing. A printed slip on the cover reads "This book is left for your inspection and will be called for to-morrow" — the Recipe Co. of Bulwell, Nottingham, sold these as sixpenny pamphlets, deliberately undercutting chemists who, the compiler complains, would rather sell you "a bottle already made up for about 2s. 6d." than the raw ingredients.

What's striking is that nearly every component of that syrup has subsequent pharmacological evidence behind it:

• Tincture of Lobelia — Lobelia inflata contains lobeline, a nicotinic receptor agonist that acts as a respiratory stimulant and mild bronchodilator. It was a mainstream asthma drug well into the 20th century and only fell out of favor when better-targeted beta-agonists arrived.
• Horehound (Marrubium vulgare) — Still licensed in Germany's Commission E monographs as an expectorant; marrubiin loosens bronchial secretions.
• Liquorice root — Glycyrrhizin has documented anti-inflammatory effects in airway tissue.
• Hyssop and Vervain — Both contain volatile oils with mild antispasmodic activity on smooth muscle.
• Honey — A 2021 BMJ Evidence-Based Medicine review concluded honey outperforms standard care for upper respiratory cough symptoms.

So the syrup, taken on its own, was a credible bronchodilator-plus-expectorant-plus-demulcent stack — essentially a Victorian approximation of what a modern cough preparation tries to do, minus the targeted beta-2 selectivity.

The dietary half is where things get speculative-but-interesting. "Live chiefly on Boiled Carrots or Leeks" sounds like nonsense until you notice that both are high in quercetin, a flavonoid that stabilizes mast cells and inhibits histamine release. There's ongoing research into quercetin as an adjunct for allergic asthma. The pint of new milk twice daily is harder to defend — modern asthma guidance is more cautious about dairy, though the evidence for outright avoidance is thinner than commonly believed.

The real lost wisdom here isn't any single ingredient — it's the assumption that a chronic condition deserved a multi-pronged daily protocol combining diet, a maintenance syrup, and lifestyle. That structure looks remarkably like how a modern respiratory specialist actually manages asthma: controller medication plus rescue inhaler plus trigger avoidance. The 1909 compiler had the architecture right, even if the pharmacy was primitive.

The title page promises something audacious: a "practical treatise on a new process of printing in pigment especially suitable for pictorial workers." In 1901, photography was barely sixty years old and still fighting for status as art. The opening advertisements give away the mood of the era — cameras sold on military pedigree:

BENETFINK LIGHTNING HAND CAMERAS. RELIABLE IN ACTION. NO COMPLICATIONS. EASY TO USE. AS USED IN THE BOER WAR.

But the real forgotten knowledge is in the title itself: the gum-bichromate process. Alfred Maskell and Robert Demachy were leading lights of Pictorialism, the turn-of-the-century movement that insisted photographs could be paintings. Their recipe: coat watercolor paper with a slurry of gum arabic, artist's pigment, and potassium bichromate. Dry it in the dark. Lay a negative on top, expose to sun. Where light hits, the bichromate cross-links the gum into an insoluble matrix that traps the pigment; everywhere else, a warm-water bath washes the gum (and pigment) away. Repeat with new colors for full-color prints. The photographer could brush, scrub, or smudge the wet emulsion mid-development — a photograph you could literally paint.

The results looked like Whistler etchings. Demachy's nudes and landscapes hang in museums today, and almost no one alive can read the recipe in this book and reproduce them without weeks of trial and error. The chemistry is finicky, the materials (especially the dichromates) are nasty carcinogens, and silver gelatin printing made it obsolete by the 1920s.

Here is the surprising part. That exact chemistry — a colloid plus a chromium salt that hardens on exposure to UV light — is the direct ancestor of every photoresist used in modern manufacturing:

• Printed circuit boards are still etched using photoresists descended from dichromated gelatin.
• Screen-printing emulsions (the t-shirt on your back) work on identical principles.
• The first integrated circuits at Fairchild Semiconductor in 1959 used photoresists chemically continuous with Maskell and Demachy's gum.
• Even your passport hologram traces its lineage to dichromated gelatin holography.

A delicious cross-reference from the other documents in the archive: a 1955 CIA report lists the chemicals Communist China was desperate to import, including "potassium bichromate" and "sodium bichromate" — the same sensitizers Maskell specified for soft-focus art prints fifty years earlier. By then the chemical had quietly migrated from the salon to the factory floor.

Pictorialist photographers thought they were rescuing photography from mechanical sterility. They didn't realize they were perfecting the very technique that would later be used to print transistors a thousand at a time onto silicon.

In 1902, a German physicist named Arthur Korn filed a patent for what he called the Bildtelegraph — a machine that could transmit photographs over ordinary telegraph wires. By 1907, he had refined the system enough to send a photograph of the Crown Prince of Germany from Munich to Berlin to Paris to London, a distance of over 1,800 kilometers. The image arrived in roughly twelve minutes. Newspapers across Europe printed it the next morning. The patent — filed in Germany and later in the US as US Patent 1,030,427 ("Apparatus for the Electric Transmission of Pictures") — quietly invented the entire field of facsimile communication.

The mechanism was beautifully clever. Korn wrapped a photographic transparency around a rotating glass cylinder. A point source of light shone through the spinning image onto a selenium photocell — selenium's resistance varies with light intensity, a property discovered in 1873. As the cylinder rotated and slowly translated along its axis, the photocell read out the image as a continuous helical scan, converting brightness into a varying electrical current. At the receiving end, that current modulated a light source aimed at a second rotating cylinder wrapped in photographic paper, synchronized via tuning forks. Bright pixels became bright spots; dark pixels became dark spots. The image rebuilt itself line by line, thousands of kilometers away.

Every element of modern raster image transmission is already present:

• Raster scanning — the helical sweep is functionally identical to how a CCD sensor reads pixels row by row, or how an inkjet printer lays down lines.
• Photoelectric digitization — selenium was a primitive but real analog-to-electrical converter, the great-grandparent of every CMOS sensor in every phone camera.
• Synchronized sampling — Korn's tuning-fork synchronization is the same problem solved today by pixel clocks and frame-sync signals in HDMI.
• Long-distance image transmission over existing infrastructure — sending pictures over telegraph wires is the conceptual seed of sending JPEGs over copper telephone lines (dial-up modems) and, ultimately, fiber.

The commercial impact was immediate and enormous. By 1910, Korn's system was being used by European newspapers to share wire photos. The technology was licensed to the French police, who used it to transmit mugshots between cities — the first photographic identity database operating at electrical speed. AT&T's Bell Labs adapted the same principles for the 1924 transatlantic photo service, and the Associated Press launched its famous Wirephoto network in 1935 using direct descendants of Korn's scheme.

Fast-forward: the office fax machine boom of the 1980s, which seemed like a sudden new technology, was Korn's invention with the selenium swapped for a CCD and the tuning fork swapped for a quartz crystal. The medical world quietly kept using it — modern teleradiology (sending X-rays between hospitals) descends directly from the same scanning logic. Even the line-by-line progressive rendering you still occasionally see on slow JPEGs in a browser is, conceptually, Korn's helical scan playing back in real time.

What makes Korn's patent astonishing is the date. In 1902, the Wright Brothers had not yet flown. Einstein had not yet published special relativity. Radio was a novelty. And a Bavarian physics professor had already built a working pipeline for transmitting digital-style raster images over a continent-spanning network — a century before anyone would think to call it "image messaging."

This repo tackles one of the most tedious parts of QA work: writing test cases from scratch. The project promises to generate and manage test cases using AI, with compliance checks built in and export support for multiple formats. Looking at the topic tags, it's clearly aiming to be more than a toy — it pulls together a serious stack: .NET/C# core, TypeScript, Node.js, PostgreSQL, Selenium, and an MCP server.

What makes this one stand out from the wave of "AI does X" repos is the MCP integration. Model Context Protocol is still relatively new, and seeing it applied to test case generation suggests the author is thinking about how QA engineers will actually plug AI into their existing toolchains rather than building yet another standalone chat interface. The mention of TestRail in the topics hints at real enterprise QA workflow integration — TestRail is the dominant test management platform in many shops, and bridging AI-generated cases into it is a genuinely valuable problem.

The combination of BDD, Selenium, and test-case generation also suggests an ambition to cover both human-readable specifications (Gherkin-style scenarios) and executable automation. That's a hard span to cover well, but if the author pulls it off, it could meaningfully shorten the gap between requirements and running tests.

Who would benefit:

• QA engineers drowning in regression test maintenance who want an AI assistant that speaks their toolchain
• Test leads evaluating MCP-based AI integrations for their team
• .NET developers curious about combining C# backends with LLM-powered tooling
• MCP enthusiasts looking for non-obvious applications of the protocol beyond coding agents

It's early days — zero stars, likely pre-release — but the topic breadth signals serious intent rather than a weekend hack.

Compilers emit instructions one at a time, but modern CPUs are smarter than that. Instruction fusion is the hardware trick where the front-end detects pairs of adjacent instructions that always travel together and merges them into a single micro-op (µop) that flows through the pipeline as one entity. Fewer µops means less pressure on the reorder buffer, fewer scheduler entries consumed, and one retirement slot instead of two.

There are two flavors, and they happen at different stages:

• Macro-op fusion: combines two architectural instructions before decode. The canonical example is cmp + jcc (compare followed by conditional jump). Intel has done this since Core 2; AMD since Bulldozer. The decoder sees cmp rax, rbx followed by jne label and emits one fused compare-and-branch µop.
• Micro-op fusion: combines two internal µops from a single complex instruction (like a load-op pair from add rax, [rbx]) so they share a single ROB entry but still dispatch to two execution ports.

Concrete example. Consider a tight loop counter:

loop:
  dec rcx
  jnz loop

Without fusion, that's 2 µops per iteration. With macro-op fusion (which works for dec/jcc, sub/jcc, and/jcc, test/jcc, cmp/jcc), it becomes 1 fused µop. On a 4-wide retire CPU, this doubles your effective loop throughput from 2 iterations/cycle to 4 iterations/cycle — assuming the branch predictor cooperates.

Rule of thumb. If your hot loop's IPC seems suspiciously high (say, 5 IPC on a 4-wide machine), fusion is the explanation. Measure UOPS_RETIRED.MACRO_FUSED via perf: perf stat -e uops_retired.macro_fused ./your_program. Ratio of fused to total retired µops above ~10% is common in branch-heavy code.

Constraints that bite.

• The two instructions must be adjacent in the instruction stream — a stray nop between them kills fusion.
• Not all jcc conditions fuse on all CPUs. Older Intel parts only fused unsigned conditions with cmp/test.
• The pair must fit within a single 16-byte (or 32-byte) fetch window on some microarchitectures.
• Memory operands in the arithmetic instruction disable macro-op fusion on most x86 designs.

This is why hand-rolled assembly that schedules cmp far from its jcc "for ILP" is usually slower than the naive adjacent form — you've forfeited a free µop.

Sparklines — those tiny, word-sized charts Edward Tufte introduced in Beautiful Evidence — are one of the most useful and least-used data visualization primitives on the web. They belong inline with prose, in tables, in status dashboards: anywhere a number alone is too sparse and a full chart is too heavy. Yet most implementations reach for Chart.js, D3, or a npm package with a build step, all to render what is fundamentally a polyline connecting a handful of points.

Terence Eden's post on shkspr.mobi cuts through that. Based on the title and his usual style, this is almost certainly a walkthrough of how to generate sparklines with nothing more than a hand-written SVG <polyline> element — no JavaScript runtime, no charting library, no canvas, no React component tree. The viewBox attribute does the scaling for you. A few coordinates and a stroke color give you a chart that:

• Renders identically in RSS readers, email clients, and static sites
• Has zero JavaScript attack surface and zero layout shift
• Scales crisply with the surrounding font size when you use em units
• Compresses well under gzip because it's just text
• Works inside an <a> tag, an <li>, or inline with running text

Why this matters to a technical audience: there's a recurring lesson here about the gravitational pull of frameworks for problems that aren't framework-shaped. A sparkline is roughly 200 bytes of SVG. The popular npm sparkline packages ship hundreds of kilobytes of JavaScript and pull in transitive dependencies that occasionally get hijacked. The "stupidly simple" approach isn't a step backward — it's the actual right tool for the job, and a useful reminder that the web platform has quietly become powerful enough that a lot of widgets we reach for libraries for can be written by hand in an afternoon.

Eden's blog has a long history of these "you don't need a library for this" posts, and they tend to be both correct and immediately useful. Drop the snippet into a Jinja template, a Hugo shortcode, or a server-rendered status page, and you've eliminated a dependency forever.

Of the ten postings, Nines (ID: 22672013) is the most revealing because of what it doesn't say. There's no stack list, no framework name-drop, no "we use Kubernetes and Rust." Instead, the entire posting is a founder-and-investor pedigree pitch: David Stavens (ex-Udacity, Stanford self-driving), Accel, 8VC. That absence is the signal.

1. The implied stack. Radiology AI in 2020 means a PyTorch/TensorFlow imaging pipeline, DICOM ingest, GPU inference clusters, and a HIPAA-compliant cloud (almost certainly AWS with BAAs). The fact that they don't bother listing it suggests they're hiring for judgment, not framework familiarity — they want people who can architect a regulated medical imaging system from scratch, not plug into an existing one.

2. Stage and direction. "First-of-its-kind radiology service" combined with "our radiologists and engineers" tells you Nines is vertically integrated — they employ the radiologists, not just sell software to them. That's a much harder business than a pure SaaS play: they're competing with teleradiology incumbents (Nighthawk, vRad) on service quality while simultaneously building the tooling. The Stavens/Waymo lineage hints they intend to apply ML to reads, but they're carefully not promising "AI radiologist" — likely because FDA clearance for autonomous diagnosis is still a multi-year slog.

3. Skills and trends highlighted.

• Vertical integration as a strategy — owning the service layer to generate proprietary training data is the 2020 ML moat playbook.
• Founder-led recruiting — the entire pitch is "come work with Stavens," which works when you're pre-Series-B and selling on optionality.
• Generalists over specialists — "Software Engineers" with no level, no specialization, no stack. They want builders.

4. Flags.

• Green: Iconic investors with healthcare exits (Oscar via 8VC), credible technical founder, mission with obvious patient impact.
• Green: Palo Alto onsite during a thread where most COVID-era postings are scrambling to claim "remote until post-COVID" — confidence in their working model.
• Yellow: No salary band, no team size, no engineering blog link. The pitch leans almost entirely on pedigree, which works for the first 10 hires but stops scaling around #30.
• Yellow: "Best radiologists deliver the best patient care" is a thin product thesis — what's the actual wedge versus existing teleradiology?

A cache miss to DRAM costs ~100ns — roughly 300 cycles on a 3GHz CPU. The CPU's hardware prefetcher tries to hide this latency by detecting access patterns and pulling cache lines in before you ask for them. But it only handles predictable strides: sequential walks, fixed offsets, and simple 2D patterns. The moment your code chases pointers, hashes into a table, or walks a tree, the prefetcher gives up and you pay full DRAM latency on every miss.

That's where software prefetching comes in. On x86, the PREFETCHT0, PREFETCHT1, PREFETCHT2, and PREFETCHNTA instructions tell the CPU to start loading a cache line into L1, L2, L3, or non-temporally (bypassing cache pollution). They're hints — they don't fault, don't block, and don't even trap on bad addresses. In C, GCC and Clang expose this as __builtin_prefetch(addr, rw, locality).

The real-world win: linked-list traversal. Consider summing values from a linked list of 10 million nodes scattered across the heap:

• Naive loop: each node = node->next stalls ~100ns waiting for the next cache line. 10M × 100ns = 1 second.
• With prefetch-ahead: __builtin_prefetch(node->next->next) issued while processing the current node. The next-next node is fetched in parallel with current work.

In production, a well-tuned prefetch distance on pointer-chasing code typically yields 1.5x–3x speedup. Postgres uses this in btree scans; the Linux kernel uses it in list_for_each on hot paths; ClickHouse uses it in hash join probes.

Rule of thumb for prefetch distance: prefetch N iterations ahead, where N ≈ memory_latency / per_iteration_work. If your loop body takes 20ns and DRAM latency is 100ns, prefetch 5 iterations ahead. Too close and the line hasn't arrived; too far and it gets evicted before use, or you prefetch past valid data and pollute cache with garbage.

When NOT to prefetch:

• Sequential access — the hardware prefetcher already handles this, and software prefetch just wastes issue slots.
• Tight loops where the data is already L1-resident — you're adding instructions for no benefit.
• When you can't predict the address far enough in advance (e.g., the address itself requires a cache miss to compute).

Verify with perf stat -e L1-dcache-load-misses,LLC-load-misses before and after. If LLC misses don't drop, your prefetch is either too late, too early, or targeting addresses the hardware prefetcher already caught.

The original poster has the basics of schematic reading down — they know the symbols and can trace a layout — but they're asking the question that separates hobbyist scribbles from documents an engineer can hand to a colleague five years later: how do you draw schematics properly and professionally? They specifically ask about international standards, where to learn, and the unwritten rules.

The thread is a goldmine because experienced engineers chime in with the conventions that nobody formally teaches you. A few of the highest-signal points that surface:

• Signal flow goes left-to-right, power top-to-bottom. Inputs on the left, outputs on the right, positive rails up, ground down. Violating this makes schematics feel "wrong" even to readers who can't articulate why.
• Standards exist: IEEE 315 and IEC 60617 define symbols; IPC-2612 covers schematic documentation practice. ANSI/IEEE conventions dominate in the US; IEC symbols in Europe and most of the rest of the world. Mixing them in one drawing is a tell of an amateur.
• Don't route signals through pins. Pins of a component shouldn't have wires crossing through them; bring traces to the pin and stop. Net labels beat long wandering wires — once a schematic crosses a page boundary or has more than a couple of crossings, labels are clearer than lines.
• No four-way junctions. Always offset T-junctions so a dot is unambiguous. A missed dot at a four-way crossing is one of the classic schematic-reading bugs.
• Group by function, not by physical layout. The schematic is a logical document — power supply in one block, MCU in another, analog front-end in a third. The PCB is where physical reality matters; the schematic is where intent matters.
• Reference designators and values on every part, plus a title block with project name, revision, date, and author. Future-you will thank present-you.

Several commenters point to Henry Ott's Electromagnetic Compatibility Engineering and Phil's Lab YouTube channel for the deeper craft, and to looking at open-source hardware schematics (Adafruit, SparkFun, Olimex) as reference examples of what clean documentation looks like.

The meta-lesson is that schematics are a form of writing. The goal isn't to capture connectivity — any netlist does that — it's to communicate intent to a reader who wasn't there when you designed it.

Every time you've run netstat -s or watched a Grafana dashboard show "TCP segments retransmitted," you've consumed data that ultimately traces back to a small family of standardized counters. RFC 4022 is the document that defines what those counters mean, what they're called over SNMP, and how a network management station can ask any conforming device — a Cisco router, a Linux box, a printer — the same question and get a comparable answer.

It updates and obsoletes the original TCP MIB in RFC 2012 (1996) and, before that, RFC 1213 (1991). The 2005 revision modernized it for SMIv2, added IPv6 support via the InetAddress textual convention, and — importantly — split the connection table so that listening sockets and established connections live in separate rows you can actually iterate sensibly.

The problem it solves. Before the TCP-MIB, every vendor exposed TCP statistics differently. You could not write a single monitoring tool that asked "how many active opens has this device performed?" and get a uniform answer. SNMP needed a canonical object identifier (OID) tree for TCP, with precise semantics for each counter, so that tcpActiveOpens.0 meant the same thing on a Sun workstation and a Wellfleet router.

What's inside. The MIB defines scalar objects under 1.3.6.1.2.1.6 (the tcp subtree of mib-2):

• tcpRtoAlgorithm, tcpRtoMin, tcpRtoMax — how this stack computes retransmission timeouts
• tcpActiveOpens, tcpPassiveOpens — outbound vs. inbound connection establishments
• tcpAttemptFails, tcpEstabResets — failure counters that are gold for diagnosing flaky links
• tcpCurrEstab — the gauge behind every "established connections" widget
• tcpInSegs, tcpOutSegs, tcpRetransSegs, tcpInErrs, tcpOutRsts — segment-level traffic stats
• tcpHCInSegs, tcpHCOutSegs — 64-bit "high capacity" versions for fast links where 32-bit counters wrap in minutes

Then there are two tables: tcpConnectionTable for active connections (indexed by local/remote address-and-port, with an address-type column so IPv4 and IPv6 coexist), and tcpListenerTable for sockets in LISTEN state. Each connection row carries a tcpConnectionState (1=closed … 11=timeWait) and a writable deleteTCB action that lets an operator forcibly kill a connection from a NMS — a feature few people realize SNMP supports.

Design decisions worth noticing. The split between connection and listener tables looks pedantic but solved a real bug: in the old MIB, a listener on 0.0.0.0:80 appeared as one row with a zero remote address, and you couldn't tell from the table whether it was idle or just unmatched. Separating them made the semantics unambiguous and made walks cheaper on busy servers. The InetAddress textual convention (from RFC 4001) means a single MIB handles both address families — the row index encodes the type explicitly rather than duplicating the whole table.

Why it still matters. Prometheus exporters, node_exporter's node_netstat_Tcp_* series, and most commercial NMS products either pull these OIDs directly or use names that are 1:1 mappings of the MIB. When you read about "TCP retransmission rate" in any monitoring system written in the last twenty years, the underlying definition is RFC 4022's tcpRetransSegs / tcpOutSegs. Linux's /proc/net/snmp file literally uses these names.

The quiet legacy: RFC 4022 is one of those documents nobody reads but everybody depends on. It's the reason cross-vendor network monitoring is even possible.

When your clean domain model has to talk to a legacy system, a third-party API, or a partner service with bizarre conventions, the foreign model will leak into yours. Field names like cust_id_v2, nullable booleans, status codes encoded as strings ("01", "02", "99") — these alien concepts spread through your codebase until your domain is shaped by someone else's bad decisions. The Anti-Corruption Layer (ACL) is a translation boundary that keeps the rot contained.

An ACL is a dedicated module — usually a set of adapters, translators, and façades — that sits between your bounded context and the external system. Internally, your code speaks your domain language. The ACL converts to and from the foreign model at the edge. Nothing else in your codebase imports the foreign types.

Real-world example: An e-commerce team integrates with a 1990s-era ERP for inventory. The ERP returns:

• STK_QTY as a space-padded string (" 42")
• STAT_CD where "A" means active, "D" deleted, "H" on hold
• Prices in cents as integers, but only sometimes — international SKUs use whole units

Without an ACL, every service that touches inventory ends up calling parseInt(stk_qty.trim()) and writing if (stat_cd === "A") checks. Six months later, the ERP team renames STAT_CD to STATUS_CODE and you have 47 places to update.

With an ACL, you have one ErpInventoryAdapter that returns a clean InventoryItem { quantity: number, status: "active" | "deleted" | "on_hold", priceCents: number }. The ERP rename touches one file.

When to build one:

• Integrating with a legacy system you can't change
• The foreign model uses concepts that don't map cleanly to yours (different aggregates, different invariants)
• You expect the foreign system to change independently — or you might replace it later
• The external API has weird quirks (inconsistent nulls, magic strings, encoded enums)

Rule of thumb: If you find yourself importing foreign types in more than 2-3 places outside the integration module, you need an ACL. If a foreign concept appears in your domain layer (not just infrastructure), you've already lost — refactor before it spreads further.

Watch out: An ACL is not just a DTO mapper. A real ACL enforces your invariants — it rejects or normalizes data that violates your domain rules. If the ERP returns negative quantities, the ACL decides whether to throw, clamp to zero, or log and skip. That decision belongs at the boundary, not scattered across consumers.

Don Libes wrote expect in 1990 to solve a problem that hasn't gone away: programs that demand a TTY and refuse to read instructions from a pipe. passwd, ssh, telnet, ftp, vendor CLIs from network gear, half the firmware update tools shipped this decade — they all check isatty(stdin) and slam the door on shell scripts. expect opens a pseudo-terminal, runs the program inside it, and lets you script the conversation.

The core vocabulary is four words: spawn starts a process, expect waits for a pattern, send types a reply, interact hands control back to you.

#!/usr/bin/expect -f
set timeout 10
spawn ssh [email protected]
expect {
    "yes/no"   { send "yes\r"; exp_continue }
    "assword:" { send "$env(SWITCH_PW)\r" }
    timeout    { puts "stuck"; exit 1 }
}
expect "switch#"
send "show running-config\r"
expect "switch#"
send "exit\r"

That expect { ... } block is the killer feature: alternative patterns matched in parallel, each with its own action, and exp_continue loops back without falling out of the block. Try expressing that in sshpass or a heredoc — you can't.

The lazy man's script generator. Ship with the package: autoexpect. Run it, do the interactive thing once by hand, and out pops a working script.exp you can edit.

$ autoexpect -f login.exp ftp legacy.example.com
# ... type your session ...
$ chmod +x login.exp && ./login.exp

Half-automated, half-manual sessions. The interact command is what makes expect different from a one-shot replay tool. Drive the boring login dance, then drop the user at a live prompt:

spawn ssh jumpbox
expect "password:"; send "$env(PW)\r"
expect "$ "
send "sudo -i\r"
expect "password:"; send "$env(PW)\r"
interact                     ;# you're now driving, live

Pacing slow devices. Cisco/Juniper consoles drop characters if you paste a config too fast. expect has send -s with set send_slow {1 .05} to throttle one character every 50ms — the kind of dirty real-world detail you only learn after bricking something at 2am.

Testing CLIs. A frequently overlooked use: black-box testing your own tools. Spawn the binary, expect a prompt, send a command, assert the response, and exit with a status code. Better than golden-file diffing because you can branch on what the program actually said.

spawn ./mytool --repl
expect "> "
send "compute 2 + 2\r"
expect {
    -re "= 4\\b"  { puts "ok"; exit 0 }
    timeout       { puts "hung"; exit 2 }
    eof           { puts "crashed"; exit 3 }
}

Why not just use ssh keys / API tokens / proper batch mode? You should, when you can. expect earns its keep on the systems where you can't: a 2008-era SAN controller, a UPS web console with a serial fallback, an installer that asks "are you sure? [y/N]" and won't take --yes, an embedded device's U-Boot prompt over picocom. The grizzled wizard's rule: when the vendor refuses to fix their tool, wrap it in a PTY and move on with your life.

It's in every distro's repos (apt install expect, brew install expect), the manual is unusually good, and the language is Tcl — which is itself a tiny, almost forgotten gem you'll have learned by accident after a week.

Ocean Thermal Energy Conversion (OTEC) is the dusty cousin of renewable energy: invented in 1881 by d'Arsonval, demoed in Cuba by Georges Claude in 1930, and never scaled past a few megawatts. The premise is gorgeous in its simplicity — the tropical ocean surface sits around 26°C, while water at 1000 m depth hovers near 4°C. That 22°C gradient is a heat engine waiting to happen. So let's push it: can we run all of North America (≈4 TW average) from the Gulf of Mexico and Caribbean?

The Carnot ceiling is brutal. Maximum theoretical efficiency is η = (T_hot − T_cold)/T_hot = (299 − 277)/299 = 7.4%. Real closed-cycle OTEC plants (using ammonia as working fluid in a Rankine loop) achieve about 3% net after parasitic pumping losses. Compare to a coal plant at 40% — OTEC is moving 13× more thermal energy per watt delivered.

The water flow problem. To extract 1 MW of net electric power, you need to dump roughly 33 MW of heat into the cold reservoir. With a 22°C ΔT and seawater's specific heat (4 MJ/m³·K), each cubic meter of cold water absorbs only ~88 MJ as it warms to surface temperature. That means ~0.4 m³/s of cold water per net MW, plus a similar volume of warm surface water.

Scale to 4 TW: you need 1.6 million m³/s of cold water pumped from 1 km depth. For context, the Amazon River discharges 209,000 m³/s. We'd need to pull eight Amazons up a kilometer of pipe, continuously, forever.

Pipe engineering gets absurd. A single 10 m diameter cold-water pipe (CWP) at 2 m/s flow carries 157 m³/s. We need ~10,000 such pipes — or equivalently, a fleet of ~1,000 plants each rated 4 GW with 10 CWPs apiece. Each CWP must survive currents, biofouling, and the fact that polyethylene at 1 km depth deals with 100 bar external pressure. Current state of the art: Makai's 1.55 m HDPE pipe tested in Hawaii. We're asking for a 40× scale-up, ten thousand times over.

Now the thermodynamic kicker — we'd cool the ocean. The Caribbean and Gulf together hold roughly 10²² J in the top 100 m above 4°C. Running at 4 TW (net) means dumping 130 TW of waste heat into the surface mixed layer. Earth's net radiative imbalance is currently ~460 TW globally. We'd add 28% to the planet's heat-disposal load regionally, in one basin.

Actually — it's subtler. OTEC moves heat from surface to depth, then radiates it skyward via evaporation. Net effect on the basin: surface cooling, deep warming, vigorous artificial upwelling. The upwelling brings nutrient-rich deep water to the photic zone, which is either a fisheries bonanza or an algal-bloom catastrophe depending on stratification dynamics.

The hidden win: that cold deep water, after passing through the condenser, is still only ~10°C. Pipe it ashore and you get free district cooling for every coastal city in the tropics. Honolulu's SWAC system already does this at small scale. At continental scale, you'd eliminate ~15% of US electricity demand (air conditioning) before you even count the OTEC generation.

Verdict: physically possible, economically ruinous (~$30 trillion in pipes alone at current $/kg HDPE), and ecologically transformative in ways we cannot model. But the Caribbean as North America's thermal battery? The physics doesn't say no.

Imagine you're designing a spacecraft headed for the outer solar system, somewhere the sunlight is so feeble that solar panels become dead weight. You need power that lasts decades, survives cosmic radiation, and never needs refueling. NASA's standard solution since the 1960s has been the Radioisotope Thermoelectric Generator (RTG) — the plutonium-238 bricks that powered Voyager, Cassini, and the Curiosity rover. But RTGs have a dirty secret: they're appallingly inefficient, converting only about 6-7% of their heat into electricity. The rest is just... wasted into space.

Enter the Stirling Radioisotope Generator — a beautiful marriage of 19th-century mechanical genius and 21st-century space exploration. Instead of using the thermoelectric (Seebeck) effect like an RTG, an SRG uses a free-piston Stirling engine driven by the heat of decaying plutonium-238. The result? Roughly four times the efficiency of an RTG. That means you can get the same electrical output from a quarter of the plutonium — and Pu-238 happens to be one of the most expensive and supply-constrained substances humans produce. The U.S. essentially stopped making it in 1988 and only restarted small-scale production at Oak Ridge in 2013.

Here's where it gets fascinating: the Stirling engine was patented in 1816 by a Scottish clergyman, Robert Stirling, as a safer alternative to the steam engines of the day (which had a tendency to explode and kill people). It works by cyclically heating and cooling a sealed working gas — typically helium — between a hot and cold side. For a deep-space probe, that "hot side" is plutonium pellets glowing at 850°C, and the "cold side" is a radiator dumping heat into the 3-Kelvin void of space.

The catch, and the reason SRGs haven't replaced RTGs yet, is mechanical:

• RTGs have zero moving parts. You can drop one in a desk drawer for 50 years and it'll still work.
• SRGs have a piston oscillating around 80 times per second for decades, in a spacecraft that cannot be repaired.
• NASA's Advanced Stirling Radioisotope Generator (ASRG) program was cancelled in 2013 after Lockheed Martin had been developing it for years — partly over reliability concerns, partly because the renewed Pu-238 supply made the efficiency gain less urgent.

Still, the concept refuses to die. Free-piston Stirling engines have now run for over 14 years continuously in lab tests without wear, because they use flexure bearings and gas bearings — no metal-on-metal contact, no lubricants, nothing to degrade. It's the kind of engineering elegance that makes you wonder why we use anything else.

The same fundamental cycle that powered Philips' 1940s "MP1002CA" portable generator (sold to Dutch radio enthusiasts), that drives modern cryocoolers cooling MRI magnets, and that hobbyists build to run on the heat of a coffee cup — that exact cycle is being seriously proposed to power humanity's future missions to Europa, Titan, and beyond.

Honestly, this batch is thin — most entries are festival recaps, logo idents, or thank-you speeches with little actual content. The Great Unreal is the only candidate that points to a real, substantive piece of work behind it: a semi-autobiographical indie film about Filipino professional wrestling, told from inside the kayfabe tradition by the wrestler-turned-filmmaker himself.

Filipino pro wrestling is a genuinely under-documented scene. Unlike the global juggernauts of WWE or New Japan, the PWR (Philippine Wrestling Revolution) circuit operates on shoestring budgets, in small venues, with performers who hold day jobs and train in borrowed gyms. A trailer like this is a rare window into a regional wrestling subculture and how its performers think about kayfabe — the industry term for the maintained fiction that wrestling storylines are real.

The hook here is the autobiographical angle: LegenDarius is telling his own story of an early career-ending retirement, blurring the line between the performed character and the person underneath. That tension — wrestler as actor, actor as wrestler — is the most interesting thing wrestling-as-art keeps wrestling with, and it's worth two minutes of trailer time to see how a tiny independent production handles it.

Most of this week's batch is YouTube Shorts — quick clips with heavy emoji titles and minimal teaching. This one stands out as a proper long-form tutorial from a tiny channel (just 35 subscribers), aimed squarely at beginners who want to add wireless control to their hobby projects.

RF remote modules — typically the cheap 433 MHz or 315 MHz ASK/OOK transmitter-receiver pairs, or encoder/decoder chips like the HT12E/HT12D — are one of the most accessible ways to get into wireless electronics. They cost a couple of dollars, need no microcontroller for basic on/off control, and teach the fundamentals of encoding addresses, matched antennas, and noise immunity that scale up to more sophisticated radios like nRF24 or LoRa.

A beginner-focused walkthrough is genuinely useful here because the datasheets for these modules are sparse and the typical Amazon listings just show pinouts without explaining why you need pull-up resistors on the data lines, how address pins prevent your garage door from opening your neighbor's, or why the receiver works dramatically better with even a basic 17 cm wire antenna soldered on.

Worth a look if you've been wanting to cut the cord on an Arduino or relay project but found the nRF24/ESP-NOW learning curve too steep for a first wireless build.

Cavitation is one of those phenomena that sounds like science fiction but quietly destroys real hardware every day. This video tackles the counterintuitive idea that a liquid can boil without being heated — purely because local pressure drops below its vapor pressure as flow accelerates around a pump impeller, propeller blade, or turbine vane.

The mechanism matters because it's a direct consequence of Bernoulli's principle: where velocity is high, static pressure is low. When that pressure dips below the saturation vapor pressure at the working temperature, microscopic vapor bubbles form. The destructive part comes next — those bubbles travel downstream into higher-pressure regions and collapse violently, producing microjets that pit and erode metal surfaces. This is why hydroelectric turbine blades and ship propellers often look like they've been sandblasted.

For anyone working with pumps, hydraulic systems, or rotating machinery, understanding the Net Positive Suction Head (NPSH) requirement and why inlet design matters is genuinely useful engineering knowledge. The channel is brand new (7 subs) so production may be rough, but the topic is concrete and the description suggests a focused conceptual explanation rather than clickbait — exactly the kind of small-channel content worth surfacing.

Note: the emojis in the title are a minor concern, but the description is technical and substantive, suggesting real content underneath.

Most of today's crop is automation/AI hype reels or hashtag-spam shorts. This Arduino project from STEM PARK is the standout because it actually teaches a buildable, end-to-end embedded systems project — the kind of thing a hobbyist or student can replicate on a weekend with parts already in their bin.

The build combines three classic components: an Arduino UNO as the controller, an HC-05 Bluetooth module for serial communication with a phone, and a servo motor to physically actuate the lock. What makes this educational rather than gimmicky is that each piece teaches a transferable concept: UART serial protocols (the HC-05 speaks plain serial, so you learn how Bluetooth modules masquerade as wired connections), PWM servo control, and the role of a smartphone voice-recognition app passing parsed commands as simple text tokens to the microcontroller.

It's also a useful introduction to the trust boundary question in IoT — once you've built it, the natural next question is "what stops someone else from pairing and shouting 'open'?" That's the right doorway into authentication, pairing PINs, and why consumer smart locks need rolling codes rather than plaintext serial commands.

Good entry-level project for anyone moving past blinking-LED tutorials into mechatronics.

From a tiny 124-subscriber shop channel, this is exactly the kind of practical fabrication content that rewards careful viewing. The premise is simple — replicate a $189 commercial roller stand for around $10 in scrap steel — but the value is in the execution. A roller stand is a deceptively good first or second "real" weldable project: it forces you to think about load paths, tripod geometry, adjustable height mechanisms, and a rolling top assembly that has to spin freely while supporting significant weight.

Expect to see square tubing layout and cutting, telescoping joints (inner tube sliding inside outer tube with a locking pin), bearing or pipe-on-pipe roller construction, and the kind of tack-then-fully-weld workflow that keeps a multi-piece weldment square. Builds like this also tend to expose the small details that separate hobby work from shop-grade work — deburring inside the telescoping tubes so they slide, getting the legs splayed at a consistent angle, and welding sequence to control distortion on a tall, slender frame.

The cost-comparison framing is a little clickbait-adjacent, but the underlying build is legitimate metal fabrication content from a small creator who appears to genuinely run the work. For anyone with a welder, a chop saw, and a pile of offcuts, this is a buildable weekend project that teaches transferable skills.