在 GPL v3 许可证颁发 11 周年之际，让我们了解一下它对自由和开源软件的持久贡献。

2017 年，我错过了为 GPL v3（GNU 通用公共许可协议的第三版）发布 10 周年撰写文章的机会。GPL v3 由 自由软件基金会 （ Free Software Foundation ） （FSF）于 2007 年 6 月 29 日正式发布，这一天在技术史上更为人熟知的事件是苹果公司推出了 iPhone 手机。一年之后的现在，我觉得应该对 GPL v3 做一些回顾。对于我来说，许多有关 GPL v3 的有趣内容可以追溯到 11 年之前，我作为积极参与者经历了当时的公共起草过程。

2005 年，经过近十年热衷于自由软件的自我沉浸，但却几乎没有任何开源法律经验可言的我被 Eben Moglen 聘用，加入 软件自由法律中心 （ Software Freedom Law Center ） （SFLC）担任法律顾问。SFLC 当时是 FSF 的外部法律顾问，我的角色被设定为关注 GPL v3 起草过程的初期公共阶段。这个机会把我从以前的并不令我满意的一次职业转变中解救出来。 自由和开源软件 （ Free and Open Source Software ） （FOSS）的法律问题成为我的新专长，我发现这一点很有吸引力，令人满意，并且在智力上有所回报。我在 SFLC 的工作，特别是我在 GPL v3 方面勇闯火线的工作，成为了我的在职培训。

GPL v3 必须被理解为早期 FOSS 时代的产物，其轮廓可能让今天的人难以想象。在 2006 年公共起草过程开始时，Linux 和开源已经不再是早年一些漫不经心的观察者所看到的几乎是同义词的情形了，但两者之间的联系仍然比现在更密切。

Linux 已经对技术行业产生深远影响的反映是，每个人都认为 GPL v2 是主要的开源许可模式。我们看到了开源（和伪开源）商业模式如寒武纪式爆发的最终震荡。一个泡沫化商业炒作包围的开源（对我来说最令人难忘的典型代表是 开源商业会议 （ Open Source Business Conference ）与软件工程专业人士目前对开源开发的接受程度几乎没有相似之处。微软凭借其不断扩大的专利组合以及对 Linux 的竞争性对抗，在 FOSS 社区中普遍被视为一种现实存在的威胁，而 SCO 诉讼已经在 Linux 和 GPL 之间笼罩上了法律风险的阴云，并且没有完全消散。

这种环境必然使得 GPL v3 的起草成为自由软件历史上前所未有的高风险事件。主要的技术公司和顶级律师事务所的律师争先恐后地对该许可协议施加影响，并确信 GPL v3 必将接管并彻底重塑开源业态及所有大量相关的商业投资。

技术社区内存在类似的心态；这在 Linux 内核开发人员于 2006 年 9 月对 GPL v3 的强烈指责中所表达的恐惧里略见一斑。我们这些接近 FSF 的人知道的多一点，但我认为我们假定新的许可协议要么是压倒性的成功，要么是彻底的失败——“成功”意味着将现有的 GPL v2 项目生态系统升级为 GPL v3，尽管也许 Linux 内核会缺席（LCTT 译注：十年过去了，Linux 内核仍旧采用 GPL v2 许可证）。实际的结果是介于两者之间的东西。

我对测量开源许可协议采用程度的尝试没有信心，近年来这种做法通常用于证明 左版 （ Copyleft ） 许可协议失去竞争优势。根据我自己的接近 Linux 和工作于 红帽 （ Red Hat ） 公司的明显有倾向性的经验，表明 GPL v3 作为自 2007 年以来推出项目的可选许可协议，享有适度的受欢迎程度。尽管 2007 年之前存在的大多数 GPL v2 项目以及它们在 2007 年以后的分支，仍然遵循旧许可协议。（GPL v3 的兄弟许可协议 LGPL v3 和 AGPL v3 从未获得过相当程度的普及）大多数现有的 GPL v2 项目（有一些明显的例外，如 Linux 内核和 Busybox）被许可为“GPL v2 或任何更高的版本”。技术界早就决定“GPL v2 或更高版本”是一个政治中立的许可协议选项，它包含了 GPL v2 和 GPL v3。这可以解释为什么 GPL v3 的采用推进得缓慢和有限，特别是在 Linux 社区中。

