Linux 内核有了新的 行为准则 Code of Conduct (CoC)。但在这条行为准则被签署以及发布仅仅 30 分钟之后，Linus Torvalds 就暂时离开了 Linux 内核的开发工作。因为新行为准则的作者那富有争议的过去，现在这件事成为了热点话题。许多人都对这新的行为准则表示不满。

如果你还不了解这件事，请参阅 Linus Torvalds 对于自己之前的不良态度致歉并开始休假，以改善自己的行为态度

Linux 内核开发遵守的新行为准则

Linux 内核开发者并不是以前没有需要遵守的行为准则，但是之前的 冲突准则 code of conflict 现在被替换成了以“给内核开发社区营造更加热情，更方便他人参与的氛围”为目的的行为准则。

“为营造一个开放并且热情的社区环境，我们，贡献者与维护者，许诺让每一个参与进我们项目和社区的人享受一个没有骚扰的体验。无关于他们的年纪、体型、身体残疾、种族、性别、性别认知与表达、社会经验、教育水平、社会或者经济地位、国籍、外表、人种、信仰、性认同和性取向。”

你可以在这里阅读整篇行为准则：Linux 行为准则。

Linus Torvalds 是被迫道歉并且休假的吗？

这个新的行为准则由 Linus Torvalds 和 Greg Kroah-Hartman (仅次于 Torvalds 的二把手）签发。来自 Intel 的 Dan Williams 和来自 Facebook 的 Chris Mason 也是该准则的签署者之一。

如果我正确地解读了时间线，在签署这个行为准则的半小时之后，Torvalds 发送了一封邮件，对自己之前的不良态度致歉。他同时宣布会进行休假，以改善自己的行为态度。

不过有些人开始阅读这封邮件的话外之音，并对如下文字报以特别关注：

在这周，许多社区成员批评了我之前种种不解人意的行为。我以前在邮件里进行的，对他人轻率的批评是非专业以及不必要的。这种情况在我将事情放在私人渠道处理的时候尤为严重。我理解这件事情的严重性，这是不好的行为，我对此感到十分抱歉。

他是否是因为新的行为准则被强迫做出道歉，并且决定休假，可以通过这几行来判断。这也可以让我们采取一些措施，避免 Torvalds 被新的行为准则伤害。

有关贡献者盟约作者 Coraline Ada Ehmke 的争议

Linux 的行为准则基于 贡献者盟约 Contributor Convenant 1.4 版本。贡献者盟约被上百个开源项目所接纳，包括 Eclipse、Angular、Ruby、Kubernetes 等项目。

贡献者盟约由 Coraline Ada Ehmke 创作，她是一个软件工程师，开源支持者，以及 LGBT 活动家。她对于促进开源世界的多样性做了显著的贡献。

Coraline 对于精英主义的反对立场同样十分鲜明。 精英主义 meritocracy 这个词语源自拉丁文，本意为系统内的进步取决于“精英”，例如智力水平、取得的证书以及教育程度。但类似 Coraline 的活动家们认为唯才是用是个糟糕的体系，因为它只是通过人的智力产出来度量一个人，而并不重视他们的人性。

图片来源：推特用户@nickmon1112

Linus Torvalds 不止一次地说到，他在意的只是代码而并非写代码的人。所以很明显，这忤逆了 Coraline 有关唯才是用体系的观点。

具体来说，Coraline 那被人关注饱受争议的过去，是一个关于 Opal 项目贡献者的事件。那是一个发生在推特上的讨论，Elia，来自意大利的 Opal 项目核心开发者说“（那些变性人）不接受现实才是问题所在。”

Coraline 并没有参加讨论，也不是 Opal 项目的贡献者。不过作为 LGBT 活动家，她以 Elia 发表“冒犯变性人群体的发言”为由，要求他退出 Opal 项目。 Coraline 和她的支持者——他们给这个项目做过贡献，通过在 GitHub 仓库平台上冗长且激烈的争论，试图将 Elia——此项目的核心开发者移出项目。

虽然 Elia 并没有离开这个项目，不过 Opal 项目的维护者同意实行一个行为准则。这个行为准则就是 Coraline 不停向维护者们宣扬的，她那著名的贡献者盟约。

不过故事到这里并没有结束。贡献者盟约稍后被更改，加入了一些针对 Elia 的新条款。这些新条款将行为准则的管束范围扩展到公共领域。不过这些更改稍后被维护者们标记为恶意篡改。最后 Opal 项目摆脱了贡献者盟约，并用自己的行为准则取而代之。

这个例子非常好的说明了，某些被冒犯的少数人群——哪怕他们并没有给这个项目做过一点贡献，是怎样试图去驱逐这个项目的核心开发者的。

人们对于 Linux 新的行为准则的以及 Torvalds 道歉的反映。

Linux 行为准则以及 Torvalds 的道歉一发布，社交媒体与论坛上就开始盛传种种谣言与推测。虽然很多人对新的行为准则感到满意，但仍有些人认为这是 SJW 尝试渗透 Linux 社区的阴谋。（LCTT 译注：SJW——Social Justice Warrior 所谓“为社会正义而战的人”。）

Caroline 发布的一个富有嘲讽意味的推特让争论愈发激烈。

我迫不及待期待看到大批的人离开 Linux 社区的场景了。现在它已经被 SJW 的成员渗透了。哈哈哈哈。
pic.twitter.com/eFeY6r4ENv

— Coraline Ada Ehmke (@CoralineAda) 9 月 16 日, 2018

随着对于 Linux 行为准则的争论持续发酵，Carolaine 公开宣称贡献者盟约是一份政治文件。这并不能被那些试图将政治因素排除在开源项目之外的人所接收。

有些人说贡献者盟约是一份政治文件，他们说的没错。

— Coraline Ada Ehmke (@CoralineAda) 9 月 16 日, 2018

Nick Monroe，一位自由记者，宣称 Linux 行为准则远没有表面上看上去那么简单。为了证明自己的观点，他挖掘出了 Coraline 的过去。如果您愿意，可以阅读以下材料。

好啦，你们已经看到过几千次了。这是一个行为准则。

它包含了社会认同的正义行为。https://t.co/KuQqeriYeJ

不过它或许没有看上去来的那么简单。pic.twitter.com/8NUL2K1gu2

— Nick Monroe (@nickmon1112) 9 月 17 日, 2018

Nick 并不是唯一一个反对 Linux 新的行为准则的人。SJW 的参与引发了更多的阴谋论猜测。

我猜今天关于 Linux 的大新闻就是现在，Linux 内核被一个 “ 后精英政治 post meritocracy ” 世界观下的行为准则给掌控了。

这个行为准则的宗旨看起来不错。不过在实际操作中，它们通常被当作 SJW 分子攻击他们不喜之人的工具。况且，很多人都被 SJW 分子所厌恶。

— Mark Kern (@Grummz) September 17, 2018

虽然很多人对于 Torvalds 的道歉感到欣慰，仍有一些人在责备 Torvalds 的态度。

我是不是唯一一个认为 Linus Torvalds 这十几年来的态度恰好就是 Linux 和开源“社区”特有的那种，居高临下，粗鲁，鄙视一切新人的行为作风？反正作为一个新用户，我从来没有在 Linux 社区里感受到自己是受欢迎的。

— Jonathan Frappier (@jfrappier) 9 月 17 日, 2018

还有些人并不能接受 Torvalds 的道歉。

哦快看啊，一个喜欢辱骂他人的开源软件维护者，在十几年的恶行之后，终于承认了他的行为可能是不正确的。

我关注的那些人因为这件事都惊讶到平地摔，并且决定给他（Linus Torvalds）寄饼干来庆祝。

— Kelly Ellis (@justkelly\_ok) 9 月 17 日, 2018

Torvalds 的道歉引起了广泛关注 ;)

