投稿/寻求报道 | zhanghy@csdn.net
随着时间推移，32 位软件及系统早已日渐式微。拿国内而言，像小米、OPPO、Vivo 这些主流应用商店，早在三年前就发话了：所有移动『安卓』应用，最迟 2022 年 8 月前必须全面上 64 位。
如今这股淘汰风也刮到了 Linux 世界，连一向更新节奏还算“稳健”的 Fedora 都坐不住了。近日，Fedora 开发人员带来一项最新的提案：想要在未来的 Fedora 44 版本中，全面移除对 i686 架构的支持。简单来说，就是 Fedora 正式跟 32 位说再见，连带着那些为 64 位系统准备的 32 位兼容包（multi-lib）也一起下线。
听起来像是清理历史遗留问题，但这项提议一出，立刻在社区掀起波澜，尤其在游戏圈引发不少担忧。
要知道，目前还有不少老游戏、Steam 应用都还依赖这些 32 位组件。对此，甚至有一款基于 Fedora 打造、专为游戏玩家设计的 Linux 发行版 Bazzite 创始人直言：如果 Fedora 最终真的砍掉 i686 支持，自家的项目可能会被迫停摆，这对他们来说无异于一次“灭顶之灾”。
Fedora 的变革：告别 32 位支持
事实上，Fedora 多年来一直在逐步减少对 32 位的支持。
早在 Fedora 31 中，该发行版就已经停止分发 i686 架构的内核软件包和安装镜像，也不再发布对应的软件仓库。不过，当时为了在 64 位系统上运行 32 位应用（即通过 multilib 机制），i686 软件包的构建工作仍被保留了下来。
后来自 Fedora 37 起，情况又发生了变化：维护者获得了更大的自由度，只要某个 i686 包不再被其他组件依赖（即“叶子包”），就可以选择不再为其构建 32 位版本。这让大家能把精力集中在真正面向用户交付的软件架构上。
现在，Fedora 团队终于准备迈出最后一步，彻底终结对 i686 架构的支持。这一变更提案将分两阶段实施：
第一阶段：不再在 x86_64 仓库中提供 i686 构建的软件包，意味着 multilib 支持将被移除，即不再支持在 64 位系统上运行 32 位程序。
第二阶段：完全停止为 i686 架构构建软件包。
Fedora 维护者表示，这个过程被刻意拆分为两步。第一阶段相对温和，若后续发现问题，仍有回退的可能；但第二阶段几乎不可逆——若要回退，不仅需要重启部分架构支持，还可能牵涉大规模的构建系统调整。
其指出，这项变动对某些软件包影响较大，需要做出相应适配。例如 Wine，将需启用“新 WoW64”模式，以便在纯 64 位环境中继续运行 32 位的 『Windows』 应用。
按照计划，项目维护者透露，第一阶段将尽早在开发周期内实施，最迟也要赶在系统的大规模重建（mass rebuild）之前完成。这一安排旨在提供至少四周的缓冲期，提前暴露并解决潜在问题——确保在进入第二阶段（即 Beta 冻结前）时，不会留下隐患。
一旦变更完成，Fedora 还将提供配套机制，在系统升级过程中自动清除旧有的 i686 软件包，避免残留不再维护的组件，从而降低升级出错的风险。
减轻各方负担的一个决定
取消对 i686 架构的支持，Fedora 维护者直言，这样可以有效减轻软件包维护者、发布工程团队、基础设施和终端用户的负担。
提案中写道：
软件包维护者：构建和维护 i686（以及更广义上的 32 位架构）软件包的工作量正不断增加——而 i686 也是 Fedora 最后一个仍提供部分支持的 32 位架构。
许多上游项目已经明确停止支持 32 位架构的构建或运行，这迫使 Fedora 要么在下游自行恢复对该架构的支持，要么对大量软件包进行打包策略的修改，以适应这些支持的缺失。
而通过彻底放弃对 i686 的支持，Fedora 可以摆脱这部分额外且日益沉重的维护负担。
发布工程：当前将 32 位库纳入 x86_64 仓库的流程依赖于一套脆弱的启发式规则。随着这项变更的实施，这套规则也可以一并移除，从而简化 x86_64 仓库的构建流程。
基础设施：不再为 i686 构建软件包，将释放 x86 架构构建『服务器』的部分资源，这些资源可转用于加速 x86_64 包的构建。
终端用户：从 x86_64 仓库中移除大约 1 万个 32 位软件包后，仓库元数据体积将显著减小，有助于加快元数据下载速度，并提升所有涉及依赖解析的 dnf 操作性能。
目前，这项变更提案已经发布到 Fedora 开发邮件列表，进入公开讨论阶段。这也意味着这件事情暂时并未板上钉钉，仍需由 Fedora 工程与指导委员会（FESCo）投票决定。
仍有不少驻足 32 位的应用
虽然技术的迭代是大势所趋，但这并不意味着变革不会带来影响。随着这一提案在社区流传开后，不少用户尤其是游戏圈的人对其潜在影响表示担忧。
反对声音中，最受关注的来自 Bazzite 发行版的创始人 Kyle Gospodnetich。
Bazzite 是一个基于 Fedora 打造、专为 Linux 游戏优化的操作系统，特别适配 Steam Deck 和其他手持设备。它内置 NVIDIA 专有驱动、支持运行 Android 应用，并提供了类似 SteamOS 的用户界面。
Kyle 对 Fedora 的这一提议表达了严重担忧。他指出，即使有人手动重建必要的软件包，Steam 的某些基础功能依然可能无法正常运行。此外，他还强调，这一变化已经在宣传层面对 Fedora 造成了负面影响：
尽管我非常希望这个变更最终能够落地，但现在还为时过早。如果现在就执行，等于直接扼杀了像 Bazzite 这样的项目—— 正值 Fedora 在游戏领域刚刚取得重大进展的时候。Neal Gompa 已经指出，即使有人手动构建了 Steam 所需的软件包，很多基础用例依然会失效。
此外，这次提案在宣传层面也给 Fedora 带来了不可挽回的伤害。我一整天都在被各种新闻和用户反馈刷屏，很多人都在担心他们的 Fedora 或 Bazzite 系统会因此无法再运行 Steam。
我认为，不仅这项变更应该被否决，甚至连提案本身也应该撤回，以减少其对 Fedora 项目所带来的负面影响。
也许可以另起一个提案，专门探讨是否要减少 32 位架构的构建范围？这样会是更稳妥的推进方式。
在进一步的讨论中，Kyle 甚至表示，如果变革按照计划进行，那么最好的选择就是解散 Bazzite 项目。
与此同时，也有不少网友将矛头指向 Steam 后面的开发商 Valve。一位网友在 Reddit 上发表评论称：“32 位问题（至少部分）要怪 Valve。”
他写道，当前 Fedora 的移除提议之所以引发争议，是因为大家担心这会让游戏“失效”——这确实是合理的担忧，毕竟 Steam 会受到影响。
他解释道：
“其实这个问题大部分早就解决了，而剩下没解决的部分，说白了，是 Valve 的锅。
移除 32 位包/库，不等于完全放弃对 32 位代码的支持（比如苹果那样彻底切断）。如果 Fedora 真按这个提案执行，32 位程序仍然可以运行——只要它们自带需要的库就行。
听起来好像很麻烦？其实不然，现在大家本来就都这么做了。Steam 自带 Linux Runtime，里面包含了运行游戏所需的全部库。喜欢 Flatpak 的用户也可以用 Flatpak 来运行。所以，那些还存在的原生 Linux 游戏，其实完全不受影响。
那 Wine / Proton 呢？也不会受影响！Wine 的新 WoW64 模式允许在纯 64 位系统中运行 32 位 『Windows』 程序，不再依赖系统层面的 32 位库。
那么这个提案到底会打破什么？
答案是：Steam 客户端本身。出于某种原因，Steam 在 Linux 上仍然是 32 位的。它是目前移除 32 位支持的最大拦路虎 —— 否则维护者早就能省下无数志愿者的时间与精力。
那为什么 Steam 还没迁移到 64 位？Valve 是不是还活在 2007 年？没人知道！更奇怪的是，他们其实曾经移植过，所以这事根本不是技术难题。
当然，32 位支持的取消并不仅仅会影响 Steam，但 Steam 的问题之所以特别，是因为它完全不受其他人控制。别的软件可以修、可以打包、可以重写 —— 可是只有 Valve 才能把 Steam 迁移到 64 位。
于是我们陷入了一个尴尬的死循环：维护者有充分理由想要放弃 32 位支持，以节省宝贵的资源和时间；但这么做就会导致 Steam 崩掉，于是任何相关提案都只能搁浅。而这个局面，除了 Valve，谁都无能为力。
这真的挺糟糕的。”
也有网友指出：“问题不仅在 Steam，还有 Mesa 等关键依赖”。
32 位游戏仍然需要 32 位图形驱动程序（例如 Mesa 软件包），而 Steam 出于充分理由不愿捆绑其自建的驱动程序。
因此，即使 Steam 客户端切换到 64 位构建，你在 Fedora 中仍然至少需要 32 位 Mesa 及其依赖项。
我认为争论的重点不应该是完全放弃 32 位库还是不放弃，而更应该关注哪些 32 位库可以放弃，哪些不可以。
随着争议的发酵，Fedora 维护者、FESCo 成员 Neal Gompa 出面安抚了众人，并分享了自己的观点：
“如果我们假设 Steam 客户端短期内不会迁移到 x86 的 64 位版本，也没有人去开发 Linux 下的 32 位库转 64 位的兼容机制（32on64 thunking），那我们就得认真思考，到底需要支持 i686 到什么程度、支持多久。
毕竟 Fedora 的每个版本只维护大约 13 个月，其实我们完全可以把 i686 的淘汰时间延后很久。
如果我没算错的话，最晚可以撑到 Fedora 65（预计在 2036 年 10 月发布），因为它的生命周期将在 2037 年 11 月才结束。”
时下，这场争议或许暂时会落幕，但围绕新旧架构、兼容性与前进节奏的博弈，只会在未来一次次重演。
参考：
https://news.itsfoss.com/fedora-could-kill-bazzite/
https://www.reddit.com/r/linux_gaming/comments/1lkl78s/the_32bit_issue_is_at_least_partially_valves_fault/
