Doubtful. The issue is probably the service needs to be moved to some framework that isn't deprecated and being turned off, and no one can justify side projects these days that don't sell an AI product.
What’s software that would benefit from running in space? The only thing I can imagine is processing of data generated in space so you need less downlink or can reduce latency, everything else can be calculated wherever you want, no?
I think the point the original guy is hand wavingly getting at is the point of something like this is to avoid the possibility of say a FBI raid or Nuremburgish trials for a vast AI surveillance processing facility hub for other down looking satellites if they were to lose their newly acquired power, or similar technocratic ramblings / ideas like it would survive the end of society.
Its like that scene at the end of Real Genius, "Maybe somebody already has a use for it, one for which it's perfectly designed." Lets look at the facts: Impossible to raid, not under any direct legal jurisdiction, high bandwidth line of sight communications options to satellite feed points that would be difficult to tap outside of other orbital actors, Power feed that is untethered to any planetary grid or at risk of terrestrial actors, etc.
That’s not how it works. Your state is responsible for your activities in space, so if you annoy other countries enough, your own country will regulate you. If they don’t, you could have just built the same thing on the ground in this country.
It's definitely much easier and much much cheaper to send a single rocket there blowing the assembled rather large target into still sizeable chucks of orbital debris than it is to deploy and assemble the thing there in the first place. And there are a few terrestrial actors rather capable of this. More than there are who could make it happen under whatever optimistic assumptions anyway.
In itself, a structure of this size in orbit is an efficient catcher of micrometeorites and orbital debris. Over "non-eternal" timeframes you don't even need a bad actor with good rockets.
Nevermind that in such a case, the eventual fate of these sizeable chunks of orbital debris is to become rods of god ... just without particular steerability.
At this point I'm going to assume that anyone pushing datacenters in space wants to host child pornography. That's the only realistic workload that ticks all the boxes for orbital datacenters.
I don't think it would "solve" little any of the legal issues with Child Pornography (not if the owner lived on earth, at least), but it would make a great and politically convenient target for space to earth weaponry.
Oh, fully agreed. Orbital datacenters don't solve many to any engineering problems either, so I figure its adherents are as much into legal problem solving as they are engineering problem solving.
Well implemented network hardware can have high bandwidth and low latency. But that doesn't get around the complexity and headaches it brings. Even with the best fiber optics, wires can be cut or tripped over. Controllers can fail. Drivers can be buggy. Networks can be misconfigured. And so on. Any request - even sent over a local network - can and will fail on you eventually. And you can't really make a microservice system keep working properly when links start failing.
Local function calls are infinitely more reliable. The main operational downside with a binary monolith is that a bug in one part of the program will crash the whole thing. Honestly, I still think Erlang got it right here with supervisor trees. Use "microservices". But let them all live on the same computer, in the same process. And add tooling to the runtime environment to allow individual "services" to fail or get replaced without taking down the rest of the system.
I think you know as well as I do that it very much does matter. Even if you have an army of engineers around to fix things when they break, things still break.
I think the point is that for Amazon it's their own code and they pay full time staff to be familiar with the codebase, make improvements, and fix bugs. OpenStack is a product. The people deploying it are expected to be knowledgeable about it as users / "system integrators" but not developers. So when the abstraction leaks, and for OpenStack the pipe has all but burst, it becomes a mess. It's not expected that they'll be digging around in the internals and have 5 other projects to work on.
reply