Daily Digest — 2026-07-14

On December 14, 1984, Grumman test pilot Chuck Sewell rolled an aircraft down Edwards AFB runway 04 that looked like it had been assembled backwards. The wings swept forward at 33 degrees. The canards sat ahead of the wings. The whole thing was aerodynamically unstable to the point that it would tumble out of the sky in 0.4 seconds without computer intervention. It flew perfectly.

The Grumman X-29 was DARPA's answer to a question aeronautical engineers had been asking since Hans Wocke's Junkers Ju 287 first flew forward-swept in 1944: what if you flipped the wing? The theoretical payoff was enormous. Forward-swept wings delay the transonic stall to the wing root instead of the tip, meaning the ailerons keep working at angles of attack where a conventional fighter departs controlled flight. Wind tunnel data suggested a 20% reduction in trim drag, 35% better aerodynamic efficiency in the transonic regime, and superior turn rates at high alpha. You could theoretically dogfight at 45 degrees angle of attack while your opponent was falling out of the sky at 25.

There was one catch: aeroelastic divergence. A forward-swept wing wants to twist itself apart. Aerodynamic load bends the wingtip up, which increases the angle of attack, which increases the load, which bends it more. On any metal wing, the feedback loop snaps the spar before you finish the sentence. This is why every serious forward-swept design from 1944 to 1980 died in the wind tunnel.

The X-29 killed the problem with aeroelastically tailored graphite-epoxy composite skins. By orienting the composite plies at specific angles, Grumman engineers built a wing that twisted the opposite direction under load — as it bent up, it rotated leading-edge-down, canceling the divergence. It was a materials science victory dressed as an aerodynamics program.

Between 1984 and 1992, the two X-29 prototypes flew 422 missions between them (242 for ship 1, 180 for ship 2), hitting 67 degrees angle of attack in controlled flight. F-16s topped out around 26. The flight control system ran three redundant digital computers processing pilot inputs 40 times per second to keep the inherently unstable airframe from disassembling itself.

Then it just... stopped. In 1992, NASA parked both aircraft. The Air Force never ordered a production variant. The reasons were embarrassingly mundane: the Cold War ended, the ATF competition (which became the F-22) had already committed to a conventional swept-wing planform, and the composite manufacturing was expensive enough that even the marginal gains couldn't justify the retooling. The Su-47 Berkut flew the same concept for Russia in 1997 and suffered the same fate.

Here's why 2026 should look again. Every objection that killed the X-29 has evaporated. Automated fiber placement has cut aeroelastically tailored composite layup costs by an order of magnitude — Boeing does it routinely on the 787. Flight control computers that required a $2M triplex system in 1984 now run on a $30 STM32. And the strategic environment has flipped: we suddenly care intensely about post-stall maneuverability, short-field performance, and turn rate for contested-airspace fighters facing S-400 batteries. The X-29's advantages at high alpha are exactly what a 6th-gen fighter needs. The data exists. The physics works. The airframes sit at Edwards and Wright-Patterson. Nobody is looking at them.

Imagine handing a very eager intern a huge codebase and saying "find me bugs." They come back with a stack of reports — and half of them turn out to be nonsense: bugs that look plausible if you squint, but that can never actually happen when the program runs. You've now spent your whole afternoon disproving imaginary problems. That's roughly the state of using large language models to hunt for bugs today. LLMs are great at pattern-matching suspicious code, but they're notoriously prone to false alarms, and each false alarm burns real developer time.

The authors of Mizzle propose a clever fix borrowed from theoretical computer science: make the LLM prove its work. Specifically, when the model reports a bug, it must attach a machine-checkable mathematical proof that the bug is actually reachable during real execution. If the proof checks out, the bug is real. If it doesn't, the report is silently discarded. No more wasted afternoons.

To make this possible, they built Mizzle, a new concurrent incorrectness logic. Traditional program logics prove that a program is correct — that nothing bad ever happens. Incorrectness logic flips this around: it proves that something bad definitely can happen, by reasoning about paths through the code that are actually reachable rather than paths that might merely seem possible. The "concurrent" part is the hard bit. Multithreaded bugs — races, deadlocks, weird interleavings — are exactly the kind LLMs both love to flag and love to hallucinate about, because reasoning about thread interleaving is genuinely tricky.

Mizzle's contributions boil down to:

• A logic expressive enough to describe real concurrent bugs (data races, atomicity violations, ordering issues).
• A completeness result: if a bug is genuinely reachable, Mizzle can, in principle, produce a proof of it. This matters because it means the framework won't accidentally rule out real bugs alongside the fake ones.
• A workflow where the LLM acts as the creative bug-hunter and Mizzle acts as the skeptical referee.

The bigger picture: as LLMs get shoved into more and more parts of software engineering, we keep hitting the same wall — they're plausible but unreliable. The interesting move here is not "make the LLM smarter" but rather wrap the LLM in a formal verifier that only lets grounded claims through. It's a template that could generalize well beyond bug-finding: any place an LLM emits a claim that can be mechanically checked, you can build a similar guardrail.

Every intake port has two curves: the short-side radius (the tight turn on the bottom, near the valve guide boss) and the long-side radius (the gentle sweep along the top, or "roof" of the port). Amateur porters obsess over the short side because it's where flow visibly separates. Professional porters know the long side sets the port's personality — and getting it wrong ruins a head that flows great on the bench and runs like garbage on the dyno.

The long-side radius is the outer wall of the port's turn as air sweeps down toward the valve. Air wants to hug this wall due to the Coanda effect — it follows curved surfaces as long as the curvature is gentle enough. A well-designed long side keeps flow attached all the way to the valve seat, feeding the upper half of the valve curtain (the annular gap between valve head and seat).

Here's the trap: if you grind the roof too aggressively — opening it up to make the port "look bigger" — you increase the radius of curvature at the top but flatten it near the valve. Air detaches from the wall right where it needs to turn downward into the cylinder. The port flows great in a straight pull on the bench (which measures steady-state CFM) but loses tumble and directional bias into the chamber. Combustion suffers. You gained 15 CFM and lost 20 lb-ft of torque.

Real-world example: the LS3 rectangular-port head. GM's factory long-side has a subtle "hump" about an inch before the valve — engineers put it there deliberately to redirect flow downward into the cylinder rather than letting it shoot straight at the far cylinder wall. Ham-fisted porters grind this hump flat to "smooth the roof." Result: the head picks up 10-15 CFM at high lift but loses mid-lift flow and torque below 5000 RPM. The factory hump was working.

