Linux is Ready for the End of Time (zdnet.com) 100
January 19, 2038 is for Linux what Y2K was for mainframe and PC computers in 2000, reports ZDNet. It's the day that the value for time "runs out of numbers" and, in the case of 32-bit Unix-based operating systems like Linux and older versions of macOS, "starts counting time with negative numbers..."
"But the fixes are underway to make sure all goes well when that fatal time rolls around." nickwinlund77 shared their report: Linux developers have seen this coming for decades. So, Linux kernel developer Arnd Bergmann and others have been working on a repair. These corrections are now in the forthcoming Linux 5.6 kernel. Bergmann explained, "Linux-5.6, or my backport of the patches to 5.4, should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038."
There are some caveats:
- All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from Linux-5.6 or higher.
- Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in Linux-5.1 in place of the existing system calls.
- Applications that use a private copy of kernel uapi header files or their contents may need to update to the Linux-5.6 version.
- A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times...
After we fix this, we won't have to worry about 64-bit Linux running out of seconds until 15:30:08 GMT Sunday, December 4, 29,227,702,659. Personally, I'm not going to worry about that one.
"But the fixes are underway to make sure all goes well when that fatal time rolls around." nickwinlund77 shared their report: Linux developers have seen this coming for decades. So, Linux kernel developer Arnd Bergmann and others have been working on a repair. These corrections are now in the forthcoming Linux 5.6 kernel. Bergmann explained, "Linux-5.6, or my backport of the patches to 5.4, should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038."
There are some caveats:
- All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from Linux-5.6 or higher.
- Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in Linux-5.1 in place of the existing system calls.
- Applications that use a private copy of kernel uapi header files or their contents may need to update to the Linux-5.6 version.
- A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times...
After we fix this, we won't have to worry about 64-bit Linux running out of seconds until 15:30:08 GMT Sunday, December 4, 29,227,702,659. Personally, I'm not going to worry about that one.
Meanwhiole in the year 29,227,702,659 (Score:2)
You hear frantic screams of panic.
"How are we going to fix this?!"
Re:Meanwhiole in the year 29,227,702,659 (Score:5, Informative)
Re: Meanwhiole in the year 29,227,702,659 (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I have to admit: In interstellar communications, this can be a problem. We won't be able to use TCP/IP for communications going farther than maybe a Cephei.
Clearly UDP is the solution
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That's 6 times as far in the future as the sun will last. Guess it's ok to call this being ready for the end of time
Yes. I, too, do not expect manned interstellar space travel to ever be a reality at this rate.
Re: (Score:2)
If Linux code still is around at that time then it may be that nobody will understand the code because they aren't homo sapiens. And it would be a "surprise m*f-er" moment.
Re:Meanwhiole in the year 29,227,702,659 (Score:5, Funny)
The sun would have died 24 billion years earlier evaporating the inner planets so there'll be no earth for anyone or thing to be around on.
However, it might just be the Year of Linux on the Desktop! ;)
Re: (Score:2)
Unless we have sent out probes that someone else have re-purposed. Or humans have found a way to spread themselves and their pets over the universe.
Re: (Score:1)
Or humans have found a way to spread themselves and their pets over the universe.
By then Humans will have reached the peak of their existence, by having become pets to the cat people of the planet Stoxx, who watch us playing with our computers as we watch our cats playing with strings.
Re: (Score:2)
The sun would have died 24 billion years earlier evaporating the inner planets so there'll be no earth for anyone or thing to be around on.
However, it might just be the Year of Linux on the Desktop! ;)
And somewhere in the distance a space probe with 64bit time which was adopted by an intelligent race of computer beings who declared the probe its supreme leader enters an intergalactic war with far flung earthling colonies due to the supreme leader's death.
You have to think these things through.
Re:Meanwhiole in the year 29,227,702,659 (Score:5, Informative)
It reminds me Vernor Vinge's Deepness in the Sky. There's a job there called "Programmer Archaeologist" because everything is just piled layers and layers deep and digging to the bottom, the Unix timer is still there, ticking away tens of thousands of years later.
Re: (Score:3)
And they had emulators/VMs nested into each other. I have to look where I placed that book, it is actually quite good.
hahaha, not ready (Score:4, Informative)
No, the 32 bit Linux, 32 bit compat and a ton of popular applications aren't ready. Even if you're on 64 bit Linux many of the popular apps still aren't, like MySQL.
It's gonna be a mess for years.
Re: (Score:3)
No, the 32 bit Linux, 32 bit compat and a ton of popular applications aren't ready. Even if you're on 64 bit Linux many of the popular apps still aren't, like MySQL.
It's gonna be a mess for years.
Well there are still 18 years or so to fix this. I'm sure Oracle has "top people" on it... /s
The problem is there are many decades of applications and libraries that all need to be re-written.
Re: (Score:2)
Re: (Score:2)
Yea, I've ran into several "mission critical" web portals that run only on IE 6 and a specific Java 1.6.0_X version (looking at you, Cisco). I 'loved' the scenario where a second "mission critical" web portal came into play that required a specific, different 1.6.0 version than the other one. *Hides in a dark room and screams*
Re: (Score:1)
Re:hahaha, not ready (Score:4, Insightful)
The summary makes it sound like it's mostly just a re-compile but that's far from it in practice. I bet a lot of code assumes time_t is 32 bit and breaks when it isn't, e.g. because it's stored in a binary file somewhere or shoved in a packet that only allocated 32 bits to it. Or worse the packet buffer is overlaid with a struct containing time_t and now half of it doesn't line up, or compatibility with older versions is broken.
What other operating systems suffer from this? To their credit Microsoft fixed this decades ago but I don't know about MacOS.
Re: hahaha, not ready (Score:2)
MacOS has _just_ jumped to 64-bit only in userland. No more 32-bit compatibility. So I would guess they fixed it at the OS level while back.
Re: (Score:2)
Looks like it was fixed in Leopard: https://apple.stackexchange.co... [stackexchange.com]
Interesting that Apple apparently lied about it around the year 2000.
Anyway, that doesn't tell us the size of time_t and I couldn't immediately find the header file. There are pros and cons to changing it, on the plus side it fixes this issue but on the negative side it can break a lot of stuff like the aforementioned time_t in structs and binary files or passing time_t between 64 and 32 bit apps.
So usually they introduce a new API for the
Re: hahaha, not ready (Score:2)
I think that statement was true for their built-from-scratch Mac OS 9, especially considering all PPC CPUs were 64 bit; but they lost that improvement when they switched to Unix-based OS X and the inferior x86 architecture.
Re: (Score:1)
I think that statement was true for their built-from-scratch Mac OS 9, especially considering all PPC CPUs were 64 bit; but they lost that improvement when they switched to Unix-based OS X and the inferior x86 architecture.
MacOS 9 was not built from scratch.
PowerPC based Macs were 32-bit.
Nothing was lost moving to x86 except having to make the choice "Mac or PC?". The move allowed us to have one machine running either Mac OS X or MS Windows natively, boot to whichever one you needed at startup.
Re: (Score:2)
Though PowerPC had many advantages, moving to x86 was one of Apple's best moves for PCs. It came down to interoperability. The ability to use software and hardware that was designed for the much larger x86 market. I even had ran into hard drives, that should have been compatible, that didn't work on the PowerPCs because the firmware assumed a x86 architecture. If they were still on PowerPC (unlikely as IBM was lagging on updating the CPUs as they had lost interest in the architecture), Macs would not ha
Move to Intel and *nix ... (Score:1)
Though PowerPC had many advantages, moving to x86 was one of Apple's best moves for PCs. It came down to interoperability. The ability to use software and hardware that was designed for the much larger x86 market.
As someone who has ported many a Windows program to MacOS and MacOS X just having the same endianness eliminates quite a bit of the effort. I looked at some cross-platform code I did in the 1990s for a master's thesis. Lots of #ifdefs for byte swapping, threading and synchronization; the code ran under Win32, Linux/BSD and MacOS. The move to Intel takes care of byte swapping, the move to a *nix based environment combined with modern C++ compilers (which support threading and synchronization and calls win32
Re: hahaha, not ready (Score:2)
Apple have been warning Users and Devs about the cessation of 32 bit support for THREE major OS revs. now.
They cannot say they havenâ(TM)t had plenty of time to avoid this being an issue; but people are lazy.
Re: (Score:2)
Wrong, Microsoft did NOT "fix this decades ago." where did you get that nonsensical idea?
32 bit windows and 32 bit windows applications have the 2038 bug. Also, if your windows app for recent version of Windows happened to be built with Studio 7 or before you're fucked.
Re:hahaha, not ready (Score:5, Informative)
32 bit Windows apps that use the standard library time_t are affected but that's not the normal way you handle time on Windows. It's only really there for POSIX.
Windows system time and file times are both good for tens of thousands of years yet. I believe that the 64 bit file timestamps were brought in with FAT32, way back when, and Win32 was using the same from the start for time APIs. So at least since 1995.
Re: (Score:2)
Yep, most win32 functions would use the FILETIME struct which is just two DWRODs, or something that can be converted to/from it:
Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC).
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME, *PFILETIME, *LPFILETIME;
So even though it's in 100 ns since 1601, I think that would still give us enough time to work something out.
Re: (Score:2)
I am not sure many people use that struct. Even Microsoft's own Excel doesn't use it consistently. Some date formulas starting from 1601 and even then it's not consistent because depending on the formula if it was present in older versions of Excel the epoch starts January 1, 1900 (or 1904) in a 32-bit integer. and Microsoft's own .NET calls starts the epoch at January 1, 1 AD and the older Win16-based calls like DDE have epochs in 1980 which is broken up into 16-bit packets representing mmddyy and add-on
Re: (Score:2)
Re: (Score:2)
Yes, that's if your whole program is sanely programmed and doesn't need to interact with any Microsoft software, which is the only reason you're writing for Windows anyway. The system libraries are rarely called in my experience, most interact with some other software or the .NET or VB or OLE libraries which for historical reasons everybody does something different.
Re: (Score:2)
32 bit windows and 32 bit windows applications have the 2038 bug. Also, if your windows app for recent version of Windows happened to be built with Studio 7 or before you're fucked.
With Windows the native OS representation uses a different structure than time_t. time_t is something the c library implements as a shim on top of the OS. Whether 32-bit applications have 2038 issues depends on the compiler runtime the application was built with.
Re: (Score:2)
The summary makes it sound like it's mostly just a re-compile but that's far from it in practice.
In my experience it has been mostly just a re-compile.
I bet a lot of code assumes time_t is 32 bit and breaks when it isn't, e.g. because it's stored in a binary file somewhere or shoved in a packet that only allocated 32 bits to it.
32-bits is sufficient for up to 2106. The way to deal with legacy wire formats is to treat the 32-bit field as unsigned and move on.
Or worse the packet buffer is overlaid with a struct containing time_t and now half of it doesn't line up, or compatibility with older versions is broken.
Good, anyone who designs protocols like this deserve everything they get.
What other operating systems suffer from this? To their credit Microsoft fixed this decades ago but I don't know about MacOS.
What Microsoft fixed was compiler/runtime.
Re: (Score:2)
Re: (Score:2)
I don't know of any... Basically you have to look at every instance where time_t is used and think through the ramifications of it being 64 bit. Storage space, overflows, conversions to other types etc. And then carefully test it of course.
It's one of the reasons why Y2K was such a big pay-day for developers who could fix it. It's not trivial in many cases.
Re: (Score:2)
Any real-world facing sub-system to the kernel can have Y2038 issues independently of whether the kernel is 32-bit or 64-bit. This includes protocols that are defined internationally such as NTP (Internet Network Time Protocol) and filesystems such as cpio that are not Y2038 compliant.
Recompilation is necessary to update 32-bit userland programs to use the Y2038 compliant glibc and other libraries on a 32-bit or 64-bit Y2038 compliant kernel.
In other words, the core of your operating system needs to be Y203
Re: (Score:2)
The problem is there are many decades of applications and libraries that all need to be re-written.
You don't have to rewrite anything, except perhaps a formatting and a parsing function. The rest is changing a typedef, and thats it. Basically a recompile.
Re: (Score:2)
Re: (Score:2)
It is not that simple to just recompile as computers need to communicate with each other with standardised protocols for inter-operability reasons. If the protocol itself is not Y2038 compliant then no amount of recompilation will help. The only solution is to replace the protocol with a Y2038 compliant variant of the protocol eg. release a new specification of the protocol.
Re: (Score:2)
If you say 18 years, then you will be too late. Sounds like a typical out by 1 error to me. There are only 17 whole years to go.
Re: (Score:2)
Monty is probably already on it for MariaDB.
Re: (Score:2)
Still 32 bit there though in MariaDB for TIMESTAMP as it is in MySQL
Re: (Score:2)
On the other hand, the end of times is ready for Linux on the desktop.
Re: (Score:2)
Even if you're on 64 bit Linux many of the popular apps still aren't, like MySQL.
Meanwhile, Postgres has been ready since before Y2K!
Re: hahaha, not ready (Score:2)
Iâ(TM)m pretty sure that was one of the biggest reasons why Apple just ripped off the bandage for their OSes (ended all 32 bit support), instead of this Kludgy, Half-Solution.
Re: (Score:2)
Re: (Score:2)
And "a mess for years"? I'm not sure how that qualifies as a mess. This won't hit for 18 years, and until then it doesn't really have any consequence if someone wants 10 years to patch their app.
Re: (Score:2)
Not just apps, Linux the operating system is not ready. There is much more above the kernel in any distro that makes a linux distribution, and it is not ready.
If you don't know why there is a huge mess, you don't understand the problem. Businesses and many science users already project dates into the future for projects, that's broken and causes problems long before 2038 arrives (actuaries and similar have already been fucked by it many times for over a decade). Business databases, apps and filesystems
Seems like early notice (Score:3)
Y2K wasn't really discussed until the 1990s, and everything critical got fixed in time. Seems like this post needs to go into the "time file" and pulled out in Y2K+28...
Re: (Score:2)
Some people I work with ran into a Y2K18 problem. They used signed 32-but integers to hold timestamps from software that counted from 1950 (due to VMS heritage). That system typically uses doubles or double doubles to hold timestamps, so they really should have known better. They didn't.
Re: (Score:2)
Some people I work with ran into a Y2K18 problem. They used signed 32-but integers to hold timestamps from software that counted from 1950 (due to VMS heritage). That system typically uses doubles or double doubles to hold timestamps, so they really should have known better. They didn't.
The VMS base date is November 17, 1858.
Re: (Score:1)
Y2K+28
How the hell is "Y2K+28" easier to type or say or read than "2028"? WTF.
Re: (Score:2)
Y2K+28
How the hell is "Y2K+28" easier to type or say or read than "2028"? WTF.
"Y2K+28" provides a context that "2028" does not, ie a calendar based computer bug. That a lot of context with only 2 more characters.
Re: (Score:2)
--
.nosig
Man why can't people fix things properly (Score:4, Insightful)
instead of just kicking the can down the road.
Re: (Score:2)
Do you expect to be alive when the 64 bit time runs out?
Re:Man why can't people fix things properly (Score:5, Funny)
Re: Man why can't people fix things properly (Score:2)
Re: (Score:2)
Who cares? The Oort Cloud awaits!
Re: (Score:1)
Do you expect Earth to be alive when 64-bit time runs out?
Irrelevant. The real question is do you expect your consciousness to still be running when 64-bit time runs out. ;-)
Re: (Score:3)
Re: (Score:2)
More alive than your sense of humour ;-)
Re: (Score:2)
My sense of humor was corrupted by Monty Python.
Re: (Score:2)
Kicking the can down the road is fun! Have you ever tried it?
Re: Man why can't people fix things properly (Score:2)
Yes and it was not fun at all. Later someone told me I had to empty it first. But why risk it with my last good leg?
Because we don't have infinite resources (Score:3)
Engineering is about making design decisions which accomplish a desired task with limited resources. In the Y2K and Unix 32-bit time cases, the designer
Re: (Score:3)
Oh good god I didn't think anyone would take my post seriously.
Re: (Score:2)
Man why can't people fix things properly
I agree with you completely!
Will you please purchase the trillions of exabyte memory modules for me for all of my properly sized variable structures?
I'm so happy to hear you are paying for all of this, I would never be able to afford that on my own and would have to "make due" with the incorrectly fixed 64 bits of storage everywhere I want to store the date.
Just tell the delivery company to leave it out back unless it's raining. Thanks!
Re: (Score:2)
Be happy to! But right now since it seems we kicked the can down the road we have a bit of time. But we shouldn't wait. Go purchase the hardware. I'll pay when the problem is solved. Payment terms are net 4/12/29227702659
Developers will be lazy (Score:2)
Why only now? (Score:2)
Its not like no one knew this date was coming. Was there some kind of expectation in the linux community that 32 bit would have gone the way of T Rex by now or was it just inertia?
Re: (Score:2)
Linux implemented POSIX, which specifies time_t is a 32 bit integer.
So the blame seems to go back to 1988 or so, if you blame the POSIX committee, or before that because it was a 32 bit int even before then.
As to why Linux didn't do differently, probably because people wanted software written for other unixes to work on it, and was a 100% hobby project at the beginning, which nobody probably expected to be this big today.
Re: (Score:2)
Re: (Score:1)
Why did anyone choose to have "system time" be a signed value?
If you want to work with time - at the non system level - use something like - Excel.....
Re: (Score:3)
So that the same typedef could be used to represent time differences, and so the compiler won't yell at you when you subtract one time value from another.
Re: (Score:2)
Well kiddo, you also had to walk to the store to make a phone call if you weren't at home in those days.
"You'll have to fix this within 30 years" was never perceived as "the way of the `T Rex'" it was merely "the future." As in, now. As in, fixing it now was planned for in the past. And they were right, most computers switched to 64 bit and never had to be fixed, it would have been a wasted effort to worry about it back then.
Re: (Score:2)
I don't know about you "kiddo", but we had these things called payphones where I lived, no walking into anywhere to make a call.
Re: (Score:2)
Look kid, did you fancy yourself older than adverbs? Look up "to."
Re: (Score:2)
When you can turn that sentence into something that actually makes sense get back to me. Perhaps go outside and rock in your chair for a while to clear your head.
Re: (Score:2)
LOL ok Ivan, when you learn yous some Angles you can give it another go.
Re: (Score:2)
Oh right, I'm a russian troll now am I? I'd suggest staying off the sauce mate, you're sounding like a grade A clown.
Re: (Score:2)
Learn yous some Angles first.
I'm Not Too Worried About Linux (Score:4, Interesting)
Honestly, I don't even expect there to be more than a handful of those, but I think there will be a few companies, and I'm kinda curious if we'll actually even hear about any of them.
Linux is not ready... (Score:2)
December 4, 29,227,702,659 (Score:1, Funny)
Sure...and 640K ought to be enough for anybody.
So they moved it to my birthday (Score:2)
Thanks for the (future) present. ;)
Please fix this (Score:2)
I have a rendez-vous at 03:14:08 UTC on 19 January 2038.
Bad Math? (Score:2)
Question ..
2^64 = 18,446,744,073,709,551,616 seconds
signed = 9,223,372,036,854,775,808 seconds
= 292,271,023,045 years, 114 days, 9 hours, 30 minutes, 40 seconds (year ~365.25 days)
+ epoch = April 24, 292,271,025,015 @ 9:30:40
The article mentions year 29,227,702,659 but appears this is off by about a factor of 10? Granted, ultimately doesn't matter but am I missing something?
Re: (Score:2)
The real question is:
Does the new time_t use milli seconds or nanoseconds?
And on top of that, is it still called time_t or got a new name? E.g. time_t64?
use CLOCK_BOOTTIME, not CLOCK_MONOTONIC (Score:2)
- A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times...
Better to use CLOCK_BOOTTIME. CLOCK_MONOTONIC doesn't count while the computer is asleep.
obHHGTTG (Score:2)
I am sure Milliways will update their POS systems
For Embedded Systems (Score:1)
This is a Unix-like problem. NetBSD and OpenBSD released their fixes in 2012 and 2014 respectively, Linux has been slower but has still allowed 18 years, which is plenty of time.
It won't affect Linux computers, where hardware and software turns over fairly quickly, cycles before 2038. Linux software is also updated fairly regularly, or becomes orphaned and is replaced by something new. It will affect Linux legacy software but there probably isn't going to be lot of that affected by 2038. The main reason f
Really? (Score:1)
Check out /usr/include/time.h. Seems to me this was fixed all the way back to at least 2005 when I fired up a var and it turned out to be a long.
Should have been fixed when they came out with 64 bit kernels.