The speed of light calculations are interesting, but don’t quite strike the heart of the matter. There are a few other important ways that latency can be improved (and are being improved every day!):

1. Boston and Seattle are two wealthy, tech-heavy cities that are connected across the Northern US through a fairly straight line of other cities, as the author mentioned. But what about any route that is not so simple? Plenty of other cities around the world (or even within the US) don’t have efficient paths to Seattle. One way to visualize this is Hurricane Electric’s layer-2 map which gives a force-directed graph of their PoPs and the connections between them. It’s not difficult to find cities that require circuitous routes to reach each other. As new fiber connects those cities, routes improve.
2. The opportunities expand when crossing oceans, as the much more limited routes of undersea cables constrain you. When I visit websites in the US from the UK, I can be pretty sure that my traffic goes straight over the pond. But if you live anywhere else, your traffic has to go to a cable landing station that might be a continent away. You can peruse through Telegeography’s map, which is improving every year as new cable-laying projects complete.
3. Perhaps most importantly, advances in networking and distributed computing mean we can put ourselves closer to where our packets need to go (this is why CDNs were invented). In the author’s example, what if CSAIL could have responded from San Jose? Or even from Seattle? That would cut down latency in ways that even “death rays” can’t.

Finding time to write down notes about things I’ve learned so I don’t forget them over the years. Inspired partly by https://lobste.rs/s/lubstu/personal_wikis_lobsters_tale, but also trying to make myself a little more disciplined about it by making the notes public.

Finished the first one earlier this week, about methods to use traceroute etc. for determining where data goes across the globe, and the many difficulties involved.

Then I plan to use some time on my 11hr LHR->SFO flight tomorrow to read some Lovecraft (At the Mountains of Madness in particular) which somehow I missed when I was younger.

This is also why when Wisconsin Circuit Courts moved from “unnamed commercial database” to Postgres, Kevin Grittner couldn’t say what the previous poorly-performing software was. Although as it was gov’t I assume it would have been easy to get the data on who was being paid for licensing.

https://www.postgresql.org/message-id/46D70B5C.EE98.0025.0%40wicourts.gov

An interesting read, as usual. On the observation that applications often make a huge number of syscalls that may not be necessary, and which require peeling back many layers of abstraction to even understand where they come from (as in the SDL case) – Dave Jones had a fun paper a little while back with a laundry list of everyday apps in the Linux ecosystem that make syscalls that seem absolutely insane, which people rarely notice because we’re not typically aware of all the subtleties of the millions of operations that our apps perform every moment: https://www.kernel.org/doc/ols/2006/ols2006v1-pages-441-450.pdf