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.

It happens with other 2-pin chargers on both MacBooks and other laptops, but it depends upon various factors how strong the leakage is

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)

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)

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.

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.

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.

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.

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.

Back when I worked at a semiconductor company, reading any articles about us was always very funny because it always had more things wrong than right.

From there the worst that can happen generally is that the packets spiral the wrong way around the continent

To the people who are like “What did you expect to happen when you picked a .af domain, are you idiots?”

* Yes, we were aware of the possibility of suspension from the start

* Yes, we were aware that political circumstances could change

* But thumbing your nose at conservative autocrats as an even minor form of protest is fun

* In the end pretty much everyone has migrated out successfully (and I’ll continue to help anyone who remains)

* We’ve all gotten a fun story out of this

I’ve been signalling the probable demise of queer.af to my followers for the past year. We knew the end was coming; we just anticipated it to take a little longer

(To put it bluntly, a big amendment was automatically applied to most UK laws on exit day replacing EU & EEA with UK; and of course in the EU the definition of both of those words changed)

(To put it bluntly, a big amendment was automatically applied to most UK laws on exit day replacing EU & EEA with UK; and of course in the EU the definition of both of those words changed)