开源工具的威力和开源运动的重要性。

我刚刚完成大学二年级的第一学期，我正在思考我在课堂上学到的东西。有一节课特别引起了我的注意：“开源世界的基础”，它由杜克大学的 Bryan Behrenshausen 博士讲授。我在最后一刻参加了课程，因为它看起来很有趣，诚实地来说，因为它符合我的日程安排。

第一天，Behrenshausen 博士问我们学生是否知道或使用过任何开源程序。直到那一天，我几乎没有听过术语“开源”，当然也不知道任何属于该类别的产品。然而，随着学期的继续，对我而言，如果没有开源，我对事业抱负的激情就不会存在。

Audacity 和 GIMP

我对技术的兴趣始于 12 岁。我负责为我的舞蹈团队裁剪音乐，我在网上搜索了几个小时，直到找到开源音频编辑器 Audacity。Audacity 为我敞开了大门。我不再局限于重复的 8 音节。我开始接受其他想要独特演绎他们最喜爱歌曲的人的请求。

几周后，我偶然在互联网上看到了一只有着 Pop-Tart 躯干并且后面拖着彩虹在太空飞行的猫。我搜索了“如何制作动态图像”，并发现了一个开源的图形编辑器 GIMP，并用它为我兄弟做了一张“辛普森一家”的 GIF 作为生日礼物。

我萌芽的兴趣成长为完全的痴迷：在我笨重的、落后的笔记本上制作艺术品。由于我没有很好的炭笔，油彩或水彩，所以我用图形设计作为创意的表达。我花了几个小时在计算机实验室上 W3Schools 学习 HTML 和 CSS 的基础知识，以便我可以用我幼稚的 GIF 填充在线作品集。几个月后，我在 WordPress 发布了我的第一个网站。

为什么开源

开源让我们不仅可以实现我们的目标，还可以发现驱动这些目标的兴趣。

快进近十年。虽然有些仍然保持一致，但许多事情已经发生了变化：我仍然在制作图形（主要是传单），为舞蹈团编辑音乐，以及设计网站（我希望更时尚、更有效）。我使用的产品经历了无数版本升级。但最戏剧性的变化是我对开源资源的态度。

考虑到开源产品在我的生活中的意义，使我珍视开放运动和它的使命。开源项目提醒我，科技领域有些倡议可以促进社会的良好和自我学习，而不会被那些具有社会经济优势的人排斥。我中学时的自己，像无数其他人一样，无法购买 Adobe Creative Suite、GarageBand 或 Squarespace。开源平台使我们不仅能够实现我们的目标，而且还能通过扩大我们接触来发现推动这些目标的兴趣。

我的建议？一时心血来潮报名上课。它可能会改变你对世界的看法。

via: https://opensource.com/article/18/3/college-getting-started

作者：Christine Hwang 选题：lujun9972 译者：geekpi 校对：wxy

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

全球开源社区通常面临着语音壁垒、文化差异以及其它的挑战。如何去解决它们呢？

今天的开源组织参与人员来自于全世界。你能预见到组建在线社区可能遇到哪些困难吗？有没有什么办法能够克服这些困难呢？

为开源社区贡献力量的人共同合作推动软件的开发和发展。在过去，人们是面对面或者通过邮件和电话来交流的。今天，科技孕育出了在线交流——人们只需要进入一个聊天室或消息渠道就能一起工作了。比如，你可以早上跟摩洛哥的人一起工作，到了晚上又跟夏威夷的人一起工作。

全球社区的三个挑战

任何一个团队合作过的人都知道意见分歧是很难被克服的。对于在线社区来说，语言障碍、不同的时区，以及文化差异也带来了新的挑战。

语言障碍

英语是开源社区中的主流语言，因此英语不好的人会很难看懂文档和修改意见。为了克服这个问题，吸引其他地区的社区成员，你需要邀请双语者参与到社区中来。问问周围的人——你会发现意想不到的精通其他语言的人。社区的双语成员可以帮助别人跨越语言障碍，并且可以通过翻译软件和文档来扩大项目的受众范围。

人们使用的编程语言也不一样。你可能喜欢用 Bash 而其他人则可能更喜欢 Python、Ruby、C 等其他语言。这意味着，人们可能由于编程语言的原因而难以为你的代码库做贡献。项目负责人为项目选择一门被软件社区广泛认可的语言至关重要。如果你选择了一门偏门的语言，则很少人能够参与其中。

不同的时区

时区为开源社区带来了另一个挑战。比如，若你在芝加哥，想与一个在伦敦的成员安排一次视频会议，你需要调整 8 小时的时差。根据合作者的地理位置，你可能要在深夜或者清晨工作。

肉身转移，可以让你的团队在同一个时区工作可以帮助克服这个挑战，但这种方法只有极少数社区才能够负担的起。我们还可以定期举行虚拟会议讨论项目，建立一个固定的时间和地点以供所有人来讨论未决的事项，即将发布的版本等其他主题。

