_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Now that's engineering.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yep, they engineered that stuff to be rock solid. To use an age old phrase, they just don't build them like they used to.



Mmmm.... Asimov...... Spent a lot of time at airports reading the various Asimov stories.



The radiation of Jupiter would kill you before the gravity would. I had looked into the details of having a story set on a moon of a gas giant, and Jupiter was just a no go place for the most part. Saturn on the other hand, it's a bit friendlier.

It goes to show how much we tend to forget all that the magnetosphere that Earth has does for us.



To quote another great Sci Fi author:
"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong." -- Arthur C. Clarke

We could argue about the merits of various SF authors all day - I'm a big fan of 'golden age', though I never particularly liked Asimov's style.

As pointed out above, Jupiter is not a particularly healthy place to be, but I expected by now that people would be all over the asteroid belt - and in particular, working around Saturn. It has those great gaudy rings, conveniently already at orbital velocity, made of ice, and in convenient-sized chunks to launch at Mars...

Get enough water on Mars and it rapidly[1] becomes a livable place - water vapour at high altitude disassociates into free oxygen and hydrogen under the influence of solar radiation, and the mean free speed of the hydrogen means it escapes the atmosphere while the oxygen stays behind. And water at lower levels remains, well, wet water.

Neil

[1] Well, a few hundred years depending how fast you can start kicking icebergs on their way. But there is a small moon's worth of water ice in Saturn's rings, and it's surely worth the wait to have another basket to put our species' eggs, no?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Plenty of SF regarding many of the issues of generation ships... :p

Neil

I'm reminded of a piece it turns out I've mentioned before, in a different OT thread

Judging from what I can gather from the timeline of that rant, I'm guessing these rules came about after Lisp was gone from JPL and C-like languages became the only ones allowed.

https://en.wikipedia.org/wiki/The_Power ... tical_Code

These rules have come up here before, of course. Now I'm wondering if the demise of Lisp had anything to do with how hard it is to statically analyze what it's doing.

Ah, a complement to MISRA...

Of course now I'm wondering why NASA has all these guidelines for how to "safely" use an imperative language in the first place. Why not create a new language whose grammar and syntax makes it at least difficult, ideally impossible, to write problematic code in the first place? Why all the emphasis on after-the-fact checking tools?

1) Don't allow GOTO by not having it in the first place. For recursion, the first thought that occurs to me is that at run time, entry to a function first examines the stack to see if it's already there. Just in case static analysis misses this. A bit more time-consuming, yes, but contemporary processors are very fast.

2) Give loops a default bound. Explicitly change it if necessary. Make this built-in so everyone knows one is always there. Kind of like default array bounds in BASIC. You don't have to rely on them, but they're always there.

3) Don't like the heap? Don't have one. Darn thing fragments anyway.

4) It's easy enough to figure out the maximum number of characters on a page. Have the compiler barf if you try to feed it more than that.

5) Not sure how to automate this, aside from looking to see how they are often used in practice and trying to get the run-time package to check for the most common cases anyway.

6) Make it really hard to access data outside its declaration scope. I kind of like how in Python I can read a variable as long as it's in a higher scope, but I can't write it unless I somehow note that it's not in the current scope. That could be pushed to make both reading and writing an out of scope variable painful, and hence avoided whenever possible.

7) Make checking return value mandatory. Compile time failure if not done.

Don't like the preprocessor? Don't have one. It's mostly a kind of syntactic sugar anyway.

9) Fine, don't allow more than one level of de-reference (you can't even write such a thing). And don't make functions first-class objects that can be indirectly referenced.

10) Have the compiler sulk and refuse to create an object file if it sees the least little thing it doesn't like. That would lead to a lot of programmer frustration, but hey, we're talking safety here!

There could be a "C-NASA" version of the language, if you like. Might even be possible to eliminate some of the ambiguities along the way. No more "undefined behavior" quirks.

I'm just going to note that the software for the Voyageur probes was created decades before these guidelines came into place. There was probably some system of checking in place even at that time. What happened to those? They seem to have worked well. Are the ones in place now easier, simpler or more effective?

This is what happens if you build things without planned obsolescence
Now it's just "build to blast" everywhere instead of "build to last", and that's kind of sad.

_________________
ROR A? Where we're coding, we don't need A.

It may be my age and the nostalgia associated with the Apollo missions (although I was born by then, I was too young to watch the moon landings) but it seemed to be a golden age of discovery we'll probably never rediscover. However, the sheer effort required to put humans on the moon was a catalyst for technological advancement of which we're probably still reaping the benefits.

It never ceases to amaze me of the technology available at the time and how it was leveraged to do what was needed. I mean wire rope memory - what on earth!?

Spurred by this, the Voyager and Viking probes were further literal voyages of discovery.

Then it seems, something changed, and I can't put my finger on it. Our attitude to risk? Would we dare send 3 people to the moon now using that technology? The proliferation of computers into every system, sub-system, sub-sub-system - necessary but introducing a weakness?

We (collectively as a species) now seem to have had quite a few space related failures - but at least they were unmanned. Mars, travel outside the solar system, landing on asteroids - I think that the uber-complexity of systems required to accomplish such things means it's very difficult to not have "undocumented features" in software if there are millions (if not billions across all systems) of lines of code. Even if the code base is 99.999% correct, it going to leave potential for a few errors. It's then blind luck as to where and when they come to the surface.

One thing that has drawn me (back) to 6502 assembly is that fact that when I see a code listing, I see ALL the code. There no libraries of 1000s of lines of someone else's code of which I know nothing about. Using python or Visual Basic to print "Hello, World!" leads to obscene sizes of code. A few tens of lines of 6502 instructions accomplishes the same. I'm sure I've read that the 6502 is the only microprocessor approved for using in medical equipment like pacemakers. Testiment to its robustness in terms of reliability.

Maybe the bizarre answer is to write even more code? Have supervisor systems that poll, say, 3 applications written by different teams independenly that do the same things but in different ways and go with the consensus - a committee of computers?

IIRC from monitoring the NASA output when the first space shuttle flew (I was working for BBC News at the time) the shuttle had five computers, one from a different maker - though I don't know if the code was different - and all five had to agree before the blue touch paper could be lit.

There was at least one occasion where the singleton disagreed with the other four, and it turned out that it was right and they were wrong.

I suppose the issue with multiple systems having to agree is that with each computer design and each software design, you have the chance for a whole new set of bugs, either hardware or software.

Neil

It's worth reading up on the Apollo Guidance Computer - that was a real lesson in resilient design. The first fully fly-by-wire craft in history, and since they couldn't get things ironed out to the point where they could guarantee against crashing...they just made it as quick and simple as possible for it to resume from a crash, pick up where it left off, and give the pilot control again Aldrin actually did have to reboot it several times during the lunar descent...!