ls65536

Another place to search for private key candidates would be the outputs of various common PRNGs when they have been seeded with a timestamp (for all timestamps in, say, the past 20 years).

These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).

It shifts the problem elsewhere, though as you suggest it's sometimes still the same people having to deal with it! For example, anyone relying on celestial navigation who had until now been satisfied with up to 1 second of time error is going to need to start keeping track of UT1-UTC before it starts exceeding those old bounds. This will be possibly within a few years, whenever the next leap second would have been inserted/removed.

I've set up all NFS mounts within my home LAN over WireGuard partly for this exact reason. The impacts to bandwidth and latency are negligible, and even the increase in CPU usage remains relatively low (at least on non-ancient hardware). This reduces some of my worries about silent data corruption (at least from this potential source).

That format looks like it would allow for up to 10k per day. Unless one of those X's is a check digit?

> just have a single timezone

We already have UTC, which is almost always used as the legal basis for all local timezone definitions. In many industries (such as in many aviation and maritime operations), UTC is used almost exclusively to synchronize things worldwide and to avoid any local timezone confusion that might cause problems.

So using UTC works great in situations where participants span multiple timezones. But I think the intuition of maintaining a local clock for local things, with solar noon kept somewhere approximately around clock noon, is still useful, since many day-to-day scheduling concerns remain entirely within one's local timezone. The key is that participants must be aware of their local timezone's offset from UTC. Not having to change their clocks twice a year would hopefully also make this easier.

In this case, the analysis focuses on Canada, which does have a few population centres around the same latitude as London.

Very unfortunate timing given the ongoing wildfires and associated smoke spreading across eastern North America in recent days.

There's an agreement to do something about leap seconds before 2035, either by allowing DUT1 to exceed its currently specified bounds (this is most likely) or by agreeing to simply not insert/delete leap seconds going forward (this is less likely). For certain bounds on DUT1 and at some timescale, these would be practically the same in terms of their effects on civilization, computing, etc. In any case, a decision will almost certainly be made much sooner than 2035, perhaps even before the next leap second insertion/deletion would need to take place under the present rules.

I have a machine that's on a Debian installation that I've been steadily upgrading, one Debian stable release at a time, since I originally installed it about a decade ago now. At one point I even copied the entire installation to another disk (just a "dd" from its original SATA SSD to a new NVMe one, plus some partition and filesystem resizing), and I've upgraded the CPU/motherboard/RAM at another time, and it just keeps going reliably. It's fun knowing that the origin of that Debian installation predates every hardware component it's presently running on (with the exception of only the case and power supply).

They bought P.A. Semi, but it was for their design capability; they never had fabs anyway, and Apple still depends on TSMC and others for manufacturing chips. Apple building fabs to ensure a guaranteed supply of memory (or logic) chips would be an unprecedented level of vertical integration, even for them.

~450 square feet, with how many feet in the third dimension? You probably had an order of magnitude more volume than 330 cubic feet there.