Mars rovers run a proprietary RTOS from 1987. Japanese lunar probes run a kernel designed for fax machines. Starlink satellites run a general-purpose OS with real-time duct-taped on top. Three paradigms. Three failures of imagination. Nexus is the architecture none of them have.
We studied the operating systems powering the most critical space missions on three continents. The findings expose a dependency landscape that should alarm every engineer who cares about sovereignty, safety, and the future.
Every NASA Mars rover runs Wind River VxWorks on the BAE Systems RAD750, a radiation-hardened PowerPC G3 derivative clocked at 133 MHz with 128 MB DRAM. Wind River's heritage with JPL goes back to 1994's Clementine Moon probe, making VxWorks the first commercial OS on Mars via the Pathfinder mission in 1997.
| Component | Detail |
|---|---|
| Operating System | VxWorks (Wind River, proprietary) |
| Processor | BAE RAD750 — PowerPC G3, 133 MHz |
| Memory | 128 MB DRAM, 256 MB Flash |
| Heritage | Clementine (1994) → Pathfinder (1997) → Present |
| Vendor Lock-In | Complete. 30 years of accumulated dependency. |
The one exception: the Ingenuity helicopter ran Linux, marking the first time Linux operated on Mars. But critically, it handled scouting and imaging—not flight-critical propulsion or real-time motor control. The rover itself stayed on VxWorks because Linux is not a hard real-time OS, and when a cosmic ray flips your bit during powered descent, you need deterministic guarantees, not a scheduler that "tries its best."
The trap: VxWorks is a proprietary black box from 1987. Vendor lock-in so deep that JPL literally cannot switch even if they wanted to. Wind River knows this. They price accordingly.
JAXA spacecraft run the TRON/TOPPERS family, Japan's sovereign RTOS play rooted in the µITRON specification from 1984. JAXA's SpaceWire modules, Hayabusa 1 and 2, and the SLIM mission all descend from this lineage. JAXA developed its own high-reliability RTOS based on the TOPPERS/HRP Kernel and Safety Kernel, purpose-built for rockets and satellites through collaboration with Nagoya University.
| Component | Detail |
|---|---|
| Operating System | TRON/TOPPERS (µITRON spec, open standard) |
| Heritage | µITRON (1984) → TOPPERS/HRP → JAXA Safety Kernel |
| Architecture | Open spec, Japanese academic roots, space heritage |
| LEV-2 (Sora-Q) | 250g rover by Tomy + Sony — bare-metal or minimal µITRON |
| Vendor Lock-In | Low (open spec), but frozen in 1990s architecture. |
The LEV-2 "Sora-Q" is a 250-gram baseball-sized rover built by a toy company (Tomy) with Sony control boards. At that scale you're looking at bare-metal firmware or a minimal µITRON derivative on whatever microcontroller Sony dropped in. Not exactly a kernel architecture showcase.
The trap: TRON/TOPPERS is the closest thing to a sovereign RTOS on this list—open spec, academic roots, real space heritage. But it's frozen in the µITRON era. No content-addressed storage. No cryptographic audit trail. No Merkle-proven event ordering. It solves the 1990s version of the problem.
Each Starlink launch of 60 satellites carries more than 4,000 Linux systems. The constellation runs over 30,000 Linux nodes and 6,000+ microcontrollers in orbit. SpaceX runs their Linux with the PREEMPT_RT patch for real-time capability, maintains their own fork of the kernel with custom drivers, and shares much of the platform infrastructure between Starlink, Falcon 9, and Dragon.
| Component | Detail |
|---|---|
| Operating System | Custom Linux (PREEMPT_RT patch) |
| Scale | 30,000+ nodes, 6,000+ microcontrollers in orbit |
| Philosophy | Satellites as disposable datacenter servers |
| Update Cycle | Weekly OTA firmware pushes |
| Vendor Lock-In | Self-maintained fork. Immune to vendor, dependent on kernel. |
SpaceX treats satellites like disposable datacenter servers—mass-produced, updatable weekly, replaceable. The antithesis of the VxWorks "one precious radiation-hardened jewel" philosophy. But underneath the bravado is an admission: they'd rather bolt real-time onto a general-purpose kernel than use a purpose-built RTOS. That tells you everything about the state of the RTOS market. The dedicated options are so bad that a patched Linux is less risky than the alternatives.
The trap: Linux was never designed for space. PREEMPT_RT is a patch, not an architecture. You are running a kernel designed for web servers in a radiation environment with 8-minute communication latency to ground control. It works until it doesn't. And in LEO, "doesn't" means debris.
Three space programs. Three continents. Every single one is trapped—either by a vendor who owns the source, a legacy architecture that can't evolve, or a general-purpose kernel that was never designed for the job.
Proprietary RTOS. No source access. Per-seat licensing. 30 years of accumulated API dependency. JPL is architecturally unable to leave.
LOCK-IN: CRITICALOpen specification, but the architecture is frozen in the µITRON era. No modern cryptographic primitives. No content-addressable anything. Sovereign in name, legacy in practice.
LOCK-IN: ARCHITECTURALNo vendor lock-in per se, but a 35-million-line kernel where real-time is a bolt-on patch. Every upstream merge is a liability. Every CVE is your problem. General-purpose means general-purpose vulnerabilities.
LOCK-IN: COMPLEXITYNexus occupies the gap none of these fill: a sovereign, content-addressed, Merkle-audited nanokernel with deterministic scheduling and zero vendor dependencies. Purpose-built. Not patched. Not inherited. Forged.
Content-addressed storage with Merkle audit trails at the kernel level. When a cosmic ray flips a bit, the kernel knows—and recovers. VxWorks detects nothing. Linux panics. Nexus self-heals.
Not PREEMPT_RT. Not a patch. Native hard real-time from the ground up. Harmonic task alignment. Worst-case execution time guarantees. The scheduler was designed for space, not retrofitted for it.
Open source. Libertaria License. No per-seat fees. No compliance theatre. No vendor holds the keys to your flight computer. You own the code that keeps your astronauts alive.
Every state transition is Merkle-proven. Every firmware update is content-addressed. Every event is ordered and auditable. TRON has no concept of this. VxWorks doesn't even try.
Same codebase runs monolithic (performance), microkernel (isolation), or unikernel (satellite). One kernel, three deployment physics. No code changes. No recompilation for a different safety model.
The entire Nexus Core profile fits in less memory than VxWorks uses for its TCP/IP stack. When your rad-hard processor has 128 MB, every kilobyte the OS doesn't use is a kilobyte for science.
Wind River charges a fortune for 1987 architecture. Linux Foundation maintains
35 million lines of code that were never meant to leave the ground.
TRON is academically interesting and operationally frozen.
Nexus is none of these things. It is clean-slate, purpose-built, and open.
If you're an aerospace engineer tired of running mission-critical systems
on prayer and PowerPC nostalgia—the Forge is open.