PowerfulWizard

I haven't heard of that being a problem for Starlink, whatever they've done there seems to be working. The Orbital AI would be at a higher orbit but still within LEO which reduces the radiation. I wonder if occasional bit flips even matter for typical AI calculations. Quantization seems to suggest a lot of the lower bits aren't all that important. Either way SpaceX has already had success building systems with commercial-off-the-shelf products in space.

To me the biggest problem of the system is the dependence on launch cost. The more launch cost can be lowered the more viable the system is and the more options there are for solving every problem. But IMO the reason Musk is building this system is to lower launch cost. He needs a project that can fund a high volume of launches and create economies of scale to lower launch cost, the way that Starlink did for Falcon 9.

Musk is deliberately creating a business that needs high volume low cost launch services because in order to get low cost launch high volume is needed, and in order to get high volume a customer is needed. In the same way that Starlink launches were used to create the Falcon 9 economies of scale, the orbital AI will be used to create the Starship economies of scale. He also wants to bet the whole company on this which creates pressure to deliver and not just coast on what they've already accomplished. There are a bunch of related high risk bets but they ultimately connect back to bringing Mars within reach with frequent low cost launch capability.

To remove heat by radiation there's a big benefit to running the GPUs hotter as the radiation will be proportional to the fourth power of temperature. This resource is using 85 deg C versus 60 deg C for OP which will improve cooling performance.

If Nvidia/SpaceX can make the chips run at a higher temperature that would help a lot although I assume it would have already been done if it were possible. Another option is to add a heat pump to raise radiator temperature if the smaller radiator mass can pay for the heat pump mass.

On judging vs. making, also someone has to take time away from development to do code review. If the code being reviewed is written by someone who is involved and interested then at least there's a benefit to training and consensus building in discussing the code and the project in the review phase. The time and energy of developers who are qualified to review is quite possibly the bottleneck on development speed too so wasting review time will slow down development.

For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)

I don't know what I want exactly but I'm thinking along the lines that SQL is already doing a lot so it would make the most sense to start with a database interface and augment from there, to try to build a system to handle all the common forms of durable storage used by applications.

The type of situation I'm thinking about is for example storing a blob in S3, storing metadata and a reference to the blob's path in a database row, sending a message into a queue to trigger some async processing, and updating a cache. It would be nice to be able to do this through a single API or service, and it would be really nice to do all this within some type of transaction abstraction that would allow all operations to pass or fail collectively, really really nice if the whole thing could be pay-as-you and scale horizontally-ish on shared infrastructure without managing nodes or slots or whatever.

I'm not a Postgres user so I don't know how far you can get currently and I should probably look into it in detail. Coordinating blob/ject storage, database, and pubsub operations is a pain point for me presently. I think that overall system design is going to prevent a database-type system from being a good idea for blob storage but I would still like to see someone try to put three systems in a trenchcoat and try to make it work behind one interface.

Very interesting. My dream is to have something like this, a KV-store, a blob store, and pubsub all behind the same interface.

This looks useful, I usually use guestfish to put files into the image before flashing but this could be a lot more flexible.

Here's what I use (as a bookmark):

    data:text/html,<body contenteditable style="line-height:1.5;font-size:20px;">

No save function obviously but this lets me open a new tab and dump some text.

It's true that Relativity Space Terran-R, Rocket Lab Neutron, and Blue Origin New Glenn are under development and are planning first stage re-use although none have flown. And also Stoke Space is developing a 2nd stage re-use solution which SpaceX hasn't solved yet. I think another American company could have a Falcon 9 competitor within 5 years if they really move fast. But they haven't yet reached the stage that SpaceX reached 10 years ago.

SpaceX’s propulsive recovery testing began over ten years ago, meaning a development campaign starting today would be ten years behind SpaceX if they can progress at the same speed. It seems crazy to me that essentially no one is even trying to follow the path demonstrated by SpaceX.

Thanks I was looking for this.

One solution is to have the key on paper in a safe, and then let the lawyer know the key is in the safe. If you die they can drill the safe. The nature of the private key makes digital solutions possible, but they aren't necessary. It doesn't have to be handled differently from any highly valuable small object.