Daily Digest — 2026-06-28

In August 1966 — three years before Neil Armstrong stepped onto the Moon — Philco-Ford delivered a 600-page final report to NASA's Marshall Space Flight Center titled "Mars Excursion Module Study." It was a complete engineering design for a vehicle to land humans on Mars and return them to orbit. The contract number was NAS8-20262. The first crewed landing was scheduled for November 1981.

The MEM was the lander half of NASA's EMPIRE (Early Manned Planetary-Interplanetary Roundtrip Expeditions) and follow-on UMPIRE studies, which proposed using a Saturn V derivative and NERVA nuclear-thermal upper stage to push a 6-crew vehicle to Mars on a roughly 640-day conjunction-class trajectory. Wernher von Braun personally championed the architecture in his August 1969 memo to Vice President Agnew, two weeks after Apollo 11 splashed down. He proposed twin nuclear-powered ships departing Earth orbit in November 1981.

The MEM itself was a marvel:

• Biconic lifting-body aeroshell, 30 feet across at the base — the same general shape SpaceX is now using on Starship's nose
• Mass at Mars arrival: ~44,000 lb, with a crew of three descending while three orbited (Apollo architecture, scaled up)
• Surface stay: 10 to 40 days
• Ascent stage burned FLOX (fluorine-oxygen) / methane — yes, methane, sixty years before Starship
• Powered by a SNAP-8 radioisotope generator for surface power
• Hypersonic entry from Mach 27 using a 70-degree blunt cone, decelerating to subsonic at ~20,000 ft for a tail-first powered landing

Why did it die? Three reasons, all political, none technical:

1. Nixon's 1970 budget gutted post-Apollo planning. NERVA was cancelled in 1972 despite passing all ground tests (the NRX-A6 ran at full power for 62 minutes). Without nuclear-thermal propulsion, the mass budget for Mars collapsed.
2. Vietnam. NASA's budget fell from 4.4% of federal spending in 1966 to 1% by 1975.
3. The Shuttle decision. NASA traded deep-space capability for a low-Earth-orbit truck that ended up costing more per flight than a Saturn V.

Why it's viable now: Every technical obstacle Philco-Ford flagged in 1966 has been solved or is being solved:

• Methane propulsion is now flight-proven (Raptor, BE-4)
• Hypersonic biconic entry has been validated by Mars Science Laboratory and Perseverance — the MSL aeroshell is geometrically close to the MEM's
• NERVA's successor, DRACO (DARPA/NASA, contracted to Lockheed/BWXT in 2023), is targeting a 2027 in-space demonstration of a nuclear-thermal stage with nearly twice the specific impulse of chemical engines — exactly the capability that died with NERVA
• Closed-loop life support has been continuously operated on ISS for 25 years
• Lifting-body precision landing at Mars density was demonstrated by Perseverance's Sky Crane in 2021

The MEM wasn't science fiction. It had a part number, a contractor, a launch date, and a crew size. NASA didn't fail to design a Mars lander. NASA designed one — and then watched the political wind change and put the binders on a shelf at Marshall, where the original Philco-Ford volumes still sit in the archive.

For over fifty years, object-oriented programming (OOP) has been the dominant way to think about building software. The core idea sounds intuitive: software should mirror reality. If your app deals with users, orders, and products, then you should have User, Order, and Product classes — each bundling the data and the behavior that "belongs" to that thing. Daniel Jackson, an MIT professor and longtime software design researcher, argues in this paper that this foundational assumption is actually wrong — and that decades of pain in software engineering can be traced back to it.

The problem with objects. Jackson's central complaint is that real-world functionality almost never lives cleanly inside one object. Consider a "checkout" feature in an e-commerce app. Which class owns it? The Cart? The Order? The Payment? The User? In practice, the logic gets smeared across all of them, with each object holding a fragment. This is what he calls fragmentation: a single coherent behavior gets shattered into pieces scattered across the codebase, and you have to mentally reassemble it every time you want to understand or change it.

The decades of patches. Jackson points out that much of software engineering's history since OOP has been an attempt to paper over this exact problem. Design patterns (Visitor, Strategy, Observer), aspect-oriented programming, dependency injection frameworks, domain-driven design's "bounded contexts" — all of these, he argues, are workarounds for the fact that objects don't actually carve software at its natural joints.

The alternative: concepts. Jackson proposes organizing software not around things (objects) but around concepts — independent units of user-facing functionality. A concept like "reservation," "upvoting," or "trash bin" is self-contained: it has its own state, its own actions, and its own purpose, and you can understand it without knowing about the rest of the system. Concepts are then composed together (he calls this "synchronization") to build full applications. Crucially, the same concept (say, "comments") can be reused across wildly different apps because it isn't tangled with any particular domain object.

The paper is partly a postmortem of OOP's limitations and partly a manifesto for what comes next. Jackson has been developing "concept design" for years; this piece is his clearest argument for why the industry should move on from the object-first mindset entirely.

Headers don't just route spent gas out — they use pressure waves to pull exhaust out of the cylinder during valve overlap. Get the primary tube length right and you'll add 15-25 hp with no other changes. Get it wrong and you'll lose torque exactly where you need it.

