Today I Learned

2026-05-13
Incident Report: CVE-2024-YIKES

Solid satire. Does a better job summarizing the things I was trying to convey in my previous post on JavaScript bloat.

2026-05-08
Lecture Friday: A New Way to look at Networking

This talk first covers two sections, though tersely, providing an overview of our move from telephony networks to packet-switched networks. I'd love more depth since it's likely difficult to follow without prior familiarity. If you've never seen an electromechanical automatic telephone exchange in action, go search for videos. They're super cool.

The harder part is that the third part is also terse, and he's introducing a new way of thinking about the role of a network. I'm left curious but apprehensive. For example, Kademlia already exists by the time of this talk. It's not the same as his pitch where he talks about being able to get access to your data using overhead airplanes, but I'm also skeptical of that sort of rhetoric. It's like talking about microcontrollers mixed into drywall to discuss the future of IoT.

To recap: Telegraphy understands the system as humans across the country with wires between them. By connecting two devices with a wire, you can send data from one end of the wire to the other nearly instantly. Applications use the network to send a message asynchronously. You first give someone on the network a message. They will then pass the message using the wires to another person on the network closer to the intended recipient. This repeats until the message reaches a person closest to the receiver, who will then deliver it when the recipient checks for new telegrams or by dispatching a courier.

Telephony understands the system as connecting wire segments into one long circuit between endpoints. It understands the system as a series of links. Applications specify a path through those links to create a circuit. By connecting devices to the ends of those temporary circuits, you can directly connect devices to each other over long distances.

TCP/IP understands the system as sender and receiver. By moving routing into the network and out of the application, you leave getting between the two up to the network. Your application only needs to know the name of its destination either directly by address or more commonly, indirectly by domain name, which translates into an address. Once you have that address, you can send data to that system and once you start sending, the receiver will obtain your address to reply.

In a data network as described, it sounds like the system removes the sender and receiver and only works on fetching and publishing data. Data has a name, systems do not. You request a name from the network or publish a list of available names to the network. The application requests a given data by name and the network fetches and returns the data for a given name for you, optionally caching it. But this is a subset of what networks currently provide, not a superset as pitched.

I'm ignoring the model where data is broadcast into the network and left there since it devolves into the storage server being treated as an edge node of the network. Someone has to store it and they're paying a cost to do so (both the cost of disk capacity and the opportunity cost to not store something else). I'm unlikely to pay for the network to store data for me if I can store it myself. Then I only have to cover the cost of transit less the savings from efficient caching that reduces the overhead on redundant copies. I might pay to store data if I don't want to run a server 24/7 or if I want redundant copies closer to users for faster response times. In that case, you can think of the network as running a server for you. He mentions the idea of networks just storing broadcast copies among nodes to move data around. That's space expensive and only makes sense when the storage cost is less than the cost to transit. This gets worse as the number of nodes in the network grows and only makes sense when more and more clients request the same data.

I'm not worried about the caching. That's the network's concern in this system as described. A robust caching scheme works when there is no caching. Availability of the data is still left to the endpoints. The network is responsible for returning data by name and storing a list of names endpoints are either publishing or subscribed to. The unfortunate part is that the network is free to return stale data and may return data after the publisher no longer wishes the data to be available. This is a trade-off. Similar to the existing trade-off in TCP/IP where your data may route through hostile nodes on the network because you don't control the paths anymore. By not connecting endpoints, only data, you lose control of lifetimes.

How do you send data back to the origin of some data? You need to be able to do this for dynamic RPCs. I don't just want to see my bank balance, I want to move money too. What's described is robust for static data, but hasn't really thought through mutable data beyond a vague versioning mechanism and generic to specific name alias. I need a way to, based on that first data, send some data back to a listener so they can create new data for me. Do you subscribe to data names and the network will ensure you get all updates to a name at least once? Do you have to poll for them? Are you able to publish names in a message that clients can publish back to? For example, how do you create an account on the New York Times? I assume I publish my account profile to the network indicating my preferences for investigative journalism. How do they know about it? If I update that profile, how do they get the changes? Do they subscribe to all of the millions of their customers' profiles published onto the network for updates? How are we efficiently tracking these subscriptions?

