You are right, that many of the more serious, less casual contributors are probably paid.

For something more modern, have a look at how the basic variants of Risc-V don't include multiplication.

A very basic pocket calculator might not have multiplication as an instruction, but multiply by running a simple multi-instruction program. That's how people multiplied on a 6502, too. (Similar also for calculation cosine or square-roots or logarithms: you run a little program.)

That's a weird thing to say. There are a lot of otherwise quite sophisticated chips that don't do multiplication. Multiplication is a pretty high bar, so the 6502 coming in below isn't much of a surprise.

Well, I was merely replying to this:

> [...] lean seems like a new foundational language family that every programmer should be able to read, [...]

But yes, you have to wrap your head around dependent types.

Lean isn't super special in that regard. If you know Haskell or OCaml you are already pretty far along in at least being able to read Lean, as it comes out of a similar-enough tradition.

Reading very charitably: you can say that at the moment a lot of the AI's advantages seem to come from: (a) having read approximately everything, and (b) being willing and able to try out lots and lots of approaches without tiring or getting bored. You don't need to have superhuman intelligence, yet, when superhuman persistence still yields so much low hanging fruit.

Not so fast. There were plenty more horses in that race.

You can easily make an argument that Python is a 'worse' language than Scheme as a first teaching language (though not necessarily one I would subscribe to: they are both dynamically typed and mostly differ in syntax). But Python (and Scheme and even Basic) are a lot better than starting people off with C or Java, or, God forbid, C++.

Obviously there are people who you can lock in a dimly lit closet with just an outdated reference manual to a made up machine and they'll can't help but pick up programming; and those won't have much trouble coping with Java or C++. But those who actually need to be taught will be better off with Python (and Scheme).

Yes. Humans are slow.

You are right that there's plenty of use cases where Opus 5.5 is better.

It's good that this is a competitive industry. So you don't have to moralise Anthropic so much.

But Kimi does have morals and refuses some things. It's just a lot less squeamish than Claude.

First, when Claude refuses I sometimes continue with Kimi or DeepSeek. They are less squeamish. Alas, the combination of C + kernel reliably makes Claude freak out: because of all the UB any tiny error becomes a security hole. (I have the cybersecurity verification stuff from OpenAI and Anthropic but they are still fairly strict.)

Second, contributing directly to the Linux kernel has never been easier. Claude knows all about how to interact with the archaic kernel mailing lists. The main rule I suggest: put in real effort, don't dump AI slop.

However I mostly worked in fixing filesystem bugs so far. I don't know whether the networking and DMA folks are as nice. But probably yes.

(Coincidence: the isofs filesystem code in the kernel is full of tiny holes as far as I can tell. I've patched some of them, but better don't try to mount a malicious CD image.)

Also empirically, pretty much any provably polynomial algorithm we have found for anything has fairly tame exponents. That's a big part of why 'polynomial' works as a short-hand for 'tractable' that also has nice theoretical properties.

Btw, I don't know whether the tame exponents are in some sense natural, or whether they are a product of how humans find and design algorithms. Perhaps AI will change that.