Rule of thumb: the long-side radius should be roughly 1.5× to 2× the port's minimum cross-sectional height. Tighter than 1.5× and flow separates. Larger than 2× and you've wasted port volume — velocity drops, and the port becomes lazy at low lift.

The other subtlety: long-side radius interacts with valve angle. A canted-valve head (like a Chevy Big Block) needs a different long-side geometry than a parallel-valve head. Copy the wrong shape from a magazine article and you'll build a port that fights its own valve.

Don't touch the roof unless you understand what the OEM was doing. It usually knew more than you.

This script cleans a cache directory. The --force flag is meant to skip the confirmation prompt. Nightly CI runs it with --force false to get the safe, interactive behavior (no prompt gets answered, so nothing gets deleted). It worked in staging. In production, it wiped the cache every night for a week before anyone noticed.

import argparse
import shutil
import sys

def parse_args():
    parser = argparse.ArgumentParser()
    parser.add_argument('--force', type=bool, default=False,
                        help='Skip the confirmation prompt')
    parser.add_argument('--cache-dir', default='/var/cache/myapp')
    return parser.parse_args()

def main():
    args = parse_args()
    if args.force:
        print(f"Force-deleting {args.cache_dir}")
        shutil.rmtree(args.cache_dir)
    else:
        response = input(f"Delete {args.cache_dir}? [y/N]: ")
        if response.strip().lower() == 'y':
            shutil.rmtree(args.cache_dir)
        else:
            print("Cancelled.")

if __name__ == '__main__':
    main()

The CI invocation: python clean_cache.py --force false --cache-dir /var/cache/prod. The engineer read that as "force is false, so prompt for confirmation." It read that way to the code reviewer, too.

The Bug

argparse's type= is a callable that's applied to the raw string argument. When you write type=bool, argparse calls bool("false") on the incoming string. And bool() of a non-empty string is always True. Try it: bool("false"), bool("no"), bool("0"), bool("False") — every single one returns True. The only way to get False is to pass an empty string, which requires shell-escaping like --force "".

So --force false sets args.force = True, which takes the rmtree branch with no prompt. The cache vanishes. Worse, this looks correct to anyone who doesn't know the trap — the argument name, the value, and the flag semantics all read English-perfectly, and the code "does what it says" as far as the type system is concerned.

The staging cache existed but was empty and rebuildable, so nobody noticed the difference between "prompt cancelled" and "rmtree of nothing." Production had a 40GB cache that took two hours to rebuild.

The Fix

Boolean CLI flags should almost never take a value. Use action='store_true' (presence means true), or on Python 3.9+, BooleanOptionalAction, which gives you both --force and --no-force for free:

parser.add_argument('--force', action=argparse.BooleanOptionalAction,
                    default=False, help='Skip the confirmation prompt')

Now --force sets it true, --no-force sets it false, and --force false raises an argument error instead of silently doing the opposite of what you meant.

If you truly need a value-taking boolean (config file compatibility, say), write the parser explicitly and reject anything ambiguous:

def strict_bool(s):
    if s.lower() in ('true', '1', 'yes'):  return True
    if s.lower() in ('false', '0', 'no'):  return False
    raise argparse.ArgumentTypeError(f"expected boolean, got {s!r}")

parser.add_argument('--force', type=strict_bool, default=False)

The general rule: any time your type= callable would accept a string it shouldn't, you have a silent-coercion bug waiting to be triggered by the first person who trusts the flag name.

DRAM stores bits as charge on tiny capacitors. Every read or refresh cycle briefly activates a row's wordline, which couples capacitively to physically adjacent wordlines. Normally the disturbance is negligible — refresh (every 64ms) tops the cells back up before charge leaks past the sense-amp threshold. But if you hammer a single row tens of thousands of times within one refresh window, the accumulated coupling drains enough charge from neighbor cells to flip a bit before refresh saves them.

The physics: Each wordline activation pulses ~1V. Adjacent wordlines see maybe 10-50mV of coupled noise per activation. That noise slightly disturbs the storage capacitor via the pass-transistor's gate leakage and subthreshold conduction. One hammer is invisible; 100,000 hammers in 64ms shifts a "1" cell (~1V stored) below the sense amp's decision threshold (~0.5V).

The classic exploit pattern (double-sided hammer):

• Pick a victim row V
• Repeatedly activate rows V-1 and V+1 in an alternating loop
• Force cache flushes (CLFLUSH) so every access hits DRAM, not the L1 cache
• After ~10⁵ activations, check V for flipped bits

Rule of thumb: Vulnerable DDR3 modules (2012-era, ~30nm process) flipped bits after roughly 139,000 activations per refresh interval. Sub-20nm DDR4 is worse, not better — cell capacitance shrank faster than coupling isolation improved. Some DDR4 parts flip after only 10,000-20,000 activations.

Real-world case: Google's Project Zero (2015) turned Row Hammer into a privilege escalation on Linux. By hammering DRAM near a page table entry, they flipped a bit in a PTE, converting a read-only user page mapping into one pointing to attacker-controlled memory — game over. This wasn't a software bug; it was DRAM physics defeating memory protection.

Mitigations:

• TRR (Target Row Refresh): DRAM tracks activation counts; rows nearing the threshold trigger a proactive refresh of their neighbors. DDR4 implementations were repeatedly bypassed by "TRRespass" patterns hammering many rows simultaneously.
• RFM (Refresh Management) in DDR5: standardized command lets the controller force targeted refresh.
• ECC: single-bit correction helps, but coordinated attacks can flip multiple bits in the same word.
• Doubling the refresh rate (32ms) — halves attack window, doubles refresh power.

Row Hammer is the poster child for abstraction leaks: memory looked like a perfect array of bits, until you pounded it hard enough to see the transistors underneath.

When you need to combine multiple power sources — a battery and a wall adapter, redundant supplies, or backup capacitor banks — the classic answer is OR-ing diodes: two Schottkys, cathodes tied together, each anode to a source. Whichever source is higher wins, and neither can back-drive the other. Simple, robust, and terrible for efficiency at high current.

The problem is the forward drop. A Schottky drops 0.3–0.5 V. At 5 A, that's 1.5–2.5 W wasted as heat, plus a real voltage sag your downstream regulator has to swallow. On a 3.3 V rail, you've just lost 10–15% of your headroom.