That also implies that data names can be rapidly added and removed from the network. If I have a bespoke data stream on top of the data network (like listing their bank balance or showing a checkout page), I'm publishing new names for each client in real time. How do we manage name propagation or discovery? It's not unsolvable, but does present considerable overhead for static nodes compared to the endpoint addressing scheme. Granted, mobile nodes present overhead right now, so it's a trade-off.

If a data's name is derived from the data, you can ban data. You can work around this by adding non-semantic padding to the data to generate new names for the same effective data. It’s notable that this enables tracking even with encrypted payloads. Since senders likely want to publish statically encrypted data to get any of the benefits of caching, you can track the contents of requests at the blob level, not just the service level. You may not know what they downloaded, but you can check if what you downloaded was downloaded by anyone else. You can include random padding data to ensure uniqueness, but that invalidates any of the wins this architecture could provide in caching since you're providing all users unique data. This also runs into the rapid name problem.

I know this talk was given in 2008, so security was still somewhat fuzzy. But he mentions the example of only being able to secure the tunnel, then alludes to how getting spam over a secure tunnel isn't great. He suggests the network could fix this. I'm not sure where he's going. Let's just ignore that emails are unencrypted here (it was 2008). Why is your network doing spam detection and not the server? This raises a number of red flags around censorship. He says you can communicate over anything that moves and therefore, don't worry. Sneakernets are a fun slot machine but quite limited. The equivalent of relying on those little libraries in front of houses instead of a metropolitan or university reference library.

Let's talk mobile endpoints, which is one area he touts. This is one year before the IETF starts work on MPTCP to allow cellular networks to send a TCP stream over multiple edge connections. That protocol allows seamless transition of a stream as you move between towers. For a query response model on static data, this design is pretty streamlined. It just unfortunately requires applications to be explicitly designed to take advantage of it, unlike MPTCP which was designed to be transparent to applications. Backward compatibility tends to win.

Given the marginal gains for mobile connectivity, the broader question becomes whether this architecture could replace the current stack or simply layer onto it. And this brings me to extend versus overlay. TCP/IP emerged because it could be overlaid on the existing network until it proved valuable enough for networks to pay for equipment capable of moving it down into the hardware. After that, it inspired converged networks where it became easier to run packet networks and run voice on top than run voice networks and packets simultaneously. To that end, is it easier to run data networks and run connections on top? Could you for example run a voice call on this data network? I'm not so sure.

And that's also where my mind goes. We've rigged up the existing system to provide essentially what this does by treating addresses much like names function in the hypothetical data network. You can use BGP to anycast an address and/or GeoDNS to split-horizon a name with different addresses based on where the requester's IP address implies the client is geographically. This is how a CDN works. It's an overlay that excels at static data. It pretends to be a single HTTP server but in reality is many different servers that all serve the same data.

He mentions Akamai but says you can't use a CDN for the Olympics because it's dynamic content. I'm not sure that's right. You can stream video in chunks to distribution servers that clients pull from. Just add a layer to your star topology. Instead of everyone pulling from the origin you setup proxy distributors that pull from the origin and each have a subset of all clients. Still too many clients? Add another star layer. Origin to intermediate distribution, those out to end delivery. This is why every data link standard converges to serial point-to-point links connected in a tiered-star topology transporting packets.

For benefits, you could save the DNS round trip since the network inherently speaks names. On the other hand, everyone publishing things on the web effectively contributes to what becomes BGP routing updates. He notes that the design of names would have to be very careful, and this is partly why. Route aggregation is critical to the function of the internet. Storing individual routes for all four billion IPv4 addresses in fast hardware memory is prohibitively expensive. Now imagine storing just every HTTP path on every domain. This assumes every endpoint returns static data, a vast undercount of the number of names the system needs to handle. Without a hierarchical naming system, flat name routing would bloat forwarding tables. Giving the power of what is effectively BGP router advertisements to adversarial users is a disaster waiting to happen.

