[ale] Backup large files to span DVDs

[Alex Carver]

On 2015-10-28 13:42, Jim Kinney wrote:
> On Wed, 2015-10-28 at 14:46 -0400, James Sumners wrote:
>>
>> I am glad I do not work where you work. Redundancy doesn't imply
>> corruption mitigation. And refusing to allow such to be implemented
>> because the tool isn't "old" is asinine.
>>
> It's not that things are refused because they are new. It's rather they
> are refused because they are not yet "well understood" and "mature".
> Mil-Spec work is _always_ like that. 
> Often, there are areas where software is never upgraded or changed
> because the systems are never networked. Thus any problem can never be
> fixed and the process that machine exists for _MUST_ be up at all
> times. So, no "new hotness allowed".  Imagine being stuck in a world
> where "new" was RHEL 5.

I'll give a real world example that's happening right now.  One of the
projects here is Voyager (you know the one with the two probes that
exited the solar system and are now in interstellar space).  The last of
the original project members (the project manager) has announced his
retirement at 83 years old.

Voyager wasn't expected to be operating past ten years after launch
(long enough to reach the primary targets Jupiter and Saturn).  It was
launched in 1977 but design and construction would have started in the
very early 70's (mission concept, design and construction of this class
is typically 6-10 years) which means the Voyager documents are now over
40 years old.  It's also still classified as an active mission because
it is still returning science data which means making sure the computer
and instruments on board stay running.  Voyager's code is assembly with
64 kilobytes of total operational program storage space on board (data
is recorded to an 8-track tape).

During the flights of the two Voyagers, many modifications to the code
had to be made.  This involved, among other things, knowing very
specific details about the instruments on board each one which turned
out to have very subtle differences.  The code has to be rewritten from
scratch every time because of the limited space.  It gets written on the
ground, verified, then uploaded.

Unfortunately, the data retention policies at the time were not very
stringent.  Since the mission was expected to last only about 10 years,
many documents were not updated and archived properly.  Engineers kept
details in their heads because they would likely still be working beyond
the end of the mission.  As the mission continued past its original
endpoint, this quickly became a problem when changes needed to be made.
 Many of the engineers have died taking secrets about the spacecraft
with them.  In other cases files have been lost to time because the were
written in formats that no one knew how to interpret (work is ongoing to
recover much of that data).  There's even a working replica of the
computer in the mission office today where code is tested before upload.
 It has been running since 1979 and still needs to be maintained.

It was because of this and other early projects (Explorer, Mariner,
etc.) that the data usage, retention and archive policy was tightened.
That included what software could be used and how generated data could
be stored.  The entire intent is to maintain an accessible, functional
history for scientists and engineers in the event we need to go back to
old data for anything.  That happens very often.