We're building Mru: A Fault-Tolerant Operating System for Thousand-Year Autonomous Operation

A seismic sensor in the desert. A satellite still working after it was meant to be dead. A probe between stars. Different scales, same shape. Each one holds all the power it will ever have, and nobody is close enough to add more before it matters. The work has to get cheaper every year, or it stops. The probe is the extreme version. Solve it there and the desert sensor is easy.

On a spacecraft, running the computer makes heat. There is no air in space, so the heat cannot blow away. The only way to lose it is to radiate it off a metal panel, and panels are heavy. Somebody has to pick a panel size before launch. They pick one big enough for the busiest moment the mission will ever have. Everything the software does for the next few hundred years happens inside that choice.

An interstellar probe runs on a power supply that only shrinks, and sending a message home is the most expensive thing it does. Late in the mission, a finding worth sending might wait decades for enough power to send it. This is not a bandwidth problem. It is a budget problem, and the software decides alone.

Picture a house where the power drops a little every year, and no one ever comes to fix it. First you turn off the lights you don't need. Then the heat. Then everything but the phone line. Mru makes these choices for spacecraft.

At Earth, sunlight delivers about 1400 watts per square metre. At Jupiter it is 50. The light thins out with distance and never stops thinning. An interstellar probe crosses light years of that. It carries its own sun, slowly dying since the day it launched. No hardware fixes this. The software is where the work is.

A sensor under the Arctic ice. A monitor in a sealed reactor building. A controller on Mars during a comms blackout. All of them run on a supply that shrinks, with nobody reachable in time. We are writing the part that decides what to keep running as the power falls. The problem is the same under the ice and between the stars.

There are three proven ways to power a craft far from the sun. Decaying isotopes. Small nuclear reactors. Or solar panels you do not open until you reach the next star. None of them lasts a thousand years on its own. So the question is not which to pick. It is what the craft runs on in century one, what it runs on in century five, and how the software survives the handover. Mru is built for that whole descent, handover included.

Deep space craft run on radioactive isotopes. They give off heat as they decay, and that heat becomes electricity. All of them have a half-life, and none can be recharged. Now imagine a mission meant to last 300 years. Or 1000. Long before then the power supply is a fraction of what it started with, and there is no way to add more. So we do not write software for a schedule. We write it for a decay curve.

A spacecraft has one power supply and it only gets weaker. Every job the computer does costs energy, and running one thing means switching something else off. Mru is built so that each part of the system has to say what it costs before it runs.

Power is the resource that decides how long hardware runs. Arrays lose output to radiation and dust. Batteries lose capacity with every cycle. The ceiling drops every year and nothing on board raises it. Software built for missions that run for decades or centuries has to spend power like it is never coming back.

Mru: a fault-tolerant operating system for a probe that must execute 500 to 1,000 years with no uplink, no maintenance and no human in the loop. mru.space

Mru is not an attempt to build software that lasts a long time. It's an attempt to build software that lasts without us. Systems that still run a thousand years after we're gone.

Mru targets software that must survive faults it cannot be patched to fix. The condition arrives by three routes. Law freezes it: nuclear reactor protection systems, avionics, implanted devices. Distance isolates it: subsea nodes, polar instruments, spacecraft. Time abandons it: controllers whose toolchain and vendor are both gone. Deep space is where the requirement is undeniable. It is not where the problem is common.

Mru asserts a spacecraft can execute for a millennium unattended. No experiment can confirm it. The longest unattended-decline record is Voyager telemetry: five decades. The extrapolation is twentyfold, and our whitepaper states it openly. So the first build isn't the OS. It's a kernel, and the simulator that does the aging.

Sixty years of COBOL clearing payments is not durability. It is life support, and the maintenance staff are the ventilator. An interstellar probe is issued no staff.

Voyager's continued operation requires a standing team, a 70-metre Deep Space Network aperture, and command sequences uplinked across a one-way light time of roughly a day. Break any link in that chain and the mission ends. Mru refuses to inherit the chain.

Across 3 x 10^10 seconds of uninterrupted execution, every latent defect is eventually reached and every unhandled branch is eventually taken. Probability one, given the operating hours. That is why Mru's kernel admits a machine-checked proof.

Two well-known results in software engineering pull in opposite directions: a program must keep changing to stay useful (Lehman), and every change makes it harder to change again (Parnas). Both assume a maintainer. But an interstellar probe won't have one, and communication will take years. The operating system has to be the maintainer.

Unattended, in the Mru specification, is a hard requirement: no uplink, no patch, no spare parts, no operations team, no tracking pass and no expert reachable at any point across 500 to 1,000 years of flight.

A probe launched now and still computing in the year 3026 will have outlived every institution that built it, most of the languages spoken at its launch, and the arrangement of the sky it navigates by. Mru is an operating system for that object.