If it doesn't need to be a new internet, it could be useful for clients to explicitly support a protocol designed to be a CDN overlay on top of TCP/IP. Otherwise we're stuck cobbling it together using a dozen different protocols. Not sure if there's a good business case to get networks to adopt this transport. Speaking of business model as he did, the biggest flaw right now is the complete collapse of network companies in America and Europe. They've consolidated into monopolies and outsourced all their expertise. You're not going to see anything interesting out of them anymore without using politics to reshape the way they make money.

To give this something of a conclusion, I know I've raised objection after objection. That's probably just because I'm not fully getting it. Understanding these sorts of ideas and working through the implications is a lot of fun. It's kind of like alternative history fan fiction. Sometimes that helps you realize we're stuck in a local minima. Other times you realize we're just stuck with a set of trade-offs and there's a different set of trade-offs that were possible that we didn't end up with. Like Dvorak or Colemak keyboard layouts, foundational changes usually require the alternative to improve things by an order of magnitude to see widespread adoption, not just ten or twenty percent. We can't even switch to IPv6 to get rid of the NAT hack we added to buy time. There's just got to be an unmistakable business case to switching. In the case of IPv6, not switching is creating a reverse pressure as it creates a rental market for addresses.

2026-05-01
Lecture Friday: Practical Techniques For Predicting The Future

A decade-old lecture on forecasting the future. Spoiler: it holds up. His five rules remain ironclad. I can't think of anything in the last ten years that undermines the framework.

One big thing he missed is our continuing slide from empiricism into tribalism, where technology adoption has to be understood through partisan affiliation rather than personal experience. Not that we were purely empirical then and purely partisan now. We're just in a gradual transition, which is changing the dynamics of adoption. It helps catch edge cases like understanding how important people's egos were to Flickr.

He's a bit too enthusiastic about VR, but he admits this is because it's his area of research. I think presence is really cool, I'm just not convinced it's a foundational technology. At the very least, there's just been a series of huge missteps in the industry. Despite the flagship success of VRChat and Beat Saber, they've both made a series of bad management choices. Later games did better, like Batman: Arkham Shadow and Half-Life: Alyx (a.k.a. Half-Life 3). Yet these early blunders resulted in lasting damage to the VR ecosystem because they set a tone and people didn't easily come back. The Metaverse is probably on par with New Coke as a commercial failure. It'll be added to classroom case studies for a decade or more. Hopefully with the moneyzillas out of the picture, interesting things by small creative teams can start to flourish.

The problem, though, is that modern socialization is now highly fragmented. Highly social people bounce between literally dozens of different group chats with overlapping groups of people, navigating which group knows what to be sure messages fit the pre-existing context. I'm not sure prolonged socialization digitally, where you have to immerse yourself, is even desirable outside of romantic encounters anymore. This is where I think VRChat and its clones just couldn't pull it off, but someone else might. Allowing non-VR users was one big mistake. It's done to grow user count under the guise of making it easier to try but it allows people to miss half the fundamental experience while thinking they saw what there was to experience and thus miss the core point. Instead of working hard to make the minimum specs as low as possible, set a robust floor for enthusiasts. Perhaps eye tracking needs to be non-optional?

Still, his call that AR would only really appeal to children was pretty accurate. Even with a coat of Apple mystique, headsets are still dorky, but photo filters were huge for a while. He even predicted Nintendo's success the year after. He did miss that nostalgia is one hell of a drug, though. AR has become a huge deal for video meetings where most people use it to hide their room. It's essentially the modern computer wallpaper. It's table stakes for these applications now, but I don't think it's something that makes anyone any money.

