真相：为什么红帽为了 CentOS Stream 而抛弃 CentOS？

当 CentOS 的 Linux 母公司红帽宣布将重点从 红帽企业 Linux （ Red Hat Enterprise Linux ） （RHEL）的重建版 CentOS Linux 转移到 CentOS Stream上，而 CentOS Stream 的跟踪时间刚好在当前 RHEL 版本之前时，很多 CentOS 用户简直要昏倒了。

在 Hacker News 上，最主要的评论是，“想象一下，如果你正在经营一家企业，并基于 10 年寿命的承诺部署了 CentOS 8 。现在你全完蛋了，而红帽知道这一切。他们究竟为什么不从 CentOS 9 开始做这个转换？？！让我们不要粉饰这个问题。他们背叛了我们。”

在 Reddit/Linux 上，另一个人咆哮道：“从 CentOS 4 以来，我们的开源项目都是基于最新的 CentOS 版本的，我们的旗舰产品运行在 CentOS 8 上，我们已然把一切都押注在了他们承诺的 2029 年 5 月 31 日生命周期上。”

自称 “Unix 宇宙中最好的 Linux 博客”，nixcraft，一个拥有超过 20 万订阅者的账号发布的热门推特说：Oracle 收购了 Sun 公司， Solaris Unix、Sun 服务器/工作站和 MySQL 被转到了 /dev/null。IBM 买下红帽：CentOS 去了 >/dev/null。请注意。如果有一天 Oracle、IBM、MS 等大厂商购买了你喜欢的软件，请尽快启动迁移。”

其他许多人也加入了这个令人恼火的 CentOS 用户吐槽团，认为他们最喜欢的 Linux 被夺走是 IBM 的错。还有一些人则尖声叫骂红帽在背叛开源本身。

红帽为什么要这么做？红帽的首席技术官 Chris Wright 在推出 CentOS Stream 时说：“开发者......需要更早地[在 2019 年 9 月]访问代码，与更广泛的合作伙伴社区进行改进和更透明的合作，并能够影响新的 RHEL 版本的方向。CentOS Stream 正是为了解决这些需要而出现。”

简而言之，一个原因是开放红帽企业 Linux（RHEL）的代码。原 CentOS 董事会成员、长期的 Fedora Linux 贡献者、红帽高级社区架构师 Karsten Wade 在一篇博客文章中进行了更进一步的解释：

RHEL 本身的开发仍然封闭在红帽的防火墙之后。 这种情况已经持续了近二十年。对于开源开发生态系统来说，这一直是一个重要的，而且经常是痛苦的缺口 —— 这仍然是和 2003 年一样的开放性缺口。

这就是我们今天所处的境地。将项目的重点转移到 CentOS Stream 上的举动，就是为了在一些关键的方面填补这个开放性缺口。本质上，红帽是通过将 CentOS 的位置从 RHEL 的下游转移到 RHEL 的上游，来填补 Fedora 和 RHEL 之间存在的开发和贡献缺口。

是的，这是真的。部分原因是红帽在 Fedora 和 RHEL 开放之间做最后的、重要的步骤。另一个部分的官方原因是，正如 Wright 所说，CentOS Stream 作为 RHEL 下一步的“滚动预览”，无论是在内核还是功能上都可以用于当今容器化、云原生的 IT 世界。毕竟，Facebook 已经在 CentOS Stream 衍生的 Linux 操作系统上运行了其数百万台服务器。

因此，Wright 继续说道，虽然“CentOS Stream 并不是 CentOS Linux 的替代品，相反，它是一个自然的、不可避免的下一步发展，旨在实现该项目进一步推动企业 Linux 创新的目标。”是的，CentOS Stream 不是一个你可以运行多年、稳定版本的 Linux 服务器发行版，但它是以云为中心的公司所需要的，以部署“容器化应用和云原生服务，以快速的硬件创新和生态系统转向软件即服务（SaaS）。......这就是我们认为的 CentOS Stream 优势所在。它为社区层面的快速创新提供了一个平台，但又有足够稳定的基础来了解生产动态。”

是的，这也是事实。但是，它们不是故事的全部。以下是红帽将老式的定期发布的 CentOS 放任自流的真正原因。

红帽公司根本没有怎么谈论这方面的问题，但是红帽公司 Linux 工程副总裁 Mike McGrath 在 ITPro Today 上接受 Christine Hall 的采访时，却把秘密泄露了出来。“我想说的是，对我们来说，最大的问题是 CentOS 本身其实并没有给红帽提供那么大的用处。我们建立的大多数社区，比如 Fedora，确实有很多双向的社区参与。不幸的是，CentOS 从来就不是这样的。它一直是一个用户社区，所以那种贡献模式大多是单向的。”

让我再重复一遍，“CentOS 本身其实并没有给红帽提供那么大的用处。” 它从来没有。而且，有很多红帽的资深人士从第一天开始就知道这一点，他们一点也不喜欢它。

你知道谁在使用 CentOS 吗？一份简短的名单包括迪士尼、GoDaddy、Rackspace、丰田和 Verizon。此外，还有几十家公司围绕 CentOS 打造产品。这些公司包括 GE、Riverbed、F5、Juniper 和 Fortinet。红帽从这些 CentOS 的“客户”身上赚了多少钱？零！

在 CentOS 博客上，一位不满的用户说：“整个前提，也是唯一有人使用 CentOS 的原因，就是因为它重构了 RHEL。恭喜你破坏了这一点，笨蛋。”

没错，这也是 CentOS 要为 CentOS Stream 让位的最大原因。

红帽公司没有人愿意公开说这句话，但众多红帽公司的高管告诉我，情况就是这样。

有一位说：“这与 IBM 几乎无关。在 2018 年秋季收购的消息还没有传来之前，我们就在详细地讨论这个问题。有两个内部原因。首先，工程和销售部门无论如何也想不出如何在各自的产品组合中定位 CentOS。而且，把 CentOS 变成上游的想法始于 2014 年，当时 Jim Perrin [前红帽开发人员和 CentOS 董事会成员，现为微软首席项目经理]在 2014 年巴西的 Fórum Internacional de Software Livre（FISL）演讲中谈到了这种可能性。结果就出现了 CentOS 特别兴趣小组（SIG），这是 CentOS Stream 之路的开始。”

一位前红帽高管坦言：“CentOS 在挖销售的墙角。客户的看法是‘它来自红帽，是 RHEL 的克隆，所以它很好用！ ’其实不然。它是一个二流的拷贝。”以他的立场看，“这 100% 是防守，以避免 CentOS 造成更多损失。”

还有一位前红帽官员说。如果不是因为 CentOS，在红帽成为十亿美元的企业之前，红帽就已经是一家百亿美元的公司了。

而另一位红帽员工指出：“看看 CentOS 的 FAQ，它就在那里写着 ——

CentOS Linux 不受 Red Hat 公司的任何支持。
CentOS Linux 不是 Red Hat Linux，不是 Fedora Linux，也不是 Red Hat Enterprise Linux，它不是 RHEL。CentOS Linux 不包含 Red Hat® Linux、Fedora 或 Red Hat® Enterprise Linux。
CentOS Linux 不是 Red Hat® Enterprise Linux 的克隆。
CentOS Linux 是由 Red Hat, Inc 为 Red Hat Enterprise Linux 提供的公开源代码，在一个完全不同的（CentOS 项目维护的）构建系统中构建的。

我们不欠你什么。”

这可能会让你们中的一些人对红帽非常生气。不过，在你们发火之前，让我先问你们一些问题。CentOS 的“客户”为 CentOS 贡献了多少？我说的不是钱。我说的是代码、文档和支持。所有这些开源社区应该回馈的东西。答案是：几乎没有，接近于无。

在 CentOS 从事安全工作的 Dick Morrell 在推特上写道：“社区[是]由合作和互动定义的。如果 @CentOSProject 是一个社区建设的住宅开发项目，它将享受那些受益和使用其设施的人所贡献的扩建、楼层和功能。” Morrell 继续说道：“然而 @CentOSProject 一直是不断给予的仁慈礼物，而现在那些抱怨的人从来没有站出来用砖头、水泥或玻璃来扩建这个物产。”

你真的能责怪红帽做了一个企业应该做的事情吗？赚钱的同时而为他们的付费社区服务？我明白为什么人们对红帽感到生气。这是沟通不畅的问题。仅仅用一年的警告就切断了对 CentOS 8 的支持，这理所当然地换来了很多人的不满。 但如果你是那些现在对红帽愤怒的人之一，在你太过自以为是之前，你可能要先自我反思一下，想想你对 CentOS 的回报有多少。

最后，如果你还是无法忍受红帽对 CentOS 的做法，还有其他的 Linux 替代品。而且，至少有两个“经典”的 CentOS 构建版本，CloudLinux 的 Project Lenix 和 Rocky Linux 可供你考虑。

via: https://www.zdnet.com/article/why-red-hat-dumped-centos-for-centos-stream/

作者：Steven J. Vaughan-Nichols 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文转载来自 Linux 中国: https://github.com/Linux-CN/archive