分类 观点 下的文章

容器构建有两大趋势:使用基本镜像和从头开始构建。每个都有工程上的权衡。

有人说 Linux 发行版不再与容器有关。像 distroless 和 scratch 容器等可替代的方法,似乎是风靡一时。看来,我们在考虑和做出技术决策时,更多的是基于时尚感和即时的情感满足,而不是考虑我们选择的次要影响。我们应该问这样的问题:这些选择将如何影响未来六个月的维护?工程权衡是什么?这种范式转换如何影响我们的大规模构建系统?

这真让人沮丧。如果我们忘记了工程是一个零和游戏,有可衡量的利弊权衡,有不同方法的成本和收益 —— 这样对我们自己不利,对雇主不利,对最终维护我们的代码的同事不利。最后,我们对所有的维护人员(向维护人员致敬! )都是一种伤害,因为我们不欣赏他们所做的工作。

理解问题所在

为了理解这个问题,我们必须首先研究为什么我们使用 Linux 发行版。我将把原因分为两大类:内核和其他包。编译内核实际上相当容易。Slackware 和 Gentoo( 我的小心脏还是有点害怕)教会了我们这一点。

另一方面,对于一个可用的 Linux 系统需要打包大量的开发软件和应用软件,这可能会让人望而生畏。此外,确保数百万个程序包可以一起安装和工作的唯一方法是使用旧的范例:即编译它并将它作为一个工件(即 Linux 发行版)一起发布。那么,为什么 Linux 发行版要将内核和所有包一起编译呢?很简单:确保事情协调一致。

首先,我们来谈谈内核。内核很特别。在没有编译好的内核的情况下引导 Linux 系统有点困难。它是 Linux 操作系统的核心,也是我们在系统启动时首先依赖的。内核在编译时有很多不同的配置选项,这些选项会对硬件和软件如何在一个内核上运行产生巨大影响。这方面中的第二个问题是,系统软件(如编译器 、C 库和解释器)必须针对内核中内置的选项进行调优。Gentoo 的维基以一种发自内心的方式教我们这一点,它把每个人都变成了一个微型的开发版维护者。

令人尴尬的是(因为我在过去五年里一直在使用容器),我必须承认我最近才编译过内核。我必须让嵌套的 KVM 在 RHEL7 上工作,这样我才能在笔记本电脑上的 KVM 虚拟机中运行 OpenShift on OpenStack 虚拟机,以及我的 Container Development Kit(CDK)。我只想说,当时我在一个全新的 4.X 内核上启动了 RHEL7。和任何优秀的系统管理员一样,我有点担心自己错过了一些重要的配置选项和补丁。当然,我也的确错过了一些东西。比如睡眠模式无法正常工作,我的扩展底座无法正常工作,还有许多其他小的随机错误。但它在我的笔记本电脑上的一个 KVM 虚拟机上,对于 OpenStack 上的 OpenShift 的实时演示来说已经足够好了。来吧,这很有趣,对吧?但我离题了……

现在,我们来谈谈其他的软件包。虽然内核和相关的系统软件可能很难编译,但从工作负载的角度来看,更大的问题是编译成千上万的包,以提供一个可用的 Linux 系统。每个软件包都需要专业知识。有些软件只需要运行三个命令:./configuremakemake install。另一些则需要大量的专业知识,从在 etc 中添加用户和配置特定的默认值到运行安装后脚本和添加 systemd 单元文件。对于任何一个人来说,调试好你可能用得到的成千上万种不同软件所需要的一套技能都是令人望而生畏的。但是,如果你想要一个可以随时尝试新软件的可用系统,你必须学会如何编译和安装新软件,然后才能开始学习使用它。这就是没有 Linux 发行版的 Linux。当你放弃使用 Linux 发行版时,那么你就得自己编译软件。

关键是,你必须将所有内容构建在一起,以确保它能够以任何合理的可靠性级别协同工作,而且构建一个可用的包群需要大量的知识。这是任何一个开发人员或系统管理员都无法合理地学习和保留的知识。我描述的每个问题都适用于你的 容器主机(内核和系统软件)和 容器镜像(系统软件和所有其他包)——请注意:在容器镜像中还包含有编译器 、C 库、解释器和 JVM。

解决方案

所以你也看到了,其实使用 Linux 发行版就是解决方案。别再看了,给离你最近的软件包维护者(再次向维护人员致敬!)发张电子卡吧(等等,我是不是把我的年龄告诉别人了?)。不过说真的,这些人做了大量的工作,这真的是被低估了。Kubernetes、Istio、Prometheus,还有 Knative:我在看着你们。你们的时代要来了,到时候你们会进入维护模式,被过度使用,被低估。大约七到十年后,我将再次写这篇文章,可能是关于 Kubernetes 的。

容器构建的首要原则

从零开始构建和从基础镜像构建之间存在权衡。

从基础镜像构建

从基础镜像构建的优点是,大多数构建操作只不过是安装或更新包。它依赖于 Linux 发行版中包维护人员所做的大量工作。它还有一个优点,即六个月甚至十年后的修补事件(使用 RHEL)是运维/系统管理员事件 (yum update),而不是开发人员事件(这需要通过代码找出某些函数参数不再工作的原因)。

你想想,应用程序代码依赖于许多库,从 JSON mung 库到对象关系映射器。与 Linux 内核和 Glibc 不同,这些类型的库很少改变 API 兼容性。这意味着三年后你的修补事件可能会变成代码更改事件,而不是 yum 更新事件。因此让他自己深入下去吧。开发人员,如果安全团队找不到防火墙黑客来阻止攻击,你将在凌晨 2 点收到短信。

从基础镜像构建不是完美的;还有一些缺点,比如所有被拖入的依赖项的大小。这几乎总是会使容器镜像比从头开始构建的镜像更大。另一个缺点是你并不总是能够访问最新的上游代码。这可能会让开发人员感到沮丧,尤其是当你只想使用依赖项中的一部分功能时,但是你仍然不得不将你根本用不着的东西一起打包带走,因为上游的维护人员一直在改变这个库。

如果你是一个 web 开发人员,正在对我翻白眼,我有一个词可以形容你:DevOps。那意味着你带着寻呼机,我的朋友。

Scratch 构建

Scratch 构建的优点是镜像非常小。当你不依赖容器中的 Linux 发行版时,你有很多控制权,这意味着你可以根据需要定制所有内容。这是一个最佳模型,在某些用例中是很有效的。另一个优势是你可以访问最新的软件包。你不必等待 Linux 发行版更新任何内容。是你自己在控制,所以你可以自行选择什么时候去费功夫纳入新的软件。

记住,控制一切都是有代价的。通常,更新到具有新特性的新库会拖如不必要的 API 更改,这意味着修复代码中的不兼容(换句话说,这就像给牦牛剪毛)。在凌晨 2 点应用程序不起作用的时候给牦牛剪毛是不好玩的。幸运的是,使用容器,你可以在下一个工作日回滚并给牦牛剪毛,但它仍会占用你为业务提供新价值、为应用程序提供新功能的时间。欢迎来到系统管理员的生活。

好吧,也就是说,有些时候,Scratch 构建是有意义的。我完全承认,静态编译的 Golang 程序和 C 程序是 scratch/distorless 构建的两个不错的候选程序。对于这些类型的程序,每个容器构建都是一个编译事件。三年后你仍然需要担心 API 的损坏,但是如果你是一个 Golang 商店,你应该有能力随着时间的推移修复问题。

结论

基本上,Linux 发行版做了大量工作来节省你在常规 Linux 系统或容器上的时间。维护人员所拥有的知识是巨大的,而且没有得到真正的赞赏。容器的采用使得问题更加严重,因为它被进一步抽象了。

通过容器主机,Linux 发行版可以让你访问广泛的硬件生态系统,从微型 ARM 系统到 128 核 CPU x86 巨型机箱,再到云服务商的虚拟机。他们提供可工作的容器引擎和开箱即用的容器运行时环境,所以你只需启动你的容器,让其他人担心事情的进展。

对于容器镜像,Linux 发行版为你的项目提供了对大量软件的轻松访问。即使你从头开始构建,你也可能会看到一个包维护人员是如何构建和运送东西的 —— 一个好的艺术家是一个好的偷学者,所以不要低估这项工作的价值。

所以,感谢 Fedora、RHEL(Frantisek,你是我的英雄 )、Debian、Gentoo 和其他 Linux 发行版的所有维护人员。我很感激你所做的工作,尽管我是个“容器工人”


via: https://opensource.com/article/19/2/linux-distributions-still-matter-containers

作者:Scott McCarty 选题:lujun9972 译者:Chao-zhi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

根据 Tidelift 的第三次开源管理调查,根据公司规模,出现了差异。

Tidelift 的第三次开源管理调查发现,企业在大流行期间正在转向开源,44% 的组织报告他们将增加使用开源进行应用开发。

我们以前见过类似现象。在以前的经济衰退中,组织转向开源以节省成本,并因其它一些转型收益而留下来。我们想了解哪些长期收益对不同规模的组织最有帮助。以下是我们发现的摘要。

开源正在推动成本和时间的节约,同时提高效率。68% 的组织提到的一个关键驱动力是节约资金和开发时间,因为使用开源减少了开发人员从头开始编写新代码的时间。近半数(48%)报告称,它提高了应用开发和维护效率。拥有超过 1000 名员工的组织更有可能将此作为鼓励使用更多开源的原因(61%,而少于 1000 人的组织为 41%)。

 title=

(Tidelift ©2020)

在组织使用更多的开源的原因中,消除供应商锁定是一个重要原因。 我们发现 40% 的受访者将这视为主要原因。用开源软件取代昂贵的专有软件,可以确保组织更加灵活,避免对供应商的依赖。同样,规模较大的组织也倾向于这个原因。在拥有 1000 名以上员工的组织中,有 50% 的组织将此作为主要优势。

增加开发人员的满意度是使用更多开源的另一个原因,有 31% 的组织提到了这一点。 随着企业对人才的激烈竞争,他们了解确保开发人员在工作中和使用的工具中感到快乐的价值。调查发现,开发人员使用的前三种语言是 JavaScript(78%)、Python(52%)和 Java(41%)。

此外,随着开源使用量的增加,83% 的组织继续对其贡献,近一半的组织制定了管理贡献的政策。 这些政策包括:在工作时间对组织使用但不赞助或管理的项目的贡献、对他们赞助或管理的项目的贡献、在个人时间对与工作无关的(个人)项目的贡献、以及在工作时间对与工作无关的(个人)项目的贡献。

虽然向开源的长期迁移仍在继续,但很明显,COVID-19 的影响可能正在加速这一进程,组织继续从使用和贡献中获得更深层次的价值。

更多信息,请查看 2020 年开源管理调查的所有调查结果。


via: https://opensource.com/article/20/12/open-source-survey

作者:Chris Grams 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

openEuler 是什么?在 2019 年 7 月 19 日,华为宣布要在年底正式开源 openEuler 操作系统;在半年后的 12 月 31 日,华为正式开源了 openEuler 操作系统,邀请社区开发者共同来贡献。

一年后,截止到 2020 年12 月 25日,openEuler 已经拥有了 3 万社区用户,2 万多个合入的 拉取请求 Pull Request ,2000 多名社区贡献者,7032 款社区软件,75 个特别兴趣组(SIG)以及 7 个商业发行版。不仅如此,openEuler 还在系统主体之外,开源了虚拟化平台 StratoVirt、容器引擎 iSula 等重量级软件。

openEuler 是发行版,还是...

和其他发行版不同,openEuler 的开场并不是以发行版开场的,而是从一个更加深刻的问题开始的——“操作系统有创新么?”。这个答案是肯定的,近些年来,无论是内核的架构还是应用组织的方式,都在不断的发生着创新和变化。但这些创新又好似离我们很遥远,也没有听到谁在实际生产环境中应用。这背后不是开发者的不努力,而是操作系统开发和交付的问题。

openEuler 技术委员会主席胡欣蔚拿线下的物流供应链举例,一条供应链是以满足客户需求为目的,包含了所有与满足客户需求相关的环节,从生产、运输、仓储、零售一直到最终的顾客,而与之类比的软件开发供应链,则由软件组成的相互依赖(构建、运行、代码的复制粘贴、定制化)形成的复杂关系网络被称为软件供应链。过去的开源软件把软件的交付终结于某一个特定的发行版,这带来了一些便利,简化了供应链的管理,相应的,也为软件开发的整体流程带来了单点故障的可能。

openEuler 技术委员会主席胡欣蔚

为了解决这个问题,openEuler 不是先做操作系统,而是先对软件开发供应链进行梳理,并将整个供应链梳理开源出来,让开发者的软件可以更好的交付给用户,让用户可以更好的把需求反馈到开源软件的上游社区。整个生态中开发者的需求、用户的需求都可以在这个供应链中得到满足。

而也正是这样的供应链,为 openEuler 带来了更多的可能,各个开源社区、合作伙伴,可以根据自己的需求,结合所在的行业和领域,打造出一款专精于领域的发行版。

不仅如此,供应链的思维,也让胡欣蔚可以重新思考云原生这个问题——“只有云才需要云原生么?”,答案显然是否定的。所有的数字化转型领域,都会需要云原生的这些特性。如何让这些边缘计算设备、端设备享受到云原生中的交付、迭代的性能,也是 openEuler 在关注的。openEuler 所特有的供应链,让操作系统的打包和精简变的更简单,可以根据设备不同的类型、场景整合出适合相应场景的操作系统,从而让这些新特性,可以不只交付给云,更可以交付给边和端,云边端一体为行业和业务创造价值。

openEuler 是操作系统,还是....

openEuler 广为人知的是一个新的发行版,一个 Linux 操作系统,但对于 openEuler 自己来说,操作系统不过是一个创新的产品的承载平台。在胡欣蔚来看,如果一个平台没有创新,则这个平台没有未来;如果一个创新没有好的平台去落地,那这个创新不过是无根浮萍,毫无意义。对于开发者来说,openEuler 就是这样一个孵化和培养创新的平台

胡欣蔚做了个比喻,“openEuler 就是 Apache 基金会 + CentOS 操作系统”。 CentOS 操作系统是一个著名的服务器系统,而 Apache 基金会是一个非常善于对新项目进行培育的基金会。openEuler 的操作系统,只是为了让创新可以有一个落地的平台,让创新有价值,而 openEuler 背后,是一个创新的平台、一个创新的土壤。

在这片土壤中,诞生了一些非常有意思,同时有具备使用价值的特性,比如跟随 openEuler 一同开源的 A-Tune,将 AI 的技术引入到系统的调教和优化过程中,用机器智能进行优化;比如开源的容器引擎 iSula ,让容器的运行可以更加的轻量和简单,从过去的只能运行于 x86 服务器,到现在可以应用在不同的边缘计算设备;比如 Bisheng JDK ,基于 specjbb 基准测试,相对 openJDK 性能提升了 20%;比如 StratoVirt,是基于 rust 语言开发的轻量级虚拟机,相对 QEMU 资源占用减少了80%,启动速度提升了 10 倍。

这些小的创新,让 openEuler 从一个普通的发行版,变成了一个远超过去的操作系统;而 openEuler 的孵化机制,可以让更多的有用的特性,从需求的收集,到发布到用户端,更加快速和方便。

行业在演进,操作系统和应用之间的分界线,开始变的更加的模糊,操作系统要做什么?应用要做什么?很难有一个一概而论的回答,但可以肯定的是,无论什么样的变更,都是希望这个行业可以有更大的进展,每一个行业中的开发者,都可以有更多的时间和精力去做更加核心的业务逻辑的开发。

openEuler 是软件,还是....

