跳转到主要内容

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

5星评论
没有投票
Last modified
星期三, 一月 27, 2021 - 19:13
  • #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】

Article

标签(Tags)

企业架构(35) 数据分析(35) Power BI(32) 微服务(31) 微服务架构(30) Data Analysis(30) 商务智能(30) BI(30) 认证考试(30) 微软认证(30) DA-100(28) 应用安全(27) 考试题(26) 物联网(25) 敏捷(25) Enterprise Architecture(24) 试题(20) 首席架构师(19) 首席架构师推荐(19) 云计算(19) 网络安全(18) 技术架构(17) 机器学习(17) 试卷(17) SAFe(16) 大数据(15) Kafka(15) 规模化敏捷(14) enterprise security architecture(14) 企业安全架构(14) 前端架构(14) microservice(13) 业务架构(13) 数据架构(13) IOT(13) 安全运营(13) 容器云(12) 敏捷建模(12) 服务网格(12) 数据分析师(12) 事件驱动架构(12) 区块链(12) 数据安全(12) 数据湖(11) 应用架构(10) AWS(10) 数据科学(10) 人工智能(10) Kubernetes(10) 产品管理(9) BI数据分析师(9) NGINX(9) 数字化转型(9) 深度学习(9) 软件架构(9) 架构师(9) machine learning(9) 商务智能分析师(8) CIO(8) 技术选型(8) 安全战略(8) 软件测试(8) ArchiMate(8) PostgreSQL(8) Azure(8) Cloud Computing(8) Big Data(8) API(8) MSA(8) MDM(8) 技术趋势(7) 容器云架构(7) 核心实践(7) 无服务器架构(7) JavaScript框架(7) Vue(7) React(7) 参考架构(7) DevOps(7) 数据仓库(7) Data Lake(7) Envoy architecture(7) 容器(7) 主数据架构(7) microservices(7) 技术架构师(7) digital transformation(7) 投资组合管理(6) 安全架构(6) 集成架构(6) 合同测试(6) 工控协议(6) ICS(6) Micro Service Architecture(6) Envoy架构(6) 事件驱动(6) 数字化(6) 微服务架构师(6) strategy(6) 安全工具(6) application security principle(6) Angular(6) Postgresql架构(6) 网络架构(6) agilemodeling(6) 首席架构师精选(6) 高管洞察与创新(6) 云安全(6) 合约测试(5) Event Hub(5) 应用安全原则(5) Enterprise Portfolio Management(5) WAF(5) 编程语言(5) JavaScript Frameworks(5) 用户体验(5) 云原生(5) Agile(5) Python(5) IT战略(5) 企业敏捷性(5) 数字化业务(5) API Gateway(5) 项目管理(5) Digital business(5) 工业控制系统(5) Microservice Architecture(5) ICP(5) 软件架构师(5) 数据挖掘(5) Data Architecture(5) 主数据管理(5) 性能(5) Architecture Overview(5) Best Practices(5) Data Warehouse(5) k8s(5) 战略(5) IoT(5) 解决方案(5) 工业物联网(5) 数据科学家(5) 敏捷数据(4) 领导力(4) IPS(4) 领域驱动设计(4) DDD(4) 性能调优(4) 微前端(4) Vue.js(4) Docker(4) 敏捷核心实践(4) 应用组合管理(4) Agile Core Practice(4) 程序员(4) 数据可视化(4) 前端开发(4) 前端架构师(4) 前端开发工程师(4) 容器云架构师(4) 职业发展(4) executive insights and innovation(4) enterprise agility(4) 数据湖架构师(4) 开源合规(4) 敏捷模型(4) 业务转型(4) 企业微服务架构(4) 消费者驱动的合同测试(4) JWT(4) security(4) 企业架构师(4) architecture(4) 应用架构师(4) blockchain(4) 存储架构(4) GDPR(4) Cloud(4) RESTful(4) 最佳实践(4) 分布式计算(4) 数据湖架构(4) Service Mesh(4) BDD(4) 解决方案架构师(4) Event-Driven(4) SCADA(4) 云原生架构(4) 去中心化(4) IoT(4) IoT(4) Deep Learning(4) EA(3) technology(3) NFR(3) 安全(3) 应用现代化(3) Big Data(3) Spark(3) Microservice(3)