In this episode, Tim Bird (Sony) joins us to discuss Linux in space:
Tim’s path from early embedded Linux at Lineo (Sharp Zaurus) to 20+ years at Sony on cameras, TVs, phones — and now Sony’s space work (Space Communications Corp, the SLIM micro rover, and the STAR SPHERE satellite).
How much Linux is already in orbit: ~50% of satellites by project, ~90%+ by raw count thanks to Starlink’s 10,000+ Linux-based satellites.
The Space Grade Linux (SGL) project: modeled on Automotive Grade Linux, currently an ELISA work group, targeting a standalone Linux Foundation project in 2026. Delivers a meta-sgl Yocto layer with planned integrations for Space-ROS, Core Flight System, and F Prime.
The “big five” challenges of space — radiation, thermal cycling, vacuum, launch vibration, and no service calls — and how commodity hardware (Ingenuity’s Qualcomm processor, Perseverance’s base station) is pushing past traditional rad-hard designs.
Emerging work on fault-tolerant file systems (FTRFS, ZFS), QEMU-based radiation simulation, OTA updates at fleet scale (SpaceX Starlink), and why AI workloads on orbit favor a general-purpose OS.
How to get involved: monthly SGL calls, the meta-sgl repo at github.com/elisa-tech, and the BeagleV-Fire reference board.
Advice for newcomers: embedded is in a golden age — start cheap (Raspberry Pi, Arduino-based kits like CrunchLabs), blink some LEDs, and grow from there.
The excellent podcast episode with Tim Bird on embedded Linux in space touches on many topics. Out of memory and paraphrasing, Tim thinks Linux will be the OS of choice for space application, especially when AI workloads are involved (ML, perhaps LLMs). He also reports numbers like 90% of active satellites are on Linux because of the Starlink fleet, while only ~50% in terms of projects (so across companies and countries).
Indeed ML and related are basically developed and served on Linux. These software stacks are large, rich and complex, requiring dedicated hardware (GPU/NPU/TPU and other accelerators) and their drivers. Rewriting this all for space is very unlikely, so basing everything on Linux sounds very smart.
At the same time, I have been involved in more and more projects that seem Windows first, to the point that Linux lags behind by several months, when it happens, sadly, and often unofficial community work. Examples are support of AMD modern processors with iGPU and NPU like Ryzen AI and Versal (here AI Edge). Intel’s OpenVINO has been working fine on Linux these days, but it seems Windows first too—not sure, just a feeling. AI on the ONNX runtime is also Windows first, given ONNX is MS…
Last, Tim also shares that SpaceX is mainly a Linux company. It may have changed over time, and depends on the departments, but I was applying in 2016 for software there, and the job openings then were Windows (as a developer, not clear on deployment targets). I ended up not applying and know no more, but Musk is known with a preference for Windows (more precisely for the best business choice).
The excellent podcast episode with Tim Bird on embedded Linux in space touches on many topics. Re-reading the podcast summary to review the rich content, I stumble on the reasons why Linux is going to ease the spread of AI out there. I intend to listen to the episode again, but interested in expanding on the points listed by Tim.
What do you think are the reasons?
Out of memory and paraphrasing, I mainly remember the argument that ML and related are basically developed and served on Linux. These software stack is large, rich and complex, requiring dedicated hardware (GPU/NPU/TPU and other accelerators) and their drivers. Rewriting this all for space is very unlikely, so basing everything on Linux becomes the most likely.
It is counter intuitive that Linux can be reliable, and while I don’t work on any super high-reliability stuff, I can compare my experiences with Linux and Zephyr. If I deploy a Go app to an Embedded Linux system, I rarely have any problems - it just works. Zephyr on the other hand, I’m occasionally fighting resource problems (memory, handles, etc) as MCU devices are very resource constrained compared to MPUs. Typically, we think of smaller, simpler system being more reliable, but practically this is not always the case, especially with smaller teams who don’t have the resources to exhaustively verify the code. So sometimes, a more complex device without any resource limits (memory/performance) works better.
There is also the dynamic that widespread use tends to flush out problems, and this is one of the reasons a complex system like Linux can be so reliable: