网站可靠性工程师 （ Site Reliability Engineer ） 是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。

本文为 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑的 《网站可靠性工程》 Site Reliability Engineering 一书的摘录。

SRE（ 网站可靠性工程 （ Site Reliability Engineering ） ）在 11 月 7-10 日在阿姆斯特丹举办的 O'Reilly Velocity 会议上也有提到。

介绍

希望不是一种策略。 （ Hope is not a strategy. ）

—— 传统的 SRE 如是说

一个公认的事实是系统不会自己运行。 那么，一个系统 — 尤其是复杂大规模系统 — 应该怎么运行呢？

系统管理员的服务管理方法

以前，公司雇用系统管理员来运行复杂的计算系统。

系统管理员（或者称为 sysadmin）这种方式包括整合现有软件组件，使之互相协作来完成一个服务。系统管理员的任务是运行服务，响应事件，并在事件发生时进行更新。随着系统复杂度的增长和流量的增长，事件和更新也相应增长，导致管理员团队也越来越庞大才能完成更多的工作。由于系统管理员的角色需要的技能与产品开发人员有很大不同，开发和系统管理员被分为不同的团队：“开发”和“运维”。

系统管理员模式的服务管理有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个已被人们所熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手系统管理团队不必重新发明轮子以及从头设计系统。

此方式将公司开发和运维分离，也有一些缺点和困难。主要有两类：直接代价和间接代价。

直接代价很显而易见了。利用依靠手工干预来进行变更管理和事件处理的团队进行服务管理，当服务和/或流量增长时，成本是很昂贵的，因为团队随着系统负载的增长也在相应增长。

开发/运维分离的间接代价可能不那么明显，但常常比直接代价还要昂贵。代价来自于两个团队背景，技术，激励都非常不同。他们使用不同的词汇来描述所面临的情境；对技术方案的风险和可能性他们持不同的假设；对产品稳定性的目标级别也会有不同的争议。团队的分离很容易导致不只是激励的不同，还有沟通、目标的不同，以及最终，信任和尊重的分离。这是一种恶性循环。

因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在开发团队的核心上，他们希望推出新功能，并看到它们被用户采纳。在运维团队的核心上， 他们希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。

两个团队都明白，以最想要的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用常见的斗争形式来提高他们的利益。 运维团队试图通过提高发布和变更门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对每个问题的显式审查，这些问题过去都曾经引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有检查元素都一样重要。开发团队很快学会了如何回应。他们通过较少的“发布”和更多的“功能切换”、“增量更新”或 “选择性失明”来规避。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。

Google 的服务管理方法：网站可靠性工程

冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行自己的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由系统工程师手动完成的工作。

什么是 网站可靠性工程 （ Site Reliability Engineering ） ，是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时所发生的结果。当我在 2003 年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我以自己是一名 SRE 的方式，设计和管理了一个我想要的团队的样子。这个团队已经成为了 Google 的目前的 SRE 团队，它仍如最初一名终生软件工程师所想象的那个样子。

Google 服务管理方法的主要构成部分是由每个 SRE 团队组成的。作为一个整体，SRE 可以分为两大类。

50-60％ 的人是 Google 软件工程师，或者更确切地说，是通过 Google 软件工程师的标准程序招聘的人。其他 40-50％ 的候选人非常接近 Google 软件工程师资格（即拥有所需技能集的 85-99％），以及一些具有大多数软件工程师没有的一些 SRE 技术技能的人。到目前为止，UNIX 系统底层和网络（第 1 层到第 3 层）的专业知识是我们寻求的两种最常见的替代技术技能。

所有的 SRE 的共同点是有开发软件系统以解决复杂问题的信念和能力。在 SRE 中，我们密切跟踪两个团队的职业发展，并且迄今为止发现在两种工程师之间的表现没有实际差异。事实上，SRE 团队的多样性背景经常产生聪明、高质量的系统，这显然是几个技能集合成的产物。

我们这样招聘 SRE 的结果是，我们有了这样一个团队：（a）手动执行任务很快会变得无聊。（b）他们有必要的技能集来写出软件以取代以前的手动操作，即使解决方案很复杂。SRE 还会与其他开发部门分享学术以及知识背景。因此，SRE 从根本上做了一个运维团队历来做的工作，但它使用具有软件专业知识的工程师，并期望这些内在倾向于使用软件并且有能力用软件的人用软件设计并实现自动化来代替人力劳动。

按照设计，至关重要的是 SRE 团队专注于工程。没有恒定的工程，运维工作增加，团队将需要更多的人来上工作量。最终，传统的以运维为中心的团队与服务规模呈线性关系：如果服务支持的产品成功，运维工作将随着流量而增长。这意味着雇用更多的人一遍又一遍地完成相同的任务。

为了避免这种命运，负责管理服务的团队需要写代码，否则就会被工作淹没。因此，Google 为 SRE 们设置了一个 “运维” 工作的上限，如任务单、紧急呼叫、手动任务最多只占 50% 工作量。此上限确保 SRE 团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限；随着时间的推移，除了自己的设备，SRE 团队应该只有很少的运维工作，他们几乎可以完全从事开发任务，因为服务基本上可以运行和维修自己：我们想要的系统是自动的，而不只是自动化。在实践中，规模和新功能始终是 SRE 要考虑的。

