<![CDATA[The Low End Disruptor - Medium]]> https://medium.com/the-low-end-disruptor?source=rss----16704e6008f5---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png The Low End Disruptor - Medium https://medium.com/the-low-end-disruptor?source=rss----16704e6008f5---4 Medium Sun, 15 Nov 2026 17:24:08 GMT <![CDATA[The King Is Dead: Jensen Huang’s Nvidia Ousting and the Holy Grail of Founder Control]]> https://medium.com/the-low-end-disruptor/the-king-is-dead-jensen-huangs-nvidia-ousting-and-the-holy-grail-of-founder-control-2c503623bd4b?source=rss----16704e6008f5---4 https://medium.com/p/2c503623bd4b Thu, 12 Nov 2026 17:24:31 GMT 2026-11-12T17:24:30.922Z Why Nvidia’s board could remove its founder CEO, and how startup founders can use dual-class shares, board seats, and voting control to protect their companies

The Unthinkable Happened on a Thursday

The headline news is shocking.

This morning, November 12, 2026, Nvidia’s board said Jensen Huang had resigned as President, CEO, and director, effective immediately. CFO Colette Kress is now interim CEO. The board also named Harvey C. Jones as its first-ever chair, which tells you it had been a one-man show for 33 years.

The board’s word is “resigned.” Most headlines went with “ousted.” Days earlier, CBS had reported the board was preparing to remove him. You decide which word fits.

Here’s the short version. A New York Times report alleged multiple affairs, including one with a Singapore data-center executive whom U.S. officials reportedly suspected of ties to Chinese intelligence, at a firm that bought billions of dollars of Nvidia hardware. Another alleged affair was with a senior executive who reported directly to him. Huang had already admitted infidelity in a memo to employees on November 9. Then came national-security questions, demands from lawmakers, and a stock that fell roughly 10%, wiping out hundreds of billions in market value. After that, the end came quickly.

Set the morality aside for a minute, because the board didn’t need to settle it. What I want founders to notice is the mechanics.

Jensen Huang co-founded Nvidia in a Denny’s in 1993. He bet the company on GPUs, then on CUDA, then on AI, and grew it into a company worth more than $4 trillion. He is about as close to a founder-god as Silicon Valley has.

And he had no structural protection whatsoever.

Nvidia has a single class of stock: one share, one vote. Its board was made up of independent directors plus Jensen, and it could remove the CEO with or without cause by simple majority. Mark Zuckerberg can’t be fired. Larry Page couldn’t be fired. Jensen Huang, the man who made the AI age possible, could be shown the door in a week.

If that doesn’t make every founder reading this check their charter, nothing will.

Jensen Huang at Stanford, April 2026, seven months before the fall. Thirty-three years of vision, and a single class of stock.

Why Founders Fall: A Short History of Losing Your Own Company

Founders don’t usually lose control in one dramatic boardroom scene. They lose it gradually, through a series of small and individually reasonable decisions.

Act I: One share, one vote. For about sixty years the NYSE refused to list companies with dual-class shares. The idea was that voting power should track economic risk. Ford’s 1956 IPO, where the family kept super-voting shares, was the famous exception. Media dynasties like the New York Times Company got a pass on the grounds of editorial independence.

Act II: Google changes the rules. In 2004, Larry Page and Sergey Brin took Google public with Class B shares carrying 10 votes each. The public bought it anyway. Facebook, LinkedIn, Snap, and Alibaba all followed. Hong Kong held out, lost Alibaba’s $25 billion IPO to New York, and changed its rules in 2018. By 2021–22, about 47% of U.S. tech IPOs were dual-class.

Act III: the slow loss of your majority. This is the part nobody puts in the pitch deck. According to Carta’s 2025–26 data, founders typically hold:

The median founding team’s stake by funding stage (Carta, 2025–26). By Series C, the option pool owns more of your company than you do.

  • ~56% after Seed
  • ~36% after Series A (thanks, pre-money option pool)
  • ~23% after Series B
  • ~16% after Series C, which is less than the employee option pool

Capital intensity makes it worse. If your company works with atoms (chips, robots, biotech), you burn two to three times the cash of a SaaS company and sell more of the company at every round. Jensen is the hardware founder’s cautionary tale: decades of capital-hungry growth, and nothing left to vote with when it counted.

The lesson: you don’t lose control when the board votes. You lose it, one term sheet at a time, years before.

Case Study: Apple and the Prodigal Son

Every founder knows this story, and every founder assumes it couldn’t happen to them.

In 1985, Steve Jobs was 30, a co-founder of Apple, and the person most responsible for its products and culture. He had no super-voting shares. The Macintosh launched to great reviews and disappointing sales. Jobs’s “my way or the highway” style wore everyone out. John Sculley, the Pepsi executive Jobs had personally recruited with the famous “sugar water” pitch, moved to take away his operating authority.

Jobs tried to get Sculley removed instead. The plan leaked, the board backed Sculley, and Jobs, with no structural power at all, resigned and went off to start NeXT.

Steve Jobs with the Macintosh in January 1984. Sixteen months later, the board picked the sugar-water guy.

What followed was a twelve-year slide that brought Apple to within about 90 days of insolvency in 1997. The board, out of options, bought NeXT, mostly to get Jobs back. You know the rest: iMac, iPod, iPhone, and the most valuable company on Earth.

Dual-class advocates like to say that if Jobs had held super-voting stock, Apple would have skipped a lost decade.

Maybe. I’ll give you the more uncomfortable version. The Jobs who got fired was probably not the Jobs who saved Apple. NeXT and Pixar humbled him and taught him things, and he came back a better CEO. Getting fired may have been the most valuable thing that ever happened to him, though it’s hard to see it that way while it’s happening.

The Counter-Lesson: WeWork, or What Happens When Nobody Can Say No

Now for the cold shower.

Adam Neumann got the thing Jobs never had: 20 votes per share. The board couldn’t fire him, investors couldn’t overrule him, and he ran the company accordingly.

He bought buildings personally and leased them back to WeWork. He trademarked the word “We” and had his own company pay him $5.9 million for it. (He reversed that after the public backlash, which is a bit like returning the cookie once your mom has already seen the crumbs.)

Adam Neumann: 20 votes per share and $5.9 million for a pronoun.

When the S-1 came out in August 2019, public investors saw $47 billion in lease obligations against $4 billion in committed revenue, plus governance that made Apple’s 1985 board look like the Federalist Papers. The IPO collapsed and SoftBank had to fund a bailout. Neumann was out, and in 2023 the company filed for Chapter 11.

Here’s the lesson I care about most. Super-voting stock does two things: it protects you from the market’s panic, and it protects you from your own mistakes. The first is valuable. The second can kill the company. The same structure that would have saved 1985 Jobs from Sculley also saved Neumann from anyone who might have told him no.

The Founder’s Toolkit and War Chest

So what should you actually do? Here is the playbook, roughly by stage. If you can, negotiate these terms when you have leverage, which means before you need the money.

At formation

  • Founder-friendly charter from day one. Authorizing a high-vote Class B before institutional money arrives is far easier than recapitalizing later. Musk said he wanted 25% voting control at Tesla and admitted that retrofitting dual-class after the IPO is close to impossible. Don’t put yourself in that position.
  • Clean vesting and 83(b) elections. These are boring and they are essential.

Seed through Series B

  • Board composition is the real cap table. Lock in seats elected by common stockholders. A 2–1–2 board (two founders, one independent, two VCs) holds up much better than a board where you have one seat and keep telling yourself the independent director is on your side.
  • Supermajority to fire the CEO. Make your own termination without cause require a supermajority of the board. That gives you a veto over your own exit.
  • Drag-along guardrails. The 2026 NVCA baseline lets a majority of preferred force a sale. Push for a dual trigger (preferred and common) and a price floor, so you can’t be forced to sign a deal in which the liquidation preferences consume everything and common gets nothing.
  • Series FF shares. These let you take some money off the table in a later round without giving up voting control. A founder who can pay the mortgage makes better long-term decisions.

Pre-IPO

  • Dual-class with a sunset you choose. Glass Lewis and ISS now recommend voting against directors at companies that IPO without a time-based sunset. Pick your own, seven to ten years, before someone picks one for you.
  • Choose your jurisdiction deliberately. Delaware’s new Section 122(18) makes founder consent rights in stockholder agreements enforceable again after Moelis. Texas offers friendlier rules for controllers and has a growing business court. (See: Tesla’s move after Tornetta.)

Throughout

  • Character is part of your governance. No structure would have protected Jensen this week. Nvidia’s code of conduct, the national-security issues, and lawmakers demanding briefings would have overridden any share class. Super-voting stock doesn’t protect you from regulators, prosecutors, or your own direct reports.

The Balance: Governance as Seatbelt, Not Leash

The academics have a useful framework for this. Agency costs are the damage a founder does when nobody can stop them; that’s WeWork. Principal costs are the damage investors do when they’re in charge: panic, short-termism, and a buyback where an R&D budget should be. That’s 1985 Apple.

Law professors Zohar Goshen and Richard Squire argue the right structure minimizes the sum of the two. A visionary founder in a 20-year bet like AI, VR, or rockets should get more insulation. A mature company with a founder who has drifted should get less.

The data supports this. Dual-class firms trade at a premium at IPO, because markets value the founder’s vision. Around seven to ten years later, that premium tends to become a discount as the founder’s economic stake shrinks while their votes don’t.

The founder-control spectrum. Stay too far left and you can be fired in a week; go too far right and nobody can stop you from walking off a cliff.

So the goal isn’t maximum control. It’s control that fits where your company is in its life: enough insulation to make long-term bets, with a working mechanism for someone to say “stop” if you lose your way.

Jensen had plenty of the first and none of the second, which was fine for 33 years until this week. Neumann had too much of both. Jobs had none, and it took a lost decade to fix.

A Look Into the Future

Here’s what I expect over the next five years.

1. The Jensen effect on fundraising. Founders raising in 2027 will bring up Nvidia in every board-composition negotiation, and investors will bring up WeWork. Both are fair points.

2. Trust-based structures as the new middle ground. Anthropic’s S-1 shows a new model. The founders hold a Class F share that gives them 50.1% of ordinary votes, while an independent Long-Term Benefit Trust with no economic stake elects a majority of the board. The founders control the shareholder vote, and the trust controls the board. OpenAI’s foundation keeps exclusive power over its PBC’s board even though Microsoft owns 27% of the equity. These are deliberate checks and balances in a company charter, and you’ll see others copy them.

3. Sunsets become standard. Perpetual founder control is ending. Index providers, proxy advisors, and institutional investors all agree on that. Expect seven-to-ten-year sunsets to become the price of a dual-class IPO.

4. The jurisdiction wars continue. Delaware vs. Texas vs. Nevada. Your state of incorporation is now a strategic decision, not a box your lawyer checks.

5. Character as a governance mechanism. This is the uncomfortable one. As founders gain more structural protection, the remaining risks come from conduct: personal behavior, conflicts of interest, national security. Those risks don’t care how many votes your shares carry.

My closing advice to every engineer-founder reading this:

Fight for control early, when it’s cheap. Protect it with structure, not just goodwill. Give it an expiration date before someone else does. And above all, build a company and a character that a board would never want to fire.

Jensen Huang built one of the greatest companies in history and still lost it in a week. Your share structure can’t fully protect you from yourself, so you’ll have to manage that part on your own.

References

Image Credits

The King Is Dead: Jensen Huang’s Nvidia Ousting and the Holy Grail of Founder Control was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[SpaceX Wants to Be Your Phone Company. It Just Hired Qualcomm to Build the Radios.]]> https://medium.com/the-low-end-disruptor/spacex-wants-to-be-your-phone-company-it-just-hired-qualcomm-to-build-the-radios-75646ef63a06?source=rss----16704e6008f5---4 https://medium.com/p/75646ef63a06 Wed, 04 Nov 2026 22:22:57 GMT 2026-11-04T22:22:57.204Z The company that put thousands of routers in orbit is now coming down to earth: steel towers, rooftop leases, zoning boards and all. Here’s what’s planned, how 5G works, and why the hard part isn’t the rockets.

Back in February 2020, I wrote a parody called “SpaceX Starlink Master Plan”, in the voice of a certain CEO. It copied the “trickle-down” structure of Tesla’s master plan, in four steps:

  1. Build a bulky, expensive terminal for professionals.
  2. Use that money to build a rooftop consumer terminal.
  3. Use that money to build “a low cost and high volume mobile phone.”
  4. Build an interstellar communication system for Mars and beyond.

Fake-Elon also bragged that Starlink could beat 5G because the carriers “need to deploy a lot more cell sites,” while Starlink doesn’t “need to pay site rentals and backhaul.” For the astronomers, he promised to paint every satellite chroma green “so they can be easily removed in photoshop.”

Six and a half years later, steps 1 and 2 happened, if not quite in that order (consumers came first): millions of pizza-box dishes, on roofs and on boats. Step 3 took a turn I didn’t see coming. SpaceX never built a StarPhone; it made every phone a StarPhone, beaming signals straight to the one already in your pocket. And now comes the twist the parody never imagined: SpaceX is about to pay site rentals. Lots of them.

For about 30 years, American mobile service has worked like this: three giant companies own the networks (the airwaves, the radios bolted to the towers, and your monthly bill), and everyone else rents from them. Not even the giants own most of the towers anymore. Over a decade ago they sold or long-term leased them to landlords like American Tower and Crown Castle, and now pay rent like everybody else. Upstarts have tried to break in. Most have ended up as footnotes, or as a Boost Mobile ad.

Now a rocket company wants a go. On November 4, 2026, SpaceX and Qualcomm announced a multi-year deal under which Qualcomm supplies the core radio silicon and software for a nationwide terrestrial 5G network under the Starlink Mobile brand. SpaceX already has phone service coming down from orbit. This time the plan is phone service coming across, from tens of thousands of ordinary cell sites. Construction starts in 2027; when you can actually get service from them, nobody has said.

So: what exactly was announced, how does the technology work, and how many billions of dollars and zoning hearings stand between SpaceX and your SIM card?

1. The Announcement: Starlink Gets a Ground Game

What SpaceX said

The short version:

  • Qualcomm supplies the guts of the radio access network (RAN): the radio-unit and baseband platforms (chips plus reference designs) and the commercial-grade Layer 1 software, all from its Dragonwing cellular infrastructure line. SpaceX builds the actual boxes around them. Neither company disclosed the dollar value.
  • Scale: “Tens of thousands of sites,” according to the announcement, and Qualcomm executive vice president Durga Malladi expects the rollout to “ramp up pretty rapidly.” Unconfirmed press reports say SpaceX is talking to tower owners about access to as many as 80,000 sites; no tower partners have been named.
  • Timing: Tower deployment starts in 2027. No launch date for terrestrial service has been given. Separately, SpaceX is targeting early 2028 to switch on its next-generation “full 5G quality” satellite service.
  • Ambition: a genuine fourth national carrier that owns its own network, not just another reseller.

Malladi called it “huge,” and agreed with Light Reading that it’s Qualcomm’s biggest network deal since 3G. For a company best known for the modem in your phone, that’s a big deal.

Wait, what’s Dragonwing?

Dragonwing, launched in February 2025, is Qualcomm’s brand for its industrial, networking and infrastructure silicon, the chips that go into things other than phones.

The Dragonwing toolbox (the deal announcement names the QRU100 and QDU100 platforms specifically):

This gear has been deployed before, though not at this scale. Vietnam’s Viettel runs Qualcomm-based radios across “a few thousand sites,” and Qualcomm chips have shown up inside radios from NEC and Mavenir (which has since quit making radios). SpaceX is about to become its first customer at continental scale.

Qualcomm handles the physical layer, the hard real-time signal math. SpaceX is expected to write its own Layer 2, Layer 3 and core network software on top. As Malladi put it, “They still have to do the Layer 2, the Layer 3, and so on.” That’s very SpaceX: buy the chips and own the software, the same way it treats rocket engines and satellite buses.

The airwaves SpaceX has lined up

Radios are useless without airwaves, and in about 13 months SpaceX has agreed to spend roughly $28 billion on spectrum (not all of it paid yet):

  • EchoStar (September 2025): about 50 MHz of 2 GHz AWS-4 and H-Block spectrum for about $17 billion (half cash, half SpaceX stock), plus roughly $2 billion of EchoStar’s debt interest. In November 2025 SpaceX added a 15 MHz uplink-only AWS-3 slice (1695–1710 MHz) for about $2.6 billion in stock, for a total of roughly $19.6 billion. The FCC approved the deal in May 2026 and allowed the spectrum to be used from space, on the ground, or both, which SpaceX CFO Bret Johnsen calls crucial. The final closing, when SpaceX actually pays, is expected around late 2027.
  • Grain Management (October 2026): up to 14 MHz of paired, nationwide 800 MHz low-band spectrum for a reported $8 billion (terms undisclosed; FCC approval pending). These airwaves started life at Nextel, passed to Sprint and then T-Mobile, which sold them to private investor Grain for about $3.6 billion ($2.9 billion in cash plus Grain’s 600 MHz licenses) in a deal that closed in August 2026. Grain flipped them to SpaceX two months later for more than double that, which suggests either very good timing or a buyer in a hurry.

SpaceX is also reportedly (per the Washington Post) in talks to buy Boost Mobile from EchoStar. That would bring an existing customer base, retail distribution, and wholesale roaming deals with AT&T and T-Mobile, two carriers that have so far shown little interest in signing anything directly with Elon Musk.

2. The State of American Wireless: Three Giants and a Rounding Error

The incumbents

The U.S. market is a mature three-way oligopoly. Verizon, AT&T and T-Mobile together serve the overwhelming majority of American phone lines, each with roughly 120 to 147 million connections. Cable companies (Comcast’s Xfinity Mobile, Charter’s Spectrum Mobile, about 23 million lines combined) have become the fastest-growing challengers, but they cheat a little: their consumer service runs on Verizon’s network as an MVNO, and they push as much traffic as possible onto their own Wi-Fi (plus some CBRS small cells).

A quick scorecard:

  • T-Mobile: the 5G speed leader, thanks to Sprint’s mid-band spectrum. It holds “nearly 400 MHz” of airwaves. Remember that number.
  • Verizon: the coverage champ, finally growing again (406,000 postpaid phone adds in Q3 2026).
  • AT&T: betting on fiber-plus-wireless bundles, and swapping its Nokia gear for Ericsson’s.

AT&T and Verizon each plan to spend $16–24 billion on their networks in 2026, and T-Mobile about $10 billion. That’s the annual fee for staying in this business.

Pay more, get… about the same

A three-way oligopoly is a comfortable place to be, if you’re one of the three. Americans pay some of the highest mobile prices in the developed world:

Source: Connect Europe, State of Digital Communications 2025.

Notably, South Korea also has just three carriers and still charges far less, so the number of players isn’t the whole story. Scale, geography and decades of regulatory choices all play a part.

That pricing turns into money. The Big Three post EBITDA margins in the mid-30s percent, which makes them some of the most profitable mobile operators anywhere. European carriers, squeezed by cutthroat competition, have spent the past decade complaining about the opposite problem.

What do Americans get for the premium? A good network, but not a world-beating one. Opensignal’s Global Network Excellence Index ranked the U.S. 14th in the world in late 2025, behind South Korea, among others. Ookla’s Speedtest index has put U.S. median mobile download speeds somewhere between 9th and 13th in recent months, far behind the Gulf states and South Korea. And the rural dead zones are still there. In fairness, covering a huge, sparsely populated continent costs more than wiring Seoul. But that gap between price and performance is exactly the opening a fourth carrier is looking for.

The cautionary tale named Dish

The last company to try building a fourth facilities-based network was Dish (later EchoStar). Regulators made it the designated fourth carrier as a condition of the T-Mobile–Sprint merger, which closed in 2020. It built what it billed as the world’s first cloud-native Open RAN 5G network and hit its 2023 coverage milestone of 70% of the population (its later deadline was pushed back). Then in 2025 it agreed to sell its spectrum to AT&T and SpaceX, and it is now moving Boost customers onto AT&T’s network as a hybrid MVNO. Its wireless unit filed for Chapter 11 in mid-2026.

So the most recent attempt to build a new U.S. carrier ended with a handful of companies dividing up its airwaves, and SpaceX was one of the buyers.

Where Starlink 5G could fit

SpaceX isn’t going to out-Verizon Verizon in midtown Manhattan in 2028. It’s going after the problems the incumbents have never fully solved:

  1. Dead zones. Highways through the Mojave, national parks, farmland, the stretch of interstate where your podcast always cuts out. The carriers’ coverage maps are generous, and the reality is patchier. Towers rarely pay for themselves out there; SpaceX’s satellites can cover those gaps without them.
  2. Seamless ground-to-space handoff. Today, satellite texting from T-Mobile’s T-Satellite or Apple’s Globalstar-based service (Amazon is buying Globalstar) is a separate, slower mode you drop into. SpaceX wants a single network where your phone moves from tower to satellite and back without you noticing.
  3. Price disruption. Starlink already rattled the broadband market. A carrier with no legacy network and no union-negotiated copper plant to maintain could undercut the incumbents on price, or charge a premium for “never lose signal.”

The incumbents, for their part, sound unbothered. “The physics just don’t allow direct-to-cell to be a substitute product,” said T-Mobile’s (outgoing) CFO Peter Osvaldik in September. Verizon CEO Dan Schulman said Starlink “just can’t compete without a terrestrial network in urban and suburban.” Hence the towers.

3. A Primer on Cellular, 5G, and Phones That Talk to Space

Cellular in one paragraph

A cellular network divides the world into cells, areas each served by a base station. Your phone talks to the nearest one over licensed radio spectrum. The base station passes your data back over backhaul (fiber, or a microwave radio link) to the operator’s core network, which handles authentication, billing, mobility, and the connection to the internet. When you move, the network hands you off to the next cell. Every generation since the 1980s (1G analog voice, 2G digital voice and SMS, 3G mobile data, 4G LTE mobile broadband, 5G) has been a better trick for packing more bits into the same air.

What actually makes 5G faster

5G New Radio (NR) isn’t magic. It uses three broad levers:

1. More spectrum, in three flavors. Radio physics forces a trade-off: lower frequencies travel farther and go through walls, while higher frequencies carry more data but give up at the first pane of low-E glass.

  • Low-band (<1 GHz): the coverage layer. Goes for miles and works deep indoors. Spectrum is scarce, so channels are narrow. SpaceX’s 800 MHz lives here.
  • Mid-band (roughly 1–7 GHz): the “Goldilocks” layer, a usable mix of reach and capacity. This is where 5G mostly lives. SpaceX’s 2 GHz AWS-4 lives here.
  • High-band / mmWave (24 GHz+): blazing fast, with a range of about a city block, and blocked by leaves, rain, and your own hand. Mostly found in stadiums and press releases.

2. Denser modulation. Every radio symbol encodes bits through combinations of amplitude and phase. Since 3GPP Release 17, 5G’s downlink supports up to 1024-QAM, meaning 10 bits per symbol, but only when the signal is clean enough. It’s like a crowded restaurant: the quieter the room, the faster you can talk.

3. Massive MIMO and beamforming. This is the big one. An old 4G antenna is a floodlight: it sprays energy across a whole 120° sector. A 5G massive MIMO panel such as Qualcomm’s 64T64R has dozens of small antenna elements. By adjusting the phase of each element’s signal, the base station makes the waves add up in some directions and cancel in others. That produces focused beams aimed at individual phones.

Once you can aim beams, you can reuse the same frequencies for several users at the same time, as long as they’re in different places. This is spatial multiplexing. Vendor and industry estimates suggest a 64T64R sector can carry roughly 3x the capacity of a 4T4R sector on the same 100 MHz, and give users at the cell edge a signal boost of around 9 dB.

There’s a catch that matters a lot for SpaceX. Most massive MIMO deployments use TDD spectrum, where uplink and downlink take turns on the same channel, which makes it easy for the base station to learn the radio channel. SpaceX’s spectrum is all FDD: paired blocks with separate uplink and downlink channels, plus an uplink-only slice, and no TDD at all. Massive MIMO is harder to do well on FDD, and the FDD deployments out there today are mostly 32T32R. “If they’re spectrum constrained, which they are, then this FDD massive MIMO is the way to get the capacity but especially the coverage benefits,” says Omdia analyst Gabriel Brown. Qualcomm’s pitch is that it can make 64T64R work well on SpaceX’s 2 GHz FDD bands. A lot depends on that being true.

Plus the 5G stuff you’ve heard about. A standalone 5G core makes network slicing possible (virtual private networks with guaranteed performance), lower latency, and better handling of huge numbers of IoT devices. These matter for enterprises and are mostly invisible to people scrolling TikTok.

Now contrast that with a cell tower in orbit

SpaceX’s existing Direct-to-Cell satellites (about 650 launched since January 2024) work on a seemingly impossible premise: talk to an unmodified smartphone from hundreds of kilometers up.

Here is what they’re up against:

The satellites make up for it with brute force: huge phased-array antennas (several square meters) and very sensitive receivers, so they can pick up a phone’s faint signal from orbit. Each satellite is essentially an eNodeB (an LTE base station) in space, backhauled through laser links to the rest of Starlink. That’s the clever part. The phone thinks it’s talking to an unusually distant tower in a roaming partner’s network.

SpaceX’s next-generation satellites, dubbed Starlink Mobile V2 and borrowing technology from its V3 broadband satellites, start launching on Starship around mid-2027. In October 2026 the FCC authorized a constellation of up to 15,000 of them. CFO Johnsen promises a “full 5G quality service,” and SpaceX’s target is up to 150 Mbps per user at peak. New 3GPP Release 19 phone modems with built-in satellite support, like Qualcomm’s X105, should help. Even so, physics has a vote. A satellite beam covering a whole county is one shared cell. It will never match the capacity of a dense mesh of towers in a city.

That’s the whole logic of the terrestrial plan: towers for capacity, satellites for coverage, one network for both.

4. Who Builds 5G Networks (and Why Qualcomm Is an Odd Choice)

The traditional cartel… er, “ecosystem”

Global RAN equipment is one of the most concentrated markets in tech. According to Dell’Oro and Omdia, the top five vendors (Huawei, Ericsson, Nokia, ZTE and Samsung) took about 95–96% of RAN revenue in 2025, and Dell’Oro says market concentration hit a ten-year high.

  • Huawei: the global #1. Together with Ericsson, it holds nearly two-thirds of the market. Huawei is also banned from U.S. networks for national security reasons, and rural carriers are still working through a federally funded “rip and replace” program to remove its gear (fully funded since 2025, about half done).
  • Ericsson: the U.S. heavyweight, with more than 60% of North American RAN. In December 2023 it won AT&T’s Open RAN contract, worth up to $14 billion. Ericsson is the vendor you hire when you want nobody to get fired.
  • Nokia: #3 globally, T-Mobile’s other main RAN supplier, which lost AT&T to Ericsson. It got a lifeline from NVIDIA in October 2025: a $1 billion investment to develop GPU-based “AI-RAN.”
  • ZTE: the other Chinese giant, also effectively shut out of the U.S.
  • Samsung: the top challenger in the U.S., with a $6.6 billion Verizon contract and virtualized RAN software that runs on standard servers. It also supplied part of Dish’s network.

The traditional model was vertically integrated: the radio on the tower and the baseband box at the bottom came from the same vendor and spoke a proprietary dialect over the cable between them. Once you’d picked Ericsson, you were an Ericsson shop for a decade.

Open RAN cracks the box open

Open RAN (driven by the O-RAN Alliance) standardizes the interfaces inside the base station so operators can mix vendors. It splits the base station into three parts:

  • O-RU (Radio Unit): on the tower. Antennas, amplifiers, the lowest-level signal processing.
  • O-DU (Distributed Unit): an ordinary server near the tower doing real-time baseband work: scheduling, error correction, beamforming math.
  • O-CU (Centralized Unit): software in a data center or cloud handling the less time-critical protocol layers.

The key standard is the 7.2x fronthaul split, which defines exactly which signal-processing steps happen in the radio and which happen in the server, connected by plain Ethernet (eCPRI). That standard is the only reason a chip company like Qualcomm can sell what is effectively a full base station design to a carrier like SpaceX without Ericsson in the room.

The challengers

  • Qualcomm sells merchant silicon: chips and reference designs that radio makers (or ambitious customers) build into products. It is betting on inline acceleration, which runs the entire Layer 1 signal-processing pipeline on a dedicated DSP card (the X100) instead of bouncing data between a general-purpose CPU and an accelerator, the “lookaside” approach Intel long championed (it has since built the accelerator into its Xeon chips). Qualcomm’s pitch is cheaper servers, lower power and fewer bottlenecks. The X100 card draws at most 35 W, according to Qualcomm’s product brief, and at network scale every watt saved adds up.
  • NVIDIA is pushing AI-RAN on GPUs through its Aerial platform: a cell site that runs the radio and AI inference on the same hardware. Qualcomm’s Malladi isn’t convinced: “AI-based RAN is a lot more than just throw a GPU at it, and you’re done.”
  • Marvell and Intel supply competing baseband silicon, inline and lookaside respectively.
  • Startups and software players: Mavenir (chiefly a cloud-native core and RAN software vendor, which quit making macro radios in 2025), Parallel Wireless, Rakuten Symphony (the arm that sells the software behind Rakuten’s own Open RAN network in Japan), 1FINITY (Fujitsu’s network business, spun out in 2025), and DeepSig (AI-native signal processing), among others.

Open RAN’s track record is mixed. Rakuten in Japan and Dish in the U.S. (until EchoStar wound its network down) proved it works, though neither proved it wins. Integrating parts from multiple vendors turned out to be expensive and messy, which is why the radios and baseband in AT&T’s “Open RAN” come almost entirely from Ericsson. The first third-party radio, from 1FINITY, only made its first call in 2025. SpaceX is taking a third path: one silicon vendor, its own software, and an engineering culture that would rather build than integrate.

5. The Hard Part: Building a National Network From Scratch

Rockets are hard. Getting a conditional use permit from a county planning board in suburban New Jersey may be harder. Here’s what’s in the way.

Cost: $100 billion, give or take a moon mission

