Hacker Newsnew | past | comments | ask | show | jobs | submit | eldenring's commentslogin

Cooling is relatively easy, you just need radiators which are passive, and essentially reduce to a launch cost penalty. You are right that they can't be serviced, but that is missing the point of orbital data centers. The whole point is that you can build hundreds of thousands of these in a factory and launch them in a scalable manner. The power, cooling, etc. comes for "free". In the long run, as the cost of the chip, launches, etc. goes down, orbital data centers will scale better terrestrial ones.

As a side note, I don't understand why I keep seeing these wrong arguments on HN repeatedly. Like everything mentioned in this thread can easily be fact checked. Radiative cooling is solved, launch costs are going down, so power costs will pay themselves back very quickly, etc.

You can argue about specifics, like chips will get more sophisticated + power efficient and fabrication will be the true longterm bottleneck, or SMRs/fusion could reduce energy bottlenecks, but talking about cooling as if convective cooling is the only option is just nonsensical.


"you just need radiators which are passive

"Just" is doing a lot of work there. SpaceX is planning to launch 100 GW of compute annually, that comes with ~ 2.5 square kilometers of radiator (assuming an optimistic 800K radiator temp and emissivity of 0.9, double sided)

Go for advanced carbon composites, you can do that with just 5,000 metrics tons or so of material. That's 34 starship launches just for the radiators. We haven't solved assembly, we haven't brought up power panels or core compute. Planned launch cadence that SpaceX hopes to reach end of this year: 12/year.


radiators about the same size and weight as solar panels will do the trick

there is already a h100 in orbit

1GW of compute is a lot in 2026. comparing 100GW of annual compute to SpaceX 2026 goals does not make sense

if Starship launch cost predictions are accurate, data centers in space will happen within 10 years


> The numbers are brutal. Starcloud’s own white paper estimates that a two-sided radiator held around 20°C would emit only about 633 watts per square meter, over 1,000 times slower than water cooling of AI chips on Earth. So, a puny 1-megawatt orbital data centre, 1,000 times smaller than the gigawatt scale of hyperscale data centres on Earth, would need about 1,600 square meters of radiator, an area roughly the size of a hockey rink.

1GW needs a pretty big area for radiation.

And in space your data centers is hard to defend against foreign actors


chips run way hotter than 20C, and radiative cooling scales to the fourth power of temperature. check the math


Don't you think a company like Starcloud has a reason to put 20C in their white paper?


Yes, to get funding.


The whole point is that you can build hundreds of thousands of these in a factory and launch them in a scalable manner. The power, cooling, etc. comes for "free". In the long run, as the cost of the chip, launches, etc. goes down, orbital data centers will scale better terrestrial ones.

How is this not true for terrestrial/ocean deployment as well? It will ALWAYS be easier to shed heat on Earth than it will be in orbit. Convection, conduction, radiation... in space, you only get the last one.

So take the same unattended hardware you were going to launch into orbit, and put it on a container ship instead. You'll be better off in every way. If it makes you feel better, lie and tell everyone that you launched it into space. Building orbit-capable data centers might make sense, but actually launching them never will.


> and essentially reduce to a launch cost penalty.

Are you arguing that all this is technically possible or something? The whole point is that the costs would dwarf the gains.

> You are right that they can't be serviced, but that is missing the point of orbital data centers.

Pointing out a downside of something isn't ever "missing the point".

> The whole point is that you can build hundreds of thousands of these in a factory

In an Earth-based factory, right? Am I to understand that we can't build hundreds of thousands of regular Earth-based datacenters in a factory?

> and launch them in a scalable manner.

Wanna bet that launching something to space will always be a few orders of magnitude more expensive than shipping it somewhere across the planet?

> The power, cooling, etc. comes for "free".

Unlike on Earth, where you pay for sunshine? Or is cooling "free" in space but not on Earth? Lol?

> In the long run, as the cost of the chip, launches, etc. goes down, orbital data centers will scale better terrestrial ones.

The costs of the chips will get lower in space than on Earth?

The costs of launches will, again, become cheaper than terrestial transport?

> As a side note, I don't understand why I keep seeing these wrong arguments on HN repeatedly. Like everything mentioned in this thread can easily be fact checked. Radiative cooling is solved, launch costs are going down, so power costs will pay themselves back very quickly, etc.

The question isn't whether this is physically possible, but why you'd want to do it instead of an Earth-based datacenter. It's all downsides basically.


My back of the envelope maths:

Suns energy at ISS is about 1.4KW/m2 Solar panels about 35% efficient but let’s say 50% for fun

700w/m2, or about one H100 worth per sq metre (hey, I could run my own H100 off a roof top panel !!)

We want a small 70MW data centre - which is 100,000 times the size so 100,000 m2 or an array 316mx316m or 15 football pitches

Then as it’s energy in and energy out you need radiators on dark side of same size

The ISS is ~ 2000m2, so that’s fifty ISSes

I mean it’s physically possible. But the engineering, the space launch costs they are staggering. And the upside is … Im not sure

