> Regarding "that almost nobody on Earth fully understands anymore", I claim this is nonsense, and definitely not an obstacle.It seems like you aren't very familiar with the history of the Voyager or the computer systems it uses. The Voyager has three onboard computers, each of which has a custom ISA. Two of the three computers were only used on Voyagers. After the main Voyager mission ended in the late 1980s and they were repurposed to collect data on interstellar space, the probes were reprogrammed to only require limited commands on one of the computers, and no intervention whatsoever on the other two. They also got rid of the testbench for testing code on the ground, so the only working Voyager systems are billions of miles away from Earth. Since then, Voyager has been operated by a skeleton crew that has been shrinking over time as people retire. The result of all of this is that they legitimately do not have a full understanding of how the hardware and software operates. Here's one example from a talk about how the crew fixed an issue with the Flight Data Subsystem, one of the computers that hadn't needed any significant software changes since the interstellar mission began (https://www.youtube.com/watch?v=dF_9YcehCZo):
> So our top priority was to figure out what the FDS was and how it worked. Because unfortunately the person who was the real expert had retired decades ago and the person who was their fill-in, their backup, had retired two years ago. So it was the worst place it could have hit us. These are some examples of some of the documentation we dug up on the FDS. So they're all hand written. These are some very dim circuit diagrams and these are hand written timelines for how to change FDS processors. We were lucky to find these. Some things we couldn't find. A lot of it was like this, that had been scanned. And frequently, these sources were contradictory, ambiguous. Why? Because we changed the way the spacecraft worked with every planetary encounter and entering the VIM and when things broke. So there was a lot of opportunity for ambiguity to arise in the documents over the course of 50 years. This is my favorite example. So this is a page out of an important FDS document. The change bar on the far side indicates it's a change, but somebody went in and made a very cryptic circle of the sentence and crossed it out. I have no idea to this day what it means. I have no idea. Maybe it was important. Maybe they crossed it out, because they thought crossing out was important. I'm not sure. So there were other cases like this. So we were even so confused in some cases, we weren't sure if we were sending data to the FDS - should it be least significant bit first or most significant bit first? We had that level of uncertainty.
> We didn't know we had the right instruction set. I showed you the instruction set there. We didn't know that was the one used to build the software, back when there was an assembler. We didn't know the source code version was the same as what was running onboard the spacecraft. We had a listing of the code, but it was a Microsoft Word document, with optical character recognition scans. We didn't know if there were errors in it. We had no assembler. So they're just playing with bits. There's no simulator and there's no test bed. So there were a few challenges. So basically this was bare knuckle binary manipulation. And they had to think of all the problems. I'm sure you guys are far better than I am of thinking of the problems associated with playing with memory like this. You could overwrite something. You can fail to recognize jumps. How do you debug it in flight on a flying spacecraft? And how do you know you're not missing something in those instruction sets and codes? And the list goes on and on.