Estimates are all over the map. BNP Paribas analyst Sam McHugh reckons SpaceX would need to spend at least $100 billion on a terrestrial network before it earns real revenue, not counting spectrum. TD Cowen says more than $80 billion, and Bernstein $50–130 billion including spectrum. LightShed thinks the initial build could be as little as $10–15 billion. Verizon’s Schulman, who is not a neutral party, says $300–500 billion. Some back-of-envelope numbers show why:

  • Tower rent. SpaceX doesn’t own towers. It will lease space from American Tower, Crown Castle, SBA and others; the U.S. has roughly 450,000 cell sites of all kinds. Lease brokers put the ground rent that tower companies pay landowners at around $1,300–1,500/month, with urban rooftops at $4,000+. A carrier renting space on a tower typically pays more than that, and leases usually rise about 3% a year. Even at a lowball $1,500/month, 50,000 sites comes to $900 million a year before buying a single radio.
  • Equipment and installation. Radios, antennas, servers, power systems, structural analysis, crane time and tower crews. This can run well into six figures for a new site, less for adding gear to an existing one.
  • Power and backhaul. Electricity at every site, plus a fiber or microwave link to carry its traffic back to the core.
  • Customer acquisition. Stores, marketing, handset subsidies and customer care. The incumbents spend billions a year on this alone, and most of it is money spent getting people to switch.

SpaceX has unusual advantages here: a Starlink broadband business that throws off cash, the ability to raise money at an enormous valuation, and a satellite layer that can cover rural areas, so it doesn’t have to build towers everywhere the incumbents did.

But deep pockets have a lot of pockets. Since swallowing Elon Musk’s xAI in February 2026, SpaceX has been pouring money into AI data centers: capital spending hit a reported $28.5 billion in the first half of 2026, more than triple a year earlier, with most of it going to AI infrastructure such as xAI’s Colossus supercomputers in Memphis. Investors knocked the stock down about 13% when that number came out. Every dollar spent on GPUs is a dollar not spent on tower leases. If AI and 5G end up competing for the same budget, it’s not obvious the cell towers win.

Spectrum: 80 MHz vs. 400 MHz

Here’s the number from earlier. SpaceX’s terrestrial holdings total roughly 80 MHz, and some of that is uplink-only. T-Mobile has nearly 400 MHz. Verizon and AT&T each have hundreds of MHz too, including wide TDD mid-band channels (C-band, 2.5 GHz, 3.45 GHz) that are ideal for massive MIMO.

Spectrum is capacity. With a fifth of the airwaves, SpaceX has to squeeze far more out of every MHz, which is why 64T64R FDD massive MIMO and Qualcomm’s AI-driven beam prediction are central to the plan and not just marketing. Expect SpaceX to show up at every future FCC auction, starting with the upper C-band auction (160 MHz at 3.98–4.14 GHz), due by July 2027. (An AWS-3 re-auction already wrapped up in June 2026, raising about $3.5 billion.)

There’s also a band-sharing puzzle: the same 2 GHz spectrum is supposed to serve both towers and satellites. Keeping the two from interfering, especially near the edges of tower coverage where a phone could hear both, takes careful coordination, and it’s a novel problem.

Time: towers don’t launch on Starship

Dish took about three years from the Sprint merger to cover roughly 70% of the U.S. population, and it struggled with indoor coverage and actual customer uptake the whole way. The physical rollout is limited by:

  • Zoning and permitting: thousands of local jurisdictions, each with its own process.
  • Tower crews: the pool of certified climbers is finite, and the incumbents are already booking them.
  • Structural analysis: a 64T64R massive MIMO radio is heavy and catches a lot of wind. Many tower spots will need reinforcement.
  • Backhaul: every site needs a fiber or microwave link, and a massive MIMO site moving gigabits needs fiber. Leasing or trenching it, site by site, is slow.

Phones: the quiet dependency

Your phone has to support SpaceX’s frequencies. The good news is that much of SpaceX’s 2 GHz spectrum lines up with 5G band n70 (which Dish got into recent phones, iPhones included) and band n66, and the 800 MHz block sits inside band 26, which nearly every U.S. phone supports. One snag: Apple’s phones don’t list the 4G LTE version of band 70. The less good news: carrier certification, eSIM provisioning, Wi-Fi calling, VoNR voice, emergency-911 location accuracy and roaming agreements are all tedious, unglamorous work, and any one of them can sink a launch. It helps that Qualcomm makes most of the modems in question.

Competition: the incumbents won’t sit still

AT&T, Verizon and T-Mobile are not ignoring the sky. AT&T and Verizon have backed AST SpaceMobile, a direct-to-phone satellite rival. T-Mobile is currently Starlink’s own D2C partner, which makes the relationship awkward. In May 2026 the three carriers also agreed to pool spectrum in a joint satellite venture aimed at rural dead zones. SpaceX’s CFO reportedly mused that they “wanted to create a cartel, maybe.” And they all have one powerful tool: price cuts, funded by networks they paid off years ago.

Execution: SpaceX hasn’t fully committed

As recently as September 2026, SpaceX’s CFO was publicly hedging on whether it would build a terrestrial network at all, keeping options open for an MVNO arrangement or rooftop “femtocells” next to Starlink dishes. The Qualcomm deal suggests the company has made up its mind. Still, signing a supply contract is the easy part.

6. Milestones to Watch, 2026–2036

Near term (2026–2027): Paper and steel

  • FCC filings and master lease agreements. How many sites, which markets first, and with which tower companies. Watch for an American Tower or Crown Castle master lease announcement. It would be the first hard evidence of real scale.
  • Boost Mobile acquisition. If it closes, SpaceX gets millions of customers and a roaming bridge on day one.
  • Starlink Mobile V2 satellites on Starship (from mid-2027). These next-generation satellites carry the “full 5G” satellite layer. Each Starship launch matters.
  • EchoStar closing (around late 2027) and FCC approval of the Grain 800 MHz deal.
  • First cell sites go up (2027). Watch where the first clusters appear, and for any trial service. When drive-test data shows up on Ookla or Opensignal, the network is real.

Medium term (2028–2030): Show me the subscribers

  • Commercial launch. The satellite 5G service is targeted for early 2028; watch for the terrestrial launch date. Pricing will tell you the strategy: aggressive undercutting or a premium “never offline” tier.
  • Handset certification, especially iPhone. If Apple certifies a carrier, that carrier is real.
  • Population coverage claims vs. reality. Can SpaceX reach 50%+ of the population with good indoor service? This is where Dish struggled.
  • Subscriber numbers and churn. In wireless, adding customers gets the headlines, but keeping them is what makes the money.
  • More spectrum. The upper C-band auction (2027), or more secondary-market deals.

Long term (2030–2036): The 6G turn

  • 6G standards (3GPP Release 21, ~2028–2029) and first 6G deployments (~2030). Satellite links are being designed into 6G from the start, which plays to SpaceX’s strengths. Qualcomm is already floating a “giga-MIMO” concept with 128 or 256 transmitters and receivers per radio, and Malladi says the deal will “lay the foundation for AI-native 6G.”
  • Real integration. The end goal is a single core network, one phone number, and handoffs between tower and satellite that nobody notices. If SpaceX gets there first, the dead zone stops being a fact of life and becomes a product choice.
  • The market structure question. By the mid-2030s, either the U.S. has a durable fourth carrier with its own satellites, or there’s one more company dividing up a former challenger’s spectrum. There’s not much middle ground.

The Bottom Line

SpaceX is doing something no operator has tried: building a cellular network from the sky down, with satellites for coverage, towers for capacity, and Qualcomm silicon to make the towers cheap and power-efficient enough to deploy by the tens of thousands.

The technology is plausible. The spectrum is thin but usable. The money exists, at least for SpaceX. What remains is the unglamorous work that has humbled every challenger before it: leases, permits, crews, phone certification, customer care and price wars.

SpaceX has a habit of turning “impossible” into “late, but done.” Phone networks are a slower industry, measured in zoning variances instead of launch windows. Either way, the next few years will be interesting, and probably good news for anyone’s phone bill.

Even if SpaceX stumbles, the industry is better off for the attempt. In 2023 I wrote an obituary, “R.I.P. ‘Innovation in Mobile’ (2015–2023)”, blaming three killers: mergers that wiped out independent carriers, the big three swallowing the MVNOs, and spectrum priced beyond any challenger’s reach. SpaceX is taking on all three. It has committed roughly $28 billion to spectrum, and, shut out as an MVNO, it is building its own network as an independent carrier. Even if it never wins, it forces everyone else to move. Maybe the obituary was premature.

In my 2020 parody, fake-Elon bragged about never paying for cell sites or backhaul. Real SpaceX is about to pay for both, which is the most grown-up thing a rocket company has ever done. Master plan amendment, Step 3b: rent the towers. If it works, your next dead zone might just be a fond memory.

The chroma-green satellites are still pending. Don’t tell anyone.

References

Image Credits

SpaceX Wants to Be Your Phone Company. It Just Hired Qualcomm to Build the Radios. was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Guido van Rossum: Why Python’s Creator Quit as Dictator for Life]]> https://medium.com/the-low-end-disruptor/guido-van-rossum-why-pythons-creator-quit-as-dictator-for-life-32590a738682?source=rss----16704e6008f5---4 https://medium.com/p/32590a738682 Tue, 03 Nov 2026 23:45:41 GMT 2026-11-03T23:45:41.423Z He wrote Python over a 1989 Christmas break. By 2018 it ran AI and the web, and a fight over the walrus operator (PEP 572) drove him to resign as BDFL.

I. The Cold Room

Guido van Rossum was tired.

It wasn’t the kind of tired a nap fixes. It was the kind that settles into the joints of a sixty-two-year-old man and stays there. Early on the morning of Thursday, July 12, 2018, at his home in Belmont, California, he began to type to the python-committers mailing list, the small closed room where the inner circle of his kingdom did its business.

Tak. Tak. Tak-tak.

He was the Benevolent Dictator For Life. The Benevolent Dictator For Life! The title began as a joke, scribbled into the notes of a 1995 meeting in Virginia. Over twenty-three years it hardened into something that was no joke at all. He had the final word on every comma, every keyword, every bit of syntax in a language that had quietly become one of the load-bearing walls of civilization. Python ran Instagram, the recommendation engines at Netflix, the playlists at Spotify. It was the mother tongue of artificial intelligence, of astronomers and geneticists and hedge-fund quants and twelve-year-olds making their first turtle draw a square. And every one of them, in some abstract and terrible sense, answered to him.

No scandal brought him down, no lawsuit, no hostile takeover. Two characters did, a colon and an equals sign:

:=

They called it the walrus. Tilt your head and you see the eyes and the tusks. For months it had been the cause of a civil war: hundreds upon hundreds of emails, a blizzard of Reddit comments, strangers questioning his judgment, his competence, his fitness to rule. The night before, he had formally accepted the proposal, PEP 572. He had won, and winning had cost him so much that he no longer wanted the prize.

He typed:

Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

Despise. He didn’t write disagree with, or question. He wrote despise. That was the word for it.

I would like to remove myself entirely from the decision process.

He was Dutch, and he had never been a man for speeches, least of all dramatic ones. So the message that ended one of the longest reigns in open-source software came out almost offhand. He mentioned “that bus lurking around the corner,” the programmer’s grim joke about a creator stepping off the wrong curb. He noted that he wasn’t getting younger. Then, with that dry deflection of his: (I’ll spare you the list of medical issues.)

I am not going to appoint a successor.
So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

And then the last line, the one people would quote for years:

I’m tired, and need a very long break.

He hit send. The King didn’t abdicate in a scene of crashing thunder. He got up from the throne, left the crown on its cushion, and walked out of the room.

How does a holiday hobby, a toy to keep idle hands busy, become a weight that crushes the one who made it? To find out you have to go back to the real cold. Amsterdam, December, 1989.

II. Christmas in Amsterdam

Winter on Amsterdam’s eastern canals. The kind of dark, still season that produced Python.

Picture the city in the last week of the 1980s. The canals have gone black and still, the gables lean over the water like tired old men, and darkness comes down by four in the afternoon. The Berlin Wall fell six weeks ago. History is happening everywhere, and on the eastern side of the city a thirty-three-year-old programmer is bored.

He works at the Centrum Wiskunde & Informatica, the CWI, the Dutch national research center for mathematics and computer science. Over the holidays the offices are closed. The young man with the high forehead and the spectacles has a computer at home and, as he’ll later put it, not much else on his hands. He also has a grudge that’s really more of a grief.

The Centrum Wiskunde & Informatica in Amsterdam, where ABC was built and Python began.

The grief is called ABC.

From 1982 to 1986 he had worked on the ABC programming language under Lambert Meertens and Steven Pemberton. ABC was beautiful, an academic’s dream of programming for scientists, teachers and beginners, and its most radical idea was significant indentation: the visual shape of the code was its logical shape. No thicket of curly braces and semicolons. You indented, and the indentation meant something.

ABC was also a failure. It was too pure to survive, a sealed world that couldn’t talk to the operating system, and the hackers who most needed a clean, high-level tool walked right past it.

By 1989 he had moved on to Amoeba, a distributed operating system project at the CWI, whose team badly needed a scripting language. So, in the dark of that Christmas, he started writing one that would keep ABC’s soul but open the windows to Unix and C.

He needed a name. He’d been reading the published scripts of Monty Python’s Flying Circus, and he wanted something short, unique, a little irreverent. Python. That was the whole decision, a joke for people who knew the joke.

Stop here a moment, on the young man in the dark, because this is the last moment of perfect innocence in the story. No community, no mailing list, no corporation, no AI, no walrus. One man, a keyboard, a holiday, and the private pleasure of building a thing exactly the way he thinks it ought to be built. He’ll spend the next three decades trying to get back to this room.

III. The Wager

The early Python wordmark, designed by Just van Rossum, Guido’s brother.

In February 1991, Python 0.9.0 was posted to alt.sources, one of the dusty Usenet bulletin boards of the early internet. No launch event, no press release. A file appeared, and a few strangers downloaded it.

Hidden inside that file was a wager, the most important bet in the whole story. He’d put it into words years later, in Python’s style guide:

Code is read much more often than it is written.

In 1991 the macho culture of programming prized density. Perl hackers wrote one-liners that looked like a cat had walked across the keyboard, and they were proud of it. Cryptic was cool. Unreadable meant you were smart.

Van Rossum bet the other way. If a language made the clear path the easy path, the whole ecosystem would drift toward clarity like water running downhill. And he wrote it into the grammar. In Python, indentation wasn’t a suggestion. It was law. Indent wrong and the program wouldn’t run. The machine itself would make you write code a human could read.

Years later the core developer Tim Peters boiled the ethos down into nineteen lines of something close to poetry, The Zen of Python, which you can still summon from any interpreter by typing import this. Beautiful is better than ugly. Readability counts. And the line that would come back, nearly three decades later, as a weapon:

There should be one, and preferably only one, obvious way to do it.

Van Rossum didn’t write those words. He didn’t have to; they described what he’d already built. Python was idiosyncratic, approachable, a little goofy, and because anyone could pick it up and understand it, it spread from hand to hand and machine to machine like a friendly virus.

IV. The Dictator Who Wouldn’t Shout

The polder at Kinderdijk. Dry land is held there by agreement, and that’s the Dutch art of consensus.

A crowd gathered around Python, a few dozen people, then hundreds, then thousands, sending bug fixes and feature requests and patches. Somebody had to decide which ones went in. In April 1995, at a meeting of early Python users at CNRI in Virginia, Ken Manheimer’s notes named van Rossum “benevolent dictator”; Barry Warsaw is credited with adding “for life.” Benevolent Dictator For Life. BDFL.

The joke part was the Benevolent and the For Life. The Dictator part was real. He had the final say on the design of the language. Full stop.

Other open-source founders came to be called BDFLs, but the most famous of them was Linus Torvalds, and the contrast between the two men tells you almost everything.

Torvalds, the creator of Linux, ruled his kernel like a warlord. He swore. He shamed. He sent emails that read like declarations of war, tearing into developers who’d submitted bad code, and he defended his right to do it. Friction forged steel. He liked the fight. (Two months after van Rossum quit, Torvalds would publicly apologize for his behavior and take a break of his own.)

Linus Torvalds, the other dictator for life, who thrived on the fight.

Van Rossum was nothing like that. He came from a country that had pulled itself out of the sea through cooperation. The Dutch call it polderen, after the polders, reclaimed lands kept dry only because farmers and towns and rival interests agreed, painstakingly, on who would maintain which dike. Government by consensus and patient compromise, because if anyone stops pumping, everyone drowns. That was his temperament. He didn’t want to yell. He wanted to read the code, weigh the trade-offs, and make people feel heard.

In 1999, working by then at the Corporation for National Research Initiatives in Reston, Virginia, he wrote a funding proposal to DARPA, the Pentagon’s research arm, with a title that said everything: Computer Programming for Everybody. Programming as a basic literacy, for high schoolers and hobbyists and ordinary people, not a priesthood. Python would be the vehicle.

It was a generous, democratic vision, and it had a hidden price. If you build a language for everybody, everybody comes. And everybody has opinions.

As Python grew, the process for changing it was formalized as the Python Enhancement Proposal, the PEP. Anyone could write one. Each was argued over in public on the mailing lists. It was open and, on paper, democratic.

In practice it was a funnel. All the anxiety, ambition and ego of tens of thousands of brilliant, stubborn engineers poured down it, and at the narrow end sat one man. He read the threads, hundreds of messages on a single question. He weighed technical merit against aesthetic purity, the beginner against the expert. He was the pressure valve for the whole community, and he wasn’t built like Torvalds. He felt it.

V. Mondrian

At Google I/O, 2008. Google paid him to spend half his time on his own language.

In December 2005, Google hired him.

This was Google at its most intoxicating, all lava lamps and free lunches, and it ran on his language. Its engineers’ motto, made public by the Googler Alex Martelli in 2007, was Python where we can, C++ where we must. Google gave van Rossum half his working time to spend on Python itself. He was no longer a researcher with a hobby. He was a celebrity with a corporate badge, the subject of what one PyCon photographer would caption, without irony, the “obligatory Guido shot.”

With the other half he built Mondrian, an internal code review tool named, being who he was, after a Dutch painter. It moved Google’s review ritual onto the web, line by line, and taught a generation of engineers his deepest belief: human eyes reading code are the last defense against chaos.

Piet Mondrian, Composition II in Red, Blue, and Yellow (1930), namesake of Google’s code review tool.

The irony would take years to ripen. He was building a culture of intense, line-by-line, public scrutiny, and that same culture, scaled up past the point where anyone knew each other, would one day be turned on him. On a small team, review is intimate: people who know and trust each other, catching each other’s mistakes. Scale it to thousands of strangers on the internet and the intimacy goes sour. It becomes a tribunal.

VI. The Schism

OSCON, 2006. This was the era of “Python 3000”, before the long schism began.

The first real crack ran right down the middle of the kingdom.

By the mid-2000s, van Rossum could see that some of Python’s early decisions, made in a hurry by a young man in a cold winter, were holding the language back. The worst was text. Python 2 muddled human-readable text and raw binary bytes. In 1991 that hadn’t mattered. In a global internet of Chinese and Arabic and Hindi and emoji, it was a disaster.

The fix wasn’t a patch. It was surgery, and it meant deliberately breaking backward compatibility. Python 3.0 arrived in December 2008, following the blueprint of PEP 3000. It was bold and it was right, and it meant that millions upon millions of lines of Python 2 code wouldn’t run on it without being rewritten.

The migration was supposed to be brisk. It took a decade.

It was a grinding war of attrition. Big companies with mountains of technical debt refused to move. Red Hat Enterprise Linux and CentOS 7 clung to Python 2.7 for years. The volunteers who maintained the open-source libraries burned out making their code run on both versions at once. The community split into camps, the Twos and the Threes.

Van Rossum spent those years defending the decision to angry people, playing diplomat between factions of his own. Python 2’s death date, first set for 2015, slipped five years to January 1, 2020, with a last-gasp release, 2.7.18, that April.

In the end the transition worked. But victory isn’t the same as peace. The schism used up enormous amounts of the Dictator’s political capital and stamina. He came out of it weary.

What he didn’t know was that the real explosion hadn’t even started.

VII. The Serpent Eats the World

The serpent’s habitat: the server farms where Python became the mother tongue of machine learning.

Then, in the 2010s, the ground shifted under the whole of computing. Artificial intelligence and machine learning, which had lived in academic papers for decades, became almost overnight a corporate necessity. The people building them were mathematicians and physicists who thought in matrices and had no patience for Java’s ceremony. They wanted a clean, readable wrapper around brutally complicated math.

They chose Python, for exactly the reasons van Rossum had bet on in 1991. NumPy and pandas turned it into a numerical powerhouse, and then it had a gravity of its own: researchers used it, so the tools were built for it, so more researchers came. When Google’s TensorFlow and Meta’s PyTorch arrived, and later the large language models of OpenAI and everyone else, they all spoke Python.

Look at the size of it! By 2018, nearly 39 percent of developers in Stack Overflow’s survey used Python, the fastest-growing major language in the world, and behind them poured biologists, astronomers, accountants and teenagers who had never thought of themselves as programmers at all.

The language had become the scaffolding of the AI revolution and a load-bearing pillar of the global economy. Every machine-learning lab, every startup chasing the next model, every billion-dollar bet on artificial intelligence, bets that by 2026 would swell into the trillions, now ran through a language whose final arbiter was one tired man reading his email. A small tweak under the hood could move a Fortune 500 company’s server bills by millions. Every decision landed on him.

He lived it from the inside, too. At Dropbox, which he joined in 2013, he spent years helping migrate more than five million lines of code from Python 2 to Python 3, in the trenches of the very war he had started. Meanwhile the mailing lists filled with a new generation who saw him not as a peer but as a gatekeeper between them and the feature they needed right now. The intimacy was gone. It only needed a spark.

VIII. Tusks

The walrus. Tilt your head at := and there are the eyes and the tusks.

The spark was a walrus.

In February 2018 a developer named Chris Angelico, joined by Tim Peters and van Rossum himself, drafted PEP 572: Assignment Expressions.

On paper it was about as dull as language design gets. Python had always kept a strict wall between statements, which do something, like store a value in a variable, and expressions, which evaluate to something. PEP 572 proposed a small door in that wall: a new operator, :=, that would let you assign a value and use it at the same moment, inside an expression. It would save computing expensive things twice and untangle clumsy loops.

Take the old, familiar ritual of reading a file in chunks:

while True:
    chunk = file.read(8192)
    if not chunk:
        break
    process(chunk)

With the walrus, it collapses into this:

while chunk := file.read(8192):
    process(chunk)

To the purists none of that mattered, because to them PEP 572 was heresy.

They had the scripture to prove it. There should be one, and preferably only one, obvious way to do it. Python already had a way to assign a variable. Now there would be two. To the faithful this was the road to Perl, to show-off one-liners that would baffle beginners. Readability counts! Readability counts! And here was the Dictator himself, they said, selling it out.

What should have been a dry argument about parsing rules turned, almost immediately, into something feral.

The volume of email was staggering. Thread after thread on python-dev and python-ideas, hundreds of messages, every one a little hotter than the last. People dug in. They accused the authors of smuggling C-style syntax into a language that had been designed specifically to reject it. And the poison of modern internet discourse seeped into the technical debate, the way it seeps into everything. People were no longer just disagreeing with the proposal. They were attacking the people: questioning their competence, their motives, their intelligence. And by extension, unavoidably, they were attacking the man at the narrow end of the funnel.

He looked at the evidence, the way he always did. In huge real-world codebases, including Dropbox’s, programmers were already doing awkward and risky things to save a line. Used with care, the walrus would make real code cleaner. He believed in it.

On July 9 he announced his intention to accept. On the evening of Wednesday, July 11, 2018, he formally accepted PEP 572 for Python 3.8.

By then the backlash had been building for months, and his decision only fed it. He had ruined the language. People announced they’d ban the walrus from their projects. People talked about forking Python.

This was a man who had spent nearly three decades building a community on collaboration and mutual respect, who came from a culture of the polder and the patient meeting, who had believed that if you made things readable people would understand each other. He was hit with a wave of contempt so large that he couldn’t do anything with it. He couldn’t answer it or reason with it. It was too much to read and too much to absorb.

Being the final arbiter, the one person who has to soak up the collective fury of thousands of engineers over a colon and an equals sign, had finally changed something between him and the thing he loved. The language that had been his joy had become the source of his misery.

He had won the walrus war and lost the thing he’d been fighting for.

The next morning, roughly fifteen hours after he accepted the proposal, he opened the python-committers list, and you know the rest.

IX. Transfer of Power

Van Rossum on stage at PyCon, 2013.

The subject line was almost comically bureaucratic: Transfer of power.

The shock spread across the technology world within hours. Guido steps down. Python’s BDFL quits. Reddit threads filled with hundreds of comments. Podcasts rushed out emergency episodes. Developers on the far side of the planet woke to news that felt, absurdly, like the death of a pope, or a parent leaving home.

Look at what he didn’t do. He didn’t name an heir or hand the crown to a trusted lieutenant. He didn’t present a constitution. He did something stranger and, in its way, braver. He threw the question back at them.

Create a democracy? Anarchy? A dictatorship? A federation?

I’ll still be here, but I’m trying to let you all figure something out for yourselves.

He would stay on as an ordinary core developer, he wrote. He’d be around to mentor. But the burden of being the last word on everything was over.

The King wasn’t overthrown. Nobody stormed the palace. He just stood up, set the crown down on the cushion, and walked out of the room, and behind him the court stood frozen, staring at the empty throne.

X. The Republic

Van Rossum with the photographer, Mahmoud Hashemi, and Kurt Rose at PyCon 2012. The community that would one day govern itself.

What came next was something close to existential dread.

How does a dictatorship invent democracy? How do you decide how to make decisions when your only mechanism for deciding has just walked out the door? The core developers were brilliant engineers, not political philosophers, and they found themselves in a constitutional convention they’d never asked for.

They had good reason to be afraid. Open-source governance is a fragile thing, held together by volunteer labor and goodwill. When a founder leaves, the vacuum is usually filled in one of two ugly ways: a corporation moves in and captures the project, or it shatters into warring forks. The history of free software is littered with the remains of projects that didn’t survive their creator’s departure.

The models on offer each had a flaw. There was the benevolent dictator, the old Python and the current Linux, where everything hung on one person’s health, sanity, and patience, which was exactly the problem they were trying to solve. There was the corporate team, the model of Google’s Go, where a company’s priorities could always quietly override the community’s. There was the meritocratic voting of the Apache projects, which tended to be too heavy, too bureaucratic, too slow for a living language. And there was the elected council, the model of projects like Django, which needed elections, voter lists and rules, and carried the constant risk of gridlock.

Here’s the elegant twist. By refusing to name a successor, van Rossum had forced his community to find, in the words of their own scripture, one obvious way, and so they would own it. Seven competing governance proposals were written. In December 2018 the core developers voted, and the winner, by Nathaniel J. Smith and Donald Stufft, became PEP 13, arguably the most important document in Python’s history that contains no code at all.

PEP 13 created a five-person Steering Council, elected by the core team after each major release. The authors had studied the failure modes and built in defenses against them. To keep any one company from capturing the language, no more than two council members could work for the same employer; if a third was elected, they were disqualified. Elections used a carefully designed multi-winner voting system meant to produce broad consensus rather than factional victory. And there was a fail-safe, the vote of no confidence: if the council lost the community’s trust, the core team could remove a single member or dissolve the whole council and force a new election.

Most telling, the council’s mandate was written in van Rossum’s image: to seek consensus, to act as a court of final appeal, not a throne, and to use its formal power as little as possible. The Republic would be governed the way the King had always wanted to govern. This time, though, five people would share the weight.

When the first council was elected in early 2019, one of the five names on it was Guido van Rossum. The core developers wanted him there, as a citizen and not a king, and he served one term. Then he stepped back again and left his seat to others.

The real test came with PEP 634: Structural Pattern Matching, a whole new match/case construct for Python 3.10 that took apart complex data structures in a single stroke. It was a far bigger change than the walrus, with far more ways to go wrong.

Again opinion split. Again the threads ran hot. Again people said the language was being ruined.

This time the weight didn’t fall on one man. The Steering Council took the pressure and in early 2021 approved the proposal, acknowledging the reservations openly. Nobody burned out. Nobody walked away. The language had survived its creator’s leaving, and it was stronger for it.

XI. Retirement Is Boring

The Microsoft campus in Redmond, where the retired King came back to work as an engineer.

In October 2019, van Rossum left Dropbox and retired. He was sixty-three. He had seen the Python 3 migration through and laid down the crown. He had earned a quiet life.

It lasted about a year.

Retirement, it turned out, was boring. Then came the pandemic and the empty days of 2020, with nothing to push against. He missed the code. He missed having a team. He missed the satisfaction of a hard technical problem.

In November 2020 he stunned the tech world by coming out of retirement to join Microsoft, in its Developer Division, as a Distinguished Engineer.

Microsoft! The irony was hard to miss. For decades Microsoft had been the great dark empire of the open-source imagination, the company whose leadership had once called Linux a “cancer.” Now the creator of one of the most important open-source languages ever was drawing a salary in Redmond. But the Microsoft of Satya Nadella wasn’t the Microsoft of the 1990s. It had become, improbably, an open-source powerhouse. And it offered van Rossum something he hadn’t really had since that Christmas in 1989: the freedom to just be a programmer.

He put together a small team with the core developer Mark Shannon and went after the oldest complaint about Python: it’s slow. No mailing-list wars, no final say, just a hard problem. Their Faster CPython project taught the interpreter to rewrite its own hot code paths as it ran, and Python 3.11, released in 2022, ran about 25 percent faster on average. For a man who had once absorbed a whole community’s fury, it was the work he had always wanted: a benchmark, not a referendum.

Corporate patronage cuts both ways, though. In May 2025, in company-wide layoffs, Microsoft ended its support for Faster CPython and let go of Mark Shannon along with fellow core developers Eric Snow and Irit Katriel. The work went on in the open-source community. A year later, in May 2026, van Rossum retired from Microsoft. This time, the language didn’t need him to stay.

XII. The Lock

There was one dragon left, the oldest and biggest: the Global Interpreter Lock, the GIL.

Since its earliest days, CPython had used a single lock that let only one thread run Python code at a time. It kept things simple, and it meant Python couldn’t really use the multi-core processors that had become universal. It was a fossil from the young man’s cold winter, still lodged in the heart of the machine.

