It took 8 months from my first acute back pain problems to the diagnostic.

First, there are two SRE ladders: SRE-SWE and SRE-SysEng. SRE-SWE have the same interviews and hiring bar as SWEs. SysEng have less coding interviews but I think the interview questions are more practical and less algorithm oriented.

Still, SREs are subject to the same rules and policies as SWEs when it comes to submitting code.

And in the end, I don't see why using python on some projects would be a bad engineering practice

From where I sit (SRE), I see a lot of Python which is very much mission critical.

> Some wouldn't have been viable, sure. Others were probably too ingrained in Google's hardware/software ecosystem to be separated out (although I wonder if nowadays everything Google runs on its cloud offering, which would make it simpler, just change the billing).

Google Cloud is built on top of Google's tech ecosystem, not the other way around.

But when he says "the movie is done without CGI shots", he can't ignore that most people will assume the movie is also made without digital editing and compositing.

In the case of Oppenheimer (and other Nolan movies) they use a lot of practical effects but they are eventually digitally composited, color corrected and edited.

> The director was not attempting to claim that there was no CGI in Oppenheimer at all. He was instead stating that there are no shots in the movie that were entirely created using visual effects.

see https://screenrant.com/how-much-oppenheimer-real-cgi/

Exposing "descriptors" is a latter thing, but their default implementation was already a thing before they were visible to python users.

I believe he said this to satisfy his audience, and maybe to try to put pressure on social media so that they cooperate with authorities (to identify leaders and/or limit coordination between rioters).

It's bad because he's still pushing the overton window to the right, pretending this is OK for a the leader of a democracy to consider this. But I don't think they are seriously thinking about cutting social media.

On the other hand, no problem for triggering laughs. It's actually the reverse: you need good direction and good editing (because rhythm matters a lot) to make a joke impactful.

I've never really understood that. Is it shameful to be emotionally affected by a movie, even if you don't really like all of it?

I've seen that a lot about Spielberg movies, and more recently with J.A. Bayona (in particular with The Impossible and A Monster calls).

There is a well known tool named Panopticon (abbreviated pcon) internally and this is not at all what you describe.

(I work at Google)

We don't use drive to store other files. Actually, we don't really "store files" since almost everything we need is remote.

See for instance this discussion: https://news.ycombinator.com/item?id=13561096

But I don't think it changes my point: knowing what/how Google Cloud designs regions or zones is still an implementation detail, what matters is what MTTR they are targeting and this should be known ahead of time.

There are so many "implementation details" that customers are not aware of, because they are always changing, non contractual, or just hard to make sense of, what matters is meaningful abstractions.

I am not saying it's OK if the zones are in the same building or not, I don't know and I was really surprised when I discovered this a few years ago. But this information gives you a mental model of "what could go wrong" that is biased towards some specific risks, and in my experience, relying on these very practical aspects make the risk analysis and design decisions harder to make.

Otho, one thing that may be problematic too (and biasing) is that the common understood definition of a "zone" is the one people know from AWS, so using the same term without being very explicit about the differences will also lead to incorrectly calculated risks. I find the public documentation of Google Cloud too vague in general (and often ambiguous).

Being in the same building is an "implementation detail" from a customer perspective, what matters is the consequences of this decision.

For example, maybe this decision allows for better network connectivity at a lower cost for inter-zones traffic, while, on the other hand, not protecting against some classes of risks.

In the end, you can have a similar multi-zone outage keeping the region down for an extended period of time just because of a bad network config push (see the massive facebook outage in 2021). As a customer, I don't care if it's a flood or a network outage.

Imho, what matters the most is a clear documentation of how these abstractions work for users and the corresponding contractual agreements (costs, SLAs, etc). Users can thus decide if they are ready to pay the price of protecting themselves against an extended outage impacting a single region.

> Regions are independent geographic areas that consist of zones. Zones and regions are logical abstractions of underlying physical resources provided in one or more physical data centers. > (...) > A zone is a deployment area for Google Cloud resources within a region. Zones should be considered a single failure domain within a region. To deploy fault-tolerant applications with high availability and help protect against unexpected failures, deploy your applications across multiple zones in a region.

You should use "region" and "zone" as abstract concepts with shared properties like network topology, local peering, costs, and availability. AFAIK no cloud provider discusses (nor provides guarantees) against specific threats or correlated failures.

There is no guarantee that a given risk will not impact multiple zones, but this risk is lowered by the implementation of various safeguards (for example, rollouts are not happening in multiple regions at the same time).

Google doesn't say "put your VMs in more than one zone because you can be sure we won't have all zones in a region down at the same time", but rather "by putting your VMs in multiple zones in the same region, you can target better SLOs that the SLOs in one zone".

Note that it's different from the concept of "availability zone" of AWS which explicitly says that AZs are physically separated:

> AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.

https://aws.amazon.com/about-aws/global-infrastructure/regio...