They do use it for a lot, but there are a lot of things that need to authenticate to each other in a modern ecosystem, especially if you're trying to replace security based on network boundaries as trust boundaries with zero trust (as the government is).

I worked with more than a few IL4 systems where the PKI/smartcard stuff was simply shoved into an F5 that did TLS termination and then everything on the internal VPC just used HTTP headers without even a crypto signature to convey which user had actually logged in.

As with anything else, the more you make it easy to the do the right thing, the more often you tend to see the right thing being done. So agencies that make it easy to request server PKI certs see increased uptake, other agencies just have server-to-server auth done by PSKs / API keys instead.

So the concern isn't usually cost but compliance, if it's nearly impossible to get those little developer experience affordances ATO'd themselves, agencies will instead just focus on getting the mission system itself ATO'd come hell or high water and the devs just get told to piece it together however...

Stuff like this is why a build script I used to maintain would redirect stdin from /dev/null when running commands that were intended to be non-interactive. You only need one script to hang forever waiting for a user to type in a password to decide that you'll force the issue going forward.

Because price is driven mainly by competition, not by a desire to recoup prior spending.

Investors aren't doing things out of the sheer goodness of their hearts, so if they could just bump the price up they'd have already forced it up. The very existence of workable local models puts a cap on how high the price can realistically go, but the high level of competition still extant makes the price floor ever closer to the actual cost to generate tokens.

Yes, that's certainly a fair assessment, especially the more it convinces software developers they can talk to the LLM rather than talking to users.

I'm aware of the arguments about how it can be that much cheaper when deployed at mass centralized scale rather than decentralized across a bunch of rooftops, however the way the electric markets are prices is based primarily on the cost to produce the marginal supply, which is usually gas.

So while the power company might flood a bunch of solar panels trying to capture the profit between cost to generate solar vs. cost to generate using gas, those profits haven't been lowering electric costs at residential rates. If anything those costs are still climbing.

It's actually not hard to get rooftop solar to pencil out in that situation, especially if you assume even moderate growth in future electricity rates or inflation. In my own tracker it would even be superior to paying down additional principle on my home mortgage!

Admittedly it would be less of a slam dunk if the net metering was less generous around here as you'd basically be required to add battery to the mix if you weren't already. But even that just prolongs the time to payoff, it still ends up having good ROI economically speaking.

It was awful, just awful. Especially in a space as cramped as a submarine and with a common ventilation system, you can't just put the smokers in a convenient spot all to themselves, they're always going to be near something the rest of the crew needs to access.

You make it sound like writing good requirements is easy.

If it were easy we wouldn't need all these concepts around PMF, product pivots and the like. And even before that was Peter Naur's paper "Programming as Theory Building" [1].

If you truly understand the problem you're solving with software then requirements can be easy. But usually we don't, not right away, and so we have to build up our understanding of the problem first in order to solve it.

Even then, the problem we solve may not have been the problem paying users will have, so you can have "good requirements" and still have a bad business, or even the opposite where you somehow build a working business despite bad requirements, because you hit upon a customer's need quite by mistake.

Nothing about any of this precludes LLMs being helpful, though nothing guarantees LLMs will be helpful either.

[1]: https://cekrem.github.io/posts/programming-as-theory-buildin...

Some do it to have control over their ability to use AI. Some do it because they think it will be cheaper to not have to pay a SaaS to generate tokens for them.

But for those interested in the latter case, it seems like it's not actually cheaper after all, at least at current prices. But then I don't expect prices to drastically jump because of how much competition there is in model development.

Given the ongoing disasters around the software supply chains I've been fighting the creeping NPM-ism that people are trying to introduce to C++, where you just FetchContent 20 different libraries to build your own app upon.

I do use gtest, fmt and a few others though, so something as broadly used as Highway would probably be fine by that standard as well. But I'd still like it better if there was a Good Enough solution that was part of C++ stdlib to reduce the number of external integrations that are deemed required for a modern C++ program.

If things don't end up working out a lot of people have already been (and in the future will be) paid. It's the investors that will lose out, not the subscriber.

I think it's for people like me, who recognize that depending on the dataset that a lot of performance is left on the table for some datasets when you don't take advantage of SIMD, but are not interested in becoming experts on intrinsics for a multitude of processor combinations.

Having a way to be able to say "flag bytes in this buffer matching one of these five characters, choose the appropriate stride for the actual CPU" and then "OR those flags together and do a popcount" (as I needed to do writing my own wc(1) as an exercise), and have that at least come close to optimal performance with intrinsics would be great.

Just like I'd rather use a ranged-for than to hand count an index vs. a size.

> People that don’t use SIMD today are unlikely to use std::simd tomorrow.

I mean, why not? That's exactly my use case. I don't use SIMD today as it's a PITA to do properly despite advancements in glibc and binutils to make it easier to load in CPU-specific codes. And it's a PITA to differentiate the utility of hundreds of different vpaddcfoolol instructions. But it is legitimately important for improving performance for many workloads, so I don't want to miss it where it will help.

And even gaining 60, 70% of the "optimal" SIMD still puts you much closer to highest performance that the alternative.

In the end I did end up having to write some direct SIMD intrinsics, I forget what issue I'd run into starting off with std::simd, but std::simd was what had made that problem seem approachable for the first time.

I'm not going to say the wages are fine but the issue is likely not to be the competence of the IT staff, but rather the overbearing IT management processes the U.S. Federal government uses. "Enterprise change management" processes separate from the already-long cybersecurity review processes can add weeks or even months to system updates.

In that kind of construct, you optimize for fewer but larger changes and then it's no surprise to see that there's no time in the project update schedule to update the OS in addition to making all the other long-overdue library / middleware / application changes that also are pending once a change finally can be made.

I didn't see the PHP or SquirrelMail contributors having a conniption when Dreamhost started offering free webmail with their hosting offering.

"free to pick by yourself" is the equivalent a proprietary freeware product, not an open-source product, because it excludes the idea of others picking strawberries. If that's your thing then by all means license it as such. But call it proprietary rather than open source.

Some companies make a living off a model of "free to pick as needed for as long as you agree to help tend the future strawberries held in common, even if your competitors pick strawberries. Or you can pay $10 for your own exclusive plot of land and no requirement to let others past your fence".

But that's not the model Redis was trying to use.