linux的2038年的严重问题
2038年一月19号，星期二，凌晨3点14分7秒钟的时候，在这一秒钟滑过后，凡是安装着linux的32位机都会死机或者陷入死循环。当然，对于PC领域，那时候估计所有的电脑都进入了64位时代了，但是，在嵌入式领域，二十几年的时间并不长，那时候还会有很多的设备运行在32位机上。目前，在嵌入式领域，linux可是独霸天下，但这个2038年就是linux的"阿喀琉斯之踵"。很多工业控制领域的产品、军工领域的产品，一用就是二三十年，如果接下来的十年linux还没有解决这个2038年的问题的话，那么它将会失去在嵌入式领域的位置，对于在嵌入式领域没有用处的linux还有谁还会去用它呢！
对于这个问题，linux的大神们好像并不怎么在意，我只能呵呵了。奉劝大神们不要舍本求末了。 本帖最后由 amarant 于 2016-01-14 13:25 编辑
编辑了，看来不是一个问题 ipv4 --> ipv6都解决了，呵呵，只是进度慢了点 听起来蛮严重的，，
如果问题修复了，系统升级也是个问题， 本帖最后由 lishengwu 于 2016-01-09 14:30 编辑
不过，据我所了解的，Linus Torvalds不打算解决这个问题。我认为：十年后，如果这个问题还没有解决的话，那么，在32位机的嵌入式领域，大家就千万不要用Linux，不然，问题就大了。 但是大家也不用太过紧张。2038年问题比千年虫（the Millennium bug）问题解决起来相对要容易一些，只要给那些程序换一个新版本的“标准时间库”就可以了，比如说，改用8字节64位的形式来存储时间。这样做并不怎么费事，因为在C程序中“标准时间库”是相对独立的一个部分，里面的时间表达都有自己的一套时间类型和参数（而在碰到Y2K的那些大型主机中，时间格式大都没有一）。
说到这里，一些冰雪聪明的菜鸟DDMM们应该可以联想到，WindowsNT用的是64位操作平台，它的开始时间是1601年1月1日———但是它每过1个纳秒就跳一下，因此，WindowsNT它会碰到的是2184年问题……
而在一些用64位来表示时间的平台上，例如DigitalAlpha、SGI、Sparc等等，想要看到它们的时间出错你得等到天荒地老———那大概是2920亿年。到那时，位于猎户座旋臂的太阳，已经是黑矮星或暗黑物质，猎户座旋臂已经被重力波震断，银河系大概则已经变成小型似星体了。
所以，给那些准备攒机的菜鸟DD一个建议，除非您想要把资料流传给下一个宇宙，一台64位的电脑已经足够。
总之，32位的最后时间是2038年1月19日03:14:07，星期二。
64位的最后时间约2900亿年后的292,277,026,596年12月4日15:30:08，星期日。
看到一篇文档说过这问题，貌似解决方案是基年偏移，到了2038，貌似就从1970+(2038-1970)/2开始算 本帖最后由 lishengwu 于 2016-02-03 11:11 编辑
回复 7# 流氓无产者
不知道这个解决方案在哪里看到的？但是，Linus Torvalds在邮件中也说了，目前还没有对这个问题在内核中做出修改。。。所以，在嵌入式领域，这个目前还是个很大的问题。而且，如果这个问题要拖到很后面解决的话，那么，接下来的几年，很多军工领域和工业控制领域的产品就不能再用linux系统了，因为他们的产品工作起来都是十几二十年。。
流氓无产者，你说的解决方案，那篇文章能共享出来吗？ 本帖最后由 Buddy_Zhang1 于 2016-03-11 16:04 编辑
+U +U +U 回复 8# lishengwu
原文暂时没找到，记得大概是gnu和linuxjournal的一篇文章
刚才搜了一下，大部分方案是升级到64bits
页:
[1]
2