177KB patch, so it's not a small change. The patch did not apply cleanly initially; the agent had to do nontrivial work.

I just showed it the patch against 3.3.1, what command to use to build, and the path to 3.5.7 along with a link to the documentation of the change (https://fil-c.org/constant_time_crypto).

Note, I use my own coding agent (T800, which isn't public, and was previously well tested and tuned for K2.5).

I think this cost me between $5 and $10 in API usage.

(EDIT: OpenSSL, not OpenSSH)

Not being integrated can be an advantage because it gives you the freedom to think outside the box.

Meanwhile an AI engineer embedded into an incumbent slide app team has to ask permission and get cross functional alignment for every little feature. And deal with neckbeard tech leads lecturing them on what the right architecture is

My trick for that is that the set of threads that I create pre fork have to be suspendable and resumable, preferably lazily (they resume when they are actually needed). So, the zygotes are sitting with those threads suspended. When they become active, they can do work immediately. They might lazily resume those threads as needed.

There are other idioms for this too.

> Raw fork() is terrible. Instead we need a proper primitive to stop and make a snapshot of a process.

Folks have been saying that it's terrible for as long as I can remember. But it's still there, because it's better than the alternatives

In all uses of zygotes that I have seen, here's what's really happening:

- `fork` is being used to reduce the cost of starting a process that has a high start-up cost. So, you start one process, run it through the expensive initialization, and then fork it from there to start new processes.

- To make this even faster, you have a pool of pre-forked processes sit around.

- Having pre-forked processes sitting around ready to be used is not expensive because of the CoW property and the fact that a process that forks and then immediately pauses will not have triggered any significant CoW yet.

So, the zygote optimization you speak of is in practice only meaningful on top of systems that are using an optimization uniquely enabled by `fork` (avoiding process initialization costs by cloning a process), and that zygote optimization is further optimized by another property of `fork` (memory sharing of forked processes that haven't done anything else yet).

Hard to come up with an optimization that is equally efficient and elegant

I especially love how making a nicely styled website these days is a matter of describing what it looks like and waiting 10-15 minutes. There are other examples

But the OP is claiming 10x productivity improvements along some metrics. If that was even slightly true under even a generous interpretation of what it might mean, I’d expect an actual breakthrough, not the ability to churn out little things

But the clock is ticking.

To play devils advocate, computers didn’t translate to massive productivity gains until long after businesses adopted them. There was that quote from ’87: "you can see the computer age everywhere but in the productivity statistics"

Maybe we’re seeing something like that right now with AI?

Who knows man

If the only breakthrough is automated coding with no outside consequence then it’s just masturbation

- The first web browser

- the first web browser with images

- typescript

- react

- rust

- Fil-C

- doom

- quake

- the anamorphic VM, and its follow-ups like HotSpot, and even competitors/copycats like J9, V8, JSC, etc

- Fortnite battle royale

- Roblox

- thefacebook

- ChatGPT

- Claude code

I know that’s quite a range and that’s intentional.

Anyway, I think we’ll know it when we see it.

Claude is amazing, that’s true.

But if it was as amazing as this article implies, I’d expect some breakthrough outside of AI itself.

Rewriting a Zig program in unsafe Rust? Not a breakthrough. Finding a bunch of security vulns? Maybe that’s sort of a breakthrough though it’s underwhelming and possibly just a net negative. But like if I rolled back to using software from 2023 then life would be ok.

Maybe we just need to give it time, and sometime real soon, we will all be amazed by such a breakthrough? Who knows

you are confirming their point even as you contradict the specifics

It’s not the same obviously, but here’s why I can’t help but view it analogously:

The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with rigor or just trying random stuff until it seemed to work.

In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).

So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor

But why I’m saying has always been true. What has changed is that the effective portability of C and C++ code has increased due to the reduction in number of compilers and arches

It’s not. All that matters is what C compilers actually do and what real C programs expect.

This is a good thing. It creates a culture where the two sides meet each other where they’re at

It would be a big change. Probably not backwards compatible with today’s rust.