If you want an ESP32 dev board with GPIOs exposed there are dozens (or hundreds, maybe thousands) of other options out there. It makes sense not to expose them when you're going for the smallest possible footprint.
I think the reasoning behind this is because of the nature of the file being pushed - from the post mortem:
"This feature file is refreshed every few minutes and published to our entire network and allows us to react to variations in traffic flows across the Internet. It allows us to react to new types of bots and new bot attacks. So it’s critical that it is rolled out frequently and rapidly as bad actors change their tactics quickly."
In this case, the file fails quickly. A pretest that consists of just attempting to load the file would have caught it. Minutes is more than enough time to perform such a check.
I believe the purpose of choosing such an odd scenario is to show that, while you might think that you can beat the generic sort algos with a more domain-specific implementation, you might be wrong, or you might not gain enough performance to make it worth the other pitfalls of using such algos
Could be, I seem to recall some relationship. It was just that blitzortung didn't work right for me. While lightningmaps did. Anyways. That's from years (maybe 10?) ago.
Maybe my browser just got better? Who knows :-)
By working right, I mean whenever I see flickering from afar, or hearing the first rolling of thunder, clicking on it without much fuss, maybe zooming out, shifting a little, zooming back in and seeing what's going on where instantly.
Which in the context of larger storms works even better in kachelmannwetter.com, because there it's embedded in other data, and projected where it moves/arrives in how many minutes in easily understandable symbology. But that's for Germany only. Useless for Colorado. Havn't found something comparable for there, so far. Would be mostly useless anyways, because weather at 2600+ m altitude changes faster. Or can.