我现在要在我的个人档案里写上”我不知是否该原谅 Linus Torvalds“ 吗？

— Verónica. (@maria\_fibonacci) 9 月 17 日, 2018

不继续开玩笑了。有关 Linus 道歉的关注是由 Sharp 挑起的。她因为“恶劣的社区环境”于 2015 年退出了 Linux 内核的开发。（LCTT 译注，Sarah Sharp 现在改名为“Sage Sharp”，并要求别人称其为“them”而不是“she”或“he”。）

现在我们要面对的问题是，这个成就了 Linus，给予他肆意辱骂特权的社区能否迎来改变。不仅仅是 Linus 个人，Linux 内核开发社区也急需改变。https://t.co/EG5KO43416

— Sage Sharp (@sagesharp) 9 月 17 日, 2018

你对于 Linux 行为准则怎么看？

如果你问我的观点，我认为目前社区的确是需要一个行为准则。它能指导人们尊重他人，不因为他人的种族、宗教信仰、国籍、政治观点（左派或者右派）而歧视，营造出一个积极向上的社区氛围。

对于这个事件，你怎么看？你认为这个行为准则能够帮助 Linux 内核的开发，或者说因为 SJW 成员们的加入，情况会变得更糟？

在 FOSS 里我们没有行为准则，不过我们都会持着文明友好的态度讨论问题。

via: https://itsfoss.com/linux-code-of-conduct/

作者：Abhishek Prakash 选题：lujun9972 译者：thecyanbird 校对：wxy

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

应用 Align 中，用户主页的控制面板

从构思到部署应用程序的简单分步指南

我在 Grace Hopper Program 为期三个月的编码训练营即将结束，实际上这篇文章的标题有些纰漏 —— 现在我已经构建了 三个 全栈应用：从零开始的电子商店、我个人的 私人黑客马拉松项目，还有这个“三周的结业项目”。这个项目是迄今为止强度最大的 —— 我和另外两名队友共同花费三周的时光 —— 而它也是我在训练营中最引以为豪的成就。这是我目前所构建和涉及的第一款稳定且复杂的应用。

如大多数开发者所知，即使你“知道怎么编写代码”，但真正要制作第一款全栈的应用却是非常困难的。JavaScript 生态系统出奇的大：有包管理器、模块、构建工具、转译器、数据库、库文件，还要对上述所有东西进行选择，难怪如此多的编程新手除了 Codecademy 的教程外，做不了任何东西。这就是为什么我想让你体验这个决策的分布教程，跟着我们队伍的脚印，构建可用的应用。

首先，简单的说两句。Align 是一个 web 应用，它使用直观的时间线界面帮助用户管理时间、设定长期目标。我们的技术栈有：用于后端服务的 Firebase 和用于前端的 React。我和我的队友在这个短视频中解释的更详细。

从第 1 天（我们组建团队的那天）开始，直到最终应用的完成，我们是如何做的？这里是我们采取的步骤纲要：

第 1 步：构思

第一步是弄清楚我们到底要构建什么东西。过去我在 IBM 中当咨询师的时候，我和合作组长一同带领着构思工作组。从那之后，我一直建议小组使用经典的头脑风暴策略，在会议中我们能够提出尽可能多的想法 —— 即使是 “愚蠢的想法” —— 这样每个人的大脑都在思考，没有人因顾虑而不敢发表意见。

在产生了好几个关于应用的想法时，我们把这些想法分类记录下来，以便更好的理解我们大家都感兴趣的主题。在我们这个小组中，我们看到实现想法的清晰趋势，需要自我改进、设定目标、情怀，还有个人发展。我们最后从中决定了具体的想法：做一个用于设置和管理长期目标的控制面板，有保存记忆的元素，可以根据时间将数据可视化。

从此，我们创作出了一系列用户故事（从一个终端用户的视角，对我们想要拥有的功能进行描述），阐明我们到底想要应用实现什么功能。

第 2 步：UX/UI 示意图

接下来，在一块白板上，我们画出了想象中应用的基本视图。结合了用户故事，以便理解在应用基本框架中这些视图将会如何工作。

这些骨架确保我们意见统一，提供了可预见的蓝图，让我们向着计划的方向努力。

第 3 步：选好数据结构和数据库类型

到了设计数据结构的时候。基于我们的示意图和用户故事，我们在 Google doc 中制作了一个清单，它包含我们将会需要的模型和每个模型应该包含的属性。我们知道需要 “目标（goal）” 模型、“用户（user）”模型、“里程碑（milestone）”模型、“记录（checkin）”模型还有最后的“资源（resource）”模型和“上传（upload）”模型，

最初的数据模型结构

在正式确定好这些模型后，我们需要选择某种 类型 的数据库：“关系型的”还是“非关系型的”（也就是“SQL”还是“NoSQL”）。由于基于表的 SQL 数据库需要预定义的格式，而基于文档的 NoSQL 数据库却可以用动态格式描述非结构化数据。

对于我们这个情况，用 SQL 型还是 No-SQL 型的数据库没多大影响，由于下列原因，我们最终选择了 Google 的 NoSQL 云数据库 Firebase：

1. 它能够把用户上传的图片保存在云端并存储起来
2. 它包含 WebSocket 功能，能够实时更新
3. 它能够处理用户验证，并且提供简单的 OAuth 功能。

我们确定了数据库后，就要理解数据模型之间的关系了。由于 Firebase 是 NoSQL 类型，我们无法创建联合表或者设置像 “记录 （Checkins）属于目标（Goals）” 的从属关系。因此我们需要弄清楚 JSON 树是什么样的，对象是怎样嵌套的（或者不是嵌套的关系）。最终，我们构建了像这样的模型：

我们最终为目标（Goal）对象确定的 Firebase 数据格式。注意里程碑（Milestones）和记录（Checkins）对象嵌套在 Goals 中。

（注意: 出于性能考虑，Firebase 更倾向于简单、常规的数据结构, 但对于我们这种情况，需要在数据中进行嵌套，因为我们不会从数据库中获取目标（Goal）却不获取相应的子对象里程碑（Milestones）和记录（Checkins）。）