An ideal diode controller replaces the Schottky with a MOSFET plus a tiny IC that monitors drain-to-source voltage. When current flows in the "forward" direction (source-to-drain), the controller turns the FET fully on — Rds(on) is typically 5–20 mΩ, so your drop becomes I × Rds(on) instead of 0.4 V. When the drain voltage tries to exceed the source (reverse current), it shuts the FET off in microseconds.

Concrete example: A dual-input 12 V industrial supply with a 3 A load. Using two SS34 Schottkys: 0.5 V × 3 A = 1.5 W dissipation per diode, and you'll need heatsinking. Swap in an LTC4415 controller driving two SiR426DP MOSFETs (Rds(on) ≈ 8 mΩ): drop is 8 mΩ × 3 A = 24 mV, dissipation is 72 mW. You've reduced power loss by 20×, kept the voltage rail cleaner, and eliminated the heatsink.

Rule of thumb for FET selection: Pick Rds(on) such that I_max × Rds(on) < 50 mV in normal operation. That keeps you well below the controller's typical 30 mV regulation threshold (where it starts pinching the gate to prevent reverse conduction). Also verify the FET's body diode can carry your load current for a few microseconds during startup, before the controller enhances the channel.

Watch out for two gotchas:

• Orientation matters: The MOSFET must be oriented so the body diode points in the forward direction. This lets current flow immediately at power-on (through the body diode) before the controller wakes up. Backwards and you have no path at all.
• Oscillation at crossover: When two sources are within a few mV, the controller can chatter between them. Add a small hysteresis resistor (per the datasheet) or accept that one FET will "win" via slight voltage offset.

Common controllers: LTC4352 (single channel, 0–18 V), LTC4415 (dual), LM74700 (automotive reverse-battery protection), TPS2419 (12 V servers). Most cost $1–3 and pay for themselves in eliminated heatsinks alone.

A die spring is a heavy-duty rectangular-wire compression spring engineered for the brutal environment inside stamping dies, injection molds, and clamping fixtures. Unlike a general-purpose round-wire compression spring, its wire cross-section is rectangular (taller than wide), which packs roughly 30–40% more material into the same coil envelope. That gives you a much higher spring rate and load capacity in the same bore diameter — critical when a die designer has a fixed pocket size and needs to strip a part off a punch with several thousand pounds of force.

Die springs are sold to an ISO 10243 color code that tells you the duty rating at a glance:

• Green — light duty, ~30% max deflection, longest life (2M+ cycles)
• Blue — medium duty, ~25% max deflection
• Red — heavy duty, ~20% max deflection
• Yellow — extra heavy, ~15% max deflection
• Brown — extreme, ~10% max deflection, shortest life

The trade-off is stark: a yellow spring in the same envelope delivers roughly 2× the force of a green one, but you can only compress it 15% of its free length before you start eating into fatigue life. Push a brown spring beyond 10% and it will fail in tens of thousands of cycles instead of millions.

Real-world example: A progressive stamping die running at 200 strokes/minute uses four red die springs to strip a formed bracket off the punch. Each spring is 25 mm OD × 50 mm free length with a rate of 80 N/mm. Compressed 8 mm on each stroke, each delivers 640 N, giving 2,560 N total stripping force. That's 8 mm ÷ 50 mm = 16% deflection — right at the red-duty limit, so the shop stocks spares and swaps them at scheduled PM intervals, not on failure.

Rule of thumb for sizing: Never exceed the color-code's rated deflection percentage, and prefer the next duty level up (with more springs, if needed) rather than pushing a lighter spring to its limit. Doubling the number of medium-duty springs almost always outlives one heavy-duty spring worked hard, because fatigue life scales with the cube of stress amplitude.

Other details that matter: die springs need a guide rod or bore because their high rate makes them prone to buckling if the L/D ratio exceeds ~4. They're wound left-hand by convention (so a right-hand thread doesn't back a retainer off), and the ends are ground square-and-closed so they seat flat under load.

In the mid-1960s, a physicist at Battelle Memorial Institute's Pacific Northwest Laboratories in Richland, Washington, was quietly furious at his vinyl records. Every time he lowered a needle onto a Beethoven LP, he watched a stylus scrape the very information it was trying to read. James T. Russell decided the entire premise of contact playback was wrong. Sound should be stored as bits of light, and light should never touch anything.

On October 12, 1966, Russell filed US Patent 3,501,586, "Analog to Digital to Optical Photographic Recording and Playback System for Information Storage" (granted March 17, 1970). The claims read like a 1980s Sony product manual written a generation too early:

• An analog signal (like music) is sampled and converted to binary digits.
• Those bits are recorded as microscopic transparent and opaque spots on a photographic film disc.
• A tightly focused light beam scans the disc, and a photodetector reads the on/off pattern.
• Nothing physical ever touches the medium — playback is frictionless and lossless.

Russell also worked out error-correction schemes, high-density packing (he claimed billions of bits on a disc the size of a saucer), and even the idea of writing data with a modulated light source. He built working prototypes at Battelle in the late 1960s using a xenon arc lamp long before consumer lasers were available. Battelle spun the work into Digital Recording Corporation and later Optical Recording Corporation to commercialize it.

Why the industry pretended not to see it. When Sony and Philips demonstrated the compact disc in 1980 and shipped it in 1982, their engineers described their invention as a fresh idea born of new laser-diode technology. But Russell's patents covered the fundamental architecture: digital data + optical readout + non-contact scanning. Executives from Sony, Philips, and later Time Warner visited Battelle in the 1970s and left with detailed briefings. After years of litigation, in the late 1980s and early 1990s, essentially every optical-disc manufacturer settled with Optical Recording Corporation. Time Warner alone reportedly paid around $30 million.

What Russell actually invented, in modern terms. Strip the 1966 vocabulary away and his patent describes the operating principle of every optical storage device that followed:

• The audio CD (1982) — 16-bit PCM samples as pits and lands.
• The CD-ROM (1985) — arbitrary binary data on the same medium.
• DVD (1996), Blu-ray (2006), and Ultra HD Blu-ray — same architecture, shorter-wavelength lasers, denser pits.
• Magneto-optical and holographic data storage systems.

