Wow, very interesting fact. If a unit is performing badly due to lack of equipment, they won't get the points to get the equipment they need. I wonder if that's a problem in practice. I'll read up on it, very interesting stuff.
Fun sidenote: On a recent Hotmail post on here, I saw a screenshot of hotmail V1 (way before M$ took over). They had a prominent button on their homepage about privacy.
It scores high on BenchCAD, that's interesting to see, I was wondering about how each model could handle this. Seems like they trained it on programmatic CAD specifically.
We can look at openrouter GLM 5.2 prices I think to get a rough idea about the pure inference cost (with margin). They are probably running on simmilar hardware. Although scale helps Anthropic probably.
Those font tests are cool, he's created a unique way of rendering fonts, an interesting, playful look. And great that he's letting his son play with the computer.
Any good LLM will emit Python or other scripts to analyze or work with large files (e.g. GeoJSON) naturally when asked to work with a large file. So I don't see that as needing an explicit solution. The LLMs just figure it out.
Your argument is that it's simply because of dropping prices. Maybe that does explain the bulk of it. But the article seems to suggest it's the WFH transition. How much of the vacancy rate would be explained by that?
For me, the encrypted reasoning contents, when looking at the base64 string lengtht, show this effect. However, the server-reported reasoning tokens don't. So I assumed it was part of the encryption and/or obfuscation purely. So I don't think there is a real issue.
This is the biggest downside of GPT; thinking is encrypted, so it's more of a black box than kimi/glm/deepseek. You still get thinking summaries though. It's awkward, but workable.
There seems to be no awareness from EU govenments about how much power we're handing over to two large outside companies. This incompetence in the leadership will cause a lot of harm over the years. This has been going on for a long time.
That he ran into blockers with the exotic setup is understandable. After overcoming a bunch of challenges, I was surprised to read that the missing Flatpak package stopped him in his tracks, that felt surprising when I read it. It feels like a lesser challenge than the issues he has already addressed.
> there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64
All he had to do was build some packages from source, right? It's really worth learning how to do this, since it removes a lot of constraints.
And the kernel patch should land in the kernel pretty soon, I hope? He won't have to run a patched kernel forever. Should be possible to get that in a release in a year or so?
Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.
It's in the JSONs in ~/.claude, but last 30 days only I think. You can have the model analyze history. So for correct history you'd need to run history analysis on a cron job or something. Kinda hacky.
By stating you used an LLM it sounds as if you haven't vetted it. By mentioning the LLM in this hyped-up time, you're distracting from the actual deep work you've (presumable) done.
By ensuring the patch is truly tight, and that the correspondence it tight (not LLM slop), there is no reason to suspect slop or reject it. Assuming it's a concentrated, well motivated patch.
That being said, this patch set is very large with very wordy comments. I'm not sure if he submitted all of them at once. Personally I would not accept such wordy comments in my code. A typical LLMism. These comments should be smaller and part of the email. I also suspect the code change could be smaller.
Today's LLMs do have a way of slowly poisoning a codebase by not being a tight as they could be. It tends to bloat the code up. Okay for some code, especially when bounded (e.g. module X is written by LLM, API authored by human). But in massive, established codebases, you can't accept even slightly bloated code since it will drag everything down.
Also, GLM is a lot weaker than GPT and Claude I think.
One advantage about local LLM: You could serialize the context yourself, without being constrained by APIs. And let's not forget, the Big 2 encrypt their thinking. If you use custom clients, which is a very grey area alreay, being able to produce the context string raw is a big bonus. Takes away a lot of annoying constraints and needless mystique/obfuscation.
But I don't know how usable GLM 5.2 is vs the Big 2.