• #1沟通不畅
• #2件事变了，我不喜欢变
• #3生命周期承诺发生变化
• #4商标归Red Hat所有
• #5 CentOS流支持仅5年
• #6Centos Stream会比RHEL更不稳定
• #7 你不是在寻找机会来改善这个生态系统
• 结论

改变是困难的。很难用一种有意义的方式来解释这种变化。当有人向你解释改变时，或者当你解释改变时，你不会感到沮丧。我们都是人，所以请耐心点。但是，在你生气之前，请读一下这个。我和其他人一样，一直在Twitter、Reddit和HackerNews上冲浪。我收集了一些主要的投诉，我想解决每一个问题。

 

在我开始之前，我在红帽工作，已经在这里工作了9.5年。我从来没有错过过薪水。从未。一次也没有。它总是在发薪日出现。这让我很高兴，但你在某个地方工作并不意味着你在门口检查你的大脑。我不断质疑我们在做什么，并得出自己的结论。工作关系和其他关系一样，必须不时地进行评估。像任何理性的人一样，我时不时地这样做。我也以说出自己的想法而闻名，即使真相很难听到。我认为这使我成为一个体面的外交官，可以进行强硬的对话。也就是说，这些是我的观点和想法，不是红帽子的。

 

让我们在这里进行一次艰难的谈话。对于CentOS到CentOS流的变化，有很多抱怨和一些乐观。让我们仔细分析一下我认为合理的投诉：

#1沟通不畅

正如我在引言中所说的，消息传递很困难。我们都是人，即使是红帽子的人。我觉得这有没有可能沟通得更好？当然。也就是说，我看到很多人对Rich Bowen（CentOS项目将焦点转移到CentOS Stream）以及Chris Wright（CentOS Stream：为企业级Linux构建创新未来）投下了仇恨，他写了两篇主要的文章来传达这一变化。

这不公平。他们都是站起来的人。我是说真的。我在很多月前见过里奇，因为我读过并使用过他的Apache文档。我走到他跟前，紧张地说了声谢谢。他比大多数人更相信开源。他不仅使用，而且贡献。重要时刻。克里斯也是。我从来没见过比Chris更喜欢开源的人。说真的，当你听他说话的时候，你能看出他想得有多深。他致力于此。如果Red Hat改变了他们对开源的立场，我100%肯定这两个家伙都会离开。这里没有阴谋，和这些人没有。我对他们两个人都很了解，我对他们两个都很信任。当这些人站起来说些什么的时候，就他们所知，这是真的。但是，世界在变化，战略也在变化。

 

此外，这是一个很大的变化，许多人都参与其中，来自社区和红帽。事实上，我写这个博客是因为我对贡献有偏见，我相信我们所有人都有责任有效地传达这种变化。Red Hat会从这条信息中生活和学习吗？是的，我想是的。

我唯一的问题是，请向红帽表示善意，看看这一变化如何。给它一个机会。我相信从长远来看，它会更好，更具可持续性。

#2 事变了，我不喜欢变

这让我想到我听到的下一个最常见的抱怨。我明白了。请试着把你的愤怒从这个博客讨论的其他事情中分离出来，这是不必要的改变直接导致的。每次我在工作中经历一次重组，换了角色，换了公司，买了房子，生了孩子，或者重新装修了房子，我都有一种“谁动了我的奶酪”的感觉。一切都是一种方式，现在是另一种。对变化感到恼火是合理的，但问问自己，这可能有什么好处？

已经有人提出了一些改变的好处，我同意。我将总结一下我从三个不同来源看到的好处[1][2][3]，并补充一些我自己的想法：

 