不同的时区也可以成为你的优势，因为团队成员可以全天候的工作。若你拥有一个类似 IRC 这样的实时交流平台，用户可以在任意时间都能找到人来回答问题。

文化差异

文化差异是开源组织面临的最大挑战。世界各地的人都有不同的思考方式、计划以及解决问题的方法。政治环境也会影响工作环境并影响决策。

作为项目负责人，你应该努力构建一种能包容不同看法的环境。文化差异可以鼓励社区沟通。建设性的讨论总是对项目有益，因为它可以帮助社区成员从不同角度看待问题。不同意见也有助于解决问题。

要成功开源，团队必须学会拥抱差异。这不简单，但多样性最终会使社区收益。

加强在线沟通的其他方法

• 本地化： 在线社区成员可能会发现位于附近的贡献者——去见个面并组织一个本地社区。只需要两个人就能组建一个社区了。可以邀请其他当地用户或雇员参与其中；他们甚至还能为以后的聚会提供场所呢。
• 组织活动： 组织活动是构建本地社区的好方法，而且费用也不高。你可以在当地的咖啡屋或者啤酒厂聚会，庆祝最新版本的发布或者某个核心功能的实现。组织的活动越多，人们参与的热情就越高（即使只是因为单纯的好奇心）。最终，可能会找到一家公司为你提供聚会的场地，或者为你提供赞助。
• 保持联系： 每次活动后，联系本地社区成员。收起电子邮箱地址或者其他联系方式并邀请他们参与到你的交流平台中。邀请他们为其他社区做贡献。你很可能会发现很多当地的人才，运气好的话，甚至可能发现新的核心开发人员！
• 分享经验： 本地社区是一种非常有价值的资源，对你，对其他社区来说都是。与可能受益的人分享你的发现和经验。如果你不清楚（LCTT 译注：这里原文是说 sure，但是根据上下文，这里应该是 not sure）如何策划一场活动或会议，可以咨询其他人的意见。也许能找到一些有经验的人帮你走到正轨。
• 关注文化差异： 记住，文化规范因地点和人而异，因此在清晨安排某项活动可能适用于一个地方的人，但是不合适另一个地方的人。当然，你可以（也应该）利用其他社区的参考资料来更好地理解这种差异性，但有时你也需要通过试错的方式来学习。不要忘了分享你所学到的东西，让别人也从中获益。
• 检查个人观点： 避免在工作场合提出带有很强主观色彩的观点（尤其是与政治相关的观点）。这会抑制开放式的沟通和问题的解决。相反，应该专注于鼓励与团队成员展开建设性讨论。如果你发现陷入了激烈的争论中，那么后退一步，冷静一下，然后再从更加积极的角度出发重新进行讨论。讨论必须是有建设性的，从多个角度讨论问题对社区有益。永远不要把自己的主观观念放在社区的总体利益之前。
• 尝试异步沟通： 这些天，实时通讯平台已经引起了大家的关注，但除此之外还别忘了电子邮件。如果没有在网络平台上找到人的话，可以给他们发送一封电子邮件。有可能你很快就能得到回复。考虑使用那些专注于异步沟通的平台，比如 Twist，也不要忘了查看并更新论坛和维基。
• 使用不同的解决方案： 并不存在一个单一的完美的解决方法，学习最有效的方法还是通过经验来学习。从反复试验中你可以学到很多东西。不要害怕失败；你会从失败中学到很多东西从而不停地进步。

社区需要营养

将社区想象成是一颗植物的幼苗。你需要每天给它浇水，提供阳光和氧气。社区也是一样：倾听贡献者的声音，记住你在与活生生的人进行互动，他们需要以合适的方式进行持续的交流。如果社区缺少了人情味，人们会停止对它的贡献。

最后，请记住，每个社区都是不同的，没有一种单一的解决方法能够适用于所有社区。坚持不断地从社区中学习并适应这个社区。

via: https://opensource.com/article/17/12/working-worldwide-communities

作者：José Antonio Rey 译者：lujun9972 校对：wxy

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

许多组织正在争先恐后地了解隐私法的变化如何影响他们的工作。

2018 年 5 月 25 日， 通用数据保护条例 General Data Protection Regulation, GDPR 开始生效。欧盟出台的该条例将在全球范围内对企业如何保护个人数据产生重大影响。影响也会波及到开源项目以及开源社区。

GDPR 概述

GDPR 于 2016 年 4 月 14 日在欧盟议会通过，从 2018 年 5 月 25 日起开始生效。GDPR 用于替代 95/46/EC 号 数据保护指令 Data Protection Directive ，该指令被设计用于“协调欧洲各国数据隐私法，保护和授权全体欧盟公民的数据隐私，改变欧洲范围内企业处理数据隐私的方式”。