在 GPL v3 起草过程中，一些人表达了对 Linux 生态系统“ 巴尔干化 （ balkanized ） ”的担忧，无论是因为用户必须了解两个不同的强大左版许可协议的开销，还是因为 GPL v2 / GPL v3 的不兼容。事实证明，这些担忧完全没有根据。在主流服务器和工作站 Linux 堆栈中，这两个许可协议已经和平共存了十年。这其中部分是因为这样的堆栈由强大的左版范畴的单独单元组成（参见我对容器设置中相关问题的讨论）。至于强左版范畴单元内部的不兼容性，在这里，“GPL v2 或更高版本”的普遍性被技术界视为干净利索地解决了理论问题。尽管名义上的“GPL v2 或更高版本”升级为 GPL v3 的情况几乎没有发生过。

我已经说过，我们中间的一些 FOSS 许可协议极客已经提到了假定的左版衰退的问题。早在公共起草过程的开始阶段，GPL v3 已经在批评者那里形成了滥用，并且可以推断，有些人已经在特殊情况下的 GPL v3 不受欢迎与一般意义上的 GPL 或左版失宠之间建立了联系。

我对它的看法有所不同：很大程度上是因为它的复杂性和 巴洛克 （ baroque ） 风格，GPL v3 失去了创建强大的可以广泛地吸引现代个人软件作者和企业许可人的左版许可协议的机会。我相信今天的个人开发者往往更喜欢简短、易懂、简约的许可证，最明显的例子就是 MIT 许可证。

面临开源许可协议选项的一些公司决策者可能很自然地分享这种观点，而其他公司决策者可能认为 GPL v3 的某些部分风险太大（例如专利条款或反锁定要求）或与其商业模式不相容。具有讽刺意味的是，未能吸引这些群体的 GPL v3 的一部分特性是因为有意识地试图使许可协议吸引这些具备相同类型利益的群体。

GPL v3 是如何变得如此巴洛克式的？正如我所说，GPL v3 是较早时期的产物，彼时 FOSS 许可协议被视为项目治理的主要工具。（现在我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如组织非营利组织，围绕项目决策制定规则，行为准则和贡献者协议。）

在其起草过程中，GPL v3 是对 FOSS 许可协议可以作为雄心勃勃的私人监管手段持乐观态度的最高点。对于 GPL v2 来说已经是这样了，但是 GPL v3 通过详细解决一些新的政策问题——软件专利、反规避法律、设备锁定等方式来解决问题。这必然会使 GPL v3 许可协议比 GPL v2 更长、更复杂，因为 FSF 和 SFLC 在第一份 GPL v3 基本原理文件中满怀抱歉地提到了这一点。

但是，起草 GPL v3 过程中的其他一些因素无意中导致许可协议的复杂性增长。代表供应商和商业用户利益的律师从法律和商业角度提供了有用的改进建议，但这些通常采取让措辞简单的条款变成更冗长的形式，在明晰性方面可以说没有明确的改善。对技术社区反馈（通常是识别许可条款的漏洞）的回应也有类似的效果。

GPL v3 起草人也因短期政治危机（2006 年有争议的微软/ Novell 交易）纠缠在一起，导致许可协议的专利部分永久性地增加了新的和不寻常的条件，这在 2007 年之后是毫无用处的, 除了使有良心的专利持有商更难遵守许可证。当然，GPL v3 中的一些复杂性仅仅是为了使合规更容易（特别是对于社区项目开发人员）或者编写 FSF 的解释实践。最后，人们可以对 GPL v3 中使用的语言风格提出质疑，其中大部分语言都具有传统软件许可法律的顽皮模仿或嘲弄；在许多情况下，一种更简单、直接的措辞形式是一种改进。

GPL v3 的复杂性以及在许可协议起草中倾向于简练和简洁的趋势以及明智的许可政策目标，意味着 GPL v3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年所惊奇和高兴地看到的那样，MPL 2.0 改编了 GPL v3 的两个部分：GPL v3 终止条款中的 30 天补救和 60 天休眠文本，并保证升级到更高版本许可协议的下游对上游许可人没有新的义务。