Google 的经验法则是，SRE 团队必须花费剩余的 50％ 的时间来进行实际开发。那么我们该如何执行这个阈值呢？首先，我们必须测量 SRE 如何花费时间。通过测量，我们确保团队不断花费不到 50% 的时间用于开发改变他们实践的工作上。通常这意味着会将一些运维负担转移回开发团队，或者给团队添加新的员工，而不指派该团队额外的运维责任。意识到在运维和开发工作之间保持这种平衡使我们能保证 SRE 具有参与创造性的自主工程的空间，同时仍然保留从运维那学来的智慧。

我们发现 Google SRE 的运行大规模系统的方法有很多优点。由于 SRE 是直接修改代码以使 Google 的系统可以运行自己，SRE 团队的特点是快速创新以及大量接受变革。这样的团队能相对价廉地支持相同的服务，面向运维的团队需要大量的人。相反，运行、维护和改进系统所需的 SRE 的数量随系统的大小而线性收敛。最后，SRE 不仅规避了开发/运维分裂的障碍，而且这种结构也改善了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉训练了整个团队，并且提高了那些在学习构建百万级别分布式系统上有困难的开发人员的技能。

尽管有这些好处，SRE 模型的特点是其自身独特的挑战。 Google 面临的一个持续挑战是招聘 SRE：SRE 不仅与产品开发招聘流程竞争相同的候选人，而且我们将招聘人员的编码和系统工程技能都设置得如此之高，这意味着我们的招聘池必然很小。由于我们的学科相对新颖独特，在如何建立和管理 SRE 团队方面没有太多的行业信息（不过希望这本书能朝着这个方向迈进！）。一旦 SRE 团队到位，他们潜在的非正统的服务管理方法需要强有力的管理支持。例如，一旦错误预估耗尽，除非是管理层的强制要求, 否则在季度剩余的时间里决定停止发布可能不会被产品开发团队所接受。

DevOps 或者 SRE？

“DevOps” 这个术语在 2008 年末出现，并在写这篇文章时（2016 年早期）仍在发生变动。 其核心原则：IT 部门在系统设计和开发的每个阶段的参与、严重依赖自动化与人力投入、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为几种核心 SRE原则向更广泛的组织，管理结构和人员的推广。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。

作者简介：Benjamin Treynor Sloss 创造了“ 网站可靠性工程 （ Site Reliability Engineering ） ”一词，他自 2003 年以来一直负责 Google 的全球运营、网络和生产工程。截至 2016 年，他管理着全球范围内一个大约 4000 名软硬件和网络工程师团队。

via: https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering

作者：Benjamin Treynor 译者：geekpi 校对：jasminepeng

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

这是一篇来自 Canonical 的软件工程师 Alan Griffiths 的一篇游客文章。如果你也想投稿，请联系 [email protected]

Mir 是一个计算机显示的管理应用的支持项目。它可以与当前 Ubuntu 桌面（及很多其他桌面）上使用的、我们更熟悉的 X-Window 相比较。我下面会讨论 Mir 的一些动机，但本篇的目的是澄清 Mir 和 Unity 8 之间的关系。

大多数时候你听说 Mir 时都会提到 Unity 8。这并不奇怪，因为 Unity 8 是 Canonical 新的用户界面 shell，用户会一直与它交互。 Mir “只”是使这成为可能。Unity 8 目前用于手机和平板电脑，也可以在 Ubuntu 16.10 桌面上“预览”它。

在这里我想解释一下，可以不用 Unity 8 也可以使用 Mir。要么作为替代 shell，要么作为嵌入式环境的更简单的界面：信息亭，电子标牌等。Mir “抽象层”证明了这一点，它提供了三个重要的元素：

1. libmiral.so - Mir 的稳定接口，提供基本的窗口管理；
2. miral-shell - 一个提供“传统”和“平铺”窗口管理的示例 shell；
3. miral-kiosk - 一个仅提供基本窗口管理的示例“信息亭”。

miral-shell 和 miral-kiosk 示例服务器可从 zesty 的归档文件中获得，Kevin Gunn 已经在“Voices”上写了一篇基于 miral-kiosk 的“信息亭”的概览的博文。我将在下面给出更多关于使用这些例子的细节，但在我的“voices”博客上有更多（包括“如何”开发自己的替代 Mir 服务器）。

使用 MIR

Mir 是一套编程库，而不是独立的程序。这意味着这需要程序去调用它实现相应的功能。有两种方式去使用 Mir 库：编写程序的时候作为“客户端”，或者在实现 shell 时作为“服务端”。客户端（和 X11 一起）典型是使用工具库，而不是直接使用 Mir（或者 X11）。

GTK、Qt 和 SDL2 中有对 Mir 的支持。当在那些工具库中启用对它的支持时（默认在 Ubuntu 中启用支持），意味着使用这些工具的程序应该“可以工作”于 Mir 中。除此之外还有一个 Xmir：一个运行于 Mir 的 X11 服务器，这允许基于 X 的服务运行在 Mir 服务端上。

但是开始之前 Mir 客户端需要一个相匹配的 Mir 服务端。在最后一个开发周期中，Mir 团队在演示中将 MirAL 作为编写 Mir 服务端的推荐方法，并推出了一个“miral-examples”包。在 Ubuntu 的开发版本 zesty 中，你可以从归档中安装它：

$ sudo apt install miral-examples mir-graphics-drivers-desktop qtubuntu-desktop

对于其他平台，你需要自己构建 MirAL（有关详细信息，请参阅 Mir 桌面环境示例）。

miral-examples 安装后你可以在 Unity 7 中以窗口的方式运行一个 Mir 服务端，然后在里面运行一个客户端（比如 gedit）：

