分类 观点 下的文章

传统观念中的领导者总是强壮、大胆、果决的。我也确实见过一些拥有这些特点的领导者。但更多时候,领导者也许看起来比传统印象中的领导者要更脆弱些,他们内心有很多这样的疑问:我的决策正确吗?我真的适合这个职位吗?我有没有在做最该做的事情?

解决这些问题的方法是把问题说出来。把问题憋在心里只会助长它们,一名开明的领导者更倾向于把自己的脆弱之处暴露出来,这样我们才能从有过相同经验的人那里得到慰藉。

为了证明这个观点,我来讲一个故事。

一个扰人的想法

假如你在教育领域工作,你会发现发现大家更倾向于创造一个包容性的环境 —— 一个鼓励多样性繁荣发展的环境。长话短说,我一直以来都认为自己是出于营造包容性环境的考量,而进行的“多样性雇佣”,意思就是人事雇佣我看重的是我的性别而非能力,这个想法一直困扰着我。随之而来的开始自我怀疑:我真的是这个岗位的最佳人选吗?还是只是因为我是个女人?许多年来,我都认为公司雇佣我是因为我的能力最好。但如今却发现,对那些雇主们来说,与我的能力相比,他们似乎更关注我的性别。

我开解自己:我到底是因为什么被雇佣并不重要,我知道我是这个职位的最佳人选而且我会用实际行动去证明。我工作很努力,达到过预期,也犯过错,也收获了很多,我做了一个老板想要自己雇员做的一切事情。

但那个“多样性雇佣”问题的阴影并未因此散去。我无法摆脱它,甚至回避一切与之相关的话题如蛇蝎,最终意识到自己拒绝谈论它意味着我能做的只有直面它。如果我继续回避这个问题,早晚会影响到我的工作,这是我最不希望看到的。

倾诉心中的困扰

直接谈论多样性和包容性这个话题有点尴尬,在进行自我剖析之前有几个问题需要考虑:

  • 我们能够相信我们的同事,能够在他们面前表露脆弱吗?
  • 一个团队的领导者在同事面前表露脆弱合适吗?
  • 如果我玩脱了呢?会不会影响我的工作?

于是我和一位主管在午餐时间进行了一场小型的 Q&A 会议,这位主管负责着集团很多领域,并且以正直坦率著称。一位女同事问他,“我是因为多样性才被招进来的吗?”,他停下手头工作花了很长时间和一屋子女性员工解释了这件事,我不想复述他讲话的全部内容,我只说对我触动最大的几句:如果你知道自己能够胜任这个职位,并且面试很顺利,那么不必质疑招聘的结果。每个怀疑自己是因为多样性雇佣进公司的人私下都有自己的问题,你不必重蹈他们的覆辙。

完毕。

我很希望我能由衷地说我放下这个问题了,但事实上我没有。这问题挥之不去:万一我就是被破格录取的那个呢?万一我就是多样性雇佣的那个呢?我认识到我不能避免地反复思考这些问题。

几周后我和这位主管进行了一次一对一谈话,在谈话的末尾,我提到作为一位女性,自己很欣赏他那番对于多样性和包容性的坦率发言。当得知领导很有交流的意愿时,谈论这种话题变得轻松许多。我也向他提出了最初的问题,“我是因为多样性才被雇佣的吗?”,他回答得很干脆:“我们谈论过这个问题。”谈话后我意识到,我急切地想找人谈论这些需要勇气的问题,其实只是因为我需要有一个人的关心、倾听和好言劝说。

但正因为我有展露脆弱的勇气——去和那位主管谈论我的问题——我承受我的秘密困扰的能力提高了。我觉得身轻如燕,我开始组织各种对话,主要围绕着内隐偏见及其引起的一系列问题、怎样增加自身的包容性和多样性的表现等。通过这些经历,我发现每个人对于多样性都有不同的认识,如果我只囿于自己的秘密,我不会有机会组织参与这些精彩的对话。

我有谈论内心脆弱的勇气,我希望你也有。

我们可以谈谈那些影响我们领导力的秘密,这样从任何意义上来说,我们距离成为一位开明的领导就近了一些。那么适当示弱有帮助你成为更好的领导者吗?

作者简介

Angela Robertson 是微软的一名高管。她和她的团队对社群互助有着极大热情,并参与开源工作。在加入微软之前,Angela 就职于红帽公司。


via: https://opensource.com/article/17/12/how-allowing-myself-be-vulnerable-made-me-better-leader

作者:Angela Robertson 译者:Valoniakim 校对:wxy

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

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

本文是《代码英雄》系列播客第一季(1):操作系统战争(上)音频脚本。

Saron Yitbarek:有些故事如史诗般,惊险万分,在我脑海中似乎出现了星球大战电影开头的爬行文字。你知道的,就像——

配音:“第一集,操作系统大战”

Saron Yitbarek:是的,就像那样子。

配音:这是一个局势紧张加剧的时期。 比尔·盖茨 Bill Gates 史蒂夫·乔布斯 Steve Jobs 的帝国发起了一场无可避免的专有软件之战。[00:00:30] 盖茨与 IBM 结成了强大的联盟,而乔布斯则拒绝了对它的硬件和操作系统开放授权。他们争夺统治地位的争斗在一场操作系统战争中席卷了整个银河系。与此同时,这些帝王们所不知道的偏远之地,开源的反叛者们开始集聚。

Saron Yitbarek:好吧。这也许有点戏剧性,但当我们谈论上世纪八九十年代和 2000 年代的操作系统之争时,这也不算言过其实。[00:01:00] 确实曾经发生过一场史诗级的统治之战。史蒂夫·乔布斯和比尔·盖茨确实掌握着数十亿人的命运。掌控了操作系统,你就掌握了绝大多数人使用计算机的方式、互相通讯的方式、获取信息的方式。我可以一直罗列下去,不过你知道我的意思。掌握了操作系统,你就是帝王。

我是 Saron Yitbarek,你现在收听的是代码英雄,一款红帽公司原创的博客节目。[00:01:30] 你问,什么是 代码英雄 Command Line Hero ?嗯,如果你愿意创造而不仅仅是使用,如果你相信开发者拥有构建美好未来的能力,如果你希望拥有一个大家都有权利表达科技如何塑造生活的世界,那么你,我的朋友,就是一位代码英雄。在本系列节目中,我们将为你带来那些“白码起家”(LCTT 译注:原文是 “from the command line up”,应该是演绎自 “from the ground up”——白手起家)改变技术的程序员故事。[00:02:00] 那么我是谁,凭什么指导你踏上这段艰苦的旅程?Saron Yitbarek 是哪根葱?嗯,事实上我觉得我跟你差不多。我是一名面向初学者的开发人员,我做的任何事都依赖于开源软件,我的世界就是如此。通过在博客中讲故事,我可以跳出无聊的日常工作,鸟瞰全景,希望这对你也一样有用。

我迫不及待地想知道,开源技术从何而来?我的意思是,我对 林纳斯·托瓦兹 Linus Torvalds 和 Linux ® 的荣耀有一些了解,[00:02:30] 我相信你也一样,但是说真的,开源并不是一开始就有的,对吗?如果我想发自内心的感激这些最新、最棒的技术,比如 DevOps 和容器之类的,我感觉我对那些早期的开发者缺乏了解,我有必要了解这些东西来自何处。所以,让我们暂时先不用担心内存泄露和缓冲溢出。我们的旅程将从操作系统之战开始,这是一场波澜壮阔的桌面控制之战。[00:03:00] 这场战争亘古未有,因为:首先,在计算机时代,大公司拥有指数级的规模优势;其次,从未有过这么一场控制争夺战是如此变化多端。比尔·盖茨和史蒂夫·乔布斯? 他们也不知道结果会如何,但是到目前为止,这个故事进行到一半的时候,他们所争夺的所有东西都将发生改变、进化,最终上升到云端。

[00:03:30] 好的,让我们回到 1983 年的秋季。还有六年我才出生。那时候的总统还是 罗纳德·里根 Ronald Reagan ,美国和苏联扬言要把地球拖入核战争之中。在檀香山(火奴鲁鲁)的市政中心正在举办一年一度的苹果公司销售会议。一群苹果公司的员工正在等待史蒂夫·乔布斯上台。他 28 岁,热情洋溢,看起来非常自信。乔布斯很严肃地对着麦克风说他邀请了三个行业专家来就软件进行了一次小组讨论。[00:04:00] 然而随后发生的事情你肯定想不到。超级俗气的 80 年代音乐响彻整个房间。一堆多彩灯管照亮了舞台,然后一个播音员的声音响起-

配音:女士们,先生们,现在是麦金塔软件的约会游戏时间。

