Adam Langley

1.3K Followers
44 Following
177 Posts

Recent podcast episodes that I particularly enjoyed, and that might be worth your time.

Deliberately, none of them are about current affairs. Not that you should be cut off from the world, but I need to measure my intake of it in times like this. (The second and last are more anchored in the current moment, so choose your own mixture as desired.)

* Ada Palmer on understanding the Renaissance: https://www.dwarkesh.com/p/ada-palmer
* Joe Weisenthal on literate and oral cultures: https://www.theringer.com/podcasts/plain-english-with-derek-thompson/2026/02/17/the-media-theory-that-explains-99-percent-of-everything
* Acquired on the history of Formula 1 racing: https://www.acquired.fm/episodes/formula-1 (It seems silly to link to an Acquired podcast; it seems like the most popular podcast in the world at the moment. But I'm still finding that people aren't aware of it so, if that includes you, here you go.)
* Hank Green on running an education company: https://podcasts.voxmedia.com/show/decoder-with-nilay-patel (I can't seem to link to a specific episode, but it was only a few weeks back).

How cosplaying Ancient Rome led to the scientific revolution

Ambassador visiting Renaissance Florence: “Where am I? None of this has existed for a thousand years."

Dwarkesh Podcast

Dustin Moody from NIST: “you don’t need more than 128 bits of symmetric keys for post-quantum security” #rwc2026

Say it louder, for the people in the back!

@tynstar Indeed! There are likely services already which do this. (And I've used one in the past.) They'll be more polished and featureful. But the no account, no emails, exactly-what-you-need nature is nice for my basic use.

Since custom little utilities are now almost free for the technically-minded, I guess I value of ideas for them has increased.

In light of that, two things that have been making my life slightly better this week:

* A Chrome extension that lets you select any div on a page and then downloads the contents of that div (including images) as an EPUB for putting on an ereader.

* A job that runs on a little server that monitors my email and, based on a YAML file of regexps for sender, subject, etc, will notify me via Pushover if a matching email is received. (No polling, thanks to JMAP.)

I'm not saying the Trump administration is turning the US into a dystopian hellscape, but when the local newspaper needs to help you identify what toxic gas Federal agents are unleashing on citizens, I think it speaks for itself.

It seems that py/cryptography's thoughts about OpenSSL (https://cryptography.io/en/latest/statements/state-of-openssl/) are doing the rounds at the moment.

I've not touched OpenSSL directly in a long time. In fact, it appears that the 10-year anniversary of that (https://www.imperialviolet.org/2015/10/17/boringssl.html) passed by a few months ago!

So I've no direct comments on the piece but, a long time ago, I was in the position where I was landing changes in both OpenSSL and NSS (Mozilla's TLS library). OpenSSL was somewhat famous for having bad code. And, indeed, if you looked at it back then the functions were full of single-letter variable names with pointer arithmetic everywhere and context-free, somewhat scary comments. It wasn't outside the norm for 1990s C code, but I understand why people recoiled.

In contrast, if you looked at NSS code, it looked good! Consistent formatting (before clang-format), good naming, good comments.

But NSS had a PKCS#11 abstraction layer and, even after years, I never could understand how the control flow worked there. I would have to single-step in gdb every time to figure out where an operation grounded out into actual code. I was reminded of that when reading py/cryptography's descriptions of OpenSSL 3.0.

I had a pet theory at the time that, because OpenSSL was repulsive on the surface, it inhibited people enough that they couldn't add much deeper complexity. But NSS, with its invitingly clean-looking code, was understandable and then people had enough capacity left over to add deeper complexity.

There might be something to it, although you shouldn't discount the fact that entities who are willing to fund cryptography libraries often have demands that are contrary to clean code. Things like FIPS compliance and compatibility with a zoo of different accelerators and bespoke needs.

So rather it might have been that old OpenSSL was old OpenSSL because it was mostly unfunded. That meant that it looked pretty ragged, but also there weren't so many demands in tension with good design.

NSS was funded by interests that really cared about PKCS#11 compatibility so that you could use a super-expensive, certified-everything HSM with it. When OpenSSL got shocked into switching to a higher-funding model, that brought lots of those same sorts of competing interests, and then the incentives pointed towards adding slow, impenetrable layers of abstraction all over.

The State of OpenSSL for pyca/cryptography — Cryptography 47.0.0.dev1 documentation

@evmar But it's all about history, no?

In order to use limited address space in the past, some CPU decided that stack grows down and heap grows up. But I don't know of a reason that it couldn't be the other way around. However, somewhere along the line, it was seemingly convenient for someone to put the stack at the top and that happened to stick.

When threads were introduced, they existed in the context of an ecosystem of compilers and everything else that assume a downwards-growing stack, so they continued to do that. Why fight to change?

The only serious attempt to break away given the new realities of threads that I'm aware of was Go's segmented stacks. But Go gave up on them because (I think) of the excessive runtime costs if a thread frequently grew and shrunk its stack across a segment boundary. (Not sure about that motivation, however.)

Even when the underlying reality changes, the status quo has a strong grip. People are deeply creatures of habit. It's also difficult for the emerging understanding to overcome the barrier of becoming "common knowledge" and, prior to that, people will follow old patterns because they assume that it's expected.

High-salience events create new common knowledge and so lead to larger changes in behaviour than might otherwise be justified. For example, the '56 Suez crisis was a high-salience event that communicated that world power had shifted from Europe to the US. Its impact was much greater than a narrow analysis would convey.

The Russo-Ukrainian war and today's events are also high-salience, and they communicate that there aren't any rules any longer.

One consequence is that, in the absence of Pax(ish) Americana, the only effective defense is a nuclear one. This was well understood: a lot of the motivation for creating the post-WWII system was to create an alternative to nuclear weapons. But Libya gave up its program and Gaddafi ended up dead. Ukraine gave up its weapons and got invaded. Venezuela didn't have them.

It'll take a while for this to play out, but I suspect keeping it in mind will help with understanding the news over the next decade or so.

How come James Cameron is the only person who can make 3D movies?

There were trailers before it, in 3D, and they looked bad. But then Avatar itself is visually stunning — again. ("IMAX" 3D.)

The first Avatar was revelatory but audiences (including me) quickly learnt that in every other case 2D movies were actually better than than the 3D version.

Except Avatar movies, which continue to be astonishingly pretty. This one is even better looking than the last due to mostly avoiding the weird frame rate switches.

If you find yourself traveling, cooking, cleaning, etc by yourself in the coming week, one of my favourite podcasts has had a great series on tracking down some nasty bugs recently.

Consider it like a murder mystery podcast, but for systems issues. If that sounds fun to you, peruse:

https://oxide-and-friends.transistor.fm/episodes/futurelock

https://oxide-and-friends.transistor.fm/episodes/grown-up-zfs-data-corruption-bug

https://oxide-and-friends.transistor.fm/episodes/death-by-uptime

Oxide and Friends | Futurelock

We're big users of async Rust at Oxide, and recently we found (another) very odd and hard to debug pathology related to async Rust that we dubbed

Oxide and Friends