Daily Digest — 2026-05-27

Tucked into the back-matter advertisements of Dr. Foote's 1902 medical encyclopedia is a remarkable artifact of Victorian reproductive technology: a discreet pitch from A. Lambert & Co. of 16 Dalston Lane, London, for "VIMULE Soluble Tablets," sold as a contraceptive pessary. What is startling is not that such a product existed, but the chemistry behind it — and the casual confidence with which it was marketed.

"Their active property is a special preparation of Quinine, which has been proved, under careful microscopic examination and experience of many years to be the most perfect of any for instantly destroying the generative nature of the seminal fluid."

The ad goes further, boasting commercial scale that would impress a modern e-commerce founder:

"For a considerable time we have recommended these to numbers of ladies in delicate health, and although we have sold upwards of eight millions 8,000,000 we have not had a single complaint of failure."

Dr. Edward Bliss Foote (1829–1906) was a New York physician and one of the most prolific popular-medical writers of the 19th century — a freethinker who championed birth control, dress reform, and frank sexual education at a time when the Comstock laws made distributing such information a federal crime. His Home Cyclopedia was a doorstop compendium that mixed practical recipes with surprisingly progressive social commentary, and its commercial appendices reveal an entire shadow economy of "marital appliances" sold by mail order.

Was the quinine claim real? Surprisingly, yes — partially. Quinine is a genuine spermicide. In 1885, the British pharmacist Walter Rendell introduced quinine-based pessaries that became the standard chemical contraceptive in Britain for roughly fifty years, used widely until the 1930s. Laboratory studies confirmed that quinine sulfate at sufficient concentrations does immobilize spermatozoa. Marie Stopes, the founding figure of British family planning, recommended quinine pessaries in her clinics well into the 1920s.

The catch: quinine's spermicidal effect is weak and unreliable compared to modern nonoxynol-9, and the "8 million sold, zero failures" claim is obvious advertising puffery. Real-world failure rates were likely 20–30% per year — better than nothing, but the "absolutely reliable and unfailing" pitch contributed to many unplanned pregnancies. Quinine pessaries were finally displaced by the rubber diaphragm and later by hormonal contraception.

The truly forgotten detail is the marketing positioning:

• "Can be used by the wife without the knowledge of her husband" — covert female-controlled contraception, decades before "the pill" became shorthand for the same idea.
• Sold in "sealed metal boxes... perfectly free from observation" — the discreet brown-paper-package model still used by sexual wellness brands today.
• Distributed by a "Manufacturer of Surgical Instruments" that also sold trusses, syringes, and "Every description of Appliance for the Prevention of Conception" — a Victorian Planned Parenthood storefront hiding inside a medical-supply shop.

A century before Plan B and modern femtech apps, a London surgical-supply firm was already selling discreet, female-controlled fertility products by mail — with overconfident efficacy claims that would make a modern FTC regulator wince.

Buried in the preface of a 1902 trade manual for photoengravers — a workshop guide for men who etched zinc plates with acid to reproduce illustrations for newspapers and magazines — Harry Jenkins makes a quietly radical argument about what it means to be a skilled tradesman. The book itself is a practical recipe book: how to coat a plate, how to mix the bichromate sensitizer, how to expose a halftone screen. But before the formulas, Jenkins pauses to deliver a small sermon:

The importance of a study of the scientific laws upon which the practical work is based can not be too strongly emphasized. It is the possession of this knowledge that makes the difference between the intelligent investigator and the "rule-of-thumb" workman, and the student is urged to give ample attention to these fundamental principles.

This is a striking framing for 1902. The photoengraving trade was, at the time, the digital photography of its day — a young, fast-moving technology that had only existed commercially for about two decades. Most practitioners learned by apprenticeship, copying the master's gestures without understanding why the chemistry worked. A "rule-of-thumb" workman could produce a perfectly serviceable plate on a good day, but when the bath went off, or the weather shifted, or a new pigment behaved oddly, he had no theory to fall back on.

Jenkins is arguing for what we'd now call first-principles thinking. He wants his readers to understand the chemistry of silver halide reduction, the optics of the halftone screen, the acid-resist behavior of hardened gelatin — not because the theory is beautiful, but because recipes break and principles don't.

What's remarkable is how thoroughly modern society has re-learned this lesson and then forgotten it again. The contemporary parallel is almost too obvious: the developer who can wire up a React component by pattern-matching against Stack Overflow but cannot debug when the framework misbehaves; the data scientist who runs model.fit() without understanding gradient descent; the home cook who follows recipes flawlessly but cannot rescue a broken sauce. Jenkins would recognize all of them as "rule-of-thumb workmen."

The forgotten wisdom here isn't a technique or a recipe — it's an attitude toward craft. In an era when YouTube tutorials and LLM-generated code make the rule-of-thumb path easier than ever, Jenkins's 1902 preface reads like a warning shot across 124 years. He believed that the difference between a competent tradesman and a master wasn't dexterity or experience, but the willingness to learn the underlying science when the trade school told you that you didn't need to.