openEuler 不仅仅是一款软件产品,为什么 openEuler 会出现?有了数百款发行版的 Linux 世界,真的缺这样一款操作系统么?

答案是肯定的。

提及 openEuler 的诞生,胡欣蔚回顾了自己的过去,早在 2013 年,他就开始参与 ARM 服务器的构建,彼时 Linus Torvalds 对于 ARM v7 架构的评价刚刚过去不久,ARM 芯片应用在通用计算领域也只是刚刚开始,整个行业方兴未艾。他通过研究发现,整个行业的操作系统都存在一个普遍的问题:只适配于自家的芯片和计算平台,这使得应用开发者在开发的时候,需要根据不同的芯片来进行适配,大大的降低了开发者的效率,将更多的精力放在适配,而不是业务逻辑的研发上。

在他看来,这样薄的操作系统,无法为业务创新和行业的创新提供价值,而想要促进行业的前进,操作系统的变厚、变强是必不可少的,必须要像 x86 服务器一样,一个版本足以支撑所有厂商的 ARM 服务器,才能真正的促进 ARM 在通用计算领域的蓬勃发展。

也正是因为从那时开始的努力,经过了多年的耕耘,如今在 openEuler 上可以有所收获,当年的选择也无疑是正确的。如今的 openEuler 可以完美的运行在华为自家的鲲鹏处理器上,更是可以支撑多家的 ARM 服务器。不仅如此,一些科研院所,比如国科大的“一生一芯”项目,也被 openEuler 很好的支持了。对于开发者来说,使用的是 RISC-V 架构的芯片,也可以完美的支持 openEuler。未来,openEuler 将会从系统软件的角度,打通不同算力,让软件开发者可以在一个更加简单的操作系统之上,进行技术的创新。

openEuler 还可以是什么?

openEuler 的过去,是我们熟悉的 Linux 发行版,是我们所不熟悉的创新平台。而未来,openEuler 可能是什么?

胡欣蔚也向我们介绍了他的一些想法,在未来,openEuler 会在当前已有的基础之上,投入更多的精力去做一些普通开发者、厂商所无法实现的特性。比如在操作系统层面,提供秒级内核切换能力,让那些过去不敢升级、不愿升级内核的老旧系统,可以通过 openEuler 提供的特性,实现秒级的内核切换。在系统几乎不受影响的情况下,完成底层内核的切换,让老系统也可以享受到新内核提供的特性。也会花更多的精力,在 openEuler 社区的治理上,让 openEuler 社区可以有更多的用户,以及更多的开发者,让 openEuler 造福更多的企业和个人用户。

未来,openEuler 会出现在我们所熟悉的云计算和边缘计算上,到时候,我们再来看看,openEuler 还可以是什么。

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽(Red Hat)精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客《代码英雄》第三季(6):Bash Shell 中的英雄音频脚本。

导语:Shell 使得大规模 IT 成为可能。它们是现代计算的必要组成部分。但是,如果没有 自由软件基金会 Free Software Foundation 一位名叫 Brian Fox 的开发者的辛勤工作,它可能不会变成这样。现在,世界上几乎每台电脑都有 Bash shell。

在上世纪 70 年代, 贝尔实验室 Bell Labs 希望将重复的、复杂的命令序列自动化。Chet Ramey 描述了贝尔实验室是如何开发出几个 shell 的 —— 但 UNIX 只能有一个官方支持的 shell。获选的是 Bourne shell。尽管 Bourne shell 是这些之中最好的一个 shell,但它也有其局限性。而且它只有在受到限制的 UNIX 许可证下才能使用。Brian J. Fox 讲述了他在自由软件基金会的工作,他需要创建一个自由的 Bourne shell 版本。它必须兼容但不使用任何原始源代码的元素。这个 Bourne-Again Shell,即 Bash,可能是这个星球上使用最广泛的软件。而 Taz Brown 描述了它是如何成为一个开发者可以学习使用的最重要的工具之一。

00:00:07 - Saron Yitbarek

那是 1987 年。里根总统治下的美国正蓬勃发展,一个怀揣远大梦想的人正驱车前往他位于 圣巴巴拉 Santa Barbara 的新家。这个人名叫 Brian Fox,27 岁,是高中辍学生。在他车的后备箱里,有两盒巨大的磁带,里面载满了他当时正在编写的代码。

00:00:28

Fox 多年来一直以程序员的身份工作在所谓的自由软件运动中。他相信他锁在这个后备箱里的代码,可以带来一场革命,这是一种全新的软件范例。他的社区正在一点一点地使之成为现实。

00:00:49