$ miral-shell&
$ miral-run gedit

这会给你一个（非常基础的）“传统” 的桌面窗口管理。另外你可以试下“平铺”窗口管理器：

$ miral-shell --window-manager tiling&
$ miral-run qterminal

或者（甚至更基础的）信息亭界面：

$ miral-kiosk&
$ miral-run 7kaa

这些 Mir 服务端都不会提供带有“启动器”、通知等的完整“桌面”。但是它们演示了不使用 Unity 8 使用 Mir 的可能。

MIR 解决的问题

X-Window 系统过去是，并且现在也是，一种提供了与计算机的交互的非常成功的方式。它提供了广泛的硬件和驱动程序一致的抽象。它支持许多桌面环境和图形用户界面工具包，并可以让它们在大量计算机上一起工作。

但它来自一个与当前电脑使用方式非常不同的时代，现在有一些问题是很难满足的，因为它需要支持老旧的系统。

在 1980 年，大多数计算机是由专家管理的大型事物，将它们连接在一起“是非常困难的”。在那个时代，开发软件的成本是这样的，一个程序“监听”另一个程序获得的好处是可以忽略不计的：此时几乎没有计算机，同时它们是独立的，它们所有的工作和金融无关。

X-Window 开发于这种环境下，通过一系列扩展，它已经适应了许多变化。但它本质上是不安全的：任何应用程序可以知道显示了什么（并影响它）。你可以编写像 Xeyes（用“眼睛”跟踪光标）或“Tickeys”（通过键盘来生成打字机噪声）等应用程序。现实是，任何应用程序可以跟踪和操纵几乎所有的事情。这就是基于 X 的桌面如 Unity 7、Gnome、KDE及其它桌面工作的方式。

X-Window 中窗口管理的开放性质不适合用于具有数百万计算机连接到因特网的世界，它们用于信用卡交易和网上银行，且由非专家管理，并自愿安装来自陌生人的程序。人们越来越意识到让 X-Window 适应新的安全性和图形性能的要求是不可行的。

现在至少有两个开源项目旨在提供一个替代品：Mir 和 Wayland。虽然有些人认为两者是竞争关系，但在很多领域，它们有共同的利益：它们都需要与那些之前假定使用 X11 的其它软件交互，并且许多引入支持的工作对两者都有益。

Canonical 的 X-Window 替换品 Mir，它只将信息暴露给它需要的应用程序（因此没有按键监听或光标跟踪）。它可以满足当前时代的需求，并可以利用现代硬件，如图形处理器。

via: https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/

作者：Alan Griffiths 译者：geekpi 校对：wxy

本文由 LCTT 组织编译，Linux中国 荣誉推出

你在新的一年里需要刷哪些技能？

成为 Linux 专家的一个问题是“专家”的定义在不断变化。当我进入 Linux 世界的时候，那时认为成为一个 Linux 专家，你需要能够编译自己的内核。天啊，如果你想在笔记本电脑上使用 Linux，即便你只是用户，你也必须编译一个自定义内核。 如今编译自己的内核通常是浪费时间。这不是说它并不重要，但在开源世界，我们建立在他人成功的基础之上，而 Linux 发行版为我们提供了运行良好的内核。虽然“专家”的定义并不总是那么剧烈变化，但对 IT 专业人员的需求每年都在变化。

下面是 2017 年 Linux 专业人员的四个重要技能：

1、 安全

我不是在讨论安全专家或安全顾问。这些职位和服务当然很重要，但是随着联网设备渗透到我们生活的每一个方面，我们需要在我们做出的每一个决定中都具有安全意识。今年，我的妻子和我买了一台洗衣机和一台冰箱，它们都配备了蓝牙。黑客攻入我的漂洗系统的想法可能看起来很傻，但这都是潜在的攻击点。

当激活工作、家庭或我们的口袋中的任何系统时，我们应该考虑它们可能引发的安全问题。而且因为像联网烤面包机这样的物品不太可能及时获得固件升级，我们需要按照普通设备可能遭到破坏的思路来设计其余的系统。相比以前任何时候，我们更需要考虑来自防火墙内的攻击。不要让你的文件服务器被你的搅拌器破坏！

2、 DevOps

DevOps 不再是一个新概念。在过去两三年里，我们一直鼓励员工学习 DevOps，以便他们能够在工作中取得成功。这是个好建议，但这并不意味着我们应该完全依赖自动化工具来完成我们的工作。Chef、Puppet、Ansible、Salt Stack 及类似的工具是美好的，但我们需要了解背后发生了什么，所以当发生一些不可避免的错误，我们应该知道如何解决它。

使用 DevOps 的编程方法来计算，我们仍然需要能够维护、修复和理解在代码层之下运行的系统的人。没有 Linux 专家，云计算将是一个可怕的地方，即使那个云在你自己的机房里。

3、 开发

作为系统管理员，20 年来，我从来没有时间学习编程。这听起来可能是一个借口，但这是事实。我所有的开发技能就是基本的脚本编写，以帮助我更快工作。不过，那些日子已经结束了。虽然我们需要在 DevOps 世界中拥有系统管理技能，但我们还需要系统管理员拥有编程技能。

如果你是一个像我一样的老练的系统管理员，你可能已经采用 DevOps 并每天使用它。如果你真的想要胜过他人，你需要学习如何以编程方式解决问题，并且不要认为 Chef 或 Puppet 代码只是配置文件。 每个 IT 专业人员都至少需要掌握编程的概念，因为 DevOps 代码至少在某种程度上抽象了 IT 的每个方面。

