151–160 of 160 posts
Step 1: Use linux
The problem was that their parameter file had no header for the machine type. Unchecked memcpy in space is seldom good, and you are lucky if it trips a shutdown. Rotating satellites don't tend to unrotate in time, and very soon they are gone.
Earlier quoted context omitted.
Personally, I wouldn't be stoked to run Linux on them either to be honest. But both are being done. Practicality rules I suppose.
Having sourcecode to everything would make me trust things more as at least we could fix things without calling MS. But what would you run? QNX? BSD?
Earlier quoted context omitted.
Can you speak at all as to how the development on this software is done? Is it distributed with centralized version control? Does release and engineering process interact with the version control at all? Are there mechanisms that link defect reports, corrections, and sign offs back to version control and into the build system? I got lost recently in how the Shuttle software was managed, mostly through IBM mainframes,…
> I got lost recently in how the Shuttle software was managed, mostly through IBM mainframes, and z/OSs facilities for all the above. I'm curious how modern development looks in comparison. Do you have any references for this? I also recently went down a research rabbit hole of the history of computing on Earth and in space - super interesting stuff. And the parallels are quite obvious when you look at it.
Oh yea. https://ntrs.nasa.gov/citations/20090001334
> And the parallels are quite obvious when you look at it.
The insane level of detail and strategy when writing the shuttle software is something to behold. The testing laboratory SAIL was a full scale orbiter that actually flew test missions. "Day of use I-Loads" are one of my favorite things. They couldn't change the software load, but they could move some constants around before launch, really useful for feeding wind data into the shuttle before it launched.
Earlier quoted context omitted.
I can't tell if this a serious comment or not, but they need an OS with realtime guarantees. They have claimed to use linux in a rtos configuration, also probably have a redundancy and voting-based failover system.
I can't tell if this is a serious answer to the question or not, as you have answered it in terms of the question: "why the need for RTOS? -> because they need RTOS". Stop wasting time with replies like this that add no value.
Earlier quoted context omitted.
> I got lost recently in how the Shuttle software was managed, mostly through IBM mainframes, and z/OSs facilities for all the above. I'm curious how modern development looks in comparison. Do you have any references for this? I also recently went down a research rabbit hole of the history of computing on Earth and in space - super interesting stuff. And the parallels are quite obvious when you look at it.
> Do you have any references for this? Oh yea. https://ntrs.nasa.gov/citations/20090001334 > And the parallels are quite obvious when you look at it. The insane level of detail and strategy when writing the shuttle software is something to behold. The testing laboratory SAIL was a full scale orbiter that actually flew test missions. "Day of use I-Loads" are one of my favorite things. They couldn't change the software…
Earlier quoted context omitted.
Wow a real SWE showing up and explaining how you can actually approach a real problem using a browser. Instead of just going "well its not compiled so clearly it will just randomly explode". I am always amazed how HN doesn't realize many mission & life critical systems are powered by JS - especially as a front end through a browser.
> I am always amazed how HN doesn't realize many mission & life critical systems are powered by JS - especially as a front end through a browser I am always amazed how some people believe that adding more levels of abstraction leads to safer systems. /s
As long as the risks are acceptable (single non mission critical display out of many may rarely crash) then it's fine imo.
Earlier quoted context omitted.
> And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke). why would that be mistaken for a joke?
I believe it's because in JavaScript some values or expressions are "truthy" or "falsey" depending on how they are evaluated.
People also point out stuff like `[]+[]` where Array addition operator is not overloaded to handle it at all because the correct way is to use `.concat` so I think by default duck typing comes into play and in most cases with that in JS the preferred type is string.
I do wish that there was a "cleaner" spec of JS that wasn't as backwards compatible but fixed all of the gotchas and filled in every gap but there doesn't seem to be much call for it atm.
Earlier quoted context omitted.
Every Starlink runs with Linux. The license list is a bit long: https://www.starlink.com/assets/pdfs/Starlink-Open-Source-Co...
It's surprising they didn't pick a RTOS.
In the same way that any pi project should really use i2c or spi to comms with hardware that's more purpose designed.