• 它使RHEL开发更加透明和可靠[1]——历史上，一旦RHEL从Fedora发布，它就变成了一个黑匣子。Red Hat试图通过创建我们与客户和合作伙伴共享的Alpha和Beta版本来解决这个问题。我们花费了大量的时间/精力/金钱（作为一名PM，我必须回答关于Alpha/Beta的一系列问题），但实际上几乎没有人使用它们。又贵又痛。CentOS Stream将改变这一点。现在，任何CentOS Stream用户都可以访问并参与此过程。这太神奇了。
• 它为ISV和开发人员提供了一种方法来提供修复和功能[1]——即使合作伙伴和客户使用beta/Alphas，他们也很难提供更改。没有一个分支/存储库是公共的。记住，源代码git.centos.org基本上是只读的，来自RHEL的下游代码。这就是红帽子遵守GPL的方式。从技术上讲，我们超越了这一点，因为法律只要求我们向客户提供代码，而不要求我们为BSD/Apache/etc许可代码提供代码，只要求归属。尽管如此，这不是一个社区，而是一个代码库。RHEL代码更类似于Android的只读，而不是Kubernetes或Linux内核的读写社区。有了CentOS Stream，一切都变了。
• 它为社区提供了一种提供反馈的方式[1]——合作伙伴有专门的人，称为合作伙伴经理，这些合作伙伴经理在历史上帮助合作伙伴提供反馈并推动对RHEL存储库的更改。Community CentOS用户（甚至Fedora用户）从来没有办法驱动RHEL minor版本的更改。Fedora将变更驱动到主要版本中，但是有一个带有次要版本的黑盒。这给了莱尔一种与上游社区隔绝的感觉。使用CentOS Stream，这一切都变得透明。这是一个崇高的目标，我真心相信这会更好。
• 移动到滚动的Stream是移动到云原生世界的结果[2]——这是一个有趣的过程，我没有想到这一点。这是容器世界的结果。我一直理解容器的价值，当你将更新吸收到你的应用程序依赖中时，它可以控制，但是这也意味着一个不断变化的操作系统更新流已经不再重要了。既然容器控制了更新的发生时间，为什么还要关心它是一个滚动流还是发布了版本号呢。做一个“podman构建”在RHEL中的小版本发布之后，直到下一个dot版本才再次更新-砰，你有一个非常类似于下游CentOS流的东西。滚滚的小溪让我们走得更快更自由。
• 不要低估与Red Hat engineering直接合作的价值[3]——正如Neal所指出的，CentOS始终是一个社区驱动的项目。Red Hat将其品牌延伸至CentOS品牌，可能错误地认为这是一个资金充足的项目，而事实上它从来就不是。就像我见过的每一个社区驱动的项目一样，有比时间和精力更多的需求和渴望。维护社区驱动的项目并不完全像非营利组织，那里弥漫着一种压抑感，因为它让人觉得你从来没有取得足够的进展，更糟糕的是，你觉得你没有得到那些从慈善机构受益的人的赏识。CentOS stream将直接与Red Hat engineering集成，提供到RHEL的直达线路。这些人的报酬是做这项工作，使RHEL更好的服务。这使激励措施更加协调，使其更具可持续性，但更重要的是，它在红帽工程和社区之间创造了一个自然的沟通渠道，坦率地说，这是不存在的。这将使RHEL engineering更贴近用户需求的实际情况，并为社区提供一种连接感。这是一个非常积极的举措。
• 不要低估了这种力量，因为它吸引了上千位新的聪明、积极的超级用户，他们倾向于贡献，而不是消费[4]——我还没有看到有人强调这种价值。Red Hat有成千上万的解决方案架构师、顾问、工程师、产品经理、产品和技术营销经理以及传道者。他们中没有一个人有动机谈论CentOS，更不用说对它有贡献了。我已经9年没用CentOS了，因为我喜欢拿薪水。当顾客想和我谈CentOS时，我很生气。我从来没有贡献过。我并不讨厌它，但我一直认为它是一个洗-它获得了红帽技术的用户，但这些用户很少贡献。我甚至从未见过CentOS用户提交RHEL问题（又名Bugzilla）或在Twitter上为CRI-O、Podman、Buildah、Skopeo或任何我在Red Hat工作的东西ping我。这些用户甚至不在我的雷达上。大约一个月前，我安装了CentOS Stream，这样我们的团队就可以在Podman开发上与客户协作。我不必为把他们指向下游重建而感到肮脏。对于上游重建，反馈对RHEL都是直接有用的–特性请求、bug等。这是非常强大的。