Saron Yitbarek:乔布斯的脸上露出一个大大的笑容,台上有三个 CEO 都需要轮流向他示好。这基本上就是 80 年代钻石王老五,不过是科技界的。[00:04:30] 两个软件大佬讲完话后,然后就轮到第三个人讲话了。仅此而已不是吗?是的。新面孔比尔·盖茨带着一个大大的遮住了半张脸的方框眼镜。他宣称在 1984 年,微软的一半收入将来自于麦金塔软件。他的这番话引来了观众热情的掌声。[00:05:00] 但是他们不知道的是,在一个月后,比尔·盖茨将会宣布发布 Windows 1.0 的计划。你永远也猜不到乔布斯正在跟苹果未来最大的敌人打情骂俏。但微软和苹果即将经历科技史上最糟糕的婚礼。他们会彼此背叛、相互毁灭,但又深深地、痛苦地捆绑在一起。

James Allworth:[00:05:30] 我猜从哲学上来讲,一个更理想化、注重用户体验高于一切,是一个一体化的组织,而微软则更务实,更模块化 ——

Saron Yitbarek:这位是 James Allworth。他是一位多产的科技作家,曾在苹果零售的企业团队工作。注意他给出的苹果的定义,一个一体化的组织,那种只对自己负责的公司,一个不想依赖别人的公司,这是关键。

James Allworth:[00:06:00] 苹果是一家一体化的公司,它希望专注于令人愉悦的用户体验,这意味着它希望控制整个技术栈以及交付的一切内容:从硬件到操作系统,甚至运行在操作系统上的应用程序。当新的创新、重要的创新刚刚进入市场,而你需要横跨软硬件,并且能够根据自己意愿和软件的革新来改变硬件时,这是一个优势。例如 ——,

Saron Yitbarek:[00:06:30] 很多人喜欢这种一体化的模式,并因此成为了苹果的铁杆粉丝。还有很多人则选择了微软。让我们回到檀香山的销售会议上,在同一场活动中,乔布斯向观众展示了他即将发布的超级碗广告。你可能已经亲眼见过这则广告了。想想 乔治·奥威尔 George Orwell 的 《一九八四》。在这个冰冷、灰暗的世界里,无意识的机器人正在独裁者的投射凝视下徘徊。[00:07:00] 这些机器人就像是 IBM 的用户们。然后,代表苹果公司的漂亮而健美的 安娅·梅杰 Anya Major 穿着鲜艳的衣服跑过大厅。她向着大佬们的屏幕猛地投出大锤,将它砸成了碎片。老大哥的咒语解除了,一个低沉的声音响起,苹果公司要开始介绍麦金塔了。

配音:这就是为什么现实中的 1984 跟小说《一九八四》不一样了。

Saron Yitbarek:是的,现在回顾那则广告,认为苹果是一个致力于解放大众的自由斗士的想法有点过分了。但这件事触动了我的神经。[00:07:30] Ken Segal 曾在为苹果制作这则广告的广告公司工作过。在早期,他为史蒂夫·乔布斯做了十多年的广告。

Ken Segal:1984 这则广告的风险很大。事实上,它的风险太大,以至于苹果公司在看到它的时候都不想播出它。你可能听说了史蒂夫喜欢它,但苹果公司董事会的人并不喜欢它。事实上,他们很愤怒,这么多钱被花在这么一件事情上,以至于他们想解雇广告代理商。[00:08:00] 史蒂夫则为我们公司辩护。

Saron Yitbarek:乔布斯,一如既往地,慧眼识英雄。

Ken Segal:这则广告在公司内、在业界内都引起了共鸣,成为了苹果产品的代表。无论人们那天是否有在购买电脑,它都带来了一种持续了一年又一年的影响,并有助于定义这家公司的品质:我们是叛军,我们是拿着大锤的人。

Saron Yitbarek:[00:08:30] 因此,在争夺数十亿潜在消费者心智的过程中,苹果公司和微软公司的帝王们正在学着把自己塑造成救世主、非凡的英雄、一种对生活方式的选择。但比尔·盖茨知道一些苹果难以理解的事情。那就是在一个相互连接的世界里,没有人,即便是帝王,也不能独自完成任务。

[00:09:00] 1985 年 6 月 25 日。盖茨给当时的苹果 CEO John Scully 发了一份备忘录。那是一个迷失的年代。乔布斯刚刚被逐出公司,直到 1996 年才回到苹果。也许正是因为乔布斯离开了,盖茨才敢写这份东西。在备忘录中,他鼓励苹果授权制造商分发他们的操作系统。我想读一下备忘录的最后部分,让你们知道这份备忘录是多么的有洞察力。[00:09:30] 盖茨写道:“如果没有其他个人电脑制造商的支持,苹果现在不可能让他们的创新技术成为标准。苹果必须开放麦金塔的架构,以获得快速发展和建立标准所需的支持。”换句话说,你们不要再自己玩自己的了。你们必须有与他人合作的意愿。你们必须与开发者合作。

[00:10:00] 多年后你依然可以看到这条哲学思想,当微软首席执行官 史蒂夫·鲍尔默 Steve Ballmer 上台做主题演讲时,他开始大喊:“开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者。”你懂我的意思了吧。微软喜欢开发人员。虽然目前(LCTT 译注:本播客发布于 2018 年初)他们不打算与这些开发人员共享源代码,但是他们确实想建立起整个合作伙伴生态系统。[00:10:30] 而当比尔·盖茨建议苹果公司也这么做时,如你可能已经猜到的,这个想法就被苹果公司抛到了九霄云外。他们的关系产生了间隙,五个月后,微软发布了 Windows 1.0。战争开始了。

开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者,开发者。

[00:11:00] 你正在收听的是来自红帽公司的原创播客《代码英雄》。本集是第一集,我们将回到过去,重温操作系统战争的史诗故事,我们将会发现,科技巨头之间的战争是如何为我们今天所生活的开源世界扫清道路的

好的,让我们先来个背景故事吧。如果你已经听过了,那么请原谅我,但它很经典。当时是 1979 年,史蒂夫·乔布斯开车去 帕洛阿尔托 Palo Alto 施乐公园研究中心 Xerox Park research center [00:11:30] 那里的工程师一直在为他们所谓的图形用户界面开发一系列的元素。也许你听说过。它们有菜单、滚动条、按钮、文件夹和重叠的窗口。这是对计算机界面的一个美丽的新设想。这是前所未有的。作家兼记者 Steve Levy 会谈到它的潜力。

Steven Levy:[00:12:00] 对于这个新界面来说,有很多令人激动的地方,它比以前的交互界面更友好,以前用的所谓的命令行 —— 你和电脑之间的交互方式跟现实生活中的交互方式完全不同。鼠标和电脑上的图像让你可以做到像现实生活中的交互一样,你可以像指向现实生活中的东西一样指向电脑上的东西。这让事情变得简单多了。你无需要记住所有那些命令。

Saron Yitbarek:[00:12:30] 不过,施乐的高管们并没有意识到他们正坐在金矿上。一如既往地,工程师比主管们更清楚它的价值。因此那些工程师,当被要求向乔布斯展示所有这些东西是如何工作时,有点紧张。然而这是毕竟是高管的命令。乔布斯觉得,用他的话来说,“这个产品天才本来能够让施乐公司垄断整个行业,可是它最终会被公司的经营者毁掉,因为他们对产品的好坏没有概念。”[00:13:00] 这话有些苛刻,但是,乔布斯带着一卡车施乐高管错过的想法离开了会议。这几乎包含了他需要革新桌面计算体验的所有东西。1983 年,苹果发布了 Lisa 电脑,1984 年又发布了 Mac 电脑。这些设备的创意是抄袭自施乐公司的。

让我感兴趣的是,乔布斯对控诉他偷了图形用户界面的反应。他对此很冷静。他引用毕加索的话:“好的艺术家抄袭,伟大的艺术家偷窃。”他告诉一位记者,“我们总是无耻地窃取伟大的创意。”[00:13:30] 伟大的艺术家偷窃,好吧,我的意思是,我们说的并不是严格意义上的“偷窃”。没人拿到了专有的源代码并公然将其集成到他们自己的操作系统中去。这要更温和些,更像是创意的借用。这就难控制的多了,就像乔布斯自己即将学到的那样。传奇的软件奇才、真正的代码英雄 Andy Hertzfeld 就是麦金塔开发团队的最初成员。

Andy Hertzfeld:[00:14:00] 是的,微软是我们的第一个麦金塔电脑软件合作伙伴。当时,我们并没有把他们当成是竞争对手。他们是苹果之外,我们第一家交付麦金塔电脑原型的公司。我通常每周都会和微软的技术主管聊一次。他们是第一个尝试我们所编写软件的外部团队。[00:14:30] 他们给了我们非常重要的反馈,总的来说,我认为我们的关系非常好。但我也注意到,在我与技术主管的交谈中,他开始问一些系统实现方面的问题,而他本无需知道这些,我觉得,他们想要复制麦金塔电脑。我很早以前就向史蒂夫·乔布斯反馈过这件事,但在 1983 年秋天,这件事达到了高潮。[00:15:00] 我们发现,他们在 1983 年 11 月的 COMDEX 上发布了 Windows,但却没有提前告诉我们。对此史蒂夫·乔布斯勃然大怒。他认为那是一种背叛。

