_ea1k

That depends on whether Gemini CLI counts. I've had generally bad experiences with it, but it is free for at least some usage.

YMMV, but I've had pretty good luck with just force closing it and launching again when getting errors like that. It doesn't necessarily mean the whole environment is corrupt, even though that is the recovery option that is presented.

It is very unreliable though. I hope Android 17 improves it, as other than the restart issues, I've generally found it to be very functional.

You know what's weird? This is a company that has been using the fleet api for quite a while now to monitor non-professional drivers using FSD on their daily commute, often while distracted doing other things. The latest versions even allow some phone usage.

And yet people are skeptical. I mean, they should be skeptical, given that the company is using this for marketing purposes. It doesn't make sense to just believe them.

But it is strange to see this healthy skepticism juxtaposed with the many unskeptical comments attached to recent Electrek articles with outlandish claims.

Sure, but we now have millions of miles of Tesla autopilot and FSD data in the hands of untrained and often semi-malicious end users as well. Out of that data, we've gotten flawed reports from Tesla claiming that it is dramatically safer, as well as independent renormalization that showed it to be at best about the same.

None of those millions of miles resulted in a smoking gun showing the cars to be even 2x worse.

And yet a badly written blog thinks they've shown them to be 3x worse with professional monitors? This is indeed an extraordinary claim.

I've always assumed that the answer to this would be no. However, I also always assumed that a huge space-based internet system would be both expensive and impractical for bandwidth and latency.

Starlink has largely defied those expectations thanks to their approach to optimize launch costs.

It is possible that I'm overlooking some similar fundamental advancement that would make this less impractical than it sounds. I'm still really skeptical.

Yeah, I remember being amazed at the immediate incremental compilation on save in Visual Age for Java many years ago. Today's neovim users have features that even the most advanced IDEs didn't have back then.

I think a lot of people in the industry forget just how much change has come from 30 years of incremental progress.

TBH, the comments here amaze me. The claim is that a human being paid to monitor a driver assistance feature is 3x more likely to crash than a human alone.

That needs extraordinary evidence. Instead the evidence is misleading guesses.

Good analysis. Just over a month ago, Electrek was posted here claiming that Teslas with humans were crashing 10x more than with humans alone.

That was based on a sample size of 9 crashes. In the month following that, they've added one more crash while also increasing the miles driven per month.

The headline could just as easily be about the dramatic decline in their crash rate! Or perhaps the data is just too small to analyze like this, and Electrek authors being their usual overly dramatic selves.

It is sad, but big sedans do not sell well and the X really needed to be replaced with something completely different. There are now several other 3 row EV SUVs competing with it, and even low volume ones (eg, R1S) outsell it easily.

Don't be surprised if something else takes its place as they do need something larger than Y and less expensive than X was.

It was estimated at >200k/year, but in reality is well under 50k/year. I'd say that is a failure compared to their guidance.

They are almost exclusively focused on autonomous cars, humanoid robots, and energy (batteries now, maybe more solar manufacturing later).

As much as I dislike it, I can't disagree with the business case here. They already have >300k monthly subscribers at about $100/month. That business will grow rapidly from here as well as the robotaxi business itself.

Within 2 years, this business will look radically different just because of these two changes.

S and X were a small fraction of Fremont already. The plant can do >500k units per year, but S/X were closer to 20k.

It sounds like this would be giving ~5% of the factory space to Optimus production, which seems reasonable.

A big part of it is insurance. Family coverage can easily cost $15-20k per year in the US. Avoiding the need to pay for this out of pocket drives a lot of people into less than optimal job dependence.

I'd say it is a success at being useful, but yeah it does seem like the code itself has been a bit of a mess.

I've used a version that had a bd stats and a bd status that both had almost the same content in slightly different formats. Later versions appear to have made them an alias for the same thing. I've also had a version where the daemon consistently failed to start and there were no symptoms other than every command taking 5 seconds. In general, the optimization with the daemon is a questionable choice. It doesn't really need to be _that_ fast.

And yet, even after all of that it still has managed to be useful and generally fairly reliable.