关于 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 修复。

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

我发这帖的背景是看到朋友圈又在转发 CentOS 8 相关的事情，觉得有必要开帖和大家分享一下我了解到的内容。
看到大家在评论中有一些疑问，我会挑比较典型的回复一下自己的观点。同样的，本文正文和评论仅代表我个人见解，不代表公司立场，也不是官方解释。

这里引用一下 @m4d3bug 的评论：
> 我的理解是 bugfix 优先给 stream，RHEL 和 stream 是同级别的，只不过是谁先用谁后用（和疫苗优先分配给冷链，医护人员一样）。

其实最大的误解就是认为 CentOS Stream 是 RHEL 的测试版。个人认为可以把 CentOS Stream 理解为以前的 RHEL，而新的 RHEL 变成了 CentOS Stream 的下游。CentOS Stream 不是新功能的试验田。

CentOS Stream 的滚动只会在小版本滚动，大版本是不会变的。比如 RHEL 9 将会对应一个新的 CentOS Stream 9，而不是从 CentOS Stream 8 滚动上去。

有些人可能误解了 CentOS/RHEL 的稳定就是版本旧、不更新。其实不是的，RHEL 的策略是在保持软件包大版本不变、不会造成破坏性更新（即 ABI 稳定）的前提下，将最新版本的 bug 修复反向移植（ backport ）到老版本，让用户可以在不引入破坏性更新的前提下及时获得 bug 和安全修复。

此外，对于实在无法用 CentOS Stream 的用户，红帽还有为个人开发者和小企业提供免费的 RHEL 订阅的选项。见 https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel

CentOS Stream 作为 RHEL 上游，感情上确实会给人 Stream 版是测试版的感觉，但实际在软件质量上并没有降低，反而增大了社区参与度，加快了 CentOS 的 bug 修复速度，还能反哺 RHEL 。
但总而言之这个决策确实考虑没那么周全，引起了相当大的负面反响。

总结：

我觉得这个问题的矛盾在于，好多 CentOS 的用户虽然都号称追求“稳定”，但其实很多人并不理解他们谈论的“稳定”是什么，反而做 RHEL 的下游给了他们安全感，即使 CentOS 本身比 RHEL 更新慢几个月、编辑参数不一样、缺包。现在的 CentOS Stream，虽然比之前 CentOS 更加接近原汁原味的 RHEL 了，软件质量和测试也相当于之前的 RHEL，却因为做上游而丧失了做那种所谓的安全感。

说这么多也无法为相关决策的失败开脱。这种重大决策本来就应该做的浅显易懂，真不如当时就说把 CentOS Stream 8 叫做 RHEL 社区版。

[markgor]

RHEL 竞争对手是 ubuntu 吗？
RHEL 多年前公司有一套，现在基本满是灰。
后来转了 CENTOS，实话说 CENTOS 和 RHEL YUM 源的版本都非常老旧，更新特别慢（当时听说是为了稳定...）
具体关系我也不清楚，只记得当时主管和我说，rhel 是红帽商用版本，但授权过期了其实和 centos 差不多，没服务了。
CENTOS 是 rhel 的社区版，rhel 有任何新东西都会丢去 centos 测试，看反馈。

[Mountain]

我至今记得小时候去新华书店买游戏都能看到一盒红帽 Linux 放在一个很显眼的地方从来没有人动过

[raysonx]

@markgor
> 实话说 CENTOS 和 RHEL YUM 源的版本都非常老旧，更新特别慢
RHEL 作为企业版追求稳定第一，是很难上新版本的包的（企业软件经常会依赖旧版本包）。通常情况下在某个 RHEL 的主版本（比如 RHEL 7.0 ）发布后，大多数软件的版本就定死了，之后只会收到 bug 和安全更新，很少会收到功能更新。为了解决你说的问题，RHEL8 引入了 AppStream，比如对于 Python 而言会针对 Python 3.7 3.8 3.9 每个主要版本提供一个 AppStream，用户可以选择需要的版本，并在不升级主要版本的前提下一直获得 bug 和安全更新。

RHEL 的授权过期后就无法收到包更新了，且不再有技术支持，而 CentOS 的更新是社区负责的，需要自己切源。

[vibbow]

好像没啥误解把？主要槽点就两个呀

1 是 CentOS 8 生命周期缩短
2 是 CentOS 变成滚动更新

这两个变动导致 CentOS 不再适合在企业内稳定部署使用了。

[wangkun025]

调整后，centos 和 fedora 的区别在哪里？
感觉慢慢的 centos 和 Fedora 可以合并了。

[benjix]

@wangkun025 #5 同问

[liprais]

懂了
redhat 不想自己测试了准备甩给社区

[whee1]

主要是因为下游变上游吧。
但听 lz 一说，rhel 的人分两拨，一拨开发 centos，一拨继续维护 rhel，好像看起来也还行。

[ETiV]

LZ 把英文大小写拼得很对，看着太赏心悦目了

respect

[Kobayashi]

不担心个毛。原来 CentOS 是 RHEL 下游，现在变成了它的上游帮它测试。这能一样吗？

[raysonx]

@vibbow 这里的 CentOS 8 生命周期结束指的是原先的 CentOS 8 不再维护，原因是改变开发模式切换到 Stream 。Stream 一样也是 CentOS 8，由于开发模式转变导致不得不开新分支。我觉得需要明确的是 CentOS 8 Stream 的更新并不是测试版本，而是由原 RHEL 开发测试人员维护的稳定版本，理论上稳定性等同于之前的 RHEL 。

Stream 虽名为滚动更新，但其实和普通的滚动发行版不一样，只是不再区分 8.1 8.2 8.3 这些子版本而已。具体为什么不再区分子版本我没去了解，但能够确定的是进入 Stream 的内容都是要进入 RHEL 的，并不是那种一更新就容易挂的那种滚动版。RHEL 的主版本不变的情况下，ABI 是稳定的，个别场景下如果真的需要卡在某个子版本不升级，说法是后续会有解决方案。

不知道我这么解释明确与否。

[fiveelementgid]

建议先把滚动测试说明白
下游变上游
不是小白鼠是啥？

[raysonx]

@wangkun025
@benjix
Fedora 才是真正的 RHEL 测试版，各种软件包新功能都是最新的。和 RHEL 的区别主要在于：
1. 支持周期很短（通常只有不到 2 年）
2. 不保证 ABI 的稳定，也就是升级某软件包后可能会破坏兼容性。
3. 进入 Fedora 的内容不见得最终会进入 RHEL 。

[swulling]

感觉你可能对使用 CentOS 的公司或者组织的动机有所误解。

选择基于社区的免费发行版的思考不外乎几点：

1. 发行版的 Bug 特别是安全问题修复速度
2. 发行版的社区强大，有问题可以依靠社区解决
3. 发行版有很好的商业版本，碰到的问题商业版本都有，能够蹭解决方案
4. 发行版功能稳定，有非常良好的测试

CentOS 如楼主所说，存在 1 上的问题，但是如果要 Bug 修复快，为什么这些组织不用 Ubuntu 或者 Fedora，何必守在 CentOS 上呢，主要是看中了 2-4 。

原先 CentOS 是 RHEL 的下游，也就意味着 CentOS 有的问题 RHEL 也有，解决方案可能已经有了。而且 RHEL 商业用户相当于小白鼠，给 CentOS 的人来做测试，

现在 CentOS 是 RHEL 的上游，那就意味着 CentOS 有的问题 RHEL 没有，需要等待社区解决；然后虽然 CentOS 的软件包依然会经过 RHEL 的测试人员测试，但是其相当于 CentOS 的人做小白鼠，给 RHEL 商业用户做测试。

本质上就是原先 CentOS 的地位甚至高于 RHEL 的地位，虽然获取更新慢了，但是软件包都是经过 RHEL 的商业用户们先在生产环境测试过的，现在反过来，自然很多人不爽。

最后一句，在考虑稳定性的公司上是不可能使用滚动发行版的，必须有大版本锁定机制才行，否则会出大乱子。

[cev2]

明白了，可是已经晚了。
我有什么理由不选择 Oracle Linux 呢？甲骨文官方提供了 CentOS 一键切换 Oracle Linux 的脚本 [https://linux.oracle.com/switch/centos/] ，还是原来 CentOS 的配方，还是原来 CentOS 的味道，无痛切换。

[raysonx]

@liprais
@whee1
@Kobayashi
分歧就出在这。让 RHEL 的开发测试人员去开发测试 CentOS Stream，这个 Stream 版等同于之前 RHEL 最新版的质量，并不是所谓的小白鼠。使用最新的 CentOS Stream 就和以前使用最新的 RHEL 是差不多的，而且社区用户也可以来反馈 bug 贡献代码，一举双得，但外界普遍非要认为这是做小白鼠。

[swulling]

再举一个例子，RHEL 有编写的非常好（可以说是最好的之一）的用户手册，原先 CentOS 内部培训的时候，直接拿 RHEL 的手册即可，非常的详尽清楚。CentOS 自己的文档只有一个安装手册。

现在 CentOS 在 RHEL 之前，那部分功能可能就和 RHEL 不同，这事就麻烦大了。

[swulling]

@raysonx
> Stream 虽名为滚动更新，但其实和普通的滚动发行版不一样，只是不再区分 8.1 8.2 8.3 这些子版本而已

问下以后 RHEL 出 9 后，CentOS Stream 是搞一个新的 CentOS Stream 9，还是继续滚动？还是说 RHEL 以后也滚动？

[EPr2hh6LADQWqRVH]

明白了，是名字起错了，应该叫 RHEL-CE

[swulling]

另外在官网的博客文章中明确建议不要在生产环境使用 CentOS Stream，并自称为 develop branch

> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.

也就是 Redhat 对 CentOS Stream 的定位就是一个用于开发测试环境的发行版，不能用在生产环境。

[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

[vibbow]

CentOS Stream 8 这个 8 被省略的时候，就很容易被联想到 arch 的更新模式

[testratter]

Red Hat 基本所有软件都是开源社区优先的，bugfix，feature 基本都是先提到对应的开源社区版本，然后再 backport 的，只有 CentOS 是个例外，其落后于 RHEL 。

CentOS Stream 也是大版本锁定的。

“CentOS 有的问题 RHEL 没有”这种情况其实现在也存在，因为 CentOS 落后 RHEL 几个月，所以可能 RHEL 修复了，CentOS 很久才跟进。变成 stream 之后反而应该会有所改善。

就是现在的 Fedora，其 Bugfix 优先于 RHEL 的情况也不少见，当然因为激进的 feature 也导致 Fedora bug 更多。

CentOS Stream 一个大版本中不会有大的 Feature，相比之前，只会有更优先的 Bugfix 。除了有 Bugfix 失败导致更多 Bug 这种特殊情况以外，整体应该是好于之前的。

不过用户角度看，CentOS 看起来确实更加激进了。但我个人觉得这不是个坏事，KABI 等稳定性不变，系统运行稳定性不好说，可能更好，更坏，或总体没什么区别。

[iConnect]

这次变更如果算公关失误的话，其实命名方面造成很大困惑。不如 centos 原名称不改，增加类似 plus 版，advanced 版，Pro 版，max 版等等，这些命名套路手机公司可是玩的很六的。

修改社区中广为流传的概念本来就是风险很大的事，新概念传播(辟谣)没那么容易。

[raysonx]

@junkman
> 如果直接在 CentOS Stream 上修复 bug 的话，那么那些宣称兼容 RHEL 的 Linux 发行版获取 bug fixes 也是从 CentOS Stream 获取是这个意思吗？
我只能说 CentOS Stream 和 RHEL 的源代码都是开放的，其他发行版有他们自己的决策。

根据官网，“Updates for the CentOS Stream 8 distribution continue through the RHEL 8 “full support” phase.”，也就是说 CentOS Stream 8 的生命周期与 RHEL 8 的 full support 生命周期相同，也就是 5 年。

[vibbow]

我个人认为 centos / redhat 谁先于谁更新并不是这次变更争论的重点

而是很多人都以为 CentOS Stream (8)是类似 arch 那种的滚动更新

[m4d3bug]

@raysonx 我的理解是 bugfix 优先给 stream，RHEL 和 stream 是同级别的，只不过是谁先用谁后用（和疫苗优先分配给冷链，医护人员一样）。并不是说 bugfix 还要从 Stream 拿

[iConnect]

版本命名方面，Ubuntu 做的不错，兼具灵活性和清晰

[m4d3bug]

@vibbow 毕竟很多人不看 changelog

[vibbow]

@m4d3bug 这是 CentOS 自己的锅
谁叫他们自己很多新闻稿都写的 CentOS Stream，省略掉了版本号

[felixcode]

有点像 Debian testing 和 stable 的关系吧，但那是从社区中来，到社区里去啊。
这里是从 CentOS8 Stream 里由社区测完了，再放商业版本的 RHEL 里去

[m4d3bug]

@vibbow 不完全是，新闻稿这种东西对手公司也没少写

[testratter]

Fedora 才是真-小白鼠，不过就是 Fedora 也不是 Arch 那种滚动更新，而是一年一个大版本，每个版本支持会有个 1 年，期间会修 Bug 和安全问题，一般也没有大的 Feature 或引入大的 Bug 。

Fedora 有个滚动分支 Fedora Rawhide，那个激进至极，大小问题不断，一般每年会从中 branch 一个新的 Fedora 版本，稳定下来之后就是新的 Fedora 发行版本。

CentOS 是比 Fedora 稳定得多得多的，Fedora 正式版都相对温和，而且有相对完整的 QA，CentOS 就更不会多激进了。

[twl007]

一样不一样看 Red Hat 的反应就知道了 这种改变并不是好事情 现在每个版本发布都会有一个已知问题列表 变成 stream 了还会有么？

感觉就是变相强迫当前用户去买 RHEL 得订阅罢了

另外 RHEL 的订阅过期 可能会要求你回退到你买订阅的那个版本 而不是留在当前的版本

[m4d3bug]

@twl007
>感觉就是变相强迫当前用户去买 RHEL 得订阅罢了
RHEL 有 16 个免费的开发者订阅了解一下

>另外 RHEL 的订阅过期 可能会要求你回退到你买订阅的那个版本 而不是留在当前的版本
有白纸黑字吗？我怎么从来都不知道有红帽的人这样做？

[raysonx]

@felixcode 并不是 Debian testing 和 stable 的关系。CentOS Stream 的大版本是不变的，只是在小版本上滚动。CentOS Stream 也不是 RHEL 的测试版本，而是已经通过质量测试的版本，只不过比 RHEL 付费用户早那么一点，我的理解是 CentOS Stream 就是以前的 RHEL （除了没有商业支持），而新的 RHEL 变成了 CentOS Stream 的下游。

[m4d3bug]

@raysonx 你的理解是对的

[raysonx]

@m4d3bug
> 我的理解是 bugfix 优先给 stream，RHEL 和 stream 是同级别的，只不过是谁先用谁后用（和疫苗优先分配给冷链，医护人员一样）。
赞同

[Lemeng]

我觉得吧，这事，
算了，看看大神们的想法

[FS1P7dJz]

事实就是大部分选择 centos 的场景和用户,都是要求就一个字"稳"
谁要你修 bug 多块,谁要你功能多新
需要这些直接用别的发行版了

当你抛弃自己最具特色的点之后,那么用户抛弃你也是一件很正常的事情

[m4d3bug]

@FS1P7dJz 事实上，sorry，bug 修不快≠稳，另外 Stream 没有 break change 没有你所谓的“功能多新”，不看文档不看 changelog 自己给自己挖坑也是一件很正常的事情

[twl007]

@m4d3bug

RHEL 有 16 个免费的开发者订阅了解一下

开发者订阅之前只能用来开发 并不能用来企业内部跑生产的 也是 CentOS 政策公布后 RedHat 才更新的政策 开放了面向小企业的选项 如果之前你知道谁在用开发者订阅跑公司内部生产环境 你要意识到这个是违反用户协议的

有白纸黑字吗？我怎么从来都不知道有红帽的人这样做？

可能政策有修改 但是这个情况以前应该是存在的 也是相关的人说的 所有合同应该是独立的 不知道楼主是归属于 RedHat 开发团队还是销售团队 如果是销售团队的话可以再确认下 可能现在的政策已经改变

[m4d3bug]

@twl007
>开发者订阅之前只能用来开发 并不能用来企业内部跑生产的 也是 CentOS 政策公布后 RedHat 才更新的政策 开放了面向小企业的选项 如果之前你知道谁在用开发者订阅跑公司内部生产环境 你要意识到这个是违反用户协议的

所以你要怎么用，选择权在你自己手上，没有人强迫你。

>可能政策有修改 但是这个情况以前应该是存在的 也是相关的人说的 所有合同应该是独立的 不知道楼主是归属于 RedHat 开发团队还是销售团队 如果是销售团队的话可以再确认下 可能现在的政策已经改变

闻所未闻，建议找相关的人要说法

[raysonx]

@FS1P7dJz CentOS/RHEL 的稳是指在保持 ABI 稳定（不会有破坏性更新造成兼容性问题）的前提下，能够长时间地获取 bug 和安全问题修复，而不是长时间不更新。RHEL 的策略是，如果某个软件包 bug 在开源社区上游被修复了，老版本没人管，红帽就会把这个修复移植（ backport ）到老版本，不需要用户升级到最新的软件包，因为最新版可能有破坏性更新。

[raysonx]

@twl007 强制降级是不可能的。大多数开源软件都是 GPL 协议的，这个协议保证了某个软件的版本一旦授予了某个用户的使用权，是不可撤销的。

[Marszm]

嘛...感觉我服务器的 centos7 估计还能用个十几年吧....

[bin456789]

说白了就是 Centos Stream 要变成 RHEL Beta，想让更多人测试 RHEL
但 CentOS 的目标群体只是想要 RHEL 的免费替代品
CentOS 剩下 Stream 后，他们会转向 Oracle Linux 或者 Rocky Linux
但红帽放宽了免费限制，这部分人可能会用 RHEL 稳定版
也是很好的处理办法

[raysonx]

@bin456789 我觉得可以把 CentOS Stream 认为是 RHEL 的 Pre-release 版本而不是 Beta 版本，因为它确实在公司内部的定位不是测试版，而是和之前的 RHEL 同等质量。这样的好处是一方面能让社区也参与进 RHEL 的开发与反馈，另一方面能够极大的加快 CentOS 的 bug 修复速度，减轻 CentOS 的维护压力，一举双得。感情上确实会给人 Stream 版是测试版的感觉，但实际在质量上并没有降低。

[FS1P7dJz]

如果 RHEL 是 release,你这个 pre-release 不就是 beta 么...
为什么还觉得你们的公关失败?
你们的公关失败大概在于过于直白不会绕弯弯

但是我觉得既然就是一个事实上的 beta,坦诚公布说出来挺好的
别忽悠别人以为很稳真用在生产环境了结果嗝屁,反过来更毁声誉

[m4d3bug]

@bin456789

>说白了就是 Centos Stream 要变成 RHEL Beta，想让更多人测试 RHEL
原谅我的杠，Stream 更接近 RHEL λ而不是 RHEL β，RHEL 有自己的β，并且这个β不是 fedora

>CentOS 剩下 Stream 后，他们会转向 Oracle Linux 或者 Rocky Linux
Oracle 服务一样收费，免费更新和免费使用和红帽开发者订阅是一样的东西。
Rocky Linux 能活多久，会不会重蹈 CentOS 被收购前的故事，这又是另一个故事了。

[m4d3bug]

@FS1P7dJz
>如果 RHEL 是 release,你这个 pre-release 不就是 beta 么...
真不是 beta，请看#46 #69

>别忽悠别人以为很稳真用在生产环境了结果嗝屁,反过来更毁声誉
bugfix 不快都能算稳的做法，你确定你所谓的“稳”不是更毁声誉的做法吗？

[raysonx]

@FS1P7dJz 我已经把 CentOS Stream 以及 RHEL 的开发模式说的很明白了，CentOS Stream 的软件质量相比之前是没有降低的，而且更新速度加快，红帽并不依赖于 CentOS 社区来做测试，而且 RHEL 本身也有自己的 Beta 版本。如果您还是认为 CentOS Stream 是测试版我也没办法了。

[FS1P7dJz]

@m4d3bug
不是所有的 bug 都是严重到让系统无法运行
对线上环境来说,不可预期才是更要命的

如果这个 bug 已经知道,但是并不影响我的业务,或者说我的业务不涉及这个 bug,那修复与否就并不是一个很紧急的情况,这就是我所说,并不在意你修复多快

[raysonx]

@FS1P7dJz 如果不影响您的业务或者担心不可预期，您不更新不就得了，每个软件包都是有 changelog 的。这个 Stream 版本几乎是等同于之前用最新版 RHEL 的，每个软件包的发布都是有通过测试的，如果这都不可预期那就只能换发行版了。

[m4d3bug]

@FS1P7dJz
>不是所有的 bug 都是严重到让系统无法运行
>对线上环境来说,不可预期才是更要命的

1. 所以你要“可以预期”，应该做的是去看看 changelog，做好克隆测试。
你只需一个软件一个软件 update，所以，“不可预期”的是没看 changelog 的你，还是 CentOS Stream 呢？还是盲信别人开源社区分发，以为在 RHEL 后但没有任何人兜底的说法呢？
你不会还指望开源社区分发的经大批量硬件测试？难道就是“可以预期”吗？
https://mp.weixin.qq.com/s/heX7Qtc7Fizx43EgGkIiMQ
你要知道，你拿到的更新与红帽官方分发的基本没有区别，并且直属于红帽人员维护而非 CentOS 社区分发。

[xiaokfy]

加快了 CentOS 的 bug 修复速度的同时也会带来更多 bug，哈哈。

[m4d3bug]

@xiaokfy 绝对没 bug 的“生产可用”的东西怕是不存在的~

[raysonx]

@xiaokfy 修复 bug 的时候引入新的 bug 是有可能的，但肯定总体上 bug 数量是越来越少的。虽然我觉得你这句话应该也是半开玩笑的😅

[twl007]

@m4d3bug

现在协议改了 开放了对于小企业的限制 可以随便用 但是 16 个限制对于很多小企业来说并不够 现在一个企业有个一二百台服务器又不是什么问题


@raysonx

订阅到期回退的是你在订阅期间享受的服务 可能是补丁之类 就 RHEL 而言没订阅一样用 只是没法更新罢了

另外大家最看重的点在于已知变成了未知 之前的 CentOS 只是一个速度慢一点 去掉了 RedHat 专属的软件的复制版 但是改成 CentOS Stteam 之后 很多都变成了未知 甚至 bugfix 是不是一定没问题也不知道如何保证 如果 RedHat 有自己的 RHEL 的 beta 版本 那么 CentOS 是共享一套还是有自己的？如果 CentOS 的 qa 是分开做的 那么如何保证 CentOS 的 qa 能不被区别对待？抑或是 CentOS 的测试完直接合并到 RHEL 并且不再做测试？这些都是需要澄清的点 也是大家所关注的点 至于开发流程怎么变其实大家并不关心 之前大家放心的就是 CentOS 的东西是在 RHEL 验证之后的东西 而不会去抱怨那慢一点的更新速度

这么多年的信任建立很容易 但是摧毁起来只要一个决定就够了 就算 RedHat 撤回这些决定 也并不能阻止大家开始考虑替代品的计划了

[raysonx]

@twl007 CentOS Stream 的 QA 是 RHEL 的人，软件包是一样的只是先后区别。这个问题确实比较难以理解而且外人也很难了解这些东西。这个决策必须承认是比较失败的，我也只是有感而发以个人力量解释一下而已，并不能挽回什么。

[bin456789]

@m4d3bug “免费更新和免费使用和红帽开发者订阅是一样的东西”
真不是一样的东西，Oracle Linux 是完全免费的，商用也免费，和 CentOS 一样
而红帽还要激活一下，超过 16 个系统的商用也要付费

[lplusk]

@raysonx 没懂。Debian 的包也是先进入 testing 然后再变成 stable 的，但不能因此认为 Debian stable 和 testing 一样稳定啊。

[twl007]

@raysonx 这个只是 RedHat 的人 我觉得 RedHat 需要证明不仅仅是人一样 包括测试流程 测试标准以及测试环境都是一样的 但是这样的话又变成了另外一个 RHEL 个人感觉不会太一样 应该只是 RedHat 的人去开发 patch 然后遵照社区的流程构建测试然后发布 真的 RHEL 的测试流程应该是另外一套 而且会收集 CentOS 的反馈改进 patch 并且再按招 RHEL 标准继续构建测试和发布一次

就像 Ceph 这样 一样的 RedHat 的人并不能保证最后的成品也是一个级别 这方面是需要 RedHat 自己去披露更多的资料来证明的 否则最后知识 RedHat 的 QA 但是遵照社区的标准 我觉得这样还是退步

[m4d3bug]

@twl007

>现在协议改了 开放了对于小企业的限制 可以随便用 但是 16 个限制对于很多小企业来说并不够 现在一个企业有个一二百台服务器又不是什么问题

当业务量去到这种量级，真的应该好好想想该怎么做才能做到“尽量”兜底了，是 fork 回来的 Oracle 吗？还是靠信仰的 Rocky linux 吗？还是内核代码贡献都看不见前三的 Tencent OS 或者 AliOS 呢？还是虚拟机技术呢？还是红帽呢？这些大概是老板们需要思考的问题，我也给不了答案，毕竟只是打工仔。

>RedHat 有自己的 RHEL 的 beta 版本 那么 CentOS 是共享一套还是有自己的？
你粗暴地可以将 CentOS Stream 理解成 RHEL λ而非 RHEL β。

>如果 CentOS 的 qa 是分开做的 那么如何保证 CentOS 的 qa 能不被区别对待？
事实上 CentOS 一直被区别对待，其软件的编译参数和 RHEL 未必一样。仅是代码一样，之前的漏洞影响以及性能，与 RHEL 都有所区别。
而这些区别我相信 CentOS Stream 都在，而前后的区别是它现在无限接近于 RHEL，而不是像以前一样待在后面等待旷日持久的修复，实质只是一剂安慰剂。

>抑或是 CentOS 的测试完直接合并到 RHEL 并且不再做测试？
我的理解是，修复代码下发到 RHEL 之前的临门一脚，优先分配给 Stream 先适用，之后没有问题会再走一次 RHEL 的发布流程给到 RHEL 。

在我看来，这和分发疫苗的事，也是一样的一件事，可以两种说辞。
干部先打，冷链医护先打→官大过民
人民先打→草菅人命

[m4d3bug]

@bin456789
>“免费更新和免费使用和红帽开发者订阅是一样的东西”

原谅我的描述不准确，我说的一样的东西指的是使用感官，并不指代其完全一样。

[houtizong]

生成环境能乱来吗？ 哪个程序员不怕麻烦，反正只要有一点点不安定的因素，基本直接弃用

[m4d3bug]

@houtizong 所以在此之前，没有任何人兜底，靠社区用爱发电 CentOS，在我看来可不止“一点点”不安定因素

[cat9life]

你觉得当前的 CentOS 用户，和当前的 RHEL 用户群，是一个吗 （不考虑金钱费用的前提下）？我感觉使用 CentOS 的人都比较“懒”，一把梭把业务跑起来，碰到问题有解决方案（社区或者蹭 RHEL ）。然后放那就不管了..

[m4d3bug]

@cat9life +10086

[raysonx]

@cat9life
@houtizong
@m4d3bug
我觉得这个问题的矛盾在于，好多 CentOS 的用户虽然都是追求“稳定”的小公司和个人，但其实他们并不理解他们谈论的“稳定”是什么，而做 RHEL 的下游反而给了他们安全感，即使 CentOS 本身比 RHEL 更新慢、编辑参数不一样、缺包。现在的 CentOS Stream，虽然让他们用了更加接近之前的 RHEL 的版本，却丧失了做那种安全感，即使这个 Stream 版本更好。

说这么多也无法为相关决策的失败开脱。这种重大决策本来就应该做的浅显易懂，真不如当时就说 CentOS 8 将迁移到 RHEL 社区版。

[markgor]

@houtizong
就我接触过的 4 种人：

1 、开发、环境一脚踢：
宝塔面板、YUM/APT 大神：RHEL 是什么，CentOS/Ubuntu 不好吗，教程倾向哪种系统多我就用哪种。

2 、中小公司内部运维：
非特殊环境，最高只能使用 CentOS 6.2，CentOS 5.6 是他们主要的选择，CentOS 6.2 是他们最后的妥协。

3 、大公司运维:
给钱 RHEL 支持，有问题直接联系，社区版本根本不管。

4 、高级玩家：
密切关注此事，并借题发挥。


我不是专业运维，所以圈子比较小，
但我觉得，实际影响并不大....
只是被人借题发挥了.....

就像当年 oracle 收购 mysql，微软收 GitHub，IBM 收 RHEL
实际上最终社区版对大部分公司并没影响.....

[RickyC]

是就像麦当劳要改名金拱门那样吗？

[m4d3bug]

@raysonx 其实 Stream 的事，在宣布时已经有一年之久的 changelog 了，但尽管如此也还是没有太多人去看 changelog

[no1xsyzy]

讲个冷笑话
RHEL 社区版（ RHEL-CE ） ✘
RHCL ✔

@markgor 媒体才借题发挥，高级玩家选择 Arch Linux （滚动？我已经滚了快一年了 XD

[cubecube]

码这么多字，解释了个啥？是怕我们英文不好，没看懂 centos 官网的说明么？
真是一片良苦用心的话，沿用现在的模式，保留 centos stable 不就得了。
Ps，上个月，一个 home-server centos8 切 oracle linux，自动脚本执行完，最后挂了，起不来，索性换成 debian 一了百了了。

[Zhouisme]

RHEL 不论如何，只用 Debian，FreeBSD，Gentoo

[Zhouisme]

https://feng.si/posts/2019/07/centos-the-last-linux-distro-you-should-ever-consider/

[adoal]

那不就是相当于 Debian 系的 proposed-updates 么。确实不是 Debian testing 那个意义上的滚动发行。对于整个 RHEL 来说也不能算是 beta 版，大概可以看作是的 issue fix 的 beta 版。

不过呢，作为常年保持 Debian 随手升甚至 n 多次跨版本大升都没出问题的人，唯二两次升挂掉之一就是曾经开了 proposed，之后就再也坚决不开了。

[doyel]

@wangkun025 如果还并存，那 Fedora 能滚得更激进一点。。。

[wangkun025]

@doyel 激动和保守之间的界线并不清晰。Fedora 不能老是挡着 centos 的开发者吧。

[wxlg1117]

其实辩论什么公关失败傻的没傻用,看看原 centos 创始人都要重新再立一个山头这反应就知道不是好事了...