GDPR 目标是在当前日益数据驱动的世界中保护欧盟公民的个人数据。

它对谁生效

GDPR 带来的最大改变之一是影响范围的扩大。不管企业本身是否位于欧盟，只要涉及欧盟公民个人数据的处理，GDPR 就会对其生效。

大部分提及 GDPR 的网上文章关注销售商品或服务的公司，但关注影响范围时，我们也不要忘记开源项目。有几种不同的类型，包括运营开源社区的（营利性）软件公司和非营利性组织（例如，开源软件项目及其社区）。对于面向全球的社区，几乎总是会有欧盟居民加入其中。

如果一个面向全球的社区有对应的在线平台，包括网站、论坛和问题跟踪系统等，那么很可能会涉及欧盟居民的个人数据处理，包括姓名、邮箱地址甚至更多。这些处理行为都需要遵循 GDPR。

GDPR 带来的改变及其影响

相比被替代的指令，GDPR 带来了很多改变，强化了对欧盟居民数据和隐私的保护。正如前文所说，一些改变给社区带来了直接的影响。我们来看看若干改变。

授权

我们假设社区为成员提供论坛，网站中包含若干个用于注册的表单。要遵循 GDPR，你不能再使用冗长、无法辨识的隐私策略和条件条款。无论是每种特殊用途，在论坛注册或使用网站表单注册，你都需要获取明确的授权。授权必须是无条件的、具体的、通知性的以及无歧义的。

以表单为例，你需要提供一个复选框，处于未选中状态并给出个人数据用途的明确说明，一般是当前使用的隐私策略和条件条款附录的超链接。

访问权

GDPR 赋予欧盟公民更多的权利。其中一项权利是向企业查询个人数据包括哪些，保存在哪里；如果 数据相关人 data subject （例如欧盟公民）提出获取相应数据副本的需求，企业还应免费提供数字形式的数据。

遗忘权

欧盟居民还从 GDPR 获得了“遗忘权”，即数据擦除。该权利是指，在一定限制条件下，企业必须删除个人数据，甚至可能停止其自身或第三方机构后续处理申请人的数据。

上述三种改变要求你的平台软件也要遵循 GDPR 的某些方面。需要提供特定的功能，例如获取并保存授权，提取数据并向数据相关人提供数字形式的副本，以及删除数据相关人对应的数据等。

泄露通知

在 GDPR 看来，不经数据相关人授权情况下使用或偷取个人数据都被视为 数据泄露 data breach 。一旦发现，你应该在 72 小时内通知社区成员，除非这些个人数据不太可能给 自然人 natural persons 的权利与自由带来风险。GDPR 强制要求执行泄露通知。

披露记录

企业负责提供一份记录，用于详细披露个人数据处理的过程和目的等。该记录用于证明企业遵从 GDPR 要求，维护了一份个人数据处理行为的记录；同时该记录也用于审计。

罚款

不遵循 GDPR 的企业最高可面临全球年收入总额 4% 或 2000 万欧元 （取两者较大值）的罚款。根据 GDPR，“最高处罚针对严重的侵权行为，包括未经用户充分授权的情况下处理数据，以及违反设计理念中核心隐私部分”。

补充说明

本文不应用于法律建议或 GDPR 合规的指导书。我提到了可能对开源社区有影响的条约部分，希望引起大家对 GDPR 及其影响的关注。当然，条约包含了更多你需要了解和可能需要遵循的条款。

你自己也可能认识到，当运营一个面向全球的社区时，需要行动起来使其遵循 GDPR。如果在社区中，你已经遵循包括 ISO 27001，NIST 和 PCI DSS 在内的健壮安全标准，你已经先人一步。

可以从如下网站/资源中获取更多关于 GDPR 的信息：

• GDPR 官网 (欧盟提供)
• 官方条约 （欧盟） 2016/679 （GDPR，包含翻译）
• GDPR 是什么？ 领导人需要知道的 8 件事 （企业人项目）
• 如何规避 GDPR 合规审计：最佳实践 （企业人项目）

关于作者

Robin Muilwijk 是一名互联网和电子政务顾问，在 Red Hat 旗下在线发布平台 Opensource.com 担任社区版主，在 Open Organization 担任大使。此外，Robin 还是 eZ 社区董事会成员，eZ 系统 社区的管理员。Robin 活跃在社交媒体中，促进和支持商业和生活领域的开源项目。可以在 Twitter 上关注 Robin Muilwijk 以获取更多关于他的信息。更多关于我的信息

via: https://opensource.com/article/18/4/gdpr-impact

作者: Robin Muilwijk 选题者: lujun9972 译者: pinewall 校对: wxy

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

想要你的整个团队都登上 IT 自动化之旅吗？ IT 执行者们分享了他们的战略。

在任何重要的项目或主动变更刚开始的时候，IT 的管理者在前进的道路上面临着普遍的抉择。

