91–100 of 106 posts
Earlier quoted context omitted.
It's a tragedy some of our best minds are dedicated to that, and digital surveillance so their corporate masters can sell better targeted ads with a higher click-thru rate.
I really think it's overly generous to throw people who do not understand the importance of extending Voyager's scientific mission into the "our best minds" category. I guess I agree with the larger point.
Earlier quoted context omitted.
Understanding assembly language (any architecture) give insights into how computers work that are still valuable and relevant today. Almost nobody still writes code in assembly, but understanding it at least conceptually is still worth something. If I were hiring, I would almost always prefer a candidate who had some experience at machine/assembly programming to one that didn't, all else being roughly equal.
I've been a developer for 20 years, I do some reverse engineering stuff on the side using assembly. There hasn't been a single time in 20 years that it was actually relevant for real work in any way. Unless you are doing very specific work knowing assembly is about as useful as knowing COBOL (which is also useful for a very specific kind of work that most devs will never do)
> younger engineers often have the capability but not the inclination Kids these days... Why would someone in their right mind think working on the Voyager project could damage their careers? You can work on new and fancy tools all you want to improve supporting tools, and it's still one of the coolest space missions active. Plus, it has a real end - at some point, support will be further reduced and the person will…
I would go further... This project gives a rare opportunity for a young engineer to learn to build truly mission critical, resilient software while requiring complete, top to bottom understanding of the software and hardware stack.
A: I had a very slow network connection to the computer, and it was 23 light-hours away from me.
Earlier quoted context omitted.
> none of this existed like the cult it is now So you'd prefer for all this project management drama and power struggle to be invisible? All this scaffolding is not a cult. It exists to democratize the process. Your personal comfort is irrelevant to the results.
Unfortunately in many places it is indeed a cult and serves to ossify management decisions. We ARE doing Agile, what do you mean? No this person is the scrum master and they tell us what Agile is and then we do it, see? I have worked at 8 different software places and none of them implemented things in a way I would call "genuinely agile" and most of them were just bad waterfall with more meetings and telling the eng…
I mean of course it didn't exactly work like that in practice because directors had to have the corners and they wanted their teams close to them, so that, e.g. our team of 15 mainframe engineers could file in to a 5 x 5 meter cubicle and one-by-one give a report on what they had done the previous day a.k.a. The Scrum. We had a certified Scrum Master.
The one time I tried to sit in a different team's space I got yelled at by their director and had to go back. I had moved in his team's space out of protest because the only space left for me to be near my team was right in front of the gents and it smelled a bit funny. I was supposed to be sitting next to my (official) Mentor but I was studying part-time for a MSc and so was not there in the mornings and another engineer would always take my place next to the Mentor, who was the most experienced Cobol programmer in the team. He always looked at me with a wry smile whenever I came in to the office and found him sitting at ... well, it wasn't really my place so I couldn't really say anything. But then the only place for me to sit was in front of the loos. So I tried to go and sit somewhere else, farther away, in protest. And then I got yelled at.
But in principle we had hot-desking and we could sit anywhere throughout the building while communicating remotely with our colleagues.
We were very agile.
Our certified Scrum Master moved on before I did.
Earlier quoted context omitted.
I've been a developer for 20 years, I do some reverse engineering stuff on the side using assembly. There hasn't been a single time in 20 years that it was actually relevant for real work in any way. Unless you are doing very specific work knowing assembly is about as useful as knowing COBOL (which is also useful for a very specific kind of work that most devs will never do)
Learning new and weird things builds brain elasticity and vocabulary for you to express new ideas. I always recommend people to learn FORTH, or Lisp, or APL. Learn to think with different paradigms.
Regarding "that almost nobody on Earth fully understands anymore", I claim this is nonsense, and definitely not an obstacle. I've audited codebases in languages that I haven't programmed in. It is a matter of grasping a few basic concepts, like branch execution, branch destination, where data is stored, how it is communicated. Don Lancaster told us how to do this: https://www.tinaja.com/ebooks/enhance_vI.pdf .
I was puzzled by this claim, too. I think that the article is wrong, and that the code is written in HAL/S, a NASA-only language that sort of started off as a preprocessor to Fortran, though it has some PL/I-like features. If it really was written in Fortran, it probably was in a vendor-extended Fortran IV, which a lot of old guys like us know. But NASA used HAL/S for a number of projects, including the Shuttle. (And…
Earlier quoted context omitted.
I was puzzled by this claim, too. I think that the article is wrong, and that the code is written in HAL/S, a NASA-only language that sort of started off as a preprocessor to Fortran, though it has some PL/I-like features. If it really was written in Fortran, it probably was in a vendor-extended Fortran IV, which a lot of old guys like us know. But NASA used HAL/S for a number of projects, including the Shuttle. (And…
I think that the Voyager software is in assembly languages (there are several distinct computers on board), and that it is the program preparation software is written in a “Fortran V” extension.
As the should. Voyagers are still active and this maintenance is needed in case issues occur. In a way due to the +24 hours oneway communication to correct software issues should they occur, this will help speed corrections up. Now I wonder how the test it ? Is it on a software emulator on modern equipment or do they have a Voyager replica ?
They have a simulator for one of the three computers on Voyager, the Computer Command Subsystem. They don't have a simulator for the other two computers, the Attitude and Articulation Control Subsystem and the Flight Data Subsystem. They used to have a Voyager replica, the Capability Demonstration Lab, but they got rid of it after they moved the Voyager team into a satellite office following the end of the main mission. There's more information here if you're interested: https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2415
Regarding "that almost nobody on Earth fully understands anymore", I claim this is nonsense, and definitely not an obstacle. I've audited codebases in languages that I haven't programmed in. It is a matter of grasping a few basic concepts, like branch execution, branch destination, where data is stored, how it is communicated. Don Lancaster told us how to do this: https://www.tinaja.com/ebooks/enhance_vI.pdf .
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.
Earlier quoted context omitted.
Unfortunately in many places it is indeed a cult and serves to ossify management decisions. We ARE doing Agile, what do you mean? No this person is the scrum master and they tell us what Agile is and then we do it, see? I have worked at 8 different software places and none of them implemented things in a way I would call "genuinely agile" and most of them were just bad waterfall with more meetings and telling the eng…
My point is you would never even have a clue that there is dysfunction at all without these methodologies. These days you at least have some idea in your head how it should be vs how it is. I think there's something critical being lost in younger people who have never been exposed to the bad old ways and only understand their current situation through memes. We need to get a grip here.