GPL v3 补救文本已经产生了重大影响，特别是在过去一年中。随着 FSF 的支持， 软件自由保护组织 （ Software Freedom Conservancy ） 颁布了《 面向社区的 GPL 执行原则 （ Principles of Community-Oriented GPL Enforcement ） 》，该原则要求将 GPL v3 补救机会扩展到 GPL v2 违规行为，Linux 基金会技术顾问委员会发布了一份声明，得到了一百多个 Linux 内核开发人员支持，其中包含了 GPL v3 的补救文本。接下来是以红帽公司为首的一系列企业承诺，将 GPL v3 补救条款扩展到 GPL v2 和 LGPL v2.x 违规，这是一项建议个人开源开发者做出同样承诺的活动。红帽公司的一项声明宣布，从此以后其主导的 GPL v2 和 LGPL v2.x 项目将在项目存储库中直接使用承诺文本。我在最近的博客文章中讨论了这些发展。

关注 GPL v3 的一个持久贡献是改变了对广泛使用的 FOSS 许可协议修订方式的期待。在没有社区评论的参与，也没有努力与主要利益相关者进行磋商的情况下，这些许可协议不能完全进行私下修改。MPL 2.0 以及最近的 EPL 2.0 的起草过程反映了这一新规范。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

有些人可能会认为 macOS 和 Linux 内核之间存在相似之处，因为它们可以处理类似的命令和类似的软件。有些人甚至认为苹果公司的 macOS 是基于 Linux 的。事实上是，两个内核有着截然不同的历史和特征。今天，我们来看看 macOS 和 Linux 的内核之间的区别。

macOS 内核的历史

我们将从 macOS 内核的历史开始。1985 年，由于与首席执行官 John Sculley 和董事会不和， 史蒂夫·乔布斯 Steve Jobs 离开了苹果公司。然后，他成立了一家名为 NeXT 的新电脑公司。乔布斯希望将一款（带有新操作系统的）新计算机快速推向市场。为了节省时间，NeXT 团队使用了卡耐基梅隆大学的 Mach 内核) 和部分 BSD 代码库来创建 NeXTSTEP 操作系统。

NeXT 从来没有取得过财务上的成功，部分归因于乔布斯花钱的习惯，就像他还在苹果公司一样。与此同时，苹果公司曾多次试图更新其操作系统，甚至与 IBM 合作，但从未成功。1997年，苹果公司以 4.29 亿美元收购了 NeXT。作为交易的一部分，史蒂夫·乔布斯回到了苹果公司，同时 NeXTSTEP 成为了 macOS 和 iOS 的基础。

Linux 内核的历史

与 macOS 内核不同，Linux 的创建并非源于商业尝试。相反，它是由芬兰计算机科学专业学生 林纳斯·托瓦兹 Linus Torvalds 于 1991 年创建的。最初，内核是按照林纳斯自己的计算机的规格编写的，因为他想利用其新的 80386 处理器（的特性）。林纳斯于 1991 年 8 月在 Usenet 上发布了他的新内核代码。很快，他就收到了来自世界各地的代码和功能建议。次年，Orest Zborowski 将 X Window 系统移植到 Linux，使其能够支持图形用户界面。

在过去的 27 年中，Linux 已经慢慢成长并增加了不少功能。这不再是一个学生的小型项目。现在它运行在世界上大多数的计算设备和超级计算机上。不错！

macOS 内核的特性

macOS 内核被官方称为 XNU。这个首字母缩写词代表“XNU is Not Unix”。根据 苹果公司的 Github 页面，XNU 是“将卡耐基梅隆大学开发的 Mach 内核和 FreeBSD 组件整合而成的混合内核，加上用于编写驱动程序的 C++ API”。代码的 BSD 子系统部分“在微内核系统中通常实现为用户空间的服务”。Mach 部分负责底层工作，例如多任务、内存保护、虚拟内存管理、内核调试支持和控制台 I/O。

Linux 内核的特性

虽然 macOS 内核结合了微内核（Mach）和宏内核（BSD）的特性，但 Linux 只是一个宏内核。宏内核负责管理 CPU、内存、进程间通信、设备驱动程序、文件系统和系统服务调用（ LCTT 译注：原文为 system server calls，但结合 Linux 内核的构成，译者认为这里翻译成系统服务调用更合适，即 system service calls）。

用一句话总结 Linux 和 Mac 的区别

macOS 内核（XNU）比 Linux 历史更悠久，并且基于两个更古老一些的代码库的结合；另一方面，Linux 新一些，是从头开始编写的，并且在更多设备上使用。

如果您发现这篇文章很有趣，请花一点时间在社交媒体，黑客新闻或 Reddit 上分享。

via: https://itsfoss.com/mac-linux-difference/

作者：John Paul 选题：lujun9972 译者：stephenxs 校对：wxy

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

找出 Human Connection 是如何将透明度和社区放在首位的。

如今，开源软件具有深远的意义，在推动数字经济创新方面发挥着关键作用。世界正在快速彻底地改变。世界各地的人们需要一个专门的、中立的、透明的在线平台来迎接我们这个时代的挑战。

开放的原则也许是让我们达成这一目标的方法。如果我们用开放的思维方式将数字创新与社会创新结合在一起，会发生什么？

这个问题是我们在 Human Connection 工作的核心，这是一个具有前瞻性的，以德国为基础的知识和行动网络，其使命是创建一个服务于全球的真正的社交网络。我们受到这样一种观念为指引，即人类天生慷慨而富有同情心，并且他们在慈善行为上茁壮成长。但我们还没有看到一个完全支持我们的自然趋势，与乐于助人和合作以促进共同利益的社交网络。Human Connection 渴望成为让每个人都成为积极变革者的平台。

为了实现一个以解决方案为导向的平台的梦想，让人们通过与慈善机构、社区团体和社会变革活动人士的接触，围绕社会公益事业采取行动，Human Connection 将开放的价值观作为社会创新的载体。

以下是有关它如何工作的。

首先是透明

透明是 Human Connection 的指导原则之一。Human Connection 邀请世界各地的程序员通过在 Github 上提交他们的源代码共同开发平台的源代码（JavaScript、Vue、nuxt），并通过贡献代码或编程附加功能来支持真正的社交网络。

但我们对透明的承诺超出了我们的发展实践。事实上，当涉及到建立一种新的社交网络，促进那些让世界变得更好的人之间的真正联系和互动，分享源代码只是迈向透明的一步。

为促进公开对话，Human Connection 团队举行定期在线公开会议。我们在这里回答问题，鼓励建议并对潜在的问题作出回应。我们的 Meet The Team 活动也会记录下来，并在事后向公众开放。通过对我们的流程，源代码和财务状况完全透明，我们可以保护自己免受批评或其他潜在的不利影响。

对透明的承诺意味着，所有在 Human Connection 上公开分享的用户贡献者将在 Creative Commons 许可下发布，最终作为数据包下载。通过让大众知识变得可用，特别是以一种分散的方式，我们创造了一个多元化社会的机会。

有一个问题指导我们所有的组织决策：“它是否服务于人民和更大的利益？”我们用 联合国宪章 UN Charter 和“ 世界人权宣言 Universal Declaration of Human Rights ”作为我们价值体系的基础。随着我们的规模越来越大，尤其是即将推出的公测版，我们必须对此任务负责。我甚至愿意邀请 Chaos Computer Club （LCTT 译注：这是欧洲最大的黑客联盟）或其他黑客俱乐部通过随机检查我们的平台来验证我们的代码和行为的完整性。

一个合作的社会

以一种以社区为中心的协作方法来编写 Human Connection 平台是超越社交网络实际应用理念的基础。我们的团队是通过找到问题的答案来驱动：“是什么让一个社交网络真正地社会化？”

一个抛弃了以利润为导向的算法、为最终用户而不是广告商服务的网络，只能通过转向对等生产和协作的过程而繁荣起来。例如，像 Code Alliance 和 Code for America 这样的组织已经证明了如何在一个开源环境中创造技术，造福人类并变革现状。社区驱动的项目，如基于地图的报告平台 FixMyStreet，或者为 Humanitarian OpenStreetMap 而建立的 Tasking Manager，已经将众包作为推动其使用的一种方式。

我们建立 Human Connection 的方法从一开始就是合作。为了收集关于必要功能和真正社交网络的目的的初步数据，我们与巴黎 索邦大学 University Sorbonne 的 国家东方语言与文明研究所 National Institute for Oriental Languages and Civilizations （INALCO）和德国 斯图加特媒体大学 Stuttgart Media University 合作。这两个项目的研究结果都被纳入了 Human Connection 的早期开发。多亏了这项研究，用户将拥有一套全新的功能，让他们可以控制自己看到的内容以及他们如何与他人的互动。由于早期的支持者被邀请到网络的 alpha 版本，他们可以体验到第一个可用的值得注意的功能。这里有一些：