[1] ：吉姆·佩林的《关于CentOS Stream的思考》（@BitIntegrity）

[2] ：不受欢迎的观点：克里斯汀·科恩托普（@isotopp）认为CentOS改用Stream一点都不坏

[3] ：不要低估Neal Gompa（@Det\u Conan\u Kudo）与RHEL engineering的直接关系的价值

[4] ：我自己的想法。

 

#3生命周期承诺发生变化

投诉是CentOS wiki最初说CentOS 8将在2029年之前得到支持，而这似乎特别离谱，因为CentOS 6最近被弃用。我完全理解，如果你已经下定决心要用这个的话，你会为此感到不安，但是想想你为什么会感到不安？让我们从开源产品管理的角度来深入研究这个问题。据我所知，我是第一个尝试在创造和获取价值的背景下谈论开放源代码的人（博客/演示：使用开放源代码进行产品管理的微妙艺术）–这两个概念在初创企业中非常常见。

让我们在产品管理的第一原则中讨论这个问题。一些免费的东西满足了你的需求（市场问题）。这种解决方案并没有降低RHEL（底部暗红色区块）的开发成本，同时也给red Hat获取我们创造的一些价值的能力带来了价格压力。这是一个长期的问题。科技公司有个肮脏的秘密，不是为了赚钱，而是为了超越竞争对手。赚稳定的钱对一个沙砾公司来说是好的，但对一个科技公司来说却是致命的。你要么生要么死。Red Hat公布连续69个季度增长，然后计入IBM的收益，并在IBM的云业务部门内继续增长。这不是巧合。这不是运气。我们必须继续关注增长。我们成长或死亡，就像任何科技公司一样。

大家都知道CentOS给RHEL带来了价格压力。让我们都直视对方的眼睛讨论一下。许多CentOS用户猜测这就是Red Hat做出这一改变的原因，但让我解释一下这不是一个阴谋。如果成功，CentOS将通过在社区中推广RHEL来降低其开发成本。有了更多的眼球，所有的虫子都很小。但是，这并不能消除价格压力。没错，如果CentOS Stream成功了，我们还得和自己竞争赚钱。为什么？因为CentOS流可能会像CentOS一样非常稳定。那很好。这意味着作为RHEL团队的产品经理，我需要专注于为客户提供他们所需要的。每一天。单身。一天。我必须关注我们的团队（Podman和container images）为RHEL和OpenShift客户提供价值的速度。

 

接受挑战。我仍然会确保RHEL提供CentOS Stream没有的价值。对我来说，它与CentOS Stream无关，而与专注于在买家问题框（上图中的浅红色和粉色框）中创造价值有关！

 

Red Hat是否可以等到CentOS 9改变这个生命周期？当然，我同意这样做会减少麻烦，但我们需要CentOS Stream社区的这些人。专有工程是一个零和游戏，改变这种局面的唯一方法是进行社区驱动的开发，在那里，成本在受益人群中社会化（另请参见：为什么Red Hat要投资CRI-O和Podman）。任何对CentOS Stream稳定性的抱怨都必须从稳定CentOS下游的支出角度来看待。没有下游的担忧，上游会变得更好。工程成本的零和部分向上游移动，并变得社会化。这有效地增加了CentOS Stream非常棒的可能性。

 

#4商标归Red Hat所有

这是一个敏感的话题。有人会说红帽不该碰CentOS。喝啤酒的时候，我可以相信这个论点。在Red Hat获得CentOS商标时，我正在做销售。有些人讨厌它，有些人喜欢它。我对此一直保持中立。我觉得它是OpenStack现有的最好的开发平台，这在当时是个问题。在OpenStack上工作的红帽团队需要比Fedora更稳定的东西，因为他们对操作系统开发不感兴趣，他们感兴趣的是在操作系统之上构建一个平台。那是一个很难解决的问题。Fedora不是答案，因为Fedora不是RHEL次要版本（又名dot版本）的上游版本。我敢肯定有些人想过向RHEL释放一个上游，但这将花费数年时间，OpenStack正在以光速移动。所以，红帽收购了CentOS。