The hard part with children is cost. Tech is expensive, and children's toys just aren't. Everything for children has to hit a price point that's extremely low. It's just what happens when your target market has little to no disposable income. Meanwhile, I recently went to a graduate showcase for media studies and game design students, and there was a surprising number of VR experiences the students were working on. Other pieces were predicting the future of an AI singularity, so obviously take this as anecdata, but VR adoption may have more generational divergence than we think, which may materialize more as they acquire more buying power. The experience is going to have to be very valuable to overcome the friction of headset brace face, whacking your knees on nearby furniture, and installing and calibrating the motion sensors in your room. Headsets with eye tracking are more expensive, and that further limits the social impact. Same with adding limb trackers. And yet, PlayStation VR may just have been a catalyst. Its very low cost meant you could buy one for your kids. I'm just not sure if they enjoyed it enough to pay a high price later for something better.

And that's another hidden lesson: the impact that purchasing power has on technology. As we squeeze out the middle class, we'll see larger and larger pivots to providing goods and services exclusively for the rich, and that will curtail the futures you're likely to experience. As Gibson notes, "The future is already here — it's just not very evenly distributed." It's why many professions have already become app-based gig work with more being transitioned every year. All while we pour trillions of dollars into betting on AI. The R&D is being spent chasing rich money because there's more and more of it and less elsewhere.

The problem is rich money continues to chase abstract wealth. Don't make things, rent them. Don't rent them, own a rental company. Don't own a company, sell it to a conglomerate. Don't conglomerate into a monopoly, own shares in a monopoly. Don't own shares, bet on derivatives and outcomes. Don't bet your money, use AI to write an algorithm to bet others' money and charge fees. What does that say about future trends in technology?

2026-04-24
Lecture Friday: You and Your Research

I recall sharing this with a colleague and his response was essentially, "This is arrogant claiming that doing academic research is the best thing you can do with your life." I don't think that's what he's driving at. It's just that Hamming's life's work was academic research. That's what significant success looked like to him, so he's talking about that as an example. What he's talking about broadly is how to do something significant. It distils the tips and strategies he found success with on his journey and serves to point out, if he can do it, so can anyone.

This could just as easily be about starting a company, becoming a top musician or artist, climbing your career ladder, having a life of memorable experiences, raising a family, or any number of other things. Just focus on not being mediocre in your true pursuit. Why spend the few decades you have doing nothing of import?

2026-04-22
Cybersecurity Looks Like Proof of Work Now

LLMs have finally found their killer app. Finding security exploits really hits the trifecta of where LLMs excel:

1. when output quality and maintainability don't matter,
2. success is objective and easy for the system to measure, and
3. each output is worth a large amount of money already.

Security exploit chains in monoculture/duopoly software are extremely valuable to governments and organized crime who will pay top dollar for tools that use them to spy on journalists, terrorize dissidents, attack critical infrastructure, and make a boatload of cash with ransomware. The market for these exploits is high value and growing. With high value targets being worth millions of dollars per exploit, spending hundreds of thousands of dollars on compute for these still makes it a 10x productivity improvement compared to the status quo.

When I say the output quality doesn't matter and it's easy to measure, I mean, adversaries will wade through even complete nonsense if it demonstrably opens Notepad on a Windows machine without user intervention. It's super easy to write a test for, and thus extremely clear to check. The rest could involve a million monkeys on a million typewriters for all anyone's concerned.

A report published and reviewed by the 'who's who' of security notes the same thing. Yes there have been many fuzzers and scanning tools before the use of LLMs, but something's happened in the last few weeks. I didn't post it here at the time, but cURL canceled their bug bounty program at the end of January because they were getting flooded with slop. It's April and they've completely changed their tune.

It's going to be a rough couple years and the future of software security seems more and more like proof of work.

2026-04-17
Lecture Friday: Dream Team: Why GitHub Has Never Lost an Employee

Obviously the premiss is not still true, but I think the key takeaways from this talk about early GitHub are still worth considering. This was roughly 5 years after they founded, which would put it longer than the common 2-3 year jump rate I've seen among many developers. Counter point, they formed following the 2008 financial crisis. One of the unstated but likely bigger reasons was just that everyone felt like friends. This is by far one of the biggest reasons people tend to stay at companies since it's both a force holding them back and a force repelling from a new company (not knowing anyone there). You can extrapolate this when he's talking about their music culture and flying out someone else for conferences.

On the why people leave side, it's usually some combination of crappy boss, being forced to do things you don't see as valuable, and better compensation elsewhere.

For a proper framework for understanding why people leave your company, check out The Ultimate Guide to JTBD which uses a 2x2 matrix to understand why people change products. Applying that to changing jobs works just as well.

2026-04-16
The Economics of Software Teams: Why Most Engineering Organizations Are Flying Blind

You should take your time reviewing the metric matrix in depth.

It's weird reading "The Liability Hiding as an Asset" section. On one hand, I completely agree that your source code is a liability—not an asset. On the other hand, I don't think a vibe-coded copy is the reason you should see your source code as a liability. You should see it as a liability because the source code isn't the business value. The business is valuable because of the processes you deliver to customers. These processes are encoded in software but live in the heads of your customers and the product teams, not the code. The code is a tool they've used to encode and automate those processes. That encoding is an inexact representation of the real processes. That inexact encoding is experienced as friction by your customers. You make money because people can pay you to outsource processes that are slower, less desirable, or less valuable when performing them without your products. It's also important to understand that not all processes are equally valuable; some are even costing you money.

Other than that quibble, I agree that software developers need to understand that their employment is premised on the idea that the company will make roughly 6x their salary in profit from their work every year. You get 6x because your fully loaded salary (when you account for office space, time off, benefits, taxes, and support like IT and HR) is roughly 2x the cost of your take-home pay. The remaining factor of 3x is because most projects fail to increase revenue or reduce costs, so all the real revenue gains have to offset all the losses on failures or time spent on less productive work to prevent running out of money.

That's the reality of running a business. Software development is extremely expensive. The last decade and a half has fostered many bazaar businesses and thus trained many to expect that running around doing whatever you want while being wildly unprofitable is somehow a fine way to run a business. You now have to convince investors you have a serious chance of beating bond yields to get investment money if you can get it at all. Learning to categorize work as revenue increasing, loss decreasing, or frivolous is now more important than ever.

2026-04-15
How I Run Multiple $10K MRR Companies On A $20/month Tech Stack

This is exactly what I keep going on about. Some great tips in there, especially for those of us waiting for LLMs to stabilize.

Obviously not aligned on every detail, but a lot of this is just how you build software when you don't have dump trucks of investor cash to set ablaze. A skill that seems increasingly rare these days thanks to scale fever. My favourite part was reading the comments. Not everyone there is beyond hope, but I sure lost mine trying to read through those.

2026-04-10
Lecture Friday: The Silver Bullet Syndrome

He's up front. You won't learn anything from this talk. It's one of those great art of the rant style talks. If anything, maybe it'll help those who haven't seen the silver bullet syndrome in action learn before they end up propagating this mistake.

2026-04-06
Against the State – A Primer on Terrorism, Insurgency and Protest

I think I remember once reading that part of the reason for expanding the student loan program was to provide leverage to demand changes to the curriculums of universities. Specifically to get classes on politics, history, and civic participation curtailed by noting contemptuously that schools were indoctrinating students with classes on how to protest (reminds me of recent remarks about basket weaving). I can't find the source so I'm pretty sure it's either a lie or I'm misremembering something. That said, more people could use an education on protesting. Too many people think protests themselves change things. Let's all get together in front of a government building for an afternoon of sign holding.

