cjsplat

What should they have done?

They put Ghislaine Maxwell in jail then had to wait until her appeal about Epstein's immunity deal made it to the Supreme Court.

The safety stats are per road mile, so it is normalized.

https://waymo.com/safety/impact/

A lot of human drivers blasted through intersections with lights that were out.

There were indeed accidents, and so yes, human cars were in fact stopped in the middle of traffic.

I've heard from English and German visitors that 4 way intersections are frequently disambiguated by a concept of priority roads, and they seem surprised by the relatively smaller number of intersections in SF that stop only one of the roads.

The Tesla example is a single oncoming car, clear right of way, and ample time in a simple 4-way intersection.

The Waymo video has over a dozen cars, at least 6 pedestrians crossing streets (many more on the sidewalks), and is a 5-way intersection.

These are cherry picked examples. Either advertising or propaganda.

I saw plenty of Waymos managing to make it through intersections. They were slow and tentative, but definitely made forward progress.

I think the emergency "phone home" protocol requires a phone, presumably with enough channel capacity for reasonable video feeds. I wouldn't be surprised if the dead in the road Waymos were lacking connectivity.

There is of course also a possibility that the total demand exceeded the number of people at Waymos available for human intervention.

So maybe the point was to consider a different store or route.

Or look at the traffic and decide if you REALLY want to spend an hour or more in gridlock for whatever activity you are considering.

And maybe wherever you wanted to go is closed because they don't have power either.

It is a perfectly reasonable request.

The fact that you acknowledge that is was a "crisis" implies pretty strongly that you understand that a priority evaluation might be useful.

Actually that is specifically not true at Google, and I expect it applies to Waymo also.

People get promoted for running DiTR exercises and addressing the issues that are exposed.

Of course the problem is that you can't DiRT all the various Black Swans.

Yes, that is the same law in California, but so many people drift through stop signs that the guidance is close to meaningless.

In addition, there are 4-way stop signs all over SF and tourists regularly comment on how they work here.

The law is clear - yield to the right, but that is a pretty slow system in congested roads.

The local custom in SF is that someone is usually obviously first, rightmost, or just most aggressive, and opposing pairs of cars go simultaneously, while being wary about left turns.

Of course pedestrians have right of way in California, so someone in a crosswalk gives implied right of way to the road parallel to the person's crosswalk.

The result is 2x or better throughput, and lots of confused tourists.

So ... with the lights out on a Saturday before Xmas, there was a mess of SF local driving protocol, irritated shoppers, people coming to SF for Xmas parties, and just normal Saturday car and foot traffic.

I thought Waymo did pretty well, but as I said, I didn't see any ones that were dead in the middle of the street..

I was driving across the east side of SF and hit a patch of lights that were out.

The Waymo's were just going really slow through the intersection. It seemed that the "light is out means 4-way stop" dynamic caused them to go into ultra-timid mode. And of course the human drivers did the typical slow and roll, with decent interleaving.

The result was that each Waymo took about 4x as long to get through the intersections. I saw one Waymo get bluffed out of its driving slot by cross traffic for perhaps 8 slots.

This was coupled with the fact that the Waymos seemed to all be following the same route. I saw a line of about a dozen trying to turn left, which is the trickiest thing to navigate.

And of course I saw one driver get pissed off and drive around a Waymo that was advancing slowly, with the predictable result that the Waymo stopped and lost three more slots through the intersection.

On normal days, Waymos are much better at the 4-way stops than they used to be a few years back, by which I mean they are no longer dangerously timid. The Zoox (Amazon) cars are more like the Waymos used to be.

I expect there will be some software tweaks that will improve this situation, both routing around self-induced congestion and reading and crossing streets with dead lights.

Note that I didn't see any actually dead Waymos as others have reported here. I believe this is an extreme failsafe mode, and perhaps related to just too much weirdness for the software to handle.

It would be interesting to see the internal post mortem.

Umm - there was a network capable computer and a display.

There was no way to build that for $100 to $200 at that time.

Our Cobalt Networks boxes were about $1k.

Take out the disk, add the display.

Just because the software makes it a thin client doesn't make the hardware cheaper.

This was obviously going to happen once they turned the Village into Portmeirion Hotel.

SF is worse, except for the snow.

You can complain about Boston drivers, but they are pretty predictable compared to SF tourists.

Snow is an issue, but they'll get that done.

Lots of surplus power in any ICE vehicle.

1 HP is over 700 watts.

A few extra HP to generate power isn't any big deal.

You need to distinguish "hardware" and "consumer hardware".

Google wouldn't exist as you know it if they didn't didn't build great data center and network hardware.

Their problems in consumer hardware are not about the hardware specifically. It is about product management and go-to-market.

Depending on the numbers involved, previous generation hardware can waterfall to infrastructure apps that are throughput based.

Things accessed through network APIs and billed per op or in aggregate. Distributed file systems, databases, even build and regression suite systems.