The photoengraving industry that Jenkins wrote for was obliterated by offset lithography within fifty years. But the practitioners who understood the chemistry — the Frederic E. Ives who co-wrote Jenkins's color-work chapters — went on to invent the next generation of imaging. The rule-of-thumb workmen simply lost their jobs.

In 1880, the U.S. Census took eight years to count 50 million people. By the time the results were published, they were already obsolete. The Census Bureau feared the 1890 count — projected at 63 million — might take longer than the decade itself. A young engineer named Herman Hollerith, working at the Bureau and watching clerks hand-tally tick marks for years, decided to mechanize the problem.

His solution was filed as U.S. Patent 395,782, "Art of Compiling Statistics," granted January 8, 1889. The mechanism: encode each person's data — age, sex, race, occupation, marital status — as a pattern of holes punched into a stiff card the size of an 1887 dollar bill. To tabulate, a clerk placed the card under a press of spring-loaded pins. Where a hole existed, the pin dropped through into a mercury-filled cup beneath, completing an electrical circuit that advanced a counter dial by one. To sort, the same circuit triggered a solenoid that flipped open the lid of a corresponding sorting bin.

It was, in essence, a parallel query engine. Set the wiring to "count cards where column-12 = female AND column-22 = widowed" and the machine performed what we'd now call a SELECT COUNT(*) WHERE filter — at roughly 80 cards per minute, against millions of records.

The 1890 Census finished in six weeks for the initial population count, and the full statistical analysis in two years. Hollerith's machines saved the government an estimated $5 million (about $170 million today). Governments worldwide lined up: Russia, Austria, Canada, France, Norway. In 1896 Hollerith founded the Tabulating Machine Company. In 1911 it merged with three others. In 1924 the conglomerate renamed itself International Business Machines — IBM.

What's startling is how many modern concepts the patent already contained:

• Structured records with fixed fields — each column position meant something specific. This is a database schema.
• Boolean query composition — by wiring multiple sensing pins in series (AND) or parallel (OR), an operator built compound predicates. This is SQL's WHERE clause as copper and mercury.
• Indexed sorting — the sorter bins are a one-pass radix sort, the same algorithm modern databases use for billion-row joins.
• Separation of storage and compute — cards (data) were physically distinct from the tabulator (processor). Swap the cards, run a different query. This is the architectural premise of every data warehouse from Teradata to Snowflake.
• Batch processing — load a tray, return later for results. The mainframe job queue, born 70 years before mainframes.

The punched card itself outlived Hollerith by half a century. FORTRAN, COBOL, and the entire 1960s programming workflow ran on 80-column cards descended directly from his 1889 design. The IBM 80-column card was standardized in 1928 — and the column count survives in your terminal emulator's default width today.

Could it be built better now? It already was: every analytical database — BigQuery, Redshift, ClickHouse, DuckDB — is Hollerith's machine with the mercury cups replaced by SSDs and the sorting bins replaced by hash partitions. The conceptual leap was his. The semiconductors are an implementation detail.

Out of today's batch of zero-star repos, polygentic/anti-fun stands out purely on the strength of its name. In a sea of "blank-app," "dotfiles2," and randomly-named placeholder projects, a repo called anti-fun under an org called polygentic demands a second look. There's no description, no language detected, and no topics — but the naming convention suggests someone thinking carefully about what they're building rather than reaching for a generic scaffold.

The polygentic organization name itself is interesting wordplay — riffing on "polyglot" or "polygenic," it hints at a project space dealing with multi-agent systems, multi-language tooling, or perhaps genetic/evolutionary approaches. "Anti-fun" as a project name has the deadpan quality of names like boring-company or no-bullshit — projects that lean into being deliberately unglamorous about something the maintainer takes seriously.

Without a README or code yet visible, this repo is essentially a name claim — an early stake in a concept. That's actually one of the more interesting moments to discover a project, because:

• You can watch an idea take shape from commit zero
• The earliest contributors often have outsized influence on direction
• The naming choices often reveal the maintainer's taste and worldview before any code does

Who might find it useful: Developers who enjoy following projects from inception, anyone curious about polyagent/polyglot systems, and people who appreciate a project name that doesn't try to sound enterprise-friendly. Star it now and you'll be employee #1 if it turns into something — or you'll have a fun bookmark to revisit in six months when you've forgotten what "anti-fun" was supposed to mean.

Sometimes the gems are the ones you have to wait on.

Every branch predictor we've discussed — TAGE, perceptron, tournament — assumes it has enough table entries to remember each branch's behavior. In reality, predictor tables are small (typically 4–32 KB), and your program has thousands of dynamic branches per millisecond. When branches outnumber entries, they alias: two unrelated branches hash to the same predictor slot and corrupt each other's history. This is called predictor capacity pressure, and it's the silent killer of prediction accuracy in large codebases.