Without a long term coordinated effort to change policy behind a protest, a protest is meaningless. Protests in and of themselves don't do anything. They're a tool of political action. You have to know how to properly use such a tool. This is an introduction to what that tool is and how it works. My thanks to Dr. Devereaux for all his work on his blog. It really is a modern example of what the old web's blogs were all about. Something I hope I'm helping carry forward in my own little way.

2026-04-05
Scalability! But at what COST?

One of the keys to picking the right architecture is first understanding what the machines you're running on are actually capable of. A typical server in 2026 is an absolute behemoth. Many small to medium sized tech companies could run their entire SaaS app on a single 42U rack of hardware if they stopped fad chasing and started writing moderately performance aware software focused on optimizing their COGS.

2026-04-04
We Haven't Seen the Worst of What Gambling and Prediction Markets Will Do to America

I've not got much to add here. I guess I should point out, it's not just the United States of America like the title claims, but I assume that's fairly obvious. Welcome the next big tech hype after generative AI.

2026-04-03
Lecture Friday: The Beauty of Bézier Curves

You may have already watched this video given its view count and featuring in the Summer of Math Exposition from 3Blue1Brown. If you haven't, it's definitely worth the watch.

While you can't calculate the distance along the bézier in closed form, you can at least calculate the roots as I do in my bézier visualizer using Cardano's Method. Just an extra tidbit I found hard to locate when I was doing my research for that project.

2026-04-02
The Three Pillars of JavaScript Bloat

Great rundown on the problem and a number of tools to help you solve it.

We're definitely at a tipping point as an industry. Security vulnerabilities are now being routinely exploited within hours of a patch being made available. Supply chain attacks are punishing those too eager to update. We're being squeezed on both sides.

Your best defence is to narrow and shorten your supply chains. You need fewer dependencies. We just saw the axios supply chain attack. Maybe you dodged the bullet because you pinned dependencies and waited a few days. Something is going to sneak through. How much longer until something as brutal as the XZ backdoor slips through without someone managing to catch it early enough to save you?

Fewer dependencies make every other countermeasure more effective. If you think scanning is the answer, there is still a false negative rate to worry about. If this scanning is centralized at the public repository level, attackers can easily keep probing until they find something that slips through in throw away accounts before launching their attack. If there are vendor solutions, those can also be tested VirusTotal style. If you're instead focused on manually reviewing and signing off on updates, good luck having your team manually review tens or hundreds of updates a week. Every countermeasure is harder at scale. You're going to have to descale.

That said, if you've got a better idea than manual or automated review, there could be a million-dollar idea in there. For now I'm building a little tool that feeds the diff of package updates to an LLM to try and flag suspicious code for manual review. A hybrid approach run locally. It's not a great solution, but I'm also sure it's only a matter of time until the antivirus vendors catch on and offer basically the same thing but with much better classifiers and heuristics.

The problem is that every source code dependency has effectively complete and unrestricted access. I'd love it if my execution runtime could come with something like pledge(2) at the module level so I could create a list of just the allowed permissions each package is allowed to use. Then a module can only call other modules that have a subset of its own privileges. I'd even use this for my own code like I do already at the process level. Start by getting an inventory and then strictly watch that new additions are appropriate. The hard part is doing it without requiring a whole new programming language or dependency ecosystem.

In any case, a little duplication is better than a little dependency.

2026-04-01
Shell Tricks That Actually Make Life Easier (And Save Your Sanity)

As someone who spends easily over 85% of my time in a terminal, it's rare for me to learn something new from one of these sorts of articles, especially those starting with simple concepts. I did not know about Ctrl-Y.

Kudos to the author here. This is the exact sort of list of everyday things I use too, so it's likely from the top of their head and not just regurgitating the Zsh manual at you. Not everything noted is a daily mainstay for me (I've never needed pushd/popd), but it's got a lot of the things I use constantly and very little else I don't use.

Here is one bonus tip: they cover cd - but didn't mention just running cd without an argument. That takes you to your home directory.