ucarion

That makes sense. The weirdness of https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-char... makes more sense now. Reminds me of DynamoDB capacity units.

Really, really great article. The visualization of random writes is very nicely done.

On:

> Another issue with network-attached storage in the cloud comes in the form of limiting IOPS. Many cloud providers that use this model, including AWS and Google Cloud, limit the amount of IO operations you can send over the wire. [...]

> If instead you have your storage attached directly to your compute instance, there are no artificial limits placed on IO operations. You can read and write as fast as the hardware will allow for.

I feel like this might be a dumb series of questions, but:

1. The ratelimit on "IOPS" is precisely a ratelimit on a particular kind of network traffic, right? Namely traffic to/from an EBS volume? "IOPS" really means "EBS volume network traffic"?

2. Does this save me money? And if yes, is from some weird AWS arbitrage? Or is it more because of an efficiency win from doing less EBS networking?

I see pretty clearly putting storage and compute on the same machine strictly a latency win, because you structurally have one less hop every time. But is it also a throughput-per-dollar win too?

Such a cool website.

In case anyone else was looking for it, this article from the same author covers the more algorithm-y question of how a camera body decides to actually use these motors when you press the "focus" button: https://exclusivearchitecture.com/03-technical-articles-DSLR...

I can't find any articles on how a camera body decides what is and isn't a desired subject. I'm guessing there's some amount of machine learning-type stuff involved in that, seeing as how they can detect human (and bird?) faces?

You could rent a car out of Auxerre, but don't count on being able to get by in rural l'Yonne without one.

What does "cooked" mode mean in the context of this article?

I didn't know RFCs are being written with xml2rfc directly anymore; I was under the impression most work was now happening through https://github.com/cabo/kramdown-rfc, which lets you hand-write markdown instead of hand-writing XML.

And then https://github.com/martinthomson/i-d-template, though a bit elaborate, does automate a lot of IETF stuff, including use of kramdown-rfc.

The ruling comes down to the definition of "property", and the court finds that Tornado Cash's immutable smart contracts aren't property. Treasury can only sanction property under the law. Tornado is a tool that nobody controls, and which OFAC cannot sanction.

> Indeed, when someone has a property interest, he or she typically has the “rights of possession and control.” And “one of the most essential sticks in the bundle of rights that are commonly characterized as property” is “the right to exclude others.”

> The immutable smart contracts at issue in this appeal are not property because they are not capable of being owned. More than one thousand volunteers participated in a “trusted setup ceremony” to “irrevocably remov[e] the option for anyone to update, remove, or otherwise control those lines of code.” And as a result, no one can “exclude” anyone from using the Tornado Cash pool smart contracts.

Immutability is what makes this whole thing work for Tornado. The ruling is basically a whole explanation of why an immutable smart contract isn't property, isn't a service, isn't a patent, it isn't anything Treasury can touch. In fact, it's not even a "contract" (no counterparty).

But the mutable aspect of Tornado -- the optional gas fee anonymization middlemen, who are registered via a mutable smart contract -- they're still in the rough. Which makes the rally in the TORN coin those middlemen get paid in all the weirder.

It seems pretty clear to me that Treasury can sanction all of those Tornado relayers, because relayers have control over their actions; their participation happens through a mutable smart contract, and they can stop at any time.

Almost every calendar system has a similar trick: https://en.wikipedia.org/wiki/Intercalation_(timekeeping)

The west inherits from the Romans, and Julius Caesar standardized away the Roman intercalary month by glomming it into Feburary. Before that a "priest" (the pontifex maximus) (in scare-quotes because it was a political office) would add that month on an ad-hoc basis. Not so different!

tzdb often has the answer, and it's almost always because everyone used to do local solar time (i.e. on average, the sun is at the top of the sky at noon) until convenience (i.e. train and plane schedules) required an offset friendlier to mental math.

I mention Asia/Kathmandu instead of Pacific/Chatham or Australia/Eucla mostly because it's not one of those "exotic birds / kangaroos outnumber humans 5:1" kinds of places.

If you go by the wtf-ness of the comments on a tz, Asia/Riyadh has gotta be up there. But contemporarily it behaves as `<+03>-3`, which is vanilla.

You should read Matt Levine's Money Stuff! I think his is the tone I roughly was going for here.

Thanks! The irony is not missed on me. I think I have the dates internally in the article metadata, just didn't set up my Hugo templates to display it. TODO!