• 将信息与行动联系起来是我们研究会议的一个重要主题。当前的社交网络让用户处于信息阶段。这两所大学的学生团体都认为，需要一个以行动为导向的组件，以满足人类共同解决问题的本能。所以我们在平台上构建了一个“Can Do”功能。这是一个人在阅读了某个话题后可以采取行动的一种方式。“Can Do” 是用户建议的活动，在“ 采取行动 Take Action ”领域，每个人都可以实现。
• “Versus” 功能是另一个成果。在传统社交网络仅限于评论功能的地方，我们的学生团体认为需要采用更加结构化且有用的方式进行讨论和争论。“Versus” 是对公共帖子的反驳，它是单独显示的，并提供了一个机会来突出围绕某个问题的不同意见。
• 今天的社交网络并没有提供很多过滤内容的选项。研究表明，情绪过滤选项可以帮助我们根据日常情绪驾驭社交空间，并可能通过在我们希望仅看到令人振奋的内容的那一天时，不显示悲伤或难过的帖子来潜在地保护我们的情绪健康。

Human Connection 邀请改革者合作开发一个网络，有可能动员世界各地的个人和团体将负面新闻变成 “Can Do”，并与慈善机构和非营利组织一起参与社会创新项目。

订阅我们的每周时事通讯以了解有关开放组织的更多信息。

via: https://opensource.com/open-organization/18/3/open-social-human-connection

作者：Dennis Hack 译者：MjSeven 校对：wxy

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

以及 3 个有趣的 RFC。

阅读源码是开源软件的重要组成部分。这意味着用户可以查看代码并了解做了什么。

但“阅读源码”并不仅适用于代码。理解代码实现的标准同样重要。这些标准编写在由 互联网工程任务组 Internet Engineering Task Force （IETF）发布的称为“ 意见征集 Requests for Comment ”（RFC）的文档中。多年来已经发布了数以千计的 RFC，因此我们收集了一些我们的贡献者认为必读的内容。

6 个必读的 RFC

RFC 2119 - 在 RFC 中用于指示需求级别的关键字

这是一个快速阅读，但它对了解其它 RFC 非常重要。 RFC 2119 定义了后续 RFC 中使用的需求级别。 “MAY” 究竟意味着什么？如果标准说 “SHOULD”，你真的必须这样做吗？通过为需求提供明确定义的分类，RFC 2119 有助于避免歧义。

RFC 3339 - 互联网上的日期和时间：时间戳

时间是全世界程序员的祸根。 RFC 3339 定义了如何格式化时间戳。基于 ISO 8601 标准，3339 为我们提供了一种表达时间的常用方法。例如，像星期几这样的冗余信息不应该包含在存储的时间戳中，因为它很容易计算。

RFC 1918 - 私有互联网的地址分配

有属于每个人的互联网，也有只属于你的互联网。私有网络一直在使用，RFC 1918 定义了这些网络。当然，你可以在路由器上设置在内部使用公网地址，但这是一个坏主意。或者，你可以将未使用的公共 IP 地址视为内部网络。在任何一种情况下都表明你从未阅读过 RFC 1918。

RFC 1912 - 常见的 DNS 操作和配置错误

一切都是 #@%@ 的 DNS 问题，对吧？ RFC 1912 列出了管理员在试图保持互联网运行时所犯的错误。虽然它是在 1996 年发布的，但 DNS（以及人们犯的错误）并没有真正改变这么多。为了理解我们为什么首先需要 DNS，如今我们再来看看 RFC 289 - 我们希望正式的主机列表是什么样子的 就知道了。

RFC 2822 — 互联网邮件格式

想想你知道什么是有效的电子邮件地址么？如果你知道有多少个站点不接受我邮件地址中 “+” 的话，你就知道你知道不知道了。 RFC 2822 定义了有效的电子邮件地址。它还详细介绍了电子邮件的其余部分。

RFC 7231 - 超文本传输​​协议（HTTP/1.1）：语义和内容

想想看，几乎我们在网上做的一切都依赖于 HTTP。 RFC 7231 是该协议的最新更新。它有超过 100 页，定义了方法、请求头和状态代码。

3 个应该阅读的 RFC

好吧，并非每个 RFC 都是严肃的。

RFC 1149 - 在禽类载体上传输 IP 数据报的标准