第一条路径看上去是提供了一个从 A 到 B 的最短路径：简单的把项目强制分配给每个人去执行，本质来说就是你要么按照要求去做要么就不要做了。

第二条路径可能看上去会不是很直接，因为要通过这条路径你需要花时间去解释项目背后的策略以及原因。你会沿着这条路线设置停靠站点而不是从起点到终点的马拉松：“这就是我们正在做的 —— 和为什么我们这么做。”

猜想一下哪条路径会赢得更好的结果？

如果你选的是路径 2，你肯定是以前都经历过这两条路径——而且经历了第一次的结局。让人们参与到重大变革中总会是最明智的选择。

IT 领导者也知道重大的变革总会带来严重的恐慌、怀疑，和其他的挑战。IT 自动化确实是很正确的改变。这个术语对某些人来说是很可怕的，而且容易被曲解。帮助人们理解你的公司需要 IT 自动化的必要性的原因以及如何去实现是达到你的目标和策略的重要步骤。

阅读我们的相关文章，[IT自动化最佳实践：持久成功的7个关键点。]

考虑到这一点，我们咨询了许多 IT 管理者关于如何在你的组织中实现 IT 自动化。

1、向人们展示它的优点

我们要面对的一点事实是：自我利益和自我保护是本能。利用人们的这种本能是一个吸引他们的好方法：向他们展示自动化策略将如何让他们和他们的工作获益。自动化将会是软件管道中的一个特定过程意味着将会减少在半夜呼叫团队同事来解决故障？它将能让一些人丢弃技术含量低的技能，用更有策略、高效的有序工作代替手工作业，这将会帮助他们的职业生涯更进一步？

“向他们传达他们能得到什么好处，自动化将会如何让他们的客户和公司受益，”来自 ADP 全球首席技术官 vipual Nagrath 的建议。“将现在的状态和未来光明的未来进行对比，展现公司将会变得如何稳定，敏捷，高效和安全。”

这样的方法同样适用于 IT 领域之外的其他领域；只要在向非技术领域的股东们解读利益的时候解释清楚一些术语即可，Nagrath 说道。

设置好前后的情景是一个不错的帮助人们理解的更透彻的故事机。

“你要描述一幅人们能够联想到的当前状态的画面，” Nagrath 说。“描述现在是什么工作，但也要重点强调是什么导致团队的工作效率不够敏捷。”然后再阐释自动化过程将如何提高现在的状态。

2、将自动化和特定的商业目标绑定在一起

一个强有力的案列的一部分要确保人们理解你不只是在追逐潮流趋势。如果只是为了自动化而自动化，人们会很快察觉到进而会更加抵制的——也许在 IT 界更是如此。

“自动化需要商业需求的驱动，例如收入和运营开销，” Cyxtera的副总裁和首席信息安全官 David Emerson 说道。“没有自动化的努力是自我辩护的，而且任何技术专长都不应该被当做一种手段，除非它是公司的一项核心能力。”

像 Nagrath 一样，Emerson 建议将达到自动化的商业目标和奖励措施挂钩，用迭代式的循序渐进的方式推进这些目标和相关的激励措施。

3、 将自动化计划分解为可管理的条目

即使你的自动化策略字面上是“一切都自动化”，对大多数组织来说那也是很艰难的，而且可能是没有灵活性的。你需要制定一个强有力的方案，将自动化目标分解为可管理的目标计划。而且这将能够创造很大的灵活性来适应之后漫长的道路。

“当制定一个自动化方案的时候，我建议详细的阐明推进自动化进程的奖励措施，而且允许迭代朝着目标前进来介绍和证明利益处于一个低风险水平，”Emerson 说道。

GA Connector 的创始人 Sergey Zuev 分享了一个为什么自动化如此重要的快节奏体验的报告——它将怎样为你的策略建立一个强壮持久的论点。Zuevz 应该知道：他的公司的自动化工具将公司的客户关系应用数据导入谷歌分析。但实际上是公司的内部经验使顾客培训进程自动化从而出现了一个闪耀的时刻。

“起初， 我们曾尝试去建立整个培训机制，结果这个项目搁浅了好几个月，”Zuev 说道。“认识到这将无法继续下去之后，我们决定挑选其中的一个能够有巨大的时效的领域，而且立即启动。结果我们只用了一周就实现了其中的电子邮件序列的目标，而且我们已经从被亵渎的体力劳动中获益。”

4、 出售主要部分也有好处

循序渐进的方法并不会阻碍构建一个宏伟的蓝图。就像以个人或者团队的水平来制定方案是一个好主意，帮助人们理解全公司的利益也是一个不错的主意。

“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会平息。”

AHEAD 的首席技术官 Eric Kaplan 赞同通过小范围的胜利来展示自动化的价值是一个赢得人心的聪明策略。但是那些所谓的“小的”的价值揭示能够帮助你提高人们的整体形象。Kaplan 指出个人和组织间的价值是每个人都可以容易联系到的领域。

