Reading Room

SpaceX and Nvidia have announced a satellite called Starmind AI1, built to run artificial intelligence computing in orbit. It is a headline grabbing idea: no land to buy, no fight for electricity from the power grid, no water needed to cool machines down. But a close read of the plan shows why that headline hides a basic, unsolved problem. Space is one of the hardest places you could pick to cool a computer.

The numbers are big. Each Starmind satellite will stand 30 meters tall with a 75-meter solar panel wingspan, carrying Nvidia's newest chips, the Vera processor and the Rubin graphics chip, in an orbit about 600 kilometers up. The satellites will talk to each other and to Earth using Starlink's laser links. SpaceX says the onboard computing will draw up to 250 kilowatts at its peak and 175 kilowatts on average, all powered by the sun. Getting each 2.3 metric ton satellite into orbit needs SpaceX's Starship rocket, which is still not flying reliably. The eventual goal, per SpaceX, is a million of these satellites, built at an 11 million square foot factory still under construction in Bastrop County, Texas.

Here is the physics problem. Space is not uniformly cold. Whichever side of a satellite faces the sun heats up. The side facing away eventually cools toward near absolute zero. The key word is eventually. On Earth, machines shed heat mainly through air and water: fans, cooling towers, liquid systems. None of that works in a vacuum. The only way to get rid of heat in space is to radiate it away as infrared light, and that is a slow process. That creates a hard trade off: more computing power means more radiator surface area, which adds weight, which limits how much you can launch. Each Starmind satellite will carry a deployable liquid radiator measuring 160 square meters. Nobody has confirmed which liquid it will use, though a professor at the University of Birmingham expects ammonia, the same coolant already used on the International Space Station. Whether that scales up to a full AI data center's worth of heat is untested.

Networking has its own limits. The plan leans on Starlink's laser links between satellites, rated at up to 25 gigabits per second (a measure of data speed) across distances up to 4,000 kilometers, with roughly 25 milliseconds of delay. That is fine for sending results back to Earth. It is not the same as the tightly wired, extremely low delay connections that link chips together inside a ground based AI supercomputer, which is what training a large model actually needs. A moving constellation of satellites, laser links that need to reacquire their target, and real physical distance make that kind of tight coordination far harder in orbit. Do not expect large scale AI training to happen up there soon. Relaying finished results is the realistic use.

Then there is debris. A bad actor could target one or more satellites, creating space debris, whether by accident or on purpose. Several countries, including the US, Russia and China, already have weapons built to destroy satellites, and a single nuclear detonation in orbit could disable many satellites at once through the resulting electromagnetic pulse.

The lesson worth carrying past this one story: a big AI infrastructure announcement can sound solved when the actual engineering, cooling, networking, physical safety, is still an open problem. Worth asking the same question of the next headline grabbing AI buildout: has the hard part actually been solved, or just described?

Outside your usual reading: this is a programmer's close look at Principia Mathematica, the 1910 book by mathematician philosophers Alfred North Whitehead and Bertrand Russell. The book is famous for taking roughly a thousand pages of tightly detailed proof just to establish that 1 plus 1 equals 2. This piece argues that is the wrong reason to care about it. The real value is a small set of ideas laid out in the preface and first chapter, ideas that still sit underneath how modern computer science works.

The authors set out to find the smallest possible set of basic notions from which all of mathematics could be built, then prove those notions were enough. If the book were published today, most of that thousand pages of formal proof would likely be pushed into an appendix or checked automatically by software, what is now called a theorem prover, a program that checks logical proofs step by step. What actually matters, the piece argues, is the setup: the handful of core ideas, not the mechanical proof that follows from them.

One of those ideas is the propositional function: a statement built around a variable, such as Principia's own example x equals x, that only becomes a definite true or false claim once an actual value is asserted. This is an early ancestor of what programmers now call a function: a piece of logic with a placeholder that only means something once you plug in a real value.

The book also draws a distinction that programming languages still rely on: the split it makes between what it calls real variables and apparent variables, what we would now call free and bound variables. A free variable, like the x in x equals x, is still open, standing for any value. A bound variable, tied down by a phrase like for all x, is closed: it makes one single claim about every possible value at once. That distinction between an open placeholder and a closed one is the same idea behind how programming languages decide which part of the code a variable name is even visible in.

The book even compares its for all x notation to a definite integral from calculus, where x is used inside the expression but disappears once you have the final answer, something the piece calls a striking early example of the idea. On proving something exists, the book's method was blunt and still holds up: the only real way to prove something exists is to produce one actual example of it, a witness, rather than argue abstractly that one must be out there somewhere.

This is a pulse check on how developer tools evolve, useful background if a future project ever touches a cross platform app (one codebase that runs on phones, web, and desktop). Google's Flutter framework shipped version 3.47, and the headline change is structural: it split its two visual design systems out of the core toolkit into their own standalone packages.

Flutter apps are built using one of two visual design systems, Google's own Material look or Apple's Cupertino look. Until now both were bundled inside the core Flutter toolkit, so they only got updates on Flutter's slower, quarterly release schedule. As of 3.47, the material_ui and cupertino_ui packages have reached version 1.0 on pub.dev (Flutter's library store) as optional add ons, and from here they will ship fixes and new components on their own weekly schedule instead of waiting for the next full Flutter release. The core toolkit still includes the old bundled versions for this release, so nothing breaks if a project does not opt in right away.

Splitting the two apart gives one concrete benefit Flutter's own team highlights: a project can pick up the newest Cupertino and Material widget styles without upgrading its entire Flutter version.

Developers who want to move over run dart fix --apply, which rewrites their imports automatically. There is one known early bug: if the tool has trouble updating a project's pubspec.yaml (the file that lists a project's dependencies), the fix is to manually run flutter pub add material_ui, and cupertino_ui if the project uses it, then run dart fix --apply a second time. The old versions inside the core toolkit are not gone yet: Google has scheduled their formal deprecation for the Fall stable release in November, giving developers about three months to move.

The change also affected translations. Support for translated text in Material and Cupertino widgets used to live in a separate flutter_localizations package. It has now moved inside material_ui and cupertino_ui too, so setting one shorter line, GlobalMaterialLocalizations.delegates, now pulls in the Cupertino and Widgets translations automatically, replacing what used to take three separate lines of setup.

The release also turns on Impeller, Flutter's newer graphics engine, by default for desktop apps, which should make desktop rendering faster and smoother. Flutter Widget Previews, a tool for seeing interface changes without a full rebuild, moved from experimental to stable. The team has also started preparing its build pipelines for Apple's next wave of updates, Xcode 27, iOS 27, and macOS 27, all expected this fall.

The bigger signal here is process, not any one feature. Google is deliberately splitting Flutter's design libraries out so it can ship fixes weekly instead of quarterly, the same trade off other cross platform frameworks have made to keep pace with fast moving mobile platforms. If a project ever touches Flutter, budget time to run the migration command before November, when the old bundled libraries are deprecated.