Here's the physics: when the exhaust valve opens, a high-pressure pulse rockets down the primary tube at roughly the speed of sound (around 1,700 ft/sec in hot exhaust gas, ~2x ambient sound speed). When that pulse hits the collector — where multiple primaries merge — it reflects back as a negative pressure wave (rarefaction). If that low-pressure wave arrives back at the exhaust valve during overlap (when intake and exhaust valves are both open), it literally sucks fresh charge through the cylinder. This is scavenging, and it boosts volumetric efficiency above 100%.

The catch: pulse timing depends on RPM. A tube tuned for 7,000 rpm scavenging is too long at 3,000 rpm — the wave arrives after the valve has closed and does nothing. Too short, and the positive pulse can reflect back early and actually push exhaust into the next cylinder.

Rule of thumb for primary length (inches, from valve to collector):

• L ≈ (850 × ED) / RPM_target − 3
• Where ED = exhaust duration in crank degrees from valve opening to BDC (typically ~85-95°)

Example: targeting peak torque at 6,500 rpm with 90° of effective duration: L = (850 × 90) / 6500 − 3 ≈ 11.8 inches. That's why NASCAR Cup headers run roughly 30-34" primaries (tuned for 8,500-9,500 rpm), while a truck header making torque at 3,500 rpm wants 40"+ primaries — often impossible to package, which is why truck headers are usually shorty designs that sacrifice scavenging for fitment.

Primary diameter matters too. Bigger isn't better. A 1.75" primary on a 350 hp small-block scavenges beautifully; bump it to 2.0" and gas velocity drops, killing the pressure pulse. Target ~280-320 ft/sec mean gas velocity at peak power. Diameter is sized to total flow, length is sized to RPM.

The collector is equally critical. A 4-into-1 design gives the strongest single rarefaction pulse — great for high-RPM peak power. A 4-2-1 (tri-Y) pairs cylinders 540° apart in firing order so two smaller pulses combine, broadening the torque curve. Honda's S2000 famously used 4-2-1 to get scavenging from 3,000 rpm all the way to 9,000.

This function reads a log file and counts how many lines contain "ERROR". It looks textbook — open, defer close, scan, count. It passes every unit test against the synthetic fixtures. In production it returns plausible numbers. But the on-call engineer swears there were more errors than this.

package main

import (
    "bufio"
    "os"
    "strings"
)

// CountErrors scans a log file and returns the number of lines
// containing the substring "ERROR".
func CountErrors(path string) (int, error) {
    f, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    count := 0
    scanner := bufio.NewScanner(f)
    for scanner.Scan() {
        if strings.Contains(scanner.Text(), "ERROR") {
            count++
        }
    }
    return count, nil
}

The Bug

bufio.NewScanner ships with a default maximum token size of 64 KiB (bufio.MaxScanTokenSize = 64 * 1024). The instant the scanner encounters a line longer than that — a fat JSON-encoded log entry, a Java stack trace, a base64-blob attachment — Scan() returns false and stashes bufio.ErrTooLong inside scanner.Err().

The for-loop's exit condition can't distinguish "clean EOF" from "I gave up". The code never calls scanner.Err(), so the error is swallowed. Worse, the scanner doesn't just truncate the offending line — it abandons it and every line after it. One oversized line halfway through a 10 GB file means you've counted errors from the first 30% of the file and silently dropped the rest. The function returns (count, nil) with a straight face.

This bug is invisible in tests because fixtures are usually small and uniform. It only bites on real-world data — exactly when you need the tooling to work.

The Fix

Two changes: enlarge the buffer to accommodate realistic line sizes, and always check scanner.Err() after the loop so a truncation failure is surfaced rather than hidden.

func CountErrors(path string) (int, error) {
    f, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    count := 0
    scanner := bufio.NewScanner(f)
    // Allow lines up to 10 MiB; starting buffer is 64 KiB and grows.
    scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)

    for scanner.Scan() {
        if strings.Contains(scanner.Text(), "ERROR") {
            count++
        }
    }
    if err := scanner.Err(); err != nil {
        return count, err  // surface ErrTooLong, I/O errors, etc.
    }
    return count, nil
}

If your input genuinely has no bound on line length, ditch Scanner entirely and use bufio.Reader.ReadString('\n') or ReadBytes, which grow as needed and report partial reads via io.EOF instead of giving up. The Scanner API is optimized for the common case; it trades correctness on pathological input for a clean iterator interface, and that trade is hidden behind a friendly-looking for scanner.Scan().

The deeper lesson: any iterator whose stop condition is a bare bool is hiding an error channel somewhere. In Go, that channel is almost always a separate Err() method, and "I forgot to check it" is one of the most reliable ways to ship a silent data-loss bug.

You've seen flip-flops and latches mentioned dozens of times. Now the foundational distinction that determines whether your design is timing-safe or a race-condition factory: level-sensitive latches are transparent, while edge-triggered flip-flops sample at an instant.

