How to avoid a BSOD on your 2B dollar spacecraft

Original Article ↗ Hacker News Discussion ↗

Engineers debate how spacecraft flight software should be built and tested to avoid triggering “safemode,” a protective state likened to a blue screen of death where satellites shut down non‑critical functions to survive. Most describe real satellites running custom C code, RTOSes like VxWorks or QNX, or carefully configured Linux rather than Windows, emphasizing formal verification, real‑time guarantees, and resilience to radiation‑induced faults. A recurring theme is the importance of rigorous, trustworthy ground testing and telemetry‑driven root‑cause analysis, especially when risk‑averse government customers demand explanations for every safemode event even during pre‑launch tests.

Was Windows Really Used?

  • Many commenters initially assume the spacecraft runs Windows due to the title and BSOD image.
  • Multiple replies clarify that the flight system is not Windows but a custom C “Flight Software” OS on an onboard computer.
  • Windows is mentioned as historically used on astronaut laptops and some ground systems, but not on the spacecraft bus itself.
  • Several people find the title misleading or click‑baity; others think the humor is acceptable and helped them read the article.

Operating System Choices for Spacecraft

  • Common bus OSes cited: VxWorks, QNX, LynxOS, RTEMS, and bare metal; newer or experimental missions sometimes use Linux.
  • SpaceX reportedly uses Linux with RT patches on Dragon and Starlink; some ESA and research payloads also use Linux on payload computers.
  • Suggestions include microkernels (seL4, Fuchsia), QNX‑like systems, or bare metal with minimal RTOS for critical control.
  • Discussion notes that QNX used to be more open but is now proprietary; no clear open-source equivalent.

Source Code vs Reliability

  • Debate over value of source access:
    • Pro: ability to review and potentially fix bugs, especially in long‑lived systems.
    • Con: in practice, teams often can’t modify vendor stacks or toolchains, so reading source can waste time if you can’t ship a fix.
  • Windows is noted as “source‑available” for big customers; some argue that still doesn’t help you rebuild or fork it.

Real-Time, Radiation, and Safety

  • Real‑time behavior is seen as essential for navigation/attitude control, less so for all subsystems.
  • Some argue Linux with RT patches is sufficient; others prefer traditional RTOSes for verification and timing guarantees.
  • Space radiation and bit flips are highlighted as major constraints, motivating specialized OSs and robust error handling.

Safemode, Testing, and Customer Dynamics

  • Safemode is described as the satellite’s self‑protective state: non‑critical functions shut down; power and comms prioritized.
  • Avoiding safemode during formal tests is politically important: each event triggers reporting and customer scrutiny, even if fully recoverable.
  • Commenters criticize relying on an unreliable ground test rig, noting this undermines confidence in testing.

Debugging & Operations

  • Arbitrary memory read/write from the ground is defended as a powerful diagnostic and patching tool, despite being “scary” to some.
  • Idea raised of using a fully deterministic “digital twin” on Earth to test patches before uplink, but bandwidth and hidden hardware state are concerns.