In 2023, the Steering Council took up PEP 703, a proposal by the Meta engineer Sam Gross to make the GIL optional. It was open-heart surgery on the language, with the risk of breaking decades of extensions the whole ecosystem depended on, a far more dangerous change than the walrus.

Think about what that proposal would have done to the old order. If it had landed on the BDFL’s desk in 2018, alongside the walrus and on top of everything else, the pressure of managing the fallout might well have broken him outright.

In 2023 there was no single desk to land on. The council accepted PEP 703 as a body and laid out a careful, multi-year road. An experimental free-threaded build appeared in Python 3.13. In Python 3.14, in 2025, it became an officially supported option.

The GIL work belonged to others, to Gross and the council and a long list of contributors, and that was exactly the point. Van Rossum spent those years as an engineer, not a besieged monarch, tuning the interpreter and arguing over implementation details as an equal, while a decision bigger than the walrus was made without him.

He had found his way back to the room in Amsterdam.

XIII. The Liberation of Limits

In the end, this is a story about the limits of a single human being.

We love the lone genius in technology. We build myths around founders who started in a dorm room or a garage or over a bored Christmas holiday, and we assume the spark of creation comes with the armor needed to rule an empire. We expect the founder to be in command, unbothered, turning any amount of pressure into more power.

But software doesn’t have a nervous system. People do.

Python scaled without limit, copying itself across servers and laptops and research clusters until it was the foundation of the AI age. Its creator couldn’t scale. There was one of him, with one inbox, one finite supply of patience, and one body that wasn’t getting younger. He had built a language on human readability, and it had grown a community that was, in the end, emotionally unreadable.

By walking away, Guido van Rossum won a rare and quiet victory. He escaped the founder’s trap, the one that catches creators who can’t let go and end up strangling the thing they made, or being strangled by it. He forced his community to grow into a self-governing republic that could carry out pattern matching, a faster interpreter and the slow dismantling of the GIL without tearing itself apart. He made sure Python would outlive him.

The young man in the dark Amsterdam winter of 1989 wanted to build something readable that would let people talk to machines, and to each other, more clearly. He did that. Then it grew into a monster, and the monster nearly ate him. When the fury over a walrus pushed him to the edge, he walked away from his crown, and in doing so he saved his kingdom. More importantly, he saved himself.

Guido van Rossum was tired. Then, at last, he rested. And then, because he’d always been a programmer before he was a king, he went back to writing code, until in 2026, at seventy, he retired once more. This time he went on his own terms.

Author’s note: This profile is narrative nonfiction. Interior moments and scene-setting are imagined, drawn from the public record. Quotations from the “Transfer of power” email are from van Rossum’s message to the python-committers list on July 12, 2018.

References

Image Credits

Guido van Rossum: Why Python’s Creator Quit as Dictator for Life was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Starship’s Heat Shield: Can 18,000 Tiles Escape the Space Shuttle’s Fatal Flaw?]]> https://medium.com/the-low-end-disruptor/starships-heat-shield-can-18-000-tiles-escape-the-space-shuttle-s-fatal-flaw-64c4fe517372?source=rss----16704e6008f5---4 https://medium.com/p/64c4fe517372 Mon, 26 Oct 2026 23:12:15 GMT 2026-10-27T17:32:16.154Z A broken heat shield doomed Columbia. SpaceX’s Starship rebuilt it with a steel hull and pinned hexagonal tiles, but experts say rapid reuse is still unsolved.

The tragedy of Columbia (STS-107)

I was a kid who memorized orbiter names the way other kids memorized NBA rosters. Columbia was the first to fly in space: the one that flew STS-1 in 1981, the heaviest of the fleet, the one with the black chines where its wings met the fuselage. On the morning of February 1, 2003, it was coming home from a 16-day science mission with seven people on board: Rick Husband, William McCool, Michael Anderson, Kalpana Chawla, David Brown, Laurel Clark, and Ilan Ramon.

At about 8:44 a.m. EST, Columbia hit the top of the atmosphere over the Pacific. At 8:59, Mission Control lost contact. People in Texas watched the orbiter break into a spray of bright streaks across the sky at about 200,000 feet and roughly 18 times the speed of sound. Nobody survived. And I was in tears.

The cause had been sitting in plain sight for 16 days.

At 81.7 seconds after liftoff, a briefcase-sized chunk of insulating foam, about 1.67 pounds, broke off the External Tank’s left “bipod ramp,” a foam fairing over the fitting where struts attach the orbiter’s nose to the tank. Drag slowed the light foam almost instantly while the Shuttle kept accelerating, and it struck the lower part of Reinforced Carbon-Carbon (RCC) panel 8 on the left wing’s leading edge at more than 500 mph.

Engineers saw the strike in launch video the next day and asked, more than once, for military satellites or telescopes to photograph the wing. One request reached the Department of Defense, and NASA managers cancelled it. Foam had hit orbiters many times before without disaster, and the anomaly had become routine. Sociologist Diane Vaughan had coined a phrase for this after Challenger, “normalization of deviance,” and it became central to the Columbia Accident Investigation Board’s (CAIB’s) findings on NASA’s culture.

During re-entry, hot gas entered the breach. It did not have to beat the heat shield. It went around it, into a wing built of aluminum designed to stay below about 175°C (350°F). The plasma burned through the leading-edge spar and then the wiring and structure inside. Sensors went offline one after another, the wing deformed, the flight control system ran out of authority, and the vehicle came apart.

Many people did not believe soft foam could break reinforced carbon. In July 2003, the CAIB settled it at the Southwest Research Institute in San Antonio, firing a 1.67-pound block of the same foam from a nitrogen gas cannon at a flight-flown RCC panel from Atlantis. The foam blew a hole about 16 by 17 inches. People in the room reportedly gasped.

The CAIB foam impact test, July 7, 2003. A 1.67-lb block of foam fired at about 530 mph opened a roughly 16-by-17-inch hole in an RCC leading-edge panel. (NASA/CAIB)

The foam was the trigger. The real lesson was in the architecture: a thin, brittle heat shield over an airframe that could not tolerate heat at all. One breach in the wrong place was enough to lose the vehicle. Every reusable heat shield since has been designed in Columbia’s shadow.

Why thermal protection is one of the hardest problems in reusable spacecraft

Start with the energy. In low Earth orbit, a spacecraft moves at about 7.8 kilometers per second. Each kilogram of vehicle carries about 30 megajoules of kinetic energy, roughly seven times the energy in a kilogram of TNT. To land, nearly all of it has to go into the air.

The vehicle does this by plowing into the atmosphere behind a shock wave. Air crossing the shock is heated so violently that oxygen and nitrogen molecules split into atoms, forming a glowing layer thousands of degrees hot. Most of the heat flows away in the wake. The small fraction that reaches the surface is still enough to destroy almost any material, and free atoms recombining on the surface dump their chemical energy straight into the heat shield.

Where the heat goes during re-entry. Most of the energy is carried away in the shock layer and wake. The fraction that reaches the surface still pushes windward temperatures past 1,260°C, and higher at the nose and leading edges.

For a capsule that flies once, there is an elegant answer: ablation. Apollo, Orion, and SpaceX’s Dragon use heat shields that char and erode, carrying heat away as they break down. It is very reliable, but the heat shield destroys itself and must be replaced after each flight.

A reusable heat shield gets no such option. It has to survive the heat without consuming itself, flight after flight. It has to be extremely light, because every kilogram of it is payload you never carry to orbit. It has to survive the violent acoustics and debris of launch, the cold of space and cryogenic tanks, and rain, humidity, and handling on the ground. And it has to be inspectable, because a heat shield you cannot verify is one you cannot trust.

Those requirements fight each other. Light materials are fragile. Tough materials are heavy. Good insulators are porous, and porous materials soak up water. Rigid ceramics do not stretch, and metal airframes always do. And in most places on the vehicle, there is no backup.

What did the Space Shuttle do?

The Shuttle’s airframe was mostly aluminum: cheap, light, well understood, and completely unable to survive re-entry. The belly reached about 1,260°C (2,300°F), and the nose cap and wing leading edges went past 1,500°C. The aluminum had to stay below about 175°C. The heat shield had to hold back more than a thousand degrees in a layer only a few inches thick.

NASA’s answer was a mosaic of about 24,000 tiles, plus blankets and carbon composite panels, each matched to the heating in its zone.

The Shuttle’s heat shield was a patchwork: black HRSI tiles on the belly, white LRSI tiles and blankets on the cooler upper surfaces, and RCC on the nose cap and wing leading edges. (NASA)

The tiles: 94 percent air

The black belly tiles were made mostly of LI-900: fibers of 99.9 percent pure silica glass, sintered into a block that is about 94 percent empty space and weighs 9 pounds per cubic foot, about as light as balsa wood.

The Shuttle’s belly up close: every tile individually shaped, numbered, and glued. (NASA)

That porosity made it an extraordinary insulator. In a famous demonstration, a tile heated in a 2,200°F oven until it glows can be picked up by its edges with bare fingers seconds later. The surface radiates heat away so fast, and the interior conducts it so poorly, that the corners cool almost immediately.

A Shuttle tile glowing after a 2,200°F (1,200°C) oven. Seconds later its corners are cool enough to touch. (NASA/Jim Grossmann)

The same porosity made it fragile. A tile could reportedly be crushed by hand, and a dropped tool could dent one. The fibers also had to be extremely pure. Impurities help silica crystallize into cristobalite, which expands far more than glassy silica and changes volume suddenly near 200°C, cracking the tile apart over repeated heating. A black borosilicate glass coating made each tile tough enough to handle and dark enough to radiate heat back into space.

The glue problem

The silica barely expanded with temperature. The aluminum underneath expanded 20 to 50 times more. Bonded directly to the skin, the tiles would have been torn apart.

So NASA put a cushion in between. Each tile was glued to a Strain Isolation Pad (SIP), a Nomex felt (the fiber in firefighters’ suits), which was glued to the aluminum with the same red RTV-560 silicone adhesive. The felt stretched and sheared while the tile stayed rigid. But the felt also concentrated loads where its fibers met the tile, and tiles began pulling apart at the bond line. The fix was to densify each tile’s underside with a baked colloidal silica layer. Every fix added labor and new ways to fail.

How a Shuttle tile was attached. Every layer was there to solve a problem the layer above or below it created.

Almost every tile was unique, shaped to its spot on the orbiter’s compound curves and individually machined, numbered, test-fit, glued, cured, and pull-tested. Stanford risk analyst Elisabeth Paté-Cornell, who studied the tiles for NASA, later recounted that under schedule pressure at least one worker had spat into the glue to make it cure faster.

The gaps between tiles, from about 0.028 to 0.2 inches, were packed with ceramic-fabric gap fillers. When a filler worked loose and stuck out into the airflow, it could trip the smooth boundary layer into turbulence, which heats the surface far more. On STS-114 in 2005, engineers worried two protruding fillers on Discovery could raise local heating by about 25 percent, so astronaut Steve Robinson rode the station’s robotic arm under the orbiter and pulled them out by hand.

And because a tile that is 94 percent air acts like a sponge, every tile had to be injected with a waterproofing chemical, DMES. Re-entry burned it out, so the tiles were re-treated after every flight.

The carbon edges

For the hottest places, the nose cap and the 22 panels along each wing’s leading edge, NASA used Reinforced Carbon-Carbon: carbon fiber cloth baked into pure carbon again and again, then coated with silicon carbide so it would not burn. RCC handled the heat well. It was also brittle, and the panels formed the wing’s leading edge. Columbia showed what happened when one broke.

What the Shuttle record shows

Across 135 flights, the heat shield was a constant source of worry:

  • STS-1 (1981): Columbia returned with 16 tiles missing and 148 damaged, partly from the overpressure wave of the solid rocket boosters. NASA redesigned the pad’s water sound suppression system.
  • STS-27 (1988): Debris from a booster’s nose cap left 707 damage sites on Atlantis’s belly and one tile missing. It likely survived only because that tile sat over a thick aluminum antenna mounting plate, which partially melted and held. Commander Robert “Hoot” Gibson told his crew there was “no use dying all tensed up.”
  • STS-107 (2003): Columbia.
  • STS-118 (2007): Foam gouged a 3.5-by-2-inch hole right through one of Endeavour’s tiles. Engineers studied it with the new post-Columbia inspection boom and decided it could fly home unrepaired.

NASA’s damage map of Atlantis after STS-27, the most heavily damaged orbiter ever to return safely, with inset photos of the missing tile and a large gouge. (NASA)

After Columbia, NASA added a 50-foot laser inspection boom, on-orbit repair kits, and tougher tiles in vulnerable areas. The Shuttle became safer, but not faster to turn around. The record was 54 days. The typical turnaround took months, and the heat shield was a major reason.

The Shuttle proved that a reusable heat shield was possible. It also proved that reusing one could cost nearly as much as replacing it.

What approaches is Starship trying?

SpaceX set a very different goal for Starship: full reuse, fast, more like an airliner than a museum piece. Ideally, a ship lands, refuels, and flies again within hours. That forced a rethink of the heat shield from the airframe up.

Ship 39, the first V3 Starship, inside Megabay 2 at Starbase in January 2026, covered in black hexagonal tiles on its windward side. (U.S. military photo via DVIDS, public domain)

Approach 1: Change the metal underneath

The most important thermal decision on Starship is not about tiles at all. It is the choice of stainless steel for the hull.

Aluminum is in trouble at about 175°C. Stainless steel keeps useful strength to several hundred degrees and does not melt until about 1,400°C. That changes the logic of failure. On the Shuttle, a missing tile in a hot zone could doom the vehicle. On Starship, the steel underneath gets very hot, may warp, and probably holds long enough to get home. Engineers call this the difference between fail-deadly and fail-degraded.

Steel’s heat tolerance pays off elsewhere too. The leeward side, sheltered during the belly-first re-entry, was designed to fly as bare steel with no heat shield at all. The windward tiles can be thinner than the Shuttle’s. And steel gets stronger at cryogenic temperatures, which suits a vehicle that is mostly propellant tank.

Approach 2 (shelved): Make the steel sweat

The first plan, floated in early 2019, was more radical: a double-walled steel hull that would “sweat” liquid methane or water through tiny pores, letting evaporation carry the heat away. This transpiration cooling has been studied for decades but has never flown on an orbital vehicle at this scale.

By March 2019, SpaceX was testing hexagonal ceramic tiles instead, keeping transpiration only as an option for spots that showed erosion. Starship has flown on tiles ever since. The idea has not died, though. In late 2024 Musk reportedly said SpaceX was reconsidering active cooling for the hottest areas, and in 2025 it flew an actively cooled metallic test tile.

Approach 3: Hexagonal tiles, pinned not glued

Today’s heat shield is about 18,000 hexagonal ceramic tiles, which space fans call “bestagons.” Like the Shuttle’s, they are silica-based with a black coating. Almost everything else is different.

Shape. In a square grid, a seam lined up with the airflow can channel hot gas along it. Hexagons break every seam into short zigzags across the flow.

Standardization. Instead of 24,000 unique parts, most of the acreage uses the same tile, repeated thousands of times. SpaceX fires them in industrial kilns at a Cape Canaveral facility nicknamed “the Bakery,” which it said in October 2025 was producing about 1,000 tiles a day, with a goal of 7,000.

Attachment. This is the biggest change. Starship’s main tiles are not glued. Small steel studs are welded to the hull, which is only a few millimeters thick and doubles as the propellant tank wall. Independent hardware analysts believe SpaceX uses capacitor-discharge stud welding, which fuses a stud in milliseconds with too little heat to warp the thin steel.

How a Starship tile is attached. Each pin is welded to the hull at its base (the stud), and the tile is locked on at the top with an acorn nut (the clip). Under the tile are a felt blanket and a secondary ablative layer. The steel hull can expand underneath without stretching the ceramic.

Each tile fits over its pins on top of a ceramic felt blanket. According to independent analyses (SpaceX has not published details), a self-locking acorn nut at the top of each pin holds the tile in place, and technicians drill small access holes to remove it. Because nothing is bonded, the steel can grow and shrink underneath while the gaps between tiles absorb the difference. That solves the Shuttle’s expansion problem mechanically, and turns replacement into a swap instead of a re-glue.

Approach 4: Build in a backup

After Columbia, perhaps the most important idea in reusable heat shields is this: assume a tile will fail, and decide what happens next.

Since Flight 4, Starship has carried a secondary ablative layer under its tiles, made of an undisclosed material. If a tile is lost, this layer chars away to protect the steel for the rest of re-entry. And SpaceX tests it on purpose. On several flights it has deliberately removed tiles, including from some of the hottest parts of the ship, and flown anyway. Shuttle engineers could only model that kind of test. They could never fly it.

Learning by burning: Flight 4 to the first orbit

Starship’s heat shield is being developed in public, with cameras pointed at the damage.

The trouble spots: Starship’s flaps, where moving hinges meet the fixed tiled hull. On Flight 4 in June 2024, plasma burned into the forward flap hinge during re-entry. (“Starship S20” by DimaLopatin1999, CC BY-SA 4.0, resized)

  • Early flights (2023–2024): Tiles fell off during ascent. Around flap hinges and stiffening ribs, where standard hexagons did not fit, SpaceX had used custom-cut tiles glued in place, and those areas were among the trouble spots. The Shuttle’s oldest problem had returned exactly where the new approach had not been applied.
  • Flight 4 (June 2024): Plasma burned into the forward flap hinge, melting away pieces of the flap on live video. The ship still made its landing burn and splashdown because the steel took long enough to burn through.
  • Flights 5 and 6 (late 2024): A new heat shield, with tiles Musk said were about twice as strong and the ablative backup behind them.
  • Block 2 ships (2025): SpaceX swapped many glued tiles for pinned ones, including “tiny tiles” between stiffening ribs and along flap edges. After Flight 10 it added “crunch wrap”: felt wrapped around tile edges, squeezed between neighbors to seal the gaps.
  • Flight 10 (August 2025): Besides deliberately removed tiles, the ship flew experimental metallic tiles, including one actively cooled. Orange streaks in the footage were the metal oxidizing (“rusting,” Musk said), a sign that bare metal faces its own problems in the hottest flow. The ship splashed down about 3 meters from its target.
  • Flight 12 (May 2026): The first V3 ship brought a new tile layout and better attachment clips. It also released two camera-carrying satellites to photograph its own heat shield in orbit, an early test of fast pre-re-entry inspection. Damage afterward looked light compared with earlier flights.
  • Flight 13 (July 2026): Ship 40 splashed down softly, tipped over, and, for the first time, did not explode. After weeks afloat it was towed to Christmas Island and shipped back to Starbase, giving SpaceX its first close look at tiles that had survived a real re-entry. In August, Musk told investors he would consider the heat shield problem “solved at this point.”
  • Flight 14 (September 2026): Starship reached full orbit for the first time and deployed 26 Starlink satellites. Its heat shield added extra tile retention, barriers against plasma flowing behind the tiles, and curved tiles to cut gap heating. It also carried two tiles recovered from Ship 40, the first Starship tiles known to fly through re-entry twice.

The pattern is clear. The broad acreage of hex tiles is now well understood. The hard parts are the edges: hinges, joints, curves, and transitions, where the physics is the same as it was for the Shuttle. And the real test has not happened yet: catching a ship, inspecting it, and flying the same heat shield again. As of this writing, SpaceX plans to try catching both booster and ship with the launch tower on Flight 15, no earlier than early November 2026.

Comparing the two approaches

The biggest difference between the two designs may be what is left behind a tile once it is gone.

An airplane versus a rocket: the shape sets the problem

The two vehicles come home in completely different ways, and that shapes their heat shields as much as any material choice.

The Shuttle was a glider. With no engines to use after re-entry, it had to fly to a runway like an airplane and touch down on wheels at more than 200 mph. That meant big delta wings, a tail, elevons, a body flap, and landing gear. The U.S. Air Force also wanted it able to land about 1,100 nautical miles to one side of its orbital track. Delta wings gave it that “cross-range,” at the price of a long, lifting glide: nose-high at about 40 degrees, roughly half an hour from the top of the atmosphere to the runway. Every airplane part had to be protected: thin wing leading edges hot enough to need RCC, control surfaces with hinges and seals, and landing gear doors cut right into the belly tiles. Each opening and edge was another way in for hot gas. During Columbia’s re-entry, sensors in the left main landing gear wheel well picked up rising temperatures as hot gas worked its way through the wing.

Starship is a rocket that falls. It has no wings, no wheels, and no runway. It enters belly-first at a steep angle, often described as about 60 degrees, and uses that broad belly mostly as a brake. Four flaps steer it, much like a skydiver uses arms and legs. Near the ground it flips upright, relights its engines, and lands vertically. SpaceX already catches Super Heavy boosters with the launch tower’s “chopstick” arms and plans to catch ships the same way.

Two ways home. The Shuttle flew a long, lifting glide that exposed its wings, control surfaces, and gear doors to the heat. Starship holds one belly-first attitude through peak heating, then lands like a rocket.

That changes the thermal problem in three ways:

  • Fewer holes in the shield. No landing gear means no gear doors in the windward tiles, and no wings means no long, thin leading edges. The hottest surface is a broad, gently curved belly that can be covered with mostly identical hexagons.
  • Only one side gets hot. Because Starship holds the same belly-first attitude throughout re-entry, the leeward side can stay bare steel. The Shuttle’s glide and complex shape meant it needed protection over almost its whole skin.
  • New weak spots of its own. The flaps and their hinges are Starship’s version of the Shuttle’s edges and doors. That is exactly where Flight 4 burned through. Catching a ship also requires hardpoints on its sides, and on Flight 6 SpaceX removed tiles at locations being studied for catch hardware to see how those areas would behave.

The price is fuel. A glider lands for free, while Starship has to carry propellant all the way down for its flip and landing burn. But that propellant buys a simpler shape to protect, and the Shuttle showed how dearly a complicated shape can cost.

In most rows, Starship wins. A steel airframe is the biggest single safety improvement in reusable heat shields since the Shuttle, and pinned attachment removes the Shuttle’s most labor-intensive, failure-prone step.

The caveat is reuse itself. Only one Starship, Ship 40, has been recovered intact, and no ship has flown twice. The Shuttle, for all its flaws, flew its heat shields on 135 missions.

The weight question, compared fairly

Weight is where comparisons get slippery, because the two vehicles were built for different jobs. So it helps to compare them on the same measures: the hull metal, the heat shield, and how much of what each one launches is actually cargo.

Solid bars are published or NASA figures. Hatched bars are estimates, because SpaceX has not published the dry mass of a V3 ship. All Starship ratios assume about 100 tons, within a plausible 85 to 130 tons.

The hull: heavier metal, about the same strength for its weight. Stainless steel is nearly three times as dense as the aluminum alloys in the Shuttle’s airframe: about 7.9 grams per cubic centimeter versus 2.8. Starship’s roughly 4-millimeter wall weighs about 31 kilograms per square meter before anything is attached to it. But cold-worked steel is also much stronger. Divide strength by density, and the Shuttle’s aluminum (about 124 to 138 kN·m/kg) and cold-worked 301 steel (about 122 to 179) land in the same range. Steel pulls ahead in two places that matter for Starship: it gets stronger at cryogenic temperatures, and it keeps roughly half its strength near 700°C, where the Shuttle’s aluminum was limited to about 177°C. In other words, steel is not a lighter hull. It is a hull that can do part of the heat shield’s job.

The heat shield: the same share, spread differently. The Shuttle’s whole thermal protection system weighed about 8.6 tons, roughly 10 to 11 percent of the orbiter’s dry mass, with belly tiles at only about 9 kilograms per square meter. A Block 1 Starship’s tiles plus ablative layer reportedly came to about 10.5 tons, about 10.5 percent of a 100-ton ship. The share is nearly identical. But Starship covers only its windward side, so its shield is heavier per square meter, roughly 12 to 15 kilograms by one estimate. That is the price of redundancy: felt, a backup ablator, and thousands of studs and nuts.

The payload: where Starship really differs. Here the gap opens up:

  • Share of liftoff mass. The Shuttle stack weighed about 2,040 tons at liftoff to put roughly 24 tons into low orbit, about 1.2 percent. A Starship V3 stack of roughly 5,700 tons is designed to carry 100 tons, about 1.75 percent.
  • Share of what reaches orbit. Of the reusable vehicle plus cargo that the Shuttle took to orbit, only about a quarter was payload. The rest was the 78-ton orbiter. For Starship, about half would be payload.
  • Reusable hardware per tonne of cargo. The orbiter and two booster casings came to about 10 tons of reusable hardware for every ton of payload. Starship’s ship and booster, together roughly 285 to 405 tons, would need about 3 to 4 tons per ton of cargo, but only if it carries its full 100-ton design payload. At the 35 tons claimed for the previous version, the figure rises to about 8 to 12, close to the Shuttle’s. Much of Starship’s advantage is a bet on sheer size.

Why this still is not perfectly fair. The orbiter carried a crew cabin, life support for up to eight people, a robotic arm, and three main engines inside its dry mass. Starship’s dry mass includes its own propellant tanks, while the Shuttle threw its External Tank away on every flight. Starship’s 100-ton payload is a design target, not yet demonstrated. Its figures leave out the propellant it must save for landing. And Shuttle payloads are quoted to a low 28.5-degree orbit; to the space station, it carried about a third less.

Even with those caveats, the pattern is clear. Both vehicles spend about a tenth of their dry mass on thermal protection. Starship spends more on its hull and gets more back in cargo, so the same few tons of heat shield serve a far larger payload. SpaceX’s answer to heat shield mass has been to build a bigger rocket rather than a lighter shield, betting that on a fully reusable vehicle, extra propellant is far cheaper than heat shield refurbishment.

Criticism and future directions

The “dead end” argument

In November 2024, Musk set the bar himself. A fully and immediately reusable heat shield, he wrote, was “the biggest technology challenge remaining for Starship,” and the “acid test” is to land, refill, and launch again with no refurbishment or laborious inspection.

By that standard, some very experienced people call Starship’s tiles a dead end. Days after Flight 13, and a week before Musk called the problem “solved,” three NASA veterans published an analysis of SpaceX’s footage of the floating ship. Dan Rasky spent nearly four decades on heat shield materials at NASA Ames and co-invented PICA, the basis of Dragon’s heat shield. Charlie Camarda is a former NASA Langley thermal-protection engineer who flew on STS-114, the first mission after Columbia. Charles Miller led NASA’s transition team for the Trump-Vance administration and co-founded Lynk Global, a satellite-to-phone company and Starlink rival, a potential conflict of interest worth noting.

Only a handful of tiles were lost, they said, but dozens to hundreds more appeared cracked or chipped, and white streaks at tile boundaries suggested hot gas was still getting into the gaps. “Starship’s current thermal protection system is a dead-end for all missions that require full and rapid reusability,” Rasky told Ars Technica. In their view, the design is an incremental improvement on Shuttle-era ideas.

Their case is simple. Ceramic is brittle. A V3 Super Heavy produces roughly 18 million pounds of thrust, and its acoustic energy can crack ceramic before the rocket clears the tower. Ice falls from frosted tanks, and micrometeoroids hit in orbit. Eighteen thousand tiles means eighteen thousand things to inspect. If even a few dozen need replacing after every flight, that is a maintenance operation, not an airliner turnaround. It matters most for Starship’s lunar lander, which must be refueled in orbit by a series of tanker flights. If each tanker needs days of tile work, the whole Artemis architecture slows down.

Supporters answer that the critics lean too hard on the Shuttle. A broken Starship tile is a maintenance item, not a death sentence. Tiles are standard parts, swapping them is mechanical, and machine vision can scan a hex grid far faster than people could inspect 24,000 unique pieces. Starship can now even photograph its own belly before coming home. And the progress from Flight 4 to Flight 14 has been real and visible.

My take is that both sides are right about different things. Brittleness is fundamental and cannot be fully engineered away. But Starship has made tile failure survivable, and a survivable failure can be managed with process and automation. The open question is economic, not physical: can inspection and replacement get fast and cheap enough?

What comes next

  • Tougher tiles and hybrid shields. NASA Ames’ TUFROC pairs a toughened, oxidation-resistant carbon-based cap with an insulating silica base. It has survived long, repeated arc-jet runs at about 1,600°C with no significant degradation and flies as the wing leading edges of the X-37B spaceplane. NASA estimates a TUFROC part costs about $50,000 and takes two months to make, against about $5 million and a year for equivalent Shuttle RCC. Sierra Space’s Dream Chaser, not yet flown, is designed to use a TUFROC-derived nose cap and leading edges. Cheap mass-produced tiles on the acreage, with tough composite pieces at the nose, hinges, and edges, may be the most practical next step.

The X-37B, a reusable uncrewed spaceplane whose wing leading edges use TUFROC, after its first landing in 2010. (U.S. Air Force)

Sierra Space’s Dream Chaser, a reusable spaceplane designed to use TUFROC-derived materials on its nose and leading edges. (NASA/Ken Ulbrich)

  • Integrated thermal protection systems. Instead of tiles over a hull, the skin is the structure: metal or ceramic-composite panels that carry loads and insulate at once, with fewer parts and fewer seams.
  • Active cooling. Stoke Space is building a fully reusable upper stage that cools a metal heat shield on its base with its own liquid hydrogen, much as a rocket nozzle cools itself. SpaceX’s actively cooled test tile shows it is keeping that door open too.
  • Research funding. The critics’ main request was for NASA to restart serious research into orbital re-entry heat shields. The U.S., they wrote, “stopped investing in new/better TPS over two decades ago,” and nearly everything flying today traces back to the Shuttle, X-33, and National Aerospace Plane programs of 30 to 40 years ago.
  • Inspection as a core technology. The least glamorous answer may matter most: robots, cameras, and embedded sensors that can check every tile in hours. If the Shuttle’s problem was that it was too hard to verify, the solution may be to make verification nearly automatic.

Coda

Every time I watch a Starship come out of the plasma, I think about Columbia. Columbia’s black chines and Starship’s black hexagons are two answers to the same question, and the second has learned from the first.

The Shuttle’s engineers did something extraordinary. They built a reusable heat shield out of glass fibers and felt when nobody knew whether that was possible, and it flew 135 times. Their mistake was not in the materials science. It was in the system: a brittle shield on an airframe with no tolerance for heat, run by a culture that had learned not to look closely at a known problem.

Starship’s engineers are correcting that mistake in steel, designing a vehicle where a missing tile is a maintenance item rather than a crisis, and then flying with missing tiles to prove it. That is a real advance.

But the hardest part is still ahead. No one has yet built a heat shield that can come back from orbit, get a quick look, and fly again the next day. Until then, re-entry will remain the moment when everything has to work.

I hope we get there. And I hope that when we do, the engineers who make it happen remember the seven people who flew Columbia home.

Sources and further reading

Starship’s Heat Shield: Can 18,000 Tiles Escape the Space Shuttle’s Fatal Flaw? was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Is Diffusion LLM the speed demon as promised?]]> https://medium.com/the-low-end-disruptor/is-diffusion-llm-the-speed-demon-as-promised-dd7189c4ad29?source=rss----16704e6008f5---4 https://medium.com/p/dd7189c4ad29 Wed, 21 Oct 2026 20:33:07 GMT 2026-10-21T20:33:07.132Z We test Inception’s Mercury 3 against the fastest autoregressive models from Anthropic, Google Gemini, OpenAI, and Cerebras to find out

Where each model is when the first one finishes, by median time to answer a coding problem (cars drawn at constant speed). 637 problems × 5 samples, run r2-uc1-main-20261021T034053Z, as of 2026–10–21.

On October 19, 2026, Inception Labs launched Mercury 3 with a bold pitch: a diffusion language model that beats GPT-6 Luna and Claude Haiku 5.5 on benchmarks while running 4 to 8 times faster, at more than 1,000 tokens per second (Inception blog, “Diffusion at Scale: Introducing Mercury 3”, Oct 19, 2026).

Faster and smarter than the big labs’ speed models. That is the kind of sentence that makes a benchmark nerd reach for a credit card. So I did. About $34 of API spend and more than 48,000 model calls later, here is what I found.

Short version: Mercury 3 is genuinely fast and genuinely good. It is not the fastest thing on the menu, it is not the cheapest per right answer, and it has one very odd habit.

Diffusion LLMs in one paragraph

Normal (autoregressive) LLMs write like a typist: one token at a time, left to right. A diffusion LLM writes like a sculptor: it starts with a rough block of placeholder text and refines many tokens in parallel over a few passes, until the answer “comes into focus.” In theory that means far fewer sequential steps, and so much more speed. If you want the longer explainer, I wrote one back when Mercury first launched: What is Diffusion LLM and why it matters (Feb 2025).

Here is the 2026 version doing its thing, on the same kind of prompt I used in 2025 (“write a Python function that splits an image into left and right halves”):

Mercury 3 (instant) in diffusing mode: the answer resolves in a handful of refinement steps. Run r5-diffusion-capture-20261021T181518Z, as of 2026-10-21.

Across 30 such captures, answers resolved in 5–11 visible steps, in well under a second at the median. One detail the marketing animations skip: refinement is not a smooth fade-in. In every one of the 30 calls, at least one step moved further from the final text before coming back. The sculptor occasionally un-chisels.

The two tests, in plain English

I picked two jobs where speed actually matters to a person waiting on a screen.

Test 1: “Write me this function” (code generation). Each model gets a programming task, for example “write a Python function that checks whether any two numbers in a list are closer to each other than a given threshold.” We run its code against hidden tests. Pass or fail, no partial credit. That’s 637 problems from three well-known sets (HumanEval+, MBPP+, and LiveCodeBench), 5 tries each, for every model. This is the coding-assistant use case: you ask, you wait, you hope.

Test 2: “Answer this question from our database” (a SQL agent). The model gets a real database and a question like “What is the total amount of money spent on food?” (from BIRD, a standard text-to-SQL benchmark). It can’t see the data upfront. It has to look around: list tables, peek at columns, run a few test queries, then submit the query that answers the question. Up to 8 turns. We check whether its query returns the same rows as the official answer. 150 questions, 3 tries each.

Why an agent? Because agents are where speed compounds. If one call takes a second and the agent needs six of them, you’re waiting six seconds. A model that is fast per call but needs more calls can lose the race. More on that in a moment.

The contenders, each the “fast” tier of its maker:

  • Mercury 3 (Inception, diffusion), at four reasoning settings from instant to high
  • Claude Haiku 5.5 (Anthropic), GPT-6 Luna (OpenAI), Gemini 3.5 Flash-Lite (Google)
  • gpt-oss-120b on Cerebras: an ordinary autoregressive open model running on very fast specialised chips. This one is my control. If Mercury is fast because of diffusion, it should beat a normal model on fast hardware. If it’s fast because of serving, it won’t.

Same prompts, same settings, randomised order, everything measured end-to-end over the public APIs from one machine. Full code, configs and raw results: github.com/zbruceli/mercury3.

Finding 1: Speed is real, but it is not unique

On code generation, Mercury 3 at its best setting (low) passes 86.0% of problems with a median response time of 0.83 seconds. That ties Claude Haiku with thinking off (86.1% at 0.97 s) and edges out GPT-6 Luna with reasoning off (83.2% at 1.28 s).

Then the control walks in. gpt-oss-120b on Cerebras passes 84.9% at 0.34 seconds. Within about a point of Mercury, at well under half the wait.

Code generation: accuracy vs median latency, one point per model and setting. Up and to the left is better. Run r2-uc1-main-20261021T034053Z, as of 2026–10–21.

Raw generation speed tells the same story. Measured as visible text streamed after the first token, Mercury 3 writes about 850–900 tokens per second. That’s roughly 2× Gemini Flash-Lite, 2.8× Claude Haiku and 6× GPT-6 Luna, which lands neatly inside Inception’s “4–8× faster” for Luna, and short of it for Haiku. But gpt-oss on Cerebras writes about 2,400–2,500 tokens per second, ~2.7× Mercury, at every output length we tried. Diffusion’s advantage is a constant factor, and it doesn’t grow on longer outputs.

One nice touch you can feel: short Mercury answers arrive in a single block. Total time (0.30 s) is basically the time to first token (0.29 s). The answer doesn’t stream in; it just appears.

Finding 2: In agents, the number of turns matters as much as speed per turn

In the SQL agent, Mercury 3 (low) finishes a whole task in 2.06 seconds at the median. Claude Haiku takes 3.86 s, Gemini 4.43 s, GPT-6 Luna 5.95 s. That's 1.9–2.9× faster than the frontier labs' fast models per task. Diffusion, or at least this product, delivers in the agent loop.

But look at how it gets there:

SQL agent: median latency per model call (faint bar) and per whole task (solid bar), relative to Mercury 3 low, with average turns per task. Run r4-uc2-main-20261021T165313Z, as of 2026-10-21.

Claude Haiku is 3.2× slower than Mercury per call, but only 1.9× slower per task, because it solves the problem in about 3.2 turns where Mercury takes 5.1. Haiku thinks less often and better. Meanwhile gpt-oss on Cerebras is 1.7× faster than Mercury per call, but takes 6.3 turns, and ends up only slightly faster per task (1.82 s). At its medium setting it's actually slower than Mercury per task.

Lesson for agent builders: task latency ≈ call latency × number of turns, and the number of turns is a property of the model, not something your speed chart will tell you.

On accuracy, everyone lands within a few points (47.6% to 59.1% correct). Claude Haiku is the most accurate, about 5 points ahead of Mercury 3 when compared on the same questions, but that lead is borderline: its confidence interval reaches down to zero. With 150 questions, the per-model error bars are ±7–8 points, so I wouldn’t crown anyone here.

Finding 3: Cheap per token is not cheap per answer

Mercury 3 is priced at $0.10 / $0.35 per million input / output tokens, a 50% launch promo off the regular $0.20 / $0.70. Low per-token prices, but what matters is cost per correct answer:

Total spend divided by successes; Mercury’s hatched bar shows the regular (non-promo) price. Runs r2-uc1-main-20261021T034053Z and r4-uc2-main-20261021T165313Z, prices as listed 2026–10–20, as of 2026–10–21.
  • Code: Mercury 3 low costs $0.59 per 1,000 passing answers at the promo price ($1.19 regular). GPT-6 Luna with reasoning off costs $0.07. Claude Haiku (thinking off) costs $0.14.
  • SQL agent: Mercury 3 instant costs $1.31 per 1,000 correct tasks ($2.62 regular). Luna costs $0.74. gpt-oss on Cerebras and Gemini are the priciest here ($4.83–$6.56), because more turns mean re-sending more context.

Mercury isn’t expensive, but it’s also not the bargain the per-token sticker suggests, and the promo price won’t last.

Finding 4: Mercury 3 sometimes thinks forever

Here’s the odd habit. Mercury 3 has reasoning settings, and you’d expect more reasoning to mean better answers. It’s the opposite. On code, accuracy drops from 86.0% at low to 82.3% at medium and 81.4% at high.

The reason: at higher settings, Mercury 3 sometimes reasons silently until it hits the 32,768-token output cap and returns nothing at all. That happened on 7.5% of calls at medium and 8.6% at high. Those runaway calls burned 61% of all the output tokens Mercury 3 used in the code test, and pushed its slowest-5% response times past 50 seconds. Giving it 4× more room barely helped: in a small 12-call probe, only one extra call finished. No other model in the code test ran away even once.

My favourite example: an easy-looking problem asking for the “directrix of a parabola,” whose single worked example doesn’t match the textbook formula. The autoregressive models shrug, write the standard formula, and fail. Mercury 3 at medium and high tries to reconcile the math with the example on all 10 attempts, and thinks until it runs out of budget. Same score as a wrong guess, but at ~32,000 tokens and close to a minute per attempt. Autoregressive models fail by committing; this one fails by not stopping.

Practical advice: use Mercury 3 at low or instant. At low it is also 9 points better than its predecessor Mercury 2.5 at the same setting (86.0% vs 76.9%), and faster (0.83 s vs 1.36 s). Real progress in 20 months.

Surprises that have nothing to do with diffusion

Benchmarking five vendors side by side turns up some gossip.

  • OpenAI has a slow front door. Even a free “list models” request took about 0.8–1.2 s of server-side processing at OpenAI, where the same call to the other providers came back in about 15–225 ms. On real requests, OpenAI spent ~0.6 s server-side before doing anything visible. It’s not your account tier: paying 2× for OpenAI’s Fast mode trimmed only ~0.15 s at the median (it mostly fixes the worst cases).
  • The cheapest right answer comes from GPT-6 Luna with reasoning off. Slowest decoder in the test (about 130–160 tokens/s), cheapest per solved problem in both tests.
  • Some models really like to talk. Asked for an ~800-line program, Claude Haiku and GPT-6 Luna wrote about 15,000 tokens; gpt-oss wrote about 6,000. Compare speeds in tokens per second, not total seconds.
  • Haiku stops exploring when you ask for JSON. With a strict JSON output format switched on, Claude Haiku answered all 150 database questions in one shot, without looking at the database once. It still scored 53.3%.
  • Mercury 3 sometimes leaks its own plumbing. In that same strict-JSON mode, it broke the format on 6 of 150 tasks, mostly by appending fragments of its internal tool-call markup after valid JSON. Every other model: zero.
  • Cerebras throttled us below its published limit. We kept under its documented 1,000 requests per minute and still collected 765 rate-limit errors in the code test.

So, is it the speed demon as promised?

Back to Inception’s claim:

  • “More than 1,000 tokens per second”: close. We measured ~850–900 visible tokens/s from the client side, over the network, so it includes streaming and network overhead that a server-side number doesn’t.
  • “4–8× faster than Luna and Haiku”: on raw generation speed, about 3× Haiku and 6× Luna. On what you actually wait for, smaller: 1.2–1.5× per coding answer at matched quality, and 1.9–2.9× per agent task.
  • “Outperforms Luna and Haiku”: ties them when their reasoning is off, trails them when it’s on (88.4% and 87.9% vs 86.0% on code). In the SQL agent, all three are within the error bars.
  • “Because diffusion”: this is where the claim needs a caveat. An ordinary autoregressive model on Cerebras hardware was faster than Mercury 3 in both tests. What we measured is a product (model plus serving stack), not an architecture. Diffusion may well be why Mercury beats the big labs’ fast models, but it isn’t the only road to speed.

Verdict: Mercury 3 is faster than the big labs’ fast models, about as accurate as them with reasoning off, and especially good in agent loops. It’s a speed demon, just not the only one in town.

Caveats, honestly

  • Products, not architectures. Every comparison includes each vendor’s hardware, network and API overhead.
  • LiveCodeBench is not contamination-free. All public problems predate the models’ training cutoffs, so it serves as a “harder set,” equal for everyone, not a fresh one.
  • The SQL accuracy numbers are noisy. ±7–8 points per model; only paired differences are worth quoting.
  • Promo pricing. Mercury’s numbers double at the regular price. Both are shown.
  • One machine, one region, one day. Single client host in the US West, standard (non-priority) API tiers, measured October 2026. Your latency will vary.

What I’d test next

  • A bigger SQL run (all ~500 scorable BIRD questions) to shrink those error bars.
  • Mercury on fast hardware, if Inception ever serves it on Cerebras- or Groq-class chips. That’s the clean “diffusion vs. hardware” experiment.
  • Code editing: Inception’s separate Mercury Edit model does fill-in-the-middle and next-edit prediction, which this study didn’t touch.
  • Real-time and voice-style workloads, where Mercury’s realtime flag might matter (it made no difference for code).
  • Controllability: early research suggested diffusion models handle “reverse this” tasks that trip up left-to-right models. Worth a proper probe.

For a comprehensive technical report, you can find on my personal website at https://zbruceli.org/blog/mercury-3-vs-the-fast-autoregressive-models/. All code, configs, run data summaries, and the scripts that generate every chart here are on GitHub: github.com/zbruceli/mercury3. If you find a bug in my numbers, I’d genuinely like to hear about it.

Data notes. All numbers come from these runs (October 21, 2026): code generation r2-uc1-main-20261021T034053Z; output-length sweep r3-uc1-length-20261021T152238Z; output-cap probe r1b-cap-probe-20261021T021543Z; SQL agent r4-uc2-main-20261021T165313Z; strict-JSON sub-run r4b-uc2-strict-20261021T170547Z; diffusion capture r5-diffusion-capture-20261021T181518Z; OpenAI Fast-mode test oai-priority-ab-20261021T033428Z. Mercury prices as listed 2026–10–20.

Is Diffusion LLM the speed demon as promised? was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Moxie Marlinspike: The Anarchist Sailor Who Built Signal and Encrypted Billions of Chats]]> https://medium.com/the-low-end-disruptor/moxie-marlinspike-the-anarchist-sailor-who-built-signal-and-encrypted-billions-of-chats-5d3f7b486403?source=rss----16704e6008f5---4 https://medium.com/p/5d3f7b486403 Mon, 19 Oct 2026 23:22:19 GMT 2026-10-19T23:22:19.226Z

Moxie Marlinspike, a dreadlocked squatter who sailed a $1,000 wreck to the Caribbean with bags of bricks for anchors, built Signal and the encryption guarding billions of WhatsApp and Messenger chats, then got Facebook, Google, and Microsoft to run his code.

This is a shortened version. Read the full story, with all 99 sources, at zbruceli.org.

The Bricks

The spare anchor is a bag of bricks.

Not a Danforth, not a plow, not one of those stainless-steel Rocna jewels the yacht-club people in Fort Lauderdale hang off their bows like cufflinks. Bricks. Red-clay, scavenged bricks, stuffed into a sack and tied to a line. Somewhere in the islands, off the side of a beat-up thirty-foot sailboat that a gang of broke kids bought as a wreck for a thousand dollars and named, with perfect punk logic, Pestilence, the sack goes over the side, ker-SPLOOSH, and everybody on deck watches the line pay out and thinks the same thing: Well. We’ll see.

Bricks go into a bag on the deck of Pestilence to become an anchor. A still from Hold Fast.

On deck is a tall, lanky young man with dreadlocks and a name that sounds like a pirate made it up after three rums: Moxie Marlinspike. Moxie is a childhood nickname. A marlinspike is a sailor’s steel spike for prying apart rope strands so they can be spliced. He was born in Georgia; his birth name, widely reported as Matthew Rosenfeld, is something he declines to discuss.

Over two winters, Moxie and three friends calling themselves the Anarchist Yacht Club rebuild the gutted Pearson 30 with scavenged plywood, step its mast using the dinghy crane of an unattended superyacht, and sail it from Florida through the Bahamas toward Haiti and the Dominican Republic. They film everything. The result, a 2008 video zine called Hold Fast, becomes a cult classic: a manifesto for the idea that the world’s systems are more fragile than they look, and that anybody with enough nerve and skill can sail straight past them.

Now jump ahead a decade. The same man wrote the mathematics that protects the private conversations of billions of people. The Signal Protocol, which he designed with the cryptographer Trevor Perrin, runs inside Signal, WhatsApp, Facebook Messenger, and Google Messages. A teenager in São Paulo uses it. So does a reporter in Kyiv messaging a source.

That’s the paradox, and it’s the whole story: an anarchist who distrusts technological power built the most important privacy technology on Earth, and the industry’s biggest players ended up running his code.

The Squats and the Sea

San Francisco, the late 1990s, the dot-com boom at full fever. Moxie arrives at eighteen, sleeps his first few nights in Alamo Square Park, and lands a job at the dot-com WebLogic. It doesn’t take. At the height of the bubble he quits and goes the other way, down: punk houses, squats, hacker collectives, hitchhiking and freight-hopping across America. He builds a life around one idea: autonomy above everything.

He writes it down, too. In 2005, with Windy Hart, he co-authors An Anarchist Critique of Democracy, which goes after not dictators but democracy itself. Voting, it argues, hands your will to an outside power; majority rule is still rule. What he wants instead is “unmediated relations between free individuals.”

Keep that in mind. It comes back later in the strangest possible form.

The sea is where the philosophy turns physical. Sailboats are supposed to belong to millionaires; Moxie finds marinas full of abandoned boats nobody wants. His sailing collective is called Blue Anarchy. Its creed is his creed: skip the gatekeepers, scavenge what others threw away, and trust your own competence. Years later he’d sum up his view of the pre-built world to The New Yorker:

“Living in Venice, California is like living at the end of the world, the end of history. … All the decisions have been made. This is the world we get.”

For most people, that’s a description of life. For Moxie, it’s a provocation.

“We Should All Have Something to Hide”

June 2013. A week after The Guardian published the first Snowden story, everyone was repeating the same soothing line: If you have nothing to hide, you have nothing to fear.

Moxie took it apart in an essay called We Should All Have Something To Hide. His argument: in the modern world, everybody is a criminal. Quoting law professor James Duane, he notes that federal crimes are spread across roughly 27,000 pages of the U.S. Code, plus nearly 10,000 regulations with criminal penalties. Then the punchline: owning an undersized lobster is a federal crime, even, he writes, “if you found it after it died of natural causes.”

It’s funny until it isn’t. If everyone breaks some law, and the state keeps a permanent record of everyone’s communications, then enforcement becomes purely selective. The law looks wherever the powerful point it.

He goes further. Progress, he argues, depends on people being able to break the law in private. Marijuana legalization and same-sex marriage didn’t win in an abstract “marketplace of ideas.” People lived differently first, until the law caught up. A surveillance state that enforces everything perfectly would freeze society solid.

Moxie in 2013, the year of “We Should All Have Something To Hide” and of Open Whisper Systems.

His call to action wasn’t to vote or petition. It was to build user-friendly technology that stymies surveillance, because “it’s going to take all of us.”

He had already started.

The Man Who Broke the Locks

Before he built the vault, he spent years proving that every other vault was made of cardboard. The web’s entire trust model, every padlock icon and bank login, rested on SSL/TLS and the Certificate Authority system. Moxie pulled up the floorboards.

The null-prefix trick is almost beautiful. A certificate authority sees paypal.com\0.thoughtcrime.org, confirms Moxie owns thoughtcrime.org, and signs it. But the browser, written in C, hits the null byte, which in C means the string ends here, and reads only paypal.com. A forged identity, blessed by the system itself.

The Black Hat Briefings stage, where researchers turn the industry’s assumptions into live demos.

That’s when his reputation hardened: the researcher who doesn’t just find the hole but hands you the crowbar. You can ignore a whitepaper. You can’t ignore a working exploit in every script kiddie’s toolkit.

The Border and the Saudi Pitch

November 2010, JFK airport. Returning from the Dominican Republic, Moxie is pulled aside by Customs and Border Protection for nearly five hours. Agents demand the passwords to his laptop and phones. He refuses, calmly and completely. They take the devices away to inspect them and hand them back before he leaves. He never trusts them again; they could have modified the hardware, he told Wired, or installed new keyboard firmware.

Some governments wanted to hire him instead. In 2013 an email arrived about a project run by Yasser D. Alruhaily at Mobily, one of Saudi Arabia’s largest telecoms. The subject line: “Solution for monitoring encrypted data on telecom.” Under pressure from the Saudi regulator, Mobily wanted help intercepting its customers’ Twitter, Viber, WhatsApp, and Line traffic.

Most people would quietly say no. Moxie published it. He named the project’s manager, quoted the emails, and described the design document on his blog. Mobily told Reuters that it had never communicated with him. The intelligence world got the message: this man is not for sale.

That reputation bought trust. In November 2015, Edward Snowden, the man who knew better than anyone what the NSA could do, tweeted four plain words: “I use Signal every day.”

Building Signal

Here’s where the punk who breaks locks becomes the punk who makes them.

Before Moxie, strong encryption was a hobby for the obsessed: PGP, command-line incantations, key-signing parties. His insight was moral as much as technical: privacy only experts can use isn’t privacy for anyone.

  • 2010: He and roboticist Stuart Anderson co-found Whisper Systems, launching TextSecure (encrypted texts) and RedPhone (encrypted calls) for Android.
  • 2011: Twitter buys the company to bring Moxie in to run security. He persuades Twitter to open-source both apps.
  • 2013: He leaves to start Open Whisper Systems, a grant-funded open-source project.

Then, with Trevor Perrin, he builds the thing. It was first called the Axolotl Ratchet, after the salamander that regrows lost limbs, because the protocol heals itself. Steal a key, and the system grows new ones and locks you out again. Older schemes like OTR needed both people online at once; theirs works even when one phone is asleep in a pocket.

The Double Ratchet, from the specification by Trevor Perrin and Moxie Marlinspike.

Academics led by Katriel Cohn-Gordon and Cas Cremers formally analyzed the protocol and proved the security of its core. In cryptography, where most clever ideas die in peer review, that’s close to a miracle.

Then came scale. In November 2014, WhatsApp announced it was adopting the protocol; by April 2016, more than a billion people had end-to-end encryption by default, and almost none of them noticed. That was Moxie’s theology: the best security is the kind you never have to think about. Google Allo, Facebook Messenger, Skype, and later Google Messages followed. The biggest data-harvesting companies in history were now, for message content at least, running Moxie’s code.

By then TextSecure and RedPhone had merged into one app with one blue icon: Signal. In 2017, Moxie and Perrin won the Levchin Prize for Real-World Cryptography.

The Anarchist King

As Signal grew, the decentralization faithful made one demand: Federate. Let anyone run a server or write a client, like email or Matrix. Isn’t that what anarchists want?

Moxie said no. Signal stayed a walled garden, centralized and run largely on AWS. Third-party clients weren’t welcome.

He explained why in The Ecosystem Is Moving, a 2016 essay he later delivered as a talk at the 36th Chaos Communication Congress in Leipzig in 2019, to a hall full of the most hardcore decentralization believers on Earth. Federated protocols, he argued, are frozen in time: every upgrade needs agreement from countless operators, so progress stops. “My email is not encrypted,” he told them, “and never will be.”

36C3, Leipzig, December 2019, where Moxie told the decentralization faithful the ecosystem was moving.

Centralization let Signal move fast, shipping features like Sealed Sender (2018), which hides who sent a message even from Signal. And federation leaks metadata from server to server. As former NSA and CIA director Michael Hayden had put it in 2014: “We kill people based on metadata.”

So Moxie accepted the paradox: to build the most anti-authoritarian tool on the planet, he had to run it with near-total authority. Then he designed away the need to trust him. When a U.S. grand jury subpoenaed Signal in 2016, the company could hand over just two things: when an account was created, and when it last connected. A king, maybe. But a king whose vaults are empty by design.

It Fell Off a Truck

April 2021. Israeli forensics firm Cellebrite, whose UFED devices pull data from seized phones for police and, according to Moxie’s post, authoritarian governments, had boasted that it could access Signal data. Moxie’s reply became instant legend:

“By a truly unbelievable coincidence, I was recently out for a walk when I saw a small package fall off a truck ahead of me.”

A Cellebrite UFED device, the kind of kit that “fell off a truck.”

Then he did the forensics on the forensics company. Its software lacked industry-standard exploit mitigations and bundled FFmpeg libraries from 2012 that had missed more than a hundred security updates. Worse, a specially crafted file on a phone could run arbitrary code on the investigator’s own computer and silently alter past and future reports. His video showed it popping a Windows message box. Within days, a defense lawyer in Maryland cited it in a motion for a new trial.

The kicker: future versions of Signal, he noted, would periodically fetch files that served no purpose inside Signal, files he described as merely “aesthetically pleasing.” He didn’t say what was in them. He didn’t have to.

Money, a Coin, and an Exit

Signal sells no data, shows no ads, and charges nothing, while serving tens of millions of users. In February 2018, WhatsApp co-founder Brian Acton, who had left Facebook over how to monetize WhatsApp and what that meant for privacy, put $50 million into the new Signal Technology Foundation, structured as an interest-free loan not due until 2068. The bills remain huge: in 2024 the foundation reported $29.4 million in revenue against $38.0 million in expenses.

Moxie at TechCrunch Disrupt, San Francisco, September 2017, in his years as Signal’s CEO.

In 2021 Moxie led the integration of MobileCoin, a privacy cryptocurrency he had advised from its start, so users could pay each other as privately as they talk. It blew up. Bruce Schneier called it a mistake that invited regulators; critics called it a “funny-money” scheme.

On January 10, 2022, Moxie stepped down as CEO, saying the team was strong enough that he felt “very comfortable replacing myself.” The next day one headline read: “Shame on You, Moxie Marlinspike.” Acton became interim CEO, and that September Meredith Whittaker, AI researcher and 2018 Google walkout organizer, became president. The kingdom kept running without its king. That may be what he was proudest of building.

The Poop Emoji Heard Round the World

Three days before stepping down, Moxie threw one more grenade: My first impressions of web3.

At the height of the NFT frenzy, he actually built some decentralized apps and found a con of architecture. Phones can’t run blockchain nodes, so “decentralized” apps quietly depended on a few companies like Infura, Alchemy, and OpenSea, without verifying what those services sent back.

So he made an NFT that changed depending on who was looking. On OpenSea it looked like one thing; in your crypto wallet, the thing you supposedly owned forever, it was a poop emoji. 💩 When OpenSea delisted it, it vanished from his own wallets too, because they relied on OpenSea’s API. The blockchain record never changed. One company flipped one switch, and the illusion was gone.

Moxie in 2022, after Signal: still building, still sailing past the gatekeepers.

The irony was rich. The man condemned for refusing to decentralize Signal had shown that much of what passed for decentralization was theater.

Quantum Ratchets and Confer

The architecture he left behind kept evolving. In 2023 Signal added PQXDH, a post-quantum handshake using CRYSTALS-Kyber (since standardized as ML-KEM), against agencies that “harvest now, decrypt later.” In 2025 it added the Sparse Post-Quantum Ratchet, forming a Triple Ratchet. Moxie didn’t write these upgrades, but the bones were his. The salamander grew a limb its creators never imagined.

He didn’t stay idle. In late 2025 he launched Confer, a private AI assistant. People confess things to chatbots they once told only priests and therapists, and Moxie sees mainstream AI apps, OpenAI’s above all, as vast data lakes. Confer encrypts chat history with passkeys and runs the model inside sealed hardware enclaves, so the host can’t read the conversation.

Then, in March 2026, a twist worthy of his career: Moxie announced he would build Confer’s privacy technology into Meta AI, with Confer staying independent, much as he once brought the Signal Protocol to WhatsApp. The anarchist was walking back into the house of Zuckerberg, carrying the lock.

Hold Fast

The contradictions are the man. An anarchist who ran the world’s most important privacy infrastructure like an autocrat. A cryptographer who distrusts technology. A punk who never wore a suit and still got Facebook, Google, and Microsoft to run his code. A lock-breaker who built the strongest lock in the world.

As security experts have long argued, tools like his change the economics of surveillance. Mass surveillance used to be cheap and invisible. For the billions whose messages now run on his protocol, spies are pushed toward expensive, risky, targeted attacks. He didn’t end surveillance. He made it cost something.

Hold fast is an old sailor’s command: grip the line, don’t let go. It was the name of his movie. It turned out to describe his life. The only way to protect human autonomy in an age of total visibility, he has argued all along, is to make sure everyone keeps the dangerous right to hide.

He held fast. The anchor held.

This is a shortened version. The full story, with the complete list of 99 sources, is at zbruceli.org.