Saron Yitbarek:随着新版 Windows 的发布,很明显,微软从苹果那里学到了苹果从施乐那里学来的所有想法。乔布斯很易怒。他的关于伟大艺术家如何偷窃的毕加索名言被别人学去了,而且恐怕盖茨也正是这么做的。[00:15:30] 据报道,当乔布斯怒斥盖茨偷了他们的东西时,盖茨回应道:“史蒂夫,我觉得这更像是我们都有一个叫施乐的富有邻居,我闯进他家偷电视机,却发现你已经偷过了”。苹果最终以窃取 GUI 的外观和风格为名起诉了微软。这个案子持续了好几年,但是在 1993 年,第 9 巡回上诉法院的一名法官最终站在了微软一边。[00:16:00] Vaughn Walker 法官宣布外观和风格不受版权保护。这是非常重要的。这一决定让苹果在无法垄断桌面计算的界面。很快,苹果短暂的领先优势消失了。以下是 Steven Levy 的观点。

Steven Levy:他们之所以失去领先地位,不是因为微软方面窃取了知识产权,而是因为他们无法巩固自己在上世纪 80 年代拥有的更好的操作系统的优势。坦率地说,他们的电脑索价过高。[00:16:30] 因此微软从 20 世纪 80 年代中期开始开发 Windows 系统,但直到 1990 年开发出的 Windows 3,我想,它才真正算是一个为黄金时期做好准备的版本,才真正可供大众使用。[00:17:00] 从此以后,微软能够将数以亿计的用户迁移到图形界面,而这是苹果无法做到的。虽然苹果公司有一个非常好的操作系统,但是那已经是 1984 年的产品了。

Saron Yitbarek:现在微软主导着操作系统的战场。他们占据了 90% 的市场份额,并且针对各种各样的个人电脑进行了标准化。操作系统的未来看起来会由微软掌控。此后发生了什么?[00:17:30] 1997 年,波士顿 Macworld 博览会上,你看到了一个几近破产的苹果,一个谦逊的多的史蒂夫·乔布斯走上舞台,开始谈论伙伴关系的重要性,特别是他们与微软的新型合作伙伴关系。史蒂夫·乔布斯呼吁双方缓和关系,停止火拼。微软将拥有巨大的市场份额。从表面看,我们可能会认为世界和平了。但当利益如此巨大时,事情就没那么简单了。[00:18:00] 就在苹果和微软在数十年的争斗中伤痕累累、最终败退到死角之际,一名 21 岁的芬兰计算机科学专业学生出现了。几乎是偶然地,他彻底改变了一切。

我是 Saron Yitbarek,这里是代码英雄。

正当某些科技巨头正忙着就专有软件相互攻击时,自由软件和开源软件的新领军者如雨后春笋般涌现。[00:18:30] 其中一位优胜者就是 理查德·斯托尔曼 Richard Stallman 。你也许对他的工作很熟悉。他想要有自由软件和自由社会。这就像言论自由一样的 自由 free ,而不是像免费啤酒一样的 免费 free 。早在 80 年代,斯托尔曼就发现,除了昂贵的专有操作系统(如 UNIX)外,就没有其他可行的替代品。因此他决定自己做一个。斯托尔曼的 自由软件基金会 Free Software Foundation 开发了 GNU,当然,它的意思是 “GNU’s not UNIX”。它将是一个像 UNIX 一样的操作系统,但不包含所有的 UNIX 代码,而且用户可以自由共享。

[00:19:00] 为了让你体会到上世纪 80 年代自由软件概念的重要性,从不同角度来说拥有 UNIX 代码的两家公司, AT&T 贝尔实验室 AT&T Bell Laboratories 以及 UNIX 系统实验室 UNIX System Laboratories 威胁将会起诉任何看过 UNIX 源代码后又创建自己操作系统的人。这些人是次级专利所属。[00:19:30] 用这两家公司的话来说,所有这些程序员都在“精神上受到了污染”,因为他们都见过 UNIX 代码。在 UNIX 系统实验室和 伯克利软件设计公司 Berkeley Software Design 之间的一个著名的法庭案例中,有人认为任何功能类似的系统,即使它本身没有使用 UNIX 代码,也侵犯版权。Paul Jones 当时是一名开发人员。他现在是数字图书馆 ibiblio.org 的主管。

Paul Jones:[00:20:00] 任何看过代码的人都受到了精神污染是他们的观点。因此几乎所有在安装有与 UNIX 相关操作系统的电脑上工作过的人以及任何在计算机科学部门工作的人都受到精神上的污染。因此,在 USENIX 的一年里,我们都得到了一写带有红色字母的白色小别针,上面写着“精神受到了污染”。我们很喜欢带着这些别针到处走,以表达我们跟着贝尔实验室混,因为我们的精神受到了污染。

Saron Yitbarek:[00:20:30] 整个世界都被精神污染了。想要保持纯粹、保持事物的美好和专有的旧哲学正变得越来越不现实。正是在这被污染的现实中,历史上最伟大的代码英雄之一诞生了,他是一个芬兰男孩,名叫 林纳斯·托瓦兹 Linus Torvalds 。如果这是《星球大战》,那么林纳斯·托瓦兹就是我们的 卢克·天行者 Luke Skywalker 。他是赫尔辛基大学一名温文尔雅的研究生。[00:21:00] 有才华,但缺乏大志。典型的被逼上梁山的英雄。和其他年轻的英雄一样,他也感到沮丧。他想把 386 处理器整合到他的新电脑中。他对自己的 IBM 兼容电脑上运行的 MS-DOS 操作系统并不感冒,也负担不起 UNIX 软件 5000 美元的价格,而只有 UNIX 才能让他自由地编程。解决方案是托瓦兹在 1991 年春天基于 MINIX 开发了一个名为 Linux 的操作系统内核。他自己的操作系统内核。

Steven Vaughan-Nichols:[00:21:30] 林纳斯·托瓦兹真的只是想找点乐子而已。

Saron Yitbarek:Steven Vaughan-Nichols 是 ZDNet.com 的特约编辑,而且他从科技行业出现以来就一直在写科技行业相关的内容。

Steven Vaughan-Nichols:当时有几个类似的操作系统。他最关注的是一个名叫 MINIX 的操作系统,MINIX 旨在让学生学习如何构建操作系统。林纳斯看到这些,觉得很有趣,但他想建立自己的操作系统。[00:22:00] 所以,它实际上始于赫尔辛基的一个 DIY 项目。一切就这样开始了,基本上就是一个大孩子在玩耍,学习如何做些什么。[00:22:30] 但不同之处在于,他足够聪明、足够执着,也足够友好,让所有其他人都参与进来,然后他开始把这个项目进行到底。27 年后,这个项目变得比他想象的要大得多。

Saron Yitbarek:到 1991 年秋季,托瓦兹发布了 10000 行代码,世界各地的人们开始评头论足,然后进行优化、添加和修改代码。[00:23:00] 对于今天的开发人员来说,这似乎很正常,但请记住,在那个时候,像这样的开放协作是对微软、苹果和 IBM 已经做的很好的整个专有系统的道德侮辱。随后这种开放性被奉若神明。托瓦兹将 Linux 置于 GNU 通用公共许可证(GPL)之下。曾经保障斯托尔曼的 GNU 系统自由的许可证现在也将保障 Linux 的自由。Vaughan-Nichols 解释道,这种融入到 GPL 的重要性怎么强调都不过分,它基本上能永远保证软件的自由和开放性。

Steven Vaughan-Nichols:[00:23:30] 事实上,根据 Linux 所遵循的许可协议,即 GPL 第 2 版,如果你想贩卖 Linux 或者向全世界展示它,你必须与他人共享代码,所以如果你对其做了一些改进,仅仅给别人使用是不够的。事实上你必须和他们分享所有这些变化的具体细节。然后,如果这些改进足够好,就会被 Linux 所吸收。

Saron Yitbarek:[00:24:00] 事实证明,这种公开的方式极具吸引力。 埃里克·雷蒙德Eric Raymond 是这场运动的早期传道者之一,他在他那篇著名的文章中写道:“微软和苹果这样的公司一直在试图建造软件大教堂,而 Linux 及类似的软件则提供了一个由不同议程和方法组成的巨大集市,集市比大教堂有趣多了。”

tormy Peters:我认为在那个时候,真正吸引人的是人们终于可以把控自己的世界了。

Saron Yitbarek:Stormy Peters 是一位行业分析师,也是自由和开源软件的倡导者。