那年, 理查德•斯托曼 Richard Stallman (RMS)的 自由软件基金会 Free Software Foundation 的一组程序员,正在想尽办法给计算机界带来自由。他们想要构建一个 UNIX 的替代品,以取代自从 70 年代以来就主导编程的 UNIX 操作系统。他们的 GNU(表示 GNU's not UNIX)将成为公众的操作系统,任何人都可以使用它,无需担心许可费用或版权问题。

00:01:18

多年以来,基金会一直在努力制造这个崭新的系统。那么 Brian Fox 汽车后备箱里的那两盒装着代码的巨型磁带是什么?它们存储着这个系统一个至关重要的组成部分。这是一个自由的,而且可更改的 shell,它能够使 GNU 操作系统变得完整。这是 Brian Fox 送给自由软件运动的礼物。他称之为 Bash。

00:01:46

我是 Saron Yitbarek,这里是 代码英雄 Command Line Heroes ,一档来自 红帽 Red Hat 的原创播客节目。在这一集中,我们将来看看 Bash shell 中的英雄们。我们将探索 shell 的历史,以及它们为什么对我们如今的工作如此重要。大家可以将 shell 看作要给演员的剧本。它们提供了完整的命令序列,然后 shell 可以快速地运行,就像演员可以一行接一行地读她的台词一样。这是对于实现重复且复杂的代码的,是最终的解决方案,也是自动化的关键。你可能会说,shell 脚本是我们开发的一大助力。但是,是否可以编写一个,能给所有人带来帮助的 shell?这就是挑战所在。

00:02:38 - Ken Thompson

让我们回到 1969 年。那时候贝尔实验室的几位计算机科学家,正在根据自己的需求开发程序。

00:02:48 - Saron Yitbarek

这位是代码英雄先驱 Ken Thompson。由贝尔实验室设计的 UNIX 操作系统,在一开始确实是供他们个人使用的。最初,它只是一个内部系统。UNIX 鼓励程序员之间进行密切的交流,不过目的并不是要改变整个世界,而是改变贝尔实验室。

00:03:13 - Ken Thompson

到现在,几乎整个贝尔实验室都在使用这个系统。我们公司拥有近两万个计算机终端,其中大多数使用 UNIX 系统。

00:03:25 - Saron Yitbarek

一款由 Ken Thompson 所设计的 UNIX shell 在 1971 年发布。 虽然 Thompson shell 被设计为命令行解释器,但是它却不能很好地支持脚本。所以直到六年后的 1977 年,脚本才开始兴起。

00:03:44 - Chet Ramey

Shell 参数、特殊参数以及我们如今认为理所当然的变量,起源于 Steve Bourne 和 Bourne shell。

00:03:57 - Saron Yitbarek

这位是 Chet Ramey,Case Western Reserve 大学的 IT 架构师。Chet 致力于维护 Bash,他也为我们讲述了许多 Bash 的起源故事。他描述了贝尔实验室当时研究 UNIX shell 样子时的情景。

00:04:13 - Chet Ramey

我们如今使用的编程结构起源于 Steve Bourne,他的 shell 赢得了这场比赛。当时有大量使用 Mashey shell 的用户社区,也有大量用户开始使用 Bourne shell。那时候成立了一个委员会来决定哪一个将会获胜,哪一个将会成为从那时候起得到官方支持的 UNIX shell, Bourne 的 shell 赢了。而其他的 shell,正如他们所说,成为了历史。

00:04:54 - Saron Yitbarek

不过,这还不是历史的终结。当然,Bourne shell 是一个巨大的飞跃。它打开了一扇通向更高自动化水平的大门。但是尽管有一段时间 Bourne 占据了上风,但是 Bourne shell 并不能解决我们所有的脚本需求。

00:05:14 - Chet Ramey

Bourne 撰写自己的 shell 时所受到的限制,几乎是现在的你我难以想象的。显然,当你遇到这些限制时,你不得不放弃很多东西,Bourne 就放弃了很多。考虑到他所处理的空间、内存和 CPU 限制,他能够让 Bourne shell 包含那么多东西,这相当了不起。

00:05:42 - Saron Yitbarek

请记住,Bourne shell 仍然是贝尔实验室 UNIX 系统的一部分。它仍然与 UNIX 许可证绑定。这意味着它不是自由的,不是开放的。这款 shell 是私有的。

00:05:55 - Chet Ramey

如果你不在大学里,获取 UNIX 源码将会非常困难。显然,这对 Berkeley UNIX 的普及产生了影响。Berkeley UNIX 始于大学中,在大学社区中成长,并走了一条阻力最小的道路。因此,如果你在正确的地方,访问到 Bourne shell 的源码并不困难,但是总的来说,这并不是大众都能够认可的方案。

00:06:36 - Saron Yitbarek

Chet Ramey 是 Bash shell 的维护者。

00:06:41

因此,我们有了 shell 的雏形,可以着手写这些关键的组成部分,但是目前为止,最好的 shell 的许可证却有个大大的问题,它是闭源的。对于理查德•斯托曼和他的自由软件基金会而言,这是绝对无法接受的事情。我们所需要的是一个不与任何公司绑定的 shell,一个面向所有人的 shell。

00:07:05

但这就带来了问题。这意味着我们需要编写某种,能做到 Bourne shell 所能做到的一切,而又不会侵犯到版权的东西。如果逐字复制 Bourne shell 的代码,你会被起诉。

00:07:20

为了使人们摆脱 Bourne shell 的束缚,你必须找到一位能在没看过 Bourne shell 任何源代码的情况下,编写这款复杂程序的程序员。你必须找到这样的一位局外人天才。而理查德•斯托曼找到了完成这项工作的程序员。

00:07:46

Brian Fox 是一名 20 来岁的高中辍学生,比贝尔实验室的大多数人更懂代码。他从来没有见过任何 Bourne shell 的源代码,这使得他非常适合手头的任务。

00:08:02 - Brian Fox

我是 Brian Fox。

00:08:04 - Saron Yitbarek

为什么不直接问问这个年轻人,这个故事是什么样的呢?现如今,Fox 是一位开源倡导者以及 Opus Logica 的 CEO。但是早在 80 年代后期,他只是一个信仰开源软件运动的年轻人。我们聊了聊过去的日子,以及 Bash 是如何从那时演变过来的。

00:08:23

所以那时候理查德•斯托曼请你为 UNIX 开发一款 shell。那将会是一款自由的 shell,并且是 Bourne shell 的替代品。你是如何回应的呢?

00:08:38 - Brian Fox

“我们就不能做个更棒的吗?”

00:08:41 - Saron Yitbarek

我喜欢这个。再多跟我说说。

00:08:45 - Brian Fox

我为斯托曼所做的第一件事,其实就是编写个信息技术文档系统。我让理查德惊讶于我做这种编程的速度。他是个优秀的程序员而且工作的很快,但是他不认为其他人也能写得那么快。

00:09:00 - Brian Fox

因此,在第一周内,我完成了一款名为 GNU Info 的程序的第一版实现,理查德对此有点儿震惊。我说:“我的下一个项目是什么?我的下一个项目是什么?”他说:“好吧,现在给它做个编译器吧。”我就做了,一周时间之内就完成了。然后我说:“我的下一个项目是什么?我的下一个项目是什么?”他说:“好吧,另一个家伙一直在研究那个 shell,但他还没有太多进展。”我说了“好的”,九个月后, Bourne shell 的替代品完成了。

00:09:29 - Saron Yitbarek

九个月,哇。再多告诉我一些。为什么它如此具有挑战性?

00:09:33 - Brian Fox

这真是个有趣的问题。它之所以如此具有挑战性,是因为我们必须忠实地模仿 Stephen Bourne 最初的 Bourne shell 的所有行为,同时对其进行扩展,让它成为人们能使用的、更好的工具。

00:09:51

那时候,我和 Korn shell 的作者 David Korn 私下进行了秘密争论。POSIX 委员会,也就是规定了什么是标准 UNIX 的委员会,他们也参与了进来,并说:“哦,很好,我们需要知道 shell 到底要包含些什么。”而这方面最重要的两个人是我和 David Korn。David Korn 已经写了一个名为 KSH 的 shell。对于他所加入到 KSH 中的每一个功能,他都说:“这应该是一个标准功能。”是这样吗?对他来说这比起拥有最完美的 POSIX shell 要容易得多,如果这仅仅是他的 shell 的话。

00:10:31

其中的一些功能并不是很好的功能,不是很好的选择,而且使得这款 shell 与 Bourne shell 有些不兼容,或者我觉得缺少功能,对此我们进行了一些讨论和争论,因此构建一个兼容 POSIX 的 shell 与过去为 Bourne shell 所编写的每个 shell 脚本都完全兼容花了超过 3 个月时间。

00:10:54 - Saron Yitbarek

因此,如果你正在设计的产品不仅可以取代 Bourne shell,而且还试图模仿 Bourne shell 的每个部分,听起来你可能会遇到一些版权问题。你是如何处理的?

00:11:08 - Brian Fox

为了构建真正开源而自由的软件,你必须得在一个干净的空间里,开始做这项工作。你不能从查看别人的代码开始然后重新实现它。因此,我从未见过与任何贝尔的系统、UNIX 或者甚至 Berkeley UNIX 相关的任何软件,也从未见过这些东西的源代码。

00:11:29

当我开始构建 Bash shell 时,我使用了一个名为 Bison 的解析器,理查德已经将其整合到自由软件基金会里,并且与之前任何的其他程序完全不同。因此,我已经知道我所要构建的东西,绝对不会侵犯任何先前构建的东西的版权。

00:11:55 - Saron Yitbarek

创建 Bash 的工作有很多小插曲,对于那些硬核的代码英雄来说,这只是其中一个例子。

00:12:03 - Brian Fox

有一次,我正致力于在 shell 中实现 通配扩展 globbing 。举例来说,这是允许你匹配大量文件的通配符扩展。你可以给出 *.c,而这会匹配所有带有 .c 扩展名的文件。

00:12:17

因此我在通配扩展上忙活了几个小时,并且使其生效了,对此我感到很兴奋。这是一个很好的实现。而在创建这一版实现的过程中,我在我的目录里创建了一个名为 *.c 的文件,然后我想:“好吧,我应该删掉这个文件”,然后我输入了 RM、空格、引号、星号点 C、闭合引号,在现代 shell 中当你使用了括号,这意味着“不要扩展这个”,然后我按下了回车,提示符过了很长时间才重新出现,因为我们正在使用 Sun 350s,运行缓慢。我意识到,之所以花了很长时间是因为它要删除这个目录里的所有源文件。

00:12:58 - Saron Yitbarek

哦,不!

00:12:59 - Brian Fox

是的。所以我当时删掉了 Bash 的源代码。

00:13:01 - Saron Yitbarek

哦,不要。

00:13:04 - Brian Fox

这 ——

00:13:05 - Saron Yitbarek

哦我的天哪,嗯。

00:13:06 - Brian Fox

这件事让我笑了很久,笑的很大声。我甚至没有感到一丝沮丧。然后在接下来的几天里,我重新输入了全部。这份代码在我脑海里是完全是崭新的。

00:13:20 - Saron Yitbarek

哇。

00:13:20 - Brian Fox

问题解决了。只需将其记录到文件中即可。

00:13:25 - Saron Yitbarek

好的。因此,大多数人会在那一刻完全惊慌失措。而你笑了,只是说:“哦,我想我必须重新做一遍了。”为什么你当时那么冷静呢?

00:13:35 - Brian Fox

这让我感到疯狂很荒唐,也非常好笑,我正在打造这个工具,而要确保自己能搞好,确保该工具正常工作,你得在构建它的过程中就使用它。但是该工具无法正常工作。我还没有实现引号,并且因为我还没实现引号,所以我输入的命令没有按照我所预期的去执行,我觉得这真的很滑稽。

00:14:06 - Saron Yitbarek

太神奇了。

00:14:08

不过,甚至是关于错误的这个故事也能说明 Fox 的才华。他们说莫扎特在头脑中完成了交响曲,然后只需要在完成后写下来即可。Fox 也有类似的天赋。

00:14:23

因此,当你最终完成并交付 Bash 时,感觉如何呢?

00:14:27 - Brian Fox

呵,其实感觉很壮观。那么这里有一个故事,其实我一般不讲的。构建这款 shell 花了大约 8 个月的时候,当时我知道,我大概还需要大约一个月时间才能完成工作,然后另一个 shell 发布了 —— ASH,一个开源的 shell 被发布了,我很沮丧,因为我们还没有向任何人发布 Bash shell,所以只有少数人在使用它。我知道这还需一个月的工作量,于是我想:“哦,这太糟糕了。我投入的全部能量和精力都不会得到赞许,甚至可能都不会被看见。”所以我非常沮丧。这次我没有笑。

00:15:13 - Saron Yitbarek

然而,布丁好不好,吃了才知道。GNU 的 Bash 发布于 1989 年并且变成了 Linux 的默认 shell。如今,它是计算机中不可或缺的一部分。

00:15:25

它无处不在。如此多的人每天都在使用它。它遍布于每一台计算机上。作为 Bash 的作者感觉如何?

00:15:34 - Brian Fox

大多数时候,我甚至都没有注意到 Bash 是比工具更加重要的东西。我真的没有经常想这件事。每隔一段时间,我会走进一家苹果商店,环顾四周然后想:“哇,这里的每台计算机不仅运行着我 27 年前编写的软件,甚至上面还包含有我的名字。”然后我想:“互联网上的每台计算机、每台服务器都在运行着 Bash shell,并且其中包含有我的名字。”然后 Windows 在去年还是前年推出了 Power shell,就是 Bash,当时我想:“哦,天哪。我的名字遍及地球上的每台计算机了。”

00:16:21 - Saron Yitbarek

不过,我想让你们能仔细听听 Fox 接下来告诉我的内容,因为它是很重要。他从未想过,它的程序会这样统治全球。他试图提供帮助,试图帮助他所置身其中的编程文化。

00:16:37 - Brian Fox

我并没有打算去实现出现在每个人的计算机上这样的宏伟目标。我对此一点都不感兴趣。我想制作一款有用的软件,我希望它有典型的 3 到 5 年软件寿命,而不是像现在这样疯狂的 30 年的寿命。

00:16:58 - Saron Yitbarek

难道你对于你在计算机领域有如此巨大影响力的事情,一直反应那么平淡吗?

00:17:06 - Brian Fox

我为自己写了 Bash 而感到骄傲,而且它让我意识到了我的价值,所以有时候我会做一些事情,诸如接受播客邀约谈论 shell 之类的事情。

00:17:14 - Saron Yitbarek

非常感谢你。

00:17:15 - Brian Fox

谢谢。但这不是存在于我日常生活中的东西。幸运的是,我只是一个默默无闻的人,对吧?的确,我的软件正运行在每家每户的计算机上,不过也确实没有人知道这一点,对吧?因此我保持了许多个人隐私,而这个 shell 以及某个住在圣芭芭拉的人编写了它这一事实正越来越广为人知,我开始在生活中越来越多地注意到它。人们有时候来看我演奏音乐,然后告诉我说:“你是写了 shell 的那个家伙。”我感觉有点儿像 Keanu Reeves。

00:17:54 - Saron Yitbarek

很酷。所以你说过你不指望 Bash 出现在每台计算机上。你打算做的是什么呢?你对 Bash 有什么期望?

00:18:04 - Brian Fox

一个有用的替代工具,成为 GNU 项目的一部分,并帮助创建这个自由的开源操作系统。我实际上以为一旦我们完成了该开源操作系统的创建,该系统上的软件就可以升级,并且我将有机会创建自己想要创建的那种 shell,以帮助人们在某种程度上促进计算机科学的发展。

00:18:35 - Brian Fox

我最终意识到,Bash 被创建的原因实际上是与已经存在的 UNIX 世界向后兼容,并且这种势头使其保持了活力,这是另一个独一无二的地位,你的工具如此基础,几乎是一副不可或缺的螺母和螺栓。

00:19:01 - Saron Yitbarek

确实是这样。

00:19:01 - Brian Fox

知道我创造了世界上某种有价值的、别人仍然还在使用的东西,这真的是一种很棒的感觉。然后当我注意到这是怎么回事时,我意识到,更重要的是,“自由软件”和“开源”这些词存在于日常英语和全世界的日常语言之中了,而最初并不是这样的。这是我和理查德•斯托曼还有其他人所投入努力的产物。作为这一运动的一部分,我很幸运能这么早参与,但让我回过头来看时,也感到非常满意,我想:“哇,开源软件已经存在,而且我就是其中的一部分。”

00:19:50 - Saron Yitbarek

Brian Fox 是 Bash shell 的创建者和 Opus Logica 的 CEO。

00:20:01 - Steve Bourne

事实上,我确实听说过 Bash。

00:20:03 - Saron Yitbarek

这位就是被 Brian Fox 的工作所替代的 Bourne shell 的创建者 Steve Bourne。我们想知道 Bourne 对 Fox 的工作有何看法。他是否将重生的 shell Bash 视为自己作品的开源复制品?我的意思是,他觉得 Bash 怎么样?

00:20:20 - Steve Bourne

有一天,写了 Bash 的那个人在一次会议上找我,给了我一件 T 恤,前面印着 “Bourne again” 的字样。

00:20:26 - Saron Yitbarek

那就是 Brian Fox。

00:20:29 - Steve Bourne

那是一种友好的情绪,当时是:“好吧,希望您不介意,但我只是重写了您的 shell”,而我说:“听起来不错”,然后他给了我一件 T 恤。

00:20:38 - Saron Yitbarek

如果我在编程领域学到了一件事,那就是每个人都喜欢意外之喜。事实证明,Stephen Bourne 认为 Bash 是他和其他人在贝尔实验室所做工作的必要扩展。一点儿都不为此苦恼。

00:20:52 - Steve Bourne

曾经有一些人们想要,但是我没做的特性,例如变量替换和字符串管理,但是这些都被加入到了 Bash 中,现如今人们经常会用到。Bash 和原始 shell 之间的关系,我当时的印象是,它只是对语言的重新实现,并且随着时间的推移,它确实添加了功能,因此它确实取得了超越我所写作品的进步,当然是在字符串管理领域。我现在一直在用它。

00:21:21 - Saron Yitbarek

Steve Bourne 是 Bourne shell 的创建者和 Rally Ventures 的 CTO。

00:21:32 - Saron Yitbarek

自从 Bash 在前往圣芭芭拉的长途车程中被塞进 Brian Fox 的卡车以来,已经过去了很多年。 2019 年,版本 5.0 被发布,就像 Fox 提到的那样,Bash 现在被内置进了 Linux 中、macOS 中,甚至微软 Windows 中。Bash 已经成了开源世界中脚本编写的基石。这是我们自动化的基础。

00:22:02 - Taz Brown

随着组织规模的扩大,使用能够使我们更快完成工作的工具变得至关重要。它成为了必需品。

00:22:16 - Saron Yitbarek

Taz Brown 是 Red Hat 的资深 Ansible 自动化顾问,因此她非常了解 Bash 的价值。

00:22:24 - Taz Brown

我绝对认为人们在职业生涯初期就应该使用 Bash。与其使用 GUI 或者说是图形用户界面,不如将自己视为管理员或 DevOps 人员。

00:22:39 - Saron Yitbarek

而这是因为作为一名 Bash 程序员,你将会掌握能让你晋升的核心价值。

00:22:45 - Taz Brown

学习写脚本有一定的价值,因为这可以让你从自动化的角度,为程序的长期运行做打算。你可以看到脚本的运行方式,然后可以说:“好吧,我可以做到,我可以使这项任务自动化执行。”它开始使你成为与之前不一样的思想家和技术专家。

00:23:09 - Saron Yitbarek

对于运维而言,自动化已经变得不可或缺。复杂的程序、应用和工具均由优雅的 Bash 代码实现。

00:23:21 - Taz Brown

如果你愿意的话,你不必重复造轮子。你可以从 GitHub 库或是其他任何你存储这些特定文件的地方拉取它们。Bash 允许你这么做。Bash 允许你执行这些常见任务,并且可以从 10 台服务器扩展到 1000 台服务器。

00:23:42

关于自动化的伟大之处在于,一旦你制定了计划,就可以以一种非常有效的方式执行。它允许你执行那些,无法手动执行的操作。

00:23:56 - Saron Yitbarek

最近 Taz Brown 所从事开发的 Ansible® 这样的最新产品可以始终与 Bash 集成在一起,完成了工作。

00:24:04 - Taz Brown

虽然时代在不停前进,但是我认为 Bash 永远都会是管理员会去选择使用的工具,特别是他们想要快速自动化的情况下。

00:24:14 - Saron Yitbarek

最后,这一切的成功,都可以追溯到它是一个自由的、允许所有人加以改进的软件这件事上。它是 Brian Fox 提供给世界的,某种没有许可证和限制的东西。满足了人们一直的需求,所以是 Bash 成功的关键。实际上,他甚至已经不再主管 Bash 开发已经很长一段时间了。这位是 Chet Ramey,他维护了 Bash 数十年。

00:24:38 - Chet Ramey

我想,Brian 在发布 1.05 版本后就已经决定了他想要继续去从事其他工作。他曾在自由软件基金会负责过其他任务,他想做除了 Bash 以外的事情,而我是 Bash 最活跃的贡献者。他和我一起开发了许多新功能。我们共同努力解决了许多 bug,因此当到了需要其他人接手时,我是最佳人选。

00:25:16 - Saron Yitbarek

就像 Fox 一样,Ramey 也必须继续努力,因为 Bash 比任何一位维护者都重要。

00:25:25 - Chet Ramey

我是从 23 岁开始贡献的,有点儿像是我和 Bash 共同成长。在某些时刻,我会需要征集一个团队。我需要征集那些愿意并且有能力投入时间推动 shell 发展向前的人们。

00:25:46 - Saron Yitbarek

Bash,这款再次降生的 shell 明年将迎来 30 岁(LCTT 译注:Bash 发布于 1989 年,至本译文发表时,已经 31 岁了),并且没有衰老的迹象。Bash 乘着自由软件浪潮,然后是开源浪潮,直到传播至编程世界的每个角落。但曾经,它只是存储在 Brian Fox 汽车后备箱里磁带上的代码。它只是一些程序员,想要带给大家的 shell 语言。几乎偶然的,Brian Fox 在此过程中成为了一名伟大的代码英雄。

00:26:23

顺便说一句,有些事情始终困扰着我, Brian Fox 驱车将所有 Bash 代码载到了 Santa Barbara。为什么要转移呢?我的意思是,他在某家科技公司找到了新工作吗?

00:26:34 - Brian Fox

我想要继续我的音乐生涯,而我认为做到这一点的最佳去处就是气温总在 72 华氏度左右、天空没有乌云、海滩很美的地方。

00:26:45 - Saron Yitbarek

很好,我更喜欢这个理由。

00:26:49

现在让我们向 Wayne A. Lee 致敬,是他向我们建议了这一集标题《Bash Shell 中的英雄》。干得好,Wayne。

00:26:57

在下一集中,我们对于自动化的兴趣,将提升到一个全新的高度,并且着眼于 AI 语言,特别是 John McCarthy 创造的 LISP。

00:27:11

《代码英雄》是 Red Hat 的原创播客节目。如果你访问节目的网站 redhat.com/commandlineheroes,你将更深入了解到有关 Bash 或是我们本季所介绍的任何编程语言的故事。

00:27:28 - Saron Yitbarek

我是 Saron Yitbarek。下棋之前,坚持编程。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


via: https://www.redhat.com/en/command-line-heroes/season-3/heroes-in-a-bash-shell

作者:Red Hat 选题:bestony 译者:JonnieWayy 校对:acyanbird, wxy

本文由 LCRH 原创编译,Linux中国 荣誉推出

不,这不是 IBM 在发号施令。这个决定是红帽内部出于商业上的原因做出的,而且这个决定由来已久。

当 CentOS 的 Linux 母公司红帽宣布将重点从 红帽企业 Linux Red Hat Enterprise Linux (RHEL)的重建版 CentOS Linux 转移CentOS Stream上,而 CentOS Stream 的跟踪时间刚好在当前 RHEL 版本之前时,很多 CentOS 用户简直要昏倒了。

Hacker News 上,最主要的评论是,“想象一下,如果你正在经营一家企业,并基于 10 年寿命的承诺部署了 CentOS 8 。现在你全完蛋了,而红帽知道这一切。他们究竟为什么不从 CentOS 9 开始做这个转换??!让我们不要粉饰这个问题。他们背叛了我们。”

Reddit/Linux 上,另一个人咆哮道:“从 CentOS 4 以来,我们的开源项目都是基于最新的 CentOS 版本的,我们的旗舰产品运行在 CentOS 8 上,我们已然把一切都押注在了他们承诺的 2029 年 5 月 31 日生命周期上。”

自称 “Unix 宇宙中最好的 Linux 博客”,nixcraft,一个拥有超过 20 万订阅者的账号发布的热门推特说:Oracle 收购了 Sun 公司, Solaris Unix、Sun 服务器/工作站和 MySQL 被转到了 /dev/null。IBM 买下红帽:CentOS 去了 >/dev/null。请注意。如果有一天 Oracle、IBM、MS 等大厂商购买了你喜欢的软件,请尽快启动迁移。”

其他许多人也加入了这个令人恼火的 CentOS 用户吐槽团,认为他们最喜欢的 Linux 被夺走是 IBM 的错。还有一些人则尖声叫骂红帽在背叛开源本身。

红帽为什么要这么做?红帽的首席技术官 Chris Wright 在推出 CentOS Stream 时说:“[开发者......需要更早地[在 2019 年 9 月]访问代码](https://www.zdnet.com/article/red-hat-introduces-rolling-release-centos-stream/),与更广泛的合作伙伴社区进行改进和更透明的合作,并能够影响新的 RHEL 版本的方向。CentOS Stream 正是为了解决这些需要而出现。”

简而言之,一个原因是开放红帽企业 Linux(RHEL)的代码。原 CentOS 董事会成员、长期的 Fedora Linux 贡献者、红帽高级社区架构师 Karsten Wade 在一篇博客文章中进行了更进一步的解释:

RHEL 本身的开发仍然封闭在红帽的防火墙之后。 这种情况已经持续了近二十年。对于开源开发生态系统来说,这一直是一个重要的,而且经常是痛苦的缺口 —— 这仍然是和 2003 年一样的开放性缺口。

这就是我们今天所处的境地。将项目的重点转移到 CentOS Stream 上的举动,就是为了在一些关键的方面填补这个开放性缺口。本质上,红帽是通过将 CentOS 的位置从 RHEL 的下游转移到 RHEL 的上游,来填补 Fedora 和 RHEL 之间存在的开发和贡献缺口。

是的,这是真的。部分原因是红帽在 Fedora 和 RHEL 开放之间做最后的、重要的步骤。另一个部分的官方原因是,正如 Wright 所说,CentOS Stream 作为 RHEL 下一步的“滚动预览”,无论是在内核还是功能上都可以用于当今容器化、云原生的 IT 世界。毕竟,Facebook 已经在 CentOS Stream 衍生的 Linux 操作系统上运行了其数百万台服务器。

因此,Wright 继续说道,虽然“CentOS Stream 并不是 CentOS Linux 的替代品,相反,它是一个自然的、不可避免的下一步发展,旨在实现该项目进一步推动企业 Linux 创新的目标。”是的,CentOS Stream 不是一个你可以运行多年、稳定版本的 Linux 服务器发行版,但它是以云为中心的公司所需要的,以部署“容器化应用和云原生服务,以快速的硬件创新和生态系统转向软件即服务(SaaS)。......这就是我们认为的 CentOS Stream 优势所在。它为社区层面的快速创新提供了一个平台,但又有足够稳定的基础来了解生产动态。”

是的,这也是事实。但是,它们不是故事的全部。以下是红帽将老式的定期发布的 CentOS 放任自流的真正原因。

红帽公司根本没有怎么谈论这方面的问题,但是红帽公司 Linux 工程副总裁 Mike McGrath 在 ITPro Today 上接受 Christine Hall 的采访时,却把秘密泄露了出来。“我想说的是,对我们来说,最大的问题是 CentOS 本身其实并没有给红帽提供那么大的用处。我们建立的大多数社区,比如 Fedora,确实有很多双向的社区参与。不幸的是,CentOS 从来就不是这样的。它一直是一个用户社区,所以那种贡献模式大多是单向的。”

让我再重复一遍,“CentOS 本身其实并没有给红帽提供那么大的用处。” 它从来没有。而且,有很多红帽的资深人士从第一天开始就知道这一点,他们一点也不喜欢它。

你知道谁在使用 CentOS 吗?一份简短的名单包括迪士尼、GoDaddy、Rackspace、丰田和 Verizon。此外,还有几十家公司围绕 CentOS 打造产品。这些公司包括 GE、Riverbed、F5、Juniper 和 Fortinet。红帽从这些 CentOS 的“客户”身上赚了多少钱?零!

在 CentOS 博客上,一位不满的用户说:“整个前提,也是唯一有人使用 CentOS 的原因,就是因为它重构了 RHEL。恭喜你破坏了这一点,笨蛋。”

没错,这也是 CentOS 要为 CentOS Stream 让位的最大原因。

红帽公司没有人愿意公开说这句话,但众多红帽公司的高管告诉我,情况就是这样。

有一位说:“这与 IBM 几乎无关。在 2018 年秋季收购的消息还没有传来之前,我们就在详细地讨论这个问题。有两个内部原因。首先,工程和销售部门无论如何也想不出如何在各自的产品组合中定位 CentOS。而且,把 CentOS 变成上游的想法始于 2014 年,当时 Jim Perrin [前红帽开发人员和 CentOS 董事会成员,现为微软首席项目经理]在 2014 年巴西的 Fórum Internacional de Software Livre(FISL)演讲中谈到了这种可能性。结果就出现了 CentOS 特别兴趣小组(SIG),这是 CentOS Stream 之路的开始。”

一位前红帽高管坦言:“CentOS 在挖销售的墙角。客户的看法是‘它来自红帽,是 RHEL 的克隆,所以它很好用! ’其实不然。它是一个二流的拷贝。”以他的立场看,“这 100% 是防守,以避免 CentOS 造成更多损失。”

还有一位前红帽官员说。如果不是因为 CentOS,在红帽成为十亿美元的企业之前,红帽就已经是一家百亿美元的公司了。

而另一位红帽员工指出:“看看 CentOS 的 FAQ,它就在那里写着 ——

CentOS Linux 不受 Red Hat 公司的任何支持
CentOS Linux 不是 Red Hat Linux,不是 Fedora Linux,也不是 Red Hat Enterprise Linux,它不是 RHEL。CentOS Linux 包含 Red Hat® Linux、Fedora 或 Red Hat® Enterprise Linux。
CentOS Linux 不是 Red Hat® Enterprise Linux 的克隆。
CentOS Linux 是由 Red Hat, Inc 为 Red Hat Enterprise Linux 提供的公开源代码,在一个完全不同的(CentOS 项目维护的)构建系统中构建的。

我们不欠你什么。”

这可能会让你们中的一些人对红帽非常生气。不过,在你们发火之前,让我先问你们一些问题。CentOS 的“客户”为 CentOS 贡献了多少?我说的不是钱。我说的是代码、文档和支持。所有这些开源社区应该回馈的东西。答案是:几乎没有,接近于无。

在 CentOS 从事安全工作的 Dick Morrell 在推特上写道:“[社区[是]由合作和互动定义的](https://twitter.com/ThatPodcastChap/status/1337030501874479104)。如果 @CentOSProject 是一个社区建设的住宅开发项目,它将享受那些受益和使用其设施的人所贡献的扩建、楼层和功能。” Morrell 继续说道:“然而 @CentOSProject 一直是不断给予的仁慈礼物,而现在那些抱怨的人从来没有站出来用砖头、水泥或玻璃来扩建这个物产。”

你真的能责怪红帽做了一个企业应该做的事情吗?赚钱的同时而为他们的付费社区服务?我明白为什么人们对红帽感到生气。这是沟通不畅的问题。仅仅用一年的警告就切断了对 CentOS 8 的支持,这理所当然地换来了很多人的不满。 但如果你是那些现在对红帽愤怒的人之一,在你太过自以为是之前,你可能要先自我反思一下,想想你对 CentOS 的回报有多少。

最后,如果你还是无法忍受红帽对 CentOS 的做法,还有其他的 Linux 替代品。而且,至少有两个“经典”的 CentOS 构建版本,CloudLinux 的 Project Lenix 和 Rocky Linux 可供你考虑。


via: https://www.zdnet.com/article/why-red-hat-dumped-centos-for-centos-stream/

作者:Steven J. Vaughan-Nichols 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

“微服务架构风格是一种将 单个应用程序 开发为一套 小型服务 的方法,每个服务都在 自己的进程中运行,并使用轻量级的通信机制(通常是 HTTP 类型的 API)进行通信。这些服务是围绕 业务能力 构建的,并且可以通过 全自动化的部署机制 进行 独立部署。目前对这些服务几乎没有集中的管理,这些服务可以用 不同的编程语言 编写,也能使用 不同的数据存储技术。”

—— James Lewis 和 Martin Fowler (2014) [1]

介绍

预计在 2020 年,全球云端的微服务市场将以 22.5% 的速度增长,其中美国市场预计将保持 27.4% 的增长率 [2] 。目前的趋势是,开发人员将从本地托管的应用程序转移到云端。这将有助于企业最大限度地减少停机时间、优化资源并降低基础设施成本。同时专家们还预测,到了 2022 年,90% 的应用程序将会使用微服务架构进行开发 [2:1] 。本文将帮助你了解什么是微服务,以及目前的公司如何使用它的。

什么是微服务?

微服务已经在全球范围内被广泛使用。但是,微服务到底是什么?微服务是一种基于许多小型、互联服务的体系结构模式。它们基于 单一责任原则。根据 Robert C. Martin 的说法,“将因相同原因而变化的事物聚集起来,将因不同原因而变化的事物分离开来”。 [3] 微服务架构也被扩展到了 松耦合服务 中,可以 独立地开发、部署和维护 [3:1]

远离单体架构

微服务通常和传统的单体软件架构做对比。在单体架构中,软件是被设计为自足的,也就是说,这个程序中的各个组件都是互相连通和互相依赖的,而不是松散耦合的。在一个紧耦合的架构中( 单体 monolithic ),每个组件和它相关联的组件必须按照指定的顺序组合起来,才能被执行或编译 [4] 。当其中有一个组件需要更新时,整个应用都要被重写。

而这个现象在使用微服务架构的应用中就不会出现。因为每一个模块都是独立的,每个模块都可以更新修改而不影响程序的其他部分。因此,降低了对更改一个组件会对其他组件造成影响的风险。

如果公司的架构很难升级,或者维护过于复杂和昂贵,那么他们可能会遇到麻烦,不能扩展单体架构的应用 [5] 。把一个复杂的任务分解成小组件,彼此独立工作,就是解决这个问题的方法。

单一体系架构 vs. 微服务架构 (图片来自 [6]

开发者如何构建属于自己的微服务

微服务以提高可扩展性性能而闻名。然而,这些是世界各地的开发者开发属于他们自己的微服务的主要原因吗?《微服务 2020 研究现状》 [7] 披露了全球开发者如何构建他们的微服务,以及他们对微服务的看法。这份报告是在来自欧洲、北美、中南美洲、中东、东南亚、澳大利亚和新西兰的 660 名微服务专家的帮助下完成的。下表列出了微服务成熟度相关问题的平均评分 [7:1]

分类平均得分(满分为5分)
创建新项目3.8
维护与调试3.4
工作效率3.9
解决可扩展性问题4.3
解决性能问题3.9
团队合作3.9

从上表可知,大部分专家都对使用微服务来解决可扩展性问题感到满意。与之相反的是,维护与调试对他们来说似乎是一个挑战。

从他们所使用的架构技术来说,大部分专家使用 Javascript/Typescript (大约 ⅔ 的微服务是使用这些语言构建的),其次使用的是 Java。

尽管有很多部署微服务的选择,但大多数专家使用 AWS(49%),其次是他们自己的服务器。另外,有 62% 的人更喜欢用 AWS Lambda 作为无服务器解决方案。

这些人所使用的大多数微服务都使用 HTTP 进行通信,其次是 events 和 gRPC。此外,大多数专家将 RabbitMQ 用于消息代理,其次是 Kafka 和 Redis。

而且,大多数人使用微服务持续集成(CI)。在报告中,87% 的受访者使用诸如 GitLab CI、Jenkins 或 GitHub Actions 等 CI 解决方案。

在 86% 的受访者中,最受欢迎的调试解决方案是日志,其中 27% 的受访者使用日志。

最后,大多数人认为微服务架构将成为更复杂的系统或后端开发的标准。

微服务的成功案例

许多公司已经从单体架构转向微服务架构。

亚马逊

在 2001 年,开发延迟、编码挑战和服务相互依赖性使得 亚马逊 Amazon 无法满足其不断增长的用户群的可扩展性需求。由于需要从头开始重构他们的单体架构,亚马逊将其单体架构应用程序拆分为小型的、独立的、针对服务的应用程序 [6:1] [8]

2001 年,在微服务这个词开始流行之前的几年,亚马逊决定改用微服务。这一变化使得亚马逊开发了好几种支持微服务架构的解决方案,比如亚马逊 AWS。随着对微服务的快速增长和适应,亚马逊成为全球市值最高的公司,截至 2020 年 7 月 1 日,亚马逊市值为 1.433 万亿美元 [9]

奈飞

奈飞 Netflix 于 2007 年开始提供电影流媒体服务,到了 2008 年,它也面临着规模扩张的挑战。期间,他们经历了一次严重的数据库损坏,在三天之内,他们不能将 DVD 发送给他们的会员 [10] 。这一事故使他们意识到需要将单点故障(如关系数据库)转向云中更可伸缩和更可靠的分布式系统。于是 2009 年,奈飞开始将其单体架构的应用重构为微服务。他们首先将其非面向客户的电影编码平台迁移到云端作为独立的微服务运行 [11] 。在改用微服务之后,使奈飞能够解决扩展性挑战和服务中断的问题。并且它还允许他们按照每个流数据而不是数据中心的成本来降低成本 [10:1] 。今天,奈飞每天向 190 个国家的 1.39 亿订户发送约 2.5 亿小时的内容 [11:1]

Uber

在推出 Uber 服务之后,他们在开发和发布新功能、修复 bug,以及迅速整合新的变化方面遇到了困难。因此,他们决定改用微服务,并将应用程序结构拆分为基于云的微服务。换句话说,Uber 为每个功能创建了一个微服务,比如乘客管理和出行管理。转向微服务给 Uber 带来了很多好处,比如对每项服务的所有权都有一个清晰的概念。这提高了服务访问的速度和质量,通过允许团队只关注他们需要扩展的服务,在更新虚拟服务的同时而不中断其他服务,实现了更可靠的容错,从而促进了快速扩展 [11:2]

这就是可扩展性!

关于如何提供可伸缩性的一个很好的例子是看看中国。中国人口众多,必须通过创造和试验新的解决方案来适应规模化的新挑战。统计数据显示,中国目前为大约 9 亿互联网用户提供服务 [12] 。2019 年“双十一”期间(相当于国外的黑色星期五),阿里巴巴旗下各购物平台的交易峰值为每秒 544000 笔交易。阿里云处理的数据总量约为 970 PB [13] 。那么,这些数量的用户在技术上意味着什么呢?

为了解决可伸缩性问题,许多技术应运而生。例如,Tars 由腾讯于 2008 年创建,2018 年贡献给 Linux 基金会。它也在被大规模使用,并在 10 年内得到了很大的提升 [14] 。TARS 是开源的,许多组织都在大力贡献和扩展框架的特性和价值 [14:1] 。TARS 支持多种编程语言,包括 C++、Golang、java、node.js、PHP 和 Python;它可以快速构建系统并自动生成代码,使开发人员能够专注于业务逻辑,从而有效地提高操作效率。TARS 已广泛应用于腾讯的 QQ、微信社交网络、金融服务、边缘计算、汽车、视频、网络游戏、地图、应用市场、安全等诸多核心业务。在 2020 三月,TARS 项目转变为 TARS 基金会,这是一个开源微服务基金会,在建立开放式微服务平台的社区方面中,致力于提升社区贡献和成员的快速增长 [14:2]

一定要看看 Linux 基金会新的免费培训课程:《用 TARS 构建微服务平台

关于作者:

Isabella Ferreira 是 Linux 基金会旗下的开源微服务基金会 TARS 基金会的布道师

Mark Shan(单致豪)是腾讯开源联盟的主席,也是 TARS 基金会的董事会主席。

本篇 Linux 基金会白金赞助商内容由腾讯贡献。

  1. https://martinfowler.com/articles/microservices.html#footnote-etymology ↩︎
  2. https://www.charterglobal.com/five-microservices-trends-in-2020/ ↩︎ ↩︎
  3. https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9 ↩︎ ↩︎
  4. https://whatis.techtarget.com/definition/monolithic-architecture ↩︎
  5. https://www.leanix.net/en/blog/a-brief-history-of-microservices ↩︎
  6. https://www.plutora.com/blog/understanding-microservices ↩︎ ↩︎
  7. https://tsh.io/state-of-microservices/#ebook ↩︎ ↩︎
  8. https://thenewstack.io/led-amazon-microservices-architecture/ ↩︎
  9. https://ycharts.com/companies/AMZN/market_cap ↩︎
  10. https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration ↩︎ ↩︎
  11. https://blog.dreamfactory.com/microservices-examples/ ↩︎ ↩︎ ↩︎
  12. https://www.statista.com/statistics/265140/number-of-internet-users-in-china/ ↩︎
  13. https://interconnected.blog/china-scale-technology-sandbox/ ↩︎
  14. https://www.linuxfoundation.org/blog/2020/03/the-tars-foundation-the-formation-of-a-microservices-ecosystem/ ↩︎ ↩︎ ↩︎

via: https://www.linux.com/news/the-state-of-the-art-of-microservices-in-2020/

作者:Linux.com 选题:lujun9972 译者:zhangxiangping 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出