The math is brutal. A typical L1 BTB holds ~4K entries. A modern Pattern History Table holds ~16K 2-bit counters. If your hot loop spans 8K static branches (common in interpreters, JITs, and big switch-heavy code like protobuf decoders), half your branches collide. Aliasing patterns can be constructive (both branches go the same way — no harm) or destructive (they disagree, and the counter oscillates uselessly).

Real-world example: The V8 JavaScript engine's interpreter used to run a giant switch statement dispatching ~200 bytecodes through a single indirect branch. That one indirect branch saw essentially random targets, and the BTB couldn't predict it — mispredict rates hit 40%+. The fix was threaded dispatch: each bytecode handler ends with its own indirect jump to the next handler. Now the BTB sees ~200 separate branch sites, each with its own history of "what bytecode usually follows me." Mispredict rates dropped to ~10%, and interpreter throughput nearly doubled.

Rule of thumb: If your working set of taken branches exceeds the BTB size, expect 2–5× more mispredicts. Estimate it: count unique branch PCs executed in your hot path. If it's over ~4000, you're aliasing. perf stat -e branch-misses,branches tells you the rate; perf record -e branch-misses tells you where they cluster.

Modern CPUs fight back with several techniques:

• Hierarchical BTBs: Intel's Golden Cove has L1 BTB (~1K), L2 BTB (~12K). L1 hits in 1 cycle; L2 hits cost a bubble but cover more branches.
• Tagged predictors (TAGE): Use partial tags so colliding branches detect the collision and fall back to a base predictor instead of corrupting each other.
• PC-folding hash functions: XOR multiple PC bits to spread branches more uniformly across tables.

The practical lesson for programmers: code size matters for prediction accuracy, not just for icache. Macro-expanded code, unrolled loops past a point, and bloated template instantiations create branches that compete for predictor entries. Sometimes a smaller, "slower" loop predicts better and runs faster overall.

Free, high-quality cryptography textbooks are rare. Most introductory material splits into two unsatisfying camps: cookbook-style guides that teach you which library function to call without explaining why, and graduate-level treatises that demand measure theory before page ten. Boaz Barak's An Intensive Introduction to Cryptography — the lecture notes from his Harvard course — sits in the genuinely useful middle.

Based on the URL and the title, this is the full online edition of Barak's textbook-in-progress, freely readable at intensecrypto.org. Barak is one of the more thoughtful expositors in theoretical CS, and his approach to cryptography reflects that: he treats crypto as a branch of computational complexity rather than a bag of tricks. The "intensive" in the title isn't marketing — it means the book derives security properties from first principles, with proofs.

What a technical reader is likely to find here:

• Definitional rigor. Most engineers know that AES is "secure" but couldn't precisely state what that means. Barak's notes walk through IND-CPA, IND-CCA, and the reduction-based proofs that connect them to hardness assumptions.
• Modern coverage. Beyond the symmetric/asymmetric basics, the course historically covers zero-knowledge proofs, fully homomorphic encryption, lattice-based crypto, and post-quantum constructions — the actual frontier, not just the textbook 1990s pipeline.
• Pseudorandomness as the unifying concept. Barak's framing — that almost all of cryptography reduces to constructing pseudorandom objects from minimal assumptions — is genuinely clarifying once it clicks.
• Free and maintained. No paywall, no DRM, no $120 hardback. The notes get revised as the field evolves.