第 4 步：设置好 Github 和敏捷开发工作流

我们知道，从一开始就保持井然有序、执行敏捷开发对我们有极大好处。我们设置好 Github 上的仓库，我们无法直接将代码合并到主（master）分支，这迫使我们互相审阅代码。

我们还在 Waffle.io 网站上创建了敏捷开发的面板，它是免费的，很容易集成到 Github。我们在 Waffle 面板上罗列出所有用户故事以及需要我们去修复的 bug。之后当我们开始编码时，我们每个人会为自己正在研究的每一个用户故事创建一个 git 分支，在完成工作后合并这一条条的分支。

我们还开始保持晨会的习惯，讨论前一天的工作和每一个人遇到的阻碍。会议常常决定了当天的流程 —— 哪些人要结对编程，哪些人要独自处理问题。

我认为这种类型的工作流程非常好，因为它让我们能够清楚地找到自己的定位，不用顾虑人际矛盾地高效执行工作。

第 5 步： 选择、下载样板文件

由于 JavaScript 的生态系统过于复杂，我们不打算从最底层开始构建应用。把宝贵的时间花在连通 Webpack 构建脚本和加载器，把符号链接指向项目工程这些事情上感觉很没必要。我的团队选择了 Firebones 框架，因为它恰好适用于我们这个情况，当然还有很多可供选择的开源框架。

第 6 步：编写后端 API 路由（或者 Firebase 监听器）

如果我们没有用基于云的数据库，这时就应该开始编写执行数据库查询的后端高速路由了。但是由于我们用的是 Firebase，它本身就是云端的，可以用不同的方式进行代码交互，因此我们只需要设置好一个可用的数据库监听器。

为了确保监听器在工作，我们用代码做出了用于创建目标（Goal）的基本用户表格，实际上当我们完成表格时，就看到数据库执行可更新。数据库就成功连接了！

第 7 步：构建 “概念证明”

接下来是为应用创建 “概念证明”，也可以说是实现起来最复杂的基本功能的原型，证明我们的应用 可以 实现。对我们而言，这意味着要找个前端库来实现时间线的渲染，成功连接到 Firebase，显示数据库中的一些种子数据。

Victory.JS 绘制的简单时间线

我们找到了基于 D3 构建的响应式库 Victory.JS，花了一天时间阅读文档，用 VictoryLine 和 VictoryScatter 组件实现了非常基础的示例，能够可视化地显示数据库中的数据。实际上，这很有用！我们可以开始构建了。

第 8 步：用代码实现功能

最后，是时候构建出应用中那些令人期待的功能了。取决于你要构建的应用，这一重要步骤会有些明显差异。我们根据所用的框架，编码出不同的用户故事并保存在 Waffle 上。常常需要同时接触前端和后端代码（比如，创建一个前端表格同时要连接到数据库）。我们实现了包含以下这些大大小小的功能：

• 能够创建新目标、里程碑和记录
• 能够删除目标，里程碑和记录
• 能够更改时间线的名称，颜色和详细内容
• 能够缩放时间线
• 能够为资源添加链接
• 能够上传视频
• 在达到相关目标的里程碑和记录时弹出资源和视频
• 集成富文本编辑器
• 用户注册、验证、OAuth 验证
• 弹出查看时间线选项
• 加载画面

有各种原因，这一步花了我们很多时间 —— 这一阶段是产生最多优质代码的阶段，每当我们实现了一个功能，就会有更多的事情要完善。

第 9 步： 选择并实现设计方案

当我们使用 MVP 架构实现了想要的功能，就可以开始清理，对它进行美化了。像表单，菜单和登陆栏等组件，我的团队用的是 Material-UI，不需要很多深层次的设计知识，它也能确保每个组件看上去都很圆润光滑。

这是我制作的最喜爱功能之一了。它美得令人心旷神怡。

我们花了一点时间来选择颜色方案和编写 CSS ，这让我们在编程中休息了一段美妙的时间。期间我们还设计了 logo 图标，还上传了网站图标。

第 10 步： 找出并减少 bug

我们一开始就应该使用测试驱动开发的模式，但时间有限，我们那点时间只够用来实现功能。这意味着最后的两天时间我们花在了模拟我们能够想到的每一种用户流，并从应用中找出 bug。

这一步是最不具系统性的，但是我们发现了一堆够我们忙乎的 bug，其中一个是在某些情况下加载动画不会结束的 bug，还有一个是资源组件会完全停止运行的 bug。修复 bug 是件令人恼火的事情，但当软件可以运行时，又特别令人满足。

第 11 步：应用上线

最后一步是上线应用，这样才可以让用户使用它！由于我们使用 Firebase 存储数据，因此我们使用了 Firebase Hosting，它很直观也很简单。如果你要选择其它的数据库，你可以使用 Heroku 或者 DigitalOcean。一般来讲，可以在主机网站中查看使用说明。

我们还在 Namecheap.com 上购买了一个便宜的域名，这让我们的应用更加完善，很容易被找到。

好了，这就是全部的过程 —— 我们都是这款实用的全栈应用的合作开发者。如果要继续讲，那么第 12 步将会是对用户进行 A/B 测试，这样我们才能更好地理解：实际用户与这款应用交互的方式和他们想在 V2 版本中看到的新功能。

但是，现在我们感到非常开心，不仅是因为成品，还因为我们从这个过程中获得了难以估量的知识和理解。点击 这里 查看 Align 应用！

Align 团队：Sara Kladky（左），Melanie Mohn（中），还有我自己。

via: https://medium.com/ladies-storm-hackathons/how-we-built-our-first-full-stack-javascript-web-app-in-three-weeks-8a4668dbd67c?imm_mid=0f581a&cmp=em-web-na-na-newsltr_20170816

作者：Sophia Ciocca 译者：BriFuture 校对：wxy

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

本文作者 Greg Kroah-Hartman 是 Linux 稳定版内核的维护负责人。

很多人都问我这样的问题，在他们的产品/设备/笔记本/服务器等上面应该使用什么样的稳定版内核。一直以来，尤其是那些现在已经延长支持时间的内核，都是由我和其他人提供支持，因此，给出这个问题的答案并不是件容易的事情。在这篇文章我将尝试去给出我在这个问题上的看法。当然，你可以任意选用任何一个你想去使用的内核版本，这里只是我的建议。

和以前一样，在这里给出的这些看法只代表我个人的意见。

可选择的内核有哪些

下面列出了我建议你应该去使用的内核的列表，从最好的到最差的都有。我在下面将详细介绍，但是如果你只想得到一个结论，它就是你想要的：

建议你使用的内核的分级，从最佳的方案到最差的方案如下：

• 你最喜欢的 Linux 发行版支持的内核
• 最新的稳定版
• 最新的 LTS （长期支持）版本
• 仍然处于维护状态的老的 LTS 版本

绝对不要去使用的内核：

• 不再维护的内核版本