The surprising modern coda. Optical storage looked dead by 2015 — streaming ate the disc — but Russell's core idea is having a second life in the data center. Microsoft Research's Project Silica writes petabytes of cold-storage data into fused quartz using femtosecond lasers and reads it back with polarized light: no moving parts, non-contact, thousand-year shelf life. It is, essentially, Russell's 1966 patent scaled to glass and voxels. Meanwhile, startups like Cerabyte are pitching ceramic-on-glass archival storage using the same optical-write, optical-read principle.

Russell — who never worked at a record company, a computer company, or a movie studio — sat in a government lab in Washington State and drew the blueprint for every physical medium the entertainment industry would sell for the next 40 years, and for how humanity may store its long-term memory for the next 1,000.

This quiet little TypeScript repo tackles a genuinely underserved corner of accessibility engineering: switch scanning. For readers unfamiliar with the term, switch scanning is an input method used by people with significant motor impairments who can't operate a mouse, keyboard, or touchscreen. Instead, a highlight cycles through on-screen options and the user activates a single physical switch (a button, a sip-and-puff device, a head-mounted contact) at the moment their target is highlighted. It's the backbone technology behind AAC (Augmentative and Alternative Communication) apps used by people with ALS, cerebral palsy, and spinal cord injuries.

What makes this repo intriguing even at zero stars is who shayc is — a longtime contributor in the open-source AAC space, previously behind CBoard, a browser-based communication board. A dedicated switch-scanning primitive extracted into its own TypeScript library suggests the beginnings of a reusable building block that other AAC and accessibility tool authors could drop into their own web apps.

The interesting design questions in a library like this are non-trivial:

• Scan patterns: linear, row-column, group-item, half-and-half — each trades speed for cognitive load
• Timing: auto-scan intervals, dwell times, debouncing accidental double-hits
• Input abstraction: mapping arbitrary key events, gamepad buttons, or Bluetooth switch interfaces to a single logical "select"
• Focus management: integrating cleanly with existing DOM focus and ARIA semantics rather than fighting them

Who benefits? Web developers building AAC apps, educational software for special-needs classrooms, or inclusive kiosk interfaces. Also anyone curious about how accessibility technology actually works under the hood — reading a focused library like this is a much faster education than wading through the W3C accessibility specs.

Regular multiplication propagates carries — that's what makes it slow and what makes it multiplication. But a huge swath of cryptography and error-checking lives in GF(2ⁿ), the finite field where addition is XOR and there are no carries at all. Doing that on general-purpose ALUs is miserable: you'd loop 64 times, shifting and conditionally XORing. Intel added PCLMULQDQ (Westmere, 2010) and ARM added PMULL to fix this in one instruction.

What it actually does. Take two 64-bit inputs, treat each bit as a coefficient in GF(2), and multiply the polynomials. The result is 128 bits. No carries — every partial-product row is XORed instead of added. Silicon-wise, it's a Wallace-tree-like reduction network but with XOR gates where a normal multiplier has full adders. Cheaper per stage, and no carry-propagate at the end.

Where it earns its transistors.

• AES-GCM authentication (GHASH). GHASH is multiplication in GF(2¹²⁸). Pre-PCLMULQDQ, GHASH was often slower than the AES encryption itself. With it, GHASH drops to roughly 1 cycle per byte on Ice Lake — often faster than the ciphertext generation.
• CRC with arbitrary polynomials. Intel's own paper showed CRC32C going from ~5.5 cycles/byte (table-based Slice-by-8) to ~0.4 cycles/byte using PCLMULQDQ folding — about 13× faster.
• Reed-Solomon erasure coding (Ceph, Backblaze-style storage).
• Elliptic curves over binary fields (sect233k1, etc.).

Rule of thumb. On modern Intel (Ice Lake+) and AMD Zen 3+, VPCLMULQDQ (the AVX-512 version) is fully pipelined at 1 op/cycle with ~5-cycle latency, processing four 64×64 multiplies per instruction. That's ~32 GB/s of GHASH throughput per core at 4 GHz. Compare with the software loop: 64 shift-and-XOR iterations per 64 bits, so roughly 64× slower. This is why TLS 1.3 handshakes on modern hardware are essentially free — the auth tag stopped mattering.

The catch. The instruction is picky: you specify which halves of the two source registers to multiply via an immediate byte (0x00, 0x01, 0x10, 0x11). To multiply two full 128-bit polynomials you need four PCLMULQDQs plus XORs — the classic "Karatsuba trick" cuts this to three, and every real GHASH implementation uses it.

A concrete win. OpenSSL's AES-128-GCM benchmark on a Xeon 8380: ~1.1 GB/s per core using generic C for GHASH, ~7.5 GB/s with PCLMULQDQ. Same AES core, same everything else — just the polynomial multiply changed.

There's a whole category of LLM failure modes that only becomes visible when you give the model a tool and then watch what it chooses not to do. This project — an MCP server that simply exposes the current time — is a beautifully minimal probe of exactly that behavior. The premise: hand the model a clock, ask it time-sensitive questions, and observe how often it just... makes up an answer instead of calling the tool that's right there.

The finding hinted at in the title ("usually won't look at it") matches what a lot of practitioners have been quietly noticing but rarely benchmark rigorously. Models are trained to answer, not to check. Even when tool use is available, cheap, and clearly relevant, they default to their prior — which for temporal questions is a static training-cutoff hallucination dressed up as confidence. A model will happily tell you "it's currently around 3pm on a Tuesday" without ever invoking the tool sitting one function call away.

Why this matters for anyone building agentic systems:

• Tool availability ≠ tool usage. Adding an MCP server to your stack doesn't guarantee the model reaches for it. Prompting, tool descriptions, and system instructions all shape invocation rates in ways that are still poorly understood.
• Clocks are a canary. Time is the simplest possible external state — one integer, no ambiguity, no reasoning required. If a model won't check a clock, it probably won't check your database, your feature flags, or your rate limiter either when it thinks it can guess.
• It's a testable, reproducible artifact. Unlike vague complaints about hallucination, "did the model call tick_now() or not?" is a binary you can measure across models, prompts, and MCP client implementations.

The MCP angle is what elevates this from a cute demo to something useful. MCP is the emerging standard for wiring tools into LLM clients, and tick-mcp doubles as a diagnostic — drop it into Claude Desktop, Cursor, or any MCP-compatible harness and you get a cheap, honest read on whether the model is actually reaching for context or just confabulating around it.

For a Show HN with one point and zero comments, it's punching well above its weight as a research artifact. The kind of thing that deserves a blog post, a leaderboard, and probably a paper.