再说一次，让我们都直视对方的眼睛，像成年人一样谈论这件事。一旦红帽触及CentOS品牌，就再也无法让它自由了。永远都会有一种“红帽拥有它”的观念——这将永远有利于CentOS品牌，也永远会给红帽带来成本。在你怒气冲冲地关上笔记本电脑之前，让我解释一下。

首先让我们谈谈红帽给CentOS品牌带来的价值。在Red Hat获得分数并开始向贡献者付费之前，人们总是担心这个项目总有一天会失败。还记得2009年格雷格·戴维斯失踪一段时间人们都吓坏了吗？是的，这就是我要说的。有许多类似的事件，更新缓慢，重建新版本的时间比预期的要长，等等，但是，当红帽接管，所有这些担心都消失了。这让很多Red Hat客户不再担心在CentOS上运行开发、测试甚至生产工作负载，因为他们觉得不需要支持。

有一个几乎没人能理解的大问题。RHEL更新流具有巨大的价值主张，大多数人认为CentOS更新流是由同一个人构建的，或者至少是可以与构建它的人进行通信的人。老实说吧。但是，CentOS中的更新从未由RHEL工程团队生成。事实上，我团队的包装工从来没有，从来没有和CentOS的人谈过，CentOS的人也从来没有和他谈过。知识没有转移。CentOS更新是由一些社区成员生成的，他们重建了CentOS。不要紧，全世界都认为这是“红帽的更新”-我全心全意地知道。这是无法挽回的。从未。如果我们让这些痕迹消失，其他一些人就会发起重建，并在社区中获得这种价值。红帽公司不想放弃这种价值观是公平的。

 

第二，当Red Hat收购CentOS品牌时，我们自动产生了成本——永远。即使只是回答关于我们如何把CentOS还给社区的问题，也不要修补它。我记得当我是一名解决方案架构师，收购CentOS时，我的客户期望我告诉他们CentOS的价值。如果你仔细想想，那完全是疯了。为什么一个销售人员会进来告诉你一个免费项目能带来的价值？捕捉价值是很好的，但询问Red Hat是我们的成本。永远永远。我们总是要回答问题。这是一个奇怪的一个，老实说，我不认为任何人都可以预见有多贵。如果发生了成本，就需要获取价值。从价值的角度来看，CentOS上游可能是净中性的。这将降低RHEL的开发成本，但会产生销售成本。这总比净损失好。

我真的很理解为什么这个会让人发疯，但我也理解为什么红帽会因为把这些东西还给社区而心痛。开源是一项艰难的事业。

#5 CentOS流支持仅5年

这是一个有趣的问题。这是一个公平的批评，说实话，当我们宣布这个消息的时候，我并没有把它内化。公平地说，这与Canonical对ubuntults的作用基本相同。你为下一年的更新付费。这有很好的逻辑。如果你要做那么长时间的事情，那可能是成本/收益分析，而不是上游开发。也就是说你是在赚钱。在产品管理中，我们讨论了创造价值和获取价值这两个概念。您可能没有意识到的是，无论您在下游CentOS上运行什么样的工作负载，都在为您的业务创造价值，尤其是在6-10年。此外，您可能会为在下游CentOS上运行的服务收费，并获取价值。这是一个漏洞百出的价值链，是不可持续的。

 

我的意思是，我承认，我是一个懒惰的系统管理员的心脏和博客，维基，门票系统运行了十年前，所以这不是100%的真实。不是每个人都在赚钱，但你明白了。这是RHEL价值获取的关键领域，在这里收费对我来说没有错。感觉很公平。无论是Ubuntu还是suse enterprise linux，都没有免费提供的、高度促进的下游重建，这些重建都由销售上游产品的公司提供10年的支持、建造和支付。这感觉真的很疯狂，对吧？

 

