关于 CentOS 8 转向 CentOS 8 Stream 这个新闻，据我所知是个乌龙，用 CentOS 作生产环境的用户其实不必担心

[raysonx]

首先声明本人为红帽员工，但不是做 RHEL/CentOS 的，利益无关，本文仅代表个人看法，不代表公司观点。

当时“CentOS 8 将于 2021 年低结束支持并转向 CentOS 8 Stream，而 CentOS 8 Stream 是小白鼠版 RHEL”的消息同样在公司内部引起了很大的震动。红帽是个很大的公司，非相关团队的同事和你们一样都是在网上了解到的消息，一样对此表示震惊、失望。但就后来和相关同事、高管讨论得知，这本来是一个对社区和公司双赢的好事，却由于公司公关失败并被媒体添油加醋煽风点火，导致 CentOS 用户叛离，并对 RHEL 系发行版的声誉造成了十分恶劣的影响。

据我在公司内部了解到，红帽的本意是将 RHEL 的开发流程“开源”，并加快 CentOS 的 bug 修复速度。在 CentOS 8 Stream 出现之前，现状是这样的：

1. RHEL 的源代码是公开的，但是开发测试流程都是在内部完成且不公开，公司外部人士是无法投入 RHEL 开发或测试的。虽然 Fedora 是社区驱动的，但 Fedora 作为 RHEL 的开发版本，相关内容进入 RHEL 的速度十分缓慢。
2. 一个 bug 在 RHEL 被修复后，需要 RHEL 的测试人员进行测试，测试通过后对 RHEL 推送更新。而 CentOS 团队作为另一个团队，需要等待新版本进入 RHEL 以后，重新 build，再走 CentOS 的更新流程。这导致 CentOS 中 bug 的修复速度比 RHEL 慢几天至几个月。

而转向 CentOS Stream 之后，变成这样：

1. 源代码及开发流程向社区公开，RHEL 的开发及测试人员将直接在 CentOS 进行开发测试，公司以外的人士也可以参与。
2. 向 CentOS Stream 推送的更新是通过了 RHEL 测试人员测试后的版本，从开发流程上讲，CentOS Stream 的质量就是以前 RHEL 的质量，而以后的 RHEL 将变成 CentOS 的下游，将更加保守稳定。所以 CentOS Stream 并不是小白鼠版本。
3. 多数 bug （除个别未公开的安全漏洞外）的修复将在第一时间推送到 CentOS，CentOS 将比 RHEL 更快地获得 bug 修复。

总而言之，这件事情让我感觉到红帽是好心办了一件坏事。作为一家软件公司，缺乏高水平的公关，被媒体和竞争对手往死里黑。

[whee1]

说白了，以前白嫖真香，现在不让嫖了，不爽。
这就是部分人的心态。

[iikebug]

这可不是什么公关问题，明眼人基本上都看的出来。

[raysonx]

@swulling 会出新的 Steam，不会滚动到 9 。

关于你说的 CentOS 用户拿 RHEL 用户做小白鼠这一点很有意思，我作为一个技术人员之前没有想到。我这里面描述的这些是公司最初的动机，而这件事情所引起的反响已经远远超出所有人的预料了。我猜测公司今后可能根据反应做出一些调整，但我现在还不知道。

[raysonx]

@swulling 实际上据我 RHEL 的同事说基本就是把 RHEL 的开发测试流程搬到了 CentOS Stream，以前 RHEL 有自己的开发分支，说是开发分支其实也没错的，只不过不是传统上认为的开发分支或者开发版本。

另外你所引用的问句是有一个 and 的，这句话翻译为“如果你正在用 CentOS 8 作为生产环境并担心 Stream 版本不能满足需求”，并不是说 Stream 版不能作为生产。虽然我觉得作为社区发行版，以免责声明的角度都不会鼓励用户用于生产环境。

[wangkun025]

@raysonx 以后进入 centos 的，也不见得最终会进入 RHEL，对吧，毕竟是上游测试版。

[swulling]

@raysonx 其实这种都是商业决策，从商业道德上来说，比 Oracle Linux 这种自己正事不干，用别人辛苦测试和集成的代码做商业发行版抢生意的行为还是好一点的。

但是关键是 Redhat 的口碑太好，导致这件事情的反噬也很大。

现在卖 Linux 操作系统这个生意，现在是越来越难做。因为整体的趋势是上云，而云厂商都会提供自己的发行版（比如 AWS 提供了自己的 AWS Linux，虽然也是基于 CentOS 的）。高层们为了保住营收出这些招也很正常。

其实 RHEL 想坏名声，还有更狠的，就是搞乱 RHEL 的代码公开流程。因为 GPL 只是购买人有权利申请 GPL 格式代码，形式并没有做规定。

Redhat 可以只用光盘邮寄的方式开放代码，代码开放时只开发代码本身，所以的代码的版本历史、编译信息等都可以不给，社区就自己慢慢编译排错吧。

再狠一点，搞一些专有的软件包提供给商业客户使用，不开源，这个不违反 GPL 。但是社区拿到的版本永远没有这些专有软件包，也就和 RHEL 不可能完全一样。另外也不是所有的包都是 GPL 的，有些是 MIT 、BSD 、Apache 的，那就不开放代码，让社区自己去猜。

这事做的人多了，现在国内的银河麒麟、UOS 这些，哪个按照 GPL 提供了源代码？

[m4d3bug]

毕竟很多人连 changelog 都不看就无脑跟着吹，少了个次要版本就各种自我高潮

[junkman]

@raysonx 支持，原本我也想叛逃 CentOS 的，这么说的话我得重新考虑下我之前的决定了。

另外请教下几个问题：

1. 如果直接在 CentOS Stream 上修复 bug 的话，那么那些宣称兼容 RHEL 的 Linux 发行版获取 bug fixes 也是从 CentOS Stream 获取是这个意思吗？

2. CentOS 8 Stream 的 Life cycle 是多长？网上似乎没有找到 CentOS 8 EOL 之后 Stream 的支持时长。

[susanzhou]

所有服务器都用 ubuntu 的飘过

[vibbow]

@raysonx 那么问题来了
比如我现在有一个应用，依赖 libA 版本 1
那么当这个 libA 更新到 版本 2 的时候，CentOS Stream 会直接更新到 版本 2 呢，还是会同时维护两个版本？

如果是直接更新到版本 2，那这才是生产环境不能用滚动更新系统的根本原因。

[raysonx]

@wangkun025 CentOS/RHEL 不是新功能的实验田，通常情况下某个 RHEL 大版本发布后只会有 bug 和安全修复，我猜测你说的这种情况大概只会出现在 bug 修复无效等特殊情况吧。

[m4d3bug]

@wangkun025 并不是，centos 不是 rhel 特性的试验田，而是 rhel 的临门一脚，给 rhel 更新 /修复优先供给 centos stream

[m4d3bug]

@junkman
1，是的，临门一脚
2，stream 是五年多，之前回复过，没记错的话

[m4d3bug]

@vibbow 软件包在红帽内部，本身就有专门为了次要版本和整个主要版本的两个版本，stream 应该只会拿到主要版本，而 RHEL 会有专属的次要版本软件包

[vibbow]

@m4d3bug 我的意思是，比如 libA 有 1.x 和 2.x 两个不兼容的版本
CentOS Stream 会直接从 1.x 滚动到 2.x 么？

还是像以前一样
CentOS 6 是 1.x 并锁定大版本
CentOS 7 是 2.x 并锁定大版本

[m4d3bug]

@vibbow 我的上一条回复不够明白，重新说一下
rhel 是不会动版本号的，因此 libA 更新到版本 2，rhel 的做法是 backport 到旧版本的小版本中去，centos stream 理应也是一样的做法。

[lsylsy2]

再狠一点，搞一些专有的软件包提供给商业客户使用，不开源，这个不违反 GPL 。但是社区拿到的版本永远没有这些专有软件包，也就和 RHEL 不可能完全一样。另外也不是所有的包都是 GPL 的，有些是 MIT 、BSD 、Apache 的，那就不开放代码，让社区自己去猜。

@swulling 让我想到了安卓的 Google Play Services

[vibbow]

@m4d3bug 如果 CentOS Stream 不会锁定大版本，那就不适合生产系统试用
如果 CentOS Stream 会锁定大版本，那这个大版本的切换时机是怎样的？

[m4d3bug]

@vibbow 你说的 libA 版本和 os 次要版本没有必然联系，centos 的做法是懒得维护软件的小版本，而 RHEL 是一直保持软件的大版本而采用小版本的更新

[vibbow]

我知道问题出在哪里了
CentOS 现在的命名有问题
不应该叫 CentOS Stream 8 (绝大多数情况下这个 8 还会被省略）

应该叫 CentOS 8 Stream / CentOS 9 Stream