Re:Asteroid samples escaping from jammed NASA spacecraft
by moron4hire on Tuesday October 27, 2020 @11:14AM
(#24908189)
Another part of the difficulty with updating servers is that updates are rather opaque. My own software on any given server is maybe 0.1% of all the software running on it (if even that). The other 99.9% is someone else's code: the operating system, the software runtime, the libraries, etc. So one doesn't really have a lot of insight into what is about to happen to the server without running a duplicate setup, which as you point out is pretty difficult to get right. I'm sure NASA has much more visibility into all the software that is running on their spacecraft.
Re:Asteroid samples escaping from jammed NASA spacecraft
by manquer on Tuesday October 27, 2020 @06:02PM
(#24912478)
While the abstractions is lesser for a spacecraft, I don't think any one is hand compiling or writing machine code directly. There will always be some abstraction layers.
Re:Asteroid samples escaping from jammed NASA spacecraft
by bumby on Tuesday October 27, 2020 @01:45PM
(#24909881)
While the requirement is there, often it falls through the cracks. A recent example is the wrong mapping of the Starliner thrusters. This wasn’t found until the simulator changed due to brownouts after it was already in orbit. Just by luck, the new simulator was of sufficient fidelity to catch the mapping error.
Had 1) they not missed the correct orbit due to a different issue and 2) not had to switch simulators it could have potentially collided with the space station.
So yes, the requirements are there but often not followed but luck was on our side
(Most of us are writing code in an environment where failure is totally an option, as long as it's fast and restoration is quick ;) ).