LWN: Comments on "Asteroid "mining" with Linux and FOSS"

Asteroid "mining" with Linux and FOSS

nix — 2013-10-04T11:48:51+00:00

Yes, obviously one can design software specifically to evolve under directed mutation, and this has been done and is useful -- but unless we design *everything* that way (including OSes), we'll never get a machine analogue of evolution, and even software designed to evolve under directed mutation isn't going to evolve in the same way under random bit-flips, because the virtual machine that executes that is a) almost certainly much larger than what it's executing and b) not implemented in this fashion, so the first bitflip there and you're probably toast.

Asteroid "mining" with Linux and FOSS

oever — 2013-10-02T14:29:15+00:00

there is no bit-flip analogue of translocation!

Yes there is: instead of moving the code, you flip bits in the address referring to the code.

*None* of this is true of human-written software, ergo there is no evidence that it can evolve

unless it was written to mutate and evolve.

Radiation hardening

Wol — 2013-09-27T15:39:10+00:00

The other to bear in mind is the steady shrinkage in the size of the die. What you really want is a last-generation processor made using this-generation fabrication.

Let's assume a particle strike causes a 5nm "area of destruction". Do you want that hitting a track that's 10nm wide, or 30nm wide?

In other words, based purely on physical component size, older hardware will be more robust.

Cheers,
Wol

Asteroid "mining" with Linux and FOSS

Cyberax — 2013-09-26T19:30:17+00:00

Well, we can imagine that robots use a pre-weighted neural networks or something like it. In this case small changes can, indeed, accumulate.

And yes, the later Hogan's books grow increasingly more and more bizarre. I stopped reading after the fourth one. But the first book in the series is quite brilliant.

Asteroid "mining" with Linux and FOSS

nix — 2013-09-26T18:11:56+00:00

Of course, it couldn't actually work that way. The reason natural selection has room to work is that mutations in nature are both relatively frequent compared to bit-flips in hardware, much wider in scope (there is no bit-flip analogue of translocation!) and very often do not break or even greatly affect the organisms they happen in, because the code is redundant, many genes are duplicated, and most gene products are parts of networks with multiple redundant paths to the same end. *None* of this is true of human-written software, ergo there is no evidence that it can evolve (and plenty of evidence that it cannot).

As for Hogan, the depth of his understanding of evolution's "modern synthesis" is suggested by the fact that he become a creationist. (The depth of his understanding of other things is suggested by the fact that he became a Velikovskian (!) and multiple conspiracy theorist. Truly a man with a mind so open that his whole brain fell out.)

Asteroid "mining" with Linux and FOSS

Cyberax — 2013-09-23T16:58:59+00:00

> Interesting, I haven't seen a SF book exploit this possibility - yet it now seems the most likely way of a human-AI war to go ;-)

That's exactly the plot of "Code of the Lifemaker" by James Hogan. An alien mining spacecraft is damaged by a supernova explosion and crash-lands on Titan. It starts building mining robots, but some of their programs are damaged by the supernova explosion. So they start to evolve (eventually evolving full sentience).

Asteroid "mining" with Linux and FOSS

jospoortvliet — 2013-09-23T12:29:26+00:00

I find the idea of having a large number of half-independent, half-intelligent tiny robots exploring and mining our solar awesome and exciting. Soon they'll be self-duplicating, after all, that saves a lot of money over sending new ones up! Humanity will have millions of little workers out there, sending down resources, progressively further developed. At some point, much of our goods could be coming from space!

Meanwhile, a few stray ones with broken communication modules will get lost but continue to duplicate. The radiation will modify the code they are running, and where it doesn't impair duplication, become part of the new versions. Sometimes, a modification will give one a head start over others, allowing it to take the resources it needs for duplication - perhaps with force. Soon after, the strong will start to prey on the weak and 100 years from now, earth will be invaded by a swath of intelligent little killer bots.

...

Interesting, I haven't seen a SF book exploit this possibility - yet it now seems the most likely way of a human-AI war to go ;-)

ARKYD on Kickstarter

mtaht — 2013-09-21T04:42:52+00:00

Yes.

While I am glad the kickstarter campaign was such a a success, it never seemed clear to me that was being expressed and sold there was only the first fragments of the bold and magnificent dream. While getting a small spacecraft up and running in LEO IS a giant challenge in itself - getting to the next step - OUT of orbit, finally, into the nearer parts of the solar system - is the next big goal after that.