与生命周期抱怨相切的是，Red Hat应该等到RHEL 9才能做出这样的改变，我明白为什么人们对期望的改变感到愤怒。也就是说，在2024年之前为CentOS Stream 8提供维护服务的成本仍然是0美元。另外，请记住，当你以0美元的价格运行某个东西时，你要对它承担全部责任。有了开源，你就可以随心所欲地使用它。你没有被困住。这是开源的力量，也是责任。

 

这场为期五年的支持辩论实际上是关于价值创造和价值获取的——什么应该免费赠送，什么应该收费。这是严格的商业决定，尽管我知道这很烦人。我不是那种喜欢“责任肥皂盒”的铁杆自由主义者，但我在CentOS空间看到了问题所在，在Linux容器空间中更是如此。公司以0美元的价格消费容器镜像，却没有意识到，如果上游项目消失或决定改变方向，他们需要具备构建/重建这些镜像的专业技能。有一次，我和一个想搬到UBI的合作伙伴谈过，但他们不知道如何移动一堆软件，因为他们只是从上游消耗容器映像，而不知道如何重建它们。他们向客户销售这种解决方案。让它沉下去。这是云原生世界的一个严重问题。您必须无情地跟踪和衡量消耗上游依赖关系所带来的风险。

 

当你使用像CentOS这样的社区开源软件时，不管你意识到与否，你都会成为像我这样的产品经理。我的意思不是不敏感，但是花0美元买CentOS而不是买RHEL意味着你要对生命周期负责，即使其他人为了你而让你的生活更轻松。你只有在支付0美元并且没有贡献者的情况下才处于困境。

 

#6 Centos Stream会比RHEL更不稳定

有一种看法认为，CentOS流将比下游CentOS流更不“稳定”。这可以被重新表述为：“这让我很生气，因为我总是依赖付费RHEL用户来吸收这些更改，测试它们，并为我归档bug！实际上，这一举动基本上是交换谁先得到改变，但改变本身从来就不是“不稳定的”。假设这些改变是不稳定的，本质上是一种阴谋论。这就是原因。

 

如果Red Hat用一堆不稳定的实时测试让RHEL用户感到不安，那么Red Hat怎么会有付费客户呢？事实上，每一次dot发布，RHEL用户都在毫无问题地吸收这些变化。这怎么可能？你要蓝色药丸还是红色药丸？

事实是尼奥，RHEL，从来没有真正的点释放。不是传统的Unix编号。RHEL一直非常类似于主要版本中的滚动版本。随着RHEL8的推出，我们用AlwaysReadyRHEL使这一点更加明确，只是很少有人理解它。多年来，我们一直鼓励客户和合作伙伴不要把车停在dot发行版上。我们总是告诉他们架构中内置了前向兼容性，但他们从不理会。我真的认为这来自于其他软件供应商对他们的培训。RHEL的稳定性总是来自于它的体系结构，现在这已经通过测试和选通得到了验证。

 

首先，让我们从架构开始。许多供应商不遵守语义版本控制。莱尔知道。如果您不想阅读语义版本控制（SemVer）页面，那么三位数的版本号在软件中非常常用。它是这样工作的。给定版本号主次补丁（例如Podman 2.0.5）：

• 进行不兼容API更改时的主要版本
• 以向后兼容的方式添加功能时的次要版本
• 修复向后兼容的错误时的修补程序版本

RHEL中的软件可分为四个兼容性级别。如果您从未听说过或不明白，请查看：Red Hat Enterprise Linux 8:Application Compatibility Guide。RHEL中的所有关键软件（如kernel、glibc、openssl）都处于兼容级别1或2，这意味着它们在主要版本中是二进制兼容的。换句话说，对兼容性级别1或2软件的更改属于修补程序的类别，而不是主要或次要更改（当折扣没有破坏兼容性时，有一些次要的例外情况）。RHEL dot版本增加的主要原因是兼容性级别3和4中的一些更高级别的软件可以更改。rheldot发布版不过是一堆在某一天捆绑起来的补丁，经过质量工程（QE）测试，并标记在一起。

