A corporate purchaser is buying hundreds to thousands of Claude seats and doesn't care very much about percieved fluctuations in the model performance from release to release, they're invested in ties into their SSO and SIEM and every other internal system and have trained their employees and there's substantial cost to switching even in a rapidly moving industry.

Consumer end-users are much less loyal, by comparison.

Much easier if you can sell wholesale (sometimes via distributors) to a retailer or network of retailers, and the retailer is responsible for owning the customer relationship, dealing with their part of import/export, local regulations, etc. Retailers are businesses who will buy hundreds of your product at a time, can accept it as palletized freight, and pay you via bank EFTs instead of credit cards.

There are notable exceptions to this model like Amazon's FBA system, but they're the outliers. I'm sure we can all point to inefficiencies in legacy product distribution networks but they solve some real problems.

Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.

I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.

Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).

As a result, the entire packaged food industry is pumping up protein numbers and marketing it as the primary attribute of the food (where they might have previously marketed low fat or low sugar or whatever else in the past).

So, saturated market... but certainly one people are investing in now.

In startups I've put more effort into squeezing blood from a stone for far less change; even if the change was proportionally more significant to the business. Sometimes it would be neat to say "something I did saved $X million dollars or saved Y kWh of energy" or whatever.

With a credit card, if the card is compromised, its not my money being stolen - its the card issuer's money from my line of credit, and they were planning on settling up with me when my monthly statement closes. I still have to launch a fraud case with the issuer, but critically, _all of my money is still in my bank account_ and I can continue to pay my other bills and obligations as normal.

I think its reasonable to consider giving up that buffer to be additional risk for the debit card approach, setting aside any other advantages or disadvantages between the two.

Right now, yes, its true that a lot of my day to day purpose is driven by participating in the economy and setting myself up for the life I'd like to have in my later years, and I get genuine validation from solving problems and collaborating with people in my day job.

But sometimes, my purpose is to go snowboarding and forget about work. Or to help a friend fix their bicycle. Or to get lost in conversation with a new person I'm dating. As far as any of us know, we only get one turn to be alive on this rock, so we might as well purposefully enjoy it as much as we try to purposefully be useful.

If you look at Ginny Oliver from the article, it might be fair to question whether she was as useful on a lobster boat at 105 as she might have been in her youth. But I doubt she was concerned with usefulness since she had such sense of purpose.

Torrents would be a perfectly valid way for Google to distribute this dataset, but the key difference would be that Google is providing it for this purpose and presumably didn't do anything underhanded to collect or generate it, and tells you explicitly how you're allowed to use it via the license.

That sort of legal and compliance homework is good practice for any business to some extent (don't use random p2p discoveries for sensitive business purposes), but is probably critical to remain employed in the sorts of giant enterprises where an internal security engineer needs to build a compelling case for spending money to upgrade an outdated protocol.

Since the original company both changed names and was subsequently liquidated in bankruptcy nearly 20 years ago... that seems unlikely. There's only so many names out there, and occasionally they get fairly recycled.

The reality is that there certainly are enthusiast programmers who can thrive with the lightweight elegance of stock Ruby, but most people writing code professionally aren't enthusiast programmers under ideal conditions. Everything is always a little more distracted, a little less well-defined, and a little more coupled to legacy than anyone would want. And those are the conditions where I want my tools working as hard as possible, automatically, for me / my teams.

We're not quite there yet, but the logical progression of shorter and shorter certificate lifetimes to obviate the problems related to revocation lists would suggest that we eventually end up in a place where the major ACME CAs join the list of heavily-centralized companies which are dependencies of "the internet", alongside AWS, Cloudflare, and friends. With cert lifetimes measured in years or months, the CA can have a bad day and as long as you didn't wait until the last possible minute to renew, you're unimpacted. With cert lifetimes trending towards days or less, now your CA really does need institutionally important levels of high availability.

Its less that LE becomes more of a single point of failure than it is that the concept of ACME CAs in general join the list of critically available things required to keep a site online.

UUIDs or other similarly randomized IDs are useful because they don't include any ordering information or imply anything about significance, which is a very safe default despite the performance hits.

There certainly are reasons to avoid them and the article we're commenting on names some good ones, at scale. But I'd argue that if you have those problems you likely have the resources and experience to mitigate the risks, and that true randomly-derived IDs are a safer default for most new systems if you don't have one of the very specific reasons to avoid them.

(As an aside, they also have some of the best meat and produce you can get in the city without going to a farmers market. So many retail grocery stores here lack loading docks, the food handling getting from the truck to the sidewalk to the basement of the store to the shelves is really, really rough especially during the summer months. Skipping that and going warehouse-to-home has advantages)

And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.

And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.

Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.

But me (or my teams) are rarely asking the question of "how should I run my service on AWS" in general, its much more typically "I need a managed Postgres database, what AWS product offers that" or "I have an OCI image, what managed platform can I run that in" or even "I want this endpoint to be available all the time, but its usage is very unpredictable/intermittent, so I don't want to pay for idle compute". There might still be a couple of possible answers for those questions, but by the point I arrive there I'm solving for a specific problem.

Its sort of like walking into a kitchen hungry and seeing 3 knives and a stove and oven and a dozen peelers and can openers etc etc and being very overwhelmed by all of this (do I need the knife with a smooth edge or the serrated one?) until you decide you want to eat a grilled cheese, and then grabbing a skillet to put onto a burner and everything making sense once you actually start to cook a specific thing.

The cost is fidelity. Full-range audio transformers aren't cheap, so these systems usually make some compromises because your announcements or smooth jazz over the pasta aisle don't need to be true hi-fi.

Its cool technology. Most of the speakers have variable power taps, so you can run a bunch of them in parallel on a single line and control the actual volume as-needed based on where the speaker is deployed by varying the transformer tap on each speaker.

LLMs hallucinate because training on source material is a lossy process and bigger, heavier LLM-integrated systems that can research and cite primary sources are slow and expensive so few people use those techniques by default. Lowest time to a good enough response is the primary metric.

Journalists oversimplify and fail to ask followup questions because while they can research and cite primary sources, its slow and expensive in an infinitesimally short news cycle so nobody does that by default. Whoever publishes something that someone will click on first gets the ad impressions so thats the primary metric.

In either case, we've got pretty decent tools and techniques for better accuracy and education - whether via humans or LLMs and co - but most people, most of the time don't value them.