Another key point is that older generations of servers for full custom cloud environments tend to co-evolve with their environments. The amount of power and cooling for a rack may not support a modern deployment.

Especially if a generation lasts 6 years. You might be able to cascade gen N+1 to N, but N+6 may require a full retrofit. A 6 year old data center that is partially filled as individual servers fail may justify waiting for N+7 or even 8 to cover the cost of the downtime and retrofit.

There is a reason Google announced that they are depreciating servers over 6 years and Meta is at 5 years, vs the old accounting standard of 3 years.

Then of course there is a secondary market for memory and standard PCI cards, but the market for 6 year old tech is mainly spares, so it is unlikely to absorb the full size of the N-6 year data center build.

If you are considering a refurb style resale market for 6 year old tech, it is often the case that the performance per dollar is a non-starter because of the amount of power the older tech consumes.

Interesting.

My Kaiser almost doubled from COBRA and coverage went from better-than-platinum to high deductible gold.

Google / SF market.

That 2016 phone couldn't be protected from Spectre family attacks without a ridiculous performance penalty.

What is the point in "security updates" for a CPU that can't be made secure?

While at Sun in the early 2000's, I was part of the due diligence team for an acquisition and had two days to review the entire code base of a 3 year old, 50 person software team.

This was standard practice, and the M&A policies knew that there was no way to actually understand all the code so there was a policy document to describe what to look for.

Of course the red flag things were unexpected 3rd party copyrights and/or license terms in case the code was encumbered.

But "swear words" were on the yellow flag list, in addition to "ToDo", "XXXX", and "Fix Me" types of things.

I remember thinking about places I have been in the past and that the people used those style comments tended to be the better programmers.

I mentioned this to the person leading the evaluation, and was told that point of noticing these kinds of comments was to look a more closely at the nearby code and try to decide if major functionality was missing or being faked.

It all worked out for that acquisition, but I remember being curious about whatever deal had gone bad in the distant past that made them codify this specific practice.

For example see :

https://www.semianalysis.com/p/the-dark-side-of-the-semicond...

I think you are overestimating the value and amount of help from ARM, especially in the more recent Graviton generations, but of course I don't know Amazon's actual chip cost profile.

Impossible to know from the outside.

We know what they are selling it for, but that isn't the same.

True TCO needs to include the cost to develop the chip - after all, that is folded into the x86 price.

If you assume that the Graviton project is $250M per chip design for the 3 iterations, and the online estimates of 1 million chips is accurate, then you need to add about $750 per CPU, beyond the probably $250 per chip fab'ed and packaged.

$1000 per chip gets you a lot of x86 horsepower.

Cloud services have a lot of back end.

Cluster management, file systems, disk / storage systems, network management, database systems.

None of those require user or OS instruction set compatibility for legacy apps that are hard or impossible to recompile.

And most of these applications don't really require gonzo superscalar performance. Add more cores, support more data streams.

If you can eliminate licensing costs for that portion of your fleet, then you only need to expand the ISA compatible portion of your fleet as demanded by paying customers.

As an example, suppose all of a cloud provider's services can migrate to RISC-V. As organic demand for x86 Cloud among customers grows, services can shift incrementally to the cheaper home grown platforms. And since the freed up machines are at least partially depreciated, the cost of these servers is much less than what a customer would pay for new servers on prem. (depreciated Cap-ex, far better Op-Ex).

The interesting question is the transition rate of end customer apps to the new ISA vs the growth rate of locked ISA apps.

Eventually the locked ISA apps portion becomes a lot like the current IBM mainframe business. Very valuable to a very small number of customers.

The only counter for this is if x86 can crank performance per $TCO so far that the non-x86 branch can't compete in business terms, which has historically been the issue with ARM.

And with Coolidge's great persistence, he helped build the foundation for the Great Depression.

It is possible to "press on" in the wrong direction.

Nope.

The Sun-1 MMU was segment and page registers indexed hierarchically off the physical addresses.

It was a full page based system with segment and page level sharing and protection.

The 68000 didn't support restart from page faults, so the runtime model was indeed segment level swapping. (Note - not what Linux decided to call swapping)

The front and rear wheels have different angles of attack on the vector of the car, so they have slightly different friction vectors.

The result can be oversteer (when the back slide more) or understeer (back slides less).

And it can change depending on road conditions, tire inflation, velocity, acceleration/deceleration. And of course changes radically from vehicle to vehicle.

Covered in depth in the movie Cars "You need to turn left to turn right". :-)

Of course the same thing applies to two wheeled vehicles also - see trail braking.

To be clear, the Pixel 2 is unsecurable at reasonable performance against Spectre style attacks.

Might not matter to some.

Yup - this is the correct answer

Sure, but what is UDP bringing to the party then? The pseudoheader?

A reasonable RPC layer could just layer on IP.

Why would NTP be better with retransmisson of stale packets and go-back-N semantics on drops?

Destinations can be described in the packet headers. That is how the current systems work.