CentOS Stream不会改变这一点。它的体系结构必须遵守这些API/ABI对前端运行RHEL的承诺。

怎么可能不呢？如果CentOS Stream偏离了这些规则，它就不会是RHEL dot发布的上游。RHEL的稳定性从体系结构、应用程序兼容性承诺和后移植开始。

 

第二，让我们谈谈测试。你不能通过测试来摆脱糟糕的代码（设计、糟糕的程序员等等）。RHEL从非常高质量的代码开始，并限制可以被管道接受的任何更改的变化。每一个变化都建立在上一个稳定版本的基础上。这是使RHEL稳定的基础。即使有了这个过滤器，每一个变更都要经过严格的测试和质量工程（QE）。

 

人类做QE，这提高了稳定性，并给开发人员提供反馈，而自动化测试验证了回归没有出现在代码中。自动化测试本身并不一定使软件更稳定，它允许团队在保持同样稳定性的同时更快地移动。换句话说，门控测试是用来捕捉以前坏过的东西的。它们可以防止重大缺陷在提交前重新进入软件，但我们也要公平对待CI/CD的限制。

 

CI/CD从未捕捉到任何软件中超过一小部分的bug（即使是100%的代码覆盖率）。自动化测试计划的神奇之处在于，团队可以更快地移动、中断和修复问题，同时保持质量。他们可以快速添加新的测试，这样团队就不会一次又一次地破坏相同的东西。自动化测试之所以有效，是因为有一个隐含的假设，即事情在最薄弱的环节就破裂了。测试验证了那些最薄弱的环节没有再次破裂。这些都不会随CentOS Stream而改变。Brendon Conoboy在这篇文章中很好地解释了CentOS Stream所经历的多重测试和QE：RHEL是如何产生的。CentOS Stream基本上总是就绪的RHEL。Stef Walter带着这个博客走过了通往这个地方的愿景和旅程：CentOS Stream是持续交付的。

有人认为CentOS流不会稳定，因为它没有经过测试，或者它是“beta-RHEL”，这显然是错误的。不要听布伦丹、斯特夫或我的话，他们都在RHEL团队工作，听CentOS的一位名叫卡尔·乔治的撰稿人说：“是的，是的。事实上，大部分都要测试两次。所有发布到CS8中的东西都已经通过了RHEL8的内部测试以及公共t泷u功能测试套件。

 

历史上，如果一个bug通过了RHEL选通测试，它就会被下游CentOS自动地、天真地发现。今天，如果一个bug通过了CentOS流门控，那么它很可能会在RHEL中自动地、天真地被发现。这有效地交换了更新流中的RHEL和CentOS。如果RHEL用户以前没有得到不稳定的更改，那么没有理由相信CentOS Stream用户现在会得到不稳定的更改。

 

RHEL团队不需要CentOS Stream的公共Beta测试人员，我们需要社区成员来帮助推动下一个很酷的RHEL功能。RHEL-Alphas/beta很少使用，也从来不是稳定性的关键成分。稳定性始终来自于体系结构、高质量工程（开源）、后端端口、1级和2级软件的ABI/API兼容性以及验证测试的组合。我们的竞争对手从来没有做到同样的事情，因为他们拒绝做同样水平的工作。后端口是。不是。很有趣。让我们都诚实点。但是，消费起来超级方便。CentOS Stream用户仍然可以运行yum更新，而不必担心引入破坏性的更改。对于大多数用户来说，CentOS流的稳定性应该与下游CentOS流的稳定性相同。这应该主要是一个非事件。你的愤怒可能源于不理解这一点。

#7你不是在寻找机会来改善这个生态系统

从生态系统的角度来看，RHEL和CentOS已经成了一对。当Red Hat收购CentOS时，这一点尤其明显，但您并不是在寻找改进的机会。让我从我的角度举个例子。

 

