LWN：打算在Fedora 33中做哪些改动？

关注了就能看到更多这么棒的文章哦～

Stirring things up for Fedora 33

By Jonathan Corbet
June 29, 2020
原文来自：https://lwn.net/Articles/824620/
主译：DeepL

Fedora发行版的下一个版本——即Fedora 33——目前最新的计划是在10月底发布。Fedora作为一个快速发展的发行版，每个版本都会包含一些引人关注的变化，但 Fedora 33 现在看来可能比之前的那些版本改动更加激进。几个有争议的改动目前正在项目邮件列表中进行讨论，本文会给出一个情况概述。

The end of mod_php

多年来，mod_php 这个Apache module是使用PHP代码来响应网络请求的首选方式。但那是很多年前的事了，现在推荐的module是php-fpm。原因包括：支持threaded module，可以与nginx配合起来，以及Web server的地址空间中移除了PHP解释器。Fedora 过去这段时间一直同时支持这两个module，但目前计划 Fedora 33 开始移除 mod_php，只支持 php-fpm。

不出意料，像mod_php这样历史悠久的module，目前仍有一些用户，其中有几个人在邮件列表的讨论中表达了自己的意见。例如，John M. Harris Jr.说：

The default doesn't matter, there's absolutely no reason to take away the sysadmin's choice here. There are at least 40 servers I personally am responsible for where I see no reason to move from mod_php to php-fpm, for example.

Neal Gompa 对他的回复是这样的：

As an (oft forgotten!) member of the PHP SIG, I'd like to point out that part of what we're supposed to do is ship a PHP stack that minimizes footguns and security nightmares. The PHP stack doesn't make this easy as it is, and it's been relatively well-known for a while now that running the interpreter in the same process as the webserver is a bad idea. [...] It is absolutely a good idea to take away this choice from our builds when the advice from framework developers, ecosystem experts, and the upstream developers is to not use mod_php.

除非有更响亮的反对意见出现，否则看来是没法阻止这个计划了。目前正在运行mod_php的Fedora用户在不久的将来就会考虑转用php-fpm。

No more swap partition

Fedora 安装时通常都会配置有一个适当大小的 swap 分区来减轻内存的压力。然而，现在的一个提案却建议取消swap文件，而是使用zram建立一个虚拟的swap设备。zram设备的工作原理是将内存内容压缩并存储回内存中，如果RAM的内容压缩比很高的话，将其放到zram中压缩存放就可以释放出不少空间。此外，即使算上CPU进行压缩和解压的工作，zram的速度也往往比交换到存储设备（storage device）上要快。

这个建议引出了许多讨论回复，其中大部分对这个建议是否可以通过并没有太多帮助。参与者似乎普遍赞成，但也有少数人不完全相信这个改变是合理的。有人提出的一个反对意见是，一个没有swap file的系统就无法休眠（hibernate），根据此提案的开发者Chris Murphy的说法，这不是什么大问题：

Most laptops today have UEFI Secure Boot enabled by default and therefore hibernation isn't possible. And even when the laptop doesn't have Secure Boot enabled, there's a forest of bugs. It works for some people and not others

另一个问题是，当对旧的Fedora系统升级时，正在使用的swap file应该如何处理。显而易见的解决方案是继续保持使用swap file，但Murphy认为应该移除swap文件并将系统切换到zram。他的理由是，如果不这样做，会使用户群分散。这个细节如何解决还有待观察，但 swap-on-zram 整体看起来会继续推进。

Compiler policies

长期以来，Fedora 一直有个政策，要求整个发行版都要用 GCC 编译器编译，只有不能用 GCC 编译的包才会例外。Fedora 33 中计划取消这个要求。取而代之的要求是，任何一个软件包所使用的编译器应该是upstream建议使用的（当然，需要该软件包的上游给出了建议才行）。这就为许多喜欢LLVM的软件包开辟道路，而不再需要维护者费力地用GCC来构建。

编译器的选择往往会引起一些情绪化的反应，这次也不例外。Kevin Kofler反对这个变动，他说。"我们选择一个系统编译器，这是有原因的"。一些人，如Jakub Jelinek，指出ABI不兼容，并担心将在发行版中引入一些新的微妙bug，但主流观点似乎认为这种不兼容的情况会很少见，万一出现了，可以作为bug处理。Gompa指出，把OpenMandriva转移到LLVM上之后，性能和安全方面都有损害，但他没有提供具体细节。

