One point I think gets overlooked is that industry responds to the signals it receives. Companies aren’t going to spend millions expanding facilities, buying equipment and hiring skilled workers if procurement quantities swing wildly every few years. When demand becomes unpredictable, suppliers close their doors, experienced machinists retire, subcontractors move into commercial work, and critical manufacturing capability slowly disappears. Years later, we act surprised when production can’t keep up. It isn’t because industry suddenly forgot how to build jet engines. It’s because we’ve allowed pieces of the industrial ecosystem to disappear, and rebuilding them takes years, not months.

I’ve seen a lot of discussion blaming manufacturers. Some criticism is certainly warranted. Quality matters. Delivery schedules matter. Accountability matters. But government also has a responsibility to provide stable procurement strategies and predictable demand. Industry cannot build long-term capacity around short-term thinking.

This isn’t unique to jet engines, either. We’ve watched similar issues emerge in munitions production, shipbuilding, missile manufacturing, and other critical sectors of the defense industrial base. Every time demand spikes, we discover we no longer have the surge capacity we assumed existed. The uncomfortable truth is that surge capacity isn’t something you create during a crisis. You build it years before you need it.

That’s really the lesson here. The article is about engines, but the real story is much bigger. Jet engines are simply where the symptoms are showing today. The underlying issue is that we’ve spent decades treating our industrial base as a cost to manage instead of a strategic capability to preserve.

Yet another remote desktop solution, written in Rust. Works out of the box with no configuration required. You have full control of your data, with no concerns about security. You can use our rendezvous/relay server, set up your own, or write your own rendezvous/relay server.

OpenBMC is a Linux distribution for management controllers used in devices such as servers, top of rack switches or RAID appliances. It uses Yocto, OpenEmbedded, systemd, and D-Bus to allow easy customization for your platform.

Wickwick Ars Legatus Legionis
16y
40,943
Let's for the moment take the proposed cellular service at face value and try to apply a little analysis to see what might work and how it might happen.

As I see it, SpaceX doesn't have much in the way of ground access but has incredibly flexible backhaul. Once there are lots of direct-to-cell (D2C) satellites flying, any phone in any uncrowded region should be able to connect directly to the network. That's pretty cool in that one can contemplate a global cellular network. But it also only addresses low-density areas.

In high-density areas, Starlink's phased-array beam-forming technology may not be able to connect to enough simultaneous users to be an actual cellular provider. Instead they're proposing a smaller number of cells will connect and will aggregate communications from multiple users. That's fine. One still might run into total bandwidth on the backhaul, but the problem of too many simultaneous users is solved.

What I find interesting is the idea that one might have a lot of these cells. If there are 100X the number of satellite aggregate upload points than a traditional carrier has cellular antennas, then each cell only needs to connect to 1% of the normal traffic for an antenna. That means, these cells only need 1% of the bandwidth for cell-to-user communications, right? So SpaceX's lack of spectrum isn't as terrible as it might be otherwise.

So is it feasible to put many more Starlink uplinks than there are cellular towers for a traditional carrier? Gemini tells me Verizon has 130,000 physical locations between macrocell and small cell nodes. Starlink currently has 2.7 million subscribers in the US - or about 20X more than Verizon cells. That suggests that SpaceX has already deployed something to the tune of 20% the amount of hardware that would be needed to have 100X the number of cells (a number I randomly selected as well). Obviously, it would have to be all-new hardware, but that scale isn't an impossible number to consider.

The final issue is the actual bandwidth of the backhaul. I'm sure we've all been in situations where our cellular strength is strong but the data crawls. That's the biggest challenge for SpaceX here. In densely populated areas, there's still just a finite amount of bandwidth that can be served by the nearby satellites. The new v3 D2C satellites can apparently manage much more than the existing ones, but I'm not sure that even that will be enough.

Oddly, this might turn out to be the cellular provider whose best coverage and bandwidth is found away from city centers.