But high demand for LLM time isn't sufficient to keep customers at the frontier LLM SaaS providers. That demand can be satisfied locally or at non-frontier outlets, absent hardware shortages at least. The Tier 1 providers (and the would-be Tier 1s) presumably need to open up a much bigger lead in model quality, one that doesn't simply get distilled away this time, and/or continue to be protected by ongoing (or worsening!) hardware shortages. (And that's overlooking the revenue shortfalls which OpenAI and Anthropic seem to be facing already.)
Seemingly the AI bulls are either not sufficiently optimistic, or not sufficiently wealthy(?!), to build new fabs as joint ventures with the manufacturers in which they agree to assume most of the downside risk?
They signed long term contracts for the hardware delivery over years. AI investment is approaching 1 trillion per year and expected to grow to well over 1 trillion per year. [1]
Even over their many years, projects like the Manhattan Project, the Apollo Program, or the U.S. Interstate Highway System never added up to that. [2]
Is your argument that there is insufficient AI spending at present as they aren’t also taking on building their own fabs?
That greater efficiency only benefits the LLM SaaS providers as long as the hardware manufacturers, probably especially the VRAM manufacturers, remain supply constrained, since the high-efficiency users are the ones who can pay top dollar. But the hardware guys' dream is presumably to get parts into millions of laptops which remain on standby for 19 hours a day, not to bargain with SaaS providers who obsessively optimise their memory consumption.
I don't see a clear advantage over the the ZXCV shortcut placement which the Macintosh team chose. (The original Finder had no specific Redo shortcut because it was single-undo and ⌘-Z performed both undo and redo.) Even well-placed dedicated keys on a Xerox-style (or later Sun-style) "fun cluster" https://www.youtube.com/watch?v=pBiWtJJN5zk to the left of the alphabetic cluster would have forced the hand to move further away from the home row. Of course ZXCV is much less well-adapted to the left-handed, but that would probably be true of any dedicated keys as well, unless they were mirrored on both sides of the keyboard.
> […] left of the alphabetic cluster would have forced the hand to move further away from the home row.
The Star left cluster are primarily operations that pair the left hand on the keys with the right hand on the mouse. This derives from Engelbart's Mother of All Demos with the left-side keyset paired with the right-side mouse.
> The Star left cluster are primarily operations that pair the left hand on the keys with the right hand on the mouse.
Sure (this is demonstrated in the linked video, for instance) but the ZXCV group is pretty similar in that respect. Even for operations which involve the mouse it's preferable to drag only one hand far away from its home position, rather than both of them. (Especially since the video evidence https://www.youtube.com/watch?v=Cn4vC80Pv6Q seems to suggest that Star users tended to move their left hand only after making the mouse selection, instead of prepositioning it.) And the Star's Undo key, which presumably doesn't require help from mouse input and is likely to be needed after a non-mouse action, isn't placed any more conveniently near the home row: it's simply in the right side-cluster rather than the left one.
It also seems pretty reasonable to worry that Oracle isn't banning LLM code contributions to OpenJDK https://www.theregister.com/ai-and-ml/2026/08/03/as-larry-el... ( HN discussion at https://news.ycombinator.com/item?id=49213754 ) purely on quality grounds. If things carry on as at present, and it turns out that indeed it really was legally safe to copy and paste almost any code that came out of an LLM, then that's one thing; but if instead there's a rash of code copyright (and indeed patent) lawsuits a few years from now then the big and middling companies will simply pay each other settlements, while FOSS projects and their small-fry users will likely be in a much worse situation.
IIRC there's a common cultural tendency to put a lot of stock in the magical powers of exotic foreign wizards, so divination might not be such a bad explanation at all.
> People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern "scripting language", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. https://web.archive.org/web/20070204053516/http://www.linux-... ("But Perl was actually much more countercultural than you might think. It was intended to subvert the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that said that every tool should do only one thing and do that one thing well.") https://www.wall.org/~larry/pm.html The fact that getting things done with a Perlesque scripting language is now seen as the height of purist Unix propriety only shows how far gone the original Unix ideal now is. But moving to the scripting-glue model doesn't really get rid of small tools that endeavour to do one thing well, it just reimplements them inside the scripting-language universe as functions/objects, though with a more expressive and less burdensome common language that makes it easier for them to stay small while being correct and effective. The more expressive their shared language, the smaller [the individual tools in] a set of tools can be.
>> Text just isn't a great medium for IPC.
> Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.
[Extra text] added for clarification (in 2022 actually https://news.ycombinator.com/item?id=31259795 ) and links fixed. Basically, if you want smaller tools you must have a more expressive language—which means (in part) a more structured language—for communication between tools. Though that's not Unix's only design shortcoming: for instance it's also a big problem that even in Plan 9 mount "outputs" only files, not processes.
reply