Your RAM Is Fake. The Moon Broke Timezones. And Your Compiler Is Guessing.

Overview

The video makes several “what 2026 will look like” predictions spanning:

• Memory architecture (tiered “memory as a service”)
• Time standards (coordinated lunar time)
• Hardware-enforced memory safety (CHERI-like)
• Software supply-chain security (repository downtime)
• Compiler optimization (ML-guided, non-deterministic heuristics)

---

1) Tiered / “Memory as a Service” using CXL (cloud RAM model changes)

Problem with traditional RAM sizing

• Hyperscalers often buy servers with a fixed CPU-to-RAM ratio.
• This can cause waste (e.g., idle CPU cores when the workload needs much more memory but less compute).

New approach: shared memory fabric

• Memory is treated less like fixed local RAM and more like a shared fabric.
• CXL (Compute Express Link) is positioned as the enabling technology.
• Framed as “memory as a service”, analogous to other “as a service” models.

Key tradeoff: speed vs distance

• CXL-backed memory is slower than nearby DRAM, so the OS must manage tiering:
  • Hot data stays near the CPU (fast tier)
  • Cold data moves to farther/larger/slower pools

Linux + orchestrators angle

• Mentions Linux kernel work to improve page placement across memory tiers.
• Notes that Kubernetes/orchestrators can schedule workloads based on memory needs.

Prediction

• ~65% odds that by end of 2026, at least one major cloud provider offers a tiered/burstable memory class where customers explicitly pay less for CXL-backed memory.
• Confidence caveat: adoption is expected, but customer-facing complexity may slow public rollout.

---

2) Coordinated Lunar Time (relativity + synchronization for lunar computing)

Claim

• 2026 may finalize a coordinated lunar time standard.

Why lunar time differs

• General relativity changes clock rates between Earth and the Moon due to gravity differences.
• The video states the Moon’s clocks run ~56 microseconds faster than Earth.

Computer-science risk

• Synchronization is not just “timestamps + offsets”—it requires proper time scales.
• Raises a race-condition-like concern: systems where the flow of time itself drifts.

NASA historical workaround

• Apollo-era “smart Earth / dumb Moon”: maintain a constant Earth↔spacecraft communication loop to correct drift.

Prediction

• ~80% odds that by end of 2026, an official operational implementation strategy is published for coordinated lunar time.
• Note: a NASA Dec 31, 2026 deadline may exist, with potential slippage.

---

3) Beyond Rust vs C++: hardware-enforced memory safety (“CHERI” concept)

Why the Rust-vs-C++ debate may cool

• The video argues the debate is getting stale because hardware can enforce safety.

Core concept (implied CHERI / “Cherry”)

• Replace normal pointers with capabilities:
  • Instead of typical 64-bit pointers
  • Use larger (e.g., 128-bit) capability descriptors defining exactly which memory regions code can access.
• Hardware enforces access rules and traps/prevents invalid memory operations.

Recompilation benefit

• The video suggests you can recompile existing unsafe C/C++ for a CHERI-like system.
• The hardware catches bugs without requiring a full rewrite into Rust.

Prediction

• ~40% odds that by end of 2026, a mass-produced consumer device (example category: an IoT hub) ships with a CHERI-enabled processor.
• Notes: experimentation exists on RISC-V/ARM and dev boards.

---

4) Package supply-chain attack pressure: forced downtime for registries

Prediction

• ~70% chance that in 2026, a major package repository (e.g., npm, PyPI, or similar registries) will shut down registrations for more than 24 hours.

Reasoning

• Malicious packages are becoming easier to slip in convincingly:
  • Trojanized dependencies inside dependency chains
  • AI-generated “fake but plausible” packages at scale

“Slop squatting”

• Attackers mass-produce many plausible packages, hoping humans accidentally install the wrong one.

Mitigation direction (implied)

• Registries may require trusted developer verification (stronger identity/verification for publishing) to reduce abuse.

---

5) Non-deterministic “ML-guided” compiler optimization (LLVM + heuristics learned)

Framing

• At maximum optimization levels, optimizers may become non-deterministic:
  • Same source + same flags → different binaries across runs

Why this happens

• CPU optimization involves an enormous state space:
  • Branch prediction
  • Reordering buffers
  • Cache behavior
  • Register allocation
• Small changes can lead to different optimization pathways.

ML claim (narrow scope)

• The video rejects the idea of “AI writes binaries directly” as absurd.
• ML is positioned as helpful for subsets of compilation—choosing heuristics for specific steps.

Precedent

• Google work improving binary size, reportedly beating humans by ~7%.
• Reported as upstreamed into LLVM (2021).

Prediction

• By end of 2026, ~65% odds that LLVM includes ML-guided heuristics beyond the current two:
  • Existing examples mentioned:
    • Inlining for size
    • Register eviction
  • Next guess:
    • Loop unrolling (ML decides when it’s safe/performance-friendly)

Upstreaming constraint

• LLVM maintainers are selective:
  • ML changes will likely ship only if they consistently beat hand-tuned heuristics
  • With safe fallbacks

---

Main speakers/sources (as stated)

• Lori (recurring speaker; ends with “Lori wired out”)