The Linux Kernel Is Still Getting Ready For The Year 2038

[phoronix]

Phoronix: The Linux Kernel Is Still Getting Ready For The Year 2038

In the past number of years have been a lot of changes in prepping the kernel for Year 2038, but that work still isn't over and with the in-development Linux 4.20~5.0 kernel are yet more time keeping changes for prepping for this Y2K-like event...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.20-Prepping-For-Y2038

[cen1]

Why not just expose the 64bit API and deprecate existing one, then nuke it in let's say 2030? 12 years should be plenty enough to port everything of value. I don't understand why binary compatibility is a thing since any program storing time in 32 bit will not work correctly anyway.

[You-]

Think microcontrollers and other embedded devices that cannot be upgraded very often or ever.

[cj.wijtmans]

Think microcontrollers and other embedded devices that cannot be upgraded very often or ever.

no problem then since the kernel cant be updated anyway.

[brrrrttttt]

Why not just expose the 64bit API and deprecate existing one, then nuke it in let's say 2030? 12 years should be plenty enough to port everything of value. I don't understand why binary compatibility is a thing since any program storing time in 32 bit will not work correctly anyway.

It's not really about user-space APIs. Timestamps are pervasive everywhere, inside the kernel and out, and a great many of them are stored on non-volatile storage as part of something larger.

[cl333r]

Getting ready for Y2038 and nobody gives a crap, all are running amd64 by now, those who aren't it's their own problem.

[wagaf]

We got issues with year 2038 in our software as early as this year.

Certificates where generated as valid for 20 years so their expiration was after the 2038 epoch since January 2018.

This means that, on 32 bit systems, crypto libraries (using time_t internally) would consider the certificate as long expired.

There was no obvious fix except reducing the certificate validity period to 10 years, giving us 10 more years to fully deprecate 32 bits support.

This was mostly an issue on older/low-end 32 bits Android devices since most desktop users are now on 64bits.

[You-]

no problem then since the kernel cant be updated anyway.

That is kind of the point. ANy such hardware using the kernel deployed today might struggle in 2038. Deep sea quipment, any space probes are obvious candidates but I am sure there are other more mundane things that are expected to survive a long time. (I hope things like pacemakers dont need such a complicated OS...)

[oiaohm]

Why not just expose the 64bit API and deprecate existing one, then nuke it in let's say 2030? 12 years should be plenty enough to port everything of value. I don't understand why binary compatibility is a thing since any program storing time in 32 bit will not work correctly anyway.

The bad news is its not that straight forwards. File systems and Database storing 32 bit time values come to mind.

Getting ready for Y2038 and nobody gives a crap, all are running amd64 by now, those who aren't it's their own problem.

Running 64 bit system Y2038 not your problem idea.

https://kernelnewbies.org/y2038/vfs

Time to totally bust that bubble. Just like y2k Y2038 is also a file system problem. In fact the first one is Y2028 for isofs the file system on cdroms.

Thinking it takes about 2 years for a kernel to be deployed the first issue hits with file systems Y2028 we have less than 8 years to in fact agree on offset method.

Yes just like Y2K we have RTC problem in some hardware as well made worse by some of those RTC having cannot set date before date of manufacture. Yes you might have a 64 bit cpu but with a 32 bit RTC.

The issues that are left effect 64 bit and 32 bit kernel equally.

https://www.quora.com/Will-the-Year-2038-problem-affect-Windows-since-its-not-based-on-UNIX

32 bit time is also a Windows 32 bit application problem. So those running wine to run old programs on Linux hello problem.

32 bit time if people don't audit the applications they depend on Y2038 could be quite a bit of problem.

[Weasel]

Why not just expose the 64bit API and deprecate existing one, then nuke it in let's say 2030? 12 years should be plenty enough to port everything of value. I don't understand why binary compatibility is a thing since any program storing time in 32 bit will not work correctly anyway.

You don't understand because you lack something up there. Along with stability and performance, backwards compatibility is part of the trio that make up the most important functions on a proper system.

"Not work correctly" is a big claim. Most apps don't give a shit about correct dates. Note that delta times (i.e. difference between X and Y dates) will still be correct, unless the difference is larger than 68 years.