推动这一变化的Jeff Law表示，使用upstream所建议的编译器会让很多Fedora包维护者的工作变得更轻松。他还坚定地认为"Fedora中的包应该尽可能地接近upstream"，toolchain的选择当然也是其中的一部分。这个改动似乎也很有可能会在Fedora 33版本中成为现实。

Default editors

目前为止最具争议性的话题，完全可以预料到，就是由这个将Fedora系统的默认编辑器设置为nano的提议。并不是每个人都了解改变toolchain对构建一个某个package的影响，但每个人都知道他们最喜欢的编辑器是什么，并且通常很乐意告诉其他人。Fedora目前没有设置默认的编辑器，这意味着用户通常最终会选择vi（或vim），这对于不熟悉该编辑器特性的人来说不是最友好的选择。选择nano至少可以给新用户一个机会能弄清楚该如何退出编辑器，甚至可能还能完成他所想做得编辑工作。

这个讨论非常长，但总结其实不长。这里的观点完全不一致，有强烈的反对，也有像Jan Kratochvil的这条留言：

This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom.

这是在回复Adam Williamson的评论"我唯一的遗憾是，我只有一个+1给这个建议！"时说的。最后，大多数参与者似乎认识到vi对于新用户来说并不是最友好的体验，而有经验的用户其实可以很容易地设置EDITOR环境变量来使用他们想要的编辑器。

Switching to Btrfs

还有一个建议是将Btrfs作为新安装的Fedora的默认文件系统。这并不是一个新想法。事实上，在2011年曾经有一个被批准的计划在Fedora 16中改用Btrfs。转换到像Btrfs这样的现代文件系统有明显的优势，包括它的存储管理（storage-management）和快照(snapshot)功能。但Btrfs在2011年时使用下来太不稳定了，所以这个计划被放弃了。

这次对稳定性的担忧也很快就出现了。Vitaly Zaitsev很快就宣称：

I'm strongly against this proposal. BTRFS is the most unstable file system I ever seen. It can break up even under an ideal conditions and lead to a complete data loss.

另一方面，Btrfs的开发者（也是推动这个提案的这群人之一）Josef Bacik指出，Btrfs被部署在Facebook的大量机器上，尽管Facebook故意将其放在那些质量不好的存储器硬件上使用，但这个选择 "效果非常好"。

现在预测Btrfs是否会比九年前那次走得更远进而被Fedora采用，还为时过早。但拥有一个像Btrfs这样的文件系统对发行版的好处是显而易见的，而且有一长串有实力的开发者在推动这个提议。Fedora用户可能会在2030年前默认获得Btrfs。

One that didn't make it

只要不主动引起问题，Fedora 系统上的那些退役（retired）软件包往往会进入一种边缘状态。它们仍然留在安装它们的系统上，即使这些系统升级到那些不含这个软件包的Fedora新版本上也一样。随着时间的推移，它们可能会出现问题或安全问题，但它们就像那个被大家遗忘的某个服务一样一直在那里，直到有事情发生时才引起别人的注意。

有个提案设想了一个方案，即将退役的软件包用一个名为 fedora-retired-packages 的新的metapackage来明确淘汰掉。这将导致它们在退役后的那个Fedora版本中被自动移除。一些开发者很欢迎这种清理这些无人维护的软件包的想法，而另一些开发者则强烈反对从系统中删除那些可能仍在使用的软件包。讨论中有一个单独的分支里则在争论应该使用什么方式来移除，认为这些删除工作应该在DNF包管理器中明确操作，而不是通过一个magic metapackage来实现。

最后，推动这个建议的 Miroslav Suchý 决定撤回它。他将致力于一个新的提案，即一个功能，允许用户在合适的时候来删除无人维护的软件包。

Fedora 33时间表中，系统级别改动的提案的截止日期目前定为6月30日，而那些仅限于自身改动（self-contained）的提案的截止日期为7月21日。上面的提案中，除了这个放弃mod_php的提案之外，都是系统级别的改动。因此，还有时间为下一个 Fedora 版本提出更多的修改建议。如果社区成员认为这次的清单上已经有足够多的提案了从而拒绝后续提案的话，也请大家原谅他们。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～