“最能展现的地方就是你能够节约多少时间，”Kaaplan 说。“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会消失。”

时间和可伸缩性是业务和 IT 同事的强大优势，都复制业务的增长，可以把握。

“自动化的结果是灵活伸缩的——每个人只需较少的努力就能保持和改善你的 IT 环境”，红帽的全球服务副总裁 John Allessio 最近提到。“如果增加人力是提升你的商业的唯一途径，那么灵活伸缩就是白日梦。自动化减少了你的人力需求而且提供了 IT 演进所需的灵活性和韧性。”(详细内容请参考他的文章，[DevOps 团队对 CIO 的真正需求是什么。])

5、 推广你的成果。

在你自动化策略的开始时，你可能是在目标和要达到目标的预期利益上制定方案。但随着你的自动化策略的不断演进，没有什么能够比现实中的实际结果令人信服。

“眼见为实，”ADP 的首席技术官 Nagrath 说。“没有什么比追踪记录能够平息质疑。”

那意味着，不仅仅要达到你的目标，还要准时的完成——这是迭代的循序渐进的方法论的另一个不错的解释。

而量化的结果如比利润的提高或者成本的节省可以大声宣扬出来，Nagrath 建议他的 IT 领导者同行在讲述你们的自动化故事的时候不要仅仅止步于此。

为自动化提供案例也是一个定性的讨论，通过它我们能够促进问题的预防，归总商业的连续性，减伤失败或错误，而且能够在他们处理更有价值的任务时承担更多的责任。

via: https://enterprisersproject.com/article/2018/1/how-make-case-it-automation

作者：Kevin Casey 译者：FelixYFZ 校对：wxy

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

技术问题推动了开源协作的力量。

我最近加入了 Red Hat，在这之前我在另外一家科技公司工作了很多年。在我的上一份工作岗位上，我开发了不少不同类型的软件产品，这些产品是成功的，但都有版权保护。不仅法规限制了我们不能在公司外将软件共享，而且我们在公司内部也基本不进行共享。在那时，我觉得这很有道理：公司花费了时间、精力和预算用于开发软件，理应保护并要求软件涉及的利益。

时间如梭，去年我加入 Red Hat 并培养出一种完全不同的理念。Buildah 项目是我最早加入的项目之一，该项目用于构建 OCI (Open Container Initiative) 标准的镜像，特别擅长让你精简创建好的镜像的体积。那时 Buildah 还处于非常早期的阶段，包含一些瑕疵，不适合用于生产环境。

刚接触项目不久，我做了一些小变更，然后询问公司内部 git 仓库地址，以便提交我做的变更。收到的回答是：没有内部仓库，直接将变更提交到 GitHub 上。这让我感到困惑，将我的变更提交到 GitHub 意味着：任何人都可以查看这部分代码并在他们自己的项目中使用。况且代码还有一些瑕疵，这样做简直有悖常理。但作为一个新人，我只是惊讶地摇了摇头并提交了变更。

一年后，我终于相信了开源软件的力量和价值。我仍为 Buildah 项目工作，我们最近遇到的一个主题很形象地说明了这种力量和价值。这个标题为 Buildah 镜像体积并不小？ 的工单由 Tim Dudgeon (@tdudgeon) 提出。简而言之，他发现使用 Buildah 创建的镜像比使用 Docker 创建的镜像体积更大，而且 Buildah 镜像中并不包含一些额外应用，但 Docker 镜像中却包含它们。

为了比较，他首先操作如下：

$ docker pull centos:7
$ docker images
REPOSITORY            TAG              IMAGE ID                 CREATED             SIZE
docker.io/centos          7                   2d194b392dd1        2 weeks ago         195 MB

他发现 Docker 镜像的体积为 195MB。Tim 接着使用 Buildah 创建了一个（基于 scratch 的）最小化镜像，仅仅将 coreutils 和 bash 软件包加入到镜像中，使用的脚本如下：

$ cat  ./buildah-base.sh
#!/bin/bash

set -x

# build a minimal image
newcontainer=$(buildah from scratch)
scratchmnt=$(buildah mount $newcontainer)

# install the packages
yum install --installroot $scratchmnt bash coreutils --releasever 7 --setopt install_weak_deps=false -y
yum clean all -y --installroot $scratchmnt --releasever 7

sudo buildah config --cmd /bin/bash $newcontainer

# set some config info
buildah config --label name=centos-base $newcontainer

# commit the image
buildah unmount $newcontainer
buildah commit $newcontainer centos-base

$ sudo ./buildah-base.sh

$ sudo buildah images
IMAGE ID               IMAGE NAME                                             CREATED AT            SIZE
8379315d3e3e     docker.io/library/centos-base:latest           Mar 25, 2018 17:08   212.1 MB

