The Linux Kernel Is Still Rectifying The Year 2038 Problem

[SystemCrasher]

even if RT was fully merged. it would still be a kconfig option. I don't think mainline ever plans on using certain bits.

Mainline does not really defines which features to enable. Sure, there is defconfig, including x86 builds, but most of time defconfig is not what you want, so most distros are using their own kernel configs anyway. So it is up to them to enable or disable particular features as they see it fits. Those who think they know it better, tend to configure their kernels themselves, for one reason or another. This said, e.g. ubuntu supplies high-latency kernel by default and even their "low latency" kernel leaves a lot to be desired. So one could readily stumble on major latency spikes ("lags") when their system does heavy IO, etc. That's kinda opposite of real time. It wins several percents in benchmarks, but at what cost? The cost is laggy system.

But still, these RT patches are only useful for those who knows what they are doing. They are going to have it hard either way, facing countless obstacles. PC hardware alone is quote hostile to realtime.

[jacob]

64 Bits will get us to the year 292,471,208,630.

Damn! RHEL6 will just have finished booting.

[gamerk2]

Definitely something that needs to be addressed, but it's not like the panic a lot of people got into in 1999...



My understanding is that this is exactly what they did to find Y2K bugs in software. However the main difference between Y2K and the 2038 problem is that the Y2K problem was an issue for applications and not the underlying OSs while the 2038 problem is exactly the other way around. In other words you just need to fix the OS and you're fine and don't have to go for the massive application bug hunting that took place with the Y2K problem.

The main issue with Y2K was shortcuts taken by applications. As an example, a lot of our companies MS Access databases (Don't laugh; it was the early 90's after all) used two digits for storing year values in order to save some space. We'd use the year values for indexing purposes. For obvious reasons, at the Y2K rollover, things broke.

The 2038 problem has already started to manifest itself; 30 year mortgage calculations started to break in late 2007. Good thing every firm involved in such transactions moved to 64-bit values years ahead of time so we didn't accidentally cause a housing meltdown and start a world-wide recession...

I kid, but only half jokingly. I just find the timing of the two problems oddly coincidental.

[smitty3268]

Y292B is well over the current age of the universe. And I'm fairly certain we would have shifted to quantum computers by then

Yes, right, but I'll still be alive in my android body and using my 386SX desktop from 1990 because I don't have the money to upgrade it. These things are important to get right.

[RelaxTrolls]

I would love to know when Real Time Linux patches will get merged upstream/vanilla. Please make it happen!

https://wiki.linuxfoundation.org/realtime/start

In reality, the majority of the RT patches have been merged into mainline... the RT patches are much smaller than they used to be... it's also why even mainline works quite good for lots of usecases that it sucked to suck at...

even if RT was fully merged. it would still be a kconfig option. I don't think mainline ever plans on using certain bits.

[strtj]

Oh my goodness, are there really still people using gettimeofday() in the linux kernel? It was practically a deprecated function in the early '90s.

[pal666]

It's integer overflow, how would Rust have helped with that?

no kernel - no problem

[reavertm]

What about bioses etc. That old hw will just have to die before 2038.

[cen1]

Definitely something that needs to be addressed, but it's not like the panic a lot of people got into in 1999...



My understanding is that this is exactly what they did to find Y2K bugs in software. However the main difference between Y2K and the 2038 problem is that the Y2K problem was an issue for applications and not the underlying OSs while the 2038 problem is exactly the other way around. In other words you just need to fix the OS and you're fine and don't have to go for the massive application bug hunting that took place with the Y2K problem.

Hmm, won't the userspace programs need to be fixed also? Like, if you are storing the timestamp in int32 right now that clearly won't work anymore.

[zakhrov]

Just kicking the can down the road. Now we have a Y292B problem.

Clearly the only real solution is to come up with a variable length date structure.

Y292B is well over the current age of the universe. And I'm fairly certain we would have shifted to quantum computers by then