给上面的列表给出具体的数字，今天是 2018 年 8 月 24 日，kernel.org 页面上可以看到是这样：

因此，基于上面的列表，那它应该是：

• 4.18.5 是最新的稳定版
• 4.14.67 是最新的 LTS 版本
• 4.9.124、4.4.152、以及 3.16.57 是仍然处于维护状态的老的 LTS 版本
• 4.17.19 和 3.18.119 是过去 60 天内有过发布的 “生命周期终止” 的内核版本，它们仍然保留在 kernel.org 站点上，是为了仍然想去使用它们的那些人。

非常容易，对吗？

Ok，现在我给出这样选择的一些理由：

Linux 发行版内核

对于大多数 Linux 用户来说，最好的方案就是使用你喜欢的 Linux 发行版的内核。就我本人而言，我比较喜欢基于社区的、内核不断滚动升级的用最新内核的 Linux 发行版，并且它也是由开发者社区来支持的。这种类型的发行版有 Fedora、openSUSE、Arch、Gentoo、CoreOS，以及其它的。

所有这些发行版都使用了上游的最新的稳定版内核，并且确保定期打了需要的 bug 修复补丁。当它拥有了最新的修复之后（记住所有的修复都是安全修复)，这就是你可以使用的最安全、最好的内核之一。

有些社区的 Linux 发行版需要很长的时间才发行一个新内核版本，但是最终发行的版本和所支持的内核都是非常好的。这些也都非常好用，Debian 和 Ubuntu 就是这样的例子。

如果我没有在这里列出你所喜欢的发行版，并不是意味着它们的内核不够好。查看这些发行版的网站，确保它们的内核包是不断应用最新的安全补丁进行升级过的，那么它就应该是很好的。

许多人好像喜欢旧式、“传统” 模式的发行版，使用 RHEL、SLES、CentOS 或者 “LTS” Ubuntu 发行版。这些发行版挑选一个特定的内核版本，然后使用好几年，甚至几十年。他们反向移植了最新的 bug 修复，有时也有一些内核的新特性，所有的只是追求堂吉诃德式的保持版本号不变而已，尽管他们已经在那个旧的内核版本上做了成千上万的变更。这项工作是一项真正吃力不讨好的工作，分配到这些任务的开发人员做了一些精彩的工作才能实现这些目标。所以如果你希望永远不看到你的内核版本号发生过变化，那么就使用这些发行版。他们通常会为使用而付出一些钱，当发生错误时能够从这些公司得到一些支持，那就是值得的。

所以，你能使用的最好的内核是你可以求助于别人，而别人可以为你提供支持的内核。使用那些支持，你通常都已经为它支付过费用了（对于企业发行版），而这些公司也知道他们职责是什么。

但是，如果你不希望去依赖别人，而是希望你自己管理你的内核，或者你有发行版不支持的硬件，那么你应该去使用最新的稳定版：

最新的稳定版

最新的稳定版内核是 Linux 内核开发者社区宣布为“稳定版”的最新的一个内核。大约每三个月，社区发行一个包含了对所有新硬件支持的、新的稳定版内核，最新版的内核不但改善内核性能，同时还包含内核各部分的 bug 修复。接下来的三个月之后，进入到下一个内核版本的 bug 修复将被反向移植进入这个稳定版内核中，因此，使用这个内核版本的用户将确保立即得到这些修复。

最新的稳定版内核通常也是主流社区发行版所使用的内核，因此你可以确保它是经过测试和拥有大量用户使用的内核。另外，内核社区（全部开发者超过 4000 人）也将帮助这个发行版提供对用户的支持，因为这是他们做的最新的一个内核。

三个月之后，将发行一个新的稳定版内核，你应该去更新到它以确保你的内核始终是最新的稳定版，因为当最新的稳定版内核发布之后，对你的当前稳定版内核的支持通常会落后几周时间。

如果你在上一个 LTS （长期支持）版本发布之后购买了最新的硬件，为了能够支持最新的硬件，你几乎是绝对需要去运行这个最新的稳定版内核。对于台式机或新的服务器，最新的稳定版内核通常是推荐运行的内核。

最新的 LTS 版本

如果你的硬件为了保证正常运行（像大多数的嵌入式设备），需要依赖供应商的源码 树外 out-of-tree 的补丁，那么对你来说，最好的内核版本是最新的 LTS 版本。这个版本拥有所有进入稳定版内核的最新 bug 修复，以及大量的用户测试和使用。

请注意，这个最新的 LTS 版本没有新特性，并且也几乎不会增加对新硬件的支持，因此，如果你需要使用一个新设备，那你的最佳选择就是最新的稳定版内核，而不是最新的 LTS 版内核。

另外，对于这个 LTS 版本的用户来说，他也不用担心每三个月一次的“重大”升级。因此，他们将一直坚持使用这个 LTS 版本，并每年升级一次，这是一个很好的实践。

使用这个 LTS 版本的不利方面是，你没法得到在最新版本内核上实现的内核性能提升，除非在未来的一年中，你升级到下一个 LTS 版内核。

另外，如果你使用的这个内核版本有问题，你所做的第一件事情就是向任意一位内核开发者报告发生的问题，并向他们询问，“最新的稳定版内核中是否也存在这个问题？”并且，你需要意识到，对它的支持不会像使用最新的稳定版内核那样容易得到。

现在，如果你坚持使用一个有大量的补丁集的内核，并且不希望升级到每年一次的新 LTS 版内核上，那么，或许你应该去使用老的 LTS 版内核：

老的 LTS 版本

传统上，这些版本都由社区提供 2 年时间的支持，有时候当一个重要的 Linux 发行版（像 Debian 或 SLES）依赖它时，这个支持时间会更长。然而在过去一年里，感谢 Google、Linaro、Linaro 成员公司、kernelci.org、以及其它公司在测试和基础设施上的大量投入，使得这些老的 LTS 版内核得到更长时间的支持。

最新的 LTS 版本以及它们将被支持多长时间，这是 2018 年 8 月 24 日显示在 kernel.org/category/releases.html 上的信息：

Google 和其它公司希望这些内核使用的时间更长的原因是，由于现在几乎所有的 SoC 芯片的疯狂的（也有人说是打破常规）开发模型。这些设备在芯片发行前几年就启动了他们的开发周期，而那些代码从来不会合并到上游，最终结果是新打造的芯片是基于一个 2 年以前的老内核发布的。这些 SoC 的代码树通常增加了超过 200 万行的代码，这使得它们成为我们前面称之为“类 Linux 内核“的东西。

如果在 2 年后，这个 LTS 版本停止支持，那么来自社区的支持将立即停止，并且没有人对它再进行 bug 修复。这导致了在全球各地数以百万计的非常不安全的设备仍然在使用中，这对任何生态系统来说都不是什么好事情。