For practitioners, the value isn't that you'll write your own AES (you shouldn't). It's that after working through material like this, you stop treating crypto primitives as magic. You can read a protocol spec, identify the security game it's playing, and notice when something is off — when a "nonce" is being reused, when a MAC is missing, when a construction is leaking through a side channel. That intuition is exactly what separates engineers who quietly ship subtly broken systems from those who don't.

At three points and zero comments, this is precisely the kind of submission HN tends to upvote enthusiastically when someone notices it — a free, high-signal educational resource from a credible author. It just landed at the wrong moment in the queue.

Of the ten postings, Khan Academy's is the most strategically revealing because it contains a quiet confession most companies bury: "Our site has been built on Python 2 and Google App Engine for its first 10 years of exis[tence]." That single clause is the entire teardown.

The stack tells a survival story. Python 2 reached end-of-life on January 1, 2020 — roughly three months before this posting. Khan Academy is openly hiring senior backend/fullstack engineers to do what is almost certainly a multi-year migration off a deprecated runtime and off classic Google App Engine (a platform Google itself has been steering customers away from in favor of GAE Standard 2nd gen, Cloud Run, and GKE). The fact that they lead with this in the posting — rather than hiding it — is a recruiting tactic: they're filtering for engineers who get excited about brownfield migrations on systems serving millions of students.

What it reveals about the company's stage. Khan Academy is 10+ years old, non-profit, and load-bearing for global education — and the timing (March/April 2020, school closures worldwide) means traffic just exploded. They explicitly mention being focused on "helping teachers working in their classrooms (and a lot of teachers and parents are using Khan away from their classrooms right now!)." So they're scaling demand and re-platforming and doing it as a non-profit. That's a brutal trifecta.

Skills/trends highlighted:

• Legacy migration expertise is back in demand — the industry is paying off a decade of GAE/Python 2 technical debt simultaneously.
• Remote USA/Canada hiring from a Mountain View company in March 2020 — early signal of the pandemic-driven remote-default shift that would reshape SF Bay hiring within months.
• Mission-driven hiring as compensation strategy — non-profits compete with FAANG salaries by selling impact, and "free education for anyone, anywhere" during a global school shutdown is the strongest version of that pitch they'll ever have.

Green flags: radical honesty about the stack, clear mission, remote-friendly, senior-level roles (no junior burnout fodder for the migration).

Red flags: a 10-year Python 2 / GAE codebase means significant coupling to deprecated APIs (ndb, the old taskqueue, webapp2). Whoever joins is signing up for years of 2to3, datastore migrations, and arguing about whether to go Cloud Run vs. GKE. The posting doesn't mention what target stack they've chosen — which suggests they may not have decided yet.

Every core caches virtual-to-physical translations in its own private TLB. When one core modifies a page table — via munmap, mprotect, madvise(MADV_DONTNEED), swap-out, or COW — every other core that might have cached that translation now holds a stale entry. The hardware does not coherently invalidate TLBs across cores. The OS must do it in software, and the mechanism is called a TLB shootdown.

The sequence on x86 Linux:

• Initiating core updates the PTE and flushes its own TLB with INVLPG.
• Kernel walks the mm_cpumask to find which cores have ever run threads of this address space.
• It sends each of them an inter-processor interrupt (IPI) — vector CALL_FUNCTION_VECTOR or a dedicated TLB vector.
• Each target core takes the interrupt, runs flush_tlb_func, executes INVLPG (or a full MOV CR3 for batch flushes), and ACKs.
• Initiating core spins until all ACKs arrive, then returns to userspace.

The cost: an IPI round-trip is ~1–3 µs on modern Xeons. With 64 cores all running threads of the same process, a single munmap can stall the originator for tens of microseconds and steal cycles from every other core. At scale this dominates.

Real-world example: A JVM with 200 threads on a 96-core box calling System.gc(). The collector unmaps reclaimed regions; each munmap fires shootdowns to all 96 cores. Production traces have shown 40% of "GC pause time" being TLB shootdown IPIs, not actual collection work. Same pattern hits Go's scavenger releasing memory back to the OS.

Rule of thumb: A shootdown costs ~1.5 µs × (active cores in mm_cpumask). At 64 cores that's ~100 µs per unmap. If you're unmapping in a hot loop, batch the operations or use MADV_FREE instead of MADV_DONTNEED — MADV_FREE defers the actual unmap and avoids the immediate shootdown.

Mitigations the kernel already does: coalescing multiple invalidations into a single full flush (MOV CR3) when the per-page list exceeds tlb_single_page_flush_ceiling (default 33 pages), and PCID tags so a MOV CR3 doesn't blow away unrelated entries. ARM is better off here — TLBI instructions broadcast over the interconnect, no IPI needed — but the stall on the interconnect is real too.

By 1999, FTP was already a quarter-century old (the original spec, RFC 114, dates to 1971), and the wider world had finally noticed that it was riddled with attack surface. Rather than try to fix FTP itself — a Sisyphean task given how much deployed software depended on its exact quirks — Mark Allman and Shawn Ostermann wrote RFC 2577 as an operator's playbook: a catalogue of every known way FTP could be abused, with concrete mitigations. It is one of the more honest documents the IETF has published, essentially saying "this protocol is full of holes, here is how to live with them."

The headline attack is the FTP bounce attack. FTP uses two channels: a control connection (port 21) and a separate data connection. In active mode, the client tells the server where to deliver data via the PORT command — which specifies an arbitrary IP address and port. Nothing in the original spec required that address to be the client's own. So an attacker could connect to ftp.victim.com, issue PORT pointing at internal.target.com:25, and have the FTP server happily open a TCP connection to a host behind a firewall — using the FTP server as a proxy. Worse, attackers could stage arbitrary bytes on the FTP server (uploaded as a file), then bounce them at an SMTP port to send forged mail, or scan internal networks one port at a time. RFC 2577 mandates that servers refuse PORT commands whose IP doesn't match the control connection's peer — the fix nearly every FTP daemon ships today.

The document then enumerates a parade of other issues:

• Restricted-access attacks: servers should refuse data connections to privileged ports (<1024) to prevent bouncing into NFS, syslog, or rsh.
• Port stealing: because PASV data ports are often allocated sequentially, an attacker can predict the next port and connect first, hijacking or denying the legitimate transfer. The fix: randomize port selection.
• Brute-force passwords: FTP transmits credentials in cleartext and historically had no rate-limiting. RFC 2577 recommends delays after failed logins, capped attempt counts, and disconnecting after N failures — basic hygiene that wasn't universal in 1999.
• Username enumeration via USER/PASS timing: servers should respond identically whether the username exists or not.
• Anonymous FTP pitfalls: writable directories enable warez staging; ~ftp permissions are easy to misconfigure into a root-readable filesystem.

What makes RFC 2577 quietly important is that it's still the canonical reference for FTP hardening 27 years later. Modern FTP servers — vsftpd, ProFTPD, pure-ftpd — implement essentially this checklist. If you've ever wondered why vsftpd.conf has knobs like port_promiscuous=NO or pasv_min_port/pasv_max_port, you're looking at RFC 2577 enforcement.

The broader lesson is architectural. FTP's sins flow from one design decision: using a separate data channel whose endpoint is negotiated in-band over the control channel. That choice makes NAT traversal painful (every NAT needs an FTP ALG to rewrite PORT commands), makes TLS retrofit awkward (FTPS exists, but the dual-channel TLS dance is famously fiddly), and creates the bounce attack as a near-direct consequence. SFTP — which is just file operations over SSH — sidesteps every one of these problems by using a single authenticated channel. RFC 2577 is, in a sense, the document that finally made the case for replacing FTP, even as it taught us how to keep it limping along.

The asker has two bare-metal ELF images that will be co-resident in physical memory and wants them to share a region containing both data and code. Their instinct is to drop my_object_file.o(.data) into a fixed-address section (.my_section 0x10000) in both linker scripts and hope the resulting symbols line up.

Why it's tricky: two independent link invocations are exactly that — independent. Even with the same object file and the same address, the linker is free to:

• Order symbols differently within the section (especially if other inputs contribute).
• Apply different relocations because the surrounding code references symbols at different addresses.
• Inline, fold (ICF), or garbage-collect (--gc-sections) entries that look unused from one ELF's perspective but not the other's.
• Generate PLT/GOT stubs in one image and not the other.

So "include the same .o in the same fixed section" is necessary but not sufficient. You need the addresses, not the inputs, to be the contract between the two ELFs.

A more robust approach:

• Single source of truth for layout. Build the shared region as its own ELF (or a flat binary) linked once at 0x10000. Generate a symbol file from it (nm or --just-symbols).
• Consume symbols, not sources. In each of the two application linker scripts, pull in those addresses via INCLUDE shared.syms or pass -Wl,--just-symbols=shared.elf. Now both ELFs reference identical absolute addresses without re-linking the shared code.
• Alternatively, hardcode the contract: declare each shared symbol with PROVIDE(my_func = 0x10010); in both scripts. Ugly, but explicit.
• Mark the section NOLOAD in one of the ELFs if only the other should actually deposit bytes there — otherwise both loaders will write the region and the second write wins.

Gotchas:

• Code sharing is harder than data. Shared functions must be position-independent or linked at the exact address they'll execute from. Any internal calls/branches resolve at link time, so both ELFs must agree on those targets — which is exactly what --just-symbols from a pre-linked shared image gives you.
• BSS-style zero-init in a shared region is dangerous: whichever ELF's startup runs second will clobber state the first one set up.
• Cache coherency and MPU/MMU regions matter on real silicon — the shared window typically needs to be mapped as shareable (or uncached) on both cores/contexts.
• Don't trust --gc-sections here; mark the shared section with KEEP(...).

You have two replicas, each holding 500 GB of data. One has drifted out of sync. How do you find the differences without shipping a terabyte across the network? You build a Merkle tree: a tree where every leaf is a hash of a data block, and every internal node is a hash of its children's hashes. Compare roots — if they match, the datasets are identical. If they differ, walk down only the branches that disagree.

The magic is the asymmetry: equality is proven with a single hash comparison, but inequality is localized in O(log n) steps. You only transfer the actual data for the blocks that truly differ.

How it's built:

• Partition data into fixed-size chunks (e.g., 4 KB blocks, or key ranges in a database).
• Hash each chunk → these become leaf nodes.
• Concatenate sibling hashes and hash again → parent nodes.
• Repeat until you have a single root hash.

Real-world example: Cassandra and DynamoDB use Merkle trees for anti-entropy repair. When two replicas need to reconcile, they exchange root hashes first. If equal, done — zero data transferred. If not, they walk the tree, exchanging only the subtree hashes on each level. For a 1 TB table partitioned into 1 million 1 MB chunks, finding the one corrupted chunk takes ~20 hash comparisons (log₂ 1,000,000) instead of streaming the whole table.

Git uses the same idea — every commit is a Merkle tree of file hashes. That's why git fetch can determine what objects you're missing with a handful of hash exchanges. Bitcoin uses it so light clients can verify a transaction is in a block without downloading the block.

The bandwidth rule of thumb: for n chunks with d differences, naive sync transfers all n chunks; Merkle sync transfers roughly d × log(n/d) chunks worth of hashes plus the d differing chunks. When d is small relative to n, the savings are enormous. When d approaches n, you're better off just shipping everything.

Watch out for:

• Chunk boundaries matter. Inserting one byte at the start shifts every block, making everything look different. Content-defined chunking (rolling hashes, like rsync uses) handles this.
• Tree depth vs. chunk size tradeoff. Smaller chunks = more precise diffs but bigger trees. Tune for your access patterns.
• Build cost is O(n). You're hashing everything. Cache the tree and update incrementally on writes.

Every few years someone hands me a corrupt firmware blob, a leaked savefile, or a multi-gigabyte mmap'd database with one wrong byte at offset 0x4A2E, and asks me to "just sed it." I used to mumble something about xxd | sed | xxd -r and quietly hate my life. Then in 2005 I discovered bbe — the Binary Block Editor — and never looked back.

bbe is sed's binary-aware cousin. It understands the concept of a block (fixed-length, delimiter-bounded, or pattern-anchored), and runs a tiny command language against each block. It handles NUL bytes natively, takes hex escapes everywhere a pattern is expected, and streams gigabytes without buffering the whole file. On Debian/Ubuntu it's a one-liner: apt install bbe.

The trivial case — substitute a binary pattern:

$ bbe -e 's/\x89PNG\r\n\x1a\n/\x89BAD\r\n\x1a\n/' good.png > broken.png

Try doing that with GNU sed without it choking on the embedded NUL or eating your \r. You can't — sed is line-oriented and POSIX sed barfs on binary data entirely.

Patch a single byte at an exact offset (the firmware-modder's bread and butter):

# Replace byte at offset 0x4A2E with 0xAA, leave everything else alone
$ bbe -b '#0:1' -e 'r 0x4A2E \xAA' firmware.bin > patched.bin

The -b flag defines the block — here, the whole file as one block starting at byte 0. r OFFSET STRING replaces bytes at a position. There's also i (insert), d (delete), j (join), y/abc/xyz/ (transliterate), and >FILE / <FILE to redirect a block to or from disk.

Operate per fixed-size record — e.g. strip trailing NUL padding from every 512-byte tar block:

$ bbe -b ':512' -e 's/\x00\x00\x00\x00$//' archive.tar > trimmed.tar

Block defined by delimiters — extract every JPEG embedded inside a memory dump or PCAP, one file per match:

$ bbe -b '/\xFF\xD8\xFF/\xFF\xD9/' -e '>jpeg_%n.jpg' memdump.bin
# %n auto-increments, so you get jpeg_1.jpg, jpeg_2.jpg, ...

That one's the killer use case for me. Carving files out of unknown binary containers usually means firing up a 600 MB forensics suite. Three flags of bbe and you're done.

Translate bytes wholesale — useful for trivial obfuscation or fixing endianness in fixed-width records:

$ bbe -e 'y/\x00\xFF/\xFF\x00/' image.raw > inverted.raw

Chain multiple commands on each block like sed:

$ bbe -b '/HEADER/FOOTER/' \
       -e 'd 0 8; s/\xDE\xAD\xBE\xEF/\xCA\xFE\xBA\xBE/; r 16 \x01\x02' \
       blob.dat

Why not just use a Python script with open(..., 'rb') and .replace()? Because Python loads the file into memory, and your "quick fix" for the 40 GB VM image becomes a 40 GB malloc. bbe streams. It's also the right call inside shell pipelines where dropping into a real language feels like overkill — dd if=/dev/sdb | bbe -e 's/\xDE\xAD/\xBE\xEF/' | dd of=/dev/sdc just works.

The man page is short. Read it once and you'll keep bbe in your toolbox forever — right next to xxd and the dog-eared printout of ASCII codes you keep meaning to throw out.

Steel gets stronger when it gets colder. This isn't a gimmick — it's a well-documented property of body-centered cubic metals. A36 structural steel at room temperature has a yield strength around 250 MPa. Cool it to liquid nitrogen temperatures (77 K, or −196 °C) and that climbs to roughly 450–500 MPa. Austenitic stainless steels do even better: 304 SS jumps from ~215 MPa yield at room temp to over 700 MPa at 77 K, and its ultimate tensile strength can exceed 1500 MPa. So what if we ran cryogenic plumbing through skyscraper columns to double their load capacity?

The seductive math. A typical 50-story tower has core columns sized for ~30 MN axial loads. If yield strength doubles, you could halve the steel cross-section, or keep the section and double the building height. For a 200,000 m² high-rise using ~15,000 tonnes of structural steel at ~$1,200/tonne, halving steel saves ~$9 million in material alone. Tempting.

Now the heat leak problem. Concrete and air around the column are at ~293 K. A bare steel column at 77 K with a surface area of, say, 400 m² per floor would conduct heat ferociously. With even a high-performance multilayer vacuum insulation (MLI) jacket — say k_eff ≈ 0.0005 W/m·K at 5 cm thickness — heat leak is:

Q = (k × A × ΔT) / t
Q = (0.0005 × 400 × 216) / 0.05 ≈ 864 W per floor

Over 50 floors: ~43 kW of continuous cooling load. Liquid nitrogen's latent heat of vaporization is 199 kJ/kg, so you'd boil off:

43,000 W ÷ 199,000 J/kg ≈ 0.22 kg/s ≈ 19 tonnes per day

At industrial LN₂ prices (~$0.15/kg delivered), that's ~$2,800/day, or $1 million per year just to keep the columns cold. Recondensing on-site with cryocoolers? A Stirling cryocooler at 77 K has a Carnot efficiency of maybe 15%; ideal Carnot COP at that ΔT is 77/(293−77) = 0.36, so real COP ≈ 0.05. You'd need ~860 kW of electrical input continuously. Goodbye, savings.

The structural nightmares. Thermal contraction of steel from 293 K to 77 K is about 0.3%. A 200 m column shrinks by 60 cm. Every beam-to-column connection becomes a thermal expansion joint capable of moving 6 mm per floor. Differential contraction between cooled columns and warm floor slabs would tear conventional moment connections apart. You'd need sliding bearings everywhere, sacrificing the lateral stiffness that makes a moment frame work in the first place.

And the human factor. A cryogenic leak in an occupied building displaces oxygen — LN₂ expands 700× when it vaporizes. A single 200-liter spill releases 140 m³ of nitrogen gas, enough to asphyxiate occupants in a stairwell. The 2006 Texas A&M nitrogen incident killed a researcher from a far smaller release.

Where it almost makes sense. Cryogenic strengthening is real and used: LNG storage tanks exploit the 9% nickel steel's improved toughness at −162 °C, and some aerospace tankage uses cold-strengthened austenitics. But these are incidentally cold — the cryogen is the cargo, not a structural service fluid.

For buildings, the energy-in-perpetuity to maintain strength dwarfs the one-time material savings within ~9 years, and that's before insurance underwriters laugh you out of the room.

Pick up almost any small rubber or plastic part — the grommet on your headphones, an O-ring in your faucet, a tiny gear inside a medical device — and run your fingernail along its seam. Feel that? Probably nothing. But moments after that part popped out of its mold, there was a thin, ragged frill of excess material clinging to the parting line where the two mold halves met. That whisker of waste is called flash, and getting rid of it is one of manufacturing's quietly annoying problems. Trim it by hand and you're slow and inconsistent. Trim it by machine and you risk scarring the part. So the industry came up with something wonderfully strange: freeze the part until the flash becomes more brittle than glass, then sandblast it with frozen plastic pellets.

Welcome to cryogenic deflashing. The process exploits a property called the glass transition temperature — the point at which a polymer stops behaving like a chewy solid and starts behaving like a shatterable ceramic. Rubber, silicone, nylon, and many thermoplastics have glass transitions well below freezing, often around −80 °C to −150 °C. Liquid nitrogen, boiling at −196 °C, takes parts comfortably past that threshold.

Here's the clever bit: the flash is thinner than the part itself, so it cools faster and gets brittler sooner. When you blast the chilled parts with a media — usually tiny polycarbonate pellets, since you don't want to use something harder than the workpiece — the flash snaps off cleanly while the bulk of the part, still slightly warmer in its core, absorbs the impact without damage. The temperature differential becomes a kind of selective scalpel.

A few details that make this even cooler:

• The tumbling baskets often rotate inside the nitrogen vapor, ensuring uniform exposure and preventing parts from clumping.
• Polycarbonate media is preferred because it itself becomes brittle at cryogenic temperatures and gradually pulverizes — so it self-cleans and won't embed in the parts.
• The technique handles parts that would be impossible to deflash mechanically, like rubber bellows with internal seams or tiny medical components with intricate geometry.

If you've heard of the Liberty Bell cracking, or watched someone smash a rose dipped in liquid nitrogen at a science demo, you've seen the same principle: ductile materials become brittle when cold enough. Cryogenic deflashing is essentially that party trick weaponized into a precision industrial process, running 24/7 in factories that make everything from automotive seals to pacemaker housings.

It connects to a broader family of cryogenic manufacturing tricks — cryogenic machining (where coolant is liquid nitrogen, extending tool life dramatically), cryogenic grinding of spices (so volatile oils don't evaporate from the heat of milling), and cryogenic recycling of tires (where the frozen rubber shatters away from the steel belts).

Of the candidates in today's batch — mostly trailers, awards montages, and hashtag-laden promo clips — this interview stands out as the only one that actually teaches something about how the independent film world works behind the curtain.

Filmed at NAB Show 2026, the League of Filmmakers sits down with producer Gio Labadessa, founder of the Not Film Fest, to dig into a question most festival circuits avoid: why are so many indie filmmakers locked out by submission fees, opaque curation, and personal connections? Labadessa walks through his deliberate effort to build a festival without those traditional gatekeeping mechanisms — covering programming philosophy, how he handles selection without the usual industry politics, and the economics of running an accessible festival.

For anyone curious about the festival pipeline — submitting filmmakers, programmers, or viewers wondering why certain films keep appearing while others vanish — this is a candid look at the structural problems and one founder's concrete attempt to fix them. It's a conversation, not a sizzle reel, which makes it the rare watchable item in a list otherwise dominated by trailers and award show footage.

Note: the channel attribution "CFA Institute" on a film festival video is unusual and may be a metadata mismatch in the source listing.

Note: this batch was thin — most candidates were PC build vlogs, hashtag-spam shorts, or clickbait. This one at least covers a real circuit concept worth understanding.

A transformerless power supply (more precisely, a capacitive dropper) is a clever and compact way to step mains AC down to a low DC voltage without the bulk and cost of an iron-core transformer. The trick: an X-rated capacitor in series with the live line acts as a lossless reactive impedance, dropping most of the voltage as the AC alternates. A bridge rectifier and smoothing cap then produce DC, with a Zener clamping the output.

It's the kind of circuit you'll find inside cheap LED bulbs, mains-powered clocks, and tiny appliance controllers — anywhere you need a few milliamps at 5–12 V and can't justify a transformer or switcher. Understanding why this works (and why it's dangerous) is genuinely useful: the output is not isolated from mains, so every node is live relative to earth. Touching it can kill you.

Worth watching for the circuit concept, but treat it as theory — not a "build this on a breadboard" project. If you want isolated low-voltage power, use a proper transformer or a USB brick.

This is a rare find: a whiteboard lesson that takes a problem nearly everyone has experienced — one room in the house that refuses to cool no matter how hard the AC works — and uses it as the entry point into the actual fluid dynamics of forced-air HVAC systems. The framing is genuinely educational rather than gimmicky.

Expect a walk through fan curves (the relationship between static pressure and volumetric flow rate that every blower obeys), system curves (how duct geometry, length, and fittings impose resistance), and the operating point where those two curves intersect. That intersection is what actually determines CFM delivered to a register — not the fan's rated capacity on the box.

From there, the lesson connects to real-world failure modes: undersized return ducts starving the blower, long flex runs with too many 90-degree bends spiking pressure drop, and why simply "turning up the fan" doesn't linearly increase flow once you're climbing the steep part of the system curve. It is the kind of foundational HVAC engineering content normally buried in textbooks or ASHRAE handbooks, presented at a whiteboard pace.

At 772 subscribers, this channel is exactly the under-the-radar engineering teaching that deserves attention.

Most of today's candidates were hashtag-laden Shorts or quick clips with little real teaching content. This one stands out as the final episode of a multi-part Raspberry Pi 5 build series, which means the creator has actually been documenting a project end-to-end rather than just showing a finished gadget.

The hook here is the addition of a SQLite database for persistent guest sign-ins. That's a genuinely useful step up from the toy projects most beginner Pi tutorials stop at — it crosses the line from "blink an LED" into building something that holds real state across reboots. For anyone learning Python on embedded Linux, watching someone wire a database into a kiosk-style UI is a good template: you see schema design, write/read paths, and how to handle a touchscreen front-end against a local DB all in one project.

Because it's the final episode, expect a working demo of the whole kiosk plus a recap of the architecture. It's also worth poking around the earlier episodes if the database layer alone doesn't show enough of the wiring and OS setup. A 45-subscriber channel doing a complete, multi-episode build is exactly the kind of small-creator effort worth a watch.

Most of this week's candidates were hashtag-spam shorts from the same plasma cutting channel, so this Jimmy Riging video stands out as the only one promising a real, sustained project walkthrough. A "Fummins" is the long-running swap nickname for dropping a Cummins diesel into a Ford chassis — in this case, pulling the inline-six out of a 2nd gen Dodge Ram and transplanting it into an F550. That's a non-trivial engineering exercise: motor mounts, transmission bellhousing adapters, wiring harness integration, fuel system plumbing, and cooling all have to be reconciled between two very different platforms.

This first episode focuses on the teardown side — getting the Cummins out cleanly — plus a practical bit of fabrication: using a CNC plasma cutter to modify an engine stand so it can actually hold a 12-valve Cummins, which is heavier and physically larger than most stands are designed for. That combination of diagnosis, fabrication, and heavy diesel wrenching is exactly the kind of content that small-channel builders do better than the polished shops, because you get to see the real decisions and the mistakes.

At 264 subscribers, Jimmy is clearly just starting out, so the production may be rough, but the project scope is ambitious and worth following from episode one.