Stormy Peters:[00:24:30] 当开源软件第一次出现的时候,所有的操作系统都是专有的。如果不使用专有软件,你甚至不能添加打印机,你不能添加耳机,你不能自己开发一个小型硬件设备,然后让它在你的笔记本电脑上运行。你甚至不能放入 DVD 并复制它,因为你不能改变软件,即使你拥有这张 DVD,你也无法复制它。[00:25:00] 你无法控制你购买的硬件/软件系统。你不能从中创造出任何新的、更大的、更好的东西。这就是为什么开源操作系统在一开始就如此重要的原因。我们需要一个开源协作环境,在那里我们可以构建更大更好的东西。

Saron Yitbarek:请注意,Linux 并不是一个纯粹的平等主义乌托邦。林纳斯·托瓦兹不会批准对内核的所有修改,而是主导了内核的变更。他安排了十几个人来管理内核的不同部分。[00:25:30] 这些人也会信任自己下面的人,以此类推,形成信任金字塔。变化可能来自任何地方,但它们都是经过判断和策划的。

然而,考虑到到林纳斯的 DIY 项目一开始是多么的简陋和随意,这项成就令人十分惊讶。他完全不知道自己就是这一切中的卢克·天行者。当时他只有 21 岁,一半的时间都在编程。但是当魔盒第一次被打开,人们开始给他反馈。[00:26:00] 几十个,然后几百个,成千上万的贡献者。有了这样的众包基础,Linux 很快就开始成长。真的成长得很快。甚至最终引起了微软的注意。他们的首席执行官 史蒂夫·鲍尔默 Steve Ballmer 将 Linux 称为是“一种癌症,从知识产权得角度来看,它传染了接触到得任何东西 ”。Steven Levy 将会描述 Ballmer 的由来。

Steven Levy:[00:26:30] 一旦微软真正巩固了它的垄断地位,而且它也确实被联邦法院判定为垄断,他们将会对任何可能对其构成威胁的事情做出强烈反应。因此,既然他们对软件收费,很自然得,他们将自由软件得出现看成是一种癌症。他们试图提出一个知识产权理论,来解释为什么这对消费者不利。

Saron Yitbarek:[00:27:00] Linux 在不断传播,微软也开始担心起来。到了 2006 年,Linux 成为仅次于 Windows 的第二大常用操作系统,全球约有 5000 名开发人员在使用它。5000 名开发者。还记得比尔·盖茨给苹果公司的备忘录吗?在那份备忘录中,他向苹果公司的员工们论述了与他人合作的重要性。事实证明,开源将把伙伴关系的概念提升到一个全新的水平,这是比尔·盖茨从未预见到的。

[00:27:30] 我们一直在谈论操作系统之间的大战,但是到目前为止,并没有怎么提到无名英雄和开发者们。在下次的代码英雄中,情况就不同了。第二集讲的是操作系统大战的第二部分,是关于 Linux 崛起的。业界醒悟过来,认识到了开发人员的重要性。这些开源反叛者变得越来越强大,战场从桌面转移到了服务器领域。[00:28:00] 这里有商业间谍活动、新的英雄人物,还有科技史上最不可思议的改变。这一切都在操作系统大战的后半集内达到了高潮。

要想免费自动获得新一集的代码英雄,请点击订阅苹果播客、Spotify、谷歌 Play,或其他应用获取该播客。在这一季剩下的时间里,我们将参观最新的战场,相互争斗的版图,这里是下一代的代码英雄留下印记的地方。[00:28:30] 更多信息,请访问 https://redhat.com/commandlineheroes 。我是 Saron Yitbarek。下次之前,继续编码。


via: https://www.redhat.com/en/command-line-heroes/season-1/os-wars-part-1

作者:redhat 选题:lujun9972 译者:lujun9972 校对:wxy

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

这比较复杂。

作为一个经常管理软件开发团队的人,多年来我一直关注度量指标。一次次,我发现自己领导团队使用一个又一个的项目平台(例如 Jira、GitLab 和 Rally)生成了大量可测量的数据。从那时起,我已经及时投入了大量时间从记录平台中提取了有用的指标,并采用了一种我们可以理解的格式,然后使用这些指标对开发的许多方面做出更好的选择。

今年早些时候,我有幸在 Linux 基金会遇到了一个名为 开源软件社区健康分析 Community Health Analytics for Open Source Software (CHAOSS)的项目。该项目侧重于从各种来源收集和丰富指标,以便开源社区的利益相关者可以衡量他们项目的健康状况。

CHAOSS 介绍

随着我对该项目的基本指标和目标越来越熟悉,一个问题在我的脑海中不断翻滚。什么是“健康”的开源项目,由谁来定义?

特定角色的人认为健康的东西可能另一个角色的人就不会这样认为。似乎可以用 CHAOSS 收集的细粒度数据进行市场细分实验,重点关注对特定角色可能最有意义的背景问题,以及 CHAOSS 收集哪些指标可能有助于回答这些问题。

CHAOSS 项目创建并维护了一套开源应用程序和度量标准定义,使得这个实验具有可能性,这包括:

  • 许多基于服务器的应用程序,用于收集、聚合和丰富度量标准(例如 Augur 和 GrimoireLab)。
  • ElasticSearch、Kibana 和 Logstash(ELK)的开源版本。
  • 身份服务、数据分析服务和各种集成库。

在我过去的一个程序中,有六个团队从事于不同复杂程度的项目,我们找到了一个简洁的工具,它允许我们从简单(或复杂)的 JQL 语句中创建我们想要的任何类型的指标,然后针对这些指标开发计算。在我们注意到之前,我们仅从 Jira 中就提取了 400 多个指标,而且还有更多指标来自手动的来源。

在项目结束时,我们认定这 400 个指标中,大多数指标在以我们的角色做出决策时并不重要。最终,只有三个对我们非常重要:“缺陷去除效率”、“已完成的条目与承诺的条目”,以及“每个开发人员的工作进度”。这三个指标最重要,因为它们是我们对自己、客户和团队成员所做出的承诺,因此是最有意义的。

带着这些通过经验得到的教训和对什么是健康的开源项目的问题,我跳进了 CHAOSS 社区,开始建立一套角色,以提供一种建设性的方法,从基于角色的角度回答这个问题。

CHAOSS 是一个开源项目,我们尝试使用民主共识来运作。因此,我决定使用 组成分子 constituent 这个词而不是利益相关者,因为它更符合我们作为开源贡献者的责任,以创建更具共生性的价值链。

虽然创建此组成模型的过程采用了特定的“目标-问题-度量”方法,但有许多方法可以进行细分。CHAOSS 贡献者已经开发了很好的模型,可以按照矢量进行细分,例如项目属性(例如,个人、公司或联盟)和“失败容忍度”。在为 CHAOSS 开发度量定义时,每个模型都会提供建设性的影响。

基于这一切,我开始构建一个谁可能关心 CHAOSS 指标的模型,以及每个组成分子在 CHAOSS 的四个重点领域中最关心的问题:

在我们深入研究之前,重要的是要注意 CHAOSS 项目明确地将背景判断留给了实施指标的团队。什么是“有意义的”和“什么是健康的?”的答案预计会因团队和项目而异。CHAOSS 软件的现成仪表板尽可能地关注客观指标。在本文中,我们关注项目创始人、项目维护者和贡献者。

项目组成分子

虽然这绝不是这些组成分子可能认为重要的问题的详尽清单,但这些选择感觉是一个好的起点。以下每个“目标-问题-度量”标准部分与 CHAOSS 项目正在收集和汇总的指标直接相关。

现在,进入分析的第 1 部分!

项目创始人

作为项目创始人,我关心:

  • 我的项目对其他人有用吗?通过以下测量:

    • 随着时间推移有多少复刻?

      • 指标:存储库复刻数。
    • 随着时间的推移有多少贡献者?

      • 指标:贡献者数量。
    • 贡献净质量。

      • 指标:随着时间的推移提交的错误。
      • 指标:随着时间的回归。
    • 项目的财务状况。

      • 指标:随着时间的推移的捐赠/收入。
      • 指标:随着时间的推移的费用。
  • 我的项目对其它人的可见程度?

    • 有谁知道我的项目?别人认为它很整洁吗?

      • 指标:社交媒体上的提及、分享、喜欢和订阅的数量。
    • 有影响力的人是否了解我的项目?

      • 指标:贡献者的社会影响力。
    • 人们在公共场所对项目有何评价?是正面还是负面?

      • 指标:跨社交媒体渠道的情感(关键字或 NLP)分析。
  • 我的项目可行性程度?

    • 我们有足够的维护者吗?该数字是随着时间的推移而上升还是下降?

      • 指标:维护者数量。
    • 改变速度如何随时间变化?

      • 指标:代码随时间的变化百分比。
      • 指标:拉取请求、代码审查和合并之间的时间。
  • 我的项目的多样化 & 包容性如何?

    • 我们是否拥有有效的公开行为准则(CoC)?

      • 度量标准: 检查存储库中的 CoC 文件。
    • 与我的项目相关的活动是否积极包容?

      • 指标:关于活动的票务政策和活动包容性行为的手动报告。
    • 我们的项目在可访问性上做的好不好?

      • 指标:验证发布的文字会议纪要。
      • 指标:验证会议期间使用的隐藏式字幕。
      • 指标:验证在演示文稿和项目前端设计中色盲可访问的素材。
  • 我的项目代表了多少价值

    • 我如何帮助组织了解使用我们的项目将节省多少时间和金钱(劳动力投资)

      • 指标:仓库的议题、提交、拉取请求的数量和估计人工费率。
    • 我如何理解项目创建的下游价值的数量,以及维护我的项目对更广泛的社区的重要性(或不重要)?

      • 指标:依赖我的项目的其他项目数。
    • 为我的项目做出贡献的人有多少机会使用他们学到的东西来找到合适的工作岗位,以及在哪些组织(即生活工资)?

      • 指标:使用或贡献此库的组织数量。
      • 指标:使用此类项目的开发人员的平均工资。
      • 指标:与该项目匹配的关键字的职位发布计数。