由于这种依赖，这些公司现在要求新设备不断更新到最新的 LTS 版本——这些为它们特定发布的版本（例如现在的每个 4.9.y 版本）。其中一个这样的例子就是新 Android 设备对内核版本的要求，这些新设备所带的 “Andrid O” 版本（和现在的 “Android P” 版本）指定了最低允许使用的内核版本，并且 Andoird 安全更新版本也开始越来越频繁在设备上要求使用这些 “.y” 版本。

我注意到一些生产商现在已经在做这些事情。Sony 是其中一个非常好的例子，在他们的大多数新手机上，通过他们每季度的安全更新版本，将设备更新到最新的 4.4.y 发行版上。另一个很好的例子是一家小型公司 Essential，据我所知，他们持续跟踪 4.4.y 版本的速度比其它公司都快。

当使用这种老的内核时有个重大警告。反向移植到这种内核中的安全修复不如最新版本的 LTS 内核多，因为这些使用老的 LTS 内核的设备的传统模式是一个更加简化的用户模式。这些内核不能用于任何“通用计算”模式中，在这里用的是 不可信用户 untrusted user 或虚拟机，极大地削弱了对老的内核做像最近的 Spectre 这样的修复的能力，如果在一些分支中存在这样的 bug 的话。

因此，仅在你能够完全控制的设备，或者限定在一个非常强大的安全模型（像 Android 一样强制使用 SELinux 和应用程序隔离）时使用老的 LTS 版本。绝对不要在有不可信用户/程序，或虚拟机的服务器上使用这些老的 LTS 版内核。

此外，如果社区对它有支持的话，社区对这些老的 LTS 版内核相比正常的 LTS 版内核的支持要少的多。如果你使用这些内核，那么你只能是一个人在战斗，你需要有能力去独自支持这些内核，或者依赖你的 SoC 供应商为你提供支持（需要注意的是，几乎没有供应商会为你提供支持，因此，你要特别注意 ……）。

不再维护的内核发行版

更让人感到惊讶的事情是，许多公司只是随便选一个内核发行版，然后将它封装到它们的产品里，并将它毫不犹豫地承载到数十万的部件中。其中一个这样的糟糕例子是 Lego Mindstorm 系统，不知道是什么原因在它们的设备上随意选取了一个 -rc 的内核发行版。-rc 的发行版是开发中的版本，根本没有 Linux 内核开发者认为它适合任何人使用，更不用说是数百万的用户了。

当然，如果你愿意，你可以随意地使用它，但是需要注意的是，可能真的就只有你一个人在使用它。社区不会为你提供支持，因为他们不可能关注所有内核版本的特定问题，因此如果出现错误，你只能独自去解决它。对于一些公司和系统来说，这么做可能还行，但是如果没有为此有所规划，那么要当心因此而产生的“隐性”成本。

总结

基于以上原因，下面是一个针对不同类型设备的简短列表，这些设备我推荐适用的内核如下：

• 笔记本 / 台式机：最新的稳定版内核
• 服务器：最新的稳定版内核或最新的 LTS 版内核
• 嵌入式设备：最新的 LTS 版内核或老的 LTS 版内核（如果使用的安全模型非常强大和严格）

至于我，在我的机器上运行什么样的内核？我的笔记本运行的是最新的开发版内核（即 Linus 的开发树）再加上我正在做修改的内核，我的服务器上运行的是最新的稳定版内核。因此，尽管我负责 LTS 发行版的支持工作，但我自己并不使用 LTS 版内核，除了在测试系统上。我依赖于开发版和最新的稳定版内核，以确保我的机器运行的是目前我们所知道的最快的也是最安全的内核版本。

via: http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

作者：Greg Kroah-Hartman 选题：lujun9972 译者：qhwdw 校对：wxy

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

这是一个当老旧的 Windows 机器退役时，决定迁移到 Linux 的故事。

我在 ONLYOFFICE 的市场部门工作的每一天，我都能看到 Linux 用户在网上讨论我们的办公软件。我们的产品在 Linux 用户中很受欢迎，这使得我对使用 Linux 作为日常工具的体验非常好奇。我的老旧的 Windows XP 机器在性能上非常差，因此我决定了解 Linux 系统（特别是 Ubuntu）并且决定去尝试使用它。我的两个同事也加入了我的计划。

为何选择 Linux ？

我们必须做出改变，首先，我们的老系统在性能方面不够用：我们经历过频繁的崩溃，每当运行超过两个应用时，机器就会负载过度，关闭机器时有一半的几率冻结等等。这很容易让我们从工作中分心，意味着我们没有我们应有的工作效率了。

升级到 Windows 的新版本也是一种选择，但这样可能会带来额外的开销，而且我们的软件本身也是要与 Microsoft 的办公软件竞争。因此我们在这方面也存在意识形态的问题。

其次，就像我之前提过的， ONLYOFFICE 产品在 Linux 社区内非常受欢迎。通过阅读 Linux 用户在使用我们的软件时的体验，我们也对加入他们很感兴趣。

在我们要求转换到 Linux 系统一周后，我们拿到了崭新的装好了 Kubuntu 的机器。我们选择了 16.04 版本，因为这个版本支持 KDE Plasma 5.5 和包括 Dolphin 在内的很多 KDE 应用，同时也包括 LibreOffice 5.1 和 Firefox 45 。

Linux 让人喜欢的地方

我相信 Linux 最大的优势是它的运行速度，比如，从按下机器的电源按钮到开始工作只需要几秒钟时间。从一开始，一切看起来都超乎寻常地快：总体的响应速度，图形界面，甚至包括系统更新的速度。

另一个使我惊奇的事情是跟 Windows 相比， Linux 几乎能让你配置任何东西，包括整个桌面的外观。在设置里面，我发现了如何修改各种栏目、按钮和字体的颜色和形状，也可以重新布置任意桌面组件的位置，组合桌面小工具（甚至包括漫画和颜色选择器）。我相信我还仅仅只是了解了基本的选项，之后还需要探索这个系统更多著名的定制化选项。

Linux 发行版通常是一个非常安全的环境。人们很少在 Linux 系统中使用防病毒的软件，因为很少有人会写病毒程序来攻击 Linux 系统。因此你可以拥有很好的系统速度，并且节省了时间和金钱。

总之， Linux 已经改变了我们的日常生活，用一系列的新选项和功能大大震惊了我们。仅仅通过短时间的使用，我们已经可以给它总结出以下特性：

• 操作很快很顺畅
• 高度可定制
• 对新手很友好
• 了解基本组件很有挑战性，但回报丰厚
• 安全可靠
• 对所有想改变工作场所的人来说都是一次绝佳的体验

你已经从 Windows 或 MacOS 系统换到 Kubuntu 或其他 Linux 变种了么？或者你是否正在考虑做出改变？请分享你想要采用 Linux 系统的原因，连同你对开源的印象一起写在评论中。

via: https://opensource.com/article/18/1/move-to-linux-old-windows

作者：Michael Korotaev 译者：bookug 校对：wxy

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

这些技巧或许对那些想要践行 DevOps 的系统运维和开发者能有所帮助。