Tim 想知道为何 Buildah 镜像体积反而大 17MB，毕竟 python 和 yum 软件包都没有安装到 Buildah 镜像中，而这些软件已经安装到 Docker 镜像中。这个结果并不符合预期，在 Github 的相关主题中引发了广泛的讨论。

不仅 Red Hat 的员工参与了讨论，还有不少公司外人士也加入了讨论，这很有意义。值得一提的是，GitHub 用户 @pixdrift 主导了很多重要的讨论并提出很多发现，他指出在这个 Buildah 镜像中文档和语言包就占据了比 100MB 略多一点的空间。Pixdrift 建议在 yum 安装器中强制指定语言，据此提出如下修改过的 buildah-bash.sh 脚本：

#!/bin/bash

set -x

# build a minimal image
newcontainer=$(buildah from scratch)
scratchmnt=$(buildah mount $newcontainer)

# install the packages
yum install --installroot $scratchmnt bash coreutils --releasever 7 --setopt=install_weak_deps=false --setopt=tsflags=nodocs --setopt=override_install_langs=en_US.utf8 -y
yum clean all -y --installroot $scratchmnt --releasever 7

sudo buildah config --cmd /bin/bash $newcontainer

# set some config info
buildah config --label name=centos-base $newcontainer

# commit the image
buildah unmount $newcontainer
buildah commit $newcontainer centos-base

Tim 运行这个新脚本，得到的镜像体积缩减至 92MB，相比之前的 Buildah 镜像体积减少了 120MB，这比较接近我们的预期；然而，出于工程师的天性，56% 的体积缩减不能让他们满足。讨论继续深入下去，涉及如何移除个人语言包以节省更多空间。如果想了解讨论细节，点击 Buildah 镜像体积并不小？ 这个链接。说不定你也能给出有帮助的点子，甚至更进一步成为 Buildah 项目的贡献者。这个主题的解决从一个侧面告诉我们，Buildah 软件可以多么快速和容易地创建体积最小化的容器，该容器仅包含你高效运行任务所需的软件。额外的好处是，你无需运行一个守护进程。

这个镜像体积缩减的主题让我意识到开源软件的力量。来自不同公司的大量开发者，在一天多的时间内，以开放讨论的形式进行合作解决问题。虽然解决这个具体问题并没有修改已有代码，但 Red Hat 公司外开发者对 Buildah 做了很多代码贡献，进而帮助项目变得更好。这些贡献也吸引了更多人才关注项目代码；如果像之前那样，代码作为版权保护软件的一部分放置在私有 git 仓库中，不会获得上述好处。我只用了一年的时间就转向拥抱 开源方式，而且可能不会再转回去了。

文章最初发表于 Project Atomic，已获得转载许可。

via: https://opensource.com/article/18/5/containers-buildah

作者：Tom Sweeney 选题：lujun9972 译者：pinewall 校对：wxy

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

深入了解这两个有许多共同的传统和相同的目标的操作系统之间的不同。

如果你是位二、三十岁的软件开发人员，那么你已经成长在一个由 Linux 主导的世界。数十年来，它一直是数据中心的重要参与者，尽管很难找到明确的操作系统市场份额报告，但 Linux 的数据中心操作系统份额可能高达 70%，而 Windows 及其变体几乎涵盖了所有剩余的百分比。使用任何主流公共云服务的开发人员都可以预期目标系统会运行 Linux。近些年来，随着 Android 和基于 Linux 的嵌入式系统在智能手机、电视、汽车和其他设备中的应用，Linux 已经随处可见。

即便如此，大多数软件开发人员，甚至是那些在这场历史悠久的 “Linux 革命”中长大的软件开发人员，也都听过说 Unix。它听起来与 Linux 相似，你可能已经听到人们互换使用这些术语。或者你也许听说过 Linux 被称为“类 Unix ”操作系统。

那么，Unix 是什么？漫画中提到了像巫师一样留着“灰胡子”，坐在发光的绿色屏幕后面，写着 C 代码和 shell 脚本，由老式的、滴灌的咖啡提供动力。但是，Unix 的历史比上世纪 70 年代那些留着胡子的 C 程序员要丰富得多。虽然详细介绍 Unix 历史和 “Unix 与 Linux” 比较的文章比比皆是，但本文将提供高级背景和列出这些互补世界之间的主要区别。

Unix 的起源

Unix 的历史始于 20 世纪 60 年代后期的 AT&T 贝尔实验室，有一小组程序员希望为 PDP-7 编写一个多任务、多用户操作系统。这个贝尔实验室研究机构的团队中最著名的两名成员是 Ken Thompson 和 Dennis Ritchie。尽管 Unix 的许多概念都是其前身（Multics）的衍生物，但 Unix 团队早在 70 年代就决定用 C 语言重写这个小型操作系统，这是将 Unix 与其他操作系统区分开来的原因。当时，操作系统很少，更不要说可移植的操作系统。相反，由于它们的设计和底层语言的本质，操作系统与他们所编写的硬件平台紧密相关。而通过 C 语言重构 Unix、Unix 现在可以移植到许多硬件体系结构中。