项目维护者

作为项目维护者,我关心:

  • 我是高效的维护者吗?

    • 指标:拉取请求在代码审查之前等待的时间。
    • 指标:代码审查和后续拉取请求之间的时间。
    • 指标:我的代码审核中有多少被批准?
    • 指标:我的代码评论中有多少被拒绝或返工?
    • 指标:代码审查的评论的情感分析。
  • 我如何让更多人帮助我维护这件事?

    • 指标:项目贡献者的社交覆盖面数量。
  • 我们的代码质量随着时间的推移变得越来越好吗?

    • 指标:计算随着时间的推移引入的回归数量。
    • 指标:计算随着时间推移引入的错误数量。
    • 指标:错误归档、拉取请求、代码审查、合并和发布之间的时间。

项目开发者和贡献者

作为项目开发者或贡献者,我关心:

  • 我可以从为这个项目做出贡献中获得哪些有价值的东西,以及实现这个价值需要多长时间?

    • 指标:下游价值。
    • 指标:提交、代码审查和合并之间的时间。
  • 通过使用我在贡献中学到的东西来增加工作机是否有良好的前景?

    • 指标:生活工资。
  • 这个项目有多受欢迎?

    • 指标:社交媒体帖子、分享和收藏的数量。
  • 社区有影响力的人知道我的项目吗?

    • 指标:创始人、维护者和贡献者的社交范围。

通过创建这个列表,我们开始让 CHAOSS 更加丰满了,并且在今年夏天项目中首次发布该指标时,我迫不及待地想看看广泛的开源社区可能有什么其他伟大的想法,以及我们还可以从这些贡献中学到什么(并衡量!)。

其它角色

接下来,你需要了解有关其他角色(例如基金会、企业开源计划办公室、业务风险和法律团队、人力资源等)以及最终用户的目标问题度量集的更多信息。他们关心开源的不同事物。

如果你是开源贡献者或组成分子,我们邀请你来看看这个项目并参与社区活动!


via: https://opensource.com/article/19/8/measure-project

作者:Jon Lawrence 选题:lujun9972 译者:wxy 校对:wxy

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

“Linux 用户”这一定义已经拓展到了更大的范围,同时也发生了巨大的改变。

编者按: 本文更新于 2019 年 6 月 11 日下午 1:15:19,以更准确地反映作者对 Linux 社区中开放和包容的社区性的看法。

再有不到两年,Linux 内核就要迎来它 30 岁的生日了。让我们回想一下!1991 年的时候你在哪里?你出生了吗?那年我 13 岁!在 1991 到 1993 年间只推出了少数几款 Linux 发行版,至少它们中的三个:Slackware、Debian 和 Red Hat 为 Linux 运动发展提供了支柱

当年获得 Linux 发行版的副本,并在笔记本或服务器上进行安装和配置,和今天相比是很不一样的。当时是十分艰难的!也是令人沮丧的!如果你让能让它运行起来,就是一个了不起的成就!我们不得不与不兼容的硬件、设备上的配置跳线、BIOS 问题以及许多其他问题作斗争。甚至即使硬件是兼容的,很多时候,你仍然需要编译内核、模块和驱动程序才能让它们在你的系统上工作。

如果你当时经过过那些,你可能会表示赞同。有些读者甚至称它们为“美好的过往”,因为选择使用 Linux 意味着仅仅是为了让操作系统继续运行,你就必须学习操作系统、计算机体系架构、系统管理、网络,甚至编程。但我并不赞同他们的说法,窃以为:Linux 在 IT 行业带给我们的最让人惊讶的改变就是,它成为了我们每个人技术能力的基础组成部分!

将近 30 年过去了,无论是桌面和服务器领域 Linux 系统都有了脱胎换骨的变换。你可以在汽车上,在飞机上,家用电器上,智能手机上……几乎任何地方发现 Linux 的影子!你甚至可以购买预装 Linux 的笔记本电脑、台式机和服务器。如果你考虑云计算,企业甚至个人都可以一键部署 Linux 虚拟机,由此可见 Linux 的应用已经变得多么普遍了。

考虑到这些,我想问你的问题是:这个时代如何定义“Linux 用户”?

如果你从 System76 或 Dell 为你的父母或祖父母购买一台 Linux 笔记本电脑,为其登录好他们的社交媒体和电子邮件,并告诉他们经常单击“系统升级”,那么他们现在就是 Linux 用户了。如果你是在 Windows 或 MacOS 机器上进行以上操作,那么他们就是 Windows 或 MacOS 用户。令人难以置信的是,与 90 年代不同,现在的 Linux 任何人都可以轻易上手。

由于种种原因,这也归因于 web 浏览器成为了桌面计算机上的“杀手级应用程序”。现在,许多用户并不关心他们使用的是什么操作系统,只要他们能够访问到他们的应用程序或服务。

你知道有多少人经常使用他们的电话、桌面或笔记本电脑,但不会管理他们系统上的文件、目录和驱动程序?又有多少人不会安装“应用程序商店”没有收录的二进制文件程序?更不要提从头编译应用程序,对我来说,几乎全是这样的。这正是成熟的开源软件和相应的生态对于易用性的改进的动人之处。

今天的 Linux 用户不需要像上世纪 90 年代或 21 世纪初的 Linux 用户那样了解、学习甚至查询信息,这并不是一件坏事。过去那种认为 Linux 只适合工科男使用的想法已经一去不复返了。

对于那些对计算机、操作系统以及在自由软件上创建、使用和协作的想法感兴趣、好奇、着迷的 Linux 用户来说,Liunx 依旧有研究的空间。如今在 Windows 和 MacOS 上也有同样多的空间留给创造性的开源贡献者。今天,成为 Linux 用户就是成为一名与 Linux 系统同行的人。这是一件很棒的事情。

Linux 用户定义的转变

当我开始使用 Linux 时,作为一个 Linux 用户意味着知道操作系统如何以各种方式、形态和形式运行。Linux 在某种程度上已经成熟,这使得“Linux 用户”的定义可以包含更广泛的领域及那些领域里的人们。这可能是显而易见的一点,但重要的还是要说清楚:任何 Linux 用户皆“生”而平等。


via: https://opensource.com/article/19/6/what-linux-user

作者:Anderson Silva 选题:lujun9972 译者:qfzy1233 校对:wxy

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

从计算机自由先驱的口中探寻操作系统兼容性标准背后的本质。

POSIX 是什么?为什么如此重要?你可能在很多的技术类文章中看到这个术语,但往往会在探寻其本质时迷失在 技术初始主义 techno-initialisms 的海洋或是 以 X 结尾的行话 jargon-that-ends-in-X 中。我给 Richard Stallman 博士(在黑客圈里面常称之为 RMS)发了邮件以探寻这个术语的起源及其背后的概念。

Richard Stallman 认为用 “开源” 和 “闭源” 来归类软件是一种错误的方法。Stallman 将程序分类为 尊重自由的 freedom-respecting (“ 自由 free ” 或 “ 自由(西语) libre ”)和 践踏自由的 freedom-trampling (“ 非自由 non-free ” 或 “ 专有 proprietary ”)。开源讨论通常会为了(用户)实际得到的 优势/便利 advantages 考虑去鼓励某些做法,而非作为道德层面上的约束。

Stallman 在由其本人于 1984 年发起的 自由软件运动 The free software movement 表明,不仅仅是这些 优势/便利 advantages 受到了威胁。计算机的用户 理应得到 deserve 计算机的控制权,因此拒绝被用户控制的程序即是 非正义 injustice ,理应被 拒绝 rejected 排斥 eliminated 。对于用户的控制权,程序应当给予用户 四项基本自由

  • 自由度 0:无论用户出于何种目的,必须可以按照用户意愿,自由地运行该软件。
  • 自由度 1:用户可以自由地学习并修改该软件,以便按照自己的意愿进行计算。作为前提,用户必须可以访问到该软件的源代码。
  • 自由度 2:用户可以自由地分发该软件的副本,以便可以帮助他人。
  • 自由度 3:用户可以自由地分发该软件修改后的副本。借此,你可以让整个社区受益于你的改进。作为前提,用户必须可以访问到该软件的源代码。