A level-sensitive latch (the SR latch, the D latch) has an enable signal. When enable is high, the output follows the input — it's a wire. When enable goes low, the output freezes at whatever the input was. The "transparent window" lasts as long as enable is asserted. If the input changes three times while enable is high, the output changes three times.

An edge-triggered flip-flop samples only at the instant of a clock edge (rising or falling). For a vanishingly small moment around that edge — the setup/hold window — the input must be stable. Everywhere else, the input can wiggle freely and the output doesn't care.

Why this matters in practice: Imagine a 4-stage shift register built from D latches all sharing one enable line. When enable goes high, data races through all four stages in a single transparent window because each latch is just a wire. You get one stage of shifting per enable pulse-pair, not per stage. Build it from edge-triggered flip-flops and each rising clock edge cleanly advances data exactly one stage. This is why SIPO/PISO shift registers always use flip-flops.

So why do latches exist at all? Three reasons:

• Half the transistors. A D latch is ~6 transistors; a master-slave flip-flop is ~12+. In dense register files (think x86's physical register file with hundreds of entries), latches save enormous area.
• Time borrowing. A transparent latch lets a slow combinational path "borrow" time from the next stage — the data arrives late, but as long as it's stable before the latch closes, it propagates immediately. Flip-flops can't do this; data missing the edge is data missed.
• Lower clock-to-Q delay. Latches add only one gate delay when transparent; flip-flops add two (master + slave).

Rule of thumb: If a master-slave flip-flop has total setup+hold+clk-to-Q of ~150ps at 7nm, two back-to-back pulse latches with a 100ps pulse width can implement the same storage with ~80ps overhead — but only if your CAD tool can verify the pulse never gets wider than the shortest combinational path between latches (or data races through two stages).

Real-world example: Intel's Pentium 4 famously used pulse-latch-based design throughout its critical paths to hit 3+ GHz at 130nm; AMD's contemporary Athlon used flip-flops and ran ~25% slower per clock-period budget but was vastly easier to verify.

A solar panel is a nonlinear current source. Its I-V curve has a distinctive knee, and somewhere on that knee sits a single operating point where P = V × I is maximized — the Maximum Power Point (MPP). Connect the panel directly to a battery and you'll clamp it to the battery voltage, which is almost never at the MPP. A 100W panel might deliver only 60W. MPPT circuits dynamically adjust the load impedance the panel sees, keeping it parked at the MPP as sunlight, temperature, and shading change.

Architecturally, an MPPT controller is a DC-DC converter (usually buck, sometimes boost or buck-boost) with a smart control loop. Instead of regulating output voltage, the loop regulates the input voltage to whatever value extracts maximum power. The converter's duty cycle becomes the knob that transforms the panel's V_MPP into whatever the battery needs.

The most common tracking algorithm is Perturb and Observe (P&O):

• Measure V_panel and I_panel, compute P = V × I
• Perturb the duty cycle by a small step ΔD
• If P increased, keep stepping the same direction; if P decreased, reverse
• Repeat every few milliseconds

P&O oscillates around the MPP by ±ΔD — a fundamental tradeoff between tracking speed and steady-state efficiency. Incremental Conductance is smarter: it uses dI/dV = -I/V at the MPP, so it knows when to stop perturbing. Better for fast-changing irradiance (passing clouds).

Concrete example: A 36-cell panel rated 100W, V_MPP ≈ 18V, I_MPP ≈ 5.5A, charging a 12V lead-acid battery (float ~13.8V). Direct connection: panel pulled to 13.8V, output ≈ 13.8V × 5.7A ≈ 79W (and you've shifted off the knee — likely much worse). With a buck MPPT: panel stays at 18V × 5.5A = 99W input, converter at 96% efficiency delivers ~95W to the battery at 13.8V (≈6.9A charging current). You gained 20% — pure software cleverness on top of a switching converter you'd build anyway.

Rule of thumb for step size: ΔD ≈ 0.5–1% of full duty cycle per iteration, with a 1–10 ms update rate. Too small and you can't keep up with clouds; too large and steady-state ripple eats your efficiency gain. A panel's MPP voltage drifts about -0.4%/°C with cell temperature, so cold mornings shift V_MPP up noticeably — your tracker handles this automatically.

Watch for: local maxima under partial shading (bypass diodes create multiple peaks — P&O can get stuck on the wrong one), and input capacitor sizing (must hold V_panel stable between perturbations, typically 470µF–2200µF).

Drop a cylinder into a flowing stream and the fluid can't stay attached to its back side. Instead, alternating vortices peel off one side, then the other, forming a Kármán vortex street. The shedding frequency is almost perfectly proportional to flow velocity over a wide range — which is the entire basis of the vortex flow meter.

The governing relationship is the Strouhal number:

• St = f · d / v
• f = shedding frequency (Hz), d = bluff body width (m), v = fluid velocity (m/s)
• For a properly shaped bluff body (typically trapezoidal or T-shaped), St ≈ 0.27 and stays nearly constant from Reynolds number ~10,000 up to ~7,000,000

That constancy is the magic trick. Frequency depends only on velocity and a fixed geometric dimension — not on fluid density, viscosity, temperature, or pressure. The meter becomes a digital pulse generator: count pulses, get volumetric flow.

How the pulses get detected: the vortices create alternating pressure differentials across the bluff body. A piezoelectric crystal, capacitive sensor, or thermistor mounted in or just downstream of the shedder picks up the oscillation. No moving parts in the flow path — just a stationary obstruction and a sensor.

Real-world example: a 4-inch (102 mm) vortex meter measuring steam in a process plant has a shedder bar ~25 mm wide. At 15 m/s steam velocity, f = 0.27 × 15 / 0.025 ≈ 162 Hz. Counting pulses for one second gives you the average velocity directly. Multiply by cross-sectional area (0.0081 m²) and you have 0.122 m³/s of volumetric flow — and since steam density is known from pressure/temperature, you also get mass flow.

Where vortex meters dominate:

• Steam metering (their killer app — they tolerate high temperature, no moving parts to seize)
• Compressed air and industrial gases
• Clean liquids like water, solvents, and process chemicals
• Cryogenic services

Where they fail:

• Low flow — below ~Re 10,000, vortex shedding becomes erratic; meters have a hard low-end cutoff (turndown typically 20:1 to 30:1)
• Pulsating flow — reciprocating compressors upstream wreck the signal
• Dirty or slurried fluids — particulates erode the shedder edge, drifting the K-factor
• Two-phase flow — bubbles or droplets disrupt clean shedding

Installation rule of thumb: 15–20 pipe diameters of straight run upstream, 5 downstream. Vortex meters are exceptionally sensitive to swirl from elbows and valves — worse than orifice plates. Flow conditioners can shorten the upstream requirement but add pressure drop.

In 1919, as American industry was being transformed by precision instruments — pyrometers that could read steel temperatures to the degree, Brinell and Rockwell testers that could quantify hardness, and a whole new vocabulary of "scientific management" — a construction engineer named John Lord Bacon and his collaborator Edward R. Markham slipped a quiet warning into the preface of the third edition of a small technical manual.

The introduction of heat measuring and hardness testing instruments, together with various other modern appliances, and up to date systems of doing work have made necessary a broader knowledge of heat-treating methods than was formerly the case: for after all the most important factor is the man doing the work.

Read that last clause again. In a book celebrating the arrival of measurement, the authors insist — almost defensively — that the instruments don't displace the craftsman. They make him more necessary, not less.

Bacon was an instructor in Forge Practice and Machine Design at Lewis Institute in Chicago (later absorbed into the Illinois Institute of Technology), and Markham described himself as a "Consulting Engineer Specializing in Heat Treatment of Steel." These were not romantic anti-modernists. They were engineers who wrote a textbook published by John Wiley & Sons, the same press that helped lay the foundation of American industrial education. They wanted their book on the desks of factories that were buying pyrometers.

And yet they understood something that the next century of industry would repeatedly forget and rediscover: a tool that returns a number does not return a decision. A pyrometer can tell you the steel is at 1450°F. It cannot tell you whether this particular billet, hammered this way, for this part, is ready to quench. That judgment lives in a person who has burned, cracked, and over-tempered enough pieces to feel the difference.

The earlier preface, written by Bacon alone, made the same argument about pedagogy:

The author believes that the text book should be used to explain principles and give examples, not to give minute explicit directions for making a set of exercises.

In other words: don't teach the recipe. Teach the principle, and let the student earn the recipe by ruining a few pieces of steel.

What's striking is how directly this maps onto modern debates about automation and AI. Every generation hears the same promise — that the new instrument will deskill the work, that judgment will become an interface, that the craftsman is obsolete. And every generation discovers, around the time the instruments are fully deployed, that someone still has to interpret the readout, recognize the edge case, and decide when the standard procedure doesn't apply.

Bacon and Markham wrote that line in 1919, watching forge shops fill up with thermocouples. The diagnosis travels remarkably well to a 2026 reader watching codebases fill up with copilots.

On a Paris afternoon in 1907, a French engineer named Édouard Belin placed a photograph of a man's face on a rotating drum, shone a light on it, and watched a selenium photocell translate the image's light and dark patches into electrical pulses. Those pulses traveled down an ordinary telephone wire to a receiver across the room, where a synchronized stylus etched the same face onto carbon paper. The Belinograph was born.

Belin patented refined versions of the device in French Patent 440,597 (1912) and US Patent 1,074,098 (filed 1912, granted September 30, 1913). The mechanism was elegant: the sending drum and receiving drum spun in lockstep using tuning-fork synchronization. A photocell scanned the original line-by-line in a tight helix, converting brightness to current. At the far end, the current modulated either ink intensity or a chemical reaction on coated paper. A full photograph transmitted in roughly 12 minutes over standard phone lines.

The first transatlantic Belinograph transmission happened in 1921 — a photograph sent from Annapolis to Belin's lab outside Paris. By 1925, AT&T's commercial "Wirephoto" service (licensed from Belin's principles) let the New York Times publish overseas photographs in next-day editions. The 1937 Hindenburg disaster reached American newspapers as Belinograph images within hours.

What's astonishing is what Belin actually invented:

• The flatbed scanner — every modern scanner is a Belinograph drum unrolled flat, with a CCD sensor in place of the selenium cell.
• The fax machine — Group 3 fax (the standard from 1980 to today) uses the exact line-by-line raster scan Belin patented in 1912, just digitally encoded.
• Progressive image transmission — the idea that an image arrives as a sequence of scan lines, not all at once, is foundational to JPEG progressive rendering and to how every web browser streams an image as it downloads.
• Wirephoto journalism — the entire visual culture of 20th-century newspapers, magazines, and eventually internet news depends on the assumption that an image taken in one place can appear in another within hours. Belin made that assumption real.

The mechanism is also a perfect early example of analog-to-digital-to-analog signal conversion: a continuous image becomes a serial electrical waveform, travels through a narrow-bandwidth channel, and reconstitutes as a continuous image. Replace the selenium cell with a CMOS sensor, the telephone line with TCP/IP, and the carbon stylus with a laser printer — you have a 2026 multifunction office device. The architecture didn't change; only the components got smaller and faster.

Belin kept inventing. His 1922 "Belino" portable let war correspondents send field photographs from any hotel with a phone jack — the spiritual ancestor of every photojournalist uploading from a war zone via satellite phone today. He also built early television scanners in the 1920s that influenced both John Logie Baird's mechanical TV and later electronic systems.

Could the Belinograph be rebuilt better today? It already has been — roughly 400 million times. Every smartphone with a "scan document" feature is running Belin's 1912 algorithm in software, sampling the image as a raster of brightness values and transmitting them serially over a wireless link. The selenium photocell became a silicon photodiode; the tuning fork became a quartz crystal; the phone line became Wi-Fi. The idea — an image is just a sequence of light measurements — is unchanged after 114 years.

This is a delightfully unusual project: a 3D racing game built for KaiOS, the lightweight operating system that powers feature phones like the Nokia 8110 4G, JioPhone, and various low-cost devices popular across Africa, India, and emerging markets. While the rest of the gaming world chases photoreal 4K experiences on RTX hardware, this developer is squeezing 3D rendering out of a platform that typically tops out at a 240×320 screen, a numeric keypad, and a few hundred megabytes of RAM.

What makes this interesting:

• Constrained-platform engineering. KaiOS apps are essentially HTML/CSS/JavaScript bundles running on a Gecko fork. Implementing anything resembling 3D — even pseudo-3D scanline tricks à la OutRun, or a minimal software rasterizer — is a genuine technical challenge on this hardware.
• Audience that's usually invisible. Feature-phone users in the Global South are a massive, often-ignored market. Building games for them is meaningful work, not just a curiosity.
• D-pad and numeric-keypad input design. No touchscreen, no gamepad — just T9-style keys. Designing a racing game around that input scheme forces thoughtful UX decisions.

Who might find it useful:

• KaiOS / feature-phone developers looking for an example codebase of something more ambitious than a to-do app.
• Web devs curious about low-end JavaScript performance — the same tricks (manual canvas pixel manipulation, avoiding GC, lean asset loading) apply to old Android Go devices and smart TVs.
• Hobbyists drawn to retro-style pseudo-3D racers in the lineage of Pole Position or Lotus Turbo Challenge.

The repo has zero stars and no documentation yet, but the niche alone makes it worth a peek. If the author adds a README and a short demo video, it could easily attract the KaiOS dev community on GitHub.

DRAM has a dirty secret: writes are slower than reads, not because the cells take longer, but because switching the bus from read mode to write mode (and back) costs cycles you'll never get back. A read-to-write turnaround on DDR5 burns roughly 7-15 ns of dead bus time. Do that on every write and you waste 30%+ of your memory bandwidth on direction-change overhead.

The memory controller's solution: don't drain writes when they arrive — hoard them in a write queue, then flush them in a burst. This is the write drain policy.

Two thresholds control it:

• High watermark — when the write queue fills past, say, 32 of 64 entries, the controller stops accepting new reads and aggressively drains writes until the queue empties.
• Low watermark — when the queue empties to, say, 8 entries, the controller flips back to read mode and resumes serving loads.

Between watermarks, reads have priority. The controller only pays the read→write→read turnaround penalty twice per drain cycle, instead of once per write. If you drain 24 writes in a burst, you've amortized the ~15 ns turnaround across all 24 — about 0.6 ns of overhead per write instead of 15.

Real-world example: a database doing a checkpoint flushes thousands of dirty pages. Without write batching, every flushed cache line would force a bus turnaround, and the checkpoint would crawl. With drain policy, the controller pools the writes and rips through them in a burst — checkpoint throughput can be 3-5× higher.

But there's a cost: reads issued during a drain burst sit and wait. If your latency-sensitive request lands right when the controller starts a write drain, you eat tens to hundreds of nanoseconds of unexpected stall. This is one reason why "tail latency" on memory-bound workloads gets ugly under write pressure — your p99 reads are the ones that arrived during a drain.

Rule of thumb: if your workload is read-dominated (>80% reads), drain policy is invisible. If it's write-heavy or mixed, every read has a probability roughly equal to (write queue occupancy / queue depth) of getting stuck behind a drain. A 50%-full write queue means roughly half your reads may hit drain stalls.

Some controllers expose tuning knobs (Intel's WrPreEmpt, AMD's write drain thresholds in BIOS) to bias the policy toward latency or bandwidth depending on workload.

Homebrew development for the Nintendo 64 has long been one of the most punishing corners of the retro scene. The console's bizarre architecture — the Reality Coprocessor with its programmable RSP microcode, the cache-hostile RDRAM, the legendarily painful texture cache — has historically meant that anyone wanting to ship an N64 game needed to write half a graphics pipeline from scratch. Pyrite64 is part of a quiet revolution that's finally making this hardware approachable.

The project layers a complete game engine and editor on top of two important pieces of modern N64 infrastructure:

• Libdragon — the open-source N64 SDK that replaced Nintendo's proprietary, NDA-encumbered libultra. It's GCC-based, MIT-licensed, and means you no longer need a leaked devkit to build for the platform.
• tiny3d — a newer custom RSP microcode that delivers dramatically better triangle throughput than libultra's stock microcodes, with proper perspective-correct texturing and a friendlier API.

What makes Pyrite64 noteworthy isn't just that it runs on real hardware — it's that the author (HailToDodongo, who also maintains tiny3d) is packaging an actual editor workflow on top of this stack. Historically the N64 homebrew flow has been: write C, cross-compile, copy to flashcart, pray. Adding an editor with scene composition, asset import, and iteration loops is the kind of tooling jump that 8- and 16-bit homebrew scenes went through years ago but which the N64 has stubbornly resisted.

For a technical audience this is interesting on several fronts:

• Microcode engineering — tiny3d is one of the few non-Nintendo RSP microcodes that actually ships in real projects, and Pyrite64 is a window into what you can build on top of custom microcode.
• Constrained-system design — 4MB of RAM, a 4KB texture cache, no shaders. Every decision in the engine is a study in deliberate tradeoffs.
• Editor architecture for embedded targets — round-tripping assets and scene data into a system this small is non-trivial.

The N64 homebrew renaissance — see also the recent flood of new commercial N64 releases on cartridge — is being quietly enabled by exactly these kinds of projects. Pyrite64 deserves more eyes simply because it's the kind of foundational tooling that determines whether a homebrew scene stays a hobbyist curiosity or grows into something that ships polished games.

Of the ten postings in this thread, Nova Credit's is the most strategically revealing — not because of what it explicitly lists, but because of the structural problem the company is quietly solving and what it implies about the future of identity infrastructure.

The business model is the tell. Nova Credit is building cross-border credit bureau interoperability — convincing foreign credit bureaus (Experian UK, CIBIL India, Circulo de Credito Mexico, etc.) to share data with US lenders in a way that complies with the FCRA. That is fundamentally a data integration and regulatory arbitrage business dressed up as a fintech consumer product. The fact that they're onsite-only in SF or NYC, even in a thread where Red Hat is going fully remote and Code for America embraces REMOTE, signals heavy reliance on in-person work with regulated partners (banks, lenders, compliance officers).

Stage signals:

• ~50 people + $50M Series B (Kleiner, Index, Canapi, General Catalyst) = post-product-market-fit, scaling distribution. Canapi specifically is the banking consortium fund — that's a strategic, not financial, lead. They have customer pipeline locked in.
• The pitch leads with TAM ("millions of immigrants") and lender ROI ("new consumers for lenders") — they're selling to enterprises now, not chasing growth metrics.
• The truncated posting cuts off the actual roles, which is itself a tell: the founder is pitching the mission, not the engineering puzzle. They're hiring for belief, not stack-curiosity.

What the posting doesn't say is loud. No mention of Python, Go, ML, or a specific stack. Compare to Proton (explicit Android/iOS/Go/SRE) or TestDome (Vue.js + ASP.NET Core). Nova Credit is hiring people who can navigate FCRA compliance, ECOA, GDPR cross-border data transfer, and bank procurement cycles — the engineering is table stakes; the moat is legal and partnership work.

Green flags: Concrete mission with a real underserved market (immigrant credit access is genuinely broken), tier-1 investors with strategic value, sane headcount-to-funding ratio (~$1M raised per employee — not bloated).

Red flags: Onsite-only in March 2020 when the thread is full of "currently remote during quarantine" notes (Clyde) suggests cultural inflexibility — or, more charitably, regulated workflows they can't move home. Either way, candidates should ask. Also: cross-border credit data is a wedge product. The question is whether they become the rails for global identity verification (huge) or get acquired by Experian (fine, but capped).

For decades, Linux ran a periodic timer interrupt — the "tick" — at 100, 250, or 1000 Hz on every CPU. Each tick the kernel updated jiffies, charged CPU time to the running task, checked for scheduling decisions, expired timers, and ran RCU callbacks. On an idle core, this meant waking up 1000 times a second to do almost nothing. On a busy core running one pinned thread, it meant 1000 unwanted context switches per second into kernel mode.

The tickless kernel (NO_HZ) fixed this in stages:

• CONFIG_NO_HZ_IDLE (2007): when a core goes idle, cancel the next tick. Reprogram the hrtimer to fire only when the next real timer is due. Idle cores stop waking up, saving power on laptops and reducing wakeups on packed servers.
• CONFIG_NO_HZ_FULL (2013): even when a core is running a task, skip the tick — provided exactly one runnable task is on that CPU. The scheduler has nothing to decide. The accounting can be deferred. RCU callbacks get offloaded to housekeeping CPUs.

The catch with NO_HZ_FULL: it isn't free, and it isn't automatic. You boot with nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15, dedicate CPU 0–1 as housekeeping cores, pin one userspace thread per isolated CPU, and ensure nothing else schedules there. Add a second runnable task and the tick comes right back.

Real-world example: high-frequency trading and DPDK packet-processing rigs. A market-data handler pinned to an isolated NO_HZ_FULL core can run a tight poll loop on a NIC ring buffer for seconds without a single kernel entry. Without it, every millisecond the timer interrupt would evict ~32 KB of L1-D, blow away branch predictor state, and add 3–8 µs of jitter — catastrophic when your tail-latency SLO is 10 µs. Cloudflare's published packet-processing measurements showed p99.99 latency dropping from ~80 µs to ~12 µs after enabling NO_HZ_FULL with proper isolation.

Rule of thumb: at HZ=1000, a tick costs roughly 1–3 µs of direct work plus another 2–5 µs of cache pollution. That's ~0.5% CPU overhead you can't see in top — and 100% of your jitter budget if you care about microsecond tails.

Check whether a core is actually tickless: cat /proc/interrupts | grep LOC and watch the per-CPU local timer interrupt count. On an isolated NO_HZ_FULL core running one busy thread, that counter should increment maybe once per second (for vmstat updates), not 1000 times.

Usenet predates the World Wide Web by more than a decade, and its transport protocol — NNTP, defined in 1986's RFC 977 — was designed in an era when "authentication" meant "you're on a trusted host that peers with my trusted host." Servers exchanged news articles freely. There were no passwords, no accounts, no rate limits. By the late 1990s, that model was collapsing. Commercial ISPs were selling Usenet access to millions of subscribers, spammers had discovered the network's open relay-like properties, and operators desperately needed a way to say "prove who you are before I let you post." RFC 4643 is the formal, standards-track answer to that need.

The problem it solves. Before 4643, NNTP authentication existed only as an informational hack — RFC 2980's AUTHINFO USER / AUTHINFO PASS commands, lifted almost verbatim from FTP. Every implementation interpreted it slightly differently. There was no negotiation, no advertisement of mechanisms, no way to plug in modern auth like Kerberos or one-time passwords, and no clear interaction with TLS. RFC 4643 cleans all of this up and binds it properly to RFC 3977 (the modern NNTP rewrite from the same year).

Key design decisions.

• Two mechanisms, one framework. The RFC defines AUTHINFO USER/PASS (the legacy username/password flow, retained for compatibility) and AUTHINFO SASL, which delegates to the Simple Authentication and Security Layer (RFC 4422). SASL is the same plumbing used by IMAP, SMTP submission, XMPP, and LDAP — so NNTP suddenly inherited PLAIN, CRAM-MD5, DIGEST-MD5, GSSAPI, EXTERNAL, and anything else SASL gained later.
• Capability advertisement. The server lists supported mechanisms in its CAPABILITIES response under an AUTHINFO line. Clients no longer have to guess or probe.
• TLS-aware. Plaintext mechanisms must be refused unless the connection is encrypted (or the server is explicitly configured to permit them). This was a notable hardening — RFC 2980 had no such requirement, and many Usenet passwords had been crossing the wire in the clear for years.
• State reset on success. After successful authentication, the server resets to an "initial" state — any selected newsgroup is forgotten — so authorization decisions apply uniformly. A small detail, but it prevents whole classes of "I authenticated after selecting a restricted group" bugs.
• Reject-on-fail, retry permitted. Failed AUTHINFO doesn't drop the connection; the client may try again with a different mechanism. This matters for clients walking a capability list from strongest to weakest.

Why it still matters. Usenet didn't die — it shrank into a quieter, paid corner of the internet dominated by binary groups and a handful of text-discussion holdouts. Every major commercial provider (Giganews, Eweka, Newshosting) authenticates with AUTHINFO as defined by 4643, almost universally over TLS on port 563 (NNTPS). If you've ever configured a newsreader in the last fifteen years, you've used this RFC. More broadly, 4643 is a clean case study in retrofitting authentication onto a protocol designed without it — a pattern that recurred for SMTP (RFC 4954), IMAP (RFC 3501), and others, all leaning on SASL to avoid reinventing the wheel. The lesson is consistent: when you bolt auth onto a legacy protocol, advertise capabilities, defer to SASL, and require TLS for anything that sends a password in cleartext.

Quirky history. The authors, Jeffrey Vinocur and Ken Murchison, were also instrumental in the broader NNTP modernization effort — RFCs 3977, 4642 (TLS for NNTP), 4643 (this one), and 4644 (streaming feeds) all shipped together in October 2006, a coordinated cleanup of a protocol that had been frozen for two decades. It's one of the more thorough "let's bring this old workhorse into the modern era" efforts the IETF has ever produced.

The asker is training a BPE tokenizer with "supermerges" (arXiv 2504.00178) on a 160 GB corpus. Standard BPE only needs a word-frequency dictionary because merges happen within tokens — order between words is irrelevant. Supermerges break that assumption: they merge adjacent words in the running text, so training must see the corpus as a sequence, not a multiset. That defeats every shortcut that makes classical BPE training tractable.

Why it's hard: Each merge iteration rewrites the sequence (every chosen pair collapses to a new symbol), shifts adjacency boundaries, and changes the counts of neighboring pairs. With 160 GB of tokens you cannot keep the sequence in RAM, and you cannot reduce it to a frequency table because the adjacency graph itself is the input. Naively re-scanning the whole corpus per merge means thousands of full passes over disk — the linear regression the asker fit almost certainly extrapolates to weeks or months.

A workable direction — incremental external-memory BPE:

• Encode the corpus once as a packed u32/u64 stream on disk (memory-mapped). Treat it as an array of symbol IDs, not text.
• Build a global pair-count table in a single streaming pass: a HashMap<(u32,u32), u64>, or better, a count-min sketch followed by an exact recount for the top-K candidates. This fits in RAM even when the corpus doesn't.
• Maintain an inverted index from pair → file offsets where that pair occurs, written to disk as sorted runs (one append-only file per pair, or a single sorted-by-pair file built with external mergesort). This is the key data structure: it turns "find every occurrence of the winning pair" from a 160 GB scan into a localized read.
• Per merge iteration: pick the top pair, stream its occurrence list, rewrite those positions in the mmap'd corpus (collapsing two symbols into one, marking the freed slot with a tombstone or using a gap-buffer/rope-of-chunks layout), and emit delta updates to the pair-count table: −1 for the four neighbor pairs that disappeared, +1 for the two new neighbor pairs that appeared. Append the new pair's positions to its inverted-index file.
• Chunk the corpus by document boundaries so writes stay sequential within a chunk and you can parallelize across chunks with Rayon — supermerges presumably don't cross document boundaries anyway.

Gotchas: tombstones balloon over many iterations — periodically compact each chunk. The inverted-index files for very common pairs (early iterations) will be enormous; a hybrid of "scan if pair frequency > threshold, index otherwise" avoids paying index-maintenance cost for pairs you'd read sequentially anyway. Watch for the classic BPE bug where overlapping occurrences of the same pair (e.g. AAA with pair (A,A)) get double-merged — use a left-to-right greedy sweep within each occurrence list. Finally, the delta updates must be applied atomically per position, since a single merge changes counts for both neighbors; doing them out of order corrupts the table.

Optimistic concurrency control bets that conflicts are rare and retries are cheap. Pessimistic concurrency control makes the opposite bet: it assumes conflicts are likely or that retrying is catastrophically expensive, so it acquires a lock before touching the data and holds it until the transaction commits. Other transactions wait. No CAS gymnastics, no retry storms — just an old-fashioned queue.

The trade-off is brutal but honest. You give up throughput and concurrency in exchange for predictability. A transaction that grabs the lock will either succeed or deadlock — it will never do five seconds of work only to be told "someone else got there first, start over."

When pessimistic wins:

• High contention. If 80% of transactions touch the same row, optimistic retries will thrash. Locking serializes them cleanly.
• Long or expensive transactions. Recomputing a 10-second report after a conflict is worse than waiting 10 seconds for a lock.
• Side effects mid-transaction. If your transaction sends an email or charges a card before commit, you cannot safely retry.
• Hard external invariants. Seat booking, inventory decrement, financial ledger entries — anywhere "looked fine when I checked" isn't good enough.

Real-world example: An airline seat-booking service. Two agents try to sell seat 14C at the same time. With optimistic control, both read "available," both write "sold," and the version check rejects one — but only after the customer's card was authorized. With SELECT ... FOR UPDATE, the first agent's transaction locks row 14C; the second blocks until the first commits, then re-reads and sees "sold." No double-booking, no refund flow, no apology email.

Rule of thumb: If your retry rate under optimistic control exceeds ~10–15%, switch to pessimistic. Below that, the lock overhead and reduced concurrency cost more than the occasional retry. Measure conflict rate in production before choosing — most teams pick a strategy by reflex and pay for it later.

The pitfalls are real:

• Deadlocks. Always acquire locks in a consistent order (e.g., by primary key ascending). Set a lock timeout — never wait forever.
• Lock duration. Hold locks for the shortest possible window. Do all reads and computation before the locked section if you can.
• No long-running user think time inside the lock. Locking a row while a user fills out a form is how you destroy throughput. Use a soft application-level reservation with a TTL instead.
• Lock escalation. Some databases promote row locks to table locks under pressure. Know your engine's behavior.