除了这种新的可移植性，之所以使得 Unix 迅速扩展到贝尔实验室以外的其他研究和学术机构甚至商业用途，是因为操作系统设计原则的几个关键点吸引了用户和程序员们。首先是 Ken Thompson 的 Unix 哲学成为模块化软件设计和计算的强大模型。Unix 哲学推荐使用小型的、专用的程序组合起来完成复杂的整体任务。由于 Unix 是围绕文件和管道设计的，因此这种“管道”模式的输入和输出程序的组合成一组线性的输入操作，现在仍然流行。事实上，目前的云功能即服务（FaaS）或无服务器计算模型要归功于 Unix 哲学的许多传统。

快速增长和竞争

到 70 年代末和 80 年代，Unix 成为了一个操作系统家族的起源，它遍及了研究和学术机构以及日益增长的商业 Unix 操作系统业务领域。Unix 不是开源软件，Unix 源代码可以通过与它的所有者 AT&T 达成协议来获得许可。第一个已知的软件许可证于 1975 年出售给 伊利诺伊大学 University of Illinois 。

Unix 在学术界迅速发展，在 Ken Thompson 在上世纪 70 年代的学术假期间，伯克利成为一个重要的活动中心。通过在伯克利的各种有关 Unix 的活动，Unix 软件的一种新的交付方式诞生了： 伯克利软件发行版 Berkeley Software Distribution （BSD）。最初，BSD 不是 AT&T Unix 的替代品，而是一种添加类似于附加软件和功能。在 1979 年， 2BSD（第二版伯克利软件发行版）出现时，伯克利研究生 Bill Joy 已经添加了现在非常有名的程序，例如 vi 和 C shell（/bin/csh）。

除了成为 Unix 家族中最受欢迎的分支之一的 BSD 之外，Unix 的商业产品的爆发贯穿了二十世纪八、九十年代，其中包括 HP-UX、IBM 的 AIX、 Sun 的 Solaris、 Sequent 和 Xenix 等。随着分支从根源头发展壮大，“Unix 战争”开始了，标准化成为社区的新焦点。POSIX 标准诞生于 1988 年，其他标准化后续工作也开始通过 The Open Group 在 90 年代到来。

在此期间，AT&T 和 Sun 发布了 System V Release 4（SVR4），许多商业供应商都采用了这一版本。另外，BSD 系列操作系统多年来一直在增长，最终一些开源的变体在现在熟悉的 BSD许可证下发布。这包括 FreeBSD、 OpenBSD 和 NetBSD，每个在 Unix 服务器行业的目标市场略有不同。这些 Unix 变体今天仍然有一些在使用，尽管人们已经看到它们的服务器市场份额缩小到个位数字（或更低）。在当今的所有 Unix 系统中，BSD 可能拥有最大的安装基数。另外，每台 Apple Mac 硬件设备从历史的角度看都可以算做是 BSD ，这是因为 OS X（现在是 macOS）操作系统是 BSD 衍生产品。

虽然 Unix 的全部历史及其学术和商业变体可能需要更多的篇幅，但为了我们文章的重点，让我们来讨论 Linux 的兴起。

进入 Linux

今天我们所说的 Linux 操作系统实际上是 90 年代初期的两个努力的结合。Richard Stallman 希望创建一个真正的自由而开放源代码的专有 Unix 系统的替代品。他正在以 GNU 的名义开发实用程序和程序，这是一种递归的说法，意思是“GNU‘s not Unix!”。虽然当时有一个内核项目正在进行，但事实证明这是一件很困难的事情，而且没有内核，自由和开源操作系统的梦想无法实现。而这是 Linus Torvald 的工作 —— 生产出一种可工作和可行的内核，他称之为 Linux -- 它将整个操作系统带入了生活。鉴于 Linus 使用了几个 GNU 工具（例如 GNU 编译器集合，即 GCC），GNU 工具和 Linux 内核的结合是完美的搭配。

Linux 发行版采用了 GNU 的组件、Linux 内核、MIT 的 X-Windows GUI 以及可以在开源 BSD 许可下使用的其它 BSD 组件。像 Slackware 和 Red Hat 这样的发行版早期的流行给了 20 世纪 90 年代的“普通 PC 用户”一个进入 Linux 操作系统的机会，并且让他们在工作和学术生活中可以使用许多 Unix 系统特有的功能和实用程序。