Red Hat工程中的容器工具团队（Podman、Buildah、Skopeo、CRI-O、Red Hat Universal Base Image）发布了我们的主要应用程序流（容器）-工具：rhel8)大约每12周一次。我们比RHEL的大多数子系统团队行动得更快。我们的上游项目仍然是年轻的工具和添加功能非常快。我们的客户渴望得到最新版本的Podman。通常情况下，我们的客户甚至在一周前就很乐意访问新版本的Podman，尤其是当他们想要一些杀手级功能时。历史上，我不得不让我们的RHEL客户使用Fedora（我很喜欢），但是配置常常不同于RHEL（默认情况下是cGroupsV2）。更糟的是，我们的团队没有承诺Betas。由于我们每12周发布一次，Beta版已经很旧了。这意味着，我的客户不得不等到RHEL dot发布，这很痛苦。

 

在RHEL8.3发布之前，我能够在一个看起来与RHEL非常相似的框上共享配置的Podman2.2.5（没有cgroupsV2，相同的注册表配置，等等），而在RHEL8.3发布之前的几周。这给了我们用户反馈，将用于我们下一个12周的版本，以及RHEL8.4。历史上，我们必须等待反馈，直到RHEL8.4退出。这是非常痛苦的，因为上游的Podman团队进展如此之快，而且上面的版本从来都不是最新的。通过CentOS，我们的问题为我们的团队和客户都得到了解决。

 

此外，让我提出一个想法。每个项目都在挣扎的地方，就是文档。我不断地向我们的文档人员提供用户故事，他们不断地对它们进行排序、排序并尽可能地完成它们。想象一下，如果我们可以将容器指南（构建、运行和管理容器）移到上游，让CentOS Stream社区贡献文档？这将是惊人的和社会化的发展成本为我的团队。这是一个具体的例子，说明了如果我们大家共同努力的话，将会产生的各种想法。

 

寻找机会，而不是挑战。

结论

这种改变对某些人来说是困难的，对此我有同情心。知道我们在倾听。我正在收听Twitter@fatherlinux。我相信还会有更多的愤怒，但希望这种观点能帮助人们看到好处，也许能更好地理解为什么会做出这些改变。给它一年时间，让我们看看结果如何。这真的是我们所有人的责任。我想给你留下一些有趣和悲伤的东西。

 

让我们从搞笑开始。很明显，有人花时间制作了这个网站：中心.rip. 我不会撒谎，我看到的时候真的笑了。我是说，真的很难。我不介意有人拿这个零钱胡扯。一切都是公平的爱和开源。这很有趣。

 

现在，让我们谈谈一些悲伤的事情。有一个更改.org请愿书（不要把CentOS当作上游的RHEL来摧毁），我认为这是在线上的，因为这是为了野生动物被杀死或雨林被摧毁之类的事情，但没关系。我对人们的愤怒和表达没有任何心痛，但我确实对人们将这种变化与《查理周刊》枪击案相比较有意见。我所看到的这一点只是对被谋杀者的不尊重。感觉人们只是在试图找到传播病毒的东西。

 

现在，叙利亚的孩子们被炸死了。如果你正处于一种情绪状态，你有冲动去比较自由软件的改变和大规模的谋杀，请把你的精力和金钱花在一些真正有助于世界的事情上。我敦促你向自由缅甸游骑兵队捐款。他们向有需要的人提供食物和水，即使在战争地区，正常的非政府组织也不会也不能运作。这是一个问题的规模查理周刊，或全球变暖，或毁林的亚马逊。不要轻易作这些比较。

 

最后，我并不是要消除你的愤怒，但转到CentOS Stream实际上有三个命令（我如何将CentOS Linux 8安装迁移到CentOS Stream？）。我知道迁移服务器很烦人，即使移动非常简单，但请结合实际情况。CentOS的这一变化将导致你做一些你可能不想做的事情，但有很多潜在的积极因素，我希望你能专注于这一点，并试图帮助它变得更好。

 

原文：http://crunchtools.com/before-you-get-mad-about-the-centos-stream-change-think-about/

本文：http://jiagoushi.pro/node/1469

讨论：请加入知识星球【超级工程师】或者微信【it_training】或者QQ群【11107767】