Key Sources

  1. Taking Back Our Privacy — Anna Wiener, The New Yorker (2020), https://www.newyorker.com/magazine/2020/10/26/taking-back-our-privacy
  2. Moxie Marlinspike — Wikipedia, https://en.wikipedia.org/wiki/Moxie_Marlinspike
  3. Sailor-Punk and the State of Cruising — SAIL Magazine, https://sailmagazine.com/cruising/waterlines-diy-punk-sailors/
  4. “Hold Fast” a documentary by Moxie Marlinspike — Internet Archive, https://archive.org/details/holdFastADocumentaryByMoxieMarlinspike
  5. An Anarchist Critique of Democracy — The Anarchist Library, https://theanarchistlibrary.org/library/moxie-marlinspike-and-windy-hart-audio-anarchy-radio-an-anarchist-critique-of-democracy
  6. We Should All Have Something To Hide — Moxie Marlinspike, https://moxie.org/2013/06/12/we-should-all-have-something-to-hide.html
  7. Black Hat DC 2009: New Tricks for Defeating SSL in Practice, https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
  8. Mozilla Foundation Security Advisory 2009–42 (null-prefix certificates), https://www.mozilla.org/en-US/security/advisories/mfsa2009-42
  9. Weaknesses in MS-CHAPv2 Authentication — Microsoft Security Response Center, https://msrc.microsoft.com/blog/2012/08/weaknesses-in-ms-chapv2-authentication
  10. Hacker Moxie Marlinspike detained at border — Wired (2010), https://www.wired.com/2010/11/hacker-border-search/
  11. A Saudi Arabia Telecom’s Surveillance Pitch — Moxie Marlinspike, https://moxie.org/2013/05/13/saudi-surveillance.html
  12. Saudis’ Mobily denies asking for help to spy on customers — Reuters, https://www.reuters.com/article/saudi-telecoms-spying/saudis-mobily-denies-asking-for-help-to-spy-on-customers-idUSL6N0DW33M20130515
  13. Edward Snowden on X, “I use Signal every day” (2015), https://x.com/snowden/status/661313394906161152
  14. Whisper Systems — Wikipedia, https://en.wikipedia.org/wiki/Whisper_Systems
  15. Advanced cryptographic ratcheting — Signal Blog (2013), https://signal.org/blog/advanced-ratcheting/
  16. A Formal Security Analysis of the Signal Messaging Protocol — IACR ePrint, https://eprint.iacr.org/2016/1013
  17. WhatsApp’s Signal Protocol integration is now complete — Signal Blog (2016), https://signal.org/blog/whatsapp-complete/
  18. The Ecosystem Is Moving — Signal Blog (2016), https://signal.org/blog/the-ecosystem-is-moving/
  19. The Ecosystem Is Moving — 36C3 talk recording, https://media.ccc.de/v/36c3-11086-the_ecosystem_is_moving
  20. Grand jury subpoena for Signal user data — Signal, https://signal.org/bigbrother/eastern-virginia-grand-jury/
  21. Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer — Signal Blog, https://signal.org/blog/cellebrite-vulnerabilities/
  22. Signal Foundation announcement — Signal Blog (2018), https://signal.org/blog/signal-foundation/
  23. Signal Technology Foundation Form 990 filings — ProPublica, https://projects.propublica.org/nonprofits/organizations/824506840
  24. Signal Adds Cryptocurrency Support — Schneier on Security, https://www.schneier.com/blog/archives/2021/04/wtf-signal-adds-cryptocurrency-support.html
  25. New year, new CEO — Signal Blog (2022), https://signal.org/blog/new-year-new-ceo/
  26. My first impressions of web3 — Moxie Marlinspike, https://moxie.org/2022/01/07/web3-first-impressions.html
  27. The PQXDH Key Agreement Protocol — Signal Blog (2023), https://signal.org/blog/pqxdh/
  28. SPQR: Signal’s Sparse Post-Quantum Ratchet — Signal Blog (2025), https://signal.org/blog/spqr/
  29. Confessions to a data lake — Confer Blog (2025), https://confer.to/blog/2025/12/confessions-to-a-data-lake/
  30. Encrypted Meta — Confer Blog (2026), https://confer.to/blog/2026/03/encrypted-meta/

Image Credits

  1. Moxie Marlinspike aboard S/V Pestilence, still from Hold Fast — Moxie Marlinspike / Anarchist Yacht Club, CC BY-NC-SA 3.0, via Internet Archive — https://archive.org/details/holdFastADocumentaryByMoxieMarlinspike
  2. Bag of bricks used as an anchor aboard S/V Pestilence, still from Hold Fast — Moxie Marlinspike / Anarchist Yacht Club, CC BY-NC-SA 3.0, via Internet Archive — https://archive.org/details/holdFastADocumentaryByMoxieMarlinspike
  3. Moxie Marlinspike, 2013 — Knight Foundation, CC BY-SA 2.0, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:Moxie_Marlinspike.jpg
  4. Black Hat Briefings, Las Vegas, 2005 — Alexander Marks, Public domain, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:Michael_Lynn_Black_Hat_Briefing_Las_Vegas_2005.jpg
  5. Double Ratchet diagram — Trevor Perrin and Moxie Marlinspike, Signal Double Ratchet specification, Public domain — https://signal.org/docs/specifications/doubleratchet/
  6. 36C3, Leipzig — SimonWaldherr, CC BY-SA 4.0, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:36c3_-_FairyDust_07.jpg
  7. Cellebrite UFED device — jon crel, CC BY 2.0, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:Ufed_mobile_phone_imaging_device_(8661348282).jpg
  8. Moxie Marlinspike at TechCrunch Disrupt SF 2017 — Max Morse for TechCrunch, CC BY 2.0, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:Moxie_Marlinspike_TC.jpg
  9. Moxie Marlinspike, 2022 (color) — Christopher Michel, CC BY-SA 4.0, via Wikimedia Commons — https://commons.wikimedia.org/wiki/File:Moxie_Marlinspike_in_2022_05.jpg

Moxie Marlinspike: The Anarchist Sailor Who Built Signal and Encrypted Billions of Chats was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Is Mobile Eating the PC? The MacBook Neo, the Googlebook, and the Laptop That Became a Phone]]> https://medium.com/the-low-end-disruptor/is-mobile-eating-the-pc-the-macbook-neo-the-googlebook-and-the-laptop-that-became-a-phone-4fdcf5c07fff?source=rss----16704e6008f5---4 https://medium.com/p/4fdcf5c07fff Thu, 08 Oct 2026 15:45:36 GMT 2026-10-08T15:45:36.548Z

For forty years we told ourselves a comforting story. There were real computers, and then there were phones.

Real computers were beige towers and heavy notebooks that hummed and blew hot air. They had sockets and slots, DIMMs you could pull out with your thumbs, graphics cards the size of a brick, and an x86 processor that could run software written before you were born. Phones were the little sibling. They were sealed and soldered, thermally starved, kept on a tight battery budget, and built around an ARM chip whose whole job was to sip power and stay cool in your pocket.

In 2026, that story died twice.

In March, Apple shipped the MacBook Neo, a $599 Mac whose processor is not a “laptop chip” at all. It is the A18 Pro, the exact chip that powered the iPhone 16 Pro in 2024. Apple’s own announcement called it “the first Mac powered by an iPhone chip”.

In October, Google shipped the Googlebook, a laptop line whose operating system is not ChromeOS. It is Android, the phone OS, rebuilt for the desktop.

Read those two sentences again. Apple took the phone’s chip and put it in a laptop. Google took the phone’s operating system and put it in a laptop. Two of the most powerful companies in computing, working independently, reached the same conclusion in the same year from opposite ends of the stack.

The question used to be “will phones replace PCs?” That was always the wrong question. The phone never had to replace the PC. It just had to become it.

This article traces how that happened: the two machines that finished the job, the forty-year convergence that led to them, and the silicon, memory, kernels, runtimes, translation layers, browser technology and market forces that made the result inevitable. The conclusion is not subtle. The PC has rewritten its own DNA, and the code it copied came from the smartphone.

Part I: The Two Bites

1.1 The MacBook Neo: The Phone’s Chip

Every Apple silicon Mac before March 2026 used an M-series chip: a processor designed for the Mac, even if it borrowed heavily from iPhone designs. The MacBook Neo broke that rule. It is the first Mac sold with an A-series chip. The only earlier exception was the 2020 Developer Transition Kit, a Mac mini with an iPad’s A12Z inside, which was never sold to the public.

The chip is the A18 Pro, which debuted in the iPhone 16 Pro. It is not a cousin or a derivative. It is the same chip, binned and reused:

That five-core GPU tells the whole story. Apple took A18 Pro dies from the iPhone production line, including ones with a single defective GPU core that could not go into a phone, and turned them into a Mac. The laptop is literally made from the phone’s leftovers.

And it works. On Geekbench 6, the MacBook Neo scores about 3,541 single-core and 8,958 multi-core. That beats the M1 MacBook Air on both counts, and the single-core number is close to the M4 MacBook Air, which scores about 3,680. Multi-core is a different story: two performance cores are no match for the M4’s four, and the M4 Air lands around 14,900. But for the browsing, documents, video calls and light creative work that most laptops actually do, a phone chip from 2024 is simply enough. Apple claims the Neo is up to 50% faster at web browsing and up to 3x faster at on-device AI than Windows laptops built on Intel’s Core Ultra 5.

The rest of the machine reads like a phone spec sheet stretched across 13 inches:

  • No fan. Where the MacBook Air uses a metal heat spreader, the Neo makes do with a graphene sheet. It throttles under sustained load, a little more noticeably than an M2 Air. One YouTuber added a copper plate and thermal pads and watched multi-core scores rise from 7,921 to 8,692; with external liquid cooling, the same chip reached 9,394. The chip is held back by its thermal envelope, not its design.
  • 8GB of unified memory, fixed. It cannot be upgraded or configured.
  • Phone-class battery thinking. A 36.5Wh battery gives up to 16 hours of video streaming.
  • Phone-class I/O. One 10Gbps USB-C port, one USB 2 port, a headphone jack, and support for a single external 4K display.
  • A phone price. It launched at $599 ($499 for education), less than a flagship iPhone.

Reviewers were almost unanimous. Fast Company’s Harry McCracken called it “one of Apple’s best recent products, even though its innovation is all about thoughtful cost control”. That line is the key to the whole machine. The innovation was not inventing a new chip. The innovation was realizing a new chip wasn’t needed. The phone chip was already good enough to be a PC.

1.2 The Googlebook: The Phone’s Operating System

To see how big Google’s break is, start with what it walked away from.

The Chromebook was a beautiful, stubborn idea: the computer is the cloud, and the laptop is just a window onto it. Machines like the Pixelbook Go, Google’s last first-party Chromebook, ran low-power 8th-Gen Intel Core m3, i5 or i7 chips with a modest 8GB to 16GB of RAM. ChromeOS was, at heart, a web browser sitting on a locked-down Linux kernel, designed to keep local background processes from ever slowing the machine down. The heavy lifting happened somewhere else, in a data center you would never see.

That philosophy is now dead. Google killed it on purpose.

The Googlebook opened for pre-order on September 21, 2026 and started shipping on October 4. Its operating system, Googlebook OS, developed under the internal codename Aluminium, is not ChromeOS with a new coat of paint. It is a desktop-optimized distribution of Android that has swallowed the consumer ChromeOS branch whole. ChromeOS Flex and the enterprise versions live on, but the consumer future belongs to Android. Underneath, every Googlebook runs the Android technology stack, while keeping the familiar parts of ChromeOS on top: the full desktop Chrome browser and a Linux terminal for developers. Google promises up to 10 years of system updates.

The first wave comes from five partners. Dell and Lenovo cut their prices just before launch, to $999 and $1,099:

The chip choices reveal the same pull toward the phone. The Intel models run Core Ultra Series 3 (Panther Lake), an x86 design that has adopted the phone’s heterogeneous core layout. The Qualcomm models run Snapdragon X Elite, built on the first generation of Qualcomm’s Oryon CPU cores. A second generation of the same Oryon family now powers Qualcomm’s flagship Android phone chip, the Snapdragon 8 Elite. And Google has named MediaTek, whose Dimensity brand is best known in smartphones, as a third chip partner, although its Dimensity CX C10 Max is so far only promised for a future Lenovo model. Every model pairs its CPU with an NPU rated at about 45 TOPS or more.

The integration with Android phones is deep. Settings, passwords and messages move over encrypted connections. Continue On picks up tasks from your phone right from the taskbar, and Cast My Apps streams individual phone apps into laptop windows. Android apps and games run natively. And at the center sits Gemini. The headline feature, “Magic Pointer,” lets you wiggle the cursor to summon Gemini, then select any text or image on screen and ask it to answer a question, compare items, add an event to your calendar, or check whether an email looks suspicious.

Strip away the keyboard and hinge, and the Googlebook is, architecturally and functionally, a very large Android phone.

Google spent fifteen years arguing that the laptop should be a dumb terminal. It has now concluded that the laptop should be a smartphone.

1.3 The Pincer: Apple Took the Silicon, Google Took the Software

Put the two machines side by side and you can see the shape of what happened.

Neither company set out to “merge” the phone and the PC. Each pulled the half of the phone it was best at. Apple, the best chip designer in consumer electronics, borrowed the silicon. Google, the owner of the world’s most-installed operating system, borrowed the software.

Together they form a pincer. Attack the PC from the bottom of the stack and from the top, and there is very little left in the middle that still belongs to the old PC.

But neither move came from nowhere. Both are the end of a forty-year convergence that sped up sharply after 2020.

Part II: How We Got Here

2.1 Forty Years in Nine Moves

The Separate Worlds (1981 to 2016)

The IBM PC of 1981 set the template that lasted four decades: an x86 processor, slotted memory, expansion cards, and an operating system that assumed unlimited power from the wall. The iPhone of 2007 set the opposite template: an ARM system-on-a-chip, soldered memory, a sealed case, and an operating system that treated every milliwatt as precious.

For years the two worlds only touched at the edges. The Chromebook borrowed the phone’s simplicity but kept x86 and leaned on the cloud. Samsung DeX (2017) let a Galaxy phone drive a full desktop monitor, a striking demo that never went mainstream.

The Silicon Turn (2020 to 2024)

Then Apple flipped the table. The M1 (2020) was built from the same CPU core designs as the iPhone 12’s A14, scaled up with more cores, more GPU and more memory. Overnight, the Mac became a very large iPhone system-on-a-chip.

Intel answered in 2021 with Alder Lake, which brought the phone’s big.LITTLE idea to x86: fast Performance cores and frugal Efficiency cores on one die. That idea has shaped every Intel laptop chip since, up to Panther Lake’s three tiers of cores in the 2026 Googlebooks.

By 2024, Apple’s M4, built on second-generation 3nm with 28 billion transistors, shipped as the same die in both the iPad Pro and the MacBook Air, differing only in how many cores each model enables. A tablet and a laptop now ran on the same chip. From there, putting a phone’s chip in a Mac was one short step.

Here is where the three lineages stand today: a phone chip, a tablet-and-laptop chip, and x86’s most mobile-minded design.

A chip designed for a phone sits in the same table as two laptop processors, and it belongs there. Note the bottom rows, too: every one of them carries a neural engine. NPUs landed in phones first, for photography, voice and face unlock. Laptops did not invent them. They inherited them.

Part III: Under the Hood

3.1 Inside the Pipeline: Why the Decoder Decided the War

How can a phone chip run a Mac? The answer lies in the processor’s front end, where instructions are fetched and decoded. This is where the war was settled.

x86 was born when memory was absurdly expensive, so its instructions were made dense and complex: anywhere from 1 to 15 bytes long, able to load, compute and store in one go. In 1978 that was a brilliant trade. In 2026 it is a tax that never stops being collected. Because instruction lengths vary, the core cannot even tell where one instruction ends and the next begins without real work. It has to speculatively decode across byte boundaries before it can produce the uniform micro-operations (µops) the back end executes. That burns power, makes heat and eats die area. Worse, if the decoder cannot keep up, the whole core starves: a world-class execution engine sits idle, waiting for the front end to find the last instruction boundary.

ARM took the opposite route: a fixed-length, reduced instruction set. Every instruction is the same width, so boundaries are known in advance and wide parallel decode is cheap, a matter of slicing the fetch block into equal pieces. That is what makes the very wide decoders in the A18 Pro and M4 performance cores practical. ARM’s load/store design and large register file also take pressure off memory bandwidth.

This is why the MacBook Neo is possible at all. Two A18 Pro performance cores, built for a phone’s power budget, come close to the M4 in single-threaded speed. Intel’s Panther Lake shows x86 can still be efficient, but it got there by borrowing the phone’s P-core and E-core layout, while still carrying decades of legacy compatibility that burns power and does nothing for the user. ARM’s efficiency was forged in a sealed glass slab with no fan and a battery the size of a cracker. That turned out to be exactly the right training ground for the thin-and-light laptop.

3.2 Memory: The Day the DIMM Slot Died

If you want a single place where mobile beat the PC, it is not the CPU. It is memory.

For most of PC history, a computer had two separate memory pools: DDR system RAM for the CPU and GDDR VRAM on the graphics card. Whenever the GPU needed data, it had to be copied out of system RAM, across the PCIe bus, and into VRAM. That copy tax added latency, stranded capacity in two pools that could not share, and burned power moving bytes back and forth.

Phones never paid it. With no room for two memory systems, they have always used unified memory: the CPU, GPU and NPU all share the same physical memory. Apple scaled that phone design up to the Mac, with on-package LPDDR5X delivering 120 GB/s on the base M4 and 546 GB/s on the full M4 Max. Panther Lake Googlebooks follow the same path with LPDDR5X-9600 at about 153 GB/s, and LPDDR itself is a mobile-born standard. The MacBook Neo is the purest case: its 8GB sits on the A18 Pro package exactly as it does in the iPhone 16 Pro, at 60 GB/s. There is nothing to upgrade, because memory is part of the chip.

This is the critical enabler of the AI PC. Large language models are brutally memory-bound. A 70-billion-parameter model at 4-bit quantization needs roughly 35 to 43GB for its weights. An NVIDIA RTX 5090, the most expensive consumer graphics card there is, is capped at 32GB of VRAM. A unified-memory Mac with 64GB or 128GB can hand roughly three-quarters of its pool to the GPU by default on high-memory models, and hold the whole model. A laptop with no discrete GPU runs what the flagship gaming card cannot fit. The Neo’s 8GB is built for small on-device models, not 70B ones, but it uses the same architecture, which scales from 8GB to 128GB without changing its nature.

The PC gave up slotted, upgradeable RAM for integrated, high-bandwidth unified memory. That is not a compromise. It is a surrender to smartphone design principles, and it was the right call.

3.3 Operating Systems: Mobile Took the Throne

Desktop operating systems were built for plenty: wall power, free-running background processes, sprawling file systems. Mobile operating systems were built for scarcity: strict sandboxing, aggressive battery management, and freezing anything the user is not looking at. Scarcity-first design has now conquered the desktop.

Start with the kernels. Android and Googlebook OS share Linux; iOS and macOS share Apple’s hybrid XNU kernel. The kernel inside your phone is the kernel inside your laptop. With the MacBook Neo, Apple goes further: the same chip runs the same kernel in the iPhone 16 Pro and the Mac, and Apple silicon Macs run iPhone and iPad apps natively wherever developers allow it.

The sharpest difference between the two camps is memory management, and the two 2026 machines show it in their spec sheets. Android runs apps on a runtime with garbage collection, which periodically scans memory for unused objects and needs a large pool of free RAM to avoid stutters. When that runs out, Android’s low-memory killer ends background apps. That is why the Pixel 9 ships with 12GB and the Pixel 9 Pro with 16GB, and why every Googlebook starts at 16GB.

Apple uses Automatic Reference Counting (ARC), which the compiler builds directly into Swift and Objective-C code. Objects are freed the instant nothing references them, with no scan, no pause and no big free buffer. On top of that, macOS compresses cold memory in place instead of paging it to disk. That is the hidden reason the MacBook Neo can ship with just 8GB, the same as the iPhone 16 Pro, and reviewers mostly found it adequate. Neither approach came from the desktop. Both were refined under the memory pressure of the smartphone.

The screen tells the same story. Googlebook OS draws its windows with SurfaceFlinger, Android’s compositor, not the X11 or Wayland stacks of the traditional Linux desktop. It was designed for smooth, tear-free touch interfaces on phones, and it is now being stretched to run overlapping desktop windows, seams and all.

3.4 The Translation Layer: Burying x86’s Past

Every architecture change leaves a ghost: legacy code compiled for the old world. In 2026, the revealing thing is which direction that ghost now points.

Rosetta 2 made Apple’s jump from Intel to ARM almost painless. It translates x86 apps to ARM ahead of time, and Apple went further by changing the silicon itself. x86 enforces a strict memory-ordering model called Total Store Ordering (TSO), which is very expensive to emulate in software. So Apple built hardware TSO support into its M-series chips, which switch into Intel-style memory ordering when running translated code. Translated apps run at close to native speed.

And now Apple is shutting it down. macOS 27 drops Intel Macs entirely and is the last release with general-purpose Rosetta 2; early reports say the installer even removes it by default. With macOS 28 in 2027, only a subset will remain for older, unmaintained games. The bridge back to x86 is being demolished.

The Googlebook faces the same ghost from the other direction. Most native Android apps are compiled for ARM. On the Snapdragon Googlebooks from Dell and HP, they run natively. On the Intel models from Acer, ASUS and Lenovo, they have to go through libhoudini, Intel’s ARM-to-x86 translator, which relies on just-in-time translation and brings overhead, battery drain and compatibility problems for complex apps and games. The x86 PC is now the one that needs a translator.

Put the two stories together: Apple is deleting its x86 compatibility, and Google’s x86 laptops have to emulate the phone. Either way, the phone’s instruction set is the reference now.

Part IV: Above the Hardware

4.1 The Universal Abstraction: WebAssembly and WebGPU

So far this has been a fight over silicon and kernels. But a deeper revolution is underway that makes the whole fight start to look beside the point. The browser has become a universal operating system, powered by two W3C technologies: WebAssembly (Wasm), a finished standard, and WebGPU, still a Candidate Recommendation but already shipping in Chrome, Edge, Firefox and Safari.

WebAssembly: Native Speed, Anywhere

WebAssembly is a low-level binary instruction format that runs in a sandboxed virtual machine inside the browser. Developers compile C++, Rust, Go and Kotlin to Wasm, and the browser runs it at near-native speed. Because Wasm skips JavaScript’s parse-and-optimize path, it can handle heavy CPU work such as cryptography, video editing and physics simulation entirely on the client.

The WebAssembly Component Model and the WebAssembly System Interface (WASI) push Wasm beyond the browser. WASI provides a secure, deny-by-default, standardized interface for reaching the host’s file system and network resources safely. The same Wasm module can run on an x86 Windows laptop, a cloud server or an ARM phone without being recompiled.

Read that again. Write once, run on any instruction set. The ARM vs. x86 war, fought so fiercely in the decoders, gets abstracted away one layer up.

WebGPU: The Graphics Card, Unlocked

WebGPU, the modern successor to WebGL, is a low-level graphics and compute API that gives web apps direct, platform-independent access to the GPU. Like Vulkan or Apple’s Metal, it offers explicit control over rendering pipelines and, crucially, compute shaders. That brings general-purpose GPU computing (GPGPU) into the browser, including AI inference and complex 3D rendering, with nothing to install.

The Combined Blow

Put them together and you get something genuinely disruptive. Route parallel work through WebGPU and complex serial logic through WebAssembly, and an app delivered by a single URL can rival a native desktop executable. Profiling shows Rust compiled to Wasm running at near-native microsecond latencies, while WebGPU sustains 60 frames per second with a small memory footprint.

For the Googlebook, which keeps the full desktop Chrome browser on top of Android, this is the bridge that lets a phone OS run serious desktop-class web software. For the MacBook Neo, it means a phone chip can run the same web apps as a workstation.

The OS becomes a launcher. The ISA becomes an implementation detail. The URL becomes the installer.

4.2 Cross-Platform Frameworks: The Native Divide Collapses

When the browser runs at native speed and compilers target every architecture, the line between mobile apps, web apps and desktop apps starts to disappear. A new generation of frameworks takes advantage of exactly that, aiming one codebase at every device at once.

Kotlin Multiplatform (KMP), from JetBrains, lets developers share business logic across Android, iOS, Windows, macOS and the web while keeping native performance. With Compose Multiplatform, they can now share up to 100% of their code, UI included, across every form factor. Think about what that means for the Googlebook. The army of mobile-first Kotlin developers, raised on Android, now targets the laptop by default. The PC’s developer base is being absorbed by the mobile one.

Flutter, Google’s Dart-based framework, goes further by skipping native UI toolkits entirely. It paints every pixel with its own high-performance rendering engine. An app looks identical on an iPhone, a Googlebook or an embedded IoT screen.

Add Uno Platform, which offers production-ready WebAssembly deployment and pixel-perfect Skia rendering across six platforms, and the case for bespoke, platform-specific desktop apps shrinks fast. Flutter’s Wasm output is heavily tuned for Chromium-based browsers, while Uno targets Wasm across Chrome, Edge, Firefox and Safari. Together they make the browser the most important deployment platform there is.

Part V: The Money

5.1 Market Dynamics: The AI PC Boom and Economic Reality

None of this is a technical curiosity. It is a massive economic shift, driven by demand for local AI and by turbulence in memory costs.

Gartner forecasts worldwide IT spending reaching $6.37 trillion in 2026, up 14.2%, driven by aggressive data center buildouts and a large hardware refresh cycle at the endpoint.

Inside that tide, the NPU has become the PC’s new reason to exist. Gartner defines an AI PC as a PC with an embedded NPU, covering Windows on ARM, macOS on ARM and x86 Windows machines. Googlebooks, every one of which ships with an NPU, fit the same mold. Shipments are projected to jump from 77 million units in 2025 to 143 million in 2026.

By the end of 2026, AI PCs are expected to make up 54.7% of the entire worldwide PC market and 58.7% of laptops. In three years the NPU went from novelty to majority. Gartner goes further and predicts that by 2026, AI laptops will be “the only choice of laptop available to large businesses,” up from less than 5% in 2023.

The engine of this adoption is local small language models (SLMs). Enterprises are moving away from cloud-only AI because of latency, rising API costs and serious data privacy concerns. Running SLMs on the device keeps data local and responses instant. By the end of 2026, Gartner expects 40% of software vendors to prioritize investment in AI capabilities directly on PCs, up from just 2% in 2024.

The Phone-Chip Price Weapon

The MacBook Neo shows what phone silicon does to PC economics. Apple already makes A18 Pro chips by the tens of millions for iPhones. Reusing them, including binned dies with a disabled GPU core, lets Apple sell a Mac at $599, with an NPU and a fanless aluminum body, below the price of most Windows AI laptops. The Googlebook, built on laptop chips, starts at $899. The cheapest AI PC in this fight is the one with a phone inside it.

The Paradox: ARM Wins the War, x86 Keeps the Territory

There is a twist. Despite ARM’s clear architectural edge, ARM PCs were projected to stay below roughly 13% market share through 2025. How?

Because x86 survived by becoming mobile. Intel adopted the phone’s design philosophy, with hybrid P-core and E-core layouts, low-power islands, integrated NPUs and on-package LPDDR5X, and in doing so blocked ARM’s most obvious path to total domination. Three of the five launch Googlebooks run Intel chips. ARM may not win the logo on the box. But the ideas inside the box are mobile through and through.

Meanwhile, an AI-driven DRAM and NAND shortage is squeezing the consumer market. Gartner estimates memory and SSD prices up about 130% and average PC prices up 17%, and forecasts 2026 PC shipments down 10.4%, with budget and consumer PCs hit hardest. Even the MacBook Neo was not immune. On June 25, 2026, Apple raised both Neo models by $100, to $699 and $799, blaming a memory-chip shortage driven by AI-server demand: “We have never seen a component price increase this much, this quickly”. The traditional bargain-bin PC is effectively disappearing, replaced by premium, highly integrated laptops built like phones. The cheap, modular, upgradeable PC is not being out-competed. It is being priced out of existence.

Conclusion: The Phone Didn’t Replace the PC, It Became It

So, is mobile eating the PC?

No. Mobile has already eaten it. We are just reading the obituary.

The proof is in two machines from 2026. The MacBook Neo runs on the A18 Pro, a chip designed for the iPhone 16 Pro, with a phone’s 8GB of memory and a phone’s fanless thermal design, and it does nearly everything most people need from a laptop. The Googlebook runs on Android, the operating system of more than three billion devices, with the Chrome browser and a Linux terminal layered on top. One took the phone’s body chemistry; the other took its mind.

They are the end point of a forty-year story. The IBM PC built a world of slots, sockets and x86. The iPhone built a parallel world of SoCs, ARM and scarcity. Then the parallel lines bent toward each other. The M1 carried iPhone cores into the Mac. Alder Lake carried the phone’s big.LITTLE design into x86. The M4 shipped unchanged in a tablet and a laptop. Panther Lake made three tiers of phone-style cores the top of Intel’s range. And in 2026 the lines finally met: a phone chip in a Mac, and a phone OS on a laptop.

Every layer tells the same story. The modern laptop’s defining traits were forged in the crucible of smartphone constraints: decode-efficient instruction pipelines, unified on-package LPDDR5X, dedicated neural engines, and a flat refusal to pay the PCIe copy tax. The operating systems followed, with memory managed by ARC and compression or by Android’s runtime, rendered by a phone’s compositor, and sandboxed like an app store. Apple is deleting its x86 bridge with macOS 27 and 28. Google’s Intel laptops need a translator to run the phone’s native code. And above it all, WebAssembly, WebGPU, Kotlin Multiplatform and Flutter mean developers write once and ship everywhere, so the underlying OS and instruction set are increasingly demoted to the role of hypervisor.

The PC as a distinct, unconstrained, modular computing paradigm is finished. In its place stands a synthesis no one quite planned: the desktop form factor, driven by the relentless, efficient, unified heartbeat of mobile architecture.

The phone did not replace the PC. Apple gave it the phone’s brain. Google gave it the phone’s soul. The phone became the PC.