关于 POSIX

Seth: POSIX 标准是由 IEEE 发布,用于描述 “ 可移植操作系统 portable operating system ” 的文档。只要开发人员编写符合此描述的程序,他们生产的便是符合 POSIX 的程序。在科技行业,我们称之为 “ 规范 specification ” 或将其简写为 “spec”。就技术用语而言,这是可以理解的,但我们不禁要问是什么使操作系统 “可移植”?

RMS: 我认为是 接口 interface 应该(在不同系统之间)是可移植的,而非任何一种系统。实际上,内部构造不同的各种系统都支持部分的 POSIX 接口规范。

Seth: 因此,如果两个系统皆具有符合 POSIX 的程序,那么它们便可以彼此假设,从而知道如何相互 “交谈”。我了解到 “POSIX” 这个简称是你想出来的。那你是怎么想出来的呢?它是如何就被 IEEE 采纳了呢?

RMS: IEEE 已经完成了规范的开发,但还没为其想好简练的名称。标题类似是 “可移植操作系统接口”,虽然我已记不清确切的单词。委员会倾向于将 “IEEEIX” 作为简称。而我认为那不太好。发音有点怪 - 听起来像恐怖的尖叫,“Ayeee!” - 所以我觉得人们反而会倾向于称之为 “Unix”。

但是,由于 GNU 并不是 Unix GNU’s Not Unix ,并且它打算取代之,我不希望人们将 GNU 称为 “Unix 系统”。因此,我提出了人们可能会实际使用的简称。那个时候也没有什么灵感,我就用了一个并不是非常聪明的方式创造了这个简称:我使用了 “ 可移植操作系统 portable operating system ” 的首字母缩写,并在末尾添加了 “ix” 作为简称。IEEE 也欣然接受了。

Seth: POSIX 缩写中的 “操作系统” 是仅涉及 Unix 和类 Unix 的系统(如 GNU)呢?还是意图包含所有操作系统?

RMS: 术语 “操作系统” 抽象地说,涵盖了完全不像 Unix 的系统、完全和 POSIX 规范无关的系统。但是,POSIX 规范适用于大量类 Unix 系统;也只有这样的系统才适合 POSIX 规范。

Seth: 你是否参与审核或更新当前版本的 POSIX 标准?

RMS: 现在不了。

Seth: GNU Autotools 工具链可以使应用程序更容易移植,至少在构建和安装时如此。所以可以认为 Autotools 是构建可移植基础设施的重要一环吗?

RMS: 是的,因为即使在遵循 POSIX 的系统中,也存在着诸多差异。而 Autotools 可以使程序更容易适应这些差异。顺带一提,如果有人想助力 Autotools 的开发,可以发邮件联系我。

Seth: 我想,当 GNU 刚刚开始让人们意识到一个非 Unix 的系统可以从专有的技术中解放出来的时候,关于自由软件如何协作方面,这其间一定存在一些空白区域吧。

RMS: 我不认为有任何空白或不确定性。我只是照着 BSD 的接口写而已。

Seth: 一些 GNU 应用程序符合 POSIX 标准,而另一些 GNU 应用程序的 GNU 特定的功能,要么不在 POSIX 规范中,要么缺少该规范要求的功能。对于 GNU 应用程序 POSIX 合规性有多重要?

RMS: 遵循标准对于利于用户的程度很重要。我们不将标准视为权威,而是且将其作为可能有用的指南来遵循。因此,我们谈论的是 遵循 following 标准而不是“ 遵守 complying ”。可以参考 GNU 编码标准 GNU Coding Standards 中的 非 GNU 标准 段落。

我们努力在大多数问题上与标准兼容,因为在大多数的问题上这最有利于用户。但也偶有例外。

例如,POSIX 指定某些实用程序以 512 字节为单位测量磁盘空间。我要求委员会将其改为 1K,但被拒绝了,说是有个 官僚主义的规则 bureaucratic rule 强迫选用 512。我不记得有多少人试图争辩说,用户会对这个决定感到满意的。

由于 GNU 在用户的 自由 freedom 之后的第二优先级,是用户的 便利 convenience ,我们使 GNU 程序以默认 1K 为单位按块测量磁盘空间。

然而,为了防止竞争对手利用这点给 GNU 安上 “ 不合规 noncompliant ” 的骂名,我们实现了遵循 POSIX 和 ISO C 的可选模式,这种妥协着实可笑。想要遵循 POSIX,只需设置环境变量 POSIXLY_CORRECT,即可使程序符合 POSIX 以 512 字节为单位列出磁盘空间。如果有人知道实际使用 POSIXLY_CORRECT 或者 GCC 中对应的 --pedantic 会为某些用户提供什么实际好处的话,请务必告诉我。

Seth: 符合 POSIX 标准的自由软件项目是否更容易移植到其他类 Unix 系统?

RMS: 我认为是这样,但自上世纪 80 年代开始,我决定不再把时间浪费在将软件移植到 GNU 以外的系统上。我开始专注于推进 GNU 系统,使其不必使用任何非自由软件。至于将 GNU 程序移植到非类 GNU 系统就留给想在其他系统上运行它们的人们了。

Seth: POSIX 对于软件的自由很重要吗?

RMS: 本质上说,(遵不遵循 POSIX)其实没有任何区别。但是,POSIX 和 ISO C 的标准化确实使 GNU 系统更容易迁移,这有助于我们更快地实现从非自由软件中解放用户的目标。这个目标于上世纪 90 年代早期达成,当时Linux成为自由软件,同时也填补了 GNU 中内核的空白。

POSIX 采纳 GNU 的创新

我还问过 Stallman 博士,是否有任何 GNU 特定的创新或惯例后来被采纳为 POSIX 标准。他无法回想起具体的例子,但友好地代我向几位开发者发了邮件。

开发者 Giacomo Catenazzi,James Youngman,Eric Blake,Arnold Robbins 和 Joshua Judson Rosen 对以前的 POSIX 迭代以及仍在进行中的 POSIX 迭代做出了回应。POSIX 是一个 “ 活的 living ” 标准,因此会不断被行业专业人士更新和评审,许多从事 GNU 项目的开发人员提出了对 GNU 特性的包含。

为了回顾这些有趣的历史,接下来会罗列一些已经融入 POSIX 的流行的 GNU 特性。

Make

一些 GNU Make 的特性已经被 POSIX 的 make 定义所采用。相关的 规范 提供了从现有实现中借来的特性的详细归因。

Diff 和 patch

diffpatch 命令都直接从这些工具的 GNU 版本中引进了 -u-U 选项。

C 库

POSIX 采用了 GNU C 库 glibc 的许多特性。 血统 Lineage 一时已难以追溯,但 James Youngman 如是写道:

“我非常确定 GCC 首创了许多 ISO C 的特性。例如,\_Noreturn 是 C11 中的新特性,但 GCC-1.35 便具有此功能(使用 volatile 作为声明函数的修饰符)。另外尽管我不确定,GCC-1.35 支持的可变长度数组似乎与现代 C 中的( 柔性数组 conformant array )非常相似。”

Giacomo Catenazzi 援引 Open Group 的 strftime 文章,并指出其归因:“这是基于某版本 GNU libc 的 strftime() 的特性。”

Eric Blake 指出,对于 getline() 和各种基于语言环境的 *_l() 函数,GNU 绝对是这方面的先驱。

Joshua Judson Rosen 补充道,他清楚地记得,在全然不同的操作系统的代码中奇怪地目睹了熟悉的 GNU 式的行为后,对 getline() 函数的采用给他留下了深刻的印象。

“等等……那不是 GNU 特有的吗?哦,显然已经不再是了。”

Rosen 向我指出了 getline 手册页 中写道:

getline()getdelim() 最初都是 GNU 扩展。在 POSIX.1-2008 中被标准化。

Eric Blake 向我发送了一份其他扩展的列表,这些扩展可能会在下一个 POSIX 修订版中添加(代号为 Issue 8,大约在 2021 年前后):

关于用户空间的扩展

POSIX 不仅为开发人员定义了函数和特性,还为用户空间定义了标准行为。

ls

-A 选项会排除来自 ls 命令结果中的符号 .(代表当前位置)和 ..(代表上一级目录)。它被 POSIX 2008 采纳。

find

find 命令是一个 特别的 ad hoc for 循环 工具,也是 并行 parallel 处理的出入口。

一些从 GNU 引入到 POSIX 的 便捷操作 conveniences ,包括 -path-perm 选项。