4、 软技能

通常，我们在准备职业生涯时所考虑的最后一件事是所谓的 软技能 - 社交和沟通技巧 - 但是它们可能是最有可能决定你走向成功的技能。无论你正在寻找一份新工作，还是试图适应当前职业生涯的变化，软技能是至关重要的。

划分 IT 各个领域的标准是交错的，并且良好的沟通能力使得这些模糊的分野成为一个有利条件，而不是绊脚石。我们正生活在一个开发人员围绕着服务器，而运维团队编写 Ruby 代码来维护服务器农场的世界里。这些都是 IT 中的大胆的新思想，如果人们不能在不同部门间很好的沟通，工作场所将迅速有敌对气氛。此外，IT 人员总是需要与其他业务领域的人员进行有效沟通。而且，现在比以往有更大的需求。

你计划在 2017 年里添加什么到你的技能中？在评论栏中让我们知道吧。

作者简介：

Shawn Powers - 自 2009 年起是 CBT Nuggets (www.cbtnuggets.com) 的一名 IT 训练员，专于 Linux、Chef 及为大规模网络集成多个平台。他在 2016 年 12 月发布了一个在线高级 Linux 认证课程（LPIC-2）。

via: https://opensource.com/article/17/1/yearbook-4-hot-skills-linux-pros-2017

作者：Shawn Powers 译者：geekpi 校对：jasminepeng

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

我与许多人分享过一个愿景，我们很快就能使用由开源硬件（OSH）和开源软件所驱动的现代而强大的设备。

开放硬件是那种有完整的文档，并且可以根据你的需求自由使用、研究、修改和复制的设备。它从原理图到 PCB 布局的所有内容全都是公开的，包括驱动硬件的软件。近年来有所进步，有更多的硬件被开放了，但是我们的 PC 和其它设备中的微处理器却被限制在了桌面端的以 x86 为主导的、封闭的指令集架构（ISA），或者智能手机/平板设备上的 ARM 变体。这两个指令集架构都是闭源的，并且不能用于开放设备。此外，许多广泛使用的 ARM 实现，比如 A9 或 Snapdragon 在这些已经专有的指令集架构上添加了进一步的专有层。

RISC-V 是不同的。在加州大学伯克利分校的研究人员于 2010 年推出的 RISC-V（发音 risk-five）是根据同样的初始 RISC（ 精简指令集计算 （ Reduced Instruction Set Computing ） ） CPU 设计构建的，其基础是其它熟悉的指令集架构，如 ARM、MIPS、PowerPC 和 SPARC，但目的是开放且不受专利保护（注意：目前，RISC-V 规范仅供私人或教育用途使用，计划在将来完全开放）。RISC 设计策略与 x86 系列的复杂指令集计算（CISC）设计相反。

虽然 RISC-V 不是现有唯一的开放指令集架构，但它是唯一一个极速推进的。指导指令集架构的开发和采用的 RISC-V 基金会有一些相当大的捐赠者，如 Oracle、Western Digital、HP、Google、IBM 和 Nvidia。我可以看到名单上缺少的几个著名的芯片制造商。似乎大的玩家们已经意识到，与软件一样，硬件会在开放下发展得更快更好。而且，任何人使用它你都不必付费。因为开发中的困难和成本，像这样的项目并没有被更快取得成功。现在，一个公开的结果是大的公司正在跟进，开发资金正在源源而来。

RISC-V 在学术界也有很多支持。从在伯克利的孵化到在世界范围内超过 35 个大学项目协助其发展，在那里不缺乏聪明的头脑为这个项目工作。

在其背后也有进展。在软件方面，人们正在将程序移植到 RISC-V 上，让它启动起来。Fedora 已经移植了成千上万的程序 - 下面是 Fedora/RISC-V 在 QEMU 中启动：

向 Richard WM Jones 做出这么棒的动画致敬

在硬件方面，人们正在制造开发板。HiFive1 是一个成功众筹的项目，它是来自 SiFive 的一块 Arduino 板，由他们的 FE310 SoC 驱动，这是一块 32 位的 RISC-V 芯片，运行频率为 320+ MHz。 它会在 2 月发货，你可以在这里预订一个，价格为 $59。

这一切听起来很棒 - 我希望他们能够交付，因为我们都将从中受益非浅。如果可以，请支持这个项目。告诉人们这个东西。购买一块 HiFive1，看看它上面运行了什么。我在你的未来看到了这些芯片。

via: https://www.darrentoback.com/can-risc-v-linux-of-microprocessors-start-an-open-hardware-renaissance

作者：dmt 译者：geekpi 校对：wxy

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

让我们一起来回顾 Linux 早期版本的美好时光

开源软件最具独特性的一点就是它永远不会真正的走到 EOL（生命的终点）。它们的磁盘镜像文件大都可以一直在网上找到，并且它们的许可证也不会过期，因此，我们可以返回去找到那些老版本的 Linux 系统，并在虚拟机中安装它们，这都是很容易做到的。通过回顾那些珍贵的系统画面，让我们来回顾 Linux 系统这么多年来所发生的翻天覆地的变化。

我们从 Slackware 1.01 版本来开始这段旅程，在二十多年前它就发布在 comp.os.linux.announce 新闻组上了。

Slackware 1.01 版本系统 （1993 年）

Slackware 1.01

