Roguelazer

The important thing to remember is that for a large number of people (in the US), "work" is a place where they do things that they hate for eight hours a day, for people they hate (surveys routinely show between 40% and 60% of people are "satisfied" with their jobs). Those of us who are in the tech industry because we like actually programming computers (the "craft-lovers", in the parlance of this blog post) have been lucky enough to have jobs where where we get to actually do something we enjoy (even if it's intermingled with meetings and JIRA). If AI slop really is the future and programming becomes as rare of a job as hand-building wood furniture, then most of us are going to be living the normal experience of capitalism in a way that we are probably not well-prepared for.

Personally, I have noticed that I still produce substantially more and better code than the people at my company spending all day writing prompts, so I'm not too worried yet, but it seems plausible at some point that a machine that stole every piece of software ever written will be able to reliably turn a few hundred watt-hours of of electricity into a hallucination-free PR.

That's absolutely not true. The places that have embraced "agentic engineering" are mostly garbage factories, and lots of places, including plenty of startups and fast-moving companies are staying off of this trend. I recognize that most of the people on this site are just trying to self-promote for their own gig, but the level of misinformation is sometimes just staggering.

So what's going to happen in 3 years after these startup bros have left government, none of the frameworks they're using are supported any more, and nobody in the office that they parachuted into is trained to maintain whatever spaghetti they crapped out over three months of all-nighters? There's a reason that we don't build critical infrastructure by giving it to some guy whose entire accomplishments are "working at Airbnb for 10 years"

DCR is cool, but I haven't seen anyone roll it out. I know it has to be enabled per-tenant in Okta and Azure (which nobody does), and I don't think Google Workspace supports it at all yet. It's a shame that OIDC spent so long and got so much market-share tied to OAuth client secrets, especially since classic OpenID had no such configuration step.

Some API questions/observations

- I don't see an idempotency key in the request to authorize a charge; that might be something nice for people looking to build reliable systems on this. - How long are accessTokens valid? Forever? Do they become invalid if the subject metadata (firstName, lastName, email) changes?

I think this is a super-cool idea, but I think the idea of extending net30 terms to every customer of some B2C product seems pretty iffy; since you're deferring charging until the end of the month, you won't get most of the fraud signals from Stripe until then and anything popular that used this system seems like it'd be pretty inundated with fraud. I would at least consider doing the charges more frequently (i.e., charge at the end of the month or every $50, whichever comes first) to put a better bound on how long you can go before finding out that someone gave you a stolen card.

I think this is ignoring a lot of prior art. Our deploys at Yelp in roughly 2010 worked this way -- you flagged a branch as ready to land, a system (`pushmaster` aka `pushhamster`) verified that it passed tests and then did an octopus merge of a bunch of branches, verified that that passed tests, deployed it, and then landed the whole thing to master after it was happy on staging. And this wasn't novel at Yelp; we inherited the practice from PayPal, so my guess is that most companies that care at all about release engineering have been doing it this way for decades and it was just a big regression when people stopped having professional release management teams and started just cowboy pushing to `master` / `main` on github some time in the mid 2010's.

For most users, that'll just result in them going to Google, searching for the name of your business, and then clicking the first link blindly. At that point you're trusting that there's no malicious actors squatting on your business name's keyword -- and if you're at all an interesting target, there's definitely malvertising targeting you.

The only real solution is to have domain-bound identities like passkeys.

It's really "cool" when you get vendors like 6sense that combine browser fingerprinting with semi-licit data brokers to do full deanonymization of visitor traffic. Why bother doing marketing when you can just get a report of the name, email address, mailing address, and creditworthiness of every person who's visited your website?

I've seen people argue with a straight face that these tools and their reports don't run afoul of GDPR/CCPA because they don't involve information that a user gave you on purpose, so it's not protected. Ghouls, all of them.

It does seem like there's something wrong with that data; I find it somewhat implausible that the average parent was only caring for their child for 1.7 hours a day in 1985; even if you assume that all of the tween and teens were free-range and only got an hour or two of parenting a day, little kids have always required nonstop attention to make sure that they're not actively dying.

Although... the infant mortality rate in the US has dropped by more than 50% since 1985, so who knows...

I mean, ~90M people live in one of the top 10 metro areas, which is about ¼ of the country. Not sure that I'd necessarily call that an "exception".

> *Up to 15–50% slower decision-making in offices with high flicker (and high CO₂)

just throws me right off the argument in an article when the fine print notes that a cited study is confounding the thing the author cares about ("sensitivty to flicker") with a much simpler and better-understood explanation (CO₂ poisoning)

Running a parser for a network protocol as root seems like a pretty unnecessarily dumb thing to do. I can't really imagine why any part of airplay would need to run as root; maybe something to do with DRM? Although the DRM daemon `fairplayd` runs as a limited-privilege user `_fpsd`, so maybe not. So bizarre that Apple makes all these cool systems to sandbox code, and creates dozens of privilege-separated users on macOS, and then runs an HTTP server doing plists parsing as an unsandboxed root process.

It's been a bit more than that; about four years ago they started using machine-analyzed satellite photos to override street geometry in my neighborhood and decided that a parking lot is a through street; since then, nobody who uses Google Maps can get to my house because Google Maps directs them to drive down that parking lot (which has a brick wall in it and is not a through street). I've filed this as a data issue maybe a half-dozen times and it gets fixed and then breaks again a couple of months later in the exact same way. Drives me crazy. OpenStreetMaps and Apple Maps are both correct.