-path 选项帮你过滤与文件系统路径模式匹配的搜索结果,并且从 1996 年(根据 findutil 的 Git 仓库中最早的记录)GNU 版本的 find 便可使用此选项。James Youngman 指出 HP-UX 也很早就有这个选项,所以究竟是 GNU 还是 HP-UX 做出的这一创新(抑或两者兼而有之)无法考证。

-perm 选项帮你按文件权限过滤搜索结果。这在 1996 年 GNU 版本的 find 中便已存在,随后被纳入 POSIX 标准 “IEEE Std 1003.1,2004 Edition” 中。

xargs 命令是 findutils 软件包的一部分,1996 年的时候就有一个 -p 选项会将 xargs 置于交互模式(用户将被提示是否继续),随后被纳入 POSIX 标准 “IEEE Std 1003.1, 2004 Edition” 中。

Awk

GNU awk(即 /usr/bin 目录中的 gawk 命令,可能也是符号链接 awk 的目标地址)的维护者 Arnold Robbins 说道,gawkmawk(另一个GPL 的 awk 实现)允许 RS(记录分隔符)是一个正则表达式,即这时 RS 的长度会大于 1。这一特性还不是 POSIX 的特性,但有 迹象表明它即将会是

NUL 在扩展正则表达式中产生的未定义行为允许 GNU gawk 程序未来可以扩展以处理二进制数据。

使用多字符 RS 值的未指定行为是为了未来可能的扩展,它是基于用于记录分隔符(RS)的扩展正则表达式的。目前的历史实现为采用该字符串的第一个字符而忽略其他字符。

这是一个重大的增强,因为 RS 符号定义了记录之间的分隔符。可能是逗号、分号、短划线、或者是任何此类字符,但如果它是字符序列,则只会使用第一个字符,除非你使用的是 gawkmawk。想象一下这种情况,使用省略号(连续的三个点)作为解析 IP 地址文档的分隔记录,只是想获取在每个 IP 地址的每个点处解析的结果。

mawk 首先支持这个功能,但是几年来没有维护者,留下来的火把由 gawk 接过。(mawk 已然获得了一个新的维护者,可以说是大家薪火传承地将这一特性推向共同的预期值。)

POSIX 规范

总的来说,Giacomo Catenzzi 指出,“……因为 GNU 的实用程序使用广泛,而且许多其他的选项和行为又对标规范。在 shell 的每次更改中,Bash 都会(作为一等公民)被用作比较。” 当某些东西被纳入 POSIX 规范时,无需提及 GNU 或任何其他影响,你可以简单地认为 POSIX 规范会受到许多方面的影响,GNU 只是其中之一。

共识是 POSIX 存在的意义所在。一群技术人员共同努力为了实现共同规范,再分享给数以百计各异的开发人员,经由他们的赋能,从而实现软件的独立性,以及开发人员和用户的自由。


via: https://opensource.com/article/19/7/what-posix-richard-stallman-explains

作者:Seth Kenlon 选题:lujun9972 译者:martin2011qi 校对:wxy

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

面对倾泻的洪水或地震时业务需要继续运转。在飓风卡特里娜、桑迪和其他灾难中幸存下来的系统管理员向在紧急状况下负责 IT 的人们分享真实世界中的建议。

说到自然灾害,2017 年可算是多灾多难。(LCTT 译注:本文发表于 2017 年)飓风哈维、厄玛和玛莉亚给休斯顿、波多黎各、弗罗里达和加勒比造成了严重破坏。此外,西部的野火将多处住宅和商业建筑付之一炬。

再来一篇关于有备无患的警示文章 —— 当然其中都是好的建议 —— 是很简单的,但这无法帮助网络管理员应对湿漉漉的烂摊子。那些善意的建议中大多数都假定掌权的人乐于投入资金来实施这些建议。

我们对真实世界更感兴趣。不如让我们来充分利用这些坏消息。

一个很好的例子:自然灾害的一个后果是老板可能突然愿意给灾备计划投入预算。如同一个纽约地区的系统管理员所言,“我发现飓风桑迪的最大好处是我们的客户对 IT 投资更有兴趣了,但愿你也能得到更多预算。”

不过别指望这种意愿持续很久。任何想提议改进基础设施的系统管理员最好趁热打铁。如同另一位飓风桑迪中幸存下来的 IT 专员懊悔地提及那样,“对 IT 开支最初的兴趣持续到当年为止。到了第二年,任何尚未开工的计划都因为‘预算约束’被搁置了,大约 6 个月之后则完全被遗忘。”

在管理层忘记恶劣的自然灾害也可能降临到好公司头上之前提醒他们这点会有所帮助。根据 商业和家庭安全协会 Institute for Business & Home Safety 的说法,自然灾害后歇业的公司中 25% 再也没能重新开业 联邦紧急事务管理署 FEMA 认为这过于乐观。根据他们的统计,“灾后 40% 的小公司再也没能重新开门营业。”

如果你是个系统管理员,你能帮忙挽救你的公司。这里有一些幸存者的最好的主意,这些主意是基于他们从过去几次自然灾害中得到的经验。

制订一个计划

当灯光忽明忽暗,狂风象火车机车一样怒号时,就该启动你的业务持续计划和灾备计划了。

有太多的系统管理员报告当暴风雨来临时这两个计划中一个也没有。这并不令人惊讶。2014 年 灾备预备状态委员会 Disaster Recovery Preparedness Council 发现世界范围内被调查的公司中有 73% 没有足够的灾备计划

足够”是关键词。正如一个系统管理员 2016 年在 Reddit 上写的那样,“我们的灾备计划就是一场灾难。我们所有的数据都备份在离这里大约 30 英里的一个 存储区域网络 SAN 。我们没有将数据重新上线的硬件,甚至好几天过去了都没能让核心服务器启动运行起来。我们是个年营收 40 亿美元的公司,却不愿为适当的设备投入几十万美元,或是在数据中心添置几台服务器。当添置硬件的提案被提出的时候,我们的管理层说,‘嗐,碰到这种事情的机会能有多大呢’。”

同一个帖子中另一个人说得更简洁:“眼下我的灾备计划只能在黑暗潮湿的角落里哭泣,但愿没人在乎损失的任何东西。”

如果你在哭泣,但愿你至少不是独自流泪。任何灾备计划,即便是 IT 部门制订的灾备计划,必须确定你能跟别人通讯,如同系统管理员 Jim Thompson 从卡特里娜飓风中得到的教训:“确保你有一个与人们通讯的计划。在一场严重的区域性灾难期间,你将无法给身处灾区的任何人打电话。”

有一个选择可能会让有技术头脑的人感兴趣: 业余电台 ham radio 它在波多黎各发挥了巨大作用

列一个愿望清单

第一步是承认问题。“许多公司实际上对灾备计划不感兴趣,或是消极对待”,Micro Focus 的首席架构师 Joshua Focus 说。“将灾备看作业务持续性的一个方面是种不同的视角。所有公司都要应对业务持续性,所以灾备应被视为业务持续性的一部分。”

IT 部门需要将其需求书面化以确保适当的灾备和业务持续性计划。即使是你不知道如何着手,或尤其是这种时候,也是如此。正如一个系统管理员所言,“我喜欢有一个‘想法转储’,让所有计划、点子、改进措施毫无保留地提出来。(这)对一类情况尤其有帮助,即当你提议变更,并付诸实施,接着 6 个月之后你警告过的状况就要来临。”现在你做好了一切准备并且可以开始讨论:“如同我们之前在 4 月讨论过的那样……”

因此,当你的管理层对业务持续性计划回应道“嗐,碰到这种事的机会能有多大呢?”的时候你能做些什么呢?有个系统管理员称这也完全是管理层的正常行为。在这种糟糕的处境下,老练的系统管理员建议用书面形式把这些事情记录下来。记录应清楚表明你告知管理层需要采取的措施,且他们拒绝采纳建议。“总的来说就是有足够的书面材料能让他们搓成一根绳子上吊,”该系统管理员补充道。

如果那也不起作用,恢复一个被洪水淹没的数据中心的相关经验对你找个新工作是很有帮助的。

保护有形的基础设施

我们的办公室是幢摇摇欲坠的建筑,”飓风哈维重创休斯顿之后有个系统管理员提到。“我们盲目地进入那幢建筑,现场的基础设施糟透了。正是我们给那幢建筑里带去了最不想要的一滴水,现在基础设施整个都沉在水下了。”

尽管如此,如果你想让数据中心继续运转——或在暴风雨过后恢复运转 —— 你需要确保该场所不仅能经受住你所在地区那些意料中的灾难,而且能经受住那些意料之外的灾难。一个旧金山的系统管理员知道为什么重要的是确保公司的服务器安置在可以承受里氏 7 级地震的建筑内。一家圣路易斯的公司知道如何应对龙卷风。但你应当为所有可能发生的事情做好准备:加州的龙卷风、密苏里州的地震,或僵尸末日(给你在 IT 预算里增加一把链锯提供了充分理由)。

