The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be.

I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)

It feels like editing a database, without any affordances for easily making common updates.

If the hours of a store are wrong on Google Maps, I just upload a photo of their store, and it'll be corrected quickly.

On OSM, well, most things are out of date. There's no simple 'update this business' flow, just a database editor. And a map that feels like I could break anything by clicking in the wrong spot.

OSM is a cool project, but it isn't straightforward. And unlike Google and Apple maps, most of the businesses in my area are years out of date, so I can't effectively use it to find information either, so I just don't have any reason to interact with it. Plus no aerial/satellite/streetview imagery, which I understand is probably infeasible, but ultimately it just means OSM is a niche product that won't replace Google.

So yeah, I'm propping up Google, but I get way more benefit out of it than having an open data set used to power Amazon's delivery driver routes or whatever.

And assuming about ((32x32 core-hours) / 8766 (hours/year)) x 45,000 = 5256 MIPS-years.

So within the order of magnitude of the 1999 factoring! Of course, the MIPS number is kinda made up, so

Install CADO-NFS per upstream directions.

Get the number you want to factor. I just did this in a python repl, something like:

    from cryptography import x509
    f = open("gold-server.pem", "rb").read()
    print(x509.load_pem_x509_certificate(f).public_key().public_numbers().n)

Then pass it to CADO-NFS. The full invocation for the server root was:

    ./cado-nfs.py 10754123440737946604182274398563307850262685121187325065132187145895199633213947273310647001521000121802425390193123548314361970563322281259804690831526167 -t 32 --workdir /data/cert1

These days with the CA/Browser forum, CCADB, and openly run root programs from Mozilla, Chrome and others, this is all much better documented than what went on in the early days, so I definitely have some strong historical interest in what came before.

The biggest thing I'm afraid of is that the generated scripts missed some entries, or otherwise mis-classified them, in particular whether it got the trust bits right for each root. I would put the chances of that having some errors relatively high.

But there's too many roots across too many browser installers, so I'm not going to confirm the Netscape UI matches what the extracted data says.

I've written and worked on a few TLS implementations, so it wasn't terribly interesting to me. And I have to go to work tomorrow and solve real, modern CA problems :)

But in short, I wanted to use Go, and it doesn't support SSLv3, the SSLv2 Client Hello, or the 40-bit RC4-MD5 export-grade cipher suites which I wanted to support too.

I was more shocked that I managed to get stock OpenSSL to issue a certificate that worked. There's a number of things that didn't work there, too. You can find my scars in mkcert.sh in the repo. Perhaps all of this is worthy of a follow-up post.

I could have tried to get some old server running instead, but I wouldn't have wanted to deploy that on the internet, even on an isolated Fly VM.

Naively looking at scaling factors is going to be tricky, because computation of this scale is going to involve things like "how do I hijack every GPU on the planet", or worrying about when the sun will run out of hydrogen if you're using a single CPU.

Steve Weis, who has been doing RSA factoring on some large GPU clusters, estimates factoring 1024-bit RSA would take about 2000 GPU-years, which is well within the range of anyone with a serious budget.

I haven’t paid too much attention to the TLS WG lately (for obvious reasons if you look at their mailing list), but I assume this is mostly a “if you want Post-Quantum cryptography, you need 1.3”.

I learned about <https://en.wikipedia.org/wiki/2011_T%C5%8Dhoku_earthquake_an...> from alarms like this, as sales in Japan almost entirely stopped.

I've been told a tale of another incident where some customer ran some huge cpu-intensive workload that didn't do any networking. It caused various alarms to fire because it "looked like" a part of the network was idle (potentially indicating some sort of networking failure)

It's generally (in the broad sense) easy to add alarms for things going wrong, but in my experience anomaly detectors are just as likely to fire from other weird things like that happening.

Here's a video of a day's food: https://www.instagram.com/reel/DZd8V8BtGbH/

She said she has two desalinators - one hand-pump and another electric, plus emergency water bottles to last a few days.

https://www.instagram.com/yourowkelsey/reels/

https://www.tiktok.com/@yourowkelsey

Here's a cabin tour: https://www.tiktok.com/@yourowkelsey/video/76461920366635778...

https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-... talks about FN-DSA and has a section about how it's require to hand-implement floats to get constant-time operations.