3 ms·
Don't worry everyone will just assume that somebody else is fixing the Unix Rollover in 2038. Competence and stability breeds incompetence and instability. Hop
by kurthr 3y ago
Don't worry everyone will just assume that somebody else is fixing the Unix Rollover in 2038. Competence and stability breeds incompetence and instability.
Hopefully, we're lucky and everything just migrates seamlessly to 64bit, but a Minsky Moment for technical rather than monetary debt would be pretty apropos. Maybe the LLM designed to port everything makes a silly mistake that goes unchecked. Who knows maybe it becomes Skynet.
https://en.wikipedia.org/wiki/Minsky_moment https://en.wikipedia.org/wiki/Minsky_moment
- deleted 3y ago[deleted]
- stephen_g 3y agoDistros are already planning to change time_t to 64 bit for the 32 bit platforms that are still affected. Debian is planing on doing it this year [1]. It's not actually hard to fix the problem, it's just tricky to manage an ABI break without breaking things. Anybody who compiles their whole system (like Yocto based builds or similar for embedded systems) and doesn't use any closed source binaries can do it today. 1. https://wiki.debian.org/ReleaseGoals/64bit-time https://wiki.debian.org/ReleaseGoals/64bit-time
- fanf2 3y agoThe hard part of the 2038 problem is not the ABI changes, but all the higher-level systems and data storage formats that use 32 bit unix time. Such as file systems. Fortunately many of them can be adjusted to treat time as unsigned so they won’t need to break compatibility with old data, but it’s really hard to make a signed -> unsigned change without overlooking corner cases.