All the win seems to be is free sun energy, but a data centre in Texas or Nigeria just needs about twice the solar panels and some big ass batteries.

Im not costing that out but, honestly it seems like a marketing pitch or a really obscure need to put compute beyond the reach of governments.


> Radiative cooling is solved,

By that logic, climate change is also solved, just built a giant radiator.


> Radiative cooling is solved.

This is emphatically not true at any scale in which this scheme makes sense. Be careful with including too many Musk boosters in your information diet.


Did you read the whole thing? he is clearly talking about having lost focus which is directly in agreement with your take on the Metaverse.


If that was the case then he wouldn't have continued doubling and tripling down on these same product decisions for many more years.

Ask anyone at Meta and they will readily agree that Boz is among the most incompetent and unserious leaders in tech. His only qualification is being Zuck's friend, and that shields him from all criticism. At a more "focused" company he would have been fired a decade ago. As it stands he lost the shareholders $150B+ (and counting), dipped from the metaverse org, and got rewarded with a new role overseeing the shiny new thing - AI.


> As it stands he lost the shareholders $150B+ (and counting)

When you put it like that, I kinda warm to the guy


2-3x is completely dwarfed by the remaining improvements in training which is still in its infancy relatively


Unless there's a new paradigm, scaling up is all they can do to improve performance. They've shrunk down all the way to 1-bit models and all the low-hanging fruit is gone. There's no way for them to get much smaller, so they have to get bigger and faster to meet expectations.


This hasn’t been true for the past 2 years


Is this based on an assumption that Opus 4.7 & co are equivalent or smaller to Opus 4.5 & co? I highly doubt the advanced models (Opus, Pro, etc) aren't biggen than the standard ones (Sonnet, Flash, etc) and fairly sure newer models are bigger than older ones.


this is just not true at all, there are massive leaps from algorithms, data, etc. every year. scale is one axis of many and you need to get them all correct.


What novel data hasn't already been used in training? What new algorithms are there? Can you post some links so we can read about them?


Probably, but at some point we're very likely to run out of significant training improvements and it's not clear that we'll see that point coming from a long way out.

Likewise it's probably dwarfed by improvements in how we make dram - continuing the roughly exponential (maybe a bit less recently) scaling of chips - but not necessarily.

The 2x from returning to previous costs is interesting because it's practically guaranteed, and it's on top of everything else. We're just currently "overpaying" (relative to the stable market price) for the manufacture of dram because of a sudden increase in demand.


my reply from the other thread fits here too:

> this is just not true at all, there are massive leaps from algorithms, data, etc. every year. scale is one axis of many and you need to get them all correct.


I'm guessing they had a significant revenue spike from gpt 5.4 and gpt 5.5 being so good at coding, and hiccups at anthropic making it easier for programmers to try the models.


Its just not a thing to consider and doesn't happen often.


This article makes 0 sense. Its not up to billing or computer systems or ease of use or anything else that matters. The question is will the scaling laws, which in the asymptote are likely the laws of physics, hold up in converting energy to smarter models. Its not really up to anyone, the labs or developers, to choose if local or remote models will be the norm.


CompactStr doesnt have any additional runtime overhead iirc right? So in theory you can drop it in everywhere even when you expect > 25 chars. Maybe an extra branch in the >25 char case?


SSO does have overhead. Firstly, on every access you have a branch. Secondly, and more severely, the "most general" umbrella type that all string methods are defined on is a string slice, and whereas conversion from `String` to `&str` is literally a no-op, SSO strings require work to be done to convert them to string slices. Furthermore, note that in the (surprisingly common) case where the string is zero-length, String already skips the allocation, same as an SSO string.


> Folks are now starting to ask difficult questions about their burn rate and revenue.

this view isn't updated correctly post-claude code and codex. there will clearly be sufficient demand.


Seriously? One release is all it took to turn the whole ship around?


I think the coding market will be much larger. Knowledge work is kind of like the leaf nodes of the economy where software is the branches. That's to say, making software easier and cheaper to write will cause more and more complexity and work to move into the Software domain from the "real world" which is much messier and complicated.


Yes, and the same thing will happen in non-coding knowledge work too. Making knowledge work cheaper will cause complexity to increase, more knowledge work.


I don't think so, the whole point of writing software is it is a great sink for complexity. Encoding a process or mechanism in a program makes it work (as defined) for ever perfectly.

An example here is in engineering. Building a simulator for some process makes computing it much safer and consistent vs. having people redo the calculations themselves, even with AI assistance.


The history of both knowledge work and software engineering seems to be increasing in both volume and complexity, feels reasonable to me to bet on both of those trendlines increasing?


Yes, I have a theory - that higher efficiency becomes structural necessity. We just can't revert to earlier inefficient ways. Like mitochondria merging with the primitive cell - now they can't be apart.


Because there's a realistic chance this is the only important software technology moving forward, and commoditizes Metas's entire business which is software.


Meta’s business is human attention, human connections, and all derived data. They can use AIs for their systems, but the question is why do they feel the need to spend billions on training and running their own frontier model


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: