首先声明本人为红帽员工，但不是做 RHEL/CentOS 的，利益无关，本文仅代表个人看法，不代表公司观点。
当时“CentOS 8 将于 2021 年低结束支持并转向 CentOS 8 Stream，而 CentOS 8 Stream 是小白鼠版 RHEL”的消息同样在公司内部引起了很大的震动。红帽是个很大的公司，非相关团队的同事和你们一样都是在网上了解到的消息，一样对此表示震惊、失望。但就后来和相关同事、高管讨论得知，这本来是一个对社区和公司双赢的好事，却由于公司公关失败并被媒体添油加醋煽风点火，导致 CentOS 用户叛离，并对 RHEL 系发行版的声誉造成了十分抗投诉服务器恶劣的影响。
据我在公司内部了解到，红帽的本意是将 RHEL 的开发流程“开源”，并加快 CentOS 的 bug 修复速度。在 CentOS 8 Stream 出现之前，现状是这样的：
- RHEL 的源代码是公开的，但是开发测试流程都是在内部完成且不公开，公司外部人士是无法投入 RHEL 开发或测试的。虽然 Fedora 是社区驱动的，但 Fedora 作为 RHEL 的开发版本，相关内容进入 RHEL 的速度十分缓慢。
- 一个 bug 在 RHEL 被修复后，需要 RHEL 的测试人员进行测试，测试通过后对 RHEL 推送更新。而 CentOS 团队作为另一个团队，需要等待新版本进入 RHEL 以后，重新 build，再走 CentOS 的更新流程。这导致 CentOS 中 bug 的修复速度比 RHEL 慢几天至几个月。
而转向 CentOS Stream 之后，变成这样：
- 源代码及开发流程向社区公开，RHEL 的开发及测试人员将直接在 CentOS 进行开发测试，公司以外的人士也可以参与。
- 向 CentOS Stream 推送的更新是通过了 RHEL 测试人员测试后的版本，从开发流程上讲，CentOS Stream 的质量就是以前 RHEL 的质量，而以后的 RHEL 将变成 CentOS 的下游，将更加保守稳定。所以 CentOS Stream 并不是小白鼠版本。
- 多数 bug （除个别未公开的安全漏洞外）的修复将在第一时间推送到 CentOS，CentOS 将比 RHEL 更快地获得 bug 修复。
总而言之，这件事情让我感觉到红帽是好心办了一件坏事。作为一家软件公司，缺乏高水平的公关，被媒体和竞争对手往死里黑。
RHEL 竞争对手是 ubuntu 吗？
RHEL 多年前公司有一套，现在基本满是灰。
后来转了 CENTOS，实话说 CENTOS 和 RHEL YUM 源的版本都非常老旧，更新特别慢（当时听说是为了稳定...）
具体关系我也不清楚，只记得当时主管和我说，rhel 是红帽商用版本，但授权过期了其实和 centos 差不多，没服务了。
CENTOS 是 rhel 的社区版，rhel 有任何新东西都会丢去 centos 测试，看反馈。
我至今记得小时候去新华书店买游戏都能看到一盒红帽 Linux 放在一个很显眼的地方从来没有人动过
> 实话说 CENTOS 和 RHEL YUM 源的版本都非常老旧，更新特别慢
RHEL 作为企业版追求稳定第一，是很难上新版本的包的（企业软件经常会依赖旧版本包）。通常情况下在某个 RHEL 的主版本（比如 RHEL 7.0 ）发布后，大多数软件的版本就定死了，之后只会收到 bug 和安全更新，很少会收到功能更新。为了解决你说的问题，RHEL8 引入了 AppStream，比如对于 Python 而言会针对 Python 3.7 3.8 3.9 每个主要版本提供一个 AppStream，用户可以选择需要的版本，并在不升级主要版本的前提下一直获得 bug 和安全更新。
RHEL 的授权过期后就无法收到包更新了，且不再有技术支持，而 CentOS 的更新是社区负责的，需要自己切源。
好像没啥误解把？主要槽点就两个呀
1 是 CentOS 8 生命周期缩短
2 是 CentOS 变成滚动更新
这两个变动导致 CentOS 不再适合在企业内稳定部署使用了。
调整后，centos 和 fedora 的区别在哪里？
感觉慢慢的 centos 和 Fedora 可以合并了。
同问
懂了
redhat 不想自己测试了准备甩给社区
主要是因为下游变上游吧。
但听 lz 一说，rhel 的人分两拨，一拨开发 centos，一拨继续维护 rhel，好像看起来也还行。
LZ 把英文大小写拼得很对，看着太赏心悦目了
respect
不担心个毛。原来 CentOS 是 RHEL 下游，现在变成了它的上游帮它测试。这能一样吗？
这里的 CentOS 8 生命周期结束指的是原先的 CentOS 8 不再维护，原因是改变开发模式切换到 Stream 。Stream 一样也是 CentOS 8，由于开发模式转变导致不得不开新分支。我觉得需要明确的是 CentOS 8 Stream 的更新并不是测试版本，而是由原 RHEL 开发测试人员维护的稳定版本，理论上稳定性等同于之前的 RHEL 。
Stream 虽名为滚动更新，但其实和普通的滚动发行版不一样，只是不再区分 8.1 8.2 8.3 这些子版本而已。具体为什么不再区分子版本我没去了解，但能够确定的是进入 Stream 的内容都是要进入 RHEL 的，并不是那种一更新就容易挂的那种滚动版。RHEL 的主版本不变的情况下，ABI 是稳定的，个别场景下如果真的需要卡在某个子版本不升级，说法是后续会有解决方案。
不知道我这么解释明确与否。
建议先把滚动测试说明白
下游变上游
不是小白鼠是啥？
Fedora 才是真正的 RHEL 测试版，各种软件包新功能都是最新的。和 RHEL 的区别主要在于：
1. 支持周期很短（通常只有不到 2 年）
2. 不保证 ABI 的稳定，也就是升级某软件包后可能会破坏兼容性。
3. 进入 Fedora 的内容不见得最终会进入 RHEL 。
感觉你可能对使用 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 的商业用户们先在生产环境测试过的，现在反过来，自然很多人不爽。
最后一句，在考虑稳定性的公司上是不可能使用滚动发行版的，必须有大版本锁定机制才行，否则会出大乱子。
明白了，可是已经晚了。
我有什么理由不选择 Oracle Linux 呢？甲骨文官方提供了 CentOS 一键切换 Oracle Linux 的脚本 [https://linux.oracle.com/switch/centos/] ，还是原来 CentOS 的配方，还是原来 CentOS 的味道，无痛切换。
分歧就出在这。让 RHEL 的开发测试人员去开发测试 CentOS Stream，这个 Stream 版等同于之前 RHEL 最新版的质量，并不是所谓的小白鼠。使用最新的 CentOS Stream 就和以前使用最新的 RHEL 是差不多的，而且社区用户也可以来反馈 bug 贡献代码，一举双得，但外界普遍非要认为这是做小白鼠。
再举一个例子，RHEL 有编写的非常好（可以说是最好的之一）的用户手册，原先 CentOS 内部培训的时候，直接拿 RHEL 的手册即可，非常的详尽清楚。CentOS 自己的文档只有一个安装手册。
现在 CentOS 在 RHEL 之前，那部分功能可能就和 RHEL 不同，这事就麻烦大了。
> Stream 虽名为滚动更新，但其实和普通的滚动发行版不一样，只是不再区分 8.1 8.2 8.3 这些子版本而已
问下以后 RHEL 出 9 后，CentOS Stream 是搞一个新的 CentOS Stream 9，还是继续滚动？还是说 RHEL 以后也滚动？
明白了，是名字起错了，应该叫 RHEL-CE
另外在官网的博客文章中明确建议不要在生产环境使用 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 的定位就是一个用于开发测试环境的发行版，不能用在生产环境。
说白了，以前白嫖真香，现在不让嫖了，不爽。
这就是部分人的心态。
这可不是什么公关问题，明眼人基本上都看的出来。
会出新的 Steam，不会滚动到 9 。
关于你说的 CentOS 用户拿 RHEL 用户做小白鼠这一点很有意思，我作为一个技术人员之前没有想到。我这里面描述的这些是公司最初的动机，而这件事情所引起的反响已经远远超出所有人的预料了。我猜测公司今后可能根据反应做出一些调整，但我现在还不知道。
实际上据我 RHEL 的同事说基本就是把 RHEL 的开发测试流程搬到了 CentOS Stream，以前 RHEL 有自己的开发分支，说是开发分支其实也没错的，只不过不是传统上认为的开发分支或者开发版本。
另外你所引用的问句是有一个 and 的，这句话翻译为“如果你正在用 CentOS 8 作为生产环境并担心 Stream 版本不能满足需求”，并不是说 Stream 版不能作为生产。虽然我觉得作为社区发行版，以免责声明的角度都不会鼓励用户用于生产环境。
以后进入 centos 的，也不见得最终会进入 RHEL，对吧，毕竟是上游测试版。
其实这种都是商业决策，从商业道德上来说，比 Oracle Linux 这种自己正事不干，用别人辛苦测试和集成的代码做商业发行版抢生意的行为还是好一点的。
但是关键是 Redhat 的口碑太好，导致这件事情的反噬也很大。
现在卖 Linux 操作系统这个生意，现在是越来越难做。因为整体的趋势是上云，而云厂商都会提供自己的发行版（比如 AWS 提供了自己的 AWS Linux，虽然也是基于 CentOS 的）。高层们为了保住营收出这些招也很正常。
其实 RHEL 想坏名声，还有更狠的，就是搞乱 RHEL 的代码公开流程。因为 GPL 只是购买人有权利申请 GPL 格式代码，形式并没有做规定。
Redhat 可以只用光盘邮寄的方式开放代码，代码开放时只开发代码本身，所以的代码的版本历史、编译信息等都可以不给，社区就自己慢慢编译排错吧。
再狠一点，搞一些专有的软件包提供给商业客户使用，不开源，这个不违反 GPL 。但是社区拿到的版本永远没有这些专有软件包，也就和 RHEL 不可能完全一样。另外也不是所有的包都是 GPL 的，有些是 MIT 、BSD 、Apache 的，那就不开放代码，让社区自己去猜。
这事做的人多了，现在国内的银河麒麟、UOS 这些，哪个按照 GPL 提供了源代码？
毕竟很多人连 changelog 都不看就无脑跟着吹，少了个次要版本就各种自我高潮
支持，原本我也想叛逃 CentOS 的，这么说的话我得重新考虑下我之前的决定了。
另外请教下几个问题：
1. 如果直接在 CentOS Stream 上修复 bug 的话，那么那些宣称兼容 RHEL 的 Linux 发行版获取 bug fixes 也是从 CentOS Stream 获取是这个意思吗？
2. CentOS 8 Stream 的 Life cycle 是多长？网上似乎没有找到 CentOS 8 EOL 之后 Stream 的支持时长。
所有服务器都用 ubuntu 的飘过
那么问题来了
比如我现在有一个应用，依赖 libA 版本 1
那么当这个 libA 更新到 版本 2 的时候，CentOS Stream 会直接更新到 版本 2 呢，还是会同时维护两个版本？
如果是直接更新到版本 2，那这才是生产环境不能用滚动更新系统的根本原因。
CentOS/RHEL 不是新功能的实验田，通常情况下某个 RHEL 大版本发布后只会有 bug 和安全修复，我猜测你说的这种情况大概只会出现在 bug 修复无效等特殊情况吧。
并不是，centos 不是 rhel 特性的试验田，而是 rhel 的临门一脚，给 rhel 更新 /修复优先供给 centos stream
1，是的，临门一脚
2，stream 是五年多，之前回复过，没记错的话
软件包在红帽内部，本身就有专门为了次要版本和整个主要版本的两个版本，stream 应该只会拿到主要版本，而 RHEL 会有专属的次要版本软件包
我的意思是，比如 libA 有 1.x 和 2.x 两个不兼容的版本
CentOS Stream 会直接从 1.x 滚动到 2.x 么？
还是像以前一样
CentOS 6 是 1.x 并锁定大版本
CentOS 7 是 2.x 并锁定大版本
我的上一条回复不够明白，重新说一下
rhel 是不会动版本号的，因此 libA 更新到版本 2，rhel 的做法是 backport 到旧版本的小版本中去，centos stream 理应也是一样的做法。
再狠一点，搞一些专有的软件包提供给商业客户使用，不开源，这个不违反 GPL 。但是社区拿到的版本永远没有这些专有软件包，也就和 RHEL 不可能完全一样。另外也不是所有的包都是 GPL 的，有些是 MIT 、BSD 、Apache 的，那就不开放代码，让社区自己去猜。
让我想到了安卓的 Google Play Services
如果 CentOS Stream 不会锁定大版本，那就不适合生产系统试用
如果 CentOS Stream 会锁定大版本，那这个大版本的切换时机是怎样的？
你说的 libA 版本和 os 次要版本没有必然联系，centos 的做法是懒得维护软件的小版本，而 RHEL 是一直保持软件的大版本而采用小版本的更新
我知道问题出在哪里了
CentOS 现在的命名有问题
不应该叫 CentOS Stream 8 (绝大多数情况下这个 8 还会被省略）
应该叫 CentOS 8 Stream / CentOS 9 Stream
CentOS Stream 8 这个 8 被省略的时候，就很容易被联想到 arch 的更新模式
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 等稳定性不变，系统运行稳定性不好说，可能更好，更坏，或总体没什么区别。
这次变更如果算公关失误的话，其实命名方面造成很大困惑。不如 centos 原名称不改，增加类似 plus 版，advanced 版，Pro 版，max 版等等，这些命名套路手机公司可是玩的很六的。
修改社区中广为流传的概念本来就是风险很大的事，新概念传播(辟谣)没那么容易。
> 如果直接在 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 年。
我个人认为 centos / redhat 谁先于谁更新并不是这次变更争论的重点
而是很多人都以为 CentOS Stream (8)是类似 arch 那种的滚动更新
我的理解是 bugfix 优先给 stream，RHEL 和 stream 是同级别的，只不过是谁先用谁后用（和疫苗优先分配给冷链，医护人员一样）。并不是说 bugfix 还要从 Stream 拿
版本命名方面，Ubuntu 做的不错，兼具灵活性和清晰
毕竟很多人不看 changelog
这是 CentOS 自己的锅
谁叫他们自己很多新闻稿都写的 CentOS Stream，省略掉了版本号
有点像 Debian testing 和 stable 的关系吧，但那是从社区中来，到社区里去啊。
这里是从 CentOS8 Stream 里由社区测完了，再放商业版本的 RHEL 里去
不完全是，新闻稿这种东西对手公司也没少写
Fedora 才是真-小白鼠，不过就是 Fedora 也不是 Arch 那种滚动更新，而是一年一个大版本，每个版本支持会有个 1 年，期间会修 Bug 和安全问题，一般也没有大的 Feature 或引入大的 Bug 。
Fedora 有个滚动分支 Fedora Rawhide，那个激进至极，大小问题不断，一般每年会从中 branch 一个新的 Fedora 版本，稳定下来之后就是新的 Fedora 发行版本。
CentOS 是比 Fedora 稳定得多得多的，Fedora 正式版都相对温和，而且有相对完整的 QA，CentOS 就更不会多激进了。
一样不一样看 Red Hat 的反应就知道了 这种改变并不是好事情 现在每个版本发布都会有一个已知问题列表 变成 stream 了还会有么？
感觉就是变相强迫当前用户去买 RHEL 得订阅罢了
另外 RHEL 的订阅过期 可能会要求你回退到你买订阅的那个版本 而不是留在当前的版本
>感觉就是变相强迫当前用户去买 RHEL 得订阅罢了
RHEL 有 16 个免费的开发者订阅了解一下
>另外 RHEL 的订阅过期 可能会要求你回退到你买订阅的那个版本 而不是留在当前的版本
有白纸黑字吗？我怎么从来都不知道有红帽的人这样做？
并不是 Debian testing 和 stable 的关系。CentOS Stream 的大版本是不变的，只是在小版本上滚动。CentOS Stream 也不是 RHEL 的测试版本，而是已经通过质量测试的版本，只不过比 RHEL 付费用户早那么一点，我的理解是 CentOS Stream 就是以前的 RHEL （除了没有商业支持），而新的 RHEL 变成了 CentOS Stream 的下游。
你的理解是对的
> 我的理解是 bugfix 优先给 stream，RHEL 和 stream 是同级别的，只不过是谁先用谁后用（和疫苗优先分配给冷链，医护人员一样）。
赞同
我觉得吧，这事，
算了，看看大神们的想法
事实就是大部分选择 centos 的场景和用户,都是要求就一个字"稳"
谁要你修 bug 多块,谁要你功能多新
需要这些直接用别的发行版了
当你抛弃自己最具特色的点之后,那么用户抛弃你也是一件很正常的事情
事实上，sorry，bug 修不快≠稳，另外 Stream 没有 break change 没有你所谓的“功能多新”，不看文档不看 changelog 自己给自己挖坑也是一件很正常的事情
RHEL 有 16 个免费的开发者订阅了解一下
开发者订阅之前只能用来开发 并不能用来企业内部跑生产的 也是 CentOS 政策公布后 RedHat 才更新的政策 开放了面向小企业的选项 如果之前你知道谁在用开发者订阅跑公司内部生产环境 你要意识到这个是违反用户协议的
有白纸黑字吗？我怎么从来都不知道有红帽的人这样做？
可能政策有修改 但是这个情况以前应该是存在的 也是相关的人说的 所有合同应该是独立的 不知道楼主是归属于 RedHat 开发团队还是销售团队 如果是销售团队的话可以再确认下 可能现在的政策已经改变
>开发者订阅之前只能用来开发 并不能用来企业内部跑生产的 也是 CentOS 政策公布后 RedHat 才更新的政策 开放了面向小企业的选项 如果之前你知道谁在用开发者订阅跑公司内部生产环境 你要意识到这个是违反用户协议的
所以你要怎么用，选择权在你自己手上，没有人强迫你。
>可能政策有修改 但是这个情况以前应该是存在的 也是相关的人说的 所有合同应该是独立的 不知道楼主是归属于 RedHat 开发团队还是销售团队 如果是销售团队的话可以再确认下 可能现在的政策已经改变
闻所未闻，建议找相关的人要说法
CentOS/RHEL 的稳是指在保持 ABI 稳定（不会有破坏性更新造成兼容性问题）的前提下，能够长时间地获取 bug 和安全问题修复，而不是长时间不更新。RHEL 的策略是，如果某个软件包 bug 在开源社区上游被修复了，老版本没人管，红帽就会把这个修复移植（ backport ）到老版本，不需要用户升级到最新的软件包，因为最新版可能有破坏性更新。
强制降级是不可能的。大多数开源软件都是 GPL 协议的，这个协议保证了某个软件的版本一旦授予了某个用户的使用权，是不可撤销的。
嘛...感觉我服务器的 centos7 估计还能用个十几年吧....
说白了就是 Centos Stream 要变成 RHEL Beta，想让更多人测试 RHEL
但 CentOS 的目标群体只是想要 RHEL 的免费替代品
CentOS 剩下 Stream 后，他们会转向 Oracle Linux 或者 Rocky Linux
但红帽放宽了免费限制，这部分人可能会用 RHEL 稳定版
也是很好的处理办法
我觉得可以把 CentOS Stream 认为是 RHEL 的 Pre-release 版本而不是 Beta 版本，因为它确实在公司内部的定位不是测试版，而是和之前的 RHEL 同等质量。这样的好处是一方面能让社区也参与进 RHEL 的开发与反馈，另一方面能够极大的加快 CentOS 的 bug 修复速度，减轻 CentOS 的维护压力，一举双得。感情上确实会给人 Stream 版是测试版的感觉，但实际在质量上并没有降低。
如果 RHEL 是 release,你这个 pre-release 不就是 beta 么...
为什么还觉得你们的公关失败?
你们的公关失败大概在于过于直白不会绕弯弯
但是我觉得既然就是一个事实上的 beta,坦诚公布说出来挺好的
别忽悠别人以为很稳真用在生产环境了结果嗝屁,反过来更毁声誉
>说白了就是 Centos Stream 要变成 RHEL Beta，想让更多人测试 RHEL
原谅我的杠，Stream 更接近 RHEL λ而不是 RHEL β，RHEL 有自己的β，并且这个β不是 fedora
>CentOS 剩下 Stream 后，他们会转向 Oracle Linux 或者 Rocky Linux
Oracle 服务一样收费，免费更新和免费使用和红帽开发者订阅是一样的东西。
Rocky Linux 能活多久，会不会重蹈 CentOS 被收购前的故事，这又是另一个故事了。
>如果 RHEL 是 release,你这个 pre-release 不就是 beta 么...
真不是 beta，请看/>bugfix 不快都能算稳的做法，你确定你所谓的“稳”不是更毁声誉的做法吗？
我已经把 CentOS Stream 以及 RHEL 的开发模式说的很明白了，CentOS Stream 的软件质量相比之前是没有降低的，而且更新速度加快，红帽并不依赖于 CentOS 社区来做测试，而且 RHEL 本身也有自己的 Beta 版本。如果您还是认为 CentOS Stream 是测试版我也没办法了。
不是所有的 bug 都是严重到让系统无法运行
对线上环境来说,不可预期才是更要命的
如果这个 bug 已经知道,但是并不影响我的业务,或者说我的业务不涉及这个 bug,那修复与否就并不是一个很紧急的情况,这就是我所说,并不在意你修复多快
如果不影响您的业务或者担心不可预期，您不更新不就得了，每个软件包都是有 changelog 的。这个 Stream 版本几乎是等同于之前用最新版 RHEL 的，每个软件包的发布都是有通过测试的，如果这都不可预期那就只能换发行版了。
>不是所有的 bug 都是严重到让系统无法运行
>对线上环境来说,不可预期才是更要命的
1. 所以你要“可以预期”，应该做的是去看看 changelog，做好克隆测试。
你只需一个软件一个软件 update，所以，“不可预期”的是没看 changelog 的你，还是 CentOS Stream 呢？还是盲信别人开源社区分发，以为在 RHEL 后但没有任何人兜底的说法呢？
你不会还指望开源社区分发的经大批量硬件测试？难道就是“可以预期”吗？
https://mp.weixin.qq.com/s/heX7Qtc7Fizx43EgGkIiMQ
你要知道，你拿到的更新与红帽官方分发的基本没有区别，并且直属于红帽人员维护而非 CentOS 社区分发。
加快了 CentOS 的 bug 修复速度的同时也会带来更多 bug，哈哈。
绝对没 bug 的“生产可用”的东西怕是不存在的~
修复 bug 的时候引入新的 bug 是有可能的，但肯定总体上 bug 数量是越来越少的。虽然我觉得你这句话应该也是半开玩笑的