9 Comments
Mar 20Liked by James O'Malley

The good news is that as of July 2022, NIST picked Kyber (https://pq-crystals.org/kyber/index.shtml) as the standard post-quantum algorithm, and companies including Google and Cloudflare (which handles a big chunk of all web traffic globally) have been advertising it in TLS handshakes.

In Cloudflare's case, they've been doing it since September 2022. You can try it yourself by going to https://pq.cloudflareresearch.com/ using Google Chrome (you'll need to enable the special flag as described there). There's a longer discussion of Kyber and the various alternatives here- https://blog.cloudflare.com/nist-post-quantum-surprise/ . Disclosure: I work for Cloudflare.

Expand full comment

I remember working in 1998-99 on Y2K, one of my first jobs in IT.

Found and fixed hundreds of minor bugs and hit one major one: there was a storage system for documents (Word documents, mostly) that automatically deleted anything that hadn't been accessed for more than seven years and the calculation for the years would have gone haywire and deleted everything on 1 Jan 2000. Obviously, we fixed that!

Typical issues were things like it would display 2000 as 19100, but calculate just fine (it was treating 2000 as 100 and then sticking the characters 19 on the front).

Note that we still get date bugs - there are a bunch of systems that didn't work properly on 29 Feb this year because they don't handle leap years properly.

Expand full comment
Mar 20Liked by James O'Malley

Not Y2K-specific, but it was around 4 years after deploying a system that I discovered (when it broke) that years sometimes have 53 weeks. Time is hard to work with at the best of times!

Expand full comment

Yeah, date/time code can have bugs that you only find years later when it hits a date that has particular characteristics. Lots of people have written their own leap year implementations and they either set all years ending in 00 as not leap years (which created a problem in 2000) or they set tham as all leap years (which is only a problem in 1900 and 2100). Excel actually had the latter bug, it thought 1900 was a leap year; they fixed it for 2100 and after, but they deliberately left it in for 1900 because the first day in Excel is 1/1/1900 (so it only gets two months wrong, ie Jan/Feb 1900) and changing it would potentially break millions of existing spreadsheets.

For historians: this is why Excel won't deal with dates earlier than 1900.

Also: the first date in SQL is 01-01-1753, because the year where the UK lost eleven days was 1752 and they don't want to have to deal with the Julian/Gregorian calendar transition (and they can ignore Russia).

Expand full comment
Mar 21Liked by James O'Malley

Despite working for a mainframe manufacturer at the time I dodged all the Y2K projects, but I knew plenty of people who spent the late 90s on a massive testing and patching effort.

However I was able to exploit management fear to get paid triple time to do absolutely sod all over the New Year period. Happy days!

Expand full comment
Mar 21Liked by James O'Malley

I literally spat out my tea at the drive-by massacre of Matt Goodwin.

Expand full comment
author

I like to think my audience is the exact Venn diagram of "people who would read a 2000 piece about quantum computing" and "people who understand a fairly deep-cut reference to Matt Goodwin".

Expand full comment
Mar 20Liked by James O'Malley

Crikey. That was a cheerful read with my breakfast.

Expand full comment

Even if things are stored in 64 bit integers, there's still a surprising amount of 32bit libraries around. Everytime I build a new RDBMS release and it wants a 32bit version of the c libraries I'm thinking there's a weakness there

Expand full comment