The thing is that startups often don't have the time or capital to build a data center even though public cloud is just more expensive. If you're bootstrapping a business then it makes sense. My advice would be to always use only those features of the public cloud that you can also use on your private cloud, such as Kubernetes.
How do people think that's the only two options (AWS/cloud or build a datacenter)? It astounds me.
There's _so_ many providers of 'bare metal' dedicated servers - Hetzner and OVH come up a lot, but _before_ AWS there was ev1servers (anyone remember them?).
The real question is not why the government gets to set the retirement age. Of course it gets to set it IF it's involved in paying for people's retirements!
The real question is why governments insist on euphemistic names ("forced savings") that imply the opposite of the reality of the programs. And why people put up with such financial repression schemes. The answer to the first question is to keep people from being too upset too suddenly, too many all at once. The answer to the latter is that the people usually don't get a say in these things.
For Singapore this program probably makes a great deal of sense since Singapore is singularly vulnerable given its location in the world. To build what they did they probably needed these sorts of policies. I suspect most Singaporeans don't mind all that much, though I don't know. We would very much mind this sort of thing here in the U.S. though!
No, it's a total loss for the citizen because even if they can use that money for "(retirement, medical, housing)" the interest paid is much too low.
Forced savings programs aren't actually "savings" for the people on whom the programs are forced!! "Forced savings" is a euphemism for "we're taking your money and calling it savings based on the idea that we're going to invest it well, though you won't see much of any gains, and there might not be any gains to speak of".
Just tonight I was trying to get Claude Opus 4.6 to design a lock-less data structure, and it kept failing to solve problems which I kept then solving for it, but once presented with the solutions it was able to check them, and I think correctly so (that's not nothing!).
The only real mote was and is mindshare. Build mindshare, don't screw your users, and your competition will have a hard time dethroning you. LLMs will probably force SaaS and software prices to come down, which will be a great opportunity for dethroning reigning champions.
PostgreSQL, for example, has a ton of mindshare. It will be hard to dethrone it.
OpenSolaris was Sun's attempt to recover from the loss of mindshare to Linux. The a company that had become dominant in databases due to mindshare acquired Sun then failed to understand the mindshare play, and it killed OpenSolaris. Explain that one to me.
AI coding assistants make it trivial to switch between models, and developers will switch to a different model from a different provider if the new model is perceived to be better than the current one even if that perception is completely subjective.
Furthermore, the only users who will actually pay for AI are these assistant-using developers and other power users -- people who will not hesitate to switch to something better. We are already used to new model releases being neck in neck and there is no real incumbent/underdog dynamic going on here.
Yes, there is strong mindshare among the normies, who only know about "ChatGPT", but as soon as they graduate into a powe user, then the above applies to them.
Because we (Heimdal) need to make a release, darn it. I'm going to cut an 8.0 beta within a week or two.
Basically, an 8.0 release is super pent up -- years. It's got lots of very necessary stuff, including support for the extended GSS-API "cred store" APIs, which are very handy. Lots of iprop enhancements, "virtual service principal namespaces", "synthetic client principals", lots of PKINIT enhancements, modern public key cryptography (but not PQ), etc.
The issue is that the maintainers (myself included) have been busy with other things. But the pressure to do a release has ramped up significantly recently.
Also things like support for GSS-API pre-authentication mechanisms (so, you can use an arbitrary security mechanism such as EAP to authenticate yourself to the KDC), the new SAnon mechanism, pulling in some changes from Apple's fork, replacing builtin crypto with OpenSSL, etc. Lack of release has been typical OSS lack of resources: no one is paid to work on Heimdal full time.
- insist on disclosure of LLM origin
- review what they want, when they can
- reject what they can't review
- use LLMs (yes, I know) to triage PRs
and pick which ones need the most
human attention and which ones can be
ignored/rejected or reviewed mainly
by LLMs
There are a lot of options.
And it's not just open source. Guess what's happening in the land of proprietary software? YUP!! The same exact thing. We're all becoming review-bound in our work. I want to get to huge MR XYZ but I've to review several other people's much larger MRs -- now what?
Well, we need to develop a methodology for working with LLMs. "Every change must be reviewed by a human" is not enough. I've seen incidents caused by ostensibly-reviewed but not actually understood code, so we must instead go with "every change must be understood by humans", and this can sometimes involve a plain review (when the reviewer is a SME and also an expert in the affected codebase(s), and it can involve code inspection (much more tedious and exacting). But also it might involve posting transcripts of LLM conversations for developing and, separately, reviewing the changes, with SMEs maybe doing lighter reviews when feasible, because we're going to have to scale our review time. We might need to develop a much more detailed methodology, including writing and reviewing initial prompts, `CLAUDE.md` files, etc. so as to make it more likely that the LLM will write good code and more likely that LLM reviews will be sensible and catch the sorts of mistakes we expect humans to catch.
> Maintainers can...insist on disclosure of LLM origin
On the internet, nobody knows you're a dog [1]. Maintainers can insist on anything. That doesn't mean it will be followed.
The only realistic solution you propose is using LLMs to review the PRs. But at that point, why even have the OSS? If LLMs are writing and reviewing the code for the project, just point anyone who would have used that code to an LLM.
Claiming maintainers can (do things while still take effort and time away from their OSS project's goals) is missing the point when the rate of slop submissions is ever increasing and malicious slop submitters refuse to follow project rules.
The Curl project refuse AI code and had to close their bug bounty program due to the flood of AI submissions:
"DEATH BY A THOUSAND SLOPS
I have previously blogged about the relatively new trend of AI slop in vulnerability reports submitted to curl and how it hurts and exhausts us.
This trend does not seem to slow down. On the contrary, it seems that we have recently not only received more AI slop but also more human slop. The latter differs only in the way that we cannot immediately tell that an AI made it, even though we many times still suspect it. The net effect is the same.
The general trend so far in 2025 has been way more AI slop than ever before (about 20% of all submissions) as we have averaged in about two security report submissions per week. In early July, about 5% of the submissions in 2025 had turned out to be genuine vulnerabilities. The valid-rate has decreased significantly compared to previous years."
reply