Linux on Mars: The Ingenuity Helicopter and Orbital Infrastructure
Series: Linux Wednesday | Episode: 18 | Arc: Orbital Frontier (2021-2026)Hook type: Memoir-technical parallel (personal reflection on Ingenuity flight + ANE-01 callback; D7 pending)Strategic intent: Connect the open-source engineering choice behind Ingenuity to the orbital compute governance gap now forming around Starcloud and Project SuncatcherCross-series callbacks: Space AI Monday (primary; orbital governance), EA Thursday (orbital jurisdiction as architecture problem), Gen AI Tuesday (AI sovereignty at orbit), Cyber Sunday (GPL as supply-chain audit right)NTP claim scan: 14 e-type claims identified; all sourced or qualified. MarCO CubeSats (Flag 4): qualified as "according to accounts at the time." Starcloud Linux (Flag 3): explicitly framed as inference from Crusoe Cloud deployment pattern. Space Mafia thesis (Flag 2): framed as author's established argument from published book. Watchdog timer patch (JPL): sourced to JPL via multiple secondary sources. No unverified entities presented as confirmed without qualification.
[NAVIGATION LINKS: Not applicable for narrative series]
The news arrived on 19 April 2021. A helicopter named Ingenuity lifted off the Martian surface and flew for 39 seconds. The first powered, controlled flight on another planet. Four and a half billion years of geological silence, broken by four carbon fibre blades attached to a Qualcomm Snapdragon 801, running Linux.
I did not think about the aviation milestone first. I thought about a 486 sitting on a desk in 1994, compiling a kernel for 28 hours while the disk light burned without stopping. The same lineage of software. Not metaphorically the same; technically the same. The kernel that Torvalds released in 1991, which I first ran in 1994, which I have been using in production in one form or another for three decades since, flew on Mars because the engineers at JPL chose open source when they could have chosen anything else.
That choice was not accidental. It was a considered engineering decision. And it tells you something important about what open source actually is, and why it matters when the infrastructure starts leaving the planet.
In Episode 17, I wrote about Linux entering the kernel: the thirty-year language argument settled not by decree but by the one thing that always settles these arguments, working code in production. The supportability principle runs through both episodes. The further the substrate runs from the people who maintain it, the less you can afford to rely on discipline alone. Mars is the extreme case. This is where that argument lands.
Why Linux flew on Mars
Ingenuity was a 1.8 kilogram experiment, a proof-of-concept helicopter tucked under the belly of the Perseverance rover. Its mission was not science. Its mission was to find out whether powered flight was possible in the Martian atmosphere, which has a density roughly one percent of Earth's.
The flight software was built by Tim Canham at JPL using a framework called F Prime, which Canham had designed in 2013 as a reusable, modular system for CubeSats and small spacecraft. F Prime ran on top of a custom embedded Linux distribution. The processor was a Qualcomm Snapdragon 801, the same chip that powered the Samsung Galaxy S5 in 2014. Canham selected it because it met NASA's radiation standards and because it was, as he noted in post-flight interviews, far more powerful than the Perseverance rover's own processors. The flight software ran a 500Hz control loop, reading sensors and adjusting rotor speed 500 times every second to keep a 1.8 kilogram machine stable in one-percent atmosphere.
The entire software stack was open source. After the successful first flight, Canham described the result directly: the team was "flying an open-source operating system and an open-source flight software framework, and flying commercial parts that you can buy off the shelf." Nearly 12,000 contributors to the open-source libraries that Ingenuity depended on had their code flying on Mars without knowing it. Someone who submitted a documentation fix years earlier and never thought about Mars was, technically, a contributor to the first powered flight on another planet.
JPL had placed Linux near Mars before the first surface flight. According to accounts at the time, the two MarCO CubeSats that relayed landing confirmation for NASA's Mars Insight lander in 2018 carried Linux-based computing systems on board. Ingenuity was the first Linux system to physically operate on the surface. When a watchdog timer issue delayed the first flight by a week, the team diagnosed the problem remotely, wrote a patch, tested it in testbeds in Pasadena, and uplinked the fix to a helicopter sitting on Mars. They could do that because they had the source code. They had the source code because they chose open source.
The quiet empire in orbit
Ingenuity was the moment the public noticed. The occupation of orbit by Linux had been under way for years before that.
By 2026, SpaceX has more than 10,000 Starlink satellites in low Earth orbit, each running a custom Linux-based firmware on a quad-core ARM Cortex-A53 processor. A recent analysis by the Space Grade Linux project, an initiative incubated within the ELISA open-source safety working group, estimated that Linux now runs on approximately 90 percent of operational satellites by count, driven almost entirely by Starlink's scale.
How SpaceX manages firmware updates across that fleet illustrates something about Linux that has nothing to do with licensing debates. Updates travel over the Starlink constellation itself, not over terrestrial networks. SpaceX uses an A/B partition scheme: the update writes to the standby partition, and on reboot the bootloader switches. If something goes wrong, the system reverts to the previous known-good partition. The update is atomic. There is no service call possible. There is no engineer available to climb onto the roof of an Antarctic research station and apply a manual fix.
The GPL-mandated source code releases that SpaceX publishes for the Linux kernel it ships are not an ideological gesture. They are the legal price of using a software infrastructure that was built for exactly this kind of deployment. The Bazaar demands compliance as the price of participation. That is not incidental to the design; it is the design.
That constraint, no maintenance engineer available, is the constraint that concentrates the mind. When you cannot send someone to fix it, you have to build software that works without human intervention, updates itself reliably, and fails safely. The Linux community has been developing those properties for thirty years in production infrastructure. Boards asking their cloud providers about resilience architecture would do well to understand this history: the orbital environment did not ask for a different kind of software. It asked for more of the same.
The next layer
Ingenuity proved Linux could fly. Starlink proved it could operate at scale in orbit. The question now is whether orbit can become a computing platform in its own right, not just a communications relay.
In November 2025, a startup called Starcloud launched a satellite carrying a single NVIDIA H100 GPU into low Earth orbit. The H100 was roughly a hundred times more powerful than any GPU that had previously operated in space. Starcloud ran an AI inference workload on it, then trained a language model on orbit, and became the first organisation to do both. The satellite, Starcloud-1, weighed around 60 kilograms and used cooling technology adapted from International Space Station heat-rejection systems. Starcloud's software stack was not fully documented in public filings at launch, though the Crusoe Cloud partnership that underpins its ground infrastructure uses Linux-based virtualisation throughout; that deployment pattern almost certainly extends to the orbital layer.
Starcloud had been founded in 2024 to address a problem that has nothing to do with space: terrestrial AI data centres are running into hard limits on grid capacity, cooling water, and available land near the population centres that consume compute. The company's argument to investors was power arbitrage. Terrestrial power is becoming scarce and expensive faster than launch costs are falling. At some crossover point, orbital compute becomes cheaper per watt than building another gigawatt-scale campus. Investors accepted that argument. Starcloud raised $170 million at a $1.1 billion valuation in April 2026. Starcloud-2 is scheduled for October 2026, carrying multiple H100s and incorporating NVIDIA's Blackwell architecture.
At the same time, Google announced Project Suncatcher: constellations of solar-powered satellites equipped with Google's Trillium-generation tensor processing units, interconnected by optical laser links, operating as a distributed data centre in sun-synchronous orbit. A solar panel in that orbit collects energy up to eight times more efficiently than a ground-based panel, with no night cycle and no weather. Early modelling examined an 81-satellite cluster operating within a one-kilometre formation radius. The first demonstration, with Planet Labs, is targeted for early 2027. Google's testing showed the Trillium TPUs survived simulated radiation exposure equivalent to five years in low Earth orbit. The physics does not preclude the concept. The engineering challenges are significant but defined.
The governance question
The Linux kernel got to Mars because JPL chose an open, auditable software stack. They could inspect every line of F Prime before it flew. They could read the kernel source. When they needed to patch the flight software mid-mission, they could do it because the code was not a black box supplied by a vendor who might or might not support the mission for its full operational life.
That choice about auditability was made by engineers. Nobody voted on it. The engineers picked the best tool for the job, and the best tool was open source. This is exactly how Linux spread across the planet in the 1990s and 2000s: one engineering decision at a time, without a central authority directing it. The Bazaar, not the Cathedral.
The orbital compute wave that Starcloud and Project Suncatcher represent is arriving faster than any governance conversation about it. When Starcloud-1 ran its first AI inference job in November 2025, no international treaty clearly defined whose law applied to that computation. The satellite crossed every jurisdiction on Earth in approximately 90 minutes. The company is incorporated in Washington State. The GPU was designed in California. The model it ran had been trained on data gathered from everywhere. The output belonged to a customer whose location was not specified in any public filing.
That is not a hypothetical. It is the current state of orbital compute governance: jurisdiction changes every 90 minutes, and the legal frameworks have not caught up. The EU AI Act's provisions extend to AI systems with effects in the EU. Whether an orbital inference job serving EU customers qualifies is an open question no regulator has publicly answered. The CLOUD Act asserts US government access to data held by US companies regardless of the physical location of the servers. Starcloud is a US company. Those obligations apply to it in orbit by default. That default was not set by legislators weighing data sovereignty; it was set by engineers selecting a launch provider.
My book Space Mafia examines exactly this pattern: the people who control the orbital substrate control every layer above it, and the governance conversation that should accompany orbital infrastructure is running decades behind the engineering. The argument is essentially this: the GPL ensures you cannot take the Linux kernel proprietary. No equivalent principle governs what runs in an orbital data centre. I explore the full orbital governance question in the Space AI Monday series. The Linux story is where the substrate comes from. The governance question is where Space AI Monday picks it up.
The open-source principle offers at least one thing that proprietary systems do not: an orbital Linux system is auditable by anyone with the technical skill to read kernel code. Proprietary orbital firmware is a black box controlled by whoever holds the licence. When the infrastructure runs above the atmosphere and crosses every nation's airspace, auditability is not a convenient property. It is the closest thing to accountability that actually exists in orbit.
The technical community has been making this argument implicitly, one engineering decision at a time, for thirty years. The question now is whether it will be made explicitly, before the proprietary defaults lock in.
When the first AI model was trained in orbit, the choice of what software it ran on was made without a policy framework. Should there have been one, and if you were writing it, what would it require?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a Wellington-based enterprise architect and technology strategist with more than 30 years of experience across cloud, AI, and transformation programmes in government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of Space Mafia and Generative AI 2026. A Concise History of Linux chronicles the operating system that changed the world, and the lessons it holds for the AI era. He can be reached at linux@linux.co.nz.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] NASA / Jet Propulsion Laboratory. "Meet the Open-Source Software Powering NASA's Ingenuity Mars Helicopter." April 2021. https://www.jpl.nasa.gov/news/meet-the-open-source-software-powering-nasas-ingenuity-mars-helicopter
[2] Canham, T. JPL Mars Helicopter Operations Lead. Post-flight interview, April 2021. Cited in LinuxGizmos, IEEE Spectrum, and JPL official news release.
[3] LinuxGizmos. "NASA's Martian Helicopter Runs Linux." February 2021. https://linuxgizmos.com/nasas-martian-helicopter-runs-linux
[4] GitHub / NASA. "NASA Open Source: The Open Source Powering the Ingenuity Mars Helicopter." GitHub README/Featured. https://github.com/readme/featured/nasa-ingenuity-helicopter
[5] Bird, T. Space Grade Linux Project (ELISA). Interview on orbital Linux adoption. Podcast transcript, approx April 2026. https://tmpdir.org/052
[6] SpaceX GPL Source Code Releases. Linux kernel source publications, multiple versions. Verified via Quarkslab analysis. https://blog.quarkslab.com/starlink.html
[7] Hubble Network Community. "How SpaceX Manages Firmware Updates Across Its Satellite Fleet." February 2026. https://hubble.com/community/guides/how-spacex-manages-firmware-updates
[8] CNBC. "Starcloud Launches Satellite with NVIDIA H100, Trains First LLM in Orbit." December 2025. https://cnbc.com
[9] Introl Blog. "The First Language Model Trained in Space: Starcloud's Orbital Milestone." January 2026. https://introl.com/blog
[10] Tech-Insider. "Starcloud Raises $170 Million Series A at $1.1 Billion Valuation." April 2026. https://tech-insider.org/starcloud-170-million-series-a-space-data-center-2026
[11] Google Research Blog. "Project Suncatcher: Solar-Powered Orbital Compute." November 2025. https://research.google/blog
[12] DatacenterDynamics. "Google's Project Suncatcher: 81-Satellite Cluster, Trillium TPUs, and Five-Year Radiation Testing." 2025/2026. https://datacenterdynamics.com