I think Linux has adopted 64-bit timestamps on 32-bit systems as well by now.
Mainframes don't run Unix in the way we think of it, and the applications they run store timestamps in a different format (hence the panic about Y2K back in the day). I'm by no means an expert, but I think these people don't need to worry about Y2K38.
Yeah, I am versed in the COBOL world as much as the next guy (so not much at all), but I would sleep better knowing that the financial systems are safe from yet one more end-of-the-world crisis.
I heard some banks "fixed" the Y2K problem by shifting the offset, i.e. defining that year numbers from "00" to, say, "15" were interpreted as "2000" to "2015", giving them some time to fix the problem without the stress... ... and then doing nothing for a decade or so.
The financial world has not collapsed so far, so they must have found some way to deal with that. But I'm not sure I really want to know what "solution" they went for.
Just like with Y2K a lot of things are proofed already. But to avoid things falling over, everything has to be proofed. Not just the kernel, also file formats, file system formats, programming languages and libraries and applications.
That’s a big project with a lot of players and we won’t know if they all did their job right until the clock rolls over.
As pointed out later in the thread, the code in question is checking for dates before 1975, and is actually likely triggering on a zeroed-out superblock in a filesystem somewhere.
More interesting, and not noticed here, is the discussion in that thread about how Sun mapped SCSI IDs around.
While my nostalgia bone is tickled fiercely by this picture, I wonder what is the appeal of running SunOS these days. NetBSD shoud work on that machine, too, and that would give you at least some modern features like a current OpenSSH, IPv6, an up to date software stack...
I used to contract for a company that did semiconductors and some of the clean room equipment was running ancient stuff on computers that live in a metal box attached to the equipment. I've seen Solaris 2.5.1 x86, I've seen windows 95, some of them run weird flavors of windows server 2003 SP1, and all of them need to be connected to the network but no, you cannot update them because the support contract for the machine says if you break something you're out a mil or two.
I would have loved to tell them to go to hell and install sane software but obviously that wasn't my call to make and even so the reason the manufacturer doesn't update the OS is that the guy who wrote the drivers left 15 years ago
That kind of story also tickles my nostalgia bone heavily, but I see how up close it's a nightmare. I've seen, less than ten years ago, an industrial plant where the SCADA boxes were running NT 4.0, with plans - plans! - to eventually upgrade to Windows XP, hopefully before the hardware died. Part of the software stack ran on an ancient version of QNX, running several DOS applications on several terminals concurrently. (My guess is that QNX being a RTOS allows it to handle multiple instances of the quasi-realtime DOS application gracefully.) The hardware interface to the SCADA system was a proprietary ISA card that is no longer being built, and of course there is no replacement for PCI or PCIe. The licensing dongle is attached to the parallel port, and the way the software talks to it is so peculiar it has to be a "real" parallel port, a USB-to-parallel adapter does not work (at least not reliably enough to be useful). At least none of these machines were connected to the Internet.
If any of that had been my problem, it would have given me nightmares at the very least, and probably driven me mad. But since that wasn't the case, I just enjoyed the nostalgic and quirky setup. Not something I got to see every day, that's for sure.
Homeboy's also got an NVRAM checksum error. I bet that clock chip battery is as dead as a doornail.