References

  1. Why Google’s forgotten Pixelbook Go is still my favorite laptop in 2026, https://www.androidpolice.com/googles-forgotten-pixelbook-go-still-favorite-laptop-in-2026/
  2. REVIEW: Google Pixelbook Go in 2026 — Yes, Android … — YouTube, https://www.youtube.com/watch?v=FFXWDHdxNx8
  3. Googlebook OS — Wikipedia, https://en.wikipedia.org/wiki/Googlebook_OS
  4. Google confirms it’s ‘combining’ Chrome OS and Android … — Reddit, https://www.reddit.com/r/google/comments/1lzikpp/google_confirms_its_combining_chrome_os_and/
  5. Google’s new laptop OS is Android, ChromeOS and Linux mashed, https://www.notebookcheck.net/Google-s-new-laptop-OS-is-Android-ChromeOS-and-Linux-mashed-into-one.1404958.0.html
  6. Google to merge Chromebooks with Android — Adafruit Blog, https://blog.adafruit.com/2025/12/23/google-to-merge-chromebooks-with-android/
  7. Googlebook Launches with Intel Core Ultra Series 3 Processors, https://www.intel.com/content/www/us/en/newsroom/news/client-computing/googlebook-launches-with-intel-core-ultra-series-3-processors.html
  8. Pixel Laptop: Return of Google laptops confirmed with Googlebooks, https://www.notebookcheck.net/Pixel-Laptop-Return-of-Google-laptops-confirmed-with-Googlebooks-launching-this-fall.1294854.0.html
  9. The Googlebook era is here: some first impressions of the hardware, https://chromeunboxed.com/the-googlebook-era-is-here-some-first-impressions-of-the-hardware-and-a-whole-new-os/
  10. Introducing Googlebook, designed for Gemini Intelligence, https://blog.google/products-and-platforms/platforms/android/meet-googlebook/
  11. Googlebook Laptops, Designed for Gemini Intelligence — Google Store, https://store.google.com/category/laptops?hl=en-US
  12. Apple M4 — Wikipedia, https://en.wikipedia.org/wiki/Apple_M4
  13. Apple M4 (10 cores) Processor — Benchmarks and Specs, https://www.notebookcheck.net/Apple-M4-10-cores-Processor-Benchmarks-and-Specs.835975.0.html
  14. Apple introduces M4 chip, https://www.apple.com/newsroom/2024/05/apple-introduces-m4-chip/
  15. Panther Lake (microprocessor) — Wikipedia, https://en.wikipedia.org/wiki/Panther_Lake_(microprocessor)
  16. Intel Core Series 3 Processors for the Edge (codenamed Wildcat Lake), https://www.intel.com/content/www/us/en/content-details/917657/intel-core-series-3-processors-for-the-edge-codenamed-wildcat-lake-overview.html
  17. Intel Core Series 3 (Wildcat Lake) CPU at Hot Chips 2026, https://www.servethehome.com/intel-core-series-3-wildcat-lake-cpu-at-hot-chips-2026/
  18. The complete list of Intel Panther Lake laptops (Core Ultra X9 388H), https://www.ultrabookreview.com/74624-intel-panther-lake-laptops/
  19. Apple M4 chip AI performance explained — Mayhemcode, https://www.mayhemcode.com/2026/05/apple-m4-chip-ai-performance-explained.html
  20. ARM vs x86 Explained: What Every Developer Should Know — Medium, https://medium.com/@TechStoryLines/arm-vs-x86-explained-what-every-developer-should-know-f0a461603656
  21. Performance Debugging through Microarchitectural Sensitivity, https://arxiv.org/html/2412.13207v1
  22. Improving Instruction Fetch Efficiency via High-Level Program Map, https://arxiv.org/pdf/2406.06738
  23. Why Arm is more efficient than x86 — r/ElectricalEngineering, https://www.reddit.com/r/ElectricalEngineering/comments/1w3v6be/why_arm_is_more_efficient_than_x86/
  24. X86 vs ARM decoder impact in efficiency — r/hardware, https://www.reddit.com/r/hardware/comments/1i4a7b2/x86_vs_arm_decoder_impact_in_efficiency/
  25. Pipeline overview — Cortex-M85 — Arm Developer, https://support.arm.com/documentation/107950/0100/Overview/Pipeline-overview
  26. Introducing the Arm-membench Throughput Benchmark — arXiv, https://arxiv.org/html/2504.06813v1
  27. Apple Unified Memory vs RTX GPUs For LLMs — Mayhemcode, https://www.mayhemcode.com/2026/06/apple-unified-memory-vs-rtx-gpus-for.html
  28. What is LPDDR Memory and Unified Memory — SabrePC Blog, https://www.sabrepc.com/blog/computer-hardware/what-is-lpddr-memory-and-unified-memory
  29. What are the RAM specifications for the M4 MacBook? — Apple Community, https://discussions.apple.com/thread/255888747
  30. LPDDR5X Vs LPDDR5: Data Rate, Latency And Power Efficiency, https://eureka.patsnap.com/report-lpddr5x-vs-lpddr5-data-rate-latency-and-power-efficiency
  31. Microkernel vs. Monolithic Kernel — GeeksforGeeks, https://www.geeksforgeeks.org/operating-systems/difference-between-microkernel-and-monolithic-kernel/
  32. Research paper: microkernel vs monolithic kernel — ResearchGate, https://www.researchgate.net/publication/385879846_Research_paper_microkernel_vs_monolithic_kernel
  33. Why M1 Macs are more efficient with memory — Hacker News, https://news.ycombinator.com/item?id=25204401
  34. Does Android use more memory than iOS? — Android Authority, https://www.androidauthority.com/android-ios-ram-memory-usage-744848/
  35. Android vs iOS RAM management — Who does it better? — r/Android, https://www.reddit.com/r/Android/comments/smqger/android_vs_ios_ram_management_who_does_it_better/
  36. ARM MTE Performance in Practice (Extended Version) — arXiv, https://arxiv.org/html/2601.11786v1
  37. SurfaceFlinger and WindowManager — Android Open Source Project, https://source.android.com/docs/core/graphics/surfaceflinger-windowmanager
  38. Windowing system — Wikipedia, https://en.wikipedia.org/wiki/Windowing_system
  39. Google (or Googlebook) has desktop OS problem — r/google_book, https://www.reddit.com/r/google_book/comments/1tqeerb/googleor_googlebook_has_desktopos_problem/
  40. Support 64-bit architectures — Android Developers, https://developer.android.com/google/play/requirements/64-bit
  41. Google says the vast majority of Android apps run fine on … — r/Android, https://www.reddit.com/r/Android/comments/1wy8fu7/google_says_the_vast_majority_of_android_apps_run/
  42. Technical discussion on ARM translation — Hacker News, https://news.ycombinator.com/item?id=11733050
  43. Frida-server on Android x86 running libhoudini.so — GitHub, https://github.com/frida/frida/issues/1567
  44. ChromeOsAbiSupport: Missing ABI Support for ChromeOS, https://googlesamples.github.io/android-custom-lint-rules/checks/ChromeOsAbiSupport.md.html
  45. Why is Rosetta 2 fast? — dougallj, https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/
  46. Rosetta 2 on a Mac with Apple silicon — Apple Platform Security, https://support.apple.com/zh-hans/guide/security-pdf/secebb113be1/web
  47. Rosetta 2 hardware acceleration discussion — Hacker News, https://news.ycombinator.com/item?id=45738816
  48. How x86 to arm64 Translation Works in Rosetta 2 — InfoQ, https://www.infoq.com/news/2020/11/rosetta-2-translation/
  49. WebAssembly and WebGPU: High-Performance Computing on the Web — Medium, https://tianyaschool.medium.com/webassembly-and-webgpu-high-performance-computing-on-the-web-a1a389a9f392
  50. WebAssembly: A new development paradigm for the web — YouTube, https://www.youtube.com/watch?v=RcHER-3gFXI
  51. Kotlin/Wasm — Kotlin Documentation, https://kotlinlang.org/docs/wasm-overview.html
  52. Is the Web Browser the Most Important Platform for App Development? — DEV, https://dev.to/uno-platform/is-the-web-browser-the-most-important-platform-for-app-development-19el
  53. What’s Up With WebAssembly: Compute’s Next Paradigm Shift — Sapphire Ventures, https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/
  54. WebGPU Paradigm Shift — YouTube, https://www.youtube.com/watch?v=ESAanme_AmE
  55. WebAssembly and WebGPU for High-Performance Web and Mobile Apps — Krify, https://krify.com/the-use-of-web-assembly-wasm-and-web-gpu-for-high-performance-web-and-mobile-apps/
  56. The Seven Most Popular Cross-Platform App Development Frameworks — Kotlin, https://kotlinlang.org/docs/multiplatform/cross-platform-frameworks.html
  57. Top Cross-Platform App Development Frameworks in 2026 — Bolder Apps, https://www.bolderapps.com/blog-posts/top-cross-platform-app-development-frameworks-in-2026
  58. 5 Best Cross Platform Frameworks for App Dev in 2026 — Uno Platform, https://platform.uno/articles/best-cross-platform-frameworks-2026/
  59. Gartner Forecasts Worldwide IT Spending to Grow 14.2% in 2026, https://www.gartner.com/en/newsroom/press-releases/2026-07-27-gartner-forecasts-worldwide-it-spending-to-grow-14-point-2-percent-in-2026-totaling-6-point-37-trillion
  60. Gartner Says AI PCs Will Represent 31% of Worldwide PC Market by the End of 2025, https://www.gartner.com/en/newsroom/press-releases/2025-08-28-gartner-says-artificial-intelligence-pcs-will-represent-31-percent-of-worldwide-pc-market-by-the-end-of-2025
  61. Gartner Forecasts Worldwide Shipments of AI PCs to Account for 43% of All PCs in 2025, https://www.gartner.com/en/newsroom/press-releases/2024-09-25-gartner-forecasts-worldwide-shipments-of-artificial-intelligence-pcs-to-account-for-43-percent-of-all-pcs-in-2025
  62. 2025 will see AI PCs become the new normal, but Arm-based PCs will not grow out of their minority segment — ABI Research, https://abiresearch.com/press/2025-will-see-ai-pcs-become-the-new-normal-but-arm-based-pcs-will-not-grow-out-of-its-minority-segment
  63. MacBook Neo — Wikipedia, https://en.wikipedia.org/wiki/MacBook_Neo
  64. MacBook Neo is official for $599: specs, colors and latest news — Tom’s Guide, https://www.tomsguide.com/computing/macbooks/macbook-neo-is-official-for-usd599-specs-colors-and-latest-news
  65. MacBook Neo arrives with A18 Pro chip, $599 starting price — GSMArena, https://m.gsmarena.com/macbook_neo_arrives_with_a18_pro_chip_599_starting_price-amp-71808.php
  66. MacBook Neo Review — MacRumors, https://macrumors.com/review/macbook-neo/
  67. First benchmarks for MacBook Neo and MacBook Pro 2026 — heise online, https://www.heise.de/en/news/First-benchmarks-for-MacBook-Neo-and-MacBook-Pro-2026-11202089.html
  68. Apple MacBook Neo Long-Term Review: 27 Days On The Road — HotHardware, https://hothardware.com/reviews/apple-macbook-neo-review?page=2
  69. MacBook Neo cooling mod: massive temperature drop and FPS boost — HotHardware, https://hothardware.com/news/macbook-neo-cooling-mod-massive-temp-drop-fps-boost
  70. Googlebook Pre-Orders Open: Five First-Wave Laptops, Prices and Specs Compared — PBX Science, https://pbxscience.com/googlebook-pre-orders-open-five-first-wave-laptops-prices-and-specs-compared/
  71. Googlebook pre-orders finally have a date — Android Central, https://www.androidcentral.com/chromebooks-laptops/googlebook-pre-orders-begin-sept-21
  72. Google Opens Googlebook Pre-Orders at $899 With 5 Laptops — Cyber Kendra, https://www.cyberkendra.com/2026/09/googlebook-price-specs-os.html
  73. Googlebook Supports Intel, Qualcomm, and MediaTek Chips — Let’s Data Science, https://letsdatascience.com/news/googlebook-supports-intel-qualcomm-and-mediatek-chips-2525f6c5
  74. Apple announces $599 MacBook Neo powered by the A18 Pro chip — MacTrast, https://www.mactrast.com/2026/03/apple-announces-599-macbook-neo-powered-by-the-a18-pro-chip/
  75. How and when macOS will finally stop support for Intel apps — AppleInsider, https://appleinsider.com/articles/26/06/12/how-and-when-macos-will-finally-stop-support-for-intel-apps
  76. DIY water-cooled MacBook Neo just got a 23% performance bump — Yanko Design, https://www.yankodesign.com/2026/03/29/diy-water-cooled-macbook-neo-just-got-a-23-performance-bump-heres-how/
  77. MacBook Neo review — Fast Company, https://www.fastcompany.com/91505188/macbook-neo-review
  78. Apple just raised MacBook Neo prices — MacRumors, https://macrumors.com/2026/06/25/apple-just-raised-macbook-neo-prices/
  79. Say hello to MacBook Neo — Apple Newsroom, https://www.apple.com/newsroom/2026/03/say-hello-to-macbook-neo/
  80. WebGPU — W3C Candidate Recommendation Draft, https://www.w3.org/TR/webgpu/
  81. Memory crunch will slash PC shipments as vendors raise prices: Gartner — Computing, https://www.computing.co.uk/news-network/2026/memory-crunch-will-slash-pc-shipments-as-vendors-raise-prices-gartner
  82. recommendedMaxWorkingSetSize — Apple Developer Documentation, https://developer.apple.com/documentation/metal/mtldevice/recommendedmaxworkingsetsize
  83. Dell’s XPS Googlebook Starts at $999 With Android Sync — Technobezz, https://www.technobezz.com/news/dell-xps-googlebook-999-android-sync
  84. Lenovo Googlebook 15 price — 9to5Google, https://9to5google.com/2026/09/28/lenovo-googlebook-price/
  85. Googlebook: built-in intelligence — Google Blog, https://blog.google/products-and-platforms/devices/googlebook/googlebook-built-in-intelligence/
  86. Googlebook puts your Android phone closer to the laptop screen — The Gadgeteer, https://the-gadgeteer.com/2026/09/23/googlebook-puts-your-android-phone-closer-to-the-laptop-screen/

Image Credits

Is Mobile Eating the PC? The MacBook Neo, the Googlebook, and the Laptop That Became a Phone was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[OpenSSH Ships on Every Mac, Linux Server and Windows PC. Its Creator Trusts No One.]]> https://medium.com/the-low-end-disruptor/openssh-ships-on-every-mac-linux-server-and-windows-pc-its-creator-trusts-no-one-c06e3f3e1cb5?source=rss----16704e6008f5---4 https://medium.com/p/c06e3f3e1cb5 Mon, 05 Oct 2026 20:55:11 GMT 2026-10-05T20:55:11.809Z OpenSSH creator Theo de Raadt was pushed out of NetBSD, lost a DARPA grant and fought half of open source. Now his paranoid code guards the world’s servers.

I. Half a Second

Until the last days of March 2024, almost nobody outside a small circle of programmers had heard of liblzma. It was a compression library, a piece of plumbing buried deep in Linux, and for two years someone had been preparing to use it to walk through the front door of the internet.

He called himself Jia Tan. He was patient. He wrote helpful patches. He was polite to an exhausted volunteer maintainer, and useful, and always there, and in time he was given the keys. Then he began to build. The payload went into the release tarballs in pieces, obfuscated and disguised as test files. It was aimed at OpenSSH, the program that guards remote access to nearly every server on Earth. Once the code shipped in the stable releases of the major Linux distributions, whoever held the private key could let himself into a large share of the world’s machines.

It nearly worked. What stopped it was half a second.

Andres Freund, an engineer at Microsoft, noticed that SSH logins on his Debian test machine were burning about five hundred milliseconds more CPU than they should. Most people would have let it go. Freund didn’t. He followed the delay down through the SSH daemon, through systemd, and into liblzma, and at the bottom he found the backdoor.

He posted the disclosure to the oss-security list on March 29. Within hours the Linux world was doing triage. Red Hat issued an urgent advisory. Debian rolled back. At banks, cloud providers and hospital networks, engineers were pulled out of bed to tear open their build pipelines. They were all asking the same question: are we exposed?

The city of Calgary sits on the high plains of southern Alberta, where the prairie runs flat to the east and the Rockies stand to the west like a wall. In winter the cold comes down hard and stays. Sometimes a wind called the Chinook pours off the mountains, warm and dry, and lifts the temperature twenty degrees in an afternoon. Snowbanks rot to slush by dark. Locals say the Chinook brings migraines and short tempers, and that dogs won’t settle while it blows. It arrives without warning, and nobody asks for it.

Here, one operating system was not asking.

OpenBSD had never been in the blast radius. The attack depended on a chain. Linux distributions had patched their SSH daemons to talk to systemd, systemd pulled in liblzma, and liblzma carried the poison into the daemon’s memory. OpenBSD had never let systemd in. It had never tied that dependency to its most sensitive process. For nearly a decade it had wrapped its programs in restraints called pledge and unveil. Under those rules, a program that reached for anything it hadn’t declared in advance was killed by the kernel.

Nine years earlier, at a conference in Quebec, the man who built that system had stood before a room and named the danger. He didn’t speak of compressors in general. He named this one. “Especially with compressors like XZ,” he said, “which had 2 memory system vulnerabilities in the last year…”

Nobody had taken much notice at the time.

His name is Theo de Raadt. He has called Richard Stallman “a lying cheating hypocrite” and called Linux “garbage.” The first project he helped found threw him out. A single sentence to a newspaper cost him a million dollars of Pentagon money. And his code is almost certainly running on the machines that hold your bank balance, your medical records and the servers that delivered this page. He lives far from the centers of the technology industry, in a city known for cattle and oil. He trusts almost no one. That is why so many others can afford to trust.

II. The Boy Who Left Before the Army Came

It begins with a departure.

Pretoria, South Africa, 1977. Soweto burned the year before. The apartheid state is at war with its own people and its neighbors, and every white boy in the country has a date waiting in his future: two years of compulsory service in that army. Theo de Raadt was born on May 19, 1968. He is the eldest of four children of a Dutch father and a South African mother. He is nine, so the draft is still a decade away. The family doesn’t wait.

In November 1977 they leave for Calgary. It is the boy’s first lesson in security, and the oldest one. When the system is rotten, you don’t negotiate with it. You leave.

A boy from the Highveld steps off a plane into a prairie November, into a cold that hurts your teeth under a white, enormous sky. He learns it. In 1983 the ground moves again. Canada falls into its worst recession since the Depression, the Alberta oil economy collapses, and the family relocates for a time to the Yukon, where caribou outnumber people and the winter light lasts only a few hours.

By then he has a computer. It is a Commodore VIC-20, a wedge of beige plastic with five kilobytes of memory that plugs into a television. It speaks BASIC and, for the serious, 6502 machine code. It forgives nothing. There is no internet to ask and no one to call. There is the manual and the cursor. If you get one byte wrong the machine locks up, and you start again.

An Amiga comes later. But the VIC-20 is the one that counts. The family has been uprooted twice. The country is still foreign, and the land outside is as hard and clean as a sheet of ice. Economies collapse and people fail you, but the machine is exact. Understand it down to the last register and it will never betray you.

For a boy teaching himself to program alone in the northern dark, correctness isn’t a matter of taste. It is shelter.

He returns to Calgary and finishes a Bachelor of Science in Computer Science at the University of Calgary in 1992. He is twenty-four and brilliant. He hasn’t yet learned that most people don’t care about correctness the way he does.

III. Exile

In 1993 the free Unix world is a frontier town. AT&T and Berkeley are fighting in court over who owns the code. Linus Torvalds is a Finnish student with a hobby kernel. A few hackers scattered across the continent are trying to turn 386BSD, a free Unix for the cheap Intel PC, into something that actually works. It isn’t working well enough, and it’s run too loosely. Four of them break away: Chris Demetriou, Adam Glass, Charles Hannum and Theo de Raadt. They call their project NetBSD.

De Raadt pours himself into it. With Chuck Cranor he builds the Sun SPARC port, and he writes code in quantities that are hard to account for. When NetBSD 1.0 ships in October 1994, it is the project’s first multi-platform release. Much of that portability has his fingerprints on it.

Then there are the mailing lists.

On a mailing list, de Raadt is a blowtorch. A user asks a naïve question and gets flayed. A developer sends a patch he considers sloppy, and it comes back stripped to the bone. He is usually right, which makes it worse. He is right in a way that leaves people bleeding, and he doesn’t seem to see the blood. Or he sees it and doesn’t think it matters next to whether the code is correct.

The hacker culture of 1994 will forgive almost anything if the code is good. Almost. De Raadt finds the limit and goes past it.

On December 20, 1994, five days before Christmas, the rest of the NetBSD core team revokes his access to the source repository. The project has locked out one of its own founders.

Three days later Adam Glass writes to the netbsd-users list:

“This was a very difficult decision to make, and resulted from Theo’s long history of rudeness towards and abuse of users and developers of NetBSD. We believe that there is no place for that type of behaviour from representatives of the NetBSD Project, and that, overall, it has been damaging to the project.”

Glass concedes that de Raadt was the “principal caretaker of NetBSD’s SPARC support, and has written too much code to mention.” That changes nothing. He is out.

Years later Charles Hannum looks back on it. “It’s widely claimed that I’m ‘the one’ who ejected Theo from the NetBSD community. That is false,” he says. “At that time in NetBSD’s history, Chris G. Demetriou was playing the role of alpha male, and I wasn’t even given a choice. I was certain it was going to bite us in the ass. I think the question for historians is not whether it did bite us in the ass, but how many times and how hard.”

The writer Peter Wayner, in Free for All, puts it mildly: de Raadt’s “excessive directness” rubbed people the wrong way. From the inside it must have looked different. He had already lost one country before it could conscript him and lost his footing in another when its economy collapsed. Now the one place he had built with his own hands had voted him out, in writing, in public. They let him build it, and then they took it away.

Another man might have gone quiet after that.

De Raadt made a rule instead. He would never again build anything whose keys another person could take from him.

IV. Year Zero

October 1995, in Calgary. De Raadt takes the NetBSD source, the same code he’d been locked out of, and forks it. The license permits it, so no one can stop him. He calls the new project OpenBSD.

This time there is no core team with the power to remove him. There is one leader. Releases come every six months, on schedule, and each is supported for a year and then retired. The code is audited constantly, line by line across the whole tree. When one bug is found, the team hunts down every other instance of that kind of mistake. Features come second. So do performance, hardware support and feelings. Only one question matters: can this be broken?

The mascot is a pufferfish called Puffy. It looks cute enough for a T-shirt, but a pufferfish survives by swelling into a ball of spines and being poisonous. No software project has chosen a more honest emblem.

Early on, a Calgary security firm called Secure Networks, later absorbed by McAfee, gets in touch. It is building a network auditing tool called Ballista. The collaboration gives OpenBSD a doctrine, proactive security. You don’t wait for the burglar to break the window. You assume he is already in the yard with his hand on the glass.

OpenBSD turns paranoia into an engineering method. All code is assumed guilty. All networks are hostile. Every programmer will make mistakes, the project’s own included, so the system has to survive them. When something looks wrong, the program dies at once and loudly, because a crash can be recovered from and a compromise may not be. The default install turns almost nothing on, so that newcomers, in the project’s words, need not “become security experts overnight.”

Then de Raadt puts a boast on the front page of the website, where every attacker on Earth can read it:

“Five years without a remote hole in the default install!”

It holds for years. Across the industry, patches for commercial systems arrive every month like clockwork. In Alberta, a volunteer project goes on daring anyone to break in.

In June 2002, Mark Dowd of Internet Security Systems finds a flaw in OpenSSH’s challenge-response authentication. De Raadt changes the slogan in public: “One remote hole in the default install, in nearly 6 years!” In 2007, Alfredo Ortega finds a second hole, in the network stack. The slogan changes again:

“Only two remote holes in the default install, in a heck of a long time!”

That is two remote holes in more than a decade. The people who called him paranoid have their answer.

V. The Padlock

Until the mid-1990s, the internet ran unencrypted.

System administrators logged into remote machines with Telnet or rlogin. Every keystroke crossed the wire in cleartext, including usernames, passwords and root passwords. Anyone on the network with a card in promiscuous mode could read them. In February 1994, CERT advisory CA-94:01 described intruders who had quietly collected login credentials for tens of thousands of systems.

In 1995, Tatu Ylönen, a researcher at the Helsinki University of Technology, wrote the Secure Shell. It encrypted the session and verified the server with cryptographic keys. He released it free, and by the end of the year it had twenty thousand users in fifty countries. Then he founded a company, SSH Communications Security, and the license began to tighten. By 1999 new versions carried commercial restrictions, and companies were being directed to a firm called Datafellows to buy one.

For de Raadt, this was intolerable. The internet’s most important security tool was being walled off, and a company would hold the keys to everyone’s front door.

The OpenBSD developers found an old version of Ylönen’s code, 1.2.12, that was still under a free license. A Swedish programmer named Björn Grönvall had been maintaining it under the name OSSH. It spoke only the old 1.3 protocol, but they could take it. OpenBSD 2.6 was due to ship in less than two months. De Raadt decided it would ship with an SSH that was entirely free.

The work went fast. From Calgary, de Raadt cut out convoluted and non-portable code so that nothing could hide in it. Niels Provos, a German living in the United States, drove up to Canada again and again to work at his side, stripping out restricted cryptography and GPL-licensed code and replacing it with freely reusable libraries such as OpenSSL. In Germany, Markus Friedl rewrote the protocol support, first for SSH 1.5 and later for SSH 2.0 and SFTP. Dug Song, Aaron Campbell and Bob Beck filled the gaps. They had no office and no investors, only a deadline they had set themselves and would not move.

On December 1, 1999, OpenBSD 2.6 shipped with OpenSSH 1.2.2.

What happened next was never part of de Raadt’s plan. Damien Miller and Philip Hands ported the code to Linux and other Unix systems, creating the “portable” version and leaving OpenBSD’s core untouched. The code was free. The paranoid team had audited it. The RSA patent would expire in the United States in September 2000. So everyone took it. It went into Linux, Solaris, AIX and macOS, and into millions of routers, firewalls and appliances. By 2008 a survey found it on more than 80 percent of SSH servers. Estimates today run higher.

A man who had been thrown out of his own project had built a fortress for himself and a few like-minded paranoiacs. He had ended up making the lock the whole world uses. Bank transfers pass through it. An administrator patching a hospital database at three in the morning logs in with it. Cloud platforms are run through it. He built it to keep the world out, and the world moved in.

The industry built fortunes on it. In 2004, accepting an award from the Free Software Foundation, de Raadt gave an accounting of the thanks: the hardware vendors who used OpenSSH in all their products had given the project “a total of one laptop” in five years. “And asking them for that laptop took a year. That was IBM.”

VI. Half a Cruise Missile

At the University of Pennsylvania, Jonathan Smith of the Distributed Systems Laboratory ran a project called POSSE, Portable Open Source Security Elements. It had won a $2.125 million grant from DARPA, the Pentagon’s research agency and the builder of the original ARPANET. The government wanted hardened, open security software for its own computers, and it chose OpenBSD, calling it “the computing world’s most secure forum for the development of open-source software.” About $1 million of the grant went to de Raadt’s project.

The project had lived on donations and on sales of CD-ROMs and T-shirts, so the money meant survival. It could pay for hardware and hackathons and let developers work full-time.

In March 2003 the United States invaded Iraq. Tomahawk missiles rose off warships in the Persian Gulf and the Red Sea, trailing white fire across the night, and the images went around the world.

In April a reporter from the Globe and Mail called de Raadt and asked how he felt about taking military money.

With a million dollars at stake, the expected answer was gratitude, something about the work benefiting everyone, and then silence.

De Raadt said this:

“I actually am fairly uncomfortable about it, even if our firm stipulation was that they cannot tell us what to do. We are simply doing what we do anyways — securing software — and they have no say in the matter. I try to convince myself that our grant means a half of a cruise missile doesn’t get built.”

Within days DARPA cut off the funding. Smith said military officials had been uncomfortable with the OpenBSD leader’s anti-war remarks. The million dollars was gone.

A more practical man would have called the Pentagon the next morning to apologize and say he had been quoted out of context. De Raadt did not retract anything. He would not put a closed, unaudited binary in his kernel, and he would not put an unaudited opinion in his mouth either. His independence was part of the security model. If someone else’s money could decide what he said, it could decide what he shipped.

The project scrambled and survived, poorer than before.

VII. Nasty Things

If he would do that to the Pentagon, his peers could expect no better.

He saw Linux, the corporate-backed system that had taken over the server market, as everything wrong with software. It put features, hardware support and market share first and treated security as an afterthought. In 2005, Forbes ran an interview headlined “Is Linux For Losers?” and de Raadt said:

“It’s terrible, everyone is using it, and they don’t realize how bad it is. And the Linux people will just stick with it and add to it rather than stepping back and saying, ‘This is garbage and we should fix it.’”

Linus Torvalds answered in kind. On the Linux kernel mailing list in 2008 he called the OpenBSD crowd “a bunch of masturbating monkeys,” because they made such a big deal of security that they “pretty much admit that nothing else matters to them.” He meant it as an insult. In Calgary it read as a fair description.

Then there were the blobs. Modern Wi-Fi chips, GPUs and network cards often work only with secret firmware, called a “binary blob,” which is loaded into the device and given high privileges without anyone outside the vendor seeing what it does. Linux mostly accepts these blobs so that laptops can connect to the coffee-shop Wi-Fi.

De Raadt refused. To him a blob was a stranger handed the key to the vault with no identification. It might contain a bug or a backdoor, and there was no way to tell, because no one was allowed to look. So he went after the hardware vendors in public, by name, demanding documentation.

At a conference in Melbourne, an HP executive warned him: “If you say nasty things like that to vendors you’re not going to get anything.”

De Raadt replied:

“No, in eight years of saying nothing, we’ve got nothing, and I’m going to start saying nasty things, in the hope that some of these vendors will start giving me money so I’ll shut up.”

The shaming worked. Several major Taiwanese wireless chipmakers opened their documentation. Free drivers followed, for OpenBSD and for every other open system, Linux included. The man everyone called impossible got what polite people had been requesting for years. Almost nobody thanked him.

Then there was Richard Stallman, founder of the Free Software Foundation and author of the GPL. Its copyleft terms require anyone who builds on the code to keep their own work free as well. De Raadt considered that a leash dressed up as freedom. OpenBSD used permissive licenses, ISC and BSD, which let anyone, corporations included, use the code for anything. That is how OpenSSH ended up everywhere. To de Raadt, that was freedom. The GPL was somebody else’s rules.

In December 2007, on the openbsd-misc mailing list, Stallman accused OpenBSD of steering users toward non-free software through its ports tree. De Raadt explained, with rising heat, that the ports tree contained only Makefiles and URLs and none of the non-free software itself. Stallman didn’t back down. De Raadt wrote:

“…you are being the usual slimy hypocritical asshole… You may have had value ten years ago, but people will see that you don’t anymore… Richard, you are a lying cheating hypocrite.”

Hardly anyone speaks to Stallman that way, in public or otherwise. De Raadt does, because nothing stands between what he believes and what he types. It is the same trait that kept him from lying to the Globe and Mail and keeps him from shipping a blob. His honesty isn’t aimed at anyone in particular. It points in every direction, like the spines on a pufferfish.

VIII. The Letter

In December 2010 an email arrived without warning.

It came from Gregory Perry, former chief technology officer of NETSEC, a now-defunct government contractor, and once a technical consultant to the FBI. His non-disclosure agreement had expired, he wrote. Ten years earlier, he said, the FBI had paid NETSEC developers to plant backdoors and “side channel key leaking mechanisms” in the OpenBSD Cryptographic Framework and the IPsec stack, the code that secures VPNs. The aim was to monitor encrypted site-to-site traffic. He named two people, Jason Wright and Angelos Keromytis, as having been connected to NETSEC while the IPsec code was written.

