Links - 5^th October 2025

So, in all, I’m seeing time syncing somewhere in the 200–500 ns range across my network. The GPS time sources themselves are sometimes as far as 150 ns apart, even after compensating for systemic differences, and the network itself adds another 200–300 ns of noise.

In an ideal world, it’d be cool to see ~10 ns accuracy, but it’s not really possible at any level with this hardware. My time sources aren’t that good, my network adds more systemic error than that, and when I try to measure the difference between test servers I see a couple hundred nanoseconds of noise. So 10 ns isn’t going to happen.

On the other hand, though, I’m almost certainly accurate to within 1 μs across the set of 8 test servers most of the time, and I’m absolutely more accurate than my original goal of 10 μs.

Let me explain: have you heard about Supply Chain Attacks? They go about like this:

— “Madame Aria Salvatrice, this is GitHub here. Your javascript library YALP - Yet Another Left-Pad is used by Lockheed Martin, Monsanto, Electronic Arts, McDonald’s, and Adolf Hitler.”
— “Oh that thing i wrote one day i was shitfaced lmao i haven’t updated it in 8 years. Cool.”
— “And you just accepted a pull request by user KinkySatanicPuppygirl2 whose profile picture depicts the character named Leonmitchelli Galette des Rois from the Japanese animation series Dog Days (2011).”
— “Yeag.”
— “Your library is used to generate 26 billions of yearly revenue and this latest pull request added a vulnerabiliy to a cross-site buffer privilege distributed escalation spoofing attack (CVE-8008135). They demand a fix.”
— “Lol sucks to suck. Will they pay me?”
— “No”

CPython’s new JIT and PyPy’s JIT share fundamental similarities, as they’re both tracing JITs.

I spent ~7 years of my career optimizing existing code for PyPy at a high-frequency trading firm, and I realized that I’m probably one of the few people in the world with actual experience in optimizing real world Python code for a tracing JIT.

I expect that some of the challenges which I faced will still be valid also for CPython, and I wanted to share my experience to make sure that CPython core devs are aware of them.

One lesson which I learned is that the set of benchmarks in pyperformance are a good starting point, but they are not entirely representative of what you find in the wild.

The main goal of the talk is not to present solutions to these problems, but to raise awareness that they exist.

“So what?,” I hear you say. “I can easily use ALTER TABLE aircraft ALTER COLUMN range DROP NOT NULL if I want to drop that constraint, right? And then I don’t need the constraint name at all.” And you would be correct. However, what if you wanted to do other things to that constraint? For instance, foreign keys have the ability to be created as NOT VALID, and validated later; this is incredibly useful if your database is in continuous operation, because such a constraint addition can be made with very little disruption to your production load, because no lengthy scan of the data needs to be made. You couldn’t previously do that with not-null constraints. (Actually, you can create an invalid CHECK constraint, validate it, then add a not-null constraint (which doesn’t require a slow scan because of the CHECK constraint), then drop the CHECK constraint. But who wants to go to all that trouble!?)

Prioritization is a continuous dialogue, which is why frameworks, almost by definition, are only marginally helpful. Prioritization also occurs across fractal layers, ranging from directional ambitions to specific deliverables.

It is a never-ending journey between aspiration and pragmatism, optimism and skepticism, divergence and convergence, abundance and scarcity, and the dance of challenging constraints while also working within them.

The huge problem is that people look for quick fixes to REPLACE the conversation and the various tensions. We don’t want that.

The tension between limited capacity, limited capital, and ambition/intent is the game. It should be challenging — but the RIGHT kind of challenging. Juggling overly precise estimates and trying to fit arbitrary things into the quarter to prove out a weird say/do ratio is the WRONG kind of challenging. If you eliminate that tension or optimize for just one piece of the puzzle, you’ll end up with subpar results.

Your defense isn’t more code. It’s understanding HTTP deeply, knowing what your framework handles, using infrastructure layers for redundancy, and writing custom validation only where genuinely needed. Most security vulnerabilities come from unnecessary custom code that reimplements (incorrectly) what the framework already does correctly.

Well, all told, we needed 300 lines of Rust and Assembly code, excluding the examples, to write a pre-emptive task switching scheduler. I think that’s not bad at all, especially as the less code you write, the less you have to test and verify. We’ve seen how Armv7-M’s SysTick, PendSV and PSP functions are literally tailor-made for writing an RTOS. And I don’t think we missed C at any point? Very few lifetime or ownership and borrowing issues to worry about here.

In fact, we can do a little better. We can actually start at the very beginning, writing a skeletal version of the pixel-screen display that only uses the 1992 OpenGL 1.0 API, and then work our way up to the final 4.6 revision from 2017, picking up useful or newly-necessary capabilities as we go.