在去年大概一年的时间里，我注意到对“Devops 实践”感兴趣的开发人员和系统管理员突然有了明显的增加。这样的变化也合理：现在开发者只要花很少的钱，调用一些 API，就能单枪匹马地在一整套分布式基础设施上运行自己的应用，在这个时代，开发和运维的紧密程度前所未有。我看过许多博客和文章介绍很酷的 DevOps 工具和相关思想，但是给那些希望践行 DevOps 的人以指导和建议的内容，我却很少看到。

这篇文章的目的就是描述一下如何去实践。我的想法基于 Reddit 上 devops 的一些访谈、聊天和深夜讨论，还有一些随机谈话，一般都发生在享受啤酒和美食的时候。如果你已经开始这样实践，我对你的反馈很感兴趣，请通过我的博客或者 Twitter 联系我，也可以直接在下面评论。我很乐意听到你们的想法和故事。

古代的 IT

了解历史是搞清楚未来的关键，DevOps 也不例外。想搞清楚 DevOps 运动的普及和流行，去了解一下上世纪 90 年代后期和 21 世纪前十年 IT 的情况会有帮助。这是我的经验。

我的第一份工作是在一家大型跨国金融服务公司做 Windows 系统管理员。当时给计算资源扩容需要给 Dell 打电话（或者像我们公司那样打给 CDW），并下一个价值数十万美元的订单，包含服务器、网络设备、电缆和软件，所有这些都要运到生产或线下的数据中心去。虽然 VMware 仍在尝试说服企业使用虚拟机运行他们的“性能敏感”型程序是更划算的，但是包括我们在内的很多公司都还是愿意使用他们的物理机运行应用。

在我们技术部门，有一个专门做数据中心工程和运营的团队，他们的工作包括价格谈判，让荒唐的月租能够降一点点，还包括保证我们的系统能够正常冷却（如果设备太多，这个事情的难度会呈指数增长）。如果这个团队足够幸运足够有钱，境外数据中心的工作人员对我们所有的服务器型号又都有足够的了解，就能避免在盘后交易中不小心搞错东西。那时候亚马逊 AWS 和 Rackspace 逐渐开始加速扩张，但还远远没到临界规模。

当时我们还有专门的团队来保证硬件上运行着的操作系统和软件能够按照预期工作。这些工程师负责设计可靠的架构以方便给系统打补丁、监控和报警，还要定义 基础镜像 gold image 的内容。这些大都是通过很多手工实验完成的，很多手工实验是为了编写一个 运行说明书 runbook 来描述要做的事情，并确保按照它执行后的结果确实在预期内。在我们这么大的组织里，这样做很重要，因为一线和二线的技术支持都是境外的，而他们的培训内容只覆盖到了这些运行说明而已。

（这是我职业生涯前三年的世界。我那时候的梦想是成为制定最高标准的人！）

软件发布则完全是另外一头怪兽。无可否认，我在这方面并没有积累太多经验。但是，从我收集的故事（和最近的经历）来看，当时大部分软件开发的日常大概是这样：

• 开发人员按照技术和功能需求来编写代码，这些需求来自于业务分析人员的会议，但是会议并没有邀请开发人员参加。
• 开发人员可以选择为他们的代码编写单元测试，以确保在代码里没有任何明显的疯狂行为，比如除以 0 但不抛出异常。
• 然后开发者会把他们的代码标记为 “Ready for QA”（准备好了接受测试），质量保障的成员会把这个版本的代码发布到他们自己的环境中，这个环境和生产环境可能相似，也可能不，甚至和开发环境相比也不一定相似。
• 故障会在几天或者几个星期内反馈到开发人员那里，这个时长取决于其它业务活动和优先事项。

虽然系统管理员和开发人员经常有不一致的意见，但是对“变更管理”却一致痛恨。变更管理由高度规范的（就我当时的雇主而言）和非常必要的规则和程序组成，用来管理一家公司应该什么时候做技术变更，以及如何做。很多公司都按照 ITIL 来操作，简单的说，ITIL 问了很多和事情发生的原因、时间、地点和方式相关的问题，而且提供了一个过程，对产生最终答案的决定做审计跟踪。

你可能从我的简短历史课上了解到，当时 IT 的很多很多事情都是手工完成的。这导致了很多错误。错误又导致了很多财产损失。变更管理的工作就是尽量减少这些损失，它常常以这样的形式出现：不管变更的影响和规模大小，每两周才能发布部署一次。周五下午 4 点到周一早上 5 点 59 分这段时间，需要排队等候发布窗口。（讽刺的是，这种流程导致了更多错误，通常还是更严重的那种错误）

DevOps 不是专家团

你可能在想 “Carlos 你在讲啥啊，什么时候才能说到 Ansible playbooks？”，我喜欢 Ansible，但是请稍等 —— 下面这些很重要。

你有没有过被分配到需要跟 DevOps 小组打交道的项目？你有没有依赖过“配置管理”或者“持续集成/持续交付”小组来保证业务流水线设置正确？你有没有在代码开发完的数周之后才参加发布部署的会议？

如果有过，那么你就是在重温历史，这个历史是由上面所有这些导致的。

出于本能，我们喜欢和像自己的人一起工作，这会导致壁垒的形成。很自然，这种人类特质也会在工作场所表现出来是不足为奇的。我甚至在曾经工作过的一个 250 人的创业公司里见到过这样的现象。刚开始的时候，开发人员都在聚在一起工作，彼此深度协作。随着代码变得复杂，开发相同功能的人自然就坐到了一起，解决他们自己的复杂问题。然后按功能划分的小组很快就正式形成了。

在我工作过的很多公司里，系统管理员和开发人员不仅像这样形成了天然的壁垒，而且彼此还有激烈的对抗。开发人员的环境出问题了或者他们的权限太小了，就会对系统管理员很恼火。系统管理员怪开发人员无时无刻地在用各种方式破坏他们的环境，怪开发人员申请的计算资源严重超过他们的需要。双方都不理解对方，更糟糕的是，双方都不愿意去理解对方。

大部分开发人员对操作系统，内核或计算机硬件都不感兴趣。同样，大部分系统管理员，即使是 Linux 的系统管理员，也都不愿意学习编写代码，他们在大学期间学过一些 C 语言，然后就痛恨它，并且永远都不想再碰 IDE。所以，开发人员把运行环境的问题甩给围墙外的系统管理员，系统管理员把这些问题和甩过来的其它上百个问题放在一起安排优先级。每个人都忙于怨恨对方。DevOps 的目的就是解决这种矛盾。

DevOps 不是一个团队，CI/CD 也不是 JIRA 系统的一个用户组。DevOps 是一种思考方式。根据这个运动来看，在理想的世界里，开发人员、系统管理员和业务相关人将作为一个团队工作。虽然他们可能不完全了解彼此的世界，可能没有足够的知识去了解彼此的积压任务，但他们在大多数情况下能有一致的看法。