For fifteen years the project had told the world it could be trusted because it trusted no one. Now it was accused of carrying a government backdoor.

An ordinary organization would have hired lawyers, opened a quiet internal review, drafted a holding statement and hoped the story never got out.

On December 14, 2010, de Raadt forwarded Perry’s email, complete, to the public openbsd-tech mailing list.

“I refuse,” he wrote, “to become part of such a conspiracy.”

The accusation was aimed at the fortress, so he opened every gate and invited every cryptographer in the world to come and search it.

Wright and Keromytis denied it. “I will state clearly that I did not add backdoors to the OpenBSD operating system,” Wright wrote, and demanded an apology. The audit found real bugs from that period, including a “CBC oracle problem” in the software crypto stack, but no confirmed backdoor. De Raadt stayed suspicious. “I believe that NetSec was probably contracted to write backdoors as alleged,” he said. “If those were written, I don’t believe they made it into our tree. They might have been deployed as their own product.”

The allegation may have been true, a grudge, or a ghost story from the paranoid decade after 9/11. What mattered was the response. When the fortress was accused, it opened wider. It was safe not because anyone promised it was, but because anyone could read every line and check.

IX. Valhalla

In April 2014 the internet began to bleed.

Heartbleed, CVE-2014–0160, was a flaw in OpenSSL, the library behind the padlock icon on most encrypted web traffic. An attacker anywhere could send a malformed “heartbeat” message and read back pieces of a server’s memory, which might contain passwords, session cookies or the server’s private keys. The flaw had been in the code for two years, and a large share of the web was exposed.

Open source had long reassured itself with Eric S. Raymond’s line that “given enough eyeballs, all bugs are shallow.” De Raadt had always thought that was sentimental. “My favorite part of the ‘many eyes’ argument,” he had said, “is how few bugs were found by the two eyes of Eric.”

Then the facts came out. The library protecting the world’s credit card numbers was maintained by a small, exhausted team living on roughly $2,000 a year in donations. The code was a swamp. It was full of support for dead operating systems, and its custom memory wrappers defeated the very tools that might have caught the bug.

De Raadt didn’t file a bug report. The OpenBSD team forked OpenSSL and called the fork LibreSSL.

What followed was a purge. The developers logged it on a blog called the “OpenSSL Valhalla Rampage.” In the first week they cut more than 90,000 lines of C and some 150,000 lines of content in all. Support for Classic Mac OS, NetWare, OS/2, 16-bit Windows and VMS went. The custom memory wrappers were torn out and replaced with standard library calls.

“Some of that is indentation, because we are trying to make the code more comprehensible,” de Raadt said. “99.99% of the community does not care for VMS support, and 98% do not care for Windows support… Code must be simple.”

When more OpenSSL bugs were disclosed that June, he accused the OpenSSL team of deliberately leaving LibreSSL out of the advance warning. The break was complete. It was the same pattern as OpenBSD after NetBSD and OpenSSH after SSH Communications. When he was handed something rotten, he didn’t negotiate. He forked it, gutted it and built a new wall.

X. The Walls Within the Walls

Most people never see OpenBSD itself. What reaches them are its ideas, which tend to leave Calgary and turn up years later, often uncredited, in other operating systems.

In 2011, with Mac OS X Lion, Apple began retiring its old firewall in favor of PF, OpenBSD’s packet filter, which reached it by way of FreeBSD. PF has shipped on every Mac since. In 2018 Microsoft, whose monthly security patches had long made OpenBSD’s boast look good, built OpenSSH into Windows 10. With Windows Server 2025 it comes installed by default. The lock made in Calgary now ships with Windows itself.

The principle behind these ideas is simple: complexity is the enemy of security. Programmers will make mistakes, especially in C. So you build walls inside the walls, to keep a mistake in one room from burning down the house.

  • strlcpy and strlcat (1999). C’s standard string-copying functions produced buffer overflows constantly. Todd C. Miller and de Raadt presented safer replacements at USENIX that always terminate the string and always know how big the destination is. Ulrich Drepper, the maintainer of glibc, kept them out of Linux’s C library for years. FreeBSD, macOS and Solaris adopted them. In July 2023, twenty-four years after the USENIX paper, glibc 2.38 added them without ceremony. In 2024 POSIX made them part of the standard.
  • Privilege separation. Niels Provos built it into OpenSSH. The daemon splits in two. A small privileged monitor holds the keys, and a larger unprivileged process handles the network. An attacker who breaks into the network side finds himself locked in a cell without root.
  • W^X (Write XOR Execute). A page of memory can be writable or executable, never both. Code injected into a data buffer cannot run.
  • pledge(2), 2015. A program declares to the kernel in advance which groups of system calls it will use, such as “stdio” and “rpath,” and nothing else. If it is hijacked and tries anything outside that list, the kernel kills it.
  • unveil(2), 2018. A program declares which parts of the filesystem it is allowed to see, and the rest disappears. An attacker who gets control and goes looking for password hashes finds nothing.

The security researcher Thomas Ptacek, surveying modern sandboxing, said OpenBSD “got this right with ‘pledge’ and ‘unveil’, which allow programs to gradually ratchet down the access they get to the kernel.” He compared it favorably with Linux’s intricate seccomp profiles.

The principle is simple. Don’t trust anyone’s code, including your own. Make every program declare what it will do, and have the kernel kill it if it does anything else.

XI. The Scrape in the Floor

The OpenBSD Foundation, a Canadian non-profit founded by developer Bob Beck in July 2007, keeps the project running. It pays for servers, bandwidth and hardware on a budget that would be a rounding error at any company that runs OpenSSH. Above all, it pays for the hackathons.

The first was held in Calgary in June 1999. A handful of developers moved into a house, with no keynotes, sponsors or slides. They had laptops, cables, coffee and sleeping bags on the floor, and they worked around the clock for a week. The result was an industry first, IPv6 and IPsec stacks fully integrated into an operating system. They also left a scrape in the hardwood floor of the house, which the project still remembers.

OpenBSD developers at the c2k1 hackathon, MIT, June 2001.

Later hackathons took place in rented houses, university dorms, and any cheap place that would take a few dozen people who barely slept. They are invitation-only and exhausting. People who spend the rest of the year on different continents, exchanging terse emails, sit side by side and commit major architectural changes directly to the tree.

De Raadt sits at the center, the gatekeeper with the final word. He demands perfection and does not tolerate mediocrity. He will make the system harder to use before he makes it one degree weaker. Michael Lucas gave his book on the system the subtitle UNIX for the Practical Paranoid. It could serve as a caption for its founder.

The stories about his flame wars leave something out. People stay. Markus Friedl, Damien Miller and Bob Beck appear across twenty-five years of the project’s history. Fear alone doesn’t keep people that long. Belonging does: to a small, hard group that agrees the work comes first and that getting it right, once, is worth any amount of unpleasantness.

The fortress has people inside it, and they chose to be there.

At FISL in Porto Alegre, 2007, Jon “maddog” Hall presents Theo de Raadt with a pair of red devil horns.

XII. Half a Second, Again

Back to Calgary at the end of March 2024.

The Linux world is still cleaning up, pulling packages and rebuilding from clean sources. Commentators are writing long threads about the maintainer burnout that let Jia Tan in. Somewhere, the people who built the backdoor, whether a government, a criminal group or one gifted individual, have watched more than two years of work undone over half a second.

The fortress on the prairie is untouched.

Luck has nothing to do with it. Decades ago a boy who had already been uprooted twice decided that nothing could be trusted unless he understood it all the way down. A young man was locked out of the project he helped build and resolved that no one would ever hold his keys again. He refused systemd, blobs, the GPL, and the Pentagon’s money once he felt its strings. And in Quebec in 2015 he said the letters XZ aloud, as an example of the kind of code that frightened him.

The traits cannot be separated. The paranoia that got him expelled from NetBSD built OpenBSD. The contempt that made vendors flinch in Melbourne produced free Wi-Fi drivers for everyone. The lack of any filter between his conscience and his mouth cost him the DARPA money and also brought the FBI allegation into the open. The arrogance that wrote “lying cheating hypocrite” looked at Heartbleed and decided to rewrite OpenSSL.

By most accounts he is not a nice man, and he would probably not want to be called one. Nice men take the DARPA money and say nothing, ship the blobs, keep the old code, and leave the FBI letter in a drawer. Nice men have written most of the world’s software, and that software is in poor shape.

The internet is leaking and patched and held together by commercial compromises, tired volunteers, and code nobody has read in twenty years. Near its center, where the most sensitive traffic passes, is a lock made in Calgary by a man who trusts no one. It holds while systems worth billions fail around it. It holds because its maker assumed, every working day, that someone was coming to break it.

He was right more often than not.

A note on method: this piece uses reconstructed scenes, free indirect interior voice, and dramatic compression. The events, dates, figures, and quotations come from the sources listed below. The interior thoughts attributed to Theo de Raadt and the atmospheric detail of individual scenes are the author’s imaginative reconstruction, not reported fact.

References

  1. CUUG Meetings: 2017–2018, http://www.cuug.ab.ca/past-meetings/meetings.17-18.html
  2. OpenSSH/Overview — Wikibooks, https://en.wikibooks.org/wiki/OpenSSH/Overview
  3. Open Source Software vs Proprietary Software, https://uomustansiriyah.edu.iq/media/lectures/6/6_2019_03_12!12_11_28_AM.pdf
  4. Calgary programmer Theo de Raadt: biography and projects, https://calgary-future.com/en/eternal-calgary-programmer-theo-de-raadt-biography-and-projects
  5. Theo de Raadt — Wikipedia, https://en.wikipedia.org/wiki/Theo_de_Raadt
  6. Hackathons — OpenBSD, https://www.openbsd.org/hackathons.html
  7. OpenBSD — Wikipedia, https://en.wikipedia.org/wiki/OpenBSD
  8. Theo de Raadt — Wikiquote, https://en.wikiquote.org/wiki/Theo_de_Raadt
  9. Раадт, Тэо де — Цитаты известных личностей, https://ru.citaty.net/avtory/raadt-teo-de/
  10. Is Linux For Losers? — OSnews, https://www.osnews.com/story/10889/is-linux-for-losers/comment-page-2/
  11. netbsd-users: Theo De Raadt, https://mail-index.netbsd.org/netbsd-users/1994/12/23/0000.html
  12. POSSE project — Wikipedia, https://en.wikipedia.org/wiki/POSSE_project
  13. Famous Male Programmers — Ranker, https://www.ranker.com/list/famous-male-programmers/reference?page=2
  14. Theo de Raadt — Alchetron, https://alchetron.com/Theo-de-Raadt
  15. OpenBSD Handbook, https://www.openbsdhandbook.com/
  16. What is OpenBSD? Overview & Latest Features — Liquid Web, https://www.liquidweb.com/blog/what-is-openbsd/
  17. strlcpy and strlcat — Consistent, Safe, String Copy and Concatenation (USENIX 1999), https://www.usenix.org/event/usenix99/full_papers/millert/millert.pdf
  18. Introduction — OpenBSD Handbook, https://www.openbsdhandbook.com/introduction/
  19. OpenSSH — Proceedings of the 12th USENIX Security Symposium, https://www.usenix.org/event/sec03/tech/full_papers/provos_et_al/provos_et_al.pdf
  20. CarolinaCon 15: Writing Exploit-Resistant Code With OpenBSD, https://lteo.net/blog/2019/04/27/carolinacon-15-writing-exploit-resistant-code-with-openbsd/
  21. Writing Exploit-Resistant Code with OpenBSD — Lawrence Teo, https://lteo.net/assets/pdf/lteo-openbsd-carolinacon15-20190427.pdf
  22. The history of SSH, from telnet to OpenSSH — SSD Nodes, https://www.ssdnodes.com/learn/history-of-ssh-telnet-to-openssh
  23. Project History — OpenSSH, https://www.openssh.org/history.html
  24. Open Source Doesn’t Make Money Because It Isn’t Designed to — Reddit, https://www.reddit.com/r/programming/comments/b30m3s/open_source_doesnt_make_money_because_it_isnt/
  25. “Blob-free OpenBSD kernel needed” — Hacker News, https://news.ycombinator.com/item?id=9671025
  26. We need more people like linus — Reddit, https://www.reddit.com/r/degoogle/comments/1vp1unn/we_need_more_people_like_linus/
  27. Theo de Raadt Zitate, https://beruhmte-zitate.de/autoren/theo-de-raadt/
  28. HACK — IT ARTICLES, https://cancoute-666.blogspot.com/2010/05/hack.html
  29. OpenBSD Cryptographic Framework — Wikipedia, https://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framework
  30. OpenBSD Founder Believes FBI Built IPsec Backdoor — Dark Reading, https://www.darkreading.com/vulnerabilities-threats/openbsd-founder-believes-fbi-built-ipsec-backdoor
  31. The FBI Planted Backdoors to Easily Spy on the Internet, Claims — Gizmodo, https://gizmodo.com/the-fbi-planted-backdoors-to-easily-spy-on-the-internet-5713735
  32. Did the FBI Plant Backdoors in OpenBSD? — Intego, https://www.intego.com/mac-security-blog/did-the-fbi-plant-backdoors-in-openbsd/
  33. More Details Emerge Regarding OpenBSD FBI Backdoors — OSnews, https://www.osnews.com/story/24142/more-details-emerge-regarding-openbsd-fbi-backdoors/
  34. Allegations of OpenBSD Backdoors May be True, Updated — Linux Journal, https://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true
  35. How to Prevent the next Heartbleed — David A. Wheeler, https://dwheeler.com/essays/heartbleed.html
  36. Heartbleed — Wikipedia, https://en.wikipedia.org/wiki/Heartbleed
  37. OpenBSD forks, prunes, fixes OpenSSL — ZDNET, https://www.zdnet.com/article/openbsd-forks-prunes-fixes-openssl/
  38. Does the Heartbleed bug refute Linus’s Law? — Armed and Dangerous, http://esr.ibiblio.org/?p=5665
  39. True Crypt, Heartbleed, and Lessons Learned — zwilnik, https://www.zwilnik.com/security-and-privacy/true-crypt-heartbleed-and-lessons-learned/
  40. LibreSSL — Wikipedia, https://en.wikipedia.org/wiki/LibreSSL
  41. LibreSSL: why OpenSSL has no solution — Desde Linux, https://blog.desdelinux.net/en/libressl-because-openssl-is-irreparable-according-to-openbsd/
  42. C programming/C reference/nonstandard/strlcpy — Wikibooks, https://en.wikibooks.org/wiki/C_programming/C_reference/nonstandard/strlcpy
  43. Enhancing XFree86 Security — OpenBSD, http://www.openbsd.org/papers/xf86-sec.pdf
  44. Privilege drop, privilege separation, and restricted-service operating, https://sha256.net/privsep.html
  45. OpenBSD security features — Wikipedia, https://en.wikipedia.org/wiki/OpenBSD_security_features
  46. An early warning of the XZ Compromise? — synhack.org, https://synhack.org/blog/pledge/
  47. Sandboxing Adoption in Open Source Ecosystems — arXiv, https://arxiv.org/pdf/2405.06447
  48. Sandboxing and Workload Isolation — Fly.io, https://fly.io/blog/sandboxing-and-workload-isolation/
  49. Backdoor in upstream xz/liblzma leading to SSH server compromise — LowEndTalk, https://lowendtalk.com/discussion/193769/backdoor-in-upstream-xz-liblzma-leading-to-ssh-server-compromise-openwall-com-via-hacker-news
  50. Blog — Vivian Voss, https://vivianvoss.net/blog
  51. Did (or would) the XZ Utils backdoor affect the BSD ecosystem at all? — Reddit, https://www.reddit.com/r/freebsd/comments/1btxreq/did_or_would_the_xz_utils_backdoor_affect_the_bsd/
  52. OpenBSD is a cozy operating system — Hacker News, https://news.ycombinator.com/item?id=40024393
  53. Activities — OpenBSD Foundation, https://www.openbsdfoundation.org/activities.html
  54. www/hackathons.html at master · openbsd/www — GitHub, https://github.com/openbsd/www/blob/master/hackathons.html
  55. OpenBSD in Canada — undeadly.org, https://undeadly.org/cgi?action=article;sid=20230226065006
  56. Absolute OpenBSD: UNIX for the Practical Paranoid — Michael W. Lucas
  57. Linus Torvalds on OpenBSD (“masturbating monkeys”), LKML, July 2008 — https://lkml.org/lkml/2008/7/15/296
  58. The GNU C Library version 2.38 is now available — GNU info-gnu, July 2023, https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00010.html
  59. OpenSSH for Windows overview — Microsoft Learn, https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh-overview
  60. Installing OpenSSH on Windows 10 (1803 and higher) and Server 2019–4sysops, https://4sysops.com/archives/installing-openssh-on-windows-10-1803-and-higher-and-server-2019/
  61. PF (firewall) — Wikipedia, https://en.wikipedia.org/wiki/PF_(firewall)
  62. Ipfirewall — Wikipedia, https://en.wikipedia.org/wiki/Ipfirewall
  63. Get started with OpenSSH Server for Windows — Microsoft Learn, https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
  64. strlcat — POSIX.1–2024, The Open Group, https://pubs.opengroup.org/onlinepubs/9799919799/functions/strlcat.html

Image Credits

  1. dunnottar-graded.jpg — Dunnottar Castle, Aberdeenshire, Scotland (converted to black and white; adaptation shared under the same license). Stratos Filalithis / Wikimedia Commons, CC BY-SA 4.0, https://commons.wikimedia.org/wiki/File:Dunnotar_Castle_with_clouds.jpg
  2. calgary-blizzard.jpg — Empty snow-swept road under streetlights during a night blizzard, NE Calgary (converted to black and white). Colby Stopa / Flickr, CC BY 2.0, https://www.flickr.com/photos/93057803@N06/11189129403
  3. theo-de-raadt-bw.jpg — Theo de Raadt speaking at ruBSD 2013, Moscow (cropped and converted to black and white). FAndrey / Wikimedia Commons, CC BY 2.0, https://commons.wikimedia.org/wiki/File:Theo_de_Raadt_2013.jpg
  4. yukon.jpg — Tombstone Range in winter from North Fork Pass, Yukon (converted to black and white). Dlogic / Wikimedia Commons, CC BY 3.0, https://commons.wikimedia.org/wiki/File:Tombstone_mountain_range_winter.jpg
  5. vic-20.jpg — Commodore VIC-20 (converted to black and white). Evan-Amos / Wikimedia Commons, Public domain, https://commons.wikimedia.org/wiki/File:Commodore-VIC-20-FL.jpg
  6. sparcstation.jpg — Sun SPARCstation IPX (converted to black and white; adaptation shared under the same license). htomari / Wikimedia Commons, CC BY-SA 2.0, https://commons.wikimedia.org/wiki/File:Sun_SPARCstation_IPX.jpg
  7. puffy.png — Puffy, the OpenBSD mascot (3D render) (converted to black and white). art.gnux.info / Wikimedia Commons, CC BY 1.0, https://commons.wikimedia.org/wiki/File:Puffy.png
  8. vt100.jpg — DEC VT100 terminal, Living Computer Museum (converted to black and white). Jason Scott / Wikimedia Commons, CC BY 2.0, https://commons.wikimedia.org/wiki/File:DEC_VT100_terminal.jpg
  9. openssh-logo.png — OpenSSH logo (converted to black and white). OpenSSH / OpenBSD project, used for identification, https://www.openssh.com/
  10. tomahawk-2003.jpg — USS Donald Cook (DDG 75) launches a Tomahawk toward Iraq, 21 March 2003 (converted to black and white). U.S. Navy photo by Chief Journalist Alan J. Baribeau / Wikimedia Commons, Public domain, https://commons.wikimedia.org/wiki/File:US_Navy_030321-N-6141B-012_The_guided_missile_destroyer_USS_Donald_Cook_(DDG_75)_launches_a_Tomahawk_Land_Attack_Missile_(TLAM)_toward_Iraq_during_the_initial_stages_of_Operation_Iraqi_Freedom.jpg
  11. torvalds.jpg — Linus Torvalds at LinuxCon Europe 2014, Düsseldorf (converted to black and white; adaptation shared under the same license). Krd (photo), Von Sprat (crop) / Wikimedia Commons, CC BY-SA 4.0, https://commons.wikimedia.org/wiki/File:LinuxCon_Europe_Linus_Torvalds_03_(cropped).jpg
  12. stallman.jpg — Richard Stallman at LibrePlanet 2019 (converted to black and white). Ruben Rodriguez / Wikimedia Commons, CC BY 4.0, https://commons.wikimedia.org/wiki/File:Richard_Stallman_at_LibrePlanet_2019.jpg
  13. heartbleed.png — Heartbleed logo (converted to black and white). Leena Kurjenniska / Codenomicon / Wikimedia Commons, CC0, https://commons.wikimedia.org/wiki/File:Heartbleed.svg
  14. libressl.png — LibreSSL logo (converted to black and white). LibreSSL / OpenBSD project, used for identification, https://www.libressl.org/
  15. datacenter.jpg — Server racks, BalticServers data centre (converted to black and white; adaptation shared under the same license). BalticServers.com / Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:BalticServers_data_center.jpg
  16. hackathon.jpg — OpenBSD developers at the c2k1 hackathon, MIT, June 2001 (converted to black and white). Dug Song / Wikimedia Commons, Public domain, https://commons.wikimedia.org/wiki/File:OpenBSD_hackers_at_c2k%2B%2B_at_MIT.jpg
  17. theo-de-raadt-2.jpg — Jon “maddog” Hall gives Theo de Raadt a set of red plastic horns, FISL 8, Porto Alegre, 2007 (converted to black and white; adaptation shared under the same license). Randal Schwartz / Wikimedia Commons, CC BY-SA 2.0, https://commons.wikimedia.org/wiki/File:Jon_%22maddog%22_Hall_gives_Theo_de_Raadt_a_set_of_red_plastic_horns.jpg

OpenSSH Ships on Every Mac, Linux Server and Windows PC. Its Creator Trusts No One. was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[I Built My Own “Muse Charm” on an ESP32 Stick: One Fast Brain, One Slow Brain]]> https://medium.com/the-low-end-disruptor/i-built-my-own-muse-charm-on-an-esp32-stick-one-fast-brain-one-slow-brain-26f641dfa4b0?source=rss----16704e6008f5---4 https://medium.com/p/26f641dfa4b0 Wed, 30 Sep 2026 18:08:11 GMT 2026-09-30T18:08:11.366Z

TL;DR:

  • What it is: Kai is a push-to-talk AI pal on a charm-sized M5StickS3.
  • Two brains: a fast path (Gemini Live, ~2 s spoken answers) handles most questions. A slow path (a locked-down Hermes Agent, 15–50 s) does research, memory and schedules, and Kai speaks the result when it lands.
  • How routing works: the voice model’s own tool choice decides the path, and an eval set keeps that choice honest.
  • Size and material cost: 48 × 24 × 15 mm, 20 g, $21 for the stick, plus a home server
  • Scale: a few days, about 4,800 lines of C++ and Python, (github.com/zbruceli/kai).
  • Purpose of this article: lessons learned from building a real time AI voice device living on limited compute and power budget

A keychain charm that talks to an agent

In September, Meta launched Muse, its personal agent. Alongside it came the Muse Charm:

  • a keychain device with a fingerprint sensor, a microphone and a tiny screen;
  • a Tamagotchi-like avatar on that screen;
  • approvals and payments bounced to your phone.

It ships in December.

The Charm’s premise struck me: the agent lives in the cloud, the device is just a friendly way to reach it, and anything that needs reading or paying goes to a bigger screen. That’s an architecture, not a product. So I asked a developer’s question: how much of this can I build this week, with an off-the-shelf dev board and public APIs?

It turned out to be most of it, minus the fingerprint sensor and the payments, which I didn’t want anyway. This post covers:

  • the thought process and the use cases;
  • the architecture;
  • four design problems that decided everything: power, where the relay lives, the hybrid brain, and how to route between fast and slow.

Use cases: start from one person’s day

I’m a photographer and an angler on the San Mateo County coast. The questions I actually ask while my hands are full are narrow and local:

The surprise came from the logs: over four days, fewer than one in six real questions touched those niche tools. The rest were whatever came to mind:

  • how long to boil ramen eggs;
  • the next Starship launch;
  • LeBron versus Kobe;
  • what “moon drop” grapes are.

A pocket device gets asked everything. So general knowledge had to be excellent, and the specialised tools had to be reliable, not just present.

The hardware: M5StickS3

Kai runs on an M5StickS3, M5Stack’s newest “Stick” dev kit. It costs about $21 and needs no soldering: everything a voice gadget needs is already in the case. The Stick family got famous among developers this spring as the reference hardware for Anthropic’s open-source Claude Desktop Buddy, a little desk pet that wakes up when a Claude session starts and lets you approve or deny its permission prompts with a button press. Kai asks its newer sibling to do more: listen, talk back, and live on a keychain.

Two kinds of core, for two kinds of time. The ESP32-S3 pairs two very different processors. For the few seconds you’re talking, two Xtensa LX7 cores run at up to 240 MHz, with vector instructions to spare. That’s enough to encode a 20 ms Opus frame in 6.4 ms while the radio streams. For the other 23-odd hours of the day, those cores, the radio and main memory are switched off. What stays on is a tiny always-on corner of the chip: an RTC timer, 16 KB of RTC memory, and a RISC-V ultra-low-power (ULP) coprocessor that can run its own small program with the main cores asleep. The gap between the two sides is huge: roughly 300 mA while Wi-Fi transmits, and 7–8 µA asleep with only the timer and RTC memory powered, a ratio of about 40,000 to 1. Kai uses the always-on side today as an alarm clock and a notepad: the RTC timer wakes it for the next reminder, and RTC memory keeps the Wi-Fi channel, BSSID and relay IP so the reconnect skips the scan. The RISC-V core is the headroom: at ~190 µA it could watch the buttons or the IMU and wake the big cores only when something happens, without ever starting Wi-Fi.

Why this board and not a bare ESP32:

  • The audio chain is done. A codec, a mic and an amplified speaker on one board means no I2S wiring and no breadboard. Day one went on the protocol, not the hardware.
  • PSRAM is the quiet hero. 8 MB is room for a deep audio buffer, which is what smooths out Gemini’s bursty playback and lets you talk while Wi-Fi is still reconnecting.
  • The power chip is programmable. It reports rail voltages and currents, which made the power budget below possible, and it can cut power to the screen and audio in deep sleep.
  • It’s already a product shape. Case, battery, charging and a lanyard hole: it passes for a keychain gadget without a 3D printer.

What it doesn’t have matters just as much: no fingerprint sensor, no cellular, no GPS, and no Bluetooth Classic, so no headset profiles. Those gaps shaped the design as much as the parts did.

Constraints first

Each of the Stick’s limits forced a decision:

The design rule that fell out: voice first, glance second, everything else somewhere else.

Architecture: a thin device, a relay, two brains

The Stick is deliberately dumb.

  • It streams Opus audio over a WebSocket while the front button is held.
  • It plays back Kai’s voice, draws a pixel face and cards, and deep-sleeps after 45 s.
  • It holds one secret, a device token. No API keys live on the device.

The relay is where everything lives. It’s a Python service on an always-on box at home.

  • It bridges the Stick to Gemini Live (native audio in and out, with Google Search).
  • It runs Kai’s own tools, and keeps the inbox, the scheduler and the memory brief.
  • It hands slow work to Hermes Agent.

Keeping the logic off the device paid for itself on day one: every prompt tweak and new tool shipped with a git pull on the server, not a reflash.

The wire protocol is small:

Tools are plain async functions. Gemini gets the declaration. The relay sends the data back to Gemini and the card to the screen:

@tool(
    "get_tides",
    "High and low tide times near a place from the nearest NOAA station (US coasts). Call it for every "
    "tide question, including repeats and follow-ups: it refreshes the card on screen.",
    {"place": {"type": "STRING", "description": "Beach, harbor, pier or town. Omit for home."},
     "day": DAY_PARAM},
)
async def get_tides(ctx: ToolContext, place: str | None = None, day: str | None = None) -> ToolResult:
    ...

Two early lessons shaped every tool after that:

  1. Never let the model do date arithmetic. Days are passed as spoken (“saturday”, “day after tomorrow”) and resolved on the relay, because Gemini’s date arithmetic proved unreliable.
  2. Models skip tools. Sometimes Gemini answers a weather question from Search, with no tool call, so no card. The relay’s backstop infers the call from the transcript and runs it itself. It fires about 4 times per 90 real questions.

Consideration 1: power

A 250 mAh battery forces you to measure before you optimise. I built an estimated power budget from the power chip’s rail measurements and component datasheets. It found something I didn’t expect:

The conversation was cheap. The tail was not. After each answer, the device kept the reply screen lit with Wi-Fi awake, then idled, then dimmed, then finally slept. That tail was 84% of each question’s charge, and the idle loop was redrawing a full frame at 30 fps, spending half its time drawing nothing new.

The fixes were mundane and effective:

  • redraw only on change;
  • let FreeRTOS idle the CPU at 80 MHz;
  • Wi-Fi modem sleep whenever no audio streams;
  • codec and amp off when silent;
  • cut the LCD/audio power rail in deep sleep (~2 mA → ~0.15 mA);
  • shorter timers.

The result: projected battery life at 20 questions a day went from ~1.3 days to ~6 days.

Then Opus: switching the audio from raw PCM (256 kbit/s up, 384 kbit/s down) to Opus (~24 up, ~32 down) cut Wi-Fi airtime about 11–12×.

  • On the ESP32-S3 at 240 MHz, encoding takes 6.4 ms per 20 ms frame, and decoding 3.9 ms.
  • One gotcha: Gemini sends speech 3–4× faster than real time. Decoding every packet on arrival starved the speaker task. Queueing packets compressed and decoding them just in time fixed the stutter: zero underruns.

Waking fast matters as much as sleeping well:

  • The Wi-Fi channel, BSSID and relay IP are kept in RTC memory, so reconnecting skips the scan.
  • Holding the button while it wakes records straight into PSRAM, so you can press and talk from deep sleep without waiting for Wi-Fi.

Consideration 2: where the relay lives

