Earlier quoted context omitted.
It's surprising they didn't pick a RTOS.
They did.
How? That was a very recent change to linux.
How to avoid a BSOD on your 2B dollar spacecraft
121–130 of 160 posts
Re: How to avoid a BSOD on your 2B dollar spacecraft
#122Re: How to avoid a BSOD on your 2B dollar spacecraft
#123Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
> And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke). why would that be mistaken for a joke?
Attempt to give a serious answer: Javascript, as a language, has some bizarre return types that can make the kind of thorough testing required in spaceflight difficult. (See: https://github.com/denysdovhan/wtfjs) It also has a reputation, like PHP, as being utilized by inexperienced programmers who write poorly structured, poorly test, bloated, and slow code that often crashes and fails. If you want fast, light weight, reliable, well structured, testable, and ultimately very stable code Javascript would seem to be a poor choice within the parameters required for a space vehicle.
(Maybe this is a good place to ask, anyone have a recommendation for static testing of JS?)
Re: How to avoid a BSOD on your 2B dollar spacecraft
#124Earlier quoted context omitted.
To the shock and horror of many programming-inclined people, it turns out that having "arbitrary memory read/write" commands on a remote computer that *must* keep the mission going is quite useful. I can tell you a little first-hand account of where this helped a satellite formation flight mission I worked on. The communication system was working fine in terms of signal strength, but many command packets were ignored…
It occurs to me that writing software for spacecraft could demand an entirely different paradigm than writing software for traditional applications. For example, you could use an OS that is deterministic down to the last detail, and have a "digital twin" / virtual machine of the spacecraft computer here on Earth, kept in sync with all sensor and actuator activity out in space. Before issuing any command to the spacec…
Interesting idea. If you had control over the whole software stack down to the hardware, you could organize it in such a way that all meaningful mutable state is kept in a contiguous region of memory - and then you could just download or sync that.
I can imagine that these "state dumps" would be quite big though. And there is definitely some hidden state in the hardware blocks themselves (SPI, I2C, whatever...).
Re: How to avoid a BSOD on your 2B dollar spacecraft
#125Re: How to avoid a BSOD on your 2B dollar spacecraft
#126Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype. At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed…
>I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype.
Please tell me you have a blog
Re: How to avoid a BSOD on your 2B dollar spacecraft
#127Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
> 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.
Re: How to avoid a BSOD on your 2B dollar spacecraft
#128Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype. At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed…
Why doesn't anyone at Boeing make these observations? I don't think anyone needs to be persuaded that a browser is a good UI middleware.
Re: How to avoid a BSOD on your 2B dollar spacecraft
#129Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype. At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed…
At a minimum it should use typescript, no? Also web pages get out of sync sometimes, and need to be reloaded, which doesn’t sound great for mission critical reliability. Compiled, typed UI lib sounds like a better fit.
Re: How to avoid a BSOD on your 2B dollar spacecraft
#130Earlier quoted context omitted.
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype. At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed…
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.