体验 Slackware 1.01 系统最爽的是在 Qemu 模拟器软件 2014 免费镜像系列中有一个预先制作好的镜像文件，因此你可以不用手动去执行安装任务（真不习惯这种“奢华”待遇）。其引导启动命令如下：

$ qemu-kvm -m 16M -drive if=ide,format=qcow2,file=slackware.qcow2 \
 -netdev user,id=slirp -device ne2k_isa,netdev=slirp \
 -serial stdio -redir tcp:22122::22

在 1993 年那个版本的 Linux 系统中，很多东西都跟我们所想像的一样。所有常用的基本命令，比如 ls 和 cd 命令的使用方式，以及所有的基本工具（gawk 、cut 、 diff 、 perl，当然还有 Volkerding 最喜欢的 elvis 工具）现在都在使用，而且也包含在如今的 Linux 系统中，但是仍然有一小部分东西让我感到惊讶。当你尝试使用 tab 补全命令方式来列出上百个文件时， BASH 会非常友好地提示用户确认，并且那些查看压缩文件的工具（比如 zless 和 zmore 以及 zcat）都已经出现了。很多方面都超乎我的预计，总之，该系统给人的感觉就是超级现代化。

不过，该系统没有软件包管理的相关概念。所有软件的安装和卸载都得手动完成，也不能查询出已安装的软件包。

总的来说，Slackware 1.01 系统感觉更像是一个非常现代化的 UNIX 系统，或者更恰当的说，它给人的感觉就是一个 Linux 用户在操作一个现代化的 UNIX 系统。很多东西都非常熟悉，但是也不尽相同。这个在 1993 年发布的操作系统中，并不是所有东西都跟你想像中的一样。

Debian 0.91 版本系统（1994 年）

为了尝试 Debian 0.91 版本系统，我使用的是 Ibiblio 数字档案 网站下载的软盘镜像文件，该系统最初发布在 1994 年。启动命令如下：

$ gunzip bootdsk.gz basedsk1.gz basedsk2.gz
$ qemu-system-i386 -M pc -m 64 -boot order=ac,menu=on \
   -drive file=bootdisk,if=floppy,format=raw \
   -drive file=debian.raw,if=ide,format=raw \
   -device ne2k_isa,netdev=slirp \
   -serial msmouse -vga std \
   -redir tcp:22122::22 \
   -netdev user,id=slirp

从 Debian 0.91 的启动磁盘启动后进入到一个简洁的 shell 界面，有很清晰的提示信息告诉你下一步将要执行的操作。

安装过程进行得非常顺利。从磁盘分区，写入 ext2 文件系统到分区，到显示图形菜单操作界面要经过七个步骤，之后开始复制 basedsk 镜像文件。这里使用的是以最小化方式来安装 Debian 系统，跟大家在安装自己的 Linux 系统过程中的很多步骤都非常相似。

Debian 系统因其自身的包管理器而出名，但是在早期的版本中只是有一些提示功能而已。有 dpkg 命令，但它是一个基于交互式菜单的系统——一种古老的 aptitude，有多个层级的可选菜单，并且自然地附带了几个可用软件包。

尽管如此，你也可以感受到其简便的设计理念。你只需下载三个软盘镜像文件，最后合成一个可启动的系统，然后就可以使用一个简单的文本菜单来安装更多的东西。我由衷的明白了为什么 Debian 系统如此受欢迎的原因。

Jurix/S.u.S.E. 系统（1996 年）

安装 Jurix 系统

Jurix 系统是 SUSE 系统的前身， Jurix 带有的二进制的 .tgz 软件包会被组织到类似 Slackware 安装包结构的目录中，其安装包本身也跟 Slackware 的安装包很相似。

 $ qemu-system-i386 -M pc -m 1024 \
   -boot order=ac,menu=on \
   -drive \
    file=jurix/install,if=floppy,format=raw \
   -drive file=jurix.img,if=ide \
   -drive file=pkg.raw,if=ide,format=raw \
   -device ne2k_isa,netdev=slirp \
   -serial msmouse -vga std \
   -redir tcp:22122::22 \
   -netdev user,id=slirp

因为我不是刻意去寻找最早期的版本， Jurix 系统是找到的第一个真正‘感觉’像是打算给用户使用的有图形界面的 Linux 发行版。 XFree86 图形桌面环境已默认安装了，如果你不打算使用该工具，选择退出该环境即可。

比如 /usr/lib/X11/XF86Config （该文件后来变成了 Xorg.conf ）这个配置文件已经存在了，这让我完成了使用 GUI 前的 90% 的工作，但是我花费了一整个周末的时间来调试 vsync 、hsync和 ramdac 颜色表重写，最后我完全放弃了。

在 Jurix 系统上安装软件包也非常简单；找到源路径下的 .tgz 文件，然后运行一个常用的 tar 命令： $ su -c 'tar xzvf foo.tgz -C /' 该软件包就会被解压到根分区，并准备好使用了。我刚开始的时候安装了几个之前未安装过的软件包，发现操作也很简单、快速且非常可靠。

SUSE 5.1 版本系统（1998 年）

在 SuSE 5.1 系统上运行 FVWM 窗口管理器

我是使用 1998 年在马里兰州的一家软件商店里买的 InfoMagic 光盘来安装 SUSE 5.1 系统的。其引导启动命令如下：

 $ qemu-system-i386 -M pc-0.10 -m 64 \
   -boot order=ad,menu=on \
   -drive file=floppy.raw,if=floppy,format=raw \
   -cdrom /dev/sr0 \
   -drive file=suse5.raw,if=ide,format=raw \
   -vga cirrus -serial msmouse

