said by Velnias:You musta kidding... why just solve problems when one can invent new ways to do things that even Poettering barely grasps how it works... and yes, he deserves to be remembered forever...
Wow - I don't know where to go with that.
First, Poettering certainly did not 'invent' anything, and in fact was not even close to being the first creator of an 'init' replacement.
Second, I think systemd is a good example of exactly
why it is not a good idea to blindly plow forward at full speed without understanding what one is doing.
Those are getting off topic however so I won't go further.
The problem is far greater than just a simple user-land process, and failing to recognize that is a failure before even getting out of the gate.
The problem is not unique to Linux, or even Linux/Unix on a larger scale. There are many embedded devices that similarly use only a 32-bit counter for time and even if their 'second 0' representation is different than traditional *nix, they too will still have problems only at a different date.
Moving to *nix specifically, there are several layers of issue. The first is the internal kernel representation of time. That one's actually relatively easy to fix. The next are the kernel calls for setting and retrieving time. Those are a little more challenging, particularly if ABIs are to be maintained. These are still doable with some planning. Then there are the OS libraries and related data structures - this is where the OSs face the biggest challenge and unfortunately there is too much bickering going on in the linux space regarding the proper path forward for this to move quickly
The next step from there would be applications themselves. Many will not be affected, and others may have workarounds to allow legacy binaries to continue to function if they actually still exist. Then there will be others that completely fail with no option other than to replace the application. Note that "application" here includes services such as storage and databases as well as networking (higher levels of the stack).
Going the other way: Most hardware with an embedded RTC currently leverages an implementation that uses 32-bit counters either internally or just in their interfaces. Similarly such hardware itself typically uses only single 32-bit counters for time representation.
Now the biggest concern: While 2038 may be a little over two decades away, it could start to be a problem in less than a year. Financial applications dealing with projections and forecasts are already well aware of this as they have been dealing with dates beyond 2038 for over a decade already. Other applications, unfortunately, have not even thought of this yet and for those that do work with future dates this could result in sudden failures very soon. One could point out that proper testing would have (or will soon) identify this before it caused a problem we all know reality can be a bitch. (Does anyone remember the AOL snafu a decade or so ago? It was directly related to this problem)
Briefly back to the application side, specifically related to time synchronization: It is well recognized that the current reference implementation (ntp.org NTPd) will fail in 2038. However funding is practically non-existent for any project, and egos have been taking a front seat rather than any form of community collaboration that will be required here. There is sadly plenty of "entertainment" (if you will) that may be easily found on this with some simple searching, including some strong-willed opinions about plowing forward full speed without really having any understanding. . . .
