俗话说：“尽早打补丁，频繁打补丁”——在 Debian 针对一种潜在严重问题的修复中，提前了将近 13 年。这个问题涉及类 Unix 系统中时间的表示方式。

定于 8 月 9 日发布的 Debian 13 “Trixie”，通过将操作系统中除最旧硬件外的时间存储方式全面转向 64 位变量，从而减轻了被称为“Unix 末日”（Unix Epochalypse）的 Y2K38 问题的影响。

“Unix 末日”是对一个潜在严重问题的幽默称呼，如果厂商和用户不及时更新系统，它可能会带来严重后果。

就像早期的“千年虫（Y2K）”一样，这也是软件处理日期方式的问题——只不过这次是 Linux 和 Unix 系统。

“千年虫”其实与其说是漏洞，不如说是一种“功能”：当时是为了节省宝贵而昂贵的内存空间。系统记录日期时只保留年份的后两位，假设“70”代表的是 1970 年。但随着千禧年的临近，这种做法引发了歧义：“01/01/01”究竟指的是不久将来的某个日期，还是指近一个世纪以前的事件？

如果不是 IT 人员夜以继日地修复软件并更新系统，使年份以四位数存储、从而缓解数据中的歧义，“千年虫”问题本可能酿成灾难性的后果。

Y2K38 问题带来了类似的风险。Unix（和 Linux）系统的时钟以自 1970 年 1 月 1 日起经过的“秒数”来计时，这一天被称为 Unix 时间戳（Unix Epoch）。而一些系统将这个数字存储在有符号的 32 位整数中——这个整数将在（请做好心理准备）2038 年 1 月 19 日的世界标准时间 03:14:07 溢出。

一旦发生溢出，系统时钟将倒退回 1901 年 12 月。

“时间危机”现在就要来了？

事实上，这场混乱已经真实存在，并影响到一些系统，比如养老金基金预测等需要面向 2038 年之后未来时间的应用。

当然，这场混乱不会影响现代的 64 位系统——它们使用 64 位变量存储日期，可以支持超过 2920 亿年的时间跨度。但旧有系统和嵌入式设备就面临风险，这正是 Debian 和其他发行版着手修复的原因。从工厂控制系统、楼宇监控系统到路由器和安防摄像头，各类设备都运行着某种嵌入式操作系统，其中很多都是 32 位 Linux。这些系统常常运行数十年而不会被更换，因此软件层面的修复成为必要之举。这再次说明，如果在设计时忽视软硬件的“寿命问题”，最终会反噬我们自身。

解决方法：将日期存储方式改为 64 位变量。对 Debian 的维护者来说，这是项浩大的工程，涉及 近 6,500 个软件包，而且必须一次性完成，因为还涉及应用二进制接口（ABI）的变更。但 Debian 表示这项工作已经完成，或者说，至少完成到了目前为止能做到的程度。为了保持与 x86 二进制的兼容性，在 i386 系统上仍保留 32 位时间格式，但也在考虑如果有足够需求，未来是否在这些系统上也支持 64 位时间。

你可能觉得这个时间溢出问题还很遥远，但 Debian 在关于此问题的公告中指出：

“到 2025 年，这距离 2038 年已经不到 13 年，而许多可能受影响的系统早已出厂。我们应该停止制造更多问题。大多数计算任务，特别是使用 Debian 或其衍生系统的计算，现已在 64 位硬件上完成，在这些系统中不存在这个问题。然而，仍有大量对成本敏感的 32 位计算存在于市场中，并持续用于新设备中（比如汽车、物联网、电视、路由器、工厂控制、楼宇管理/控制、廉价安卓手机等），其中一些硬件很可能运行的是 Debian 或其衍生系统。”

这点尤其关键，因为其他很多 Linux 发行版（如 RedHat 和 Fedora）已经停止对 32 位的支持，SUSE 的 32 位支持也只是非官方的，留下了 Debian 生态系统在承担大部分 32 位维护负担。

公告还指出：

“目前仍在出货的大多数新 32 位硬件，运行的是类似 OpenEmbedded、Alpine、Android 或 Gentoo 这类‘源码构建操作系统’，但基于 Debian 的细分市场可能还会继续存在若干年。而使用这些系统构建的一些设备，很可能会使用和部署得足够久，以至于最终运行到 2038 年 1 月。”

通往未来的桥梁

Info-Tech Research Group 的数字基础设施实践负责人 John Annand 指出，这个问题就像当年的 Y2K 一样，反映了整个行业存在的一个根本性问题，亟需被正视。

他说：“物联网和嵌入式操作系统的问题，其实是计算机/软件工程与土木工程之间本质差异的症状表现。”

“在监管机构强制推行类似桥梁和建筑那样的安全性与可持续性标准之前，软件行业始终会更偏向创新的便利性与部署的速度。”