Of the ten postings, Interos is the one that actually tells you something. A company hiring Haskell engineers onsite in Arlington, VA — a stone's throw from the Pentagon — is broadcasting its strategy louder than any press release could.

The stack tells the story. Haskell is a deliberate choice, not a default. Companies pick it when correctness matters more than hiring velocity: financial systems, compilers, and — increasingly — risk modeling. Interos does supply chain risk intelligence, which means graph traversal across millions of corporate entities, provenance tracking, and answering "if supplier X goes down, what breaks?" That's a domain where Maybe types and immutable data structures earn their keep. The parallel hiring for Data Science, Python, DevOps, TypeScript, and Designers suggests a classic bifurcation: Haskell for the analytical core, Python/TS for the customer-facing surface.

Stage and direction. Arlington + Haskell + hiring across ten function areas simultaneously = a Series B/C company scaling into federal contracts. The .ai domain and dedicated Data Science hiring signals they're positioning the risk graph as an ML product, not a consulting deliverable. The breadth of open roles (Product, Marketing, Design) means they're building the go-to-market motion in parallel with engineering — that's a company with runway and a board pushing for growth.

Trends this highlights:

• Supply chain risk as a category was already heating up pre-COVID; this posting (March 2020) is early positioning for what became a boom.
• Typed functional languages in enterprise — Haskell/Scala/OCaml shops are quietly proliferating in fintech and gov-tech where bug costs are asymmetric.
• Onsite-mandated roles with COVID exceptions — the "ultimately onsite" caveat reveals a clearance-adjacent business model. You don't insist on Arlington unless you need SCIF proximity.

Green flags: Direct contact email from what appears to be a hiring manager ([email protected]), specific technology commitment, transparent about the remote-during-COVID / onsite-long-term reality. Red flags: The posting is thin on team size, comp band, and what the Haskell codebase actually does. Serious Haskell candidates are picky — a job description that doesn't sell the technical problem will lose to Standard Chartered or Mercury. Also: "and more" as a category of open roles suggests reactive hiring rather than a workforce plan.

When pthread_cond_broadcast() wakes every thread waiting on a condition variable, a naive implementation would call FUTEX_WAKE on all of them. Every woken thread immediately tries to grab the associated mutex, but only one can win. The other 999 threads run, contend on the mutex futex, fail, and go back to sleep — a classic thundering herd. Wall clock burned, cache lines bounced, scheduler thrashed.

FUTEX_REQUEUE solves this. Instead of waking N waiters on futex A, it wakes one waiter on A and moves the remaining waiters to the wait queue of futex B, all inside the kernel, without any thread ever running. Those threads stay blocked, but now they're queued on the mutex futex instead of the condvar futex. When the winner eventually releases the mutex, the next waiter is already positioned to be woken normally.

The API: futex(uaddr, FUTEX_REQUEUE, wake_count, requeue_count, uaddr2). It wakes up to wake_count waiters on uaddr, then moves up to requeue_count more to uaddr2. glibc typically passes 1 and INT_MAX.

FUTEX_CMP_REQUEUE adds a safety check: it takes an extra expected_value and atomically verifies *uaddr == expected_value before doing anything. This closes a race where a waker between the userspace decision to broadcast and the kernel's requeue could have already changed the condvar's state (e.g., another thread called signal). Without the compare, you might requeue waiters that should have been left alone. Every modern glibc uses FUTEX_CMP_REQUEUE, never plain FUTEX_REQUEUE.

Concrete example: A worker pool has 1000 threads waiting on a condition variable for new work. A producer calls pthread_cond_broadcast(). Without requeue: 1000 futex wakeups, 1000 syscall returns, 999 mutex-lock failures, 999 futex sleeps — roughly 2000 context switches for one broadcast. With FUTEX_CMP_REQUEUE: 1 wakeup, 999 in-kernel queue transfers, ~2 context switches. Measured on Linux, a broadcast to 1000 waiters drops from ~40ms of scheduler work to under 100µs.

Rule of thumb: Each avoided spurious wakeup saves roughly one context switch pair (~2–5µs on modern hardware) plus L1/L2 cache pollution. For N waiters where only one can proceed, requeue saves approximately (N-1) × 4µs. At N=1000, that's 4ms of pure overhead eliminated — per broadcast.

The requeue mechanism is why pthread_cond_broadcast scales at all. It's also why glibc's condvar implementation carefully maintains a separate "internal futex" address distinct from the mutex — the requeue destination must be stable across the operation.

In the mid-1990s, the internet had a problem that felt almost existential to the operators keeping it alive: a single flapping link in some obscure corner of the world could send BGP UPDATE storms rippling through every router on the planet. A cheap modem in Kuala Lumpur bouncing up and down every 30 seconds could push CPU load on backbone routers to 100%, and because BGP is a path-vector protocol, every withdrawal and re-announcement had to be recomputed and propagated by everyone. RFC 2439 introduced Route Flap Damping — a mechanism to punish unstable routes by temporarily suppressing them, giving operators back their CPUs.

The mechanism. Each route gets a figure of merit — essentially a penalty counter. Every time the route flaps (a withdrawal followed by re-announcement, or an attribute change), the router adds a fixed penalty (typically 1000). That penalty decays exponentially over time with a configurable half-life (default 15 minutes). When the accumulated penalty crosses a suppress-threshold (default 2000), the router stops announcing the route to peers even though it's technically reachable. Once decay brings the penalty back under reuse-threshold (default 750), the route is un-suppressed. A hard cap called max-suppress-time (default 60 minutes) ensures a route can't be dampened forever.

The key design decisions. The authors — all Cisco/ANS engineers who had personally watched the internet melt — chose exponential decay because it has a critical property: the sum of infinite flaps at a constant rate converges to a finite value. This means you can express thresholds as "flap rate" rather than "flap count," which is what operators actually care about. They also chose to keep state per-route, per-peer, so a flapping route learned from one neighbor doesn't get dampened when the same prefix arrives cleanly from another. And crucially, damping is applied only to received routes, not to your own — you never dampen yourself.

Then came the twist. Damping was widely deployed through the late 1990s and early 2000s. Then in 2002, a paper by Mao, Govindan, Varghese, and Katz — "Route Flap Damping Exacerbates Internet Routing Convergence" — showed that damping was actually making convergence worse. The reason is subtle: normal BGP path exploration during convergence generates transient UPDATE churn that looks identical to real flapping. A route that fails once and reconverges through a few alternate paths could accumulate enough penalty to get suppressed for 30+ minutes, even though the underlying link is perfectly stable. RIPE issued recommendation RIPE-378 in 2006 telling operators to turn damping off. Most did.

