> It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel.
I routinely encounter systems running 15-20 year old kernels. Given that, NOW is the time to fix the 2038 problem.
I routinely encounter systems running 15-20 year old kernels. Given that, NOW is the time to fix the 2038 problem.
Also, 20 years ago was before the Linux 2.4 kernel. You encounter systems running Linux 2.2 routinely?!
Software projects don't develop linearly. 20 years ago the Linux kernel was 8 years old, today it's 28 years old. The motivation to upgrade the relatively mature 2020 kernel will be much less than that to upgrade the immature 2000 kernel.
And perhaps the biggest one - computers have changed. 20 years ago a PC that could run Linux was a big power hungry thing. Today it's the size of a box of matches. Embedded Linux PCs with limited upgrade paths are everywhere today.
When I worked on satellites (stopped in 2015) we'd routinely use electronic test equipment which was running an embedded version of Windows 98. Given that the stuff shipping today is even further down the maturity curve, I think it's almost certain that it'll be used in 20 years (if it still works).
Yah the time on the thermostat will be wrong, but if no one has upgraded it in that long, its probably ok, put a piece of tape over it.