网络以多种不同方式传递数据包。 RFC 1149 描述了鸽子载体的使用。当我距离州际高速公路一英里以外时，它们的可靠性不会低于我的移动提供商。

RFC 2324 — 超文本咖啡壶控制协议（HTCPCP/1.0）

咖啡对于完成工作非常重要，当然，我们需要一个用于管理咖啡壶的程序化界面。 RFC 2324 定义了一个用于与咖啡壶交互的协议，并添加了 HTTP 418（“我是一个茶壶”）。

RFC 69 — M.I.T.的分发列表更改

RFC 69 是否是第一个误导取消订阅请求的发布示例？

你必须阅读的 RFC 是什么（无论它们是否严肃）？在评论中分享你的列表。

via: https://opensource.com/article/18/7/requests-for-comments-to-know

作者：Ben Cotton 选题：lujun9972 译者：geekpi 校对：wxy

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

如何在崩溃的局面中集中精力寻找解决方案。

如果你在 IT 领域工作，你知道事情永远不会像你想象的那样完好。在某些时候，你会遇到错误或出现问题，你最终必须解决问题。这就是系统管理员的工作。

作为人类，我们都会犯错误。我们不是已经犯错，就是即将犯错。结果，我们最终还必须解决自己的错误。总是这样。我们都会失误、敲错字母或犯错。

作为一名年轻的系统管理员，我艰难地学到了这一课。我犯了一个大错。但是多亏了上级的指导，我学会了不去纠缠于我的错误，而是制定一个“错误策略”来做正确的事情。从错误中吸取教训。克服它，继续前进。

我的第一份工作是一家小公司的 Unix 系统管理员。真的，我是一名生嫩的系统管理员，但我大部分时间都独自工作。我们是一个小型 IT 团队，只有我们三个人。我是 20 或 30 台 Unix 工作站和服务器的唯一系统管理员。另外两个支持 Windows 服务器和桌面。

任何阅读这篇文章的系统管理员都不会对此感到意外，作为一个不成熟的初级系统管理员，我最终在错误的目录中运行了 rm 命令——作为 root 用户。我以为我正在为我们的某个程序删除一些陈旧的缓存文件。相反，我错误地清除了 /etc 目录中的所有文件。糟糕。

我意识到犯了错误是看到了一条错误消息，“rm 无法删除某些子目录”。但缓存目录应该只包含文件！我立即停止了 rm 命令，看看我做了什么。然后我惊慌失措。一下子，无数个想法涌入了我的脑中。我刚刚销毁了一台重要的服务器吗？系统会怎么样？我会被解雇吗？

幸运的是，我运行的是 rm * 而不是 rm -rf *，因此我只删除了文件。子目录仍在那里。但这并没有让我感觉更好。

我立刻去找我的主管告诉她我做了什么。她看到我对自己的错误感到愚蠢，但这是我犯的。尽管紧迫，她花了几分钟时间跟我做了一些指导。 她说：“你不是第一个这样做的人，在你这种情况下，别人会怎么做？”这帮助我平静下来并专注。我开始更少考虑我刚刚做的愚蠢事情，而更多地考虑我接下来要做的事情。

我做了一个简单的策略：不要重启服务器。使用相同的系统作为模板，并重建 /etc 目录。

制定了行动计划后，剩下的就很容易了。只需运行正确的命令即可从另一台服务器复制 /etc 文件并编辑配置，使其与系统匹配。多亏了我对所有东西都做记录的习惯，我使用已有的文档进行最后的调整。我避免了完全恢复服务器，这意味着一个巨大的宕机事件。

可以肯定的是，我从这个错误中吸取了教训。在接下来作为系统管理员的日子中，我总是在运行任何命令之前确认我所在的目录。

我还学习了构建“错误策略”的价值。当事情出错时，恐慌并思考接下来可能发生的所有坏事是很自然的。这是人性。但是制定一个“错误策略”可以帮助我不再担心出了什么问题，而是专注于让事情变得更好。我仍然会想一下，但是知道我接下来的步骤可以让我“克服它”。

via: https://opensource.com/article/18/7/my-first-sysadmin-mistake

作者：Jim Hall 选题：lujun9972 译者：geekpi 校对：wxy

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

从比特币到下一代区块链。