Why it still matters. Damping came back — carefully — via RFC 7196 in 2014, which recommended much less aggressive default thresholds (suppress at 6000, reuse at 2000) that avoid punishing normal convergence churn. Many tier-1 networks now run "damping lite" on specific prefix categories. More importantly, RFC 2439 is a wonderful case study in emergent misbehavior: a mechanism that was locally correct, mathematically elegant, and empirically successful in isolation caused systemic harm once deployed globally. Every distributed systems engineer building rate limiters, circuit breakers, or backoff logic is fighting the same class of problem — the difference between "punish bad behavior" and "punish behavior that looks bad during recovery."

The RFC is also notable for being written in prose that assumes you already run a backbone. It reads like an operations runbook with equations, not an academic spec. That was the style of the era: RFCs were written by the people who would deploy them at 3 AM.

The asker is dissecting the C11 adaptation of the Chase-Lev work-stealing deque from Lê et al.'s "Correct and Efficient Work-Stealing for Weak Memory Models." The paper claims the implementation is optimal: no C11 synchronization can be weakened without breaking correctness. The asker isn't buying it — specifically, they can't see why the initial load of top in push() needs memory_order_acquire rather than memory_order_relaxed.

Recall the shape of push():

void push(Deque *q, void *w) {
    size_t b = atomic_load_explicit(&q->bottom, memory_order_relaxed);
    size_t t = atomic_load_explicit(&q->top,    memory_order_acquire); // <-- why acquire?
    Array *a = atomic_load_explicit(&q->array,  memory_order_relaxed);
    if (b - t > a->size - 1) { /* grow */ }
    ...
}

Why it's subtle. Only the owner thread calls push() and take(); stealers race on top. Naively you'd think the owner never reads anything published by stealers — stealers only CAS top forward. So what could an acquire load possibly synchronize with?

The real answer lies in the resize path. The t value determines whether we grow the array. If the load of top is stale, we might grow unnecessarily — annoying, but not incorrect. However, the tricky case is around the interaction with a preceding take(): after a failed CAS in take(), the owner may have written bottom back, and the value of top observed by that CAS establishes a happens-before edge. If the subsequent push() reads a value of top that's older than what the same thread already observed via the CAS in take(), we can violate the invariant bottom ≥ top that the size calculation depends on — leading to a bogus size and either a spurious resize or, worse, an underflow in b - t (unsigned wraparound producing a huge apparent size).

Sketch of a proof direction. The paper's formal model (they mechanized it in Coq/Herd) tracks the "modification order" of top. Relaxed loads by the owner can observe any prior write in that modification order, including ones already superseded by writes the same thread has causally observed. The acquire ensures the owner sees a value at least as new as any it previously read-modify-wrote, closing that window.

Gotchas:

• b - t is unsigned — stale t can wrap catastrophically.
• Single-thread reasoning fools you: even the owner needs synchronization with its own earlier atomic RMWs to preserve modification-order consistency across relaxed reloads.
• x86 hides this bug; only ARM/POWER expose it under stress. Test with TSan + relaxed accesses on weakly-ordered hardware or with a C11 model checker (CDSChecker, GenMC).

Every cache eviction policy we've covered — LRU, LFU, TinyLFU, ARC — makes a smart decision about what to evict. Smart decisions require metadata: recency timestamps, frequency counters, ghost lists, sketches. That metadata costs memory and, more importantly, requires updates on every access. LRU moves an entry to the head of a linked list on every read. LFU increments counters. That's cache-line contention, atomic operations, and cache pollution just to decide what to throw away later.

Random Replacement (RR) skips all of it. When the cache is full and you need to evict, pick a random victim and throw it out. No timestamps. No counters. No linked lists. No locks on the read path.

Why this isn't as stupid as it sounds: for many real workloads with Zipfian access patterns, RR's hit rate is surprisingly close to LRU. Hot items dominate accesses, so probabilistically they survive random eviction — a hot item accessed 1000× is unlikely to be picked when there are 10000 entries and only one gets evicted per miss. Meanwhile, cold items don't get re-inserted, so they naturally get evicted eventually.

Real-world example: ARM Cortex-A CPUs use random replacement for L1 and L2 caches. Silicon area matters more than a fractional hit-rate improvement, and RR's hit rate is within 5% of LRU on typical workloads while requiring zero replacement-state bits per line. Intel switched some of their caches from pseudo-LRU to more complex policies only when the workload analysis justified the transistor budget. Memcached's slab allocator falls back to random-ish eviction within a slab class in some configurations for similar reasons.

Rule of thumb: if your cache is small (fits in L1/L2), high-contention (many concurrent readers), or your access pattern is heavily skewed (top 20% of keys get 80% of hits), the hit-rate gap between RR and LRU is typically under 10%. Multiply that by the CPU cycles saved on every read — no list pointer updates, no atomic recency writes — and RR often wins on throughput even when it loses slightly on hit rate.

When to avoid it: uniform access patterns (RR degrades to random), or when a single miss is catastrophically expensive (DB queries taking seconds). Then spend the metadata budget on LRU or W-TinyLFU.

The lesson generalizes beyond caches: metadata isn't free. Every "smart" decision has a bookkeeping cost paid on the hot path. Sometimes the dumb algorithm with zero overhead beats the smart one that pays overhead on every access to save overhead on rare evictions.

lscpu tells you how many cores you have. lstopo shows you where they are — the exact hierarchy of sockets, NUMA nodes, L3/L2/L1 caches, sibling hyperthreads, and which PCIe devices sit on which NUMA node. It's part of hwloc (Portable Hardware Locality), the library that Open MPI, SLURM, and every serious process-pinning tool call internally. Package name is hwloc on Debian and RHEL.

Open a graphical map, or fall back to the terminal:

lstopo                    # X11 window with the full topology drawn
lstopo-no-graphics        # curses-y summary in the tty
lstopo --of console       # ASCII art tree
lstopo --of svg > box.svg # for the wiki page

The tree shows Package → NUMANode → L3 → L2/L1 → Core → PU. That's the actual topology; the flat "48 CPUs" list from /proc/cpuinfo hides all of it.

Concrete uses that pay for themselves

