60 replies
4d1h
The availability of skills is also an issue. Many of the engineers who worked on the project - Voyager 1 launched in 1977 - are no longer around,
Can you just imagine that? You wrote software in your 30s, and then 50 years later your grandchildren have to come visit you in the old folks home to ask you:
"Grandad, why did you write this goto statement at line 1892? Our AI think it might have to do with avoiding a hardware issue?"
to which you then reply, "my dear, even if you asked me one year after I wrote it, I would not be able to tell you."
See also: engineers of the B-52 bomber. It first flew 71 years ago and is expected to have another 30 years left.
There is at least one family that has three generations of B52 pilot (grandfather, father, son) [0]. Imagine being a coder who maintained code written by your grandfather and father...
[0] https://www.minot.af.mil/News/Article-Display/Article/264580...
Well, my grandpa didn’t know jack about computers, so I very well could have maintained code he’s written based on the disquality of stuff I’ve had to work on in the past.
But yeah. In “A Fire Upon the Deep”, Vinge talked about archaeological programmers. There’s no doubt in my mind we’ll reach that point. “Tell me again why time_t is only 64 bits?” “Pull up a chair while I dig out the LKML archive. You know, this was originally stored in electric fields, if you can believe it!”
Fire up the subspace ansible and create a holodeck room for us to talk about it. You can't name the holodeck program "CON", "LPT1", "PRN", or "AUX", though, because those are MS-DOS device names. ( https://news.ycombinator.com/item?id=37076523 )
To this day, I use
COPY CON FILENAME.TXT
to make a quick-n-dirty note of something without leaving the terminal.
I use `cat > foo.txt` all the time for the same reason.
There's an idea for another holodeck mishap episode right there.
The ship's replicators start spitting out PacMan ghosts which quickly overrun the passageways ala Tribbles, in the end it turns out Ensign Crusher attempted to pipe his holodeck game to PRN and the Ship's computer mistook that as a command to begin (3d) printing.
I bet they’ve replaced most of the computers by now, though.
Probably, but why’s that spar here? Why did they route that wire around the screw, and why doesn’t the 1960s bomb sight work right if the wire’s only twisted 3 times instead of 4?
Bomb sights aren’t used anymore. The weapons used by the B-52 are all gps guided and the computer on board simply gives a timer for the pilot to press the pickle button. The weapon then self guides to the target.
That sounds believable, but I bet they still have lots of surprisingly old equipment that works too well to bother replacing.
Can you just imagine that?
No this is not a plausible scenario.
I mean, this stuff does happen.
There is an old electric station near me that is used for various things sometimes. Some band was in there shooting a music video and bumped something and somehow the whole area started filling with water. Nobody could stop it.
The government, the water company, everyone was struggling to figure out what to do, and they decided to call the old guy that used to work there. He was in his 90s but he told them how to fix everything.
I would love to read the full story on this.
If it doesn’t end up with an itemised bill of $1 to turn off a stopcock and $999 to know where it is, I’d be disappointed.
Because you never write gotos? Many embedded and kernel programmers still do. I think it makes sense in general.
It is known as error handling. Some languages renamed the practice to try/catch. Others added a Result type.
Likely you know this, and you're just being funny, but the try/catch statement is more like setjmp/longjmp in C. The Result type in Rust is syntactic sugar for integer return codes, returning early on errors, and tagged union structures. And where C programmers use goto statements, C++ programmers use destructors, and Rust programmers use the Drop trait. Walter Bright also says that nested procedures in D eliminate most use cases of goto for him.
You can also always avoid goto, in C, but usually, either it has excessive if-statement nesting, it uses boolean flag variables in loop conditions, or it uses structures to create state machines, but these are usually just uglier and more error-prone than the equivalent version using goto. The same applies to avoiding break, continue, and early returns.
COBOL exists. Billions of lines of COBOL still in production today. The scenario is already happening now.
I’m not sure what you are calibrating against but I feel like the last 20 odd years are full absolute batshit crazy stuff that doesn’t make sense and this seems rather tame.
I wouldn't dismiss that scenario. It seems plausible that the documentation is so extensive that it takes time and effort to answer some questions. It might be easier to just ask the authors, if they're still around.
I know a developer in his 70's who maintains code he wrote in his 20's
Going out on a limb here, wouldn't code written that long ago be almost impossible to hack with modern tools? (not to mention still using the old hardware.)
One of the Best Practices for maintaining software that you expect to support for decades involves archiving the development tools used.
Of course, finding a platform to run it on could be a problem. Also, the License Server that so many proprietary tools need before they'll run.
I remember hearing about some hardware made for the government (military?) where the development tools ran on some 1970s minicomputer that had long since ceased to function, but it was no problem because in the 80s they wrote an emulator that ran on 68k, specifically an Amiga since that's what someone had sitting around the lab at the time. Then in the 2000's they realized the supply of Amiga parts wouldn't last forever so they bundled the whole thing up to run in an Amiga emulator that ran on whatever version of Windows was current at the time. Then 16-bit Windows ceased to be a thing, so....
This is pretty close
I’m not sure why that would be the case. If anything, I’d expect earlier code to be easier to hack.
The timeframe described would work for something written for a System/370, no? That stuff, along with the tooling, will run all day long on a current Z Series.
I would love to hear more about this if you can share any details
My understanding is that its very well documented, but the funding isn't there to do much with it. I mean most of the team behind things like the Atari computers, Acorn, Commodore, early Apples, etc are retired but we can emulate them and understand these things on a very technical level. I know this isn't a great analogy, but ultimately age of the project or the age of the original team members isn't the bottleneck.
I sometimes see retro projects on hack-a-day done by people who could be the grandchildren of the original designers of those vintage chips and OS's. They probably know more about that chip or OS than the original people do just due to them being out of the game for so long. The same way people regularly lose to fifth graders in tests because they dont recall 5th grade science and civics. If anything your scenario might be the opposite! Grandpa might be asking his granddaughter how those registers worked or how to emulate his OS from 1982.
I remember reading about the team that maintains the Voyagers. Its a skeleton crew using legacy equipment to keep the communication going with the assumption the next decade, or even earlier, is going to be it.
NASA has the same problem the private sector has. Capitalism rewards things that will generate profit/prestige, not legacy cost centers, and NASA is not immune from that dynamic as NASA employees and managers want to maximize their income and prestige too. So the people maintaining or bug fixing old products are often lowest on the prestige, pay, recruiting, and profit spectrum than those chasing new things. They get the skeleton crew funding and can't do novel things, even if technically possible because of lack of staff and buy-in.
Passion projects make for feel-good documentaries like 'It's Quieter in the Twilight' but ultimately if society isn't vested in these teams, their hands will always be tied.
A young engineer must know that getting stuck on a legacy project is a career-limiting move. Happened to me when I got stuck on a old Ada codebase for a legacy aerospace system (unemployed in 2008, you take whatever job you can get), and it took years, and a good chunk of my spare time doing projects/studying, to find a company willing to give me a chance working on something modern again.
Now, someday when I'm in my 60s/70s, and you have some legacy system written in some defunct language nobody under the age of 50 has any experience with, sure, I'll do it. But it'll cost you.
Why do companies do that? Shouldn't it be enough that you have experience contributing to a large project long-term and you can program decently? Is it that modern programming just requires different/additional programming skills compared to most old codebases, like writing asynchronous code?
I don't hire, but that story would make me want to hire you. It takes certain skills and pig-headedness to successfully work on old software!
I once asked a company to rehire me saying that I only wanted to do software maintenance work (I wanted low stress). I am good at it, and it's hard to find people that want to do that work. They didn't rehire because although the manager really wanted me back, his idiot boss had taken it personally when I had quit. Idiot boss later got ousted to their dismay: I shouldn't enjoy that but I did!
I hate people just random throw in capitalism. Is the communism better in maintaining old code … do they even exist. Not to mention please we are here not for the money as most does not, just awe of what can be done for a computer job which love to do and have such legacy.
Capitalism does not really exist. It is money, incentives, job, human … or love to hack.
I'm going to just outright dismiss this comment the way you're dismissing people talking about capitalism, a very real economic system we're all living under, since it's ridiculous on its face.
The thing Voyager has going for it is, it's a small team. JPL is laying people off all over the place lately.
I'm not sure if it's really "society" that is responsible for these funding difficulties, it's the politicians. If you ask a random member of the public how much of the federal budget is allocated to NASA, they'll generally give you a percentage that's wildly higher than the actual figure.
I'm kind of surprised, what with all the retro computing emulation software and skills I see getting posted here, that we don't have a Voyager emulator scene and a group of people standing by to run scenarios and propose fixes.
Not that I'm skillful enough to make an emulator, but I've tried years ago to find technical documents on the Honeywell HDC-402 used in Voyager and Viking (it's also apparently not related to the DDP-516 or 316 AFAIK.) There's SOME information[1], but not enough to make an emulator from what I've found.
Aside from the lack of schematics or listings, there was the problem of the assembler being incomplete!
"One problem Lander software developers had was that no adequate assembler was ever written for the computer, perhaps because of the changing nature of the instruction set.(110) Patches had to be hand-coded in octal, with many jumps to unused memory space because of the lack of an assembler with relocatable addressing." p.174 on Viking, which used the same computer
[1]https://ntrs.nasa.gov/api/citations/19880069935/downloads/19... (page 174 onwards)
As far as I can tell the HDC-402 wasn't even the Viking computer that got reused on Voyager anyway - it was something NASA developed in-house from the orbiter side of the Viking mission and that presumably has even less documentation available.
You're confusing the 24-bit HDC-402 on the lander with the custom 18-bit computer on the orbiter (p.164), which had it's origins in the sequencer for the Mariner missions (p.152-154).
Though given the apparent level of NASA involvement in the 402's design, and the lack of evidence I can find for use outside of NASA, it might as well be called custom.
DarmokJalad1701 below mentions about hearing a podcast where new engineers did work on VMs
Any details? We have people work on a dead moon lander…why not a live v1/2. If sadly one is dead, the other still has some life left ?
That would be very interesting. Someone please tell me such a community exists somewhere.
I'm going to be a humorless pedant and reply by saying that with the level of forward and backward traceability required of aerospace software, it's unlikely that such a level of misunderstanding could occur. But maybe DO-178 wasn't a thing back then.
That's just from what I've heard, though. I do medical devices. I'm told that my aerospace counterparts have it even tougher than we do.
Therac-25 happened in 1982 and changed that industry (and safety engineering in general) quite a bit, no?
Yes, but I don't get your point.
Voyager launched in 1977, well before the therac-25
OK. And?
There is a nice documentary about what remains of the Voyager project team. The video is not free however.
https://www.itsquieterfilm.com/
I watched that a couple of months ago and loved it. It does a lot to humanize that team, I've been thinking of them during the recent news cycle.
Yes, I have nightmares like this all the time.
If only it was merely nightmares and not my day job.
I never thought of this before now, but tech from 1977 might not even be using ASCII.
Great question! Voyager 1 does appear to be using ASCII. :D
https://destevez.net/2021/09/decoding-voyager-1/
No, but I did find myself in the mid 90s as an intern trying to figure out code from the early 80s. It was really tricky code to get ECG processing working on some very small memory footprint or something. The name of the woman that wrote it was at the top of the file, and I looked her up in the HP company directory and she still worked there. As a hail-mary, I emailed her and asked a question about it. And she immediately got back to me with the answer. So, there are some engineers out there that do remember this sort of thing.
LOL. I remember being asked to consult for my last employer on a problem they had while attempting to port some software that I had written almost 20 years earlier. It's amazing the random details that you remember when your memory is jogged.
It’s funny which code I remember and which code I don’t.
There’s code I wrote 10 years ago at work that I still remember and can point out exactly where everything is. Then there’s code I wrote last week that is completely gone.
I would use my old person privilege to berate you for using "AI" to "understand" the code rather than getting your soft hands dirty.
I (and at least couple thousand other people) are still running code I worked on in 1987. Maybe we should do something for the upcoming 40th anniversary...
I have definitely had to do archeology on 20+ year old code, including disassembly to work out actual production code was when it clearly wasn’t the version we had source for, and that’s now 30+ year old code which I expect will still be in productions at least a decade from now.
Equally I’ve seen COBOL compiled to new platforms because it has outlived all the systems it ran on.
I’m pretty sure there must be areas of Java, or C++’s standard libraries that haven’t changed for a very long time, and will continue to be used for decades.
The thing is, it’s often easier to just figure out the code, or rebuild the whole underlying platform, than to track down the original author and hope it wasn’t a Friday afternoon commit.