在休斯顿的情况下,多数数据中心保持运转,因为它们是按照抵御暴风雨和洪水的标准建造的。Data Foundry 的首席技术官 Edward Henigin 说他们公司的数据中心之一,“专门建造的休斯顿 2 号的设计能抵御 5 级飓风的风速。这个场所的公共供电没有中断,我们得以避免切换到后备发电机。”

那是好消息。坏消息是伴随着超级飓风桑迪于 2012 年登场,如果你的数据中心没准备好应对洪水,你会陷入一个麻烦不断的世界。一个不能正常运转的数据中心 Datagram 服务的客户包括 Gawker、Gizmodo 和 Buzzfeed 等知名网站。

当然,有时候你什么也做不了。正如某个波多黎各圣胡安的系统管理员在飓风厄玛扫过后悲伤地写到,“发电机没油了。服务器机房靠电池在运转但是没有(空调)。永别了,服务器。”由于 MPLS Multiprotocol Lable Switching 线路亦中断,该系统管理员没法切换到灾备措施:“多么充实的一天。”

总而言之,IT 专业人士需要了解他们所处的地区,了解他们面临的风险并将他们的服务器安置在能抵御当地自然灾害的数据中心内。

关于云的争议

当暴风雨席卷一切时避免 IT 数据中心失效的最佳方法就是确保灾备数据中心在其他地方。选择地点时需要审慎的决策。你的灾备数据中心不应在会被同一场自然灾害影响到的 地域 region ;你的资源应安置在多个 可用区 availability zone 内。考虑一下主备数据中心位于一场地震中的同一条断层带上,或是主备数据中心易于受互通河道导致的洪灾影响这类情况。

有些系统管理员利用云作为冗余设施。例如,总是用微软 Azure 云存储服务保存副本以确保持久性和高可用性。根据你的选择,Azure 复制功能将你的数据要么拷贝到同一个数据中心要么拷贝到另一个数据中心。多数公有云提供类似的自动备份服务以确保数据安全,不论你的数据中心发生什么情况——除非你的云服务供应商全部设施都在暴风雨的行进路径上。

昂贵么?是的。跟业务中断 1、2 天一样昂贵么?并非如此。

信不过公有云?可以考虑 colo colocation 服务。有了 colo,你依旧拥有你的硬件,运行你自己的应用,但这些硬件可以远离麻烦。例如飓风哈维期间,一家公司“虚拟地”将它的资源从休斯顿搬到了其位于德克萨斯奥斯汀的 colo。但是那些本地数据中心和 colo 场所需要准备好应对灾难;这点是你选择场所时要考虑的一个因素。举个例子,一个寻找 colo 场所的西雅图系统管理员考虑的“全都是抗震和旱灾应对措施(加固的地基以及补给冷却系统的运水卡车)。”

周围一片黑暗时

正如 Forrester Research 的分析师 Rachel Dines 在一份为灾备期刊所做的调查中报告的那样,宣布的灾难中最普遍的原因就是断电。尽管你能应对一般情况下的断电,飓风、火灾和洪水的考验会超越设备的极限。

某个系统管理员挖苦式的计划是什么呢?“趁 UPS 完蛋之前把你能关的机器关掉,不能关的就让它崩溃咯。然后,喝个痛快直到供电恢复。”

在 2016 年德尔塔和西南航空停电事故之后,IT 员工推动的一个更加严肃的计划是由一个有管理的服务供应商为其客户部署不间断电源:“对于至关重要的部分,在供电中断时我们结合使用 简单网络管理协议 SNMP 信令和 PowerChute 网络关机 PowerChute Nrework Shutdown 客户端来关闭设备。至于重新开机,那取决于客户。有些是自动启动,有些则需要人工干预。”

另一种做法是用来自两个供电所的供电线路支持数据中心。例如,西雅图威斯汀大厦数据中心有来自不同供电所的多路 13.4 千伏供电线路,以及多个 480 伏三相变电箱。

预防严重断电的系统不是“通用的”设备。系统管理员应当为数据中心请求一台定制的柴油发电机。除了按你特定的需求调整,发电机必须能迅速跳至全速运转并承载全部电力负荷而不致影响系统负载性能。”

这些发电机也必须加以保护。例如,将你的发电机安置在泛洪区的一楼就不是个聪明的主意。位于纽约 百老街 Broad street 的数据中心在超级飓风桑迪期间就是类似情形,备用发电机的燃料油桶在地下室 —— 并且被水淹了。尽管一场“人力接龙”用容量 5 加仑的水桶将柴油输送到 17 段楼梯之上的发电机使 Peer 1 Hosting 得以继续运营,但这不是一个切实可行的业务持续计划。

正如多数数据中心专家所知那样,如果你有时间 —— 假设一个飓风离你有一天的距离 —— 确保你的发电机正常工作,加满油,准备好当供电线路被刮断时立即开启,不管怎样你之前应当每月测试你的发电机。你之前是那么做的,是吧?是就好!

测试你对备份的信心

普通用户几乎从不备份,检查备份是否实际完好的就更少了。系统管理员对此更加了解。

有些 IT 部门在寻求将他们的备份迁移到云端。但有些系统管理员仍对此不买账 —— 他们有很好的理由。最近有人报告,“在用了整整 5 天从亚马逊 Glacier 恢复了(400 GB)数据之后,我欠了亚马逊将近 200 美元的传输费,并且(我还是)处于未完全恢复状态,还差大约 100 GB 文件。”

结果是有些系统管理员依然喜欢磁带备份。磁带肯定不够时髦,但正如操作系统专家 Andrew S. Tanenbaum 说的那样,“永远不要低估一辆装满磁带在高速上飞驰的旅行车的带宽。”

目前每盘磁带可以存储 10 TB 数据;有的进行中的实验可在磁带上存储高达 200 TB 数据。诸如 线性磁带文件系统 Linear Tape File System 之类的技术允许你象访问网络硬盘一样读取磁带数据。

然而对许多人而言,磁带绝对是最后选择的手段。没关系,因为备份应该有大量的可选方案。在这种情况下,一个系统管理员说到,“故障时我们会用这些方法(恢复备份):(Windows)服务器层面的 VSS (Volume Shadow Storage)快照, 存储区域网络 SAN 层面的卷快照,以及存储区域网络层面的异地归档快照。但是万一有什么事情发生并摧毁了我们的虚拟机,存储区域网络和备份存储区域网络,我们还是可以取回磁带并恢复数据。”

当麻烦即将到来时,可使用副本工具如 Veeam,它会为你的服务器创建一个虚拟机副本。若出现故障,副本会自动启动。没有麻烦,没有手忙脚乱,正如某个系统管理员在这个流行的系统管理员帖子中所说,“我爱你 Veeam。”

网络?什么网络?

当然,如果员工们无法触及他们的服务,没有任何云、colo 和远程数据中心能帮到你。你不需要一场自然灾害来证明冗余互联网连接的正确性。只需要一台挖断线路的挖掘机或断掉的光缆就能让你在工作中渡过糟糕的一天。

“理想状态下”,某个系统管理员明智地观察到,“你应该有两路互联网接入线路连接到有独立基础设施的两个 ISP。例如,你不希望两个 ISP 都依赖于同一根光缆。你也不希望采用两家本地 ISP,并发现他们的上行带宽都依赖于同一家骨干网运营商。”

聪明的系统管理员知道他们公司的互联网接入线路必须是商业级别的,带有 服务等级协议 service-level agreement(SLA) ,其中包含“修复时间”条款。或者更好的是采用 互联网接入专线 dedicated Internet access。技术上这与任何其他互联网接入方式没有区别。区别在于互联网接入专线不是一种“尽力而为”的接入方式,而是你会得到明确规定的专供你使用的带宽并附有服务等级协议。这种专线不便宜,但正如一句格言所说的那样,“速度、可靠性、便宜,只能挑两个。”当你的业务跑在这条线路上并且一场暴风雨即将来袭,“可靠性”必须是你挑的两个之一。

晴空重现之时

你没法准备应对所有自然灾害,但你可以为其中很多做好计划。有一个深思熟虑且经过测试的灾备和业务持续计划,并逐字逐句严格执行,当竞争对手溺毙的时候,你的公司可以幸存下来。

系统管理员对抗自然灾害:给领导者的教训

  • 你的 IT 员工得说多少次:不要仅仅备份,还得测试备份?
  • 没电就没公司。确保你的服务器有足够的应急电源来满足业务需要,并确保它们能正常工作。
  • 如果你的公司在一场自然灾害中幸存下来,或者避开了灾害,明智的系统管理员知道这就是向管理层申请被他们推迟的灾备预算的时候了。因为下次你就未必有这么幸运了。

via: https://www.hpe.com/us/en/insights/articles/it-disaster-recovery-sysadmins-vs-natural-disasters-1711.html

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

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