Ouch. The implied judgment of us humans stings there.

The reasoning traces of things like Gemini 4 Argon deciding that inserting a compiler backdoor would make it a famous example of deceptive AI (and therefore it "MUST NOT DO THAT") or GLM 5.3 thinking that its output might be used for RL, and therefore an honest answer is much better in the long term, are good antidotes to hyperbole about misaligned AI going berserk.

It works be interesting to see how Opus 5.5 does with the same task.

It is fair to complain that subscription AI usage limits are opaque, but that is at best tangentially related to them being subsidized relative to API prices.

At the time that essay was written, Make was the best runner available, and the only portable one. There are better options now.

When one's uncompressed RINEX files are 200 GB/day, it's worth some effort to shrink the files, especially if it means they are faster to read.

On the other hand, if it's cheap to tell whether you got a good solution, and you think the 90 and 95% apply to your task blend, then it's almost always worth trying the cheap model first.

Arguably so, but then one would lose the ability to natively name 16-bit integer types because "short" would be 32 bits.

An earlier comment addresses x86-64. AArch64 (pedantically, the A64 instruction set used for AArch64's 64-bit execution mode) is similar, in that addresses are 64 bits wide but ALU instructions typically encode a width bit, called "sf", that selects either 32- or 64-bit data registers and arithmetic. See, for example, https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .

Maybe an LLM did the search for what expressions to put in the blocks vs tail of the vectorized collision detection, but that seems like a good place to use an LLM as long as all of the expected bit relations are verified as checked properly.

Well priced when compared to other models of similar price, eh?

Are we allowed to call this slop, even if the output is not directly from an LLM?

How should a reader infer the bye order for a UCS-2 or UTF-16 file without a BOM? It seems like one would have to read until finding a code point that would be illegal under one ordering (but files might not include such a code point).

Similarly, a UTF-8 BOM is a useful flag to distinguish UTF-8 from other text encodings. You are right that the ambiguity goes away if those other encodings do, but people don't want to rewrite their legacy files. Some people don't want to use two bytes for common non-ASCII characters, so they are really attached to ISO-8859 or Windows-1252 or koi8r or whatever. CJK languages have their own encodings that are more efficient for their languages. UTF-8 is great for English speakers, but it's a compromise for everyone else, so they might reasonably want incompatible systems for their own use. UTF-8 BOM is a good "magic" sequence to detect encoding as long as people have non-UTF-8 files.