riking

Rust's no_std does not have access to a reliable clock.

you can just follow one of the "kubernetes on ec2" guides and adapt it to their apis

electrical/thermal/support power ~= compute power.

Yes, and using larger fans decreases the proportional there. Centralized rectifiers reduces the proportional. Google can make it all the way down to 10% overhead power. That's the point they are making.

Stripe is still "your bank".

Zelle can't be undone if it's done from your account. They just take the money.

Multiple big-O steps faster.

"hmm, you call it an 'enum class' yet somehow I cannot define methods on it"

It'll block the multi-login and require you to fully sign out of everything, THEN log into the other organization account.

Typically, the corporate login will be blocked if you attempt this.

On the other hand, if you make a string of common byte sequences, a couple GB long, and distribute it with every PC...

This is what brotli does.

This is the exact point of the final section of the article, yes.

Nope, you need to run `npm ci` to guarantee that you don't write a new lockfile.

It's because the well got poisoned by marketing teams selling things that were not actually a material improvement over what came before.

What I'm hearing here is "Yes, Google designed their own chip because everything on the market sucks."

ML training is an algorithm that produces an algorithm as output

On many platforms, such as FreeBSD and macOS, the application-exposed ABI for tasks such as "open a file" or "validate this x.509 TLS certificate" mandates that you link to a shared library and call into it using the C calling convention. (libc and Security.framework, respectively.)

Linux is unique in that you can hand-write assembly to perform a system call and have it work across OS upgrades. FreeBSD does not have stable syscall numbers: open() must be a libc call.

The core customer profile appears to be aging startups that know how their software behaves and are currently way over 2k cores on AWS.

The pre-takeover policies, clearly.

Engineer? I thought this was for a leadership position.

Yeah, Intel needs some major direction changes before I'll be comfortable investing in them.

Yup, the correct answer in the face of a network partition is for the PUT to return 500, even though the file really was uploaded. The API handler can't prove success, due to the network partition, so the correct move is to declare failure and let the client activate their contingencies.

The story wasn't wrong, until today. That's why people are celebrating.

To be clear: the "blowing up" would occur when a client observed the new maven-metadata.xml file, but old ("does-not-exist") records for the newly uploaded artifact, correct?

With this update, ordering the metadata update after the artifact upload means this failure is now impossible.

but... it's not current data. the historical data loses value as it ages. Aerial scans of "one month ago" are now less accessible.

Heck, it's a whole 10 sq mm. I'm sure they could work something out to combine multiple smaller projects into one slot, muxed by the supervisor.

Take a look at the Google Titan chip slides for an idea of how to implement this: https://www.hotchips.org/hc30/1conf/1.14_Google_Titan_Google... Video: https://youtu.be/ve_64dbM4YI?t=3089

Specifially, slides 35-40. You burn a feature fuse to unlock manufacturing test features. The device is personalized with a serial number + told to generate private key + record stored in database. Then, the key is locked in by burning a second feature fuse that disables any future writing to those segments.

The project comes with a standard harness around your 10mm^2 design, with provided I/O and a working RISC-V supervisor CPU.

Gmail killed bundles (Google Inbox) though.

That's due to differences in your workload - in e.g. Ruby on Rails, the total uncertainty of which objects are going to survive a request means that jemalloc does a much better job at packing.

I get the impression cloud providers don't "negotiate rates" but rather "build infrastructure" most of the time.