I seriously considered three places for the relay:

  1. The phone, as a BLE bridge.
  • The ESP32-S3 has BLE 5 but no Bluetooth Classic, so there are no headset profiles; audio has to travel as data. Opus fits comfortably in BLE bandwidth.
  • iOS suspends background apps, so the phone app has to stay a thin byte-mover rather than the brain.
  • The phone would also bring real GPS for “near me”.

2. A cloud droplet. Reachable anywhere, but it means TLS on the device, a public endpoint, and another thing to secure.

3. A home server on the LAN. Zero exposure, ws:// on a trusted network, and a box I already run.

I chose local first, remote later. The architecture doesn’t care: the phone bridge (Stick → BLE → phone → tunnel → the same relay) only adds a transport. Keeping the brain in one Python process means every tool exists once, not three times in Python, Kotlin and Swift.

Consideration 3: the hybrid brain

A realtime voice model is superb at conversation and terrible at waiting. A Gemini Live function call blocks the turn, so “research three sunrise spots” can’t run inside it. Kai needed a second brain for slow work, memory and schedules.

I compared three routes:

  • grow the relay into an agent myself: memory, task runner, cron, approvals; roughly 20+ days;
  • put OpenClaw behind it: the biggest ecosystem, but a Node stack, and a skills marketplace with a documented malware problem;
  • use Hermes Agent (Nous Research, MIT, Python), which already has memory, cron, background runs and approval gates.

I chose Hermes, and locked it down hard:

  • pinned Docker image (tag and digest), with only its own data folder mounted;
  • terminal, file, code-execution, browser and computer-use toolsets disabled;
  • approvals manual, unattended actions denied, self-written skills need approval;
  • API and MCP both on localhost, behind tokens.

A red-team prompt asking it to read ~/.ssh found no tool to do it with.

Integration is two one-way pipes:

  • Relay → Hermes: POST /v1/runs starts a background run with a voice-shaped instruction. The reply must be JSON: speak (at most two sentences), a card, and details_md.
  • Hermes → relay: Hermes is an MCP client, so the relay runs a small MCP server on localhost.
  • kai_notify delivers a result;
  • kai_profile_brief updates what Kai knows about me;
  • Kai’s own tide, weather and light tools are exposed read-only, so Hermes doesn’t re-scrape the web with worse data. It once answered sunrise from a web page (7:33) when Kai’s tool said 7:03. Job prompts now require Kai’s tools.

The key trick is how results come back. ask_agent returns immediately, and Kai says "On it." When the run finishes, the relay injects the result into the live voice session as a text turn, queued so it never talks over you:

await self._send({"type": "nudge"})  # two-note chime: news you didn't just ask for
await self._live.send_client_content(
    turns=types.Content(role="user", parts=[types.Part(text=(
        "[Background result for the owner, not something they just said. Tell them now in one or "
        f"two short spoken sentences, as your own news: {item.speak}]"))]),
    turn_complete=True,
)

If the Stick is asleep, the result waits in an inbox, and a yellow badge shows on the face the next time you pick it up.

Memory is a brief, not a database lookup.

  1. When a conversation ends, its transcript goes to Hermes.
  2. Hermes updates its long-term memory and sends back a profile brief of at most 800 characters.
  3. That brief goes into the system prompt of every new session. Facts about me cost zero tool calls; recall covers anything older, with an 8-second budget before it falls back to the inbox.

Time is where the sleeping device bites. Nothing can push to a Stick in deep sleep. So:

  • the relay owns every reminder;
  • it tells the Stick when the next thing is due;
  • the Stick sets its RTC timer before it sleeps.
  • Reminders are the relay’s own. They need no LLM when they fire.
  • Briefings (“every Saturday at 5:45, a fishing brief”) and watches (“tell me if the wind drops”) are Hermes cron jobs.
  • A watch replies [SILENT] until its condition holds, then calls kai_notify(watch=…), and the relay deletes the job.
  • Watches never wake the Stick between 22:00 and 07:00.

Consideration 4: fast or slow?

This is the most interesting design question in the project. You have ~2 seconds on one path and ~25 seconds on the other. Who decides, and how?

The option I rejected: a router in front. Keyword rules, an embedding classifier or a small model would decide before the answer starts. Those fit text pipelines. With native audio there’s no transcript until the turn ends, so a gate in front adds latency to every question to save a few.

What Kai does instead: the voice model is the router. ask_agent is just another tool, and choosing a tool is something Gemini Live does anyway. That costs zero added latency. The work goes into making that choice well-informed, and measurable.

Version one used trigger words (“research”, “look into”, “later”). The logs graded it:

  • Precise: 9 of 9 explicit requests went to the slow path, and nothing went there by mistake.
  • But timid: a hard question without a trigger word got a confident, thin answer. Twice, I asked a fast question (“new restaurants downtown?”, “Starship flight objectives?”), got one sentence, and asked again with “tell me later”.
  • And the slow path isn’t slow: 15–49 s, median ~24 s.

Before touching the prompt, I built an eval:

  • The cases: the ~76 real utterances from the logs, hand-labelled, plus 28 synthetic cases for tool collisions and false-positive traps (“find me the capital of Australia” must stay fast).
  • The harness: it replays each one through a real Gemini Live session with the relay’s exact prompt and tools, as text, and records the first decision: fast, tool:<name>, slow, offer or clarify. Three runs per case, because the same prompt routes differently from run to run.

Then I changed the rules from words to criteria:

  • Answer now when one lookup settles it.
  • Hand off when a good answer needs several sources or constraints, comparing, planning, or goes beyond a tool’s range. Always hand off when explicitly asked.
  • A third route: answer, then offer. For local “what’s new”, plans still taking shape, or thin search results, Kai says the best it found in one sentence and asks “Want me to dig into it?”. “Yes” hands off, with the question and the quick answer as context.

The eval earned its keep in the first iteration. My first draft raised accuracy, but it introduced a worse failure. Twice, Kai said “I’m looking into those road closures for you” without calling the tool. That’s a promise with nothing behind it. One hard rule fixed it: “never say you’re looking into something without calling ask_agent: nothing happens unless you call it". Without the eval, I'd have shipped a Kai that occasionally lies about doing work.

Some fixes don’t belong in the prompt at all. Gemini Live sometimes confirmed a reminder twice: once around the tool call, and again when the result came back. No wording reliably stops that, so the relay does: after a successful action tool and one spoken confirmation, it drops any further turn Gemini starts before you speak again. Use the prompt for judgement, and code for invariants.

The final implementation

Firmware (C++, PlatformIO, ~1,700 lines):

  • modes Offline → Idle → Listening → Thinking → Reply;
  • Opus through libopus at complexity 1;
  • a 2 MB PSRAM speaker ring;
  • a 20×18 pastel sprite with seven moods;
  • inbox badge, chime, RTC timer wake.

Relay (Python, uv, ~3,100 lines):

  • the Live session bridge and tools;
  • the backstop;
  • the inbox, scheduler, and Hermes client;
  • the MCP server;
  • the routing eval.

Hermes: one pinned container on the same box, reached only through localhost.

Lessons worth stealing

  1. Measure the tail, not the task. In battery devices, the time after the work usually costs more than the work.
  2. Keep the device thin, and the brain in one place. One implementation of every tool, keys never leave the server, and prompt changes ship without a reflash.
  3. Let the realtime model route, but give it criteria, not keywords. Then build an eval from your own logs before changing anything.
  4. Async by default for slow work. Acknowledge, return immediately, and deliver later into the same conversation, or into an inbox if the device is asleep.
  5. Guard invariants in code. Model behaviour drifts between runs; a relay-side check doesn’t.

What’s next

  • A richer interface. Voice and a tiny screen are only two of the ways to talk to a pocket device. The Stick already has a motion sensor, IR and a second button sitting unused: shake to dismiss, tilt to scroll a card, a raise-to-talk gesture, or a haptic buzz instead of a chime when you’re somewhere quiet.
  • Kai away from home. The relay lives on my LAN, so Kai goes quiet once I leave Wi-Fi range. A secure tunnel to the home server, over a phone hotspot or a phone BLE bridge, would take Kai to the beach and the harbor without exposing the relay to the internet.
  • A little more trust for Hermes. Today Hermes can research, remember and schedule, and nothing else. The next step is to open it up, carefully, to more of my personal digital life: calendar, email triage, photo-trip planning. Every side effect goes through a spoken read-back and a deliberate long press first.
  • A reflex layer. A new class of decision models, like TypeSafe AI’s Jev and OpenAI’s Decisions API launched this week, returns a choice from a fixed set of answers in a fraction of a second. That’s exactly what Kai needs for fast routing decisions. I expect Google to bring similar support to the Gemini Live API.

The Muse Charm will ship with a fingerprint sensor, a payments stack and Meta’s cloud behind it. Kai has a 20-gram dev board, a home server and two brains that know their jobs. For a pocket pal that answers the questions I actually ask, that’s been enough. And Kai costs $21, you can mod it however you want, and you don’t have to wait for December.

Code: github.com/zbruceli/kai (MIT).

I Built My Own “Muse Charm” on an ESP32 Stick: One Fast Brain, One Slow Brain was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[I Wanted the Phones to Stop Dropping. I Got WhatsApp Instead.]]> https://medium.com/the-low-end-disruptor/i-wanted-the-phones-to-stop-dropping-i-got-whatsapp-instead-99e019efd337?source=rss----16704e6008f5---4 https://medium.com/p/99e019efd337 Thu, 24 Sep 2026 18:09:50 GMT 2026-09-24T18:09:50.334Z The curious story of Erlang, told from inside the head of the man who built it.

A note on form. Joe Armstrong, co-creator of the Erlang programming language, died in April 2019. What follows is a work of narrative nonfiction told in an imagined first-person voice. The events, dates, and figures are drawn from the historical record, from Armstrong’s own papers, talks, interviews, and blog posts, and from the accounts of the people who worked beside him. Where he is quoted directly, the words are his. The rest is reconstruction: how it might have felt, from where he stood. He would, I think, have preferred that we say so plainly.

Stockholm, February 2014

The news reached me the way news reaches everyone now, on the small glass rectangle in my pocket. Facebook was buying WhatsApp for $19 billion.

I am not a man who follows acquisitions. I follow bugs. But this one I read twice, and then I put the phone down on the kitchen table and looked at it for a while, because I knew something about that phone that the newspapers did not think to mention.

WhatsApp had about 450 million people using it every month. It moved tens of billions of messages a day. The entire engineering staff was around fifty people. Fifty. You could fit them in a decent-sized seminar room at KTH and still have chairs left over. Every one of those engineers was responsible for something like ten million human beings, and the thing that made that arithmetic possible was a programming language that three of us had cobbled together in a laboratory in Kista in 1986, to stop telephone calls from dropping.

I was sixty-three years old. I had spent most of my life being told that Erlang was too strange, too academic, too Swedish, too functional, too old, too small. That morning, the strangest language in the world was carrying more human conversation than any piece of software in history, and the people who had built the app on top of it had never once asked my permission.

That is the best kind of success. The kind that does not need you.

A Physicist Walks Into a Telephone Company

I was born in Bournemouth, on the south coast of England, at the end of 1950. I trained as a physicist, not a programmer. Physics teaches you a particular humility. The universe does not care about your elegant theory. Things fall. Things break. Your job is to describe what actually happens, not what you wish would happen. I never quite lost that habit, and it turned out to be the whole trick.

By 1985 I had drifted north, first to Kiruna in the Swedish Arctic, where I wrote software for radar that stared at the aurora, and then to Ericsson’s Computer Science Laboratory outside Stockholm. Ericsson made telephone exchanges, the big humming cabinets that connected your call to your mother’s. The laboratory had been handed a problem by a man named Bjarne Däcker, and the problem was this: writing software for those cabinets took forever, and the software had to be perfect, and it never was.

You have to understand what a telephone exchange is asked to do. It handles thousands of calls at once, each one its own little world. Hardware fails constantly, because hardware is made of atoms. The exchange is never allowed to stop. Not for a bug, not for an upgrade, not for anything. When the exchange stops, a woman somewhere cannot reach an ambulance. Those were the rules, and they were not negotiable, and I found I rather liked that. Most software has no rules. Telecom had rules.

Bjarne’s team spent three years trying more than twenty existing languages against those rules. Lisp, Prolog, a dozen others. None of them fit. So we did the arrogant thing. Mike Williams, Robert Virding, and I started writing our own.

The first version, in 1986, was a little interpreter I wrote in Prolog. It was slow enough to be embarrassing. But it had the right shape. Everything was a process, thousands of tiny isolated processes that could not touch one another’s memory and talked only by sending messages. If one died, it died alone. Mike then wrote a proper virtual machine in C so the thing would run at a speed a telephone company could tolerate. He called it JAM, for Joe’s Abstract Machine, which I have always found faintly ridiculous and secretly loved.

We named the language Erlang. Officially it was for Agner Krarup Erlang, the Danish mathematician whose queueing theory the entire telephone industry rests on. Unofficially it was short for Ericsson Language. We let people believe whichever one they liked.

The Movie

In 1990, someone at Ericsson decided the world needed a film about us.

If you have never seen “Erlang: The Movie,” I envy you the experience of seeing it for the first time. It is eleven minutes long. Mike, Robert, and I wear enormous telephone headsets. There is a synthesizer soundtrack that sounds like a lift in a Swedish bank. I place a call to Mike through an Erlang switch. “Hello, Mike.” “Hello, Joe.” We deliberately trigger a bug in the middle of the conversation. Robert fixes the code. We load the fix into the running switch, and the call never drops. Then we say goodbye, stiffly, like men who have been told by a director to say goodbye.

The thing is, the trick in the film was real, and it was the whole point of the language. A telecom system cannot be shut down for an upgrade. So Erlang could hold two versions of the same code at once. The processes already running the old version finished what they were doing. Every new call went to the new version. When the last process on the old code was done, the old code quietly went away. Nobody’s call dropped. We called it hot code loading. Most languages still cannot do it, thirty-five years later.

The community made a tongue-in-cheek sequel in 2013, with the original cast, and I have made peace with the fact that this film may outlive everything else I ever did.

Nine Nines

Erlang spent the early nineties escaping the laboratory. We used it to prototype software for the MD110, Ericsson’s corporate exchange. In 1993 the company set up a little subsidiary, Erlang Systems, to sell the language to outsiders. For a while it felt like Erlang might become a product.

Then the company had a disaster, and the disaster saved us.

Through the early nineties, Ericsson had poured a fortune into AXE-N, a grand next-generation switch built the conventional way. In late 1995 it collapsed. Cancelled. Years of work, gone. But Ericsson still needed a broadband switch, and it needed one quickly, and someone with courage decided the replacement would be written in Erlang.

That project became the AXD301. To make Erlang fit for something that size, a dedicated team spent 1996 building what we called the Open Telecom Platform, or OTP. OTP was everything we had learned about not falling over, packaged into reusable parts. Standard ways to build a server. Standard ways to build a state machine. And above all, supervisors: processes whose only job was to watch other processes and restart them when they died.

The AXD301 shipped in the late nineties with more than two million lines of Erlang inside it. Somewhere in a British Telecom network it produced a number that has followed me around ever since: nine nines. 99.9999999 percent availability. That is about 31 milliseconds of downtime a year. People have argued about that figure for two decades, and they are right to, because it describes a specific network over a specific period and nothing more. But I will tell you what I know for certain. The switch did not fall over. In telecom, that is the only compliment that matters.

The Memo

In 1998, the same year the AXD301 was proving us right, Ericsson banned Erlang.

Not the product. The language. A memo from Ericsson Radio Systems declared that Erlang was not to be used for new product development. The reasoning was not technical. Choosing a programming language, the memo said, was a longer-term commitment than choosing a processor or an operating system. C++ and Java were standard. You could hire for them. You could outsource them. Erlang was homegrown and known by a few hundred people on the planet, most of whom I could name.

I have thought about that memo for a long time, and I have come to believe the people who wrote it were not stupid. They were doing what large companies do, which is to reduce the number of ways they can be surprised. What they could not see, and what I could not see either, was that being surprised was about to become the entire business of the internet.

So a group of us left. We founded a company called Bluetail and used Erlang to build fault-tolerant internet infrastructure for people who had never heard of a telephone exchange. Ericsson, to keep the peace with us and with the outsiders who had grown attached to the language, released Erlang and OTP as open source in December 1998. I do not think anyone in the room understood what they had just done. They had let the thing out.

Bluetail was sold within two years to Alteon WebSystems for about $140 million, at what turned out to be the exact top of the dot-com bubble. Then Nortel bought Alteon. Then the bubble burst. In 2001, Nortel laid us off.

Fifty-Two, Unemployed, at the Kitchen Table

There is a particular quiet in a house when you have been made redundant in your fifties. I filled it by going back to school.

For two years I sat and wrote a PhD thesis, which I finished in 2003 and called Making Reliable Distributed Systems in the Presence of Software Errors. That title is not modest, but it is accurate. It was fifteen years of telecom scar tissue, finally written down as a theory.

The theory begins with an admission most programmers would rather not make. Your program has bugs in it. It will always have bugs in it. The bigger it gets, the more it has. Every school of defensive programming is a way of pretending otherwise, of wrapping your beautiful logic in layers of error handling that anticipate every failure except the one that actually happens at three in the morning.

So stop pretending. Let it crash.

When a process hits something it did not expect, it should die, immediately and without ceremony. Because it shares no memory with anyone, its death corrupts nothing. Its supervisor notices, and starts a clean copy with a known-good state. That is all. It is exactly what you do to a misbehaving piece of hardware: you turn it off and turn it on again. I merely suggested that software deserved the same dignity.

The doctrine of surviving a crash was written by a man who had just been through one. I did not plan that symmetry, but I have never been able to unsee it.

The Gorilla

I am told I am famous for a gorilla.

By the late nineties, object-oriented programming had won everything. Java and C++ modeled the world as objects that bundled data with behavior and reached into one another’s insides to change them. I thought this was a catastrophe for anything that had to run forever, and I said so, and at some point I said it like this:

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”

The joke stuck because it is precise. Ask an object for one small thing and you drag along its parent and the parent’s parent and the entire mutable, shared, locked-and-double-locked jungle of the running program. When something in that jungle goes wrong, everything goes wrong together. Erlang’s processes were my answer. Isolated. Immutable. Talking only by post.

Here is the twist I did not expect. Years later I came to understand that Erlang might be the only truly object-oriented language, because its processes are exactly what objects were supposed to be: isolated things that communicate only by messages. Alan Kay, the man who coined the term, has said roughly the same thing, and has grumbled that what he had in mind looked a great deal more like Erlang than like C++. So the man who mocked objects had built the purest object system in the industry. I just called them processes, and I was too stubborn to notice.

A Post on a Mailing List

In June 2009, a man I had never heard of named Jan Koum posted a question on the mailing list for ejabberd, an open-source chat server written in Erlang. He wanted to know about client access controls. It was the kind of question you get every week. Nobody thought anything of it.

Jan Koum and Brian Acton had just founded WhatsApp. They wanted a messaging app that did one thing well: deliver the message. Always. Even when the phone was on a bad 2G connection in a basement. Even when it had been switched off for a week. They took ejabberd, and they took Erlang, and then they took both of them somewhere no one had ever gone.

I want to be honest about my role in this, which was nothing. I did not consult for WhatsApp. I did not know Rick Reed, the engineer who did most of the impossible things, until long after he had done them. What I did was build a tool in 1986 for a problem that would not exist for twenty-five years. A global messaging app is a telephone exchange. It is millions of simultaneous connections that must never drop, running on hardware that always fails, upgraded while people are still talking. It was the same problem. It was always the same problem.

By 2011, WhatsApp was holding a million simultaneous connections on a single server. That was already absurd. Then Rick and his team spent a month hunting lock contention through the operating system, through the virtual machine Mike had started, through their own code, and got to two million. In a record run in early 2012, one machine peaked at 2.8 million people connected at once. They gave each user one Erlang process, the way we had given each telephone call one Erlang process, and the machine did not fall over.

On New Year’s Eve 2012, when half the planet says the same thing to each other at midnight, WhatsApp carried 18 billion messages in a single day. The servers, as far as anyone could tell, did not notice.

There is one more thing about that $19 billion, and it is the part I enjoy most. In 2008, Facebook had launched its own chat on Erlang, on the very same ejabberd foundation. Their engineers wrote admiring posts about it. Then they rewrote the whole thing in C++, because too few people at the company could work in our strange little language. Six years later they wrote the largest cheque in the history of software for a company that had made the opposite bet and never looked back. I try not to be smug about this. I do not always succeed.

The Children

The thing about letting something out is that it stops being yours.

In 2012 a Brazilian named José Valim, who had spent years making Ruby on Rails pleasant to use, decided that our virtual machine deserved a language people actually enjoyed writing. He called it Elixir. It ran on the same BEAM, used the same OTP, and could call every line of Erlang ever written, but it looked like something from this century instead of something from a Prolog textbook. I had spent twenty-five years being told Erlang’s syntax was unpleasant. José simply agreed, and fixed it, and did not ask me.

Elixir brought people I never expected. Web developers. Startups. A chat platform for gamers called Discord built its entire real-time system on it, and by 2017 was writing about running five million people at once. Two years later it was eleven million, and one hot spot in the code could not keep up, so they rewrote that one piece in Rust and called it from Elixir. That is the pattern now. The BEAM holds the connections and survives the crashes. Something fast and unforgiving does the arithmetic. I think that is exactly right. I never wanted Erlang to do everything. I wanted it to never fall over.

Then in 2016 a young Englishman named Louis Pilfold built Gleam, which gave our machine the one thing I had never given it: a strict, compile-time type system that catches your mistakes before they run. Its mascot is a small pink starfish named Lucy. I find I cannot object to anything with a starfish.

Not every story ended kindly. A company called Basho built Riak, a distributed database in Erlang that ran, among other things, the central patient records of Britain’s National Health Service. Riak worked. Basho did not. In 2017 it collapsed into receivership, and the code was rescued by Bet365, a betting firm that had already staked its business on Erlang and bought the remains simply to set them free. The software outlived the company. In a language built around letting things crash, that felt like the correct ending.

What I Actually Learned

People ask me for the secret, and they are disappointed by the answer, because the answer is not clever.

We did not set out to build the backbone of the social internet. We set out to stop phone calls from dropping. To do that, we had to accept three things that programmers hate accepting. Hardware fails. Software has bugs. You are not smart enough to anticipate the ways either will go wrong. Once you accept those, the design writes itself. Isolate everything, so one failure cannot spread. Let the broken thing die, so it cannot lie about its state. Have something watching, ready to start a clean copy. Never stop the machine to fix it.

Everything else was consequence. The nine nines were a consequence. WhatsApp was a consequence. Fifty engineers carrying half a billion people was a consequence.

I trained as a physicist, and physics taught me that you do not get to argue with what happens. You describe it and you build accordingly. Every telephone exchange in Sweden knew that in 1986. It took the rest of the software industry rather longer.

Reliability is not writing perfect code. Nobody can. Reliability is building a system that survives your imperfections gracefully, and then going home to dinner while it does.

Afterword

Joe Armstrong died on April 20, 2019, at the age of 68, of an infection complicated by pulmonary fibrosis. The tributes came from well beyond the Erlang world, from people who had never written a line of the language but had absorbed its ideas through Elixir, through WhatsApp, or through the actor frameworks that borrowed from it.

The system he described has kept running without him.

RabbitMQ, the message broker written in Erlang in 2007, still carries much of the traffic between the world’s enterprise systems. A great many companies that have never heard of Armstrong depend on his ideas every time two of their services talk to each other.

Discord, still running on the BEAM, has become the place where developers gather and where a new generation of AI companies launched their products. Midjourney, for a time, existed almost entirely as a Discord bot. Its millions of image requests flowed through Elixir processes descended directly from Armstrong’s telephone switches.

WhatsApp kept building on the foundation. Meta wrote a new type checker for Erlang, called eqWAlizer, so that hundreds of engineers with no functional programming background could work safely inside the codebase. The company then replaced 160,000 lines of C++ media-parsing code with 90,000 lines of Rust, keeping Erlang as the orchestrator and handing the dangerous work of parsing untrusted files to a language that cannot overflow a buffer.

The language’s children grew up. Gleam reached version 1.0 in 2024. The Elixir community built Nx and Axon, and the BEAM now runs machine learning pipelines on GPUs.

And “Erlang: The Movie” is still on YouTube, headsets and all.

The phone calls, as far as anyone can tell, are still connected.

Sources

  1. A History of Erlang, Joe Armstrong, HOPL III (2007), https://dl.acm.org/doi/10.1145/1238844.1238850
  2. Making Reliable Distributed Systems in the Presence of Software Errors, Joe Armstrong, PhD thesis, KTH (2003), https://erlang.org/download/armstrong_thesis_2003.pdf
  3. Joe Armstrong (programmer), Wikipedia, https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)
  4. Erlang (programming language), Wikipedia, https://en.wikipedia.org/wiki/Erlang_(programming_language)
  5. Three Decades with Erlang, Happi Hacking, https://happihacking.com/blog/posts/2023/erlang-history/
  6. The Rise and Fall of Erlang at Ericsson AB, Imad Alihodzic, https://iknek.github.io/blog/the-erlang-story/
  7. Twenty Years of Open Source Erlang, Erlang Solutions, https://www.erlang-solutions.com/blog/twenty-years-of-open-source-erlang/
  8. Erlang: The Movie (1990), Ericsson, https://www.youtube.com/watch?v=xrIjfIjssLE
  9. Erlang: The Movie II: The Sequel (2013), https://www.youtube.com/watch?v=rRbY3TMUcgQ
  10. Write no classes! Joe Armstrong, Hacker News, https://news.ycombinator.com/item?id=5205441
  11. Objects, Smalltalk and Erlang: Joe Armstrong on why Erlang might be the only object-oriented language, InfoQ (2010), https://www.infoq.com/news/2010/07/objects-smalltalk-erlang
  12. Inside Erlang, The Rare Programming Language Behind WhatsApp’s Success, Fast Company, https://www.fastcompany.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success
  13. The WhatsApp Architecture Facebook Bought For $19 Billion, High Scalability, https://highscalability.com/the-whatsapp-architecture-facebook-bought-for-19-billion/
  14. How WhatsApp Grew to Nearly 500 Million Users, 11,000 Cores, and 70 Million Messages a Second, High Scalability, https://highscalability.com/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an/
  15. Scaling to Millions of Simultaneous Connections, Rick Reed, WhatsApp (2012), https://www.slideshare.net/slideshow/scaling-to-millions-of-simultaneous-connections-by-rick-reed-from-whatsapp/52848143
  16. WhatsApp, Facebook, Erlang and realtime messaging: It all started with ejabberd, ProcessOne, https://www.process-one.net/blog/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/
  17. WhatsApp Processed A Record 18 Billion Messages On Last Day of 2012, The Next Web (2013), https://thenextweb.com/insider/2013/01/02/whatsapp-processed-record-18-billion-messages-on-last-day-of-2012
  18. New Facebook Chat Feature Scales to 70 Million Users Using Erlang, High Scalability (2008), https://highscalability.com/new-facebook-chat-feature-scales-to-70-million-users-using-e/
  19. Erlang at Facebook: Chat Architecture, Eugene Letuchy, Erlang Factory (2009), http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
  20. History of Elixir, Practical Elixir, https://practical-elixir.woojiahao.com/history-of-elixir
  21. How Discord Scaled Elixir to 5,000,000 Concurrent Users, Discord Engineering (2017), https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users
  22. Using Rust to Scale Elixir for 11 Million Concurrent Users, Discord Engineering (2019), https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users
  23. Gleam (programming language), Wikipedia, https://en.wikipedia.org/wiki/Gleam_(programming_language)
  24. If you wagered Bet365 would buy up Basho’s remains, you’d be a big winner right now, The Register (2017), https://www.theregister.com/2017/08/25/bet365_to_buy_basho_release_code/
  25. Type-checking Erlang and Elixir, Erlang Solutions, https://www.erlang-solutions.com/blog/type-checking-erlang-and-elixir/
  26. Rust at Scale: An Added Layer of Security for WhatsApp, Engineering at Meta (2026), https://engineering.fb.com/2026/01/27/security/rust-at-scale-security-whatsapp/
  27. Why do ML on the Erlang VM?, Underjord, https://underjord.io/why-ml-on-erlang.html
  28. An Introduction to RabbitMQ, Erlang Solutions on YouTube, https://www.youtube.com/watch?v=Hx7o3pZoy0g

Image Credits

  1. Bank of Strowger selectors from a local exchange, Aachen museum. Túrelio, CC BY-SA 3.0 de, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:HebdrehwaehlerbatterieOrtsvermittlung_4954.jpg
  2. Robert Virding and Joe Armstrong, 2013. Robert Scoble’s Building 43, CC BY 3.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Robert_Virding_and_Joe_Armstrong,_2013.jpg
  3. Ericsson headquarters in Kista, Stockholm, 2010. Holger Ellgaard, CC BY-SA 3.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Ericsson_huvudkontor_Kista_2010.jpg
  4. Ericsson AXD301 ATM switch. Keyhanjkm777, CC BY-SA 4.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Ericsson-AXD-301.jpg
  5. Joe Armstrong, 2009. Yareeh, CC BY 2.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Joe_Armstrong_(3352929823).jpg
  6. OTP supervision tree diagram. Original illustration for this article.
  7. Mountain gorilla, Volcanoes National Park, Rwanda. Charles J. Sharp, Sharp Photography, CC BY-SA 4.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Mountain_gorilla_(Gorilla_beringei_beringei)_female_2.jpg
  8. WhatsApp logo. WhatsApp, public domain, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:WhatsApp.svg
  9. Jan Koum at 4 Years From Now, Barcelona, February 2014. Dan Taylor for tech.eu, CC BY 2.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Jan_Koum_-_Whatsapp_-_4_Years_from_Now_(12791847664).jpg
  10. Elixir logo. José Valim, elixir-lang.org, public domain, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Official_Elixir_logo.png
  11. Lucy, the Gleam mascot. Louis Pilfold, Gleam project, Apache License 2.0, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Gleam_Lucy.svg
  12. Erlang logo. Public domain, via Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Erlang_logo.svg

I Wanted the Phones to Stop Dropping. I Got WhatsApp Instead. was originally published in The Low End Disruptor on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>