Posted
by
Soulskill
on Friday April 04, 2014 @08:30AM
from the go-big-or-go-home dept.

An anonymous reader writes "By the end of next week, NASA will release a master catalog of over 1,000 software projects it has conducted over the years and will provide instructions on how the public can obtain copies of the source code. NASA's goal is to eventually 'host the actual software code in its own online repository, a kind of GitHub for astronauts.' This follows NASA's release of the code running the Apollo 11 Guidance Computer a few years back. Scientists not affiliated with NASA have already adapted some of NASA's software. 'In 2005, marine biologists adapted the Hubble Space Telescope's star-mapping algorithm to track and identify endangered whale sharks. That software has now been adapted to track polar bears in the arctic and sunfish in the Galapagos Islands.' The Hubble Space Telescope's scheduling software has reportedly also been used to schedule MRIs at hospitals and as control algorithms for online dating services. The possibilities could be endless."

Then you are missinformed (in many ways) code does not age. If the surroundings don't change the code will run just as ever till the end of the universe.Regarding Cobol: strange that still in our days a huge percentage of code is Cobol.

COBOL code still works. However people don't want to use it in a terminal/terminal emulator. They want it on a Web Page, or at least via GUI screens. Being that these screens now have a resolution of at least 1024x768 (Usually much higher) vs 640x200 displayed in text of 80x25 people will want to see more data per screen, charts and graphs next to their data.We use to have positions called Data Entry and Computer Operators. Who's job was just to punch in data from one system to the next and people who use the software, who are trained not to cause it to crash. Today we get data from many feeds, and the system needs to be crash proof.Your New Device has a new set of User Inputs and Outputs that the OS needs to handle. Multi-Touch screens, Multible displays, Cameras, motion sensors, GPS... which could offer an advantage if implemented.

We look back at the old computers and we go wow how cool were they, they seem to do the same job as today's computers did but with 1/100th the performance. But what has changed is the software had gradually did more work, that you use to do by hand. Plus they are a heck a lot more reliable then they were 20+ years ago.

Factually incorrect: "Plus they are a heck a lot more reliable then they were 20+ years ago."

Over twenty years ago there were computers that hardware and software that were designed to work together. At least two of these systems had extra tag bits in memory that defined the memory contents. Specifically I am talking about Symbolics Lisp Machines and Burroughs Large Systems that natively ran Algol. I worked on both of these systems and they were intrinsically more reliable then any systems I know of today.

Because of the tagged memory they had hardware protection against a large class of errors that current systems encounter all the time. It was possible to find the bugs and eliminate them so they did not re-occur. It also protected against having undetected errors, which is a true nightmare.

Having hardware and software designed at the same time results in a better product. This is even more significant when the system is designed to run a specific high level language. Everything has less bugs.

Heck, Cray machines had ECC memory: SECDED. Single Error Correction, Double Error Detection. They needed it, because memory was not so reliable as today, but now you are lucky to just have a parity bit. All this work is going on, and no one has a clue if there are bad results or not.

As an industry we have gone backwards. That's not an opinion, it's an observation.

Of course these days all of this can be done, too, much faster, on off-the-shelf hardware. Just because the hardware doesn't have tag bits doesn't mean your compilers can't implement them. I'm running a bit of safety critical code on a bunch of ARM CPUs and all of the data RAM contents are tagged, pointers are tagged, and there is also software-driven error correction for RAM, execution log, restarts, those sorts of things that were en vogue at one point or another in the "hi-rel mainframe" market.

Over twenty years ago there were computers that hardware and software that were designed to work together. At least two of these systems had extra tag bits in memory that defined the memory contents. Specifically I am talking about Symbolics Lisp Machines and Burroughs Large Systems that natively ran Algol.

Or, rather, ran an instruction set with some features oriented towards ALGOL. Other languages could also be, and were, translated to that instruction set.

You're on to something here, but not for the reasons that you think. NASA has been releasing source for a long time. It's only that getting this source requires at least a mountainload of paperwork (U.S. citizens only, etc.), and it's usually costly. It's not like they don't have a catalog already. If it's going to be more of the same, then I'd call it outright deception. Note that nowhere it's stated that the code will be under a free source license!

I *wish* NASA had released the AGC source code. I run the project providing the Apollo 11 Guidance Computer Code (and other Apollo missions as well) which is linked in the summary, and I can assure you that none of that code was released by NASA, provided by NASA, nor was made available through NASA's assistance. You can thank some dedicated private citizens for the availability of that source code.

Perhaps, but the Apollo Guidance Computer that was mentioned in the links didn't guide the rocket (in spite of the name). The AGC was used only in the Command Module and Lunar Modules. The Saturn rocket was controlled by a different computer (the so-called LVDC), for which the source-code is not presently known -- by me, at least -- and therefore is assumed permanently missing. I'd love to be proved wrong (about it being missing), however. At any rate, even if it was a security problem once upon a time,

Agreed 100%. Ron and his fellow volunteers have worked on this for several years, not only transcribing the Apollo Command Module and Lunar Module flight software from paper listings, but also writing the toolchains and simulators with which to build and run it. And not only for Apollo, but also for the Saturn IB and V rockets, the Gemini spacecraft, and probably other things I haven't found yet. There are lucid explanations of everything, and original project documentation as well. The site is a treasure t

I gave up on it years ago, when I realized there were only 32 items in it. (2 have been listed as 'coming soon'). You'll find more open source software if you look at the lists that the individual centers maintain :

I predict that some military-general-turned-politician will start complaining about national security risks and taxpayer money being wasted (on something other than the military) and the project will suddenly find itself behind a security-clearance-only paywall.

It would be very cool to see the source code for the Space Shuttle. Its retired now so releasing it shouldn't have any operational impacts on the shuttle itself and I doubt the Chinese or the North Koreans or the Iranians are interested in building their own shuttle (and certainly not one using a hardware architecture developed in the 1970s reverse engineered from a source code release)