This is why with rare, rare exceptions nothing "real" is on Microsoft.com including even the login page, with one exception (the passkey domain).

The new cloud.microsoft domain for Office will possibly help, but it's still a heck of a long list - https://learn.microsoft.com/en-us/microsoft-365/enterprise/u...

And IIRC this is just for office and windows, not azure.

The one op is referencing is more like the dollar is used to pay off the waitstaff, who pay their rent to the landlord, who pay their over due taxes, so that the government can issue a refund to the cafe owner. The dollar ends up back in the hands of the cafe owner, who puts it back down on the table with all the debts paid off.

Sounded far fetched back then, and on the face of it illegal, but now it's just common sense I imagine.

Not every company is going to see those boundaries and stakeholders as features, and they'll be under pressure to "mitigate those blockers to execution". That's where the cognitive debt skyrockets.

Given that the author didn't say any of the things you claimed, and indeed said the opposite, it leads one to conclude you have a problem with the example used.

Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.

Like yes, it would be nice for Map(ICar[] cars, keys).wingspan to throw a type error because cars is typed and we know keys can't include things not in ICar.

But to say that Map(Any[] things, keys) should have ahead of time type checking seems like you're not really using types except when inconvenient. Which might be taken as a no true scotsman or "holding it wrong" argument but... Maybe they are holding it wrong.

(Speaking as a former Windows/CLR PM now working in a Ruby monolith... It's hell and indeed trying to add types via sorbet has been miserable and useless)

If I told the DJ at my wedding to play an album front to back, and they transitioned to Aerosmith, I'd be tapping a friend to run the music the rest of the night.

Unless you're getting the device logs from the users device (in which case... All of this is moot) there is no timing attack. Six months ago you got your mobile drivers license. And then today you used it to validate your age to a website anonymously. What's the timing attack there.

1. You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else).

2. You don't want the government to know which website you're going to, nor allow the government and the website to collaborate to deanonymize you (or have the government force a website to turn over the list of tokens they got). So the government can't just hand you a uuid that the website could hand back to them to deanonymize.

The SD JWT and related specs solve for these, which is how mDL and other digital IDs can preserve privacy in this situation.

Sending all the "bad" data to the client and hoping the client does the right thing outs a lot of complexity on the client. A lot easier to know things are working if the bad data doesn't ever get sent to the client - it can't display what it didn't get.

If Microsoft did something that resulted in 300 million users leaving it would be considered crashing and burning, but I guess when Elon does the same proportion someone will show up to explain why losing half your revenue is better than losing all of it.

I just want to know who those people are so that I can pitch them on my next investment fund.

If success is losing half their revenue, reverting to revenue numbers from a decade ago, I gotta know what failure looks like. You might argue that the revenue losses aren't correlated to their headcount changes and probably make a good argument, but I mean... It's not a great one

SF is another good example of too many stops. It's honestly comical and I stopped riding the bus in SF at times because the stop count was painful.

But to call NYC, LA, Philly, Chicago, Minneapolis, Houston, etc sparse doesn't seem very accurate. Yes, LA is vast, but I wouldn't call it sparse.

Comments URL: https://news.ycombinator.com/item?id=46912076

Points: 2

# Comments: 0

While no one would ever navigate by learning what the mosaics mean, it's a fantastic setup for the expected audience of commuters. Give it a month and your brain would associate a given color with your stop coming up soon, and make navigation easier.