A single ~50MW facility dropping off the grid suddenly is something the grid can absorb fine.
The problem is with facility-level grid-responsive safety mechanisms. If the grid sags a bit and several DCs ~simultaneously disconnect, you have a problem. If the DCs going offline causes further instability that causes other facilities to disconnect or grid protection breakers to open, you have a cascading chain reaction
You can find copies of the Mastercard and Visa chargeback manuals online if you do a search, some of them (mildly redacted) from the networks themselves.
No, Stripe did. It is a common misconception that chargebacks are decided by the customer's bank. Actually, there is a multiple cycle back-and-forth process after which they are finally decided by _the network_.
I have worked in card issuing for years and I have seen various submissions by merchants I know that use Stripe where I _know_ that they have an absolute winning case under the network rules that Stripe refuse to contest.
Stripe have decided that fighting most chargebacks is not worth the money, probably becasue they can just pass the costs onto the merchants and let them eat them and the merchants will not go elsewhere.
Scaleway's equivalent only allows connections from ports <1024. This is cute and means only processes with CAP_NET_BIND_SERVICE can retrieve the tokens.
You can do similar with vsock(7) sockets. This also has the advantage that it's harder to trick an application into making a connection to a vsock socket.
Both of these have the weakness that it is not entirely atypical to give processes CAP_NET_BIND_SERVICE so they can listen on "privileged" sockets, but they work against anything without that.
Even better, you could put bootstrap credentials in DMI data or similar, where it'll end up (on Linux) inside a sysfs directory which can only be read by root.
You can fix it by switching to one of the grounded charger heads. Unfortunately in most locales those are only available with an integrated extension cable (or as everyone seems to call them, the "gooseneck" cables)
It happens with other 2-pin chargers on both MacBooks and other laptops, but it depends upon various factors how strong the leakage is
> Sure some few adults can learn languages as fast as kids, but you completely missed my main points around gatekeeping that language skills always has on adults and less so on kids.
Adults in general are actually way faster at learning languages than kids if you control for time actually spent learning the language, but generally adults are required to fit language learning in around a full time job (and are also full of shame/embarrassment)
On the contrary, an object moving across your field of vision will produce a level of motion blur in your eyes. The same object recorded at 24fps and then projected or displayed in front of your eyes will produce a different level of motion blur, because the object is no longer moving continuously across your vision but instead moving in discrete steps. The exact character of this motion blur can be influenced by controlling what fraction of that 1/24th of a second the image is exposed for (vs. having the screen black)
The most natural level of motion blur for a moving picture to exhibit is not that traditionally exhibited by 24fps film, but it is equally not none (unless your motion picture is recorded at such high frame rate that it substantially exceeds the reaction time of your eyes, which is rather infeasible)
Was it actually repeating packets or was it sending out pause frames?
In my experience USB ethernet adapters send out pause frames which shit-tier switches replicate to all ports in direct contravention of the ethernet specifications.
USB A->C cables are supposed to have a Rp pullup on CC1, and leave CC2 disconnected. Huawei made some A->C cables which (incorrectly, and spec-violatingly) have Rp pullups on both CC lines, which is how you signal you're a power sourcing Debug Accessory
Your Pixel 4A is entering debug accessory mode (DebugAccessory.SNK state in the USB-C port state machine); other devices probably don't support debug accessory mode and just shrug.
> In my tests with assorted 24-bit sRGB monitors, a difference of 1 in a single channel is almost always indistinguishable (and this might be a matter of monitor tuning); even a difference of 1 simultaneously in all three channels is only visible in a few places along the lerps. (Contrast all those common shitty 18-bit monitors. On those, even with temporal dithering, the contrast between adjacent colors is always glaringly distracting.)
Now swap the sRGB primaries for the Rec.2020 primaries. This gives you redder reds, greener greens, and slightly bluer blues (sRGB blue is already pretty good)
This is why Rec.2020 specifies a minimum of 10-bit per channel colour. It stretches out the chromaticity space and so you need additional precision.
This is "just" Wide Colour Gamut, not HDR. But even retaining the sRGB gamma curve, mapping sRGB/Rec.709 content into Rec.2020 without loss of precision requires 10-bit precision.
Swap out the gamma curve for PQ or HLG and then you have extended range at the top. Now you can go super bright without "bleeding" the intensity into the other colour channels. In other words: you can have really bright things without them turning white.
Defining things in terms of absolute brightness was a bit of a weird decision (probably influenced by how e.g. movie audio is mixed assuming the 0dBFS = 105dB(SPL) reference level that theaters are supposed to be callibrated to) but pushing additional range above the SDR reference levels is reasonable, especially if you expect that range to be used judiciously and/or you do not expect displays to be able to hit their maximum values on that across the whole screen continuously.
Being that prescriptive is fundamentally unworkable in practice. Propagating unknown attributes is fundamentally what made the deployment of 32-bit AS numbers possible (originally RFC 4893; unaware routers pass the `AS4_PATH` attribute without needing to comprehend it), large communities (RFC 8092), the Only To Customer attribute (RFC 9234) and others.
A BGP Update message is mostly just a container of Type-Length-Value attributes. As long as the TLV structure is intact, you should be able to just pass on those TLVs without problems to any peers that the route is destined for.
The problem fundamentally is three things:
1. The original BGP RFC suggests tearing down the connection upon receiving an erroneous message. This is a terrible idea, especially for transitive attributes: you'll just reconnect and your peer will resend you the same message, flapping over and over, and the attribute is likely to not even be your peer's fault. The modern recommendation is Treat As Withdraw, i.e. remove any matching routes from the same peer from your routing table.
2. A lack of fuzz testing and similar by BGP implementers (Arista in this case)
3. Even for vendors which have done such testing, a number of have decided (IMO stupidly) to require you to turn on these robustness features explicitly.
The thing (Fast)CGI had, that http proxying doesn't (and lots of web frameworks/libraries a bit too tied to http, like go net/http don't) have is the SCRIPT_NAME (path processed so far) / PATH_INFO (path left to handle) distinction
> To resolve this issue, Google could implement two immutable identifiers within > its OpenID Connect (OIDC) claims:
> 1. A unique user ID that doesn’t change over time.
> 2. A unique workspace ID tied to the domain.
1. is the OIDC `sub` claim! I strongly suspect that in those 0.04% of accounts where the anonymous quoted engineer reports that the `sub` claim changed, what actually happened was some provisioning/onboarding/offboarding system resulted in the account being deleted and recreated.
2. is sensible, and is just a versioned version of the `hd` claim.