FreeBSD 中 32 位平台支持的未来

主流系统中的 32 位支持现状

• Fedora 一直在系统性地弃用 i686 内核和软件包；许多新软件包甚至已经无法在 i686 上构建。
• Ubuntu 基本已经放弃 32 位，只保留了一小组供 Steam/Wine 使用的库。
• Debian 正在把 32 位迁移到 64 位时间，但警告称 i686 可能很快会被移除。
• FreeBSD 16 将不再支持 32 位平台，但在 64 位内核上仍支持 32 位二进制文件（目前还没有放弃这一点的计划）。
• OpenBSD 早已把 i386 视为低优先级（只修容易/关键的问题）。那里的未来并不明朗。
• NetBSD 被广泛视为 32 位/老旧硬件的长期归宿。

对软件和库的实际影响

• 旧的专有 32 位应用和与 Wine 相关的库仍然是个痛点；移除 32 位库会直接把它们弄坏。
• 一些维护者发现，新软件默认假定 64 位，并且不会修复 32 位构建问题。
• 32 位测试变得越来越困难，因为现代发行版不再提供完整的 32 位栈；人们只好回头使用老旧的虚拟机。

可移植性、UB，以及 C 类型大小之争

• 反复出现的问题：错误假设 long/size_t 的大小，以及把指针强制转换为 long 而不是 uintptr_t。
• 有人认为这只是糟糕的 C，与 32 位还是 64 位无关，应该作为 UB/可移植性 bug 来修复。
• 也有人反驳：为了理论上的平台去修复会带来真实成本，而当前收益很小；许多项目是有意针对主流 64 位 Unix 做优化的。
• 有人支持优先使用 size_t/uint32_t/uint64_t（C99 类型）而不是 int/long，甚至有人提出废弃旧式整数类型的想法。

CPU 架构与启动模式趋势

• Intel 提议的 x86‑S 和更新的 ARM Cortex‑A 设计正在移除 16/32 位启动模式；一些 ARM 核心甚至已经无法运行 32 位应用。
• Apple 很早就移除了 32 位应用支持；当前硬件不支持 32 位 Mac 代码，但 Rosetta 中有一个最小的 32 位功能，供 Wine 等用途使用。
• 有人认为 x86 早就该直接以 long mode 启动；也有人提醒，现实中并不是“所有人”都只需要 64 位。

Wine、time_t 与 Y2038

• Wine 正在转向一种模型：32 位应用调用 64 位库，这可能让发行版删除大部分 32 位库。
• 2038 年问题增加了压力：32 位系统上的 32 位时间是另一项重大的迁移负担；FreeBSD 目前除 i386 外已在所有地方使用 64 位 time_t。

嵌入式与长尾系统

• 有人担心：快速弃用 32 位会伤害嵌入式 Unix 的使用。
• 一种观点：对于严肃的嵌入式工作，RTOS 或裸机更合适；32 位 Unix 既过度又过时，而且廉价的 64 位 SoC（例如 Cortex‑A55 级别）已经广泛可得。
• 反方指出：很多“重型”嵌入式设备（路由器、安全设备、RPi 级开发板）仍在运行 32 位 Linux；32 位 Linux 很可能在那里持续存在很久。
• 有人建议把未来的 32 位 Unix 看作今天的 8/16 位系统：小众、定制化，不应成为通用可移植软件的目标。

BSD 生态中的角色与情绪

• FreeBSD 越来越被视为专注于服务器级 64 位硬件；它在嵌入式方面从来都不算强。
• NetBSD 被看作“老旧硬件”的避风港，也是与 FreeBSD 互补的小众定位。
• OpenBSD 和多架构支持因能暴露不可移植的假设（字节序、对齐、32/64 位）而受到称赞。
• 几位参与者表达了怀旧之情，并在 32 位支持退役时感到自己也老了。