[TUHS] The 2038 bug...

Theodore Ts'o tytso at mit.edu
Fri Jan 1 04:36:25 AEST 2021

On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
> So if you *can* rebuild the software for a newer architecture…then
> suddenly there’s a wider time_t and the 33d bit is suddenly 1 but
> nothing breaks.  And if you can’t, you’re probably by that point
> running it in emulation anyway, at which point your emulation
> environment can know that 1/1/1970 is really whatever/2038, and your
> software is partying like it was just 1969.

Emulation is the key problem.  I still have a production server
running on a Linode VM which was installed using Debian 6.0 using i386
binaries sometime in 2011.  I kept it on 32-bits because it's more RAM
efficient, and it would have been a pain to reconfigure all of its
services if I were to reinstall it to use a 64-bit OS --- and Debian
has had silky-smooth upgrades from Debian 6.0 all the way up to Debian
10.0 in 2019.  There is some discussion of dropping i386 support in
Debian, which may force the issue, but up until now, it's just been
easier for me to do major updates every 2-3 years to the latest Debian
stable, and rely on security updates in between major updates.

Twenty years ago, one of larger customers for the company I was
working for at the time (VA Linux Systems) was one of the new
electronic stock exchanges, and they were using Linux boxes with
PDP-11 emulators because their stock trading software was written in
Macro-11 and running on RSTS/E.  They had tried three times to rewrite
it so it could run on something more modern, but each time, the
rewrite had ended in failure.  So they simply sharded the problem, so
one x86 server running RSTS/E in emulation would service stocks
symbols AAAA--ADZZ, and the next would service stocks AEAA--AFZZ, and
so on.  Given that this was back in 1999, I assume they had solved the
Y2K problem one way or another, but even if they hadn't yet, I suspect
it would have been easier for them to fix the problem by asking their
dedicated Macro-11 Software Engineering team to fix it, than to ask
that same team to help the other team put themselves out of a job
(which for some reason, never seemed to happen successfully...)

       	   		      	     	- Ted

More information about the TUHS mailing list