Where should my NIC IRQs live?

lstopo --whole-io --physical

Now PCI devices show up with their NUMA node. If your 100GbE card is on node 1 but your packet processor is pinned to node 0, every frame crosses UPI and you're eating 30–40% of your throughput in cross-socket traffic. This one command has settled dozens of "why is our tail latency weird" arguments.

Which cores share L2/L3? Useful for co-locating a producer and consumer thread:

lstopo --no-io --only core
lstopo --output-format xml    # machine-parseable for schedulers

Distance matrix between NUMA nodes:

hwloc-distances

Same data the kernel uses, but readable. On modern EPYC boxes with chiplet-based CCDs, the numbers are surprising.

The killer companions: hwloc-bind and hwloc-calc

Pin a process by semantic location instead of hardcoded CPU IDs:

hwloc-bind L3:0 -- ./my_worker           # any core sharing L3 #0
hwloc-bind NUMANode:1.Core:2 -- ./job    # specific core on node 1
hwloc-bind socket:0 --membind socket:0 -- ./crunch

Convert those selectors to a mask you can hand to taskset, numactl, or systemd's CPUAffinity=:

$ hwloc-calc --taskset NUMANode:1
0xffff0000

$ systemctl set-property redis.service CPUAffinity=$(hwloc-calc NUMANode:0)

Distribute N tasks evenly across the machine's real physical cores (not siblings):

hwloc-distrib --single 8 --restrict $(hwloc-calc Package:0)

Why it beats numactl and taskset alone

numactl --hardware knows nodes and distances. taskset takes a raw bitmask. Neither knows anything about the cache hierarchy, PCI locality, or which "CPU 24" is actually the SMT sibling of "CPU 0". hwloc gives you the whole picture in one map, and the selector syntax means the same pinning script works unchanged on your Xeon workstation and your EPYC server — because L3:0.Core:1 means the same semantic thing on both, even when the underlying CPU numbering is wildly different.

Bonus: lstopo --top gives a live view showing which PUs are currently running which processes. It's htop arranged the way your silicon actually is.

Grid batteries usually live in shipping containers on the outskirts of town. But molten salt — the same nitrate mix (60% NaNO₃, 40% KNO₃) that runs concentrated solar plants like Crescent Dunes — stores heat cheaply at ~$25/kWh-thermal. What if we made the building itself the tank?

Imagine a 60-story tower with a central core that isn't elevators — it's a stack of insulated tanks holding 10,000 tonnes of "solar salt" cycling between 290°C (cold) and 565°C (hot). The salt is heated by cheap off-peak grid electricity through resistive immersion heaters (round-trip electric efficiency ~40% via steam turbine on discharge), and the "waste" heat leaking through the tank walls is exactly the heating load for the offices wrapped around it.

The energy math. Solar salt has a specific heat of ~1.5 kJ/kg·K. Cycling 10,000 tonnes through ΔT = 275 K stores:

Q = m·c·ΔT
  = 10⁷ kg × 1500 J/kg·K × 275 K
  ≈ 4.1 × 10¹² J
  ≈ 1,150 MWh thermal
  ≈ 460 MWh electric (at 40% conversion)

That's roughly enough to run a mid-sized US city (say, 15,000 homes at ~30 kWh/day) for one evening. For comparison, the Moss Landing lithium plant stores 3,000 MWh at ~$400/kWh; our salt core stores 460 MWh electric at maybe $80/kWh installed. The catch is you need real estate for a steam turbine and cooling loop in the basement.

The heating bonus. A 60-story office needs ~5 MW of heat in a cold-climate winter. Our tank, at 565°C surface temp behind (say) 40 cm of microporous insulation with k ≈ 0.025 W/m·K, leaks:

Q_loss = k·A·ΔT/L
       ≈ 0.025 × (π·8m × 240m) × 545 / 0.4
       ≈ 205 kW

That's less than the heating demand — so we tap the tank on purpose through a controllable heat exchanger. Round-trip combined heat and electricity efficiency climbs to ~85% because the "waste" is the product.

The structural nightmare. 10,000 tonnes concentrated in a 200-m column is a compressive load of ~1 MPa at the base plus a huge lateral hazard: solar salt freezes at 220°C. Lose heat trace for 48 hours and the entire core solidifies into an unpumpable ingot. Crescent Dunes learned this in 2016 when a cold-salt tank leaked and cost them eight months. In a skyscraper, a leak of 565°C salt into an elevator shaft would be catastrophic — salt at that temperature ignites organics on contact and eats stainless 304 at ~0.3 mm/year (you need Inconel 625 for the tank, ~$40/kg, adding maybe $400M to construction).

Seismic problem. A slug of liquid at 200 m height has a sloshing resonant period of T ≈ 2π√(H/g·π) ≈ 15 seconds — dangerously close to the fundamental sway period of a tall building. You'd need internal baffles and probably a tuned mass damper synced against the salt itself. Nature would prefer these two systems didn't share a resonance.

The verdict. As pure grid storage, hopelessly worse than a battery farm. But as combined storage + heating for a district energy zone (think Helsinki or Toronto), the numbers pencil. Vantaa, Finland is literally building a 90 GWh underground sand version of this — same physics, safer medium.

Imagine you're on a commercial airliner cruising at 35,000 feet over the Pacific. No GPS signal reaches you through the storm outside, no ground-based radio beacons are in range, and yet the plane knows precisely where it is — down to the meter. The secret sitting quietly in the avionics bay is a device with no moving parts, in which two beams of laser light race each other around a triangle of mirrors, forever.

The ring laser gyroscope (RLG) is one of the strangest and most elegant instruments humans have ever built. Instead of a spinning wheel like the mechanical gyroscopes of the early 20th century, it exploits the Sagnac effect: when a ring cavity rotates, light traveling with the rotation takes fractionally longer to complete a loop than light traveling against it. The difference is absurdly tiny — a few parts per quintillion — but because lasers form standing waves whose frequency depends on cavity length, that difference shows up as a measurable beat frequency between the two counter-propagating beams. Count the beats, and you know exactly how fast you're rotating.

Georges Sagnac demonstrated the underlying interferometry in 1913, but it was useless as a navigation tool until the laser arrived in 1960. Within three years, engineers at Sperry (yes, the same Sperry from the gyrocompass era) had built the first working RLG. By the 1980s, ring laser gyros had displaced spinning-mass gyros in nearly every serious inertial navigation system on Earth — commercial airliners, ICBMs, submarines, the Space Shuttle.