In theory, this can be expressed in tzdb. Obviously, it will cause problems.

The only really important assumption not obviously present in TZif's data format is that when you go from a local time to a UTC time, there can only be up to two possibilities. A lot of software works on that assumption, for instance java.time.LocalDateTime has a withLaterOffsetAtOverlap():

https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...

That implicitly assumes that whenever it's ambiguous what 2:30AM means, you can only have two possible solutions (pre- and post-DST). If a timezone were ever to manipulate its offsets so that there were three or more solutions (such as if they did a "fall back" at 2:00AM and then 2:15AM or something), a lot of stuff would be unable to represent that.

Japan does something similar in the context of things that close after midnight: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...

FWIW, the English-speaking world used to switch years on March 25: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...

Neither of these are technically things that tzdb can even talk about. They're concerned with civil time, not calendars or other "reckoning" problems.

This is really neat!

Separately, I'm a little skeptical of the tzdb's endeavor of even thinking about pre-Unix-epoch stuff. The bug-to-utility ratio of that stuff doesn't seem to be there. `zic` is where most of the ugly gnarliness of tzdb lies, and I sometimes feel that it would have been better if `zic` weren't an artifact others could depend on.

I'm not sure if being from the north of France changes things, but I think the Renaud song is much more familiar to folks I know than the wind.

I think this is the website for the FBI's sting? https://nexfundai.com/

I find it interesting that they made up both "NexFundAI" and "NextFundAI" (with a t) with some sort of made-up relationship between the two.

For anyone curious about the real critique of utilitarianism behind the joke, it's called a utility monster:

https://en.wikipedia.org/wiki/Utility_monster

Oh don't get me wrong at all -- deprovisioning is huge indeed!

I'm not going to misleadingly edit my initial comment, and your comment is fair. I said "just" when I should have said "precisely". As in, I was already talking about how SAML interacts with "Bob from Sales got fired, probably should kick him out of the CRM". SAML gives you "Bob can't log into the CRM ever again", SCIM gives you "... and his CRM user and sessions are immediately revoked".

To be clear, SSOReady also has a "SCIM made easy" API, we definitely know about and care about helping people implement SCIM: https://ssoready.com/docs/scim/scim-quickstart

What I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState.

For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.

It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.

That's a very fair point! I'm going to add mention of SCIM / directory sync. I feel like it's easiest to stick that into the CISO section, since a big part of SCIM is just the deprovisioning aspect?

And yeah, you're right -- Okta, for example, doesn't let you add SCIM to an OIDC application. It's unfortunate -- there's no deep technical reason you can't mix OIDC and SCIM -- but it is the world we live in.

Yeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status.

FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.

FWIW back in the day, samltest.id was a dummy IDP, whereas sptest.iamshowcase.com is a dummy SP. You could hook these two up to each other and see the whole flow.

I'm working on that at the instant (I wrote this article). Sadly the samltest.id squatter wants at least $15k, super lame. dummyidp.com it is!

You'll be pleased to know that we're not making a ton of progress on the "split things over N docs" front.

In recent years IETF has given us SCIM (which is sort of like "offline SAML") which is 3 RFCs (goals, schemas, http stuff), and of course JWT is actually part of a series of like 9 RFCs (including JWT, of course, but also JWK, JWS, JWE, JWA, ...).

I think there's this phenomenon where people who are like "dude, nobody cares, just do the dumbest possible thing we can get away with" aren't the people who decide to get involved in writing security specs.

Anticipated audience: NOBUS

I don’t really have much an opinion on the what, I think I just know how I want this to feel. My preference is whatever works, and then making it obvious how it works. Mystery meat config files feel like the opposite, but I totally acknowledge that’s where you have to start when building this.

This is really cool. Is the "standards" thing basically some sort of LLM prompt? Like, do I just say in words "use slog, discourage logrus"?

> Consequently, we need to adapt how we model color differences, as the current standard, ΔE, recognized by the International Commission for Weights and Measures, does not account for diminishing returns in color difference perception.

This isn't to reduce the notability of the article, but isn't BIPM's interest in any color-perception stuff basically limited to making lightbulbs roughly equally bright? (i.e. https://en.wikipedia.org/wiki/Luminous_efficiency_function) I guess I don't see how even nonlinearity in perceptual space matters for that purpose.