当开源项目开发下一个新版本时，用后缀 “-ng” 表示 “下一代”的情况并不鲜见。幸运的是，到目前为止，快速演进的区块链成功地避开了这个命名陷阱。但是在这个开源生态系统的演进过程中，改变是不断发生的，而好的创意以典型的开源方式在许多不同的项目中被采用、交融和演进。

在本文中，我将审视不同代次的区块链，并且看一看在处理这个生态系统遇到的问题时出现什么创意。当然，任何对生态系统进行分类的尝试都有其局限性的 —— 和不同意见者的 —— 但是这也将为混乱的区块链项目提供了一个粗略的指南。

始作俑者：比特币

第一代的区块链起源于 比特币 Bitcoin 区块链，这是以去中心化、点对点加密货币为基础的 总帐 ledger ，它从 Slashdot 网站上的杂谈变成了一个主流话题。

这个区块链是一个分布式总帐，它对所有用户的 交易 transaction 保持跟踪，以避免他们 双重支付 double-spending （双花）货币（在历史上，这个任务是委托给第三方—— 银行 ——来做的）。为防范攻击者在系统上捣乱，总帐被复制到每个参与到比特币网络的计算机上，并且每次只允许一台计算机去更新总帐。为决定哪台计算机能够获得更新总帐的权力，系统安排在比特币网络上的计算机之间每 10 分钟进行一场竞赛，这将消耗它们的（许多）能源才能参与竞赛。赢家将获得将前 10 分钟发生的交易写入到总帐（区块链中的“区块”）的权力，并且为赢家写入区块链的工作给予一些比特币奖励。这种方式被称为 工作量证明 proof of work （PoW）共识机制。

这就是区块链最有趣的地方。比特币以开源项目的方式发布于 2009 年 1 月 。在 2010 年，由于意识到这些元素中的许多是可以调整的，围绕比特币聚集起了一个社区 —— bitcointalk 论坛，来开始各种实验。

起初，看到的比特币区块链是一个分布式数据库的形式， Namecoin 项目出现后，建议去保存任意数据到它的事务数据库中。如果区块链能够记录金钱的转移，那么它也应该能够记录其它资产的转移，比如域名。这正是 Namecoin 的主要使用场景，它上线于 2011 年 4 月 —— 也就是比特币出现两年后。

Namecoin 调整的地方是区块链的内容， 莱特币 Litecoin 调整的是两个技术部分：一是将两个区块的时间间隔从 10 分钟减少到 2.5 分钟，二是改变了竞赛方式（用 scrypt 来替换了 SHA-256 安全哈希算法）。这是能够做到的，因为比特币是以开源软件的方式来发布的，而莱特币本质上与比特币在其它部分是完全相同的。莱特币是修改了比特币共识机制的第一个分叉，这也为其它的更多“币”铺平了道路。

沿着这条道路，基于比特币代码库的各种变种越来越多。其中一些扩展了比特币的用途，比如 Zerocash 协议，它专注于提供交易的匿名性和可替换性，但它最终分拆为它自己的货币 —— Zcash。

虽然 Zcash 带来了它自己的创新，使用了最近被称为“ 零知识证明 zero-knowledge proof ”的加密技术，但它维持着与大多数主要的比特币代码库的兼容性，这意味着它能够从上游的比特币创新中获益。

另外的项目 —— CryptoNote，它萌芽于相同的社区，但是并没有使用相同的代码，它以比特币为背景来构建的，但又与之不同。它发布于 2012 年 12 月，由于它的出现，导致了几种加密货币的诞生，最著名的 门罗币 Monero （2014）就是其中之一。门罗币与 Zcash 使用了不同的方法，但解决了相同的问题：隐私性和可替换性。

就像在开源世界中经常出现的案例一样，做同样的工作有不止一个的工具可用。

下一代：“Blockchain-ng”

但是，到目前为止，所有的这些变体只是改进加密货币或者扩展它们去支持其它类型的事务。因此，这就引出了第二代区块链。

一旦社区开始去修改区块链的用法和调整技术部分时，对于一些想去扩展和重新思考它们未来的人来说，这种调整花费不了多长时间的。比特币的长期追随者 —— Vitalik Buterin 在 2013 年底建议，区域链的事务应该能够表示一个状态机的状态变化，将区域链视为能够运行应用程序（“ 智能合约 smart contract ”）的分布式计算机。这个项目 —— 以太坊 Ethereum ，上线于 2015 年 4 月。它在运行分布式应用程序方面取得了巨大的成功，它的一些非常流行的分布式应用程序（ 加密猫 CryptoKitties ）甚至导致以太坊区块链变慢。