Here's where it gets weird. At very low rotation rates, the two laser beams tend to lock in to the same frequency, because the mirrors backscatter a tiny amount of each beam into the other. This "lock-in" creates a dead zone where the gyro reads zero rotation even though the vehicle is turning. The elegant fix? Vibrate the entire gyroscope mechanically — a technique called dithering — to keep the beams above the lock-in threshold at all times. The next time you're on a Boeing 777, there's a good chance something is buzzing gently in the electronics bay to keep two laser beams from becoming friends.

RLGs are so sensitive they can measure things they were never designed to detect:

• The rotation of the Earth itself — a stationary RLG registers roughly 15 degrees per hour of drift, which is used as a calibration reference
• Tiny wobbles in Earth's axis caused by earthquakes and ocean currents
• Frame-dragging effects predicted by general relativity (the goal of the ongoing GINGER project in Italy)

The largest research RLGs, like the "G" ring at Wettzell, Germany, are square cavities four meters on a side, buried in an underground vault to eliminate thermal drift. They're precise enough that geophysicists use them as seismometers for the whole planet.

Nearly every candidate in today's batch is true-crime clickbait, hashtag spam, or a Short teasing a longer video. This one stands out because it actually promises to teach something concrete: the modern scientific understanding of dietary fat, and how the received wisdom of the last fifty years has shifted.

The description signals genuine breadth — saturated fat, cholesterol, olive oil, butter, omega-3s, and the Mediterranean diet — which suggests the creator plans to walk through the evolution of nutrition science rather than pushing a single fad. The topic is well-suited to a small independent channel: mainstream nutrition coverage tends to be either sponsored, oversimplified, or captured by whichever diet camp is currently ascendant, so a from-scratch review of the literature has room to add real value.

Worth watching if you've ever wondered why guidelines flipped from "avoid all fat" to "eat olive oil generously," or why the demonization of saturated fat has quietly softened in recent meta-analyses. Even if the presenter's conclusions are contestable, the exercise of seeing the evidence laid out is more educational than another true-crime reenactment.

Caveat: zero-subscriber channel, so production quality and citation rigor are unknown going in.

Bench power supplies are one of those tools every electronics hobbyist eventually wants to build rather than buy, and this Part 2 installment focuses on the DC-DC converter circuits that form the heart of the project. It's an open-source, STM32-based low-power PSU — a design choice that hints at digital control loops, programmable current limiting, and USB or encoder-driven UI possibilities down the line.

What makes this worth watching over the typical "hook up an LM317" tutorial is the deliberate architectural approach: separating the switching pre-regulator from the linear post-regulator stage is a classic technique used in commercial bench supplies (like the Rigol DP800 series) to keep dissipation manageable across a wide output range. Seeing a small creator walk through their converter topology choices — likely a buck stage feeding a linear pass element — is genuinely educational for anyone designing their own regulated supply.

At 17 subscribers, this is a channel at the very start of its journey, and the creator explicitly invites viewers to request deeper dives. That's exactly the kind of two-way engagement that makes early-stage engineering channels rewarding to follow. If you're interested in power electronics, STM32 firmware, or open-source hardware, catching this project early means you can watch the design evolve schematic by schematic.

Most oil rig disaster videos lean on dramatic storm footage and vague "nature is unpredictable" narration. This one frames the failure as an information-transfer problem between the design office and the offshore installation crew — which is a much more useful lens for anyone working in engineering, manufacturing, or any field where a specification has to survive translation from paper to physical reality.

The premise (per the description) is that a single miscommunication propagated from design intent into fabrication and installation, and by the time the rig was in the water the compounded error was uncorrectable. That's a recurring pattern in real failure investigations: the visible catastrophe (weather, wave loading, structural collapse) is downstream of a much quieter mistake made months or years earlier by someone who never saw the ocean.

The channel is brand new (1 subscriber) so production polish will be limited, but the framing — disaster as a communication failure, not an environmental one — is exactly the kind of angle that experienced engineers and safety analysts actually care about. If the execution matches the premise, it's the kind of case-study thinking that transfers to software architecture reviews, aerospace tolerancing, or any domain where handoffs between teams are where the real risk lives.

Note: several other candidates were shorts, hashtag spam, or generic "shocking footage" compilations — this was the clearest attempt at a real technical explainer.

Honest note up front: this batch of candidates is thin. Most entries are Shorts, hashtag spam, AI-generated engine clips, or clickbait compilations. Eric Diffendal's basement workshop series is the one long-form, real-human project in the list, so it wins largely by default — but it's still genuinely worth a look if you're planning your own shop space.

This is the kickoff episode of a series documenting a basement workshop build from scratch. The design phase is often the most valuable part of a shop project to watch, because the constraints of an indoor basement space — low ceilings, limited egress, dust management, electrical capacity, moisture, noise, and neighbor considerations — force trade-offs that a garage or outbuilding shop never has to make.

Expect discussion of layout planning, tool placement, workflow zones (assembly vs. machining vs. finishing), and probably some early decisions around dust collection and lighting. Since it's a series opener from a very small creator (89 subs), it should be light on production padding and heavy on the actual thinking behind the choices — which is where beginners typically learn the most.

If you're contemplating carving a workshop out of a basement, garage corner, or spare room, watching someone reason through the design constraints in real time is more useful than any polished "shop tour" video.

Slim pickings today — most of the batch is Shorts spam, hashtag-stuffed clickbait, or silent background-music fabrication clips. Patrick Olsen's expansion chamber build is the one entry that promises a real, specific skill.

An expansion chamber is the tuned exhaust that makes a two-stroke engine actually make power. It's not just a muffler — the geometry (header, diffuser cones, belly section, baffle cone, stinger) is calculated to send a pressure wave back to the exhaust port at exactly the right moment to shove escaping fuel-air mix back into the cylinder before the piston closes the port. Get the cone angles and lengths wrong and you lose the powerband entirely.

Building one from 0.035" sheet steel is a legitimate fabrication challenge: you have to develop flat patterns for compound cones, roll them, tack them, and TIG or MIG weld thin-gauge steel without blowing through or warping the tuned geometry. The KT100 Yamaha is a classic spec-class karting engine, so there's a real performance target driving the design rather than eyeballed guesswork.

Worth watching for the sheet-metal layout work and the thin-gauge welding technique alone, even if you don't care about karting.