由于所有 Linux 组件都是自由和开放的源代码，任何人都可以通过一些努力来创建一个 Linux 发行版，所以不久后发行版的总数达到了数百个。今天，distrowatch.com 列出了 312 种各种形式的独特的 Linux 发行版。当然，许多开发人员通过云提供商或使用流行的免费发行版来使用 Linux，如 Fedora、 Canonical 的 Ubuntu、 Debian、 Arch Linux、 Gentoo 和许多其它变体。随着包括 IBM 在内的许多企业从专有 Unix 迁移到 Linux 上并提供了中间件和软件解决方案，商用 Linux 产品在自由和开源组件之上提供支持变得可行。红帽公司围绕 Red Hat Enterprise Linux（红帽企业版 Linux） 建立了商业支持模式，德国供应商 SUSE 使用 SUSE Linux Enterprise Server（SLES）也提供了这种模式。

比较 Unix 和 Linux

到目前为止，我们已经了解了 Unix 的历史以及 Linux 的兴起，以及 GNU/自由软件基金会对 Unix 的自由和开源替代品的支持。让我们来看看这两个操作系统之间的差异，它们有许多共同的传统和许多相同的目标。

从用户体验角度来看，两者差不多！Linux 的很大吸引力在于操作系统在许多硬件体系结构（包括现代 PC）上的可用性以及类似使用 Unix 系统管理员和用户熟悉的工具的能力。

由于 POSIX 的标准和合规性，在 Unix 上编写的软件可以针对 Linux 操作系统进行编译，通常只有少量的移植工作量。在很多情况下，Shell 脚本可以在 Linux 上直接使用。虽然一些工具在 Unix 和 Linux 之间有着略微不同的标志或命令行选项，但许多工具在两者上都是相同的。

一方面要注意的是，macOS 硬件和操作系统作为主要针对 Linux 的开发平台的流行可能归因于类 BSD 的 macOS 操作系统。许多用于 Linux 系统的工具和脚本可以在 macOS 终端内轻松工作。Linux 上的许多开源软件组件都可以通过 Homebrew 等工具轻松获得。

Linux 和 Unix 之间的其他差异主要与许可模式有关：开源与专有许可软件。另外，在 Unix 发行版中缺少一个影响软件和硬件供应商的通用内核。对于 Linux，供应商可以为特定的硬件设备创建设备驱动程序，并期望在合理的范围内它可以在大多数发行版上运行。由于 Unix 家族的商业和学术分支，供应商可能必须为 Unix 的变体编写不同的驱动程序，并且需要许可和其他相关的权限才能访问 SDK 或软件的分发模型，以跨越多个二进制设备驱动程序的 Unix 变体。

随着这两个社区在过去十年中的成熟，Linux 的许多优点已经在 Unix 世界中被采用。当开发人员需要来自不属于 Unix 的 GNU 程序的功能时，许多 GNU 实用程序可作为 Unix 系统的附件提供。例如，IBM 的 AIX 为 Linux 应用程序提供了一个 AIX Toolbox，其中包含数百个 GNU 软件包（如 Bash、 GCC、 OpenLDAP 和许多其他软件包），这些软件包可添加到 AIX 安装包中以简化 Linux 和基于 Unix 的 AIX 系统之间的过渡。

专有的 Unix 仍然活着而且还不错，许多主要供应商承诺支持其当前版本，直到 2020 年。不言而喻，Unix 还会在可预见的将来一直出现。此外，Unix 的 BSD 分支是开源的，而 NetBSD、 OpenBSD 和 FreeBSD 都有强大的用户基础和开源社区，它们可能不像 Linux 那样显眼或活跃，但在最近的服务器报告中，在 Web 服务等领域它们远高于专有 Unix 的数量。

Linux 已经显示出其超越 Unix 的显著优势在于其在大量硬件平台和设备上的可用性。 树莓派 Raspberry Pi 受到业余爱好者的欢迎，它是由 Linux 驱动的，为运行 Linux 的各种物联网设备打开了大门。我们已经提到了 Android 设备，汽车（包括 Automotive Grade Linux）和智能电视，其中 Linux 占有巨大的市场份额。这个星球上的每个云提供商都提供运行 Linux 的虚拟服务器，而且当今许多最受欢迎的原生云架构都是基于 Linux 的，无论你是在谈论容器运行时还是 Kubernetes，或者是许多正在流行的无服务器平台。

其中一个最显著的代表 Linux 的优势是近年来微软的转变。如果你十年前告诉软件开发人员，Windows 操作系统将在 2016 年“运行 Linux”，他们中的大多数人会歇斯底里地大笑。 但是 Windows Linux 子系统（WSL）的存在和普及，以及最近宣布的诸如 Docker 的 Windows 移植版，包括 LCOW（Windows 上的 Linux 容器）支持等功能都证明了 Linux 在整个软件世界中所产生的影响 —— 而且显然还会继续存在。

via: https://opensource.com/article/18/5/differences-between-linux-and-unix

作者：Phil Estes 选题：lujun9972 译者：MjSeven 校对：wxy

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