把所有基础设施和业务逻辑都代码化，再串到一个发布部署流水线里，就像是运行在这之上的应用一样。这个理念的基础就是 DevOps。因为大家都理解彼此，所以人人都是赢家。聊天机器人和易用的监控工具、可视化工具的兴起，背后的基础也是 DevOps。

Adam Jacob 说的最好：“DevOps 就是企业往软件导向型过渡时我们用来描述操作的词。”

要实践 DevOps 我需要知道些什么

我经常被问到这个问题，它的答案和同属于开放式的其它大部分问题一样：视情况而定。

现在“DevOps 工程师”在不同的公司有不同的含义。在软件开发人员比较多但是很少有人懂基础设施的小公司，他们很可能是在找有更多系统管理经验的人。而其他公司，通常是大公司或老公司，已经有一个稳固的系统管理团队了，他们在向类似于谷歌 SRE 的方向做优化，也就是“设计运维功能的软件工程师”。但是，这并不是金科玉律，就像其它技术类工作一样，这个决定很大程度上取决于他的招聘经理。

也就是说，我们一般是在找对深入学习以下内容感兴趣的工程师：

• 如何管理和设计安全、可扩展的云平台（通常是在 AWS 上，不过微软的 Azure、Google Cloud Platform，还有 DigitalOcean 和 Heroku 这样的 PaaS 提供商，也都很流行）。
• 如何用流行的 CI/CD 工具，比如 Jenkins、GoCD，还有基于云的 Travis CI 或者 CircleCI，来构造一条优化的发布部署流水线和发布部署策略。
• 如何在你的系统中使用基于时间序列的工具，比如 Kibana、Grafana、Splunk、Loggly 或者 Logstash 来监控、记录，并在变化的时候报警。
• 如何使用配置管理工具，例如 Chef、Puppet 或者 Ansible 做到“基础设施即代码”，以及如何使用像 Terraform 或 CloudFormation 的工具发布这些基础设施。

容器也变得越来越受欢迎。尽管有人对大规模使用 Docker 的现状表示不满，但容器正迅速地成为一种很好的方式来实现在更少的操作系统上运行超高密度的服务和应用，同时提高它们的可靠性。（像 Kubernetes 或者 Mesos 这样的容器编排工具，能在宿主机故障的时候，几秒钟之内重新启动新的容器。）考虑到这些，掌握 Docker 或者 rkt 以及容器编排平台的知识会对你大有帮助。

如果你是希望做 DevOps 实践的系统管理员，你还需要知道如何写代码。Python 和 Ruby 是 DevOps 领域的流行语言，因为它们是可移植的（也就是说可以在任何操作系统上运行）、快速的，而且易读易学。它们还支撑着这个行业最流行的配置管理工具（Ansible 是使用 Python 写的，Chef 和 Puppet 是使用 Ruby 写的）以及云平台的 API 客户端（亚马逊 AWS、微软 Azure、Google Cloud Platform 的客户端通常会提供 Python 和 Ruby 语言的版本）。

如果你是开发人员，也希望做 DevOps 的实践，我强烈建议你去学习 Unix、Windows 操作系统以及网络基础知识。虽然云计算把很多系统管理的难题抽象化了，但是对应用的性能做调试的时候，如果你知道操作系统如何工作的就会有很大的帮助。下文包含了一些这个主题的图书。

如果你觉得这些东西听起来内容太多，没关系，大家都是这么想的。幸运的是，有很多小项目可以让你开始探索。其中一个项目是 Gary Stafford 的选举服务，一个基于 Java 的简单投票平台。我们要求面试候选人通过一个流水线将该服务从 GitHub 部署到生产环境基础设施上。你可以把这个服务与 Rob Mile 写的了不起的 DevOps 入门教程结合起来学习。

还有一个熟悉这些工具的好方法，找一个流行的服务，然后只使用 AWS 和配置管理工具来搭建这个服务所需要的基础设施。第一次先手动搭建，了解清楚要做的事情，然后只用 CloudFormation（或者 Terraform）和 Ansible 重写刚才的手动操作。令人惊讶的是，这就是我们基础设施开发人员为客户所做的大部分日常工作，我们的客户认为这样的工作非常有意义！

需要读的书

如果你在找 DevOps 的其它资源，下面这些理论和技术书籍值得一读。

理论书籍

• Gene Kim 写的 《 凤凰项目 The Phoenix Project 》。这是一本很不错的书，内容涵盖了我上文解释过的历史（写的更生动形象），描述了一个运行在敏捷和 DevOps 之上的公司向精益前进的过程。
• Terrance Ryan 写的 《 布道之道 Driving Technical Change 》。非常好的一小本书，讲了大多数技术型组织内的常见性格特点以及如何和他们打交道。这本书对我的帮助比我想象的更多。
• Tom DeMarco 和 Tim Lister 合著的 《 人件 Peopleware 》。管理工程师团队的经典图书，有一点过时，但仍然很有价值。
• Tom Limoncelli 写的 《 时间管理：给系统管理员 Time Management for System Administrators 》。这本书主要面向系统管理员，它对很多大型组织内的系统管理员生活做了深入的展示。如果你想了解更多系统管理员和开发人员之间的冲突，这本书可能解释了更多。
• Eric Ries 写的 《 精益创业 The Lean Startup 》。描述了 Eric 自己的 3D 虚拟形象公司，IMVU，发现了如何精益工作，快速失败和更快盈利。
• Jez Humble 和他的朋友写的 《 精益企业 Lean Enterprise 》。这本书是对精益创业做的改编，以更适应企业，两本书都很棒，都很好地解释了 DevOps 背后的商业动机。
• Kief Morris 写的 《 基础设施即代码 Infrastructure As Code 》。关于“基础设施即代码”的非常好的入门读物！很好的解释了为什么所有公司都有必要采纳这种做法。
• Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 合著的 《 站点可靠性工程师 Site Reliability Engineering 》。一本解释谷歌 SRE 实践的书，也因为是“DevOps 诞生之前的 DevOps”被人熟知。在如何处理运行时间、时延和保持工程师快乐方面提供了有意思的看法。

技术书籍

如果你想找的是让你直接跟代码打交道的书，看这里就对了。

• W. Richard Stevens 的 《 TCP/IP 详解 TCP/IP Illustrated 》。这是一套经典的（也可以说是最全面的）讲解网络协议基础的巨著，重点介绍了 TCP/IP 协议族。如果你听说过 1、2、3、4 层网络，而且对深入学习它们感兴趣，那么你需要这本书。
• Evi Nemeth、Trent Hein 和 Ben Whaley 合著的 《 UNIX/Linux 系统管理员手册 UNIX and Linux System Administration Handbook 》。一本很好的入门书，介绍 Linux/Unix 如何工作以及如何使用。
• Don Jones 和 Jeffrey Hicks 合著的 《 Windows PowerShell 实战指南 Learn Windows Powershell In A Month of Lunches 》。如果你在 Windows 系统下做自动化任务，你需要学习怎么使用 Powershell。这本书能够帮助你。Don Jones 是这方面著名的 MVP。
• 几乎所有 James Turnbull 写的东西，针对流行的 DevOps 工具，他发表了很好的技术入门读物。

