Slashdot Mirror
Linux 5.1 Continues The Years-Long Effort Preparing For Year 2038 (phoronix.com)
Linux 5.1 continues the massive undertaking in preparing the kernel for the Year 2038 problem. Phoronix: The Linux kernel has been seeing "Y2038" work for years and the effort is far from over. Thomas Gleixner (a Linux kernel developer who serves as a member of the technical advisory board at The Linux Foundation) sent in the latest Y2038 work for the Linux 5.1 kernel, which after a lot of ground work in previous kernels has introduced the first set of syscalls that are Year 2038 safe.
We know from y2k that systems have a long lifetime. Software needs to be fixed well before 2038 to ensure that they work then, especially with Linux in so many embedded systems that make much more use of time data.
Good on them.
I wonder if Linux will survive to this date even without this problem.
only 12 years left... not that I'm counting...
Maybe this is an opportunity for computer science students who want to learn more about the Linux kernel see see its inner workings.
-typedef time_t int
+typedef time_t long
There. Fixed it.
By that time FreeBSD will be running launchd, which is basically the same thing.
Ya know, I think you can survive with the timestamp on your CCTV feed having the wrong year.
The Y2K bug hit well before the year 2000.
Back in 1990 the company I worked for had a problem when a 10 year contract with scheduled payments was entered into the system in 1990. All the programmers in the company spent weeks working through source code searching for places where dates were stored with a 2 digit year. I assume the Y2038 bug has already hit systems where future dates are used,
Many who are have been hired the last 20 years will be going on pension well after 2038 ... you need to store the date in something - many have resulted in storing dates in strings, which is less than perfect.
Well we need to come in Saturday and Sunday to keep up + WE need to talk about your TPS reports!
You're tardy, fella. I began using the ISO8601 - or "Asian" - date format way back in the (Nineteen) Eighties, likely before it was even an ISO standard. It's OBVIOUSLY the only way to store and represent dates in a fashion useful for non-human computing. Frankly, humans themselves would do well to adapt their squishy CPUs to internally represent dates in that fashion. That is still a work in progress for me, largely due to the ongoing external bombardment of non-ISO8601 insanity.
It was almost 4 years from 4.0 to 5.0, and we're 19 years from 2038, so that puts us at somewhere around 10.0, not 23.1. Of course Linus may completely change the number system by then, so it's impossible to predict.
Ya know, I think you can survive with the timestamp on your CCTV feed having the wrong year.
I will, but won't somebody please think of the NSA?
Live today, because you never know what tomorrow brings
19 years to rebuild Linux from Scratch
netbsd and OpenBSD made time_t 64 bit even on 32 bit architectures. FreeBSD is a bit lamer and didn't do that for 32 bit x86.
Pathetic.
Back in my day, we waited 1997 and then worked excessive hours in a panic for three years. If it was good enough for us, it should be good enough for you.
I actually had a 100% genuine post-Y2K bug that I needed to fix. I was one of the main people in charge of source control (which was SCCS) in our company at the time. On 2nd Jan my on-call cell phone rang (while I was watching Sleepy Hollow in a movie theatre - oops!) A few rather keen developers were working, despite it being a holiday, and were getting weird stuff happening in SCCS. It turned out that the server they were using had SCCS via someone just copying over the binaries, rather than correctly installing them, so when it got its Y2K-compliant OS upgrade, those binaries were not replaced, and were not Y2K-compliant. I was able to diagnose the problem, patch the dozen or so source code commits which they'd made with the bad binaries, and call in a sysop to install the correct binaries. (I didn't have root on that server.)
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Routers, TVs, video recorders, CCTVs, and more will be non-functional in 2038. And there is nothing we can do to stop it.
We can't stop todays or yesterdays products from having problems in 2038.
But the sooner this is fixed in the main-line the sooner it will reach the production lines the less effected equipment there will be still in use in 2038.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
If your CCTV relies on NTP (Internet time protocol) then NTP rolls-over in 2036 and this is called the Y2036 issue. Then Y2038 hits on top of Y2036. Good luck with getting the correct date after that.
It won't have been written by Lennart Poettering. And that's a good thing.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
If you're lucky they all get replaced by then or die from hardware failure. Or you could maintain an offset date by subtracting 50 years and paying attention every Feb 29/Mar 1. Or maybe you can throw Linux onto them!
It's not exactly a new problem. I have some old TRS-80 stuff where TRSDOS/LDOS stored the date year as a 3-bit number plus 1980.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }