That's not what they're doing. They're directly modifying the IR to convert it into a tracing JIT. The final artifact is a binary w/ no IR. The problem is of course not introducing any subtle bugs in the process b/c they'd have to prove the modification they're making do not change actual runtime semantics for the final binary artifact.

Why do they need to change LLVM? Why can't they make this another LLVM IR pass?

Our fork of LLVM does add a pass, amongst other changes, but we also have to do things like change stackmaps in a way that breaks compatibility. Whether stackmaps in their current incarnation are worth retaining compatibility for is above my pay grade! So some of our changes are probably upstreamable, but some might be considered too niche for wider integration.

This way they pump the stock for a little while before the whole thing comes crashing down.

Indeed, which is why it’s preferable to only start using them after some arithmetic maturity is achieved.

And we collectively decided that it's fine, you don't actually need to be able to solve 1234×5678 in your head.

But I am not sure you can compartmentalize the specific skill we can out-source to AI. I would not agree with "you don't need to be able to think in your head."

Right, which is why people make bad money decisions in everyday scenarios. People don't pull out their calculator at the grocery store, but they also never had to get good at doing simple math in their head due to the calculator.

Commercial music & movie industries are extensions of state sponsored propaganda. That is why they go to such lengths to defend their "products".

Source:

It should be possible to do this w/ eBPF. Monitor network i/o & rewrite the request on the fly to include the proper tokens & signatures. The agent can just be given placeholder tokens. That way all the usual libraries work as expected & the secrets/signatures are handled w/o worrying about another abstraction layer. Here is some prior art: https://riptides.io/blog/when-ebpf-isnt-enough-why-we-went-w...

Wait until you folks learn about the quantum panopticon. It sounds fake but governments everywhere are recording as much encrypted data as possible in hopes of decrypting it in the future w/ quantum computers: https://link.springer.com/article/10.1007/s11023-025-09723-2

Yes, only true solutions are network layer severing.

I guess you folks don't know about iota & jot: https://en.wikipedia.org/wiki/Iota_and_Jot

Eventually ML folks will discover fiber bundles.

But what bastard "new" name will they give them?

Sooner if you explain why.

Off the top of my head, connections on fiber bundles (which define a notion of "parallel transport" of points in the total space, allowing you to "lift" curves from the base space to the total space) are more general than Riemannian metrics, so maybe there are some ML concepts that can be naturally represented by a connection on a principal bundle but not by a metric on a Riemannian manifold? At least this approach has been useful in gauge theory; there must be enough theoretical physicists working in ML that someone would have tried to apply fiber bundle concepts.

Lie brackets are bi-linear so whatever you do per example automatically carries over to sums, the bracket for the batch is just the pairwise brackets for elements in the batch, i.e. {a + b + c, d} = {a, d} + {b, d} + {c, d}. Similarly for the second component.

> Similarly for the second component.

Hmm.

{a + b, c + d} = {a, c + d} + {b, c + d} = {a, c} + {a, d} + {b, c} + {b, d}.

{a + b + c, x + y + z} = {a, x + y + z} + {b, x + y + z} + {c, x + y + z} = (a sum of nine direct brackets).

This doesn't look like it will scale well.

Then don't use the Lie bracket. All bilinear forms scale the same way.