Unroasted6154

Why wouldn't they make it for external payload if they get the cost per kg lower than F9? Running starship only is going to be cheaper than running both rockets, except if the economics of starship are worse (in which case, it would not be used for starlink either).

It's not a service shutting down though. It will still work fine for a while and it there is a critical security patch required, the community might still be able to add it.

It's a bit weird to present it as an alternative to S3 when it looks like a persistent cache or k/v store. A benchmark against Redis would have been nice for example. The benchmark for rocks DB is also questionable as the performance depends a lot on how you configure it, and the article's claim that it doesn't support range read doesn't give me confidence in the results.

Also for the descried issue of small images for a frontend, nobody would serve directly from S3 without a caching layer on top.

It's a interesting read for fun, but I am not sure what it solves in the end.

Never said it was easy or desirable for most companies.

But there is only so much a cloud provider can guarantee within a region or whatever unit of isolation they offer.

You are supposed to build multi regional services if you need higher resilience.

Don't you have user profiles in Pixels? I can create another user an switch. Just not super convient. Work profiles are actually pretty good good... For work.

There is way more Java and C++ than Go at Google.

You can do that for new binaries. For existing ones you can't really or you get in a worse place for a long time.

The main issues to me seem to be that the code was not gated by a flag when it was not ready to be used, thus skipping a lot of the testing / release qualification.

The issue was that a bug got triggered globally within a few seconds and all the things that led to that. The fact that is was a null pointer exception is almost irrelevant.

If you are talking about the issue for migrating to rust, well re-writing hundred of million lines of lines of code never makes sense.

For all practical purposes impossible at this scale. The issue is not really the bug tbh.

Probably C++ or java though.

What makes you think it was completely untested? The condition that triggered the null pointer exception was obviously not tested, but it doesn't mean it didn't have tests or even 100% unit test coverage for the coverage tools.

In addition it looks like the code was not ready for production and the mistake was not gating it behind a feature flag. It didn't go through the normal release process.

Good luck re-writing 25 years of C++ though.

Google will give them more money if they win the lawsuit.

Building a fab is pretty much impossible. You can give TSMC a ton of money to build more capacity, but so can everyone else in the space.

I've mostly had non-graded homework in my studies because cheating was always easy. In highschool they might have told your parents if you don't do homework. In university you do what you want. It's never been an issue overall.

One simple way is to keep only a few days / weeks of (immutable) keys backups. You can always stop the deletion of you have a big issue. If the law says you have 14 days to delete all data, you keep only that much backups.

That's how GAFAMs size companies do it. They need to comply with European regulations for data deletion, and there are very few other options.

Was that an actual SVG?

It possible with crypto shredding. You store everything encrypted with one key by customer. When you want to delete you erase the key. The data becomes unusable everywhere (backups included). Then a job periodically garbage collects data without a key, but that's more for cost saving.

Big companies do this but it requires some technical maturity. If you operate in Europe you have to implement proper data deletion. I would be more worried about small companies that large ones tombe honest.

Loki was much cheaper to run in my experience, using S3 storage. And you could scale the parts you needed dynamically in K8s.

Elastic was kind of a resource hog and much more expensive for the same amount of data.

That might be dependent on your use case though.

Both models mentionned in the article are available, Gemini robotics for partners only, and Gemini robotics ER in private preview.

It can be very useful for grid stabilization at the scale of seconds to minutes (both with charge and discharge).You don't need that much capacity to do that.

They do have to be wide open and close pretty fast once the end on the booster had passed them.

The rocket is not filled until the last minute, by fueling arms on the tower. And the weight is like 90% fuel, so it makes a pretty big difference.

They said in the event that they will first deliver 3s and Ys. They just add a 2 seater and 20 seater van later to fill other use cases.

The mentionned the show that they will have autonomous versions of 3 and Y first.

If you use something like ArgoCD (and maybe also Argo Rollouts) you can do the diffing from Git automatically but either put a manual validation step where you have a chance to review the diff or implement some gradual rollout strategy. Also, it's probably wise to use a branch/tagging strategy and not read from head.

Bottom line is: GitOps means the source of truth is Git and automation makes sure to avoid drifts. You still have to have a rollout strategy and schedule that makes sense for your usecase.

You lose people, expertise and organizational structure. Those are more important than the "plans of the rocket". Not to mention, would nowadays engineers be able to work from the methods of back then? A lot of stuff would be faster to redesign from scratch (all the software and electronics for sure).

NASA a radically changed it's focus an functions since the space race. Suppliers have changed too.

They could do it again with enough funds and time, but it will take many years.