【操作系统】在你对CentOS Stream的改变感到愤怒之前,再想想

intelligentx 提交于 周三, 01/27/2021 - 16:35
SEO Title
Before You Get Mad About The CentOS Stream Change, Think About
  • #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】

Tags