hirsin

The space is rife with folks asking big questions like "if I give an agent money to invest, I don't owe taxes on it because the agent did it, right?"

I do enjoy asking people what they mean when they say they want to build an agent-native platform, because that work is rarely what they actually want to do.

As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?

Who do you think would host the "federated login" system that would replace the major authentication companies?

You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.

While I generally agree for general human living, I've seen impressive "digital hoarder" success using AI because it changes the dimensions of reasonableness.

Imagine your hoarder scenario except that the hoarder has unlimited storage space and a team of librarian/warehouse workers to go find and fetch the items needed for the wall hanging task.

It's implicit as a request, not something they literally say (usually).

Namely - I put near zero effort into this response, and deciding if it's correct is on you. -> I'm asking you to read it and figure out if it's correct because I couldn't be bothered to do so

Re: Topologies I found it resulted in a lot of reorgs founded on the seeming belief that Conway's law is both immediate and retroactive - if we change the teams and what they own, their features and code will similarly now become cleanly organized.

It's a shame because the underlying message of not overloading teams with extremely broad feature areas is good, and was exactly what we needed.

They mean the apartment building hallways and elevators. As in, if you summed the square footage of all the apartments on a floor, you'd get a number greater than the actual dimensions of the floor, because the common areas are counted multiple times.

Yep, the issue is that recalculating DSCR doesn't happen on the right timescale to incentivize reducing rents, instead incentivizing keeping vacancies open and using a pro forma DSCR.

The banks know this is a structural issue, but are likewise incentivized to keep "strong assets" on their balance sheet, rather than a bunch of troubled assets bound for default.

The claim isn't that they can keep this up forever, it just needs to last another quarter, every quarter.

The shell game is both parties knowing that the cups are all empty but still playing because it's better for them both to do so.

Fwiw there's a 290k sqft DC on Denny a few blocks from the Amazon towers https://h5datacenters.com/seattle-colocation.html If you live in Seattle you've probably walked right past it. Small potatoes compared to a 10M sqft DC but it hosts real traffic.

On top of the architectural challenges and efficacy of it, you have to contend with the terms of the bank loans that apply. Those are why the buildings "can't" lower rents to attract new business.

If they sign a lease at a new lower rent it basically triggers a re-check of "can they repay the loan based on their rental income?", which comes back as "no". That trigger _doesn't_ occur if you just leave the building empty, with _no one_ paying rent, because your last mark to market rent was high enough.

Fundamentally changing the type of tenant in the building would presumably trigger that check as well.

It's a shell game that eventually leads to the loan defaulting, but both the bank and the building owner are happy to pretend they can't see the train coming down the tracks at them.

For an example of this in Seattle that everyone was calling years ahead of the collision, see the Martin Selig sagas https://deepnewz.com/real-estate/seattle-developer-selig-war...

This comes across strongly any time you hear management talking about "fungibility of engineers". Everyone is a full stack everything engineer, and AI makes that even easier for them to trick themselves into believing.

If anything, I feel like AI has made domain expertise more important, not less, as the "confidently wrong" error case for agents has no one able to sanity check it. At least before AI a human would dip their toe in the water and usually realize that having no idea what they were doing, and not even being able to understand what the comments mean, was a sign that they need to go find someone more experienced to help.

Look, it wasn't _my_ request that made the server fall over, it must have been one of the other several thousand thoughtless scrapers running on the website that caused it to die.

Microsoft.com is also owned by the marketing org, not the engineering org, for various reasons that predate the existence of many employees at Microsoft now.

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.

Not quite. At least the one I found is some trickle down economics myth.

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.

It definitely looks like the old tale come true - at Microsoft people would warn against using Google because then Google could figure out what we're working on, since it was pretty easy to tell where a query was coming from.

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

That's the success case. In the failure case you have emboldened, pressured teams jumping in to make a "quick fix" or "that feature we needed" in a codebase for a team they've never heard of, and leaders cheering it on in the name of progress.

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.

I have no idea how you read a statement about how nazis and flame baiters should be able to speak their mind and then concluded that the author only cares about some minorities.

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.

Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?

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.

Right - it feels like going skin deep on types and then complaining they didn't solve for very deep problems.

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)

To torture the metaphor further - it's also a personal dj, with an audience and customer of 1. Somewhat by definition there can be no outlandish requests, certainly not "play this entire piece".

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.

I'd review the setup here. You're missing the critical distinction that the cryptography supports - separating entirely (in time and space) the issuance of the cred to the user and the use of that cred with a website.

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.

Which is why you separate the credential issuance from the credential use, per the standard mentioned.

It can't be quite that simple because you have a couple additional problems to solve - (effectively restating bits of the article poorly and partially)

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.

https://qntm.org/mmacevedo, for those unfamiliar, not the namesake of that story from digital graphics.

So does Google send a header for each search result when you look up "Ron Jeremy" so that some results get hidden, or does the browser just block the whole page?

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.

I can't think of a more quintessential crash out of a major brand than Twitter from the past couple years. For a significant percentage (>10% publicly, I'm confident much more than that internally) of users it became unattractive.

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.

That would be the good argument, yes.

The Twitter layoffs being used as proof of _anything_ is misguided no matter what you're trying to say.

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

As someone on the great, late 8 (https://fixthel8.com/) in Seattle, I'd happily give up my stop to help it be on time more often. I have three other stops I can walk to within ten minutes of me.

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.

Which of the cities used as examples in the articles are "sparse"? LA? Pittsburgh is one of the smaller ones listed and while the bus network there is very hub and spoke, it's also still semi usable.

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.

The observation that the colors were meant to be absorbed over time rather than explicitly set out reminds me of the old NYC Metro mosaics. https://www.untappedcities.com/secret-meaning-behind-colors-...

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.