One cell holds millions of ribosomes, all running the same tiny program. Lose a few and nothing notices.
A probe's chip could work the same way: many copies of one small program, so losing part of the chip costs a little, not everything.
From the Mru paper: 'Robustness lives not in any part but in the replication of a simple interpreter over a mutable program.'
That sentence describes a living cell. It also describes the spacecraft we want to build.
NASA JPL's F´ is open-source flight software. It flew the Ingenuity helicopter on Mars.
Mru Flight now comes as F´ components. They're built, they ran in full in ESA's test environment, and on October 26 we proposed them to ESA for our third run in orbit.
In the late 1940s, John von Neumann showed on paper that a machine could build a copy of itself from a written description.
Almost eighty years later, that idea is where we start on a probe that has to rebuild itself around its own broken parts.
Your phone gets a software update every few weeks. A probe sent to another star will get none, for centuries.
Everything it will ever need has to leave Earth with it, including a way to adapt.
Every cell in your body runs the same tiny machine, the ribosome. It reads instructions and builds what they say. Nobody has maintained it for 3.5 billion years.
That is the design we want for a probe: a tiny reader that never changes, and instructions that can.
A service ship at an offshore wind farm costs about $40,000 a day, before fuel.
Most trips are for batteries, sensors and moving parts. Software can't fix those. But a processor that starts giving wrong answers shouldn't need a ship.
Mru Field keeps it delivering checked results until the next visit.
Our software successfully ran on an ESA satellite for the second time on October 22.
Its three copies failed one by one as planned. When the last one went bad, it stopped rather than give a wrong answer.
Then we shut the program off without warning. It restarted where it left off, with 0 wrong results.
The Long Now Foundation (@longnow) is building a clock inside a mountain in Texas, meant to tick for 10,000 years.
An essay about Mru will be in their Book of Time, out next spring.
We write software for machines that must keep working when nobody can reach them, at sea and in orbit.
The first machine to reach another star will arrive alone. Any question it sends home will take more than eight years to answer.
So the biggest call of the mission, what to look at first, it will make by itself.
We're building software that can make calls like that.
Most of us are taught to keep a reserve. Save some for later.
On a machine nobody can ever reach, there is no later. Power still in the battery when it dies bought nothing.
So the design spends hard early, while every instrument still works.
For nearly fifty years, a team at NASA has been switching off Voyager's instruments one at a time. Not because they failed. Because there was not enough power to run them all, and somebody had to choose the order.
That choosing has been done by people, in meetings, with decades of experience behind it.
We are trying to write down how they think, so a craft that has nobody can do it alone.
Anything that runs down without resupply has the same problem. A fuel tank, a stockpile, a satellite with a finite amount of thruster fuel. Spend it now or save it for later.
Usually somebody revisits that call as things change. Prices move, plans shift, a person reconsiders.
On a machine nobody can reach, the call gets made once and then runs with nobody able to revisit it.
On a machine nobody can reach, power is not something you monitor. It is something you have to spend on purpose.
So we built a gate. Every part of the system asks before it does anything, and the answer can be no.
Your laptop knows its battery percentage. It does not refuse to run something because of it. That gap is harmless here and fatal further out.
We write software for machines nobody can reach. The clearest case is a craft sent to another star, but it is not the only one.
There will be more of them. Sensors under ice sheets. Monitors inside places we sealed on purpose. Equipment on the seabed that was never meant to come back up.
We are going to put a lot of machines where people cannot follow, and almost nothing has been written for that.
Nobody designs for forgetting. We design storage, backups, redundancy, all of it aimed at keeping things.
A machine nobody can repair has to do the opposite. Its memory corrupts faster than it can be fixed, it will lose something either way. The only question is what.
We are building the part that decides.
We build software for a machine that gets sent far away and can never be repaired.
Somewhere in it is a single number: how much of its own future it is willing to give up for work done today.
Set it too high and it burns out early. Too low and it dies with everything it saved still unused.
The strangest part of this work is how much of it is deciding things on behalf of people who are not born yet.
What counts as interesting. What is worth the power to send home. What gets switched off first when there is not enough.
None of those are software problems. They are judgment, written down, by people who will not be there to explain themselves.
Everything we are doing is public. The paper, the code, the simulation models, all of it.
Not because open source is a strategy. Because nobody has solved this and we are not going to be the ones who do it alone. If somebody reads the paper and tells us the radiation model is wrong, that is worth more to us than keeping it closed.
There is no competitive advantage in being the only ones who get this wrong.