这证明了目前的区块链存在一个很大的局限性：速度和容量。（速度通常用每秒事务数来测量，简称 TPS）有几个提议都建议去解决这个速度问题，从 分片 sharding 到 侧链 sidechain ，以及一个被称为“ 第二层 second-layer ”的解决方案。这里需要更多的创新。

随着“智能合约”这个词开始流行起来，并且用已经被证实仍然很慢的技术去运行它们，那么就需要实现其它的思路： 许可区块链 Permissioned blockchain 。到目前为止，我们所介绍的所有区块链网络有两个没有明说的特征：一是它们是公开的（任何人都可以看到它们的功能），二是它们不需要许可（任何人都可以加入它们）。这两个部分是运行一个分布式的、非基于第三方的货币应该具有的和必需具有的条件。

随着区块链被认为出现与加密货币越来越明显的分离趋势，开始去考虑一些隐私、许可场景是很有意义的。一个有业务关系但不需要彼此完全信任的财团类型的参与者，能够从这些区块链类型中获益 —— 比如，物流链上的参与者，定期进行双边结算或者使用一个清算中心的金融、保险、或医疗保健机构。

一旦你将设置从“任何人都可以加入”变为“仅邀请者方可加入”，进一步对区块链构建区块的方式进行改变和调整将变得可能，那么对一些人来说，结果将变得非常有趣。

首先，设计用来保护网络不受恶意或者垃圾参与者的影响的工作量证明（PoW）可以被替换为更简单的和更少资源消耗的一些东西，比如，基于 Raft) 的共识协议。在更高级别的安全性和更快的速度之间进行权衡，采用更简单的共识算法。对于更多群体来说这样更理想，因为他们可以用基于加密技术的担保来取代其它的基于法律关系的担保，例如为避免由于竞争而产生的大量能源消耗，而工作量证明就是这种情况。另外一个创新的地方是，使用 股权证明 Proof of Stake （PoS），它是公共网络共识机制的一个重量级的竞争者。它将可能像许可链网络一样找到它自己的实现方式。

有几个项目可以让创建许可区块链变得更简单，包括 Quorum （以太坊的一个分叉）和 Hyperledger 的 Fabric 和 Sawtooth，这是基于新代码的两个开源项目。

许可区块链可以避免公共的、非许可方式的区块链中某些错综复杂的问题，但是它自己也存在一些问题。正确地管理参与者是其中的一个问题：谁可以加入？如何辨别他们？如何将他们从网络上移除？网络上的一个实体是否去管理一个中央公共密钥基础设施（PKI）?

区块链的开放本质

到目前为止的所有案例中，有一件事情是很明确的：使用一个区块链的目标是去提升网络中的参与者和它产生的数据的信任水平，理想情况下，不需要做进一步的工作即可足以使用它。

只有为这个网络提供动力的软件是自由和开源的，才能达到这种信任水平。即便是一个正确的、专用的、分布式区块链，它的本质仍然是运行着相同的第三方代码的私有代理的集合。从本质上来说，区块链的源代码必须是开源的，但仅是开源还不够。随着生态系统持续成长，这既是最低限度的担保也是进一步创新的源头。

最后，值得一提的是，虽然区块链的开放本质被认为是创新和变化的源头，它也被认为是一种治理形式：代码治理，用户期望运行的任何一个特定版本，都应该包含他们认为的整个网络应该包含的功能和方法。在这方面，需要说明的一点是，一些区块链的开放本质正在“变味”。但是这一问题正在解决。

第三和第四代：治理

接下来，我正在考虑第三代和第四代区块链：区块链将内置治理工具，并且项目将去解决棘手的大量不同区块链之间互连互通的问题，以便于它们之间可以交换信息和价值。

关于作者

axel simon： 长期的自由及开源软件爱好者，就职于 Red Hat ，关注安全和区块链技术，以及分布式系统和协议。致力于保护互联网及其成就（知识分享、信息访问、去中心化和网络中立）。

via: https://opensource.com/article/18/6/blockchain-guide-next-generation

作者：Axel Simon 选题：lujun9972 译者：qhwdw 校对：wxy

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