"Once in orbit, you're halfway to anywhere." - R.A.H.

I'd like to see Linux in use throughout the asteroids in the fairly near term.

ARKYD on Kickstarter

jnareb — 2013-09-19T19:14:02+00:00

Is it the same ARKYD as ARKYD: A Space Telescope for Everyone funded project (at $1.5M/$1.0M goal) on Kickstarter?

NSEU on the hypervisor?

cate — 2013-09-19T14:21:28+00:00

BTW it is the same method (triple hardware instead of radiation-resistant-hardware) used successfully by SpaceX Dragons (see e.g. https://en.wikipedia.org/wiki/Dragon_(spacecraft)#Radiation_tolerance)

NSEU on the hypervisor?

kh — 2013-09-19T13:39:52+00:00

I read it as right now they are simulating redundant hardware, but will launch with redundant hardware.

Radiation hardening

kleptog — 2013-09-19T08:51:29+00:00

I actually found the wikipedia article on this quite informative:

http://en.wikipedia.org/wiki/Radiation_hardening

Essentially you have two kinds of damage. Actual physical irreversible damage which degrades your chips over a long period. And transient spikes which can cause problems. The latter can sometimes be fixed by turning it off and on, but that seems a little difficult if you're doing it on one chip with VMs.

Still, given the price difference you can play the odds. If for the same price you can send up 100 of these things and a dozen fail you're still way ahead (except, perhaps, for the space junk).

NSEU on the hypervisor?

Cyberax — 2013-09-19T05:08:35+00:00

Unfortunately, shielding doesn't really help against cosmic rays. They are just too high-energetic. It helps against fairly slow-energy particles trapped in radiation belts, though.

NSEU on the hypervisor?

dlang — 2013-09-19T02:07:51+00:00

They are planning to send redundant hardware, that's how they will be able to survive and recover from radiation induced errors.

But, 3 $1K processors are still cheaper than 1 $200K processor, not to mention faster.

Now, they may discover that NASA is right and you really need a space rated processor to keep going

Or they may find that a little bit of redundancy and shielding lets them get by for a fraction of what a NASA mission would need, and have a lot more performance available as well.

NSEU on the hypervisor?

pflugstad — 2013-09-19T02:06:55+00:00

I thought of that as well, but then what if the microcontroller has a NSEU... its RAM is not protected either.

Asteroid "mining" with Linux and FOSS

mathstuf — 2013-09-19T01:50:21+00:00

But you could get a Kerbal to run a Rad750 in the test environment :D . Poor Jebediah :( .

NSEU on the hypervisor?

Cyberax — 2013-09-19T01:46:29+00:00

Spacecraft do not really need to have millisecond-precise control all the time. Indeed, quick reaction is important only during the powered flight stages.

I'd personally just install a very simple additional microcontroller to issue timed commands during these stages.

NSEU on the hypervisor?

pflugstad — 2013-09-19T01:35:46+00:00

So what happens when the hypervisor itself gets hit by a NSEU, either in it's instruction stream, or some data structure it maintains (page tables, vm function pointer table, etc). I don't see how triplicate VMs addresses that. I guess you could just reboot the system, but then what controls the craft while that happens. Are they planning on sending dual/triplicate hardware as well to address that problem?

Asteroid "mining" with Linux and FOSS

MrMorden — 2013-09-19T01:30:11+00:00

Physical machines could still handle the RT while coming in under the cost and power budget of a rad-hardened processor. So that just leaves the mass budget.

Besides which, there's no way you could get Kerbal to run on a Rad750. (Sorry; had to get a KSP reference in this thread somehow.)

Asteroid "mining" with Linux and FOSS

dchichkov — 2013-09-18T23:19:37+00:00

Interesting approach. Virtual machines instead of hardened hardware. I would guess it is going to be soft real time are a result. With jitter on the level of hundreds of microseconds... Scary.

Not sure what could be an alternative. Perhaps a C compiler that generates radiation hardened executable code?

Asteroid "mining" with Linux and FOSS

smoogen — 2013-09-18T22:56:21+00:00

I wish them luck. Having been on the periphery of similar projects back in the 1990's that were trying off the shelf parts they will need to make sure that they have multiple systems and that I am guessing their first test box is going to run in the Van Allen belts to give a good test on "high" radiation environments.