安装过程相对于前面几次来说要复杂得多。 YasT 工具在软盘和可引导光盘之间搞乱了配置文件和设置，还需要重启好多次，在重启了好几次后我才反应过来是我操作顺序不当导致的问题。在安装过程中，我就犯了两次同样的错，我只是习惯了 YasT 工具的安装方式，到第三次才顺利的安装成功，这对于一个 Linux 用户将来的成长来说是一个很大的教训及经验。

我使用 SUSE 5.1 的主要目的就是体验其 GUI 桌面环境。配置的过程已经很熟悉了，使用几个漂亮的图形界面工具（包括一个很好用的 XF86Setup 前端界面配置工具）来测试和调试鼠标及显示器问题。我用了一个小时不到的时间就调试好 GUI 界面，并正常运行起来，其中大部分时间是耽搁在研究 Qemu 的虚拟显卡可以提供哪种分辨率和颜色方案。

可选用的桌面环境包括 fvwm、fvwm2 和 ctwm。我使用的是 fvwm，并且运行得也正常。我发现 tkDesk 这个 dock 式的文件管理器跟 Ubuntu 系统的 Unity 的启动栏非常的相似。

使用该系统总的来说还是非常令人愉快的，一旦成功安装了桌面环境并正常运行起来，SUSE 5.1 可以说是取得了令人瞩目的成功。

Red Hat 6.0 版本系统（1999 年）

在 Red Hat 6 系统上运行 GIMP 1.x 图像处理程序

下一个系统 Red Hat 6.0 安装盘我刚好家里有。不是 RHEL 6.0 —— 而是 Red Hat 6.0，这是一个在 RHEL 或 Fedora 系统出现之前商店里就有卖的桌面版系统。这个安装盘是我在 1999 年 6 月份买的。

其引导启动命令如下：

 $ qemu-system-i386 -M pc-0.10 -m 512 \
   -boot order=ad,menu=on \
   -drive file=redhat6.raw,if=ide,format=raw \
   -serial msmouse -netdev user,id=slirp \
   -vga cirrus -cdrom /dev/sr0

整个安装过程由完全由安装向导指引的，并且速度非常快。无论是选择要安装什么包（按工作站， 服务器， 及自定义进行分组 ），对磁盘分区，或者是启动安装，你都不会出现进行不下去的问题。

Red Hat 6 包括一个 xf86config 应用程序来一步步指导你完成 X 配置工作，尽管它有一些之后的 X 系统不认的奇怪的鼠标模拟选项。它比手动修改 Xf86Config 配置文件要容易得多，但是要正确无误的配置好 X 环境显然不是一个简单的工作。

Red Hat 6 绑定的桌面环境是 GNOME ，没错就是它，但是窗口管理器是早期的 Enlightenment ，它同样也提供了主声卡服务进程。xdm 和 gdm 都作为登录管理器包含在其中，以便普通用户也可以登录到系统中，即便没有权限启动或者关闭 X 进程，这在多用户系统中是非常重要的。

它缺少一些主要的应用程序；还没有 gedit 工具，没有重要的统一办公应用程序，更没有软件包管理器。有 GnoRPM 工具，这是一个图形界面的 RPM 包管理工具，用于查看及删除软件包，这个工具跟 yum 或 PackageKit 工具非常类似，还有基于图形界面的文件编辑器 gnotepad+ （尽管没有 Emacs 工具）。

总的来说，桌面环境在使用上也是非常直观的。跟后期实现的 GNOME 桌面环境不同，这个早期版本在屏幕底部有个面板，其中有一个应用程序菜单和启动器图标，在中间位置有个虚拟桌面控制器。我无法想象其它操作系统的用户在使用这个桌面环境时会有多么的不习惯。

Red Hat 6 对于 Linux 系统来说是一个巨大的进步，很明显 Linux 系统正向着成为一个适用的桌面系统方向发展。

Mandrake 8.0 版本系统（2001 年）

Mandrake: Linux 系统的一个转折点

Mandrake 8.0 于 2001 年发布，这已经可以跟 Apple OS 9.2 和 Windows ME 系统相提并论了。

我反而觉得老版本的系统才更安全一些。

其引导启动命令如下：

 $ qemu-system-i386 \
   -M pc-0.10 -m 2048 \
   -boot order=ad,menu=on \
   -drive file=mandrake8.qcow2 \
   -usb -net nic,model=rtl8139 \
   -netdev user,id=slirp \
   -vga cirrus \
   -cdrom mandrake-8.0-i386.iso

我一直觉得 Red Hat 系统的安装过程非常棒了，但是 Mandrake 的安装过程更是让人喜出望外。它非常友好，并且在继续下一步之前还给用户一个测试配置文件的机会，易用高效，使用起来像魔法一样。我也不用导入自己的 XF86Config 配置文件，因为 Mandrake 的安装程序会自动完成该任务。

Mandrake 8.0 系统的安装程序

实际上，使用 Mandrake 系统跟使用其它的桌面环境系统的感受基本相同。让我很惊奇的是它们在操作体验上如此的相似。我相信，即使这个时候我在使用 Mandrake 系统的过程中遇到一些问题，以我自己的技术能力甚至是一个技术水平一般的年轻人也很容易解决。它的界面非常直观，帮助文档也很有用，并且软件包管理起来也很容易，只是那个时候人们还不习惯直接到网上下载他们需要的任何软件包来安装。