不管是在那些把所有应用都直接部署在物理机上的公司，（现在很多公司仍然有充分的理由这样做）还是在那些把所有应用都做成 serverless 的先驱公司，DevOps 都很可能会持续下去。这部分工作很有趣，产出也很有影响力，而且最重要的是，它搭起桥梁衔接了技术和业务之间的缺口。DevOps 是一个值得期待的美好事物。

首次发表在 Neurons Firing on a Keyboard。使用 CC-BY-SA 协议。

via: https://opensource.com/article/18/1/getting-devops

作者：Carlos Nunez 译者：belitex 校对：pityonline

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

又一次为了工作图书俱乐部而读书。除了其它我亲自推荐的书，这是我至今最喜爱的书。

作为计算机科学基础之一的研究领域是算法：我们如何高效地用计算机程序解决问题？这基本上属于数学领域，但是这很少关于理想的或理论上的解决方案，而是更在于最高效地利用有限的资源获得一个充分（如果不能完美）的答案。其中许多问题要么是日常的生活问题，要么与人们密切相关。毕竟，计算机科学的目的是为了用计算机解决实际问题。《 算法之美 Algorithms to Live By 》提出的问题是：“我们可以反过来吗”——我们可以通过学习计算机科学解决问题的方式来帮助我们做出日常决定吗？

本书的十一个章节有很多有趣的内容，但也有一个有趣的主题：人类早已擅长这一点。很多章节以一个算法研究和对问题的数学分析作为开始，接着深入到探讨如何利用这些结果做出更好的决策，然后讨论关于人类真正会做出的决定的研究，之后，考虑到典型生活情境的限制，会发现人类早就在应用我们提出的最佳算法的特殊版本了。这往往会破坏本书的既定目标，值得庆幸的是，它决不会破坏对一般问题的有趣讨论，即计算机科学如何解决它们，以及我们对这些问题的数学和技术形态的了解。我认为这本书的自助效用比作者打算的少一些，但有很多可供思考的东西。

（也就是说，值得考虑这种一致性是否太少了，因为人类已经擅长这方面了，更因为我们的算法是根据人类直觉设计的。可能我们的最佳算法只是反映了人类的思想。在某些情况下，我们发现我们的方案和数学上的典范不一样，但是在另一些情况下，它们仍然是我们当下最好的猜想。)

这是那种章节列表是书评里重要部分的书。这里讨论的算法领域有最优停止、探索和利用决策（什么时候带着你发现的最好东西走，以及什么时候寻觅更好的东西），以及排序、缓存、调度、贝叶斯定理（一般还有预测）、创建模型时的过拟合、放松（解决容易的问题而不是你的实际问题）、随机算法、一系列网络算法，最后还有游戏理论。其中每一项都有有用的见解和发人深省的讨论——这些有时显得十分理论化的概念令人吃惊地很好地映射到了日常生活。这本书以一段关于“可计算的善意”的讨论结束：鼓励减少你自己和你交往的人所需的计算和复杂性惩罚。

如果你有计算机科学背景（就像我一样），其中许多都是熟悉的概念，而且你因为被普及了很多新东西或许会有疑惑。然而，请给这本书一个机会，类比法没你担忧的那么令人紧张。作者既小心又聪明地应用了这些原则。这本书令人惊喜地通过了一个重要的合理性检查：涉及到我知道或反复思考过的主题的章节很少有或没有明显的错误，而且能讲出有用和重要的事情。比如，调度的那一章节毫不令人吃惊地和时间管理有关，通过直接跳到时间管理问题的核心而胜过了半数的时间管理类书籍：如果你要做一个清单上的所有事情，你做这些事情的顺序很少要紧，所以最难的调度问题是决定不做哪些事情而不是做这些事情的顺序。

作者在贝叶斯定理这一章节中的观点完全赢得了我的心。本章的许多内容都是关于贝叶斯先验的，以及一个人对过去事件的了解为什么对分析未来的概率很重要。作者接着讨论了著名的棉花糖实验。即给了儿童一个棉花糖以后，儿童被研究者告知如果他们能够克制自己不吃这个棉花糖，等到研究者回来时，会给他们两个棉花糖。克制自己不吃棉花糖（在心理学文献中叫作“延迟满足”）被发现与未来几年更好的生活有关。这个实验多年来一直被引用和滥用于各种各样的宣传，关于选择未来的收益放弃即时的快乐从而拥有成功的生活，以及生活中的失败是因为无法延迟满足。更多的邪恶分析（当然）将这种能力与种族联系在一起，带有可想而知的种族主义结论。

我对棉花糖实验有点兴趣。这是一个百分百让我愤怒咆哮的话题。

《算法之美》是我读过的唯一提到了棉花糖实验并应用了我认为更有说服力的分析的书。这不是一个关于儿童天赋的实验，这是一个关于他们的贝叶斯先验的实验。什么时候立即吃棉花糖而不是等待奖励是完全合理的？当他们过去的经历告诉他们成年人不可靠，不可信任，会在不可预测的时间内消失并且撒谎的时候。而且，更好的是，作者用我之前没有听说过的后续研究和观察支持了这一分析，观察到的内容是，一些孩子会等待一段时间然后“放弃”。如果他们下意识地使用具有较差先验的贝叶斯模型，这就完全合情合理。

这是一本很好的书。它可能在某些地方的尝试有点太勉强（数学上最优停止对于日常生活的适用性比我认为作者想要表现的更加偶然和牵强附会），如果你学过算法，其中一些内容会感到熟悉，但是它的行文思路清晰，简洁，而且编辑得非常好。这本书没有哪一部分对不起它所受到的欢迎，书中的讨论贯穿始终。如果你发现自己“已经知道了这一切”，你可能还会在接下来几页中遇到一个新的概念或一个简洁的解释。有时作者会做一些我从没想到但是回想起来正确的联系，比如将网络协议中的指数退避和司法系统中的选择惩罚联系起来。还有意识到我们的现代通信世界并不是一直联系的，它是不断缓冲的，我们中的许多人正深受缓冲膨胀这一独特现象的苦恼。

我认为你并不必须是计算机科学专业或者精通数学才能读这本书。如果你想深入，每章的结尾都有许多数学上的细节，但是正文总是易读而清晰，至少就我所知是这样（作为一个以计算机科学为专业并学到了很多数学知识的人，你至少可以有保留地相信我）。即使你已经钻研了多年的算法，这本书仍然可以提供很多东西。

这本书我读得越多越喜欢。如果你喜欢阅读这种对生活的分析，我当然是赞成的。

Rating: 9 out of 10

Reviewed: 2017-10-22

via: https://www.eyrie.org/~eagle/reviews/books/1-62779-037-3.html

作者：Brian Christian;Tom Griffiths 译者：GraveAccent 校对：wxy

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