6 ms·

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlin

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlink) it is very widely used. citation https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_spacex_software_team_ask_us_anything/gy8xyzh/ https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_s...

XorNot 2y ago
I wonder how the integration of PREEMPT_RT is going to affect that technology stack going forwards (I imagine slowly, but it's there now).
- yndoendo 2y ago
  Save costs by integration with the new feature or increasing cost with maintaining a custom kernel branch in the long run.
- chupasaurus 2y ago
  It was merged to mainline a week ago.
bboygravity 2y ago
And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).
- DrammBA 2y ago
  > And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke). why would that be mistaken for a joke?
  - vasco 2y ago
    Because they don't want people confusing the launch pad with left-pad and having the spaceship slowing down because of Facebook Like button embeds.
    - deleted 2y ago
      [deleted]
  - deleted 2y ago
    [deleted]
  - weard_beard 2y ago
    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 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?)
  - electrosphere 2y ago
    I believe it's because in JavaScript some values or expressions are "truthy" or "falsey" depending on how they are evaluated.
    - fennecfoxy 2y ago
      Many languages work like that and a lot of the issues people point out with JS are applicable to many scripting languages. Usually people point out Maths problems...aka problems with floats, which isn't really a JS problem. 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.
  - bboygravity 2y ago
    1. Because nobody in aerospace globally and in the history of humanity never did this before as far as I know. 2. Because many people not familiar with the exact application/industry (guilty) would assume that safety critical machines need to pass safety critical software tests/standards/languages. Javascript is definitely not known to fall in that category. 3. My main reason for thinking it was a joke when I first read it: I personally hate touchscreens (I actually use a phone with a physical keyboard on it). I would hate a touchscreen in a car, let alone a spacecraft. Let alone when I'm wearing a space-suit with massive gloves where touching the wrong button could maybe be life/death in the worse case or SUPER annoying in the best case.
- cliff 2y ago
  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 a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI. I made some observations: 1) We can create a prototype right now in Chrome, with its incumbent versatility. 2) The chip running the UI can actually reasonably run Chrome. 3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs. 4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform. The prototype was a great success; we were able to implement a lot of interesting UI in just a week. I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger. As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display. Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.
  - promoterr 2y ago
    [dead]
  - tobylane 2y ago
rurban 2y ago
In the old shuttles also. They had dSpace controllers, which used rtlinux

XorNot 2y ago

I wonder how the integration of PREEMPT_RT is going to affect that technology stack going forwards (I imagine slowly, but it's there now).

yndoendo 2y ago
Save costs by integration with the new feature or increasing cost with maintaining a custom kernel branch in the long run.
chupasaurus 2y ago
It was merged to mainline a week ago.

bboygravity 2y ago

And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

DrammBA 2y ago
> And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke). why would that be mistaken for a joke?
- vasco 2y ago
  Because they don't want people confusing the launch pad with left-pad and having the spaceship slowing down because of Facebook Like button embeds.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- weard_beard 2y ago
  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 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?)
- electrosphere 2y ago
  I believe it's because in JavaScript some values or expressions are "truthy" or "falsey" depending on how they are evaluated.
  - fennecfoxy 2y ago
    Many languages work like that and a lot of the issues people point out with JS are applicable to many scripting languages. Usually people point out Maths problems...aka problems with floats, which isn't really a JS problem. 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.
- bboygravity 2y ago
  1. Because nobody in aerospace globally and in the history of humanity never did this before as far as I know. 2. Because many people not familiar with the exact application/industry (guilty) would assume that safety critical machines need to pass safety critical software tests/standards/languages. Javascript is definitely not known to fall in that category. 3. My main reason for thinking it was a joke when I first read it: I personally hate touchscreens (I actually use a phone with a physical keyboard on it). I would hate a touchscreen in a car, let alone a spacecraft. Let alone when I'm wearing a space-suit with massive gloves where touching the wrong button could maybe be life/death in the worse case or SUPER annoying in the best case.
cliff 2y ago
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 a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI. I made some observations: 1) We can create a prototype right now in Chrome, with its incumbent versatility. 2) The chip running the UI can actually reasonably run Chrome. 3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs. 4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform. The prototype was a great success; we were able to implement a lot of interesting UI in just a week. I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger. As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display. Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.
- promoterr 2y ago
  [dead]
- tobylane 2y ago

rurban 2y ago

In the old shuttles also. They had dSpace controllers, which used rtlinux