Fedora 1 版本系统（2003 年）

基于 Red Hat 的 Fedora 系统

2003 年，新的 Fedora Core 系统发布了。 Fedora Core 基于 Red Hat 系统，它的主要目的是在 Red Hat 企业版（RHEL）成为该公司旗舰产品之前继续扛起 Linux 桌面版系统发展的大旗。

启动老版本的 Fedora Core 1 系统也没啥特别的地方：

 $ qemu-system-i386 -M pc \
   -m 2048 -boot order=ac,menu=on \
   -drive file=fedora1.qcow2 -usb \
   -net nic,model='rtl8139' -netdev user \
   -vga cirrus -cdrom fedora-1-i386-cd1.iso

安装 Fedora Core 同样简单容易； Fedora 和 Red Hat 系统在之后的 9 年中使用同样的安装器，其图形界面易用而易于理解。

Anaconda GUI 界面

使用 Fedora Core 系统的体验跟 Red Hat 6 或 7 版本没多少区别。 GNOME 图形界面很漂亮，有各种独立的配置程序助手，并且界面展示都非常的整洁和专业。

桌面上的 “Start Here” 图标指导用户前往三个位置：应用程序目录，首选项面板和系统设置。 一个红帽的图标表示应用程序菜单，而下边的 GNOME 面板里包括所有最新的 Linux 应用程序的启动器，包括 OpenOffice 办公套件和 mozilla 浏览器。

展望未来

在 2000 年左右， Linux 系统已经发展得很好并取得了巨大的进步。桌面环境前所未有的更加精致美观，有各种可用的应用程序，安装过程比其它操作操作更简易更高效。事实上，从 2000 年以来，用户和系统之间的关系更加紧密，即使到现在也没发生根本上的改变。当然还有一些更新和改善，以及数量惊人的创新方面的变化。

让我们来了解一下各个 Linux 系统项目上的演变:

• Mandrake 系统后来更名为 Mandriva，如今为 Mageia ；
• Fedora Core 随后改为 Fedora ；
• Ubuntu 脱胎于 Debian ，并且它让 “Linux” 成为一个家喻户晓的词汇；
• Valve 公司开发的 SteamOS 成为其官方游戏平台；
• Slackware 现如今仍在平稳发展。

无论你是一个 Linux 新手，还是一个技术精湛的 Linux 老用户，上面的大多数截图都构成了让 Linux 系统被记入历史的一本传记。很高兴今天我们能够回顾成为世界上最大的开源项目之一的 Linux 系统是如何发展壮大起来的。更重要的是，每一次想到自己也是 Linux 开源世界中的一员我们就无比激动，把握现在，展望未来。

作者简介：

Seth Kenlon —— Seth Kenlon 是一位独立多媒体艺术家，开源文化倡导者， Unix 极客。他还是 Slackware 多媒体产品项目的维护人员之一，官网：http://slackermedia.ml 。

题图来源：互联网档案馆书籍图片。 Opensource.com. CC BY-SA 4.0 编辑引用。

via: https://opensource.com/article/16/12/yearbook-linux-test-driving-distros

作者：Seth Kenlon 译者：rusking 校对：wxy

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

Linux 容器正在改变 IT 从业者的工作方式。相比于庞大、沉重的虚拟机，一些组织发现把他们的应用部署在容器中更有效，可以提供更快的速度，更加密集，提升他们操作的敏捷性。

从安全的角度看，容器带来了一些优势，但是也面临着它们自己的一些安全挑战。和传统的基础设施一样，为了避免安全缺陷，确保运行在一个容器内的组件和系统库的定期更新是至关重要的。但是你如何知道什么东西运行在你的容器内？为了帮助你应对这些的安全挑战，一个名为 Anchore的初创公司正在开发一个同名的开源项目，它用来帮助展示 Linux 容器中的内容。

为了了解更多关于 Anchore，我找到了 Anchore 的市场和产品的发言人 Andrew Cathrow，来了解更多关于这个开源项目背后的公司。

简而言之 Anchore 是什么? 它如何工作?

Anchore 的目标是提供一套工具，允许开发人员、运营团队、安全团队在容器的整个开发周期中保持对“监管链（Chain of Custody）”的全程可见，并提供生产部署所需的可见性、可预测性和控制性。Anchore 的引擎通过插件可以进行分析（通过提取镜像数据和元数据）、查询（允许对容器进行分析）、以及策略评估（这里的策略指可以被指定的管理的图像）。

虽然市场上有很多扫描工具，但是大部分不开源。我们认为安全合规的产品应该是开源的，否则你怎么才能信任他们。

Anchore 除了开源以外，还有两大优势，使它可以区别于市场中的商业产品。

首先，我们看的不止是操作系统的镜像。如今的扫描工具专注于操作系统的软件包，比如“你的 RPM 或 DEB 包中有CVE（安全漏洞）么？”这虽然是很重要的，你不希望你的镜像中有不安全的包，但是操作系统包只是镜像的基础。其他的层次都需要进行验证，包括配置文件、语言模块、中间件等等。你可以用的全是最新的软件包，但是可能一个配置文件配置出现错误，不安全就出现在里面。第二个不同就是允许用户添加自己的数据、查询或策略来扩展这个引擎。

什么推动了容器的校验和分析工具的需求出现？这个工具可以解决运营面临的什么问题呢？

企业使用 Docker 首要关注的就是安全，特别是他们正在部署的容器的分配和合规性。在生产环境中，从公共镜像库拉取一个镜像，运行它，并在几秒钟部署，是非常简单的，甚至不知道下面可能发生什么。终端用户在部署应用时，必须信任他们所部署的是安全、高效和易于维护的。

容器是不透明的，它们是一个包含应用程序的可部署的“黑盒”。虽然非常容易把这些镜像看作“打包的应用程序”，但是它们包括了系统的镜像和多达数百个包和成千上万个文件。如同所有在物理服务器、虚拟机或者云上的操作系统一样，镜像也需要维护。镜像或许包含了未补丁的安全缺陷、带有 bug 和错误配置的过期软件。

要对您的容器部署有信心，你需要知道底层是什么，并基于容器镜像的内容来做出决定。

如今容器的创新基本上都是开源的，你认为是为什么呢？是什么促使了它们开源呢？

在过去的 20 年中，各个组织已经经历了开源带来的优势，节省成本，减少锁定，提高了安全性和更快的创新。容器，特别是 Docker，都是非常好的例子。Docker 公司的团队不能在专有系统上创建一个新的软件部署模式，他们不能要求在修改专有系统的代码，而是与行业领导者比如谷歌、IBM、英特尔、红帽合作，朝着一个共同的目标。开源和 Linux 总是开启创新和激励产业困境。在过去，实现一个大的想法需要一个大的团队和很多资源。在开源世界，一个有着很大的创意的小公司可以工作在一个更大的社区中，通过知识共享的力量来协作，提供真正的企业创新。

为了深入的说明开源的使用，Anchroe 团队最近刚从多伦多的 LinuxCon 回来，在哪里，令人难以相信的是，微软作为钻石级的赞助商，展示了他们用在 Linux 上的产品投入的增长。Linus Toravlds 曾说过，“如果微软为 Linux 开发应用就意味着我赢了”。我要把这句话改为“开源赢了”。

容器领域的通用标准的创建还需要时间，在容器的几乎所有部分，仍有许多挑战。在这个领域，创业公司有哪些挑战？

这里有个很重要的点，就是没有开放的标准和开源，我们不可能看到快速推动容器的采用和改变行业格局的创新。开放容器倡议（OCI）由 Linux 和容器行业的行业领导者组成，正在为运行环境和镜像格式创造标准，这将使我们能够看到更多的创新。Anchore 很自豪能成为 OCI 的新成员，我们期待帮助形成标准。

你将如何围绕 Anchor 项目建立一个开源社区？

Anchore 团队来自 Ansible、Eucalyptus Systems 和 Red Hat 的领导团队，在开源社区中拥有丰富的工作经验。从一开始，Anchore 就准备创建一个强大的开源社区，我们正在应用我们在开源世界中学到的经验和教训。第一课，当然，发布要尽早尽快。我们在 6 月开源我们的检测和分析引擎，远远早于我们的商用产品，以便了确保开源项目能够独立运行，使更多的直接用户能够使用它，而无需购买 Anchore 的商用产品。通过支持、服务和增强型的数据源，有很多机会给商用产品创造更多价值，但是如果开源引擎本身没有用，我们将看不到活跃的社区。

我们将 Anchore 模块化，允许添加分析、报告和策略插件，而不需要更改核心的引擎。我们希望保证任何人都可以创建插件，所以我们选择了 Python 作为项目的基本语言，因为 Python 被开发者和系统管理员广泛应用。但是，即使你不熟悉 Python，你仍然可以使用任何你喜欢的语言或者脚本环境创建插件。如果你可以创建一个 Bash 脚本，那么你也可以创建一个 Anchore 插件。我们的目标是最大化的吸引社区的参与。虽然我们鼓励用户将贡献回馈给社区，但是我们也为这个项目构建并进行了授权，来确保可以独立创建和维护私有的插件和模块。

容器的用途不止是在服务器上更大密度的部署应用程序或者技术层面更快的速度，而且还有不同工具的组合，这些工具提供了一种不同的方式来拉近开发者和操作者共同工作。作为在这个领域工作的公司，你们希望提供一个什么样的消息来让开发者和运营产生共鸣？

随着越来越多的运行环境、编排、监控和集成产品，容器的生态系统正在快速发展。所以，我们的架构中的第一个考虑因素不是限定 Anchore 的部署和使用。我们需要确保我们可以适应任何 CI/CD 工作流，无论是私有部署还是云端部署。一个经常问到我们的问题是，Anchore 是否将提供一个包含了镜像扫描和分析的容器仓库。虽然这将大大简化我们的工作，但是这会迫使用户进入特定的部署架构，并限制了用户部署他们自己最好的组件的能力。我们已经确保 Anchore 可以和所有领先的仓库、运行环境平台、 CI/CD 平台和编排工具配合使用。

一些开发者掌握了运营技能，并转换为 DevOps 角色，我们看到系统管理员/运营团队也在更多的了解开发，转换成 DevOps 角色。我们也看到了具有混合能力的团队。我们设计了可供开发运营和安全团队使用的 Anchore ，以便他们共同定义规则和策略来评估开发周期中的任何一个环节。另外一个例子是插件/模块的架构，使任何人都可以在他们喜欢的环境中轻松创建一个模块 —— 无论是以 Python、Go、Perl、C 甚至是一个 Bash 脚本。

via: https://opensource.com/business/16/10/interview-andy-cathrow-anchore

作者：Jason Baker 译者：Bestony 校对：wxy

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