If anybody else is interested in the topic, the seminal work on software development at NASA is the Fast Company feature from 1996, "They write the right stuff":
Worth saying that doesn't apply outside manned missions. They notoriously crashed a probe into Mars thanks to erroneous imperial to metric unit conversion.
EDIT: also the VxWorks fan stuff here is a bit odd, given the other notorious error involved setting the task priorities so that the probe spent the whole time checking the weather, but never phoned home. They were just lucky they shipped the thing in debug mode and reprogrammed it once it had landed.
That pathfinder bug was a priority inversion caused by failing to enable priority inheritance when creating mutexes, not quite as simple as setting the priorities wrong. VxWorks wasn't entirely at fault, although the priority inheritance feature was not obvious. Concurrency is hard. See http://research.microsoft.com/en-us/um/people/mbj/mars_pathf... for details.
you really, really should never write things such that task priorities must be of a certain arrangement for the thing to work properly. It's very bad form. Also, from the link "Tasks on the Pathfinder spacecraft were executed as threads with priorities that were assigned in the usual manner reflecting the relative urgency of these tasks." Yeaaaaaugh! "PRIORITIES DO NOT WORK THAT WAY!" - Morbo.
I worked on VxWorks and Linux on Intel's IXP embedded processors before, and VxWorks' performance and memory footprint were always better than Linux's. For 'Performance' I refer to network throughput because IXP was meant to be for routers and gateways. It was around 2006 so I am not sure what these two OSes are up to now. Don't flame me because I am just speaking from my own experience.
I was watching the Planetfest rebroadcast of Curiosity's landing, and mention was made of there needing to be two operating systems: one to deal with entry and landing, and the other to handle roving and research. The speaker went on to say that both OSes don't fit into RAM at once, so they would have to be swapped over post-landing, and that this would take four days to load from Flash.
Raises the question: why does it take four days to swap an operating system in from Flash, and how does the system go about it while having a path to fall back?
Personal theory: The hardware used has to be low powered, and be able to withstand physical and radiological abuse. Such a system probably will not post the fastest clock cycles, what with power consumption being proportional to frequency^2 and all.
I'm also going to guess that most of the available RAM will be used for redundancy.
I'm guessing the copying doesn't take four days unless they are actually sending the program from earth, in which case ~256MB over X-band to Mars could take that long. Rather I would guess that this copy is a many step procedure they do one step at a time and confirm at every step. With a 28 minute round trip to tell the rover to do something and get a response time adds up quick.
I wonder if the time taken is because it must use very tiny amounts of power, and survive at such a low temperature. They may be using a very slow processor, or a special low-power, low-temperature NAND or whatever variant.
It depends on how one defines slow. Curiosity's onboard computer is 100x faster than the previous two Mars rovers, and has twice as much ram. But that's only 200MHz and 256MB respectively.
With the exception of Sojourner, the first rover successfully placed on Mars, all Mars rovers have run VxWorks.
I remember an HP tape array running VxWorks crashing when a copy of Nessus would scan it. There was no patch for the issue at that stage. This was a tape array backing up some infrastructure that would handle the transactions of a big chunk of Europe's stock exchanges. It kind of left me with a bad impression of VxWorks, but it might just be HP's processes that was a mess at that stage.
I wonder what the ground control software is written in. I know that for one of the previous ones, they used Tcl and Tk, and the first screenshots they showed with the first image were the X windowing system if I've ever seen it.
VxWorks is used pretty extensively in space and defense contracting. The list in wikipedia is a pretty small sublist. It's also often used as a wrapper for custom bootroms.
Try getting some functional safety certification on a Linux distribution and you see why Linux is not really gaining much weight in certain areas of the embedded market.
However, it is getting small inroads in the instrument clusters for Automobiles. (http://www.genivi.org/)
VxWorks is a real-time OS. I didn't know whether there was a real-time variant of Linux and what I found was that there was, but Wind River acquired the company that was working on it and essentially killed it.
From what I understand, Linux runs the rover simulator environment - known as RSVP. It consists of a DSL that is used to direct the rover's operations and a visualization environment. This way the ground crew can first plan and test the activities they want the rover to perform in this simulated environment and then upload the action plan to the rover - so overall Linux plays a pretty important part in the the rover tech stack.
Most probably the initial rovers ran VxWorks RTOS, because back then it was the best choice (even now it isn't a bad choice at all) - complex systems are built incrementally.
Aside from what others have mentioned keep in mind that something being sent to another planet usually has 5-10 year old technology at best. For reference in 2003 Linux 2.4 was the latest stable version.
From their careers page:
"Our Flight Software Group currently has opportunities developing software for embedded flight hardware using Linux and VxWorks as well as ground simulation software using Linux."
http://www.fastcompany.com/node/28121/print?donttaseme