安卓编年史（31）：安卓 6.0 棉花糖

Summary: 2015 年 10 月，谷歌给世界带来了安卓 6.0 棉花糖。配合这个版本的发布，谷歌委托生产了两部新的 Nexus 设备：华为 Nexus 6P 和 LG Nexus 5X。

# 安卓编年史（31）：安卓 6.0 棉花糖

### 安卓 6.0 棉花糖

2015 年 10 月，谷歌给世界带来了安卓 6.0 棉花糖。配合这个版本的发布，谷歌委托生产了两部新的 Nexus 设备：[华为 Nexus 6P 和 LG Nexus 5X](http://arstechnica.com/gadgets/2015/10/nexus-5x-and-nexus-6p-review-the-true-flagships-of-the-android-ecosystem/)。除了常规的性能升级，新手机还带有一套关键硬件：为棉花糖的新指纹 API 准备的指纹识别器。棉花糖还引入了一个疯狂的全新搜索特性，被称作“Google Now on Tap”，用户控制的应用权限，一个全新的数据备份系统，以及许多其它的改良。

#### 新谷歌应用

棉花糖是[谷歌大标志重新设计](http://arstechnica.com/gadgets/2015/09/google-gets-a-new-logo/)后的第一个安卓版本。系统也随之升级，主要是一个新的谷歌应用，给搜索小部件，搜索页面以及应用图标添加了一个多彩的标志。

谷歌将应用抽屉从页面导航的横向布局还原回了单页竖直滚动表的形式。早期版本的安卓用的都是竖直滚动表的形式，直到谷歌在蜂巢中改成了横向页面系统。滚动单页面让人更容易从很多应用中找到目标。一项“快速滚动”的特性同样好用，它可以让你拖动滚动条来激活字母索引。新的应用抽屉布局也用到了小部件抽屉上。考虑到旧系统中小部件轻松就超过了 15 页，这是个大改进。

棉花糖应用抽屉顶部的“建议应用”栏也让查找应用变得更快。该栏显示的内容一直在变化，试图在你需要的时候为你提供你需要的应用。它使用了算法来统计应用使用，经常一起打开的应用以及每天的打开次数。

#### Google Now on Tap——一个没有完美实现的特性

棉花糖的头等新特性之一就是“Google Now on Tap”。有了 Now on Tap，你可以在安卓的任意界面长按 home 键，安卓会将整个屏幕发送给谷歌进行处理。谷歌会试着分析页面上的内容，并从屏幕底部弹出显示一个特殊的搜索结果列表。

Now on Tap 产生的结果不是通常的 10 个蓝色链接——即便那必定有一个通往谷歌搜索的链接。Now on Tap 还可以深度连接到其它使用了谷歌的应用索引功能的应用。他们的想法是你可以在 Youtube 音乐视频那里唤出 Now on tap，然后获得一个到谷歌 Play 或亚马逊“购买”页面的链接。在演员新闻文章处唤出 Now on Tap 可以链接到 IMDb 应用中该演员的页面上。

谷歌没有让这成为私有特性，而是给安卓创建了一个全新的“Assistant API（助理 API）”。用户可以挑选一个“助理应用”，它可以在长按 home 键的时候获取很多信息。助理应用会获取所有由当前应用加载的数据——不仅是直接从屏幕获取到的——连同所有这些图片还有任何开发者想要包含的元数据。这个 API 驱动了谷歌 Now on Tap，如果愿意的话，它还允许第三方打造 Now on Tap 的竞争对手。

谷歌在棉花糖的发布会上炒作了 Now on Tap，但实际上，这项特性不是很实用。谷歌搜索的价值在于你可以问它准确的问题——你输入你想要的内容，它搜索整个互联网寻找答案或网页。Now on Tap 让事情变得无限困难，因为它甚至不知道你要问的是什么。你带着特定意图打开了 Now on Tap，但你发送给谷歌的查询是很不准确的“屏幕上的所有内容”。谷歌需要猜测你查询的内容然后试着基于它给出有用的结果或操作。

在这背后，谷歌可能在疯狂处理整个页面文字和图片来强行获得你想要的结果。但往往 Now on Tap 给出的结果像是页面每个合适的名词的搜索结果列表。从结果列表中筛选多个查询就像是陷入必应的“[搜索结果过载](https://www.youtube.com/watch?v=9yfMVbaehOE)”广告里那样的情形。查询目标的缺失让 Now on Tap 感觉像是让谷歌给你读心，而它永远做不到。谷歌最终给文本选中菜单打了补丁，添加了一个“助理”按钮，给 Now on Tap 提供一些它极度需要的搜索目标。

不得不说 Now on Tap 是个失败的产物。Now on Tap 的快捷方式——长按 home 键——基本上让它成为了一个隐藏，难以发现的特性，很容易就被遗忘了。我们推测这个特性的使用率非常低。即便用户发现了 Now on Tap，它经常没法读取你的想法，在几次尝试之后，大多数用户可能会选择放弃。

随着 2016 年 Google Pixels 的发布，谷歌似乎承认了失败。它把 Now on Tap 改名成了“屏幕搜索”并把它降级成了谷歌助手的支援。谷歌助理——谷歌的新语音命令系统——接管了 Now on Tap 的 home 键手势并将它关联到了语音系统激活后的二次手势。谷歌似乎还从 Now on Tap 差劲的可发现性中学到了教训。谷歌给助理给 home 键添加了一组带动画的彩点，帮助用户发现并记住这个特性。

#### 权限

安卓 6.0 终于引入了应用权限系统，让用户可以细粒度地控制应用可以访问的数据。

应用在安装的时候不再给你一份长长的权限列表。在棉花糖中，应用安装根本不询问任何权限。当应用需要一个权限的时候——比如访问你的位置、摄像头、麦克风，或联系人列表的时候——它们会在需要用到的时候询问。在你使用应用的时候，如果需要新权限时会弹出一个“允许或拒绝”的对话框。一些应用的设置流程这么处理：在启动的时候询问获取一些关键权限，其它的等到需要用到的时候再弹出提示。这样更好地与用户沟通了需要权限是为了做什么——应用需要摄像头权限，因为你刚刚点击了摄像头按钮。

除了及时的“允许或拒绝”对话框，棉花糖还添加了一个权限设置界面。这个复选框大列表让数据敏感用户可以浏览应用拥有的权限。他们不仅可以通过应用来查询，也可以通过权限来查询。举个例子，你可以查看所有拥有访问麦克风权限的应用。

谷歌试验应用权限已经有一段时间了，这些设置界面基本就是隐藏的“[App Ops](http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s-hidden-app-permission-manager-control-permissions-for-individual-apps/)”系统的重生，它是在安卓 4.3 中不小心引入并很快被移除的权限管理系统。

尽管谷歌在之前版本就试验过了，棉花糖的权限系统最大的不同是它代表了一个向权限系统的有序过渡。安卓 4.3 的 App Ops 从没有计划暴露给用户，所以开发者不了解它。在 4.3 中拒绝一个应用需要的一个权限经常导致奇怪的错误信息或一个彻底的崩溃。棉花糖的系统对开发者是缺省的——新的权限系统只适用于针对棉花糖 SDK 开发的应用，谷歌将它作为开发者已经为权限处理做好准备的信号。权限系统还允许在一项功能由于权限被拒绝无法正常工作时与用户进行沟通。应用会被告知它们的权限请求被拒绝，它们可以指导用户在需要该功能的时候去打开该权限访问。

#### 指纹 API

在棉花糖出现之前，少数厂商推出了他们自己的指纹解决方案以作为对[苹果的 Touch ID](http://arstechnica.com/apple/2014/09/ios-8-thoroughly-reviewed/10/#h3) 的回应。但在棉花糖中，谷歌终于带来了生态级别的指纹识别 API。新系统包含了指纹注册界面，指纹验证锁屏以及允许应用将内容保护在一个指纹扫描或锁屏验证之后的 API。

Play 商店是最先支持该 API 的应用之一。你可以使用你的指纹来购买应用，而不用输入你的密码。Nexus 5X 和 6P 是最先支持指纹 API 的手机，手机背面带有指纹读取硬件。

指纹 API 推出不久后时间，是罕见的安卓生态合作例子之一。所有带有指纹识别的手机都使用谷歌的 API，并且大多数银行和购物应用都很好地支持了它。

---

[Ron Amadeo](http://arstechnica.com/author/ronamadeo) / Ron 是 Ars Technica 的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。[@RonAmadeo](https://twitter.com/RonAmadeo)

---

via: <http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/31/>

作者：[RON AMADEO](http://arstechnica.com/author/ronamadeo) 译者：[alim0x](https://github.com/alim0x) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


Libral：一个提供资源和服务统一管理 API 的系统管理库

# Libral：一个提供资源和服务统一管理 API 的系统管理库

>
> Libral 为系统资源和服务提供了一个统一的管理 API ，其可以作为脚本管理任务和构建配置管理系统的坚实基础。
>
>
>

<img src="content_image/album_201707_22_123246fq1quubu19a93b1z.png" alt="An introduction to Libral, a systems management library for Linux" title="An introduction to Libral, a systems management library for Linux">

作为继承了 Unix 的传统的 Linux 操作系统，其并没有一个综合的系统管理 API 接口，相反，管理操作是通过多种特定用途的工具和 API 来实现的，其每一个都有自己约定和特有的风格。这就使得编写一个哪怕是简单的系统管理任务的脚本也很困难、很脆弱。

举个例子来说，改变 “app” 用户的登录 shell 要运行 `usermod -s /sbin/nologin app`。这个命令通常没有问题，只是当系统上没有 “app” 用户时就不行了。为了解决这个例外错误，具有创新精神的脚本编写者也许要这样写：

```
grep -q app /etc/passwd \
  && usermod -s /sbin/nologin app \
  || useradd ... -s /sbin/nologin app

```

这样，当 “app” 用户存在于系统中时，会执行更改登录 shell 的操作；而当此用户不存在时，就会创建此用户。不幸的是，这种编写系统管理任务脚本的方式是不适合的：对于每一种资源来说都会有一套不同的工具，而且每个都有其不同的使用惯例；不一致性和经常出现的不完备的错误报告将会使错误的处理变得困难；再者也会因为工具自身的特性引发的故障而导致执行失败。

实际上，以上所举的例子也是不正确的：`grep` 并不是用来查找 “app” 用户的，它只能在文件 `/etc/passwd` 的一些行中简单的查找是否有字符串 “app”，在大多数情况下它或许可以工作，但是也可能会在最关键的时刻出错。

很显然，那些执行简单任务的脚本管理工具，很难成为大型管理系统的基础。认识到这一点，现有的配置管理系统，比如 Puppet、Chef 及 Ansible，围绕基本的操作系统资源的管理竭尽全力的建立其内部 API 就是明智之举。这些资源抽象是内部 API，其与所需的相应工具密切相关。但这不仅导致大量的重复性工作，也为尝试一个新创新的管理工具设置了强大的障碍。

在创建虚拟机或者容器镜像这一领域，这种障碍就变得非常明显：比如在创建镜像的过程中，就要么需要回答关于它们的简单问题，要么需要对其进行简单的更改才行。但是工具全都需要特别处理，那些所遇到的问题和更改需要用脚本逐个处理。因此，镜像构建要么依靠特定的脚本，要么需要使用（和安装）一个相当强大的配置管理系统。

[Libral](https://github.com/puppetlabs/libral) 将为管理工具和任务提供一个可靠的保证，通过对系统资源提供一个公用的管理 API，并使其可以通过命令行工具 `ralsh` 使用，它允许用户按照相同的方法查询和修改系统资源，并有可预见的错误报告。对以上的举例来说，可以通过命令 `ralsh -aq user app` 检查 “app” 用户是否存在；通过 `ralsh -aq package foo` 检查 “foo” 软件包是否已经安装；一般情况下，可以通过命令 `ralsh -aq TYPE NAME` 检查 ”NAME“ 是否是 ”TYPE“ 类型的资源。类似的，要创建或更改已存在的用户，可以运行：

```
ralsh user app home=/srv/app shell=/sbin/nologin

```

以及，要在文件 `/etc/hosts` 创建和修改条目，可以运行命令：

```
ralsh hostmyhost.example.com ip=10.0.0.1 \
  host_aliases=myhost,apphost

```

以这种方式运行，“ralsh” 的使用者事实上完全隔离在那两个命令内部的不同运行工作机制之外：第一个命令需要适当的调用命令 `useradd` 或者 `usermod`，而第二个需要在 `/etc/hosts` 文件中进行编辑。而对于该用户来说，他们似乎都采取同样的模型：“确保资源处于我所需要的状态。”

### 怎样获取和使用 Libral 呢？

Libral 可以在[这个 git 仓库](https://github.com/puppetlabs/libral)找到并下载。其核心是由 C++ 编写的，构建它的说明可以[在该仓库中](https://github.com/puppetlabs/libral#building-and-installation)找到，不过只是在你想要为 Libral 的 C++ 核心做贡献的时候才需要看它。Libral 的网站上包含了一个 [预构建的 tarball](http://download.augeas.net/libral/ralsh-latest.tgz)，可以用在任何使用 “glibc 2.12” 或者更高版本的 Linux 机器上。可以使用该 “tarball” 的内容进一步探究 ralsh ，以及开发新的提供者（provider），它使得 Libral 具备了管理新类型资源的能力。

在下载解压 tarball 后，在目录 `ral/bin` 下能找到 `ralsh` 命令。运行不需要任何参数的 `ralsh` 命令就会列举出来 Libral 的所有资源类型。利用 `--help` 选项可以打印输出关于 `ralsh` 的更多说明。

### 与配置管理系统的关系

知名的配置管理系统，如 Puppet、Chef 及 Ansible，解决了一些 Libral 所解决的同样的问题。将 Libral 与它们的区分开的主要是它们所做工作和 Libral 不同。配置管理系统被构建来处理跨大量节点管理各种事物的多样性和复杂性。而另一方面 Libral 旨在提供一个定义明确的低级别的系统管理 API ，独立于任何特定的工具，可用于各种各样的编程语言。

通过消除大型配置管理系统中包含的应用程序逻辑，Libral 从前面介绍里提及的简单的脚本任务，到作为构建复杂的管理应用的构建块，它在如何使用方面是非常灵活的。专注与这些基础层面也使其保持很小，目前不到 2.5 MB，这对于资源严重受限的环境，如容器和小型设备来说是一个重要考虑因素。

### Libral API

在过去的十年里，Libral API 是在实现配置管理系统的经验下指导设计的，虽然它并没有直接绑定到它们其中任何一个应用上，但它考虑到了这些问题，并规避了它们的缺点。

在 API 设计中四个重要的原则：

* 期望的状态
* 双向性
* 轻量级抽象
* 易于扩展

基于期望状态的管理 API，举个例子来说，用户表示当操作执行后希望系统看起来是什么状态，而不是怎样进入这个状态，这一点什么争议。双向性使得使用（读、写）相同的 API 成为可能，更重要的是，相同的资源可以抽象成读取现有状态和强制修改成这种状态。轻量级抽象行为确保能容易的学习 API 并能快速的使用；过去在管理 API 上的尝试过度加重了学习建模框架的使用者的负担，其中一个重要的因素是他们的接受力缺乏。

最后，它必须易于扩展 Libral 的管理功能，这样用户可以教给 Libral 如何管理新类型的资源。这很重要，因为人们也许要管理的资源可能很多（而且 Libral 需要在适当时间进行管理），再者，因为即使是完全成熟的 Libral 也总是存在达不到用户自定义的管理需求。

目前与 Libral API 进行交互的主要方式是通过 `ralsh` 命令行工具。它也提供了底层的 C++ API ，不过其仍处在不断的演变当中，主要的还是为简单的脚本任务做准备。该项目也提供了为 CRuby 提供语言绑定，其它语言也在陆续跟进。

未来 Libral 还将提供一个提供远程 API 的守护进程，它可以做为管理系统的基础服务，而不需要在管理节点上安装额外的代理。这一点，加上对 Libral 管理功能的定制能力，可以严格控制系统的哪些方面可以管理，哪些方面要避免干扰。

举个例子来说，一个仅限于管理用户和服务的 Libral 配置会避免干扰到在节点上安装的包。当前任何现有的配置管理系统都不可能控制以这种方式管理的内容；尤其是，需要对受控节点进行任意的 SSH 访问也会将该系统暴露不必要的意外和恶意干扰。

Libral API 的基础是由两个非常简单的操作构成的：“get” 用来检索当前资源的状态，“set” 用来设置当前资源的状态。理想化地实现是这样的，通过以下步骤：

```
provider.get(names) -> List[resource]
provider.set(List[update]) -> List[change]

```

“provider” 是要知道怎样管理的一种资源的对象，就像用户、服务、软件包等等，Libral API 提供了一种查找特定资源的<ruby> 管理器 <rp>  （ </rp> <rt>  provider </rt> <rp>  ） </rp></ruby>的方法。

“get” 操作能够接收资源名称列表（如用户名），然后产生一个资源列表，其本质来说是利用散列的方式列出每种资源的属性。这个列表必须包含所提供名称的资源，但是可以包含更多内容，因此一个简单的 “get” 的实现可以忽略名称并列出所有它知道的资源。

“set” 操作被用来设置所要求的状态，并接受一个更新列表。每个更新可以包含 “update.is”，其表示当前状态的资源，“update.should” 表示被资源所期望的状态。调用 “set” 方法将会让更新列表中所提到的资源成为 “update.should” 中指示的状态，并列出对每个资源所做的更改。

在 `ralsh` 下，利用 `ralsh user root` 能够重新获得 “root” 用户的当前状态；默认情况下，这个命令会产生一个用户可读的输出，就像 Puppet 中一样，但是 `ralsh` 支持 `--json` 选项，可以生成脚本可以使用的 JSON 输出。用户可读的输出是：

```
# ralsh user root
user::useradd { 'root':
  ensure  => 'present',
  comment => 'root',
  gid     => '0',
  groups  => ['root'],
  home    => '/root',
  shell   => '/bin/bash',
  uid     => '0',
}

```

类似的，用户也可以用下面的形式修改：

```
# ralsh user root comment='The superuser'
user::useradd { 'root':
  ensure  => 'present',
  comment => 'The superuser',
  gid     => '0',
  groups  => ['root'],
  home    => '/root',
  shell   => '/bin/bash',
  uid     => '0',
}
comment(root->The superuser)

```

`ralsh` 的输出列出了 “root” 用户的新状态和被改变的 `comment` 属性，以及修改了什么内容（在这种情形下单指 `comment` 属性）。下一秒运行相同的命令将产生同样的输出，但是不会提示修改，因为没有需要修改的内容。

### 编写<ruby> 管理器 <rp>  （ </rp> <rt>  provider </rt> <rp>  ） </rp></ruby>

为 `ralsh` 编写新的管理器（provider）<ruby> <rp>  （ </rp> <rt> </rt> <rp>  ） </rp></ruby>是很容易的，也花费不了多少工夫，但是这一步骤是至关重要的。正因为如此，`ralsh` 提供了大量的调用约定，使得可以根据管理器所能提供的能力而调整其实现复杂性成为可能。管理器可以使用遵循特定调用约定的外部脚本，也可以以 C++ 实现并内置到 Libral 里面。到目前为止，有三种调用约定：

* [simple](https://github.com/puppetlabs/libral/blob/master/examples/providers/python.prov) 调用约定是编写 shell 脚本用为管理器。
* [JSON](https://github.com/puppetlabs/libral/blob/master/doc/invoke-json.md) 调用约定意味着可以利用 Ruby 或者 Python 脚本语言编写管理器。
* [内部 C++ API[8](https://github.com/puppetlabs/libral/blob/master/doc/invoke-native.md) 可以被用来实现原生的管理器。

强烈建议使用 “simple” 或者 “JSON” 调用约定开始开发管理器。GitHub 上的 [simple.prov](https://github.com/puppetlabs/libral/blob/master/examples/providers/simple.prov) 文件包含了一个简单的 shell 管理器框架，应该很容易的替换为你自己的管理器。[python.prov](https://github.com/puppetlabs/libral/blob/master/examples/providers/python.prov) 文件包含了利用 Python编写的 JSON 管理器框架。

利用高级脚本语言编写的管理器存在一个问题是，对于这些语言，在当前运行 Libral 的系统上需要包含所有的支持库在内运行环境。在某些情况下，这不是一个障碍；举例子来说，基于 “yum” 的包管理的管理器需要 Python 被安装在当前的系统上，因为 “yum” 就是用 Python 开发的。

然而在很多时候，无法预期一种 Bourne shell（Bash）之外的设计语言能够安装到所有的管理系统上。通常，管理器的编写者需要一个更加强大的脚本编译环境是实际需要。然而事与愿违，绑定一个完整的 Ruby 或 Python 作为解释器来运行将会增加 Libral 的大小超出了实际使用环境对资源的限制。另一方面，通常选择 Lua 或者 JavaScript 作为可嵌入的脚本编辑语言是不适应这种环境的，因为大多数的管理器的编写者不熟悉他们，通常情况下需要做大量的工作才能满足系统管理的实际需求。

Libral 绑定了一个 [mruby](http://mruby.org/) 版本，一个小的、嵌入在 Ruby 的版本，提供给管理器的编写者一个稳定的基础以及功能强大的可实现的程序设计语言。mruby 是 Ruby 语言的一个完整实现，尽管其减少了大量的标准库支持。与 Libral 绑定的 mruby 包含了 Ruby 用于脚本编辑管理任务的大多数的重要标准库，其将基于管理器编写者的需求随着时间的推移得到加强。Libral 的 mruby 绑定了 API 适配器使编写管理器更适合 JSON 约定，比如它包含了简单的工具（如编译修改结构体文件的 [Augeas](http://augeas.net/)）来解决解析和输出 JSON 的约定。[mruby.prov](https://github.com/puppetlabs/libral/blob/master/examples/providers/mruby.prov) 文件包含了利用 mruby 编写的 JSON 管理器框架实例。

### 下一步工作

Libral 最关键的是下一步要使其增加广泛的可用性——从 [预编译的 tarball](http://download.augeas.net/libral/ralsh-latest.tgz) 对于开发管理器的起步和深入是一个不错的方法，但是 Libral 也需要打包到主流的发行版上，并在上面可以找到。同样的，Libral 强大的功能取决于它附带的管理器的集合，及需要被扩展覆盖一组核心管理功能。Libral 的网站上包含了[一个 todo 列表](https://github.com/puppetlabs/libral#todo-list)列出了管理器的最迫切需求。

现在有多种方法能够提高不同用途的 Libral 的可用性：从编写更多程序语言的绑定，举例来说，Python 或者 Go；到使 `ralsh` 更容易在 shell 脚本中使用，除了现有的可读输出和 JSON 输出之外，可以很轻松的在 shell 脚本中格式化输出。在大规模的管理中使用 Libral 也能够在增加上面讨论过的远程 API 而得到改良，Libral 利用像 SSH 这样的传输工具实现更好的支持批量安装要求为各种架构提供预编译的 tarball，并且脚本基于所发现的目标系统架构选择正确的包。

Libral 和它的 API、它的性能能够不断地进化发展；一个有趣的可能性是为 API 增加提醒能力，这样做可以向系统报告资源在超出它的范围发生的变化。Libral 面临的挑战是保持小型化、轻量级和良好定义的工具，来对抗不断增加的用例和管理性能——我希望每一个读者都能成为这个挑战之旅的一部分。

如果这让你很好奇，我很想听听你的想法，可以用拉取请求的方式，也可以是增强请求方式，亦或者报告你对 ralsh 体验经验。

（题图：[Internet Archive Book Images](https://www.flickr.com/photos/internetarchivebookimages/14803082483/in/photolist-oy6EG4-pZR3NZ-i6r3NW-e1tJSX-boBtf7-oeYc7U-o6jFKK-9jNtc3-idt2G9-i7NG1m-ouKjXe-owqviF-92xFBg-ow9e4s-gVVXJN-i1K8Pw-4jybMo-i1rsBr-ouo58Y-ouPRzz-8cGJHK-85Evdk-cru4Ly-rcDWiP-gnaC5B-pAFsuf-hRFPcZ-odvBMz-hRCE7b-mZN3Kt-odHU5a-73dpPp-hUaaAi-owvUMK-otbp7Q-ouySkB-hYAgmJ-owo4UZ-giHgqu-giHpNc-idd9uQ-osAhcf-7vxk63-7vwN65-fQejmk-pTcLgA-otZcmj-fj1aSX-hRzHQk-oyeZfR)，修改：Opensource.com. CC BY-SA 4.0）

---

作者简介：

David Lutterkort - 戴维是一个 Puppet 的软件工程师，他曾经参与的项目有 Direct Puppet 和最好的供给工具 Razor。他是 Puppet 最早的编著者之一，也是配置编辑工具 Augeas 的主要作者。

---

via: <https://opensource.com/article/17/5/intro-libral-systems-management-library-linux>

作者：[David Lutterkort](https://opensource.com/users/david-lutterkort) 译者：[stevenzdg988](https://github.com/stevenzdg988) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


Nylas Mail： 一个 Linux 的免费邮件客户端

Summary: Geary、Empathy、Evolution 和 Thunderbird 本身已经为很多用户提供了很好的服务，但是我发现了值得一试的东西：它被称为 Nylas Mail。

之前在arch里面，不能收取gmail就放弃了，改用chrome的checker plus for gmail

N1是今年（2017年）1月份推出的？

我怎么记得至少1年之前我就弃用过呢？

作者说的是Nylas Mail 是今年1月推出的，在那之前叫N1！

这么多年下来，用着最顺手的还是thunderbird。。

nice !!!

我已付费，但是后面还是没用起来，我每天要收5个不同邮箱发的邮件，Mac平台，这货算是我见过很漂亮的了，我就是冲着他的漂亮冲动的付了款，完后，收国外的有邮箱还行，国内有时候收不到，只能用回我的网页版收，不过，网易现在出mac版的，以前没有，所以，现在在用它

来自广东深圳的 Chrome Mobile 40.0|Android 7.0 用户

用thunderbird的路过

hnsncxy [Chrome Mobile 45.0|Android 5.1]

用不习惯！

geary　简单实用　　我用不惯太复杂的

# Nylas Mail： 一个 Linux 的免费邮件客户端

[](http://www.linuxandubuntu.com/home/nylas-mail-an-amazing-free-email-client-for-linux)

有一个经常被提及的问题是 Ubuntu 是否还应该提供默认的电子邮件客户端。就个人而言，我已经很长时间没有使用 [Thunderbird](http://www.linuxandubuntu.com/home/thunderbird-release-with-several-bug-fixes) 了。我相信这不是一个第一次被问到的问题，但我相信这是一个把它解决掉的很好机会。这是因为日常用户倾向于使用基于网络的客户端，例如 Gmail 或 Outlook 来满足其邮件需求。而对于 Linux 上的经验丰富的用户而言，还有很多可供选择的选项。[Geary](http://www.linuxandubuntu.com/home/geany-a-lightweight-ide-or-code-editor-for-programmers)、Empathy、Evolution 和 Thunderbird 本身已经为很多用户提供了很好的服务，但是我发现了值得一试的东西：它被称为 Nylas Mail。

它以前被称为 [Nylas N1](http://www.linuxandubuntu.com/home/nylas-n1-a-premium-email-client-for-linux)，Nylas Mail 于今年初在 1 月份推出，同时还发布了一个免费版本；**Nylas Mail** Basic 以前是一个付费版本。此外，在 1 月份，客户端仅适用于 Mac，但现在可用于 Linux 和 Windows 用户。

（在我写此文时，它还处于活跃开发状态，但是现在已经停止开发了。）

### 为什么使用 Nylas？

很多人因为种种原因选择了 Nylas Mail。让我们来看看一些常见的原因。

**简单** - Nylas Mail 客户端管理优雅简单。用 electron 构建，应用非常漂亮，易于使用。其设计还确保了在 Nylas 中设置电子邮件非常简单直接。

[](http://www.linuxandubuntu.com/uploads/2/1/1/5/21152474/nylas-mail-an-awesome-email-client-for-linux_orig.jpg)

**兼容性** - Nylas Mail 与所有电子邮件提供商兼容。它与 Gmail、Yahoo、Exchange 和 IMAP 帐户兼容，因此你可以在任何地方收到邮件。

[](http://www.linuxandubuntu.com/uploads/2/1/1/5/21152474/nylas-compatible-with-gmail-facebook-imap_orig.jpg)

**功能强大** - Nylas 拥有大量功能。它有一个全屏模式、离线支持、多布局格式、多帐户、统一的收件箱、提醒、打盹、签名和稍后发送功能。其中一些功能随 Nylas Mail Basic 一起提供。

[](http://www.linuxandubuntu.com/uploads/2/1/1/5/21152474/nylas-email-client-powerful-features_orig.jpg)

**混合后端** - 以前，Nylas 将邮件的一个副本同步到使用 Nylas 云的服务器中，这对许多人来说就像 mehn 一样。幸运的是，在最新版本中，Nylas 采用了一个混合后端，可直接连接到 Gmail 或 Outlook 等电子邮件提供商。云同步虽然仍然可用，但仅在使用高级订阅工具（如<ruby> 打盹 <rt>  snoozing </rt></ruby>和跟踪）时使用。缺点是它是一而二的。如果想要一些专业功能，你需要云同步；你不想用云同步，那你错过了这些功能。

[](http://www.linuxandubuntu.com/uploads/2/1/1/5/21152474/nylas-email-hybrid-backend_orig.jpg)

**开源和免费版** - Nylas 作为开源项目。这意味着你可以自己编写代码并自行构建。你甚至可以设置自己的服务器以回避问题。

[](http://www.linuxandubuntu.com/uploads/2/1/1/5/21152474/nylas-open-source-and-free-email-client_orig.jpg)

**跨平台** - Nylas 是在 Linux、Windows 和 Mac OS X 上提供的跨平台应用程序。因此，无论你喜欢哪种桌面操作系统，你都可以放心，因为 Nylas 都已经覆盖了。而且用法是相同的。

### 还要做些什么？

到目前为止，Nylas 邮件客户端很好，但有一些抱怨。首先是在 2016 年推出的付费选项。引入免费版本有点像是这个解决这个问题的方案，但事实上，一些功能只能以每月 $9 的价格使用让包括我在内的大部分人不快。此外，没有多少人喜欢将邮件的副本保存在某台服务器上。当然，你可以设置自己的服务器，但有些麻烦。最后，对于在后台运行的应用程序来说，它需要相当多的内存。我希望这不是因为它主要是用 electron 写的，我相信随着它的更新和改进，它会变得更好。

### 总结

**Nylas Mail** 在特性和功能方面对我来说非常棒，我相信你一定要用一下。作为一个电子邮件客户端，它是非常有效的，我真的很喜欢 Nylas Mail，并且一定会一直使用它。也许你应该也会。向开发人员的所做的工作致谢。你有其他的程序想让我们看下么？在下面的评论中指出，并分享你的想法和意见。

---

via: <http://www.linuxandubuntu.com/home/nylas-mail-an-amazing-free-email-client-for-linux>

作者：[linuxandubuntu](http://www.linuxandubuntu.com/home/nylas-mail-an-amazing-free-email-client-for-linux) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


拯救者 Linux：我是如何给我的团队引入 Linux 的

幸亏用的是 AIX，而不是 Windows，有问题的还是人，而不在于系统。

我想问题的原因显而易见：1998年时期的 AIX 系统比 Linux 要幼小的多，在多线程并发方面的研发尚算稚嫩。而且 IBM 是软硬通吃的，AIX 类似于服务器界的 macOS。如果放到现在的话情况要好多了。

AIX 最初发布于 86 年，在 98 年的是 4.x。

# 拯救者 Linux：我是如何给我的团队引入 Linux 的

>
> 在项目早期就遇到公开的失败后，一个著名大学的 IT 团队决定将他们的 web 注册系统部署到 Linux上，此举几乎将服务器的最大用户访问量提高了 3 倍
>
>
>

1998年，我在明尼苏达大学为一个新的 web 团队管理他们的服务器管理组。明尼苏达大学是一个非常大的大学，个个院校拥有接近 6000 名在校大学生。当时学校是用一个上了年纪的大型机系统来做学生的档案管理系统，这种系统已经过时了，所以需要做出改变。

这个系统不是 Y2K 类型的（LCTT 译注：保存年份时只用两位数，导致记录 2000 年时计算机会记录为 1900 年，详见 [What Does Y2K Compliant Mean?](https://stackoverflow.com/questions/18200744/what-does-y2k-compliant-mean)），所以我们准备建立一个由仁科软件公司来交付的新的学生档案管理系统。这个新系统对明尼苏达大学来说有很多作用，不仅能够管理学生的档案，还能提供其他的一些功能。然而它却缺少了一项关键特性：你不能在你的浏览器上通过 web 来给你的班级进行注册。

按照今天的标准来看，这是一个重大的疏忽，但是在上世纪九十年代，互联网还是一个新生概念。亚马逊才建立不久，ebay 刚创业一年，google 呱呱坠地，Wikipedia 还没有影儿。所以 1998 年仁科公司没有支持 web 在线注册课程这个功能也就不足为奇了。但是明尼苏达大学作为 Gopher 网络的发源地，并且给之前的大型机系统开发了一套 web 功能接口，我们觉得 web 在线注册功能对于这个新的学生档案管理系统是至关重要的。

我们在这个 web 团队的任务就是去实现此管理系统的 web 在线注册功能。

幸运的是，我们并不是孤军奋战。我们联系了 IBM ，在第二年一起开始来搭建这个新的 web 在线注册系统。IBM 负责提供硬件和软件环境来运行这个 web 系统：3 个运行最新的 AIX 系统（类 UNIX 操作系统）、IBM Java 和 IBM WebSphere 平台的 SP 电脑节点，并用一个 IBM 的负载均衡器来实现 3 个节点的负载分流。

在经过一年多的开发和测试后，我们的系统终于上线了！但不幸的是失败却接踵而至。

### 负载过大

在开发过程中，我们无法准确地模拟测试真实场景下许多学生同时登录的场景。原因不是没有测试环境，明尼苏达大学有定制的 web 负载测试软件包，而且 IBM 有自己的工具做补充，但是这个 web 系统在当时对我们来说实在是太陌生了，我们没有意识到这些测试工具是不能满足要求的。

通过数月的测试，我们将此 web 系统的预期负载量调整到 240 个并发用户。但不幸的是，我们实际的使用量却是预期的两倍左右，在第一天系统上线时，超过 400 名学生马上同时登录进系统，由于负载远远超出预期值，3 台 web 服务器直接宕机了。由于持续的高负载，服务器一直崩溃，只能不断地重启。一台刚重启完，另一台又宕机重启了，这种场景居然持续了一个月。

由于不能有效地通过 web 注册，学生只能通过原来的方法来注册：来到登记员的办公室，拿着笔注册，然后再出门。当地报纸也幸灾乐祸地嘲讽道："电脑软件的失败强迫学生只能面对面地注册！"

面对失败这个事实，我们尽自己全力在下一个开发周期中来提高软件性能，在之后 6 个月的时间里，我们疯狂地想去增强这套系统的负载能力。尽管增加了更多的代码，调整了多次配置，还是不能支持更多的用户。尽力了，然而面对的还是失败。

就如所料的，在下一个迭代周期后，迎接我们的还是失败。服务器由于负载问题一次又一次地宕机。这一次新闻标题已经变成了：“web 注册系统就是垃圾”。

在开始下一个为期 6 个月的迭代前，我们已经绝望了。没有人知道服务器不停宕机的原因，我们已经预期这个问题现在是无解的。我们是要采取一些措施来搞定这个问题，但是怎么做呢？以下是我们讨论得出的方法：

### 是否需要切换新的平台?

IBM 当时引入了 Linux，给它的 Java 和 WebSphere 平台做了二次开发。所有产品都获得了红帽公司的 RHEL 认证，并且有几个产品已经在我们的桌面系统上运行了。我们意识到了现在在 Linux 上已经有了完整的生态系统来运行我们的 web 管理系统，但是它能表现的比 AIX 更好吗？

在搭建好一个测试服务器并进行基本的负载测试后，我们惊奇的发现一台 Linux 服务器能够轻松地支持之前 3 台 AIX 服务器所不能支持的负载量，在相同的 web 代码、IBM Java 和 WebSphere 平台下，单台 Linux 服务器能够支持超过 200 个用户。

我们将这个消息告诉了登记员和 CIO，他们同意将 web 注册系统切换到 Linux 平台上。虽然这是我们第一次在明尼苏达大学跑 Linux，但是失败已成习惯，反而无所畏惧了。AIX 只会失败，Linux 却是我们唯一的希望。

我们马上基于 Linux 来进行开发。另一个组的同事也提供了几台 Intel 服务器来给我们使用，我们给服务器装上红帽系统和相关的 IBM 组件，然后在新系统上进行了持续性的负载测试，令人欣喜的是，Linux 服务器没有出现任何问题。

经过两个月高强度的开发测试，我们的新系统终于上线了，而且是巨大的成功！在巨大的负载下，web 注册系统在 Linux 的表现都堪称完美。同时在线峰值甚至超过了 600 名用户。Linux 拯救了明尼苏达大学的 web 注册系统~

### 成功的经验

当我回首这个项目时，我发现你可以用以下几个点来向你的团队介绍 Linux：

1、 **解决问题, 不要自欺欺人**

当我们提议在企业中使用 Linux 时，并不是因为我们认为 Linux 很酷才使用它。当然，我们是 Linux 的爱好者并且已经在自己的环境中运行过它，但是我们在公司是为了解决问题的。能用 Linux 是因为我们的登记员和出资人同意 Linux 是解决问题的一个方法，而不仅仅是因为 Linux很酷我们想用它。

2、 **尽可能小的去做改变**

我们的成功是建立在 IBM 已经基于 Linux 做出了它的 Java 和 WebSphere 产品的基础上的。这能让我们在将 web 系统从 AIX 切换到 Linux 上不用做过多的修改适配。两者比起来只有硬件和操作系统改变了，其他系统相关的组件都保持了一致，这些都是保证平台切换成功的基石。

3、 **诚实对待风险和回报**

我们的问题很明显：web 注册系统在前两个迭代周期中都失败了，而且很可能再次失败。当我们将自己的想法（AIX 切换到 Linux）告诉出资方后，我们对其中的风险和回报是心知肚明的。如果我们什么都不做，就只有失败，如果我们尝试切换到 Linux 平台，我们可能会成功，而且从最初的测试结果分析，成功的概率是高于失败的。

而且就算在 Linux 平台下项目还是失败了，我们也可以迅速地切换回 AIX 服务器。有了这些细致的分析和措施，终于使登记员能够安心让我们试试 Linux。

4、 **言简意赅地交流**

在项目平台切换的过程中，我们做了一个整体计划。我们在一张白纸上明确地写下了我们计划做什么，为什么要这么做。这种方式的成功关键就在于计划的简短性。领导们不喜欢像看小说一样来看技术性的主意，他们不想纠缠在技术细节中。所以我们有意地在执行层面上进行计划安排，在框架层面上进行描述。

当我们在进行平台切换时，我们会定期的告诉出资人当前进展。当新系统成功完成后，我们每天都会提交更新，报告已经有多少学生成功通过此系统完成注册和遇到的问题。

尽管这个项目已经过去了接近 20 年，但是其中的经验教训在今天仍然适用。尽管 Linux 在其中起了举足轻重的作用，但是最重要的还是我们成功地将所有人的目标引导到解决共同的问题上。我认为这种经验也可以运用到很多你所面对的事情当中。

---

作者简介：

Jim Hall -我是 FreeDOS 项目的发起者和协调人，我也在 GNOME 理事会中担任董事。工作上我是明尼苏达州拉姆西县的首席信息官，空闲时间里我为开源软件的可用性做出相关的贡献，并通过 [Outreachy](https://en.wikipedia.org/wiki/Outreachy)（为女性提供帮助的一项GNOME外展服务）来指导可用性测试。

via: <https://opensource.com/article/17/7/how-introduced-organization-linux>

作者：[Jim Hall](https://opensource.com/users/jim-hall) 译者：[吴霄/toyijiu](https://github.com/toyijiu) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


开发一个 Linux 调试器（四）：Elves 和 dwarves

Summary: 今天我们会详细介绍源码级的调试信息，作为本指南后面部分使用它的准备。

今天我们会详细介绍源码级的调试信息，作为本指南后面部分使用它的准备。

# 开发一个 Linux 调试器（四）：Elves 和 dwarves

<img src="content_image/album_201707_24_143821f1phescz20gc8thf.jpg" alt="" title="">

到目前为止，你已经偶尔听到了关于 dwarves、调试信息、一种无需解析就可以理解源码方式。今天我们会详细介绍源码级的调试信息，作为本指南后面部分使用它的准备。

### 系列文章索引

随着后面文章的发布，这些链接会逐渐生效。

1. [准备环境](/article-8626-1.html)
2. [断点](/article-8645-1.html)
3. [寄存器和内存](/article-8663-1.html)
4. [Elves 和 dwarves](https://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/)
5. [源码和信号](https://blog.tartanllama.xyz/c++/2017/04/24/writing-a-linux-debugger-source-signal/)
6. [源码级逐步执行](https://blog.tartanllama.xyz/c++/2017/05/06/writing-a-linux-debugger-dwarf-step/)
7. 源码级断点
8. 调用栈展开
9. 读取变量
10. 下一步

### ELF 和 DWARF 简介

ELF 和 DWARF 可能是两个你没有听说过，但可能大部分时间都在使用的组件。ELF（[Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format "Executable and Linkable Format")，可执行和可链接格式）是 Linux 系统中使用最广泛的目标文件格式；它指定了一种存储二进制文件的所有不同部分的方式，例如代码、静态数据、调试信息以及字符串。它还告诉加载器如何加载二进制文件并准备执行，其中包括说明二进制文件不同部分在内存中应该放置的地点，哪些位需要根据其它组件的位置固定（*重分配*）以及其它。在这些博文中我不会用太多篇幅介绍 ELF，但是如果你感兴趣的话，你可以查看[这个很好的信息图](https://github.com/corkami/pics/raw/master/binary/elf101/elf101-64.pdf)或[该标准](http://www.skyfree.org/linux/references/ELF_Format.pdf)。

[DWARF](https://en.wikipedia.org/wiki/DWARF "DWARF WIKI")是通常和 ELF 一起使用的调试信息格式。它不一定要绑定到 ELF，但它们两者是一起发展的，一起工作得很好。这种格式允许编译器告诉调试器最初的源代码如何和被执行的二进制文件相关联。这些信息分散到不同的 ELF 部分，每个部分都衔接有一份它自己的信息。下面不同部分的定义，信息取自这个稍有过时但非常重要的 [DWARF 调试格式简介](http://www.dwarfstd.org/doc/Debugging%20using%20DWARF-2012.pdf)：

* `.debug_abbrev` `.debug_info` 部分使用的缩略语
* `.debug_aranges` 内存地址和编译的映射
* `.debug_frame` 调用帧信息
* `.debug_info` 包括 <ruby> DWARF 信息条目 <rp>  （ </rp> <rt>  DWARF Information Entries </rt> <rp>  ） </rp></ruby>（DIEs）的核心 DWARF 数据
* `.debug_line` 行号程序
* `.debug_loc` 位置描述
* `.debug_macinfo` 宏描述
* `.debug_pubnames` 全局对象和函数查找表
* `.debug_pubtypes` 全局类型查找表
* `.debug_ranges` DIEs 的引用地址范围
* `.debug_str` `.debug_info` 使用的字符串列表
* `.debug_types` 类型描述

我们最关心的是 `.debug_line` 和 `.debug_info` 部分，让我们来看一个简单程序的 DWARF 信息。

```
int main() {
    long a = 3;
    long b = 2;
    long c = a + b;
    a = 4;
}

```

### DWARF 行表

如果你用 `-g` 选项编译这个程序，然后将结果传递给 `dwarfdump` 执行，在行号部分你应该可以看到类似这样的东西：

```
.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 0x0000000b):

            NS new statement, BB new basic block, ET end of text sequence
            PE prologue end, EB epilogue begin
            IS=val ISA number, DI=val discriminator value
<pc>        [lno,col] NS BB ET PE EB IS= DI= uri: "filepath"
0x00400670  [   1, 0] NS uri: "/home/simon/play/MiniDbg/examples/variable.cpp"
0x00400676  [   2,10] NS PE
0x0040067e  [   3,10] NS
0x00400686  [   4,14] NS
0x0040068a  [   4,16]
0x0040068e  [   4,10]
0x00400692  [   5, 7] NS
0x0040069a  [   6, 1] NS
0x0040069c  [   6, 1] NS ET

```

前面几行是一些如何理解 dump 的信息 - 主要的行号数据从以 `0x00400670` 开头的行开始。实际上这是一个代码内存地址到文件中行列号的映射。`NS` 表示地址标记一个新语句的开始，这通常用于设置断点或逐步执行。`PE` 表示函数序言（LCTT 译注：在汇编语言中，[function prologue](https://en.wikipedia.org/wiki/Function_prologue "function prologue") 是程序开始的几行代码，用于准备函数中用到的栈和寄存器）的结束，这对于设置函数断点非常有帮助。`ET` 表示转换单元的结束。信息实际上并不像这样编码；真正的编码是一种非常节省空间的排序程序，可以通过执行它来建立这些行信息。

那么，假设我们想在 `variable.cpp` 的第 4 行设置断点，我们该怎么做呢？我们查找和该文件对应的条目，然后查找对应的行条目，查找对应的地址，在那里设置一个断点。在我们的例子中，条目是：

```
0x00400686  [   4,14] NS
```

假设我们想在地址 `0x00400686` 处设置断点。如果你想尝试的话你可以在已经编写好的调试器上手动实现。

反过来也是如此。如果我们已经有了一个内存地址 - 例如说，一个程序计数器值 - 想找到它在源码中的位置，我们只需要从行表信息中查找最接近的映射地址并从中抓取行号。

### DWARF 调试信息

`.debug_info` 部分是 DWARF 的核心。它给我们关于我们程序中存在的类型、函数、变量、希望和梦想的信息。这部分的基本单元是 DWARF 信息条目（DWARF Information Entry），我们亲切地称之为 DIEs。一个 DIE 包括能告诉你正在展现什么样的源码级实体的标签，后面跟着一系列该实体的属性。这是我上面展示的简单事例程序的 `.debug_info` 部分：

```
.debug_info

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              clang version 3.9.1 (tags/RELEASE_391/final)
                    DW_AT_language              DW_LANG_C_plus_plus
                    DW_AT_name                  /super/secret/path/MiniDbg/examples/variable.cpp
                    DW_AT_stmt_list             0x00000000
                    DW_AT_comp_dir              /super/secret/path/MiniDbg/build
                    DW_AT_low_pc                0x00400670
                    DW_AT_high_pc               0x0040069c

LOCAL_SYMBOLS:
< 1><0x0000002e>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400670
                      DW_AT_high_pc               0x0040069c
                      DW_AT_frame_base            DW_OP_reg6
                      DW_AT_name                  main
                      DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                      DW_AT_decl_line             0x00000001
                      DW_AT_type                  <0x00000077>
                      DW_AT_external              yes(1)
< 2><0x0000004c>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -8
                        DW_AT_name                  a
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000002
                        DW_AT_type                  <0x0000007e>
< 2><0x0000005a>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -16
                        DW_AT_name                  b
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000003
                        DW_AT_type                  <0x0000007e>
< 2><0x00000068>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -24
                        DW_AT_name                  c
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000004
                        DW_AT_type                  <0x0000007e>
< 1><0x00000077>    DW_TAG_base_type
                      DW_AT_name                  int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000004
< 1><0x0000007e>    DW_TAG_base_type
                      DW_AT_name                  long int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000008

```

第一个 DIE 表示一个编译单元（CU），实际上是一个包括了所有 `#includes` 和类似语句的源文件。下面是带含义注释的属性：

```
DW_AT_producer   clang version 3.9.1 (tags/RELEASE_391/final)    <-- 产生该二进制文件的编译器
DW_AT_language   DW_LANG_C_plus_plus                             <-- 原编程语言
DW_AT_name       /super/secret/path/MiniDbg/examples/variable.cpp  <-- 该 CU 表示的文件名称
DW_AT_stmt_list  0x00000000                                      <-- 跟踪该 CU 的行表偏移
DW_AT_comp_dir   /super/secret/path/MiniDbg/build                  <-- 编译目录
DW_AT_low_pc     0x00400670                                      <-- 该 CU 的代码起始
DW_AT_high_pc    0x0040069c                                      <-- 该 CU 的代码结尾

```

其它的 DIEs 遵循类似的模式，你也很可能推测出不同属性的含义。

现在我们可以根据新学到的 DWARF 知识尝试和解决一些实际问题。

### 当前我在哪个函数？

假设我们有一个程序计数器值然后想找到当前我们在哪一个函数。一个解决该问题的简单算法：

```
for each compile unit:
    if the pc is between DW_AT_low_pc and DW_AT_high_pc:
        for each function in the compile unit:
            if the pc is between DW_AT_low_pc and DW_AT_high_pc:
                return function information

```

这对于很多目的都有效，但如果有成员函数或者内联（inline），就会变得更加复杂。假如有内联，一旦我们找到其范围包括我们的程序计数器（PC）的函数，我们需要递归遍历该 DIE 的所有孩子检查有没有内联函数能更好地匹配。在我的代码中，我不会为该调试器处理内联，但如果你想要的话你可以添加该功能。

### 如何在一个函数上设置断点？

再次说明，这取决于你是否想要支持成员函数、命名空间以及类似的东西。对于简单的函数你只需要迭代遍历不同编译单元中的函数直到你找到一个合适的名字。如果你的编译器能够填充 `.debug_pubnames` 部分，你可以更高效地做到这点。

一旦找到了函数，你可以在 `DW_AT_low_pc` 给定的内存地址设置一个断点。不过那会在函数序言处中断，但更合适的是在用户代码处中断。由于行表信息可以指定序言的结束的内存地址，你只需要在行表中查找 `DW_AT_low_pc` 的值，然后一直读取直到被标记为序言结束的条目。一些编译器不会输出这些信息，因此另一种方式是在该函数第二行条目指定的地址处设置断点。

假如我们想在我们示例程序中的 `main` 函数设置断点。我们查找名为 `main` 的函数，获取到它的 DIE：

```
< 1><0x0000002e>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400670
                      DW_AT_high_pc               0x0040069c
                      DW_AT_frame_base            DW_OP_reg6
                      DW_AT_name                  main
                      DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                      DW_AT_decl_line             0x00000001
                      DW_AT_type                  <0x00000077>
                      DW_AT_external              yes(1)

```

这告诉我们函数从 `0x00400670` 开始。如果我们在行表中查找这个，我们可以获得条目：

```
0x00400670  [   1, 0] NS uri: "/super/secret/path/MiniDbg/examples/variable.cpp"

```

我们希望跳过序言，因此我们再读取一个条目：

```
0x00400676  [   2,10] NS PE
```

Clang 在这个条目中包括了序言结束标记，因此我们知道在这里停止，然后在地址 `0x00400676` 处设一个断点。

### 我如何读取一个变量的内容？

读取变量可能非常复杂。它们是难以捉摸的东西，可能在整个函数中移动、保存在寄存器中、被放置于内存、被优化掉、隐藏在角落里，等等。幸运的是我们的简单示例是真的很简单。如果我们想读取变量 `a` 的内容，我们需要看它的 `DW_AT_location` 属性：

```
DW_AT_location              DW_OP_fbreg -8

```

这告诉我们内容被保存在以栈帧基（base of the stack frame）偏移为 `-8` 的地方。为了找到栈帧基，我们查找所在函数的 `DW_AT_frame_base` 属性。

```
DW_AT_frame_base            DW_OP_reg6

```

从 [System V x86\_64 ABI](https://www.uclibc.org/docs/psABI-x86_64.pdf) 我们可以知道 `reg6` 在 x86 中是帧指针寄存器。现在我们读取帧指针的内容，从中减去 `8`，就找到了我们的变量。如果我们知道它具体是什么，我们还需要看它的类型：

```
< 2><0x0000004c>      DW_TAG_variable
                        DW_AT_name                  a
                        DW_AT_type                  <0x0000007e>

```

如果我们在调试信息中查找该类型，我们得到下面的 DIE：

```
< 1><0x0000007e>    DW_TAG_base_type
                      DW_AT_name                  long int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000008

```

这告诉我们该类型是 8 字节（64 位）有符号整型，因此我们可以继续并把这些字节解析为 `int64_t` 并向用户显示。

当然，类型可能比那要复杂得多，因为它们要能够表示类似 C++ 的类型，但是这能给你它们如何工作的基本认识。

再次回到帧基（frame base），Clang 可以通过帧指针寄存器跟踪帧基。最近版本的 GCC 倾向于使用 `DW_OP_call_frame_cfa`，它包括解析 `.eh_frame` ELF 部分，那是一个我不会去写的另外一篇完全不同的文章。如果你告诉 GCC 使用 DWARF 2 而不是最近的版本，它会倾向于输出位置列表，这更便于阅读：

```
DW_AT_frame_base            <loclist at offset 0x00000000 with 4 entries follows>
 low-off : 0x00000000 addr  0x00400696 high-off  0x00000001 addr 0x00400697>DW_OP_breg7+8
 low-off : 0x00000001 addr  0x00400697 high-off  0x00000004 addr 0x0040069a>DW_OP_breg7+16
 low-off : 0x00000004 addr  0x0040069a high-off  0x00000031 addr 0x004006c7>DW_OP_breg6+16
 low-off : 0x00000031 addr  0x004006c7 high-off  0x00000032 addr 0x004006c8>DW_OP_breg7+8

```

位置列表取决于程序计数器所处的位置给出不同的位置。这个例子告诉我们如果程序计数器是在 `DW_AT_low_pc` 偏移量为 `0x0` 的位置，那么帧基就在和寄存器 7 中保存的值偏移量为 8 的位置，如果它是在 `0x1` 和 `0x4` 之间，那么帧基就在和相同位置偏移量为 16 的位置，以此类推。

### 休息一会

这里有很多的信息需要你的大脑消化，但好消息是在后面的几篇文章中我们会用一个库替我们完成这些艰难的工作。理解概念仍然很有帮助，尤其是当出现错误或者你想支持一些你使用的 DWARF 库所没有实现的 DWARF 概念时。

如果你想了解更多关于 DWARF 的内容，那么你可以从[这里](http://dwarfstd.org/Download.php)获取其标准。在写这篇博客时，刚刚发布了 DWARF 5，但更普遍支持 DWARF 4。

---

via: <https://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/>

作者：[Simon Brand](https://www.twitter.com/TartanLlama) 译者：[ictlyh](https://github.com/ictlyh) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


Linus Torvalds 说：谈论技术创新是愚蠢的，闭上嘴把事情做好

Summary: 来自 Linux 内核首领的最佳生活提示。

大神不是我说你，拿好你的2千万，多做实事，多把版本号跳跳级，少乱说话，不要成为 IT 界的贝利。

大神你好，你有什么资格说linus，万一别人采访你闭口不谈直接让ta滚蛋

没毛病

jinga50334 [BlackBerry Browser|BlackBerry Tablet OS 2.1]

说得很对。

我是不赞成标题这种说法 创新极其重要 那1%的创新比300%的汗水都重要

来自辽宁本溪的 Chrome Mobile 59.0|Android 5.1 用户

能说啊，因为我有口。

很好

没有对所在专业的熟悉，何来的创新

创新也是在汗水的基础上的。

操作系统和应用APP不相同。

日常APP和游戏APP也不相同。

不同的场景有不同的需要。

操作系统要的稳定。游戏APP，没有好的创意，就没有销路。

脚踏实地才能有突破，空谈创新，还不如脚踏实地．

你快闭嘴吧！没Linus，你现在估计连饭碗都没有！我们感谢Linus，至少他的创新让这个世界有了Linux，让无数人有了饭碗！

Linus 只要没有违法, 他有嚣张的资本与资格.

他发表的看法, 是指在内核OS开发上,

并不代表适合指其它情形,

毕竟大家的情况不同, 也不能说他是错的, 这是他的看法, 而你无法完全了解他的情况.

所以，别人说的如果觉得可用的, 就收入脑袋中,

觉得没用的就没必要较真.

站在鄙视链顶端的男人

来自 Linux 内核首领的最佳生活提示。

# Linus Torvalds 说：谈论技术创新是愚蠢的，闭上嘴把事情做好

>
> 来自 Linux 内核首领的最佳生活提示。
>
>
>

<img src="content_image/album_201707_24_190251gpa8syj8aqs7aawp.jpg" alt="Linus Torvalds at Open Source Leadership Summit" title="Linus Torvalds at Open Source Leadership Summit">

**OSLS 报道：** Linus Torvalds 认为，技术行业的创新庆祝活动是沾沾自喜，自我陶醉和自私自利的。

他所使用的艺术化术语更为直率：“行业的创新如此之多都是胡说。” 他说：“人人创新——不要做这种‘不同思考’，这是无意义的，它们有百分之九十九只是工作而已。”

周三在加利福尼亚州召开的[开源领袖峰会（OSLS）](https://www.theregister.co.uk/2017/02/14/the_government_is_coming_for_your_code/)中，Linux 基金会执行总监 Jim Zemlin 采访了 Linus，讨论了他如何管理 Linux 内核的开发和他对工作的态度。

Torvalds 说：“所有的炒作都不是真正的工作，真正的工作是在细节之中。”

Torvalds 表示赞成这样一个观点，即成功的项目是 99％ 的汗水，百分之一的创新。

作为[开源 Linux 内核](https://www.kernel.org/)的创造者和仁慈独裁者，不用提还是 Git 分布式版本控制系统的发明者，Torvalds 已经证明他的方法产生了结果。Linux 对技术行业的影响已经不用再夸大了。Linux 是服务器的主要操作系统，几乎所有的高性能计算都运行在 Linux 上，而大多数移动设备和嵌入式设备都依赖于 Linux。

Linux 内核可能是 PC 时代最成功的技术协作项目。根据 Zemlin 的说法，内核贡献者自 2005 年以来总共增加了 13500 多个，其中每天大约增加 10000 行代码，移除 8000 行代码，修改 1500 到 1800 行代码，而且这一直在继续 —— 虽然不是一直以目前的速度 —— 但这已经超过了二十五年。

Torvalds 说：“我们已经这样做了 25 年，而且我们遇到的一个常见问题是人们彼此需要磨合。所以组织代码、组织代码流、[以及]组织我们的维护关系构成了我们的历史，最终那些痛点，我说的是代码争议，基本上消失了。”

Torvalds 解释说，该项目的结构使人们能够独立工作。他说：“我们已经能够真正模块化代码和开发模式，所以我们可以并行做很多事情。”

Torvalds 说，技术起着明显的作用，但流程至少是同样重要的。

Torvalds 说：“这是一个社会化项目。这是技术层面的东西，而技术是让人们能够就问题达成一致的东西，因为……它通常有非常明确的对和错。”

但是现在 Torvalds 并没有像 20 年前一样对每一个变化进行审查，而是依靠贡献者的社交网络。他说：“这是社交网络和信任，并且我们有一个非常强大的网络，这就是为什么我们可以有一千人参与到每个发布当中。”

对信任的重视解释了参与内核开发的困难，因为人们不可以登录、提交代码然后消失不见。Torvalds 说：“你要提交很多小的补丁直到维护者信任你才行，在这一点上，你不仅仅是一个提交补丁的人，而是成为信任网络的一部分。”

十年前，Torvalds 表示，他告诉其他内核贡献者，他希望有一个八周的发布时间表，而不是可能拖延几年的发布周期。内核开发人员设法将其发布周期减少到大约两个半月。从那时起，开发工作就一直很平稳。

Torvalds 说：“说我们的流程有多么好很无聊。对于我来说，所有真正紧张的时刻都是关于流程的，它们和代码无关，当代码不工作时，这实际上是令人高兴的……流程问题是很痛苦的。你永远不会想有流程问题……尤其是当人们开始彼此生气时。”

---

via: <http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/>

作者：[Thomas Claburn](http://www.theregister.co.uk/Author/3190) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


6 个学习 OpenStack 的新指南和教程

Summary: 云基础设施是一个非常需要的技能。如果你正在为你的云基础架构需求寻找开源解决方案，那么 OpenStack 就是其中之一。

# 6 个学习 OpenStack 的新指南和教程

>
> 想了解更多关于 OpenStack 的内容？这些免费资源可能只是你所需要的。
>
>
>

<img src="content_image/album_201707_25_001553ekf9k8it93racj8a.jpg" alt="" title="">

云基础设施是一个非常需要的技能。如果你正在为你的云基础架构需求寻找开源解决方案，那么 [OpenStack](https://opensource.com/resources/what-is-openstack) 就是其中之一。

OpenStack 是一个巨大的项目集合，为云服务的几乎每一个部分都提供了解决方案和集成。虽然这个巨大范围使得它成为一个强大的工具，但这也意味着可能很难跟上并了解整个项目，了解如何使用它们、如何自定义它们以及如何向其提供代码。

幸运的是，有很多选择可以帮助你。除了[官方项目文档](http://docs.openstack.org/)、纸质书籍和认证培训计划外，还有大量社区创造的优秀资源。我们每个月可以在 Opensource.com 上查看它在博客和其他网站上最近发布的指南和教程，这会给你启发。我们来看看这次我们发现了什么。

* 首先在本月的这一批中，我们有一篇来自 Antony Messerli 的指南，介绍如何通过 Ansible [设置 OpenStack 云](https://www.reversengineered.com/2016/05/09/setting-up-an-openstack-cloud-using-ansible/)。Messerli 将引导我们完成实验室环境中的配置以及在集群上运行 OpenStack 所需的 playbook，还有添加镜像、设置网络等的基础知识。如果你正在考虑使用 Ansible 安装 OpenStack 小型本地测试环境，这是一篇很好的文章。
* 接下来，你有没有想过 Neutron 网络如何在 OpenStack 中的工作的？应用程序中发生的事情如何对应于底层代码？Arie Bregman 在[这篇文章](http://abregman.com/2017/05/29/openstack-neutron-service-code-deep-dive/)中提供了一段 OpenStack Neutron 代码。你需要熟悉一般的网络原理，至少有一点 OpenStack 代码基础才能跟上。
* Gerrit是 OpenStack 使用的开源代码审查项目，用于管理上传的修补程序，并允许在将更改合并到主 OpenStack 代码库之前进行反馈和测试。对于那些习惯于不同的代码审查系统（或根本没有的），Gerrit 可能会有点混乱，尽管它具有很好的仪表板功能，因此你只能看到对你很重要的信息。Dougal Matthews 在[这篇文章](http://www.dougalmatthews.com/2017/May/19/how-i-gerrit/)中带我们看了他的 Gerrit 仪表板设置，这可能会帮助你设置自己的。
* 上个月在波士顿举办的 OpenStack 峰会的[视频](https://www.openstack.org/videos/)已经发布了，无论你是否参加过上个月的活动，这都包含了技术和非技术专题的宝库。不知道从哪里开始？这有个来自 Julio Villarreal Pelegrino 关于如何规划、构建、运行一个成功的 OpenStack 云计算的[演讲](http://www.juliosblog.com/dont-fail-at-scale-how-to-plan-for-build-and-operate-a-successful-openstack-cloud-video-openstack-summit2017/)。
* 任何云管理员都应该担心安全问题。但你从哪里开始？Naveen Joy 发布了一个很好的十个安全问题的[清单](https://blogs.cisco.com/cloud/securing-openstack-networking)，用于加固你的 OpenStack 网络；你可以在上个月的同一主题演讲中查看[这个视频](https://www.openstack.org/videos/boston-2017/securing-openstack-networking)。
* OpenStack 中的内部消息服务在一个公共库中进行管理，该库存在于一个称为 Oslo 的项目中，自然它被称为 Oslo.Messenging。要了解这个库的基础知识，它在这个分为[两个](https://pigdogweb.wordpress.com/2017/05/22/intro-to-oslo-messaging/)[部分](https://pigdogweb.wordpress.com/2017/06/02/oslo-messaging-the-cloud-is-calling/)的博客中提到。

想要了解更多？可以从这三年来社区说提供的内容中找到我们完整的 [OpenStack 指南、如何做和教程](https://opensource.com/resources/openstack-tutorials)，以帮助你学习成为一名高效的 OpenStack 开发人员或管理员。

有很棒教程、指导或者如何做需要我们分享的么？在下面的评论中分享。

---

作者简介：

Jason Baker - Jason 热衷于使用技术使世界更加开放，从软件开发到阳光政府行动。Linux 桌面爱好者、地图/地理空间爱好者、树莓派工匠、数据分析和可视化极客、偶尔的码农、云本土主义者。在 Twitter 上关注他。

via: <https://opensource.com/article/17/6/openstack-guides-and-tutorials>

作者：[Jason Baker](https://opensource.com/users/jason-baker) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


教你如何比谷歌搜索更快速有效地利用 man

Summary: Linux 的帮助手册其实拥有很多有用的信息，而且比你想象中更容易使用

或许两个男人更合适。 man man<br />
如果还是不行，那可能需要一直找，直到第八个。 debug

nice

Linux 的帮助手册其实拥有很多有用的信息，而且比你想象中更容易使用

# 教你如何比谷歌搜索更快速有效地利用 man

>
> Linux 的帮助手册其实拥有很多有用的信息，而且比你想象中更容易使用
>
>
>

<img src="content_image/album_201707_25_005939nz9tlil3l5ofil54.jpg" alt="" title="">

我们通常通过 google 来查询 Linux 中的命令说明，但是其实还有一个更好的办法：那就是通过 Linux 自带的 **man 帮助页**来查询命令详尽完整的使用说明。

man 页面的历史本身比 Linux 还长，可以追溯到 Unix 早期那个年代。 通过[这个 Wikipedia](https://en.wikipedia.org/wiki/Man_page) 可以知道，Dennis Ritchie 和 Ken Thompson 在 1971 年写了第一个 man 帮助页，那个年代的计算器使用的还是像烤箱一样的计算机，个人电脑还未出世。man 帮助页也有它自己的一套设计精炼的语法，和 Unix 与 Linux 一样，man 帮助页也不是一成不变的，它就像 Linux 内核一样不停地发展更新。

Man 帮助页通过数字标识符来分成不同类型的内容：

1. 一般用户命令
2. 系统调用命令
3. 库函数
4. 特殊的文件和驱动程序
5. 文件格式
6. 游戏和屏保
7. 杂项
8. 系统管理命令和守护进程

尽管如此，用户一般也不需要知道他们想查询的命令是属于哪一个类型的。

这些文件格式化的方式在当今许多用户看来有点古怪。因为最开始他们是用 **trooff** 的方式，通过 PostScript 打印机来打印，所以包含了头部和布局方面的格式化信息。在 Linux 中，取而代之使用了一种叫做 [groff](https://en.wikipedia.org/wiki/Groff_(software)) 的方法。

在我的 Fedora 系统中，man 帮助页相关的文件存储在 `/usr/share/man` 下的子目录中（比如 `man1` 存储第一部分的命令），还有进一步的子目录用于存储 man 帮助页的翻译。

如果你在 Shell 中查找 `man` 命令的 man 帮助页，你时间看到将是 gzip 工具压缩的 `man.1.gz` 文件。想要查询 man 帮助页，需要输入类似如下命令：

```
man man

```

这个例子会显示 `man` 命令的 man 帮助页，这将先解压 man 帮助页文件，然后解释格式化指令并用 `less` 显示结果，所以导航操作和在 `less` 中一样。

所有的 man 帮助页都应该显示这些子段落：**Name**、 **Synopsis**、 **Description**、**Examples**、**See**、**Also**。有些还会添加一些额外的子段落，比如 **Options**、 **Exit**、**Status**、 **Environment**、**Bugs**、**Files**、**Author**、**Reporting**、**Bugs**、**History**、**Copyright**。

### 详细说明一个 man 帮助页

为了更详细地介绍一个典型的 man 帮助页，就用 ls 命令的帮助页来分析吧，在 **Name** 分段下，我们可以看到如下内容：

```
ls - list directory contents

```

它会简要地告诉我 `ls` 这条命令的作用.

在 `Synopsis` 分段下，我们可以看到如下的内容:

```
ls [OPTION]... [FILE]…

```

任何在中括号中的元素都是可选的。你可以只输入 `ls` 命令，后面不接任何参数。参数后面的省略号表示你可以添加任意多个彼此兼容的参数，以及许多文件名。对于 `[FILE]` 参数，你可以指定具体的目录名，或者可以使用通配符 `*`，比如这个例子，它会显示 `Documents` 文件夹下的 `.txt` 文件：

```
ls Documents/*.txt

```

在 **Description** 分段下, 我们可以看到关于这条命令更加详细的信息，还有关于这条命令各个参数作用的详细介绍的列表，比如说 `ls` 命令第一个选项 `-a` 参数，它的作用是显示包括隐藏文件/目录在内的所有文件：

```
-a, --all

```

如果我们想用这些参数，要么用它们的别名，比如 `-a`，要么用它们的全名，比如 `--all`（两条中划线）。然而并不是所有参数都有全名和别名（比如 `--author` 只有一种），而且两者的名字并不总是相互关联的（`-F` 和 `--classify`）。当你想用多个参数时，要么以空格隔开，要么共用一个连字符 `-`，在连字符后连续输入你需要的参数（不要添加空格）。比如下面两个等价的例子：

```
ls -a -d -l

```

```
ls -adl

```

但是 `tar` 这个命令有些例外，由于一些历史遗留原因，当参数使用别名时可以不用添加连字符 `-`，因此以下两种命令都是合法的：

```
tar -cvf filearchive.tar thisdirectory/

tar cvf filearchive.tar thisdirectory/

```

**ls** 的 **Description** 分段后是 **Author**、**Reporting Bugs**、**Copyright**、 **See Also** 等分段。

**See Also** 分段会提供一些相关的 man 帮助页，没事的话可以看看。毕竟除了命令外还有许多其他类型的 man 帮助页。

有一些命令不是系统命令，而是 Bash 特有的，比如 `alias` 和 `cd`。这些 Bash 特有的命令可以在 **BASH\_BUILTINS** man 帮助页中查看，和上面的比起来它们的描述更加精炼，不过内容都是类似的。

其实通过 man 帮助页让你可以获得大量有用的信息，特别是当你想用一个已经很久没用过的命令，需要复习下这条命令的作用时。这个时候 man 帮助页饱受非议的简洁性反而对你来说是更好的。

---

作者简介：

Greg Pittman - Greg 是住在肯塔基州路易斯维尔的一位退休神经学家，但是却对计算机和编程保持着长久的兴趣，从二十世纪六十年代就开始捣腾 Fortran IV 了。随着 Linux 和开源软件的到来，更加激起了他去学习的兴趣并投身于这项事业中，并成为 Scribus 组织的一员。

---

via: <https://opensource.com/article/17/7/using-man-pages>

作者：[Greg Pittman](https://opensource.com/users/greg-p) 译者：[吴霄/toyijiu](https://github.com/toyijiu) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


那些乌央乌央的、普普通通的 Ubuntu 用户们

Summary: “不要光挠自己的痒痒，也帮你女朋友解决一下啊！还有你的同事，以及那些你最喜欢的饭店的厨子们，还有你的医生。难道你不希望你的医生专注于医治病人，而是在 apt get 以及 grep 里心烦意乱？”

我确实挺cool

好用

ubuntu用户来了，推荐过，被拒绝

还真的不清楚到底哪个发行版用的人多，各家自己也没个统计数据

一直在用mint，确实好用

我虽然是个写程序代码的，但是我也开始慢慢不再太关心操作系统层面的东西了，我用win10和ubuntu，win10为了office，ubuntu为了rstudio，其他的只要系统能够稳定的工作就可以了，我的笔记本也6年了，运行良好……老实说，unity还是gnome都无所谓，只是unity已经用习惯了，换成gnome可能会有很多迁移的问题，这是我对将来18.04最大的担忧，我可能会去KDE，毕竟我曾经用过，而且用的很好……

我一直认为哪个系统自己用的舒服就用哪个，一个系统再cool再先进再NB自己用不顺手，对自己来说就没任何意义

mac用户路过，并向你扔了一个ubuntu

对于国内的新手，觉得deepin更友好一些！

Deepin 的+1

同感。前段时间试了下gnome，各种不爽，所以换成kde了。。kubuntu17.04，还不错。

fedora还是不错的

我不是一个重度依赖Linux的用户，出于兴趣尝试了各种版本。总的来说没有十全十美的版本，或多或少每个版本你都会遇到一丁点问题，有时候还难以解决，但换一个版本又很好解决了。就桌面来说，比较讨厌unity和现在的Gnome3，感觉体验简直是退步。Mint的cinnamon，还有mate、kde现在都不错。

有些专做给 unity 的 indicators 不能用了, 因在 gnome 显示会有问题

但可用 gnome shell extensions 取代, 一般小工具都可找到替代的,

所以就算 ubuntu 18.04 来临, 转用 Gnome 3 问题也不大

Gnome 3 简单, 比其它界面灵活度高, 想用什么就自己加 Gnome Shell Extensions

https://extensions.gnome.org

资源需求也低, 这是为啥那么多 Linux 分发版选择 Gnome 的原因

KDE Plasma 虽然也有 widgets 可用，

但做得不够好, 适用与实用的工具也很少.

https://store.kde.org/browse/cat/105/ord/latest/

有很多用户用了 Gnome 3,

可惜还是不知什么是 Gnome Shell Extensions

(其实就是 Gnome 上运行的 Java Script 小工具程序, 也就是插件)

http://jasonmun.blogspot.my/2017/05/gnome-shell-extension-gnome-shell.html

自从转了kde，就没再换过

所以说只有我一个人注意到了题图是此方酱在打游戏么

来自内蒙古包头的 Chrome Mobile 40.0|Android 7.1 用户

# 那些乌央乌央的、普普通通的 Ubuntu 用户们

>
> “更好的捕鼠器“ 并不是一个合格生物学家的专用谚语。就像 Ubuntu，它只需要好好工作，而不会让我惊着。
>
>
>

（LCTT 译注，“做个更好的捕鼠器”是个国外的谚语，意指不断有人发明更好的捕鼠器，然而其实没什么大的意义。）

### Roblimo 的藏身处

我从来就不是一个计算机极客。事实上，我在网上第一次小有名气是为 Time/Life 写一个每周专栏的时候，这个专栏的名字是“这台老电脑”。它介绍的是一台古老的设备能够做什么——通常是在上面安装 Linux——在那之后，我又在Andover.net 上开设了一个相同的专栏，名字叫做“廉价计算”，是关于如何在这个世界省钱的——而其它那些大部分在线计算机专栏都是在让你花钱花到你没饭吃（LCTT 译者注：作者的意思是“我算是一股清流了”）。

据我所知的那些大部分的 Linux 的早期使用者，都痴迷于他们的电脑，还有那些让他们电脑有用的软件。他们乐于仔细研读源代码并且做出一点小小的修改。最关键的是，他们大多是学计算机的，或者是从事 IT 行业的。他们的计算机和计算机网络迷住了他们，就像他们本该那样似的。

我过去是（现在也是）一个作者，不是一个搞计算机的。于我而言，计算机一直都只是一个工具而已。我希望它们能够老老实实的听话，我让它们做啥就做啥，最多可以出一点点小毛病。我喜欢图形化界面，因为我记不住那么长的命令行来管理我的电脑和网络。当然，我能找到它们，也能输入它们，但是我可不想费劲。

在 Linux 这个圈子里，有那么一段时间用户很少。“你什么意思？你只是想要你的电脑去写点文章，或者最多添加点 HTML 么？”开发者和管理员这样询问道，好像所有除了编写代码之外的奉献者们都不如他们所贡献的。

但是尽管面临这些讥笑和嘲讽，我在一次又一次的宣讲和谈话中提出一个像这样的主题：“不要光挠自己的痒痒，也帮你女朋友解决一下啊！还有你的同事，以及那些你最喜欢的饭店的厨子们，还有你的医生。难道你不希望你的医生专注于医治病人，而是在 `apt get` 以及 `grep` 里心烦意乱？”

所以，是的，因为我希望能够更简单的使用 Linux，我是一个[早期的曼德拉草用户](https://linux.slashdot.org/story/00/11/02/2324224/mandrake-72-in-wal-mart-a-good-idea)，而现在，我是一个快乐的 Ubuntu 使用者。

为什么是 Ubuntu？你一定是在逗我？为什么不是呢？它是 Linux 发行版中的丰田凯美瑞（或者本田思域）！平凡而卓越。它是如此的流行，你可以在 IRC、LinuxQuestion 社区、 Ubuntu 自己的论坛，以及许许多多的地方得到帮助。

当然，使用 Debian 或者 Fedora 也是很酷的，还有 Mint 也是开箱即用又华丽万分。但是我依然感兴趣于写一些文章和添加一点点 HTML，以及在浏览器中随时看点什么、在 Google Docs 为一两个公司客气写点什么，随时接收我的邮件，用一张过去或者现在的图片做这做那……基本上我就在电脑上干点这些。

当这一切都正常的时候，我的桌面是什么样子就没有意义了。我又看不见它！它整个被应用窗口覆盖了！然后我使用了两个显示器，不仅仅是一个。我有……让我数数，17 个标签页打开在两个 Chrome 窗口中。并且 GIMP 在运行中，[Bluefish](http://bluefish.openoffice.nl/index.html)，这个我刚才在使用的东西，用来书写这篇文章。

所以对我而言，Ubuntu 是我的阻力最小的道路。Mint 或许比较可爱，但是当你使用它的时候去掉它的那些边边角角的修饰，它不就是 Ubuntu 吗？所以如果我是用一个个相同的程序，并且不能看见桌面环境，所以谁还在意它长什么样子？

有些研究表明 Mint 正在变得更加流行，而有些人说 Debian 更甚。但是在他们的研究中，Ubuntu 永远都是居于最上位的，尽管这一年又一年过去了。

所以称我为大多数人吧！说我乏味吧！称我为乌央乌央的、普普通通的 Ubuntu 用户吧——至少从现在开始……

---

作者简介：

Robin "Roblimo" Miller 是一个自由职业作者，并且是开源技术集团的前主编，该公司旗下有 SourceForge、 freshmeat、Linux.com、NewForge、ThinkGeek 以及 Slashdot，并且他直到最近依然在 Slashdot 担任视频编辑。虽然他现在基本上退休了，但他仍然兼任 Grid Dynamics 的社论顾问，而且（显然）在为 FOSS Force 在写文章。

---

via: <http://fossforce.com/2017/01/many-humble-ubuntu-users/>

作者：[Robin "Roblimo" Miller](http://www.roblimo.com/) 译者：[svtter](https://github.com/svtter) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


开放组织公开追踪问题的好处

Summary: 在开放组织中，在线追踪问题可以将客户转变成伙伴。

在开放组织中，在线追踪问题可以将客户转变成伙伴。

# 开放组织公开追踪问题的好处

>
> 在开放组织中，在线追踪问题可以将客户转变成伙伴。
>
>
>

<img src="content_image/album_201707_25_222600rksw4zp98nswnvnk.jpg" alt="" title="">

一个公开的问题追踪器是开放组织的重要沟通工具，和在公开渠道中开展工作相比，没有比这种方式更[透明和包容](https://opensource.com/open-organization/resources/open-org-definition)的方式了。因此，让我们来探讨一下在开放组织中使用问题跟踪器的一些最佳实践。

在开始之前，我们先来定义“<ruby> 问题追踪器 <rt>  issue tracker </rt></ruby>”的含义。简单地说，问题跟踪器是**一个共享的待办事项列表**。想象一下一张胡乱写的待办事项列表：购买面包、邮件打包、归还图书馆书籍。当你在城里开车时，把列表上的每一项划掉的感觉很好。现在，将它扩展到你需要在组织中完成的工作，并增加合适的软件协作能力。这样你就有一个问题追踪器了！

无论你使用的是 GitHub 还是其他的，如 Bitbucket、GitLab 或 Trello，问题跟踪器都是与你的伙伴进行协调的正确工具。这对将外部人员*变成*伙伴是至关重要的，这是开放组织的特征之一。那么这是如何工作的？我很高兴你问了这个问题。

### 使用问题追踪器的最佳实践

使用公共问题跟踪器将外部人员转换为伙伴的最佳实践是基于过去五年来我们在 [Gratipay](https://gratipay.com/) 的经验。我们帮助公司和其他组织为开源买单，我们喜欢使用我们的问题跟踪器与我们的社区合作。这就是我们所学到的。

**0、 隐私优先。** 在这篇文章中谈论公共问题追踪器的隐私看上去是一个奇怪的开始。但是我们必须记住，[开放本身并不是目的](https://opensource.com/open-organization/16/9/openness-means-to-what-end)，任何真诚和真正的开放是建立在安全和认可的坚实基础之上的。不要公开发布客户或其他第三方私下给你的信息，除非你明确提出了要求并且得到了他们的明确同意。采纳一个隐私政策并培训你的人员。[这篇 Gratipay 的政策](http://inside.gratipay.com/howto/seek-consent)可供参考。好的！现在这部分清楚之后，让我们继续。

**1、 默认采用公开决策。** 如果你私下做决策，你就会失去运行一个开放组织的好处，比如表达多样化的想法、招募有活力的人才、实现更大的责任感。即使你的全职员工是最初使用你的公共问题跟踪器的唯一员工，那也要这么做。 避免将你的公共问题追踪器视为二等公民。如果你在办公室进行对话，请在公共问题跟踪器上发布摘要，并在最终决策之前给你的社区留出时间来响应。这是使用问题跟踪器解锁你组织开放权力的第一步：如果它不在问题追踪器中，那就没用！

**2、 关联其他工具。** 我们许多人都喜欢 IRC 和 Slack，这并不是什么秘密。或者你的组织已经使用 Trello，但是你也想开始使用 GitHub。这没问题！在 GitHub issue 中放入 Trello 卡片的链接很容易，反之亦然。交叉关联保证了被一个或另一个问题困住的外部人员能够发现帮助它们充分理解这个问题的更多相关信息。对于聊天服务，你可能需要配置公共日志记录才能维护关联（隐私注意事项：当你这么做时，请务必在你的频道描述中宣传该事实）。也就是说，你应该在私人 Slack 或其他私人渠道中对话，就像在办公室里面对面的对话一样。换句话说，一定要总结公众问题跟踪器上的对话。看看上面说的：无论离线或在线，如果不在问题跟踪器中，那就没用！

**3、 将谈话导向追踪器中。** 社交媒体很快就能获得很多反馈，尤其是发现问题，但这不是解决问题的地方。问题跟踪器为深入的对话和分析根本原因留出了空间。更重要的是，它们是为了完成任务而优化的，而不是无限拖延。当问题解决后点击“关闭”按钮的感觉真的很好！现在将公共问题跟踪器作为你的主要工作场所，你可以开始邀请在社交媒体上与你接触的外部人员在追踪器中进一步地讨论。简单的如，“感谢您的反馈！听起来像是（某个公共问题的链接）？” ，这可以在很大程度上向外界传达你的组织没有隐藏的内容，并欢迎他们的参与。

**4、 设置一个“元”追踪器。** 在一开始，你的问题追踪器很自然聚焦在*具体产品*上。当你准备好开放到一个新的水平时，考虑设置一个关于你的*组织*本身的问题跟踪。在 Gratipay，我们有一个称之为 “Inside Gratipay”的公共问题追踪器，我们愿意在其中讨论我们组织的任何方面，从[我们的预算](https://github.com/gratipay/inside.gratipay.com/issues/928)到[我们的法律结构](https://github.com/gratipay/inside.gratipay.com/issues/72)到[我们的名字](https://github.com/gratipay/inside.gratipay.com/issues/73)。 是的，这有时有点混乱 —— 重命名组织是一个特别激烈的[争议话题](http://bikeshed.com/)！但对我们来说，在社区参与方面的好处是值得的。

**5、 将你的元追踪器用于加入过程。** 一旦你有一个元问题追踪器，就有了一个新的加入过程：邀请潜在的伙伴创建自己的入场券。如果他们以前从未使用过你的特定的问题追踪器，那么这将是他们学习的极好机会。注册帐号并提交问题应该很简单（如果不是，请考虑切换工具！）。这将让你的新伙伴尽早跨过门槛，开始分享参与感，并在组织内部拥有一席之地。当然，没有问题是愚蠢的，尤其是在某个人的入场券中更是如此。这是你的新伙伴熟悉组织工作方式时询问任何问题的地方。你需要确保快速回复他们的问题，让他们参与并帮助他们融入你的组织。这也是一个很好的方法来记录你最终授予这个人的各种系统的访问权限。至关重要的是，这可以[在雇佣他们之前](https://opensource.com/open-organization/16/5/employees-let-them-hire-themselves)开始。

**6、 雷达项目。** 大多数问题跟踪器包括一些组织和排序任务的方法。例如，GitHub 有[里程碑](https://help.github.com/articles/creating-and-editing-milestones-for-issues-and-pull-requests/)和[项目](https://help.github.com/articles/about-projects/)。这些通常旨在使组织成员的工作重点相一致。在 Gratipay，我们发现使用这些工具可以帮助协作者拥有并排序各自的工作重点。与其它的问题跟踪器通常提供的将问题分配给特定个人的做法不同，我们发现这一点提供了不同的价值。 我可能会关心别人正在积极工作的问题，或者我可能有兴趣开始某些事情，但别人先提出来我也很高兴。拥有自己的项目空间来组织我对该组织的工作的看法是与我的伙伴们沟通“我的雷达上有什么”的强大方式。

**7、 使用机器人自动化任务。** 最终，你可能会发现某些任务会一再出现。这表明自动化可以简化你的工作流程。在 Gratipay，我们[构建](https://github.com/gratipay/bot)了一个[机器人](https://github.com/gratipay-bot)帮助我们完成一些重复的任务。诚然，这是一个有点高级的用法。如果你达到了这一点，你能完全使用公共问题追踪器来开放你的组织！

如 Jim Whitehurst 所说 “吸引社区内外参与” ，这些是我们在 Gratipay 内使用我们的问题跟踪器的一些最有用的做法。也就是说，我们一直在学习。如果你有自己的经验分享，请发表评论！

---

作者简介：

Chad Whitacre - 我是 Gratipay 的创始人，Gratipay 是一个开放组织，致力于培育一个感恩、慷慨和爱的经济。我们帮助公司和其它组织为开源买单，以及赞助我们的平台。在线下，我居住在美国宾夕法尼亚州匹兹堡，在线上，我活跃在 GitHub。

---

via: <https://opensource.com/open-organization/17/2/tracking-issues-publicly>

作者：[Chad Whitacre](https://opensource.com/users/whit537) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


安卓编年史（32）：安卓 6.0 棉花糖（2）

”如果不格式化的话，你没法取出存储卡  茶道  其它地方使用“此处有误

谢谢！

# 安卓编年史（32）：安卓 6.0 棉花糖（2）

#### 幕后变化

棉花糖对自棒棒糖引入的节电任务调度器 API 进行了扩展。任务调度器将应用后台进程从随意唤醒设备规整成一个有组织的系统。任务调度器基本上就是一个后台进程的交通警察。

在棉花糖中，谷歌还添加了一个 “Doze（休眠）”模式来在设备闲置的时候节约更多电量。如果设备静止不动，未接入电源，并且屏幕处于关闭状态，它会慢慢进入低功耗离线模式，锁定后台进程。在一段时间之后，网络连接会被禁用。唤醒会被锁定——应用会请求唤醒手机来运行后台进程——而它会被忽略。系统警报（不含用户设置的闹钟）以及[任务调度器](http://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/6/#h2)也会被关闭。

如果你曾经发现把设备设置为飞行模式，并且注意到电池续航延长了许多，Doze 就像是一个自动的飞行模式，在你手机不用的时候介入——它真的延长了电池续航。它对于整天或整夜放在桌子上的手机很有效，对于平板就更好了，因为它常常被遗忘在咖啡桌上。

唯一能把设备从 Doze 模式唤醒的来自谷歌云消息推送服务的“高优先级消息”。这是为信息服务准备的，所以即使设备处于休眠状态，也能够收取信息。

“应用待机”是另一项或多或少有用的节电特性，它在后台静默运行。这背后的逻辑很简单：如果你和应用停止交互一段时间，安卓就认为它是不重要的，并取消它访问网络和后台进程的权力。

对于应用待机而言，和一个应用“交互”意味着打开一个应用，开始一项前台服务，或者生成一条通知。任何其中的一条操作就会重置该应用的待机计时器。对于每种其它边界情况，谷歌在设置里添加了一个名字意味模糊的“电池优化”界面。用户可以在这里设置应用白名单让它免疫应用待机。至于开发者，他们在开发者设置中有个“不活跃应用”选项可以手动设置应用到待机状态来测试。

应用待机主要是自动禁用你不用的应用，这是个对抗垃圾应用或被遗忘的应用消耗电量的好方法。因为它是完全静默且后台自动执行的，它还能让新手也能拥有一部精心调教过的设备。

谷歌在过去几年尝试了很多应用备份方案，在棉花糖中它又[换了个方案](http://arstechnica.com/gadgets/2015/10/android-6-0-marshmallow-thoroughly-reviewed/6/#h2)。棉花糖的暴力应用备份系统的目标是保存整个应用数据文件夹到云端。这是可能的并且在技术上是可行的，但即便是谷歌自己的应用对它的支持都不怎么好。设置好一部新安卓手机依然是个大麻烦，要处理无数的登录和弹出教程。

到界面这里，棉花糖的备份系统使用了谷歌 Drive 应用。在谷歌 Drive 的设置中有一个“管理备份”界面，不仅会显示新备份系统的应用数据，还有谷歌过去几年尝试的其它应用备份方案的数据。

藏在设置里的还有一个新的“应用关联”功能，它可以将应用“链接”到网站。在应用关联出现之前，在全新安装的机器上打开一个谷歌地图链接通常会弹出一个“使用以下方式打开”的对话框，来获知你是想在浏览器还是在谷歌地图应用中打开这个链接。

这是个愚蠢的问题，因为你当然是想用应用而不是网站——这不就是你安装这个应用的原因嘛。应用关联让网站拥有者可以将他们的应用和网页相关联。如果用户安装了应用，安卓会跳过“使用以下方式打开”直接使用应用。要激活应用关联，开发者只需要在网站放一些安卓会识别的 json 代码。

应用关联对拥有指定客户端应用的站点来说很棒，比如谷歌地图、Instagram、Facebook。对于有 API 以及多种客户端的站点，比如 Twitter，应用关联界面让用户可以设置任意地址的默认关联应用。不过默认应用关联覆盖了百分之九十的用例，在新手机上大大减少了烦人的弹窗。

可选存储是棉花糖的最佳特性之一。它将 SD 卡从一个二级存储池转换成一个完美的合并存储方案。插入 SD 卡，将它格式化，然后你就有了更多的存储空间，而这是你从来没有想过的事情。

插入 SD 卡会弹出一条设置通知，用户可以选择将卡格式化成“外置”或“内置”存储。“内置”存储选项就是新的可选存储模式，它会将存储卡格式化为 ext4 文件系统。唯一的缺点？那就是存储卡和数据都被“锁定”到你的手机上了。如果不格式化的话，你没法取出存储卡插到其它地方使用。谷歌对于内置存储的使用场景判断就是一旦设置就不再更改。

如果你强行拔出了 SD 卡，安卓会尽它最大的努力处理好。它会弹出一条消息“建议最好将 SD 卡插回”和一个“忘记”这张卡的选项。当然“忘记”这张卡将会导致各种数据丢失，建议最好不要这么做。

不幸的是实际上可以使用可选存储的设备很长时间都没有出现。Nexus 设备不支持存储卡，所以为了测试我们插上了一个 U 盘作为我们的可选存储。OEM 厂商最初抵制这项功能，[LG 和三星](http://arstechnica.com/gadgets/2016/02/the-lg-g5-and-galaxy-s7-wont-support-android-6-0s-adoptable-storage/)都在他们 2016 年初的旗舰机上禁用了它。三星说“我们相信我们的用户需要 microSD 卡是用来在手机和其它设备之间转移数据的”，一旦卡被格式化成 ext4 这就不可能了。

谷歌的实现让用户可以在外置和内置存储选项之间选择。但 OEM 厂商完全拿掉了内置存储功能，不给用户选择的机会。高级用户们对此很不高兴，并且安卓定制组们很快就重启启用了可选存储。在 Galaxy S7 上，第三方定制组甚至在官方发布的[的前一天](http://www.androidpolice.com/2016/03/10/modaco-manages-to-get-adoptable-sd-card-storage-working-on-the-galaxy-s7-and-galaxy-s7-edge-no-root-required/)解除了三星的 SD 卡锁定。

#### 音量和通知

为了更简洁的设计，谷歌将通知优先级控制从音量弹窗中移除了。按下音量键会弹出一个单独的滑动条，对应当前音源控制，还有一个下拉按钮可以展开控制面板，显示所有的三个声音控制条：通知，媒体和闹钟。所有的通知优先级控制还在——它们现在在一个“勿扰模式”的快速设置方块中。

通知控制最有用的新功能之一是允许用户控制抬头通知——现在叫“预览”通知。这项功能让通知在屏幕顶部弹出，就像 iOS 那样。谷歌认为最重要的通知应该提升到高于你普通日常通知的地位。

但是，在棒棒糖中，这项特性引入的时候，谷歌糟糕地让开发者来决定他们的应用是否“重要”。毫无疑问，所有开发者都认为他的应用是世界上最重要的东西。所以尽管最初这项特性是为你亲密联系人的即时消息设计的，最后变成了被 Facebook 的点赞通知所操控。在棉花糖中，每个应用在通知设置都有一个“设置为优先”复选框，给了用户一把大锤来收拾不守规矩的应用。

---

[Ron Amadeo](http://arstechnica.com/author/ronamadeo) / Ron 是 Ars Technica 的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。[@RonAmadeo](https://twitter.com/RonAmadeo)

---

via: <http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/32/>

作者：[RON AMADEO](http://arstechnica.com/author/ronamadeo) 译者：[alim0x](https://github.com/alim0x) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


安卓编年史（33）：安卓 7.0 牛轧糖，Pixel 手机，以及未来

Summary: 见证这这些改变，我们可能正处在安卓历史上最不确定的点上。但在安卓最近的 2016 年 10 月活动前，安卓、Chrome OS以及谷歌 Play 的 SVP Hiroshi Lockheimer 说，他相信我们将来都会动情回顾这些最新的安卓更新。

这个系列文章暂告一段落啦？

没错，结束了！

# 安卓编年史（33）：安卓 7.0 牛轧糖，Pixel 手机，以及未来

#### 每月安全更新

在棉花糖发布的几个月前，安卓的“Stagefright”媒体服务器漏洞被披露给了公众，这个漏洞允许在旧版本安卓上远程执行代码。由于这个漏洞影响到了数十亿安卓设备，安卓受到了媒体广泛的批评。

谷歌则以开始一项月度安卓安全更新项目作为回应。每个月它都会收集 bug，修复它们，然后推送新代码给 AOSP 和 Nexus 设备。OEM 厂商——它们已经在更新的泥潭中挣扎（也许是因为不关心）——基本上就是被告知“面对现实”然后跟上步伐。每个其它的主流操作系统有经常的安全更新——这就是成为这么大的平台的代价。为了协调 OEM 厂商，谷歌让他们提前一个月可以获取到更新。30 天之后，发布安全公告并将更新推送给谷歌设备。

月度更新项目是在棉花糖发布的两个月前开始的，但在这个主要的系统更新中谷歌添加了一栏“安卓安全补丁程序级别”到关于手机界面中。这里没有使用晦涩难懂的版本号，就用了日期来表示。这让任何人都能轻松看懂手机系统过时了多久，是个很好的让动作缓慢的 OEM 厂商羞愧的方式。

文本选择菜单现在是个浮动工具条，会在你选择的时候在文本旁边弹出。这里也不止是常规的“剪切/复制/粘贴”命令。应用可以在工具栏上放置特殊选项，比如谷歌文档里的“添加链接”。

在标准的文本命令之后，一个省略号按钮会显示一个二级菜单，应用可以在这里给文本选择菜单添加额外的功能。使用新的“文本处理”API，直接给其它应用传递文本现在变得非常轻松。如果你装了谷歌翻译，在这个菜单上会显示一个“翻译”选项。谷歌搜索也在这个工具栏里为谷歌 Now on Tap 添加了一个“助理”选项。

棉花糖添加了一个隐藏的设置，叫做“系统界面调谐器”。这个部分包含了全方位的高级用户特性和试验性项目。要访问这个设置，你需要下拉通知中心，按住“设置”按钮几秒钟。设置齿轮会旋转，然后最终你会看到一条消息显示系统界面调谐器已解锁。一旦它被打开，你就可以在系统设置的底部，开发者选项附近找到它了。

在系统界面调谐器的第一部分，用户可以在快速设置面板添加自定义瓷片，这项特性后来被重制成了应用可以使用的 API。此时这项特性还很粗糙，基本就是允许用户在文本框里输入一条自定义命令。系统状态图标可以单独打开或关闭，所以如果你真的很讨厌知道你已经连接到另外无线网络，你可以把这个图标关闭。这里有一项受欢迎的电源显示新增特性，可以将电池电量百分比显示嵌入到电池图标中。还有个用来截屏的“演示”模式，它会将正常的状态栏替换成一个假的，干净的版本。

### 安卓 7.0 牛轧糖，Pixel 手机，以及未来

[安卓 7.0 牛轧糖](http://arstechnica.com/gadgets/2016/08/android-7-0-nougat-review-do-more-on-your-gigantic-smartphone/)和 [Pixel 手机](http://arstechnica.com/gadgets/2016/10/google-pixel-review-bland-pricey-but-still-best-android-phone/)几个月前刚刚发布，你可以读读我们对它们的完整评测。二者都有无数我们还没看到最终效果的特性和影响，所以我们暂且搁置，等它真正成为“历史”之后再进行评说。

牛轧糖为了 Daydream VR 对[图形和传感器](http://arstechnica.com/gadgets/2016/08/android-7-0-nougat-review-do-more-on-your-gigantic-smartphone/11/#h1)做出了很大的改动，Daydream VR 是谷歌即将来临的智能手机驱动 VR 体验，[我们已经尝试过了](http://arstechnica.com/gadgets/2016/10/daydream-vr-hands-on-googles-dumb-vr-headset-is-actually-very-clever/)但还没花时间写下点什么。从 Chrome OS 借鉴来了新的“无缝升级”功能，系统拥有两个系统分区，可以在你使用其中一个的时候，对另一个在后台进行静默升级。考虑到 Pixel 是这个功能的唯一首发设备，并且还没有收到更新，我们也不确定这个功能是什么样子的。

牛轧糖最有趣的新功能之一是改进的应用框架，它允许改变应用尺寸大小。这让谷歌可以在手机和平板上实现分屏，在安卓 TV 上实现画中画，以及一个神秘的浮动窗口模式。我们已经能够通过一些软件技巧来访问浮动窗口模式，但还没有看到谷歌在实际产品中使用它。难道它的目标是桌面计算？

安卓和 Chrome OS 则继续走在共同成长的道路上。安卓应用现在已经能够在一些 Chromebook 上[运行了](http://arstechnica.com/gadgets/2016/05/if-you-want-to-run-android-apps-on-chromebooks-youll-need-a-newer-model/)，给了这个“仅 Web”的系统 Play 商店以及一系列的应用生态。有传言称 Chrome OS 和安卓未来将会更加紧密结合成“[Andromeda](http://arstechnica.com/gadgets/2016/09/android-chrome-andromeda-merged-os-reportedly-coming-to-the-pixel-3/)”——一个“Android”和“Chrome”混合而成的词——它可能是一个融合的 Chrome/安卓系统的代号。

我们还没有看到 Pixel 手机会创造怎样的历史。谷歌最近发布了两部新旗舰机 Pixel 和 Pixel XL，加入了硬件竞争之中。谷歌之前和合作伙伴合作生产联名的 Nexus 手机，但 Pixel 产品线用的是“Google”品牌。谷歌声明这是一个完全的硬件 OEM，HTC 是合同制造商，就类似苹果把富士康作为合同制造商那样。

拥有自己的硬件改变了谷歌制造软件的方式。谷歌发布了“谷歌助理”作为未来版的“OK Google”语音命令系统。但助理是 Pixel 的独占特性，谷歌没有把它推送给所有安卓设备。谷歌对界面做了一些改变，一个定制版的“Pixel 启动器”主屏应用和一套新的系统界面，这些都是 Pixel 独占的。我们需要时间来见证未来功能点在“安卓”和“Pixel”之间的平衡。

见证这这些改变，我们可能正处在安卓历史上最不确定的点上。但在安卓最近的 2016 年 10 月活动前，安卓、Chrome OS以及谷歌 Play 的 SVP [Hiroshi Lockheimer](http://arstechnica.com/gadgets/2016/10/chatting-with-googles-hiroshi-lockheimer-about-pixel-android-oems-and-more/) 说，他相信我们将来都会动情回顾这些最新的安卓更新。Lockheimer 是现在谷歌事实上的软件统治者，他认为最新的更新会是自安卓八年前亮相以来最有意义的事件。尽管在发布会后他没有对这个观点进行详细阐述，但事实表明明年这时候我们*可能*都不会讨论安卓了——它可能已经是一个安卓/Chrome OS 结合体了！正如 2008 年以来那样，安卓历史的下一篇章一定会更加有趣。

---

[Ron Amadeo](http://arstechnica.com/author/ronamadeo) / Ron 是 Ars Technica 的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。[@RonAmadeo](https://twitter.com/RonAmadeo)

---

via: <http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/33/>

作者：[RON AMADEO](http://arstechnica.com/author/ronamadeo) 译者：[alim0x](https://github.com/alim0x) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


ss：查看网络连接的另一种方法

Summary: ss，它是 iproute2 包附带的另一个工具，允许你查询 socket 的有关统计信息。可以完成 netstat 同样的任务，但是，ss 稍微快一点而且命令更简短。

netstat 是 BSD 的项目 net-tools，已经不适合 Linux 了。要说不好，就是 ss 也是纳粹党卫军的缩写。

感觉可以哦昂

# ss：查看网络连接的另一种方法

<img src="content_image/album_201707_27_143650z3odo3rem3ndoeln.jpg" alt="" title="">

在之前的文章中，我提到过 `ss`，它是 iproute2 包附带的另一个工具，允许你查询 socket 的有关统计信息。可以完成 `netstat` 同样的任务，但是，`ss` 稍微快一点而且命令更简短。

直接输入 `ss`，默认会显示与 `netstat` 同样的内容，并且输入类似的参数可以获取你想要的类似输出。例如：

```
$ ss -t
State       Recv-Q Send-Q       Local Address:Port                        Peer Address:Port
ESTAB       0      0                127.0.0.1:postgresql                     127.0.0.1:48154
ESTAB       0      0            192.168.0.136:35296                      192.168.0.120:8009
ESTAB       0      0            192.168.0.136:47574                     173.194.74.189:https
[…]
```

`ss -t` 只显示 TCP 连接。`ss -u` 用于显示 UDP 连接，`-l` 参数只会显示监听的端口，而且可以进一步过滤到任何想要的信息。

我并没有测试所有可用参数，但是你甚至可以使用 `-K` 强制关闭 socket。

`ss` 真正耀眼的地方是其内置的过滤能力。让我们列出所有端口为 22（ssh）的连接：

```
$ ss state all sport = :ssh
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port
tcp   LISTEN     0      128                    *:ssh                                  *:*
tcp   ESTAB      0      0          192.168.0.136:ssh                      192.168.0.102:46540
tcp   LISTEN     0      128                   :::ssh                                 :::*
```

如果只想看已建立的 socket（排除了 *listening* 和 *closed* ）：

```
$ ss state connected sport = :ssh
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port
tcp   ESTAB      0      0          192.168.0.136:ssh                      192.168.0.102:46540
```

类似的，可以列出指定的 host 或者 ip 段。例如，列出到达 74.125.0.0/16 子网的连接，这个子网属于 Google：

```
$ ss state all dst 74.125.0.0/16
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port
tcp   ESTAB      0      0          192.168.0.136:33616                   74.125.142.189:https
tcp   ESTAB      0      0          192.168.0.136:42034                    74.125.70.189:https
tcp   ESTAB      0      0          192.168.0.136:57408                   74.125.202.189:https
```

`ss`与 iptables 的语法非常相同，如果已经熟悉了其语法，`ss` 非常容易上手。也可以安装 iproute2-doc 包， 通过 `/usr/share/doc/iproute2-doc/ss.html` 获得完整文档。

还不快试试! 你就可以知道它有多棒。无论如何，让我输入的字符越少我越高兴。

---

via: <https://insights.ubuntu.com/2017/07/25/ss-another-way-to-get-socket-statistics/>

作者：[Mathieu Trudel-Lapierre](https://insights.ubuntu.com/author/mathieu-trudel-lapierre/) 译者：[VicYu](https://vicyu.com) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


Neo4j 图数据库基础

Summary: 对于海量的各种非结构化信息来说，图数据库已经成为帮助收集、管理和搜索大量数据的技术。在本文中，我将向你展示图数据库的基础知识，帮助你快速了解概念模型。

# Neo4j 图数据库基础

>
> 在这个三篇系列文章的第一篇文章中，我们将学习<ruby> 图数据库 <rp>  （ </rp> <rt>  graph database </rt> <rp>  ） </rp></ruby>的基础知识，它支持了这地球上最大的一些数据池。
>
>
>

对于海量的各种非结构化信息来说，图数据库已经成为帮助收集、管理和搜索大量数据的技术。在这三篇系列文章中，我们将使用开源图数据库软件 [Neo4j](https://neo4j.com/) 来研究图数据库。

在本文中，我将向你展示图数据库的基础知识，帮助你快速了解概念模型。在第二篇中，我将向你展示如何启动 Neo4j 数据库，并使用内置的浏览器工具填充一些数据。而且，在本系列的最后一篇文章中，我们将探讨一些在开发工作中使用的 Neo4j 编程库。

掌握图数据库的概念模型是有用的，所以我们从那里开始。图数据库中只存储两种数据：<ruby> 节点 <rt>  node </rt></ruby>和<ruby> 边 <rt>  edge </rt></ruby>。

* **节点是实体：**诸如人物、发票、电影、书籍或其他具体事物。这些有些等同于关系数据库中的记录或行。
* **边名关系：**连接节点的概念、事件或事物。在关系数据库中，这些关系通常存储在具有链接字段的数据库行中。在图数据库中，它们本身就是有用的，是可以以其自己的权限搜索的对象。

节点和边都可以拥有可搜索的*属性*。例如，如果你的节点代表人，他们可能拥有名字、性别、出生日期、身高等属性。而边的属性可能描述了两个人之间的关系何时建立，见面的情况或关系的性质。

这是一个帮助你可视化的图表：

在这张图中，你知道 Jane Doe 有一个新的丈夫 John；一个女儿（来自她以前的夫妻关系）Mary Smith 和朋友 Robert 和 Rhonda Roe。Roes 有一个儿子 Ryan，他正在与 Mary Smith 约会。

看看它怎么工作？每个节点代表一个独立于其他节点的人。你需要找到关于*那个*人的一切都可以存储在节点的属性中。边描述了人们之间的关系，这与你在程序中需要的一样多。

关系是单向的，且不能是无向的，但这没有问题。由于数据库可以以相同的速度遍历两个方向，并且方向可以忽略，你只需要定义一次此关系。如果你的程序需要定向关系，则可以自由使用它们，但如果双向性是暗含的，则不需要。

另外需要注意的是，图数据库本质上是无 schema 的。这与关系数据库不同，关系数据库每行都有一组列表，并且添加新的字段会给开发和升级带来很多工作。

每个节点都可以拥有一个<ruby> 标签 <rt>  label </rt></ruby>；对于大多数程序你需要“输入”这个标签，是对典型的关系数据库中的表名的模拟。标签可以让你区分不同的节点类型。如果你需要添加新的标签或属性，修改程序来用它就行！

使用图数据库，你可以直接开始使用新的属性和标签，节点将在创建或编辑时获取它们。不需要转换东西；只需在你的代码中使用它们即可。在这里的例子中，你可以看到，我们知道 Jane 和 Mary 最喜欢的颜色和 Mary 的出生日期，但是别人没有（这些属性）。这个系统不需要知道它；用户可以在正常使用程序的过程中访问节点时为其添加信息（属性）。

作为一名开发人员，这是一个有用的特性。你可以将新的标签或属性添加到由节点处理的表单中并开始使用它，而不必进行数据库 schema 的修改。对于没有该属性的节点，将不显示任何内容。你可以使用任何一种类型的数据库来为表单进行编码，但是你可以放下在关系型数据库中要进行的许多后端工作了。

让我们添加一些新的信息：

这是一个新的节点类型，它代表一个位置，以及一些相关关系。现在我们看到 John Doe 出生在加利福尼亚州的 Petaluma，而他的妻子 Jane 则出生在德克萨斯州的 Grand Prairie。 他们现在住在得克萨斯州的赛普拉斯，因为 Jane 在附近的休斯顿工作。Ryan Roe 缺乏城市关系对数据库来说没有什么大不了的事情，我们*不知道*那些信息而已。当用户输入更多数据时，数据库可以轻松获取新数据并添加新数据，并根据需要创建新的节点和关系。

了解节点和边应该足以让你开始使用图形数据库。如果你像我一样，已经在考虑如何在一个图中重组你的程序。在本系列的下一篇文章中，我将向你展示如何安装 Neo4j、插入数据，并进行一些基本的搜索。

---

via: <https://opensource.com/article/17/7/fundamentals-graph-databases-neo4j>

作者：[Ruth Holloway](https://opensource.com/users/druthb) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


热烈祝贺！LCTT 第一位达成翻译 500 篇成就的译者 geekpi ！

默默顶一个

强势点赞！！！！！！！！

thank you guys

点赞！感谢！

辛苦了，大侠们，有了你们在下面挖井，我们菜鸟们才有水喝。辛苦了

这就是开源精神的真正体现啊！

谢谢贡献！

谢谢贡献

非常感谢！

膜拜大神，非常感谢！

谢谢啦～

good job. appreciate the contributions.

这必须支持啊，辛苦了！

资磁。。

感谢！

感谢

为一切美好，辛苦了。

十分感谢

支持

有积极打造各种轮子的 bestony 的 vizv

:D

# 热烈祝贺！LCTT 第一位达成翻译 500 篇成就的译者 geekpi ！

**今天，Linux 中国开源社区很高兴地宣布，我们旗下的翻译组织 LCTT 的译者 geekpi 在对社区持续贡献了 1371 天之后，胜利达成了 500 篇翻译的成就！**

Linux 中国发展至今，得到了社区各界的鼎力支持，其中支持我们走到今天的一大基础就是成立于 2013 年 9 月 10 日的 LCTT。在这将近四年间，LCTT 为 Linux 中国和开源世界贡献了近 3000 篇文章，其中不乏精心打造的诚意之作，也有颇多的文章值得再三回味品读。

这期间，涌现出了许许多多的贡献者，他们其中有年轻的学生，也有从业多年的专家；有从事嵌入式开发的，也有从事系统运维的；有从事互联网工作的，也有从事医疗行业的。几年来，LCTT 像个大家庭一样，来了很多朋友，也送走了一些兄弟；有因病故去的前选题负责人 DeadFire， 也有勇接重任挑起选题工作的 oska874；有默默承担起 LFS 主要翻译的 martin2011qi 和技术支持的 vizv，也有将漫画翻译推动上线的 bestony 和 GHLandy；有积极打造各种轮子的 bestony 和 vizv，也有默默持之以恒翻译的 geekpi。

今天，我要着重向大家介绍的就是这位 geekpi ！

据 geekpi 的 [LCTT 专页](https://linux.cn/lctt/geekpi)，他于 LCTT 成立一个月后加入了我们，并一直持续活动到今天。他极少出现在我们内部沟通的 QQ 群内，甚至，几乎没有人知道他的名字、年龄、样貌和职业，甚至，连我也只知道一个可以联系到他的快递地址而已。

在 LCTT 里，他是翻译贡献遥遥领先的第一译者，其翻译数量几乎是第二名的三倍、第三名的四倍，其翻译数量是第二名到第七名的总和，占到了 LCTT 翻译总量的 1/6！

*Top 10 of LCTT Translators*

可以说，在我们每年惯例制作的 LCTT 仓库活动的视频中，他是除了作为校对、发布的我和选题 oska874 之外活动最多的人。

让我们向这位默默奉献的译者 geekpi 致敬！或许，这种不为名，不为利，才是一种纯粹的开源贡献精神吧！

这是他的 LCTT 专页成就，请大家膜拜：

*geekpi's profile of LCTT*

最后，有志于加入我们 LCTT 的朋友，[请点此了解 LCTT](https://linux.cn/lctt/)。


在 Linux Mint 安装 Linux Kernel 4.12（稳定版）

Summary: Linus Torvalds 发布了 Linux 内核 4.12。你可以从这里直接下载相关的 deb 包来安装。或者，继续阅读本文，按下面的步骤安装新内核。

# 在 Linux Mint 安装 Linux Kernel 4.12（稳定版）

<img src="content_image/album_201707_27_230446qhytdigtz2t6kfn0.jpg" alt="" title="">

**Linus Torvalds** 发布了 **Linux 内核 4.12**。你可以从**[这里](https://mintguide.org/engine/dude/index/leech_out.php?a%3AaHR0cDovL2tlcm5lbC51YnVudHUuY29tL35rZXJuZWwtcHBhL21haW5saW5lL3Y0LjEyLw%3D%3D)**直接下载相关的 **deb** 包来安装。或者，继续阅读本文，按下面的步骤安装新内核。

**警告：Linux 内核是系统的关键元素。在某个硬件设备不正常工作时，可以尝试执行升级，新的内核可能会解决此问题。 但同样的，非必须地更新一个新的内核也可能导致不必要的回滚，例如，无网络连接， 没有声音，甚至是无法正常启动系统，所以安装一个新的内核，请正确认识风险。**

最简单的安装任意内核方法 - 在**Linux Mint** 使用 [UKUU](https://mintguide.org/tools/691-ukuu-ubuntu-kernel-upgrade-utility.html)。

```
TerminalShekin@mylinuxmintpc~$sudo apt-add-repository -y ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install ukuu

```

**提醒：所有的 Nvidia/AMD 电脑用户， 在安装内核之前，建议切换到 free 版本的驱动。**

**如果决定删除内核 4.12，**

1. 首先，重启计算机，选择 GRUB 菜单中的旧内核启动。系统引导完成之后，通过以下命令删除新的内核：
2. 然后，使用 [UKUU](https://mintguide.org/tools/691-ukuu-ubuntu-kernel-upgrade-utility.html) 程序，或者命令：`sudo apt purge linux-image-4.12-*`
3. 最后，更新 **GRUB** 或者 **[BURG](https://mintguide.org/effects/716-burg-graphical-bootloader-install-to-linux-mint.html)**：`sudo update-grub`

在启动 **GRUB** 的时候，选择**以前的 Linux 版本**即可回到以前版本的内核。

Good Luck!!!

---

via: <https://mintguide.org/system/798-install-linux-kernel-4-12-stable-on-linux-mint.html>

作者：[Shekin](https://mintguide.org/user/Shekin/) 译者：[VicYu](https://vicyu.com) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


漏洞修复八个月后，仍有超过七万台 memcached 服务器面临危险

# 漏洞修复八个月后，仍有超过七万台 memcached 服务器面临危险

<img src="content_image/album_201707_28_121131nhlbbn7byalcak6k.jpg" alt="" title="">

在开源缓存软件 memcached 修复了三个关键漏洞的八个月之后，仍有超过 70000 台未打补丁的缓存服务器直接暴露在互联网上。安全研究员警告说，黑客可能会在服务器上执行恶意代码或从其缓存中窃取潜在的敏感数据。

[memcached](https://memcached.org/) 是一个实现了高性能缓存服务的软件包，用于在内存中存储从数据库和 API 调用中获取的数据块。这有助于提高动态 Web 应用程序的响应速度，使其更加适合大型网站和大数据项目。

虽然 memcached 不是数据库的替代品，但它存储在内存中的数据包括了来自数据库查询的用户会话和其他敏感信息。因此，该服务器在设计上并不能直接暴露在互联网等不受信任的环境中，其最新的版本已经支持了基本身份验证。

去年 10 月份，memcached 的开发者修复了由 [思科 Talos 部门](https://www.talosintelligence.com/) 安全研究员发现并报告的三个远程代码执行漏洞（[CVE-2016-8704](https://www.talosintelligence.com/reports/TALOS-2016-0219/)、[CVE-2016-8705](https://www.talosintelligence.com/reports/TALOS-2016-0220/) 和 [CVE-2016-8706](https://www.talosintelligence.com/reports/TALOS-2016-0221/)）。所有这些漏洞都影响到了 memcached 用于存储和检索数据的二进制协议，其中一个漏洞出现在 [Simple Authentication and Security Layer](https://tools.ietf.org/html/rfc4422) （SASL）的实现中。

在去年 12 月到今年 1 月期间，成队的攻击者从数万个公开的数据库中擦除数据，这包括 MongoDB、CouchDB、Hadoop 和 Elasticsearch 集群。在很多情况下，攻击者勒索想要恢复数据的服务器管理员，然而没有任何证据表明他们的确对所删除的数据进行了复制。

Talos 的研究人员认为， memcached 服务器可能是下一个被攻击的目标，特别是在几个月前发现了漏洞之后。所以在二月份他们决定进行一系列的互联网扫描来确定潜在的攻击面。

扫描结果显示，大约有 108000 个 memcached 服务器直接暴露在互联网上，其中只有 24000 个服务器需要身份验证。如此多的服务器在没有身份验证的情况下可以公开访问已经足够糟糕，但是当他们对所提交的三个漏洞进行测试时，他们发现只有 200 台需要身份验证的服务器部署了 10 月的补丁，其它的所有服务器都可能通过 SASL 漏洞进行攻击。

总的来说，暴露于互联网上的 memcached 服务器有大约 80%，即 85000 个都没有对 10 月份的三个关键漏洞进行安全修复。

由于补丁的采用率不佳，Talos 的研究人员决定对所有这些服务器的 IP 地址进行 whois 查询，并向其所有者发送电子邮件通知。

本月初，研究人员决定再次进行扫描。他们发现，虽然有 28500 台服务器的 IP 地址与 2 月份时的地址不同，但仍然有 106000 台 memcached 服务器暴露在因特网上。

在这 106000 台服务器中，有大约 70%，即 73400 台服务器在 10 月份修复的三个漏洞的测试中仍然受到攻击。超过 18000 个已识别的服务器需要身份验证，其中 99% 的服务器仍然存在 SASL 漏洞。

即便是发送了成千上万封电子邮件进行通知，补丁的采用率也仅仅提高了 10%。

Talos 研究人员在周一的[博客](http://blog.talosintelligence.com/2017/07/memcached-patch-failure.html)中表示：“这些漏洞的严重程度不能被低估。这些漏洞可能会影响到小型和大型企业在互联网上部署的平台，随着最近大量的蠕虫利用漏洞进行攻击，应该为全世界的服务器管理员敲响警钟。如果这些漏洞没有修复，就可能被利用，对组织和业务造成严重的影响。”

这项工作的结论表明，许多网络应用程序的所有者在保护用户数据方面做得不好。首先，大量的 Memcached 服务器直接暴露在互联网上，其中大多数都没有使用身份验证。即使没有任何漏洞，这些服务器上缓存的数据也存在着安全风险。

其次，即使提供了关键漏洞的补丁，许多服务器管理员也不会及时地进行修复。

在这种情况下，看到 memcached 服务器像 MongoDB 数据库一样被大规模攻击也并不奇怪。

---

via: <https://thenewstack.io/70000-memcached-servers-can-hacked-using-eight-month-old-flaws/>

作者：[Lucian Constantin](https://thenewstack.io/author/lucian/) 译者：[firmianay](https://github.com/firmianay) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


Linux “天气预报”

Summary: 本页面是为了跟踪在不久的将来某个时间内有可能出现在主线内核和/或主要发行版中的 Linux 开发社区的进展情况。你的“首席气象学家”是 LWN.net 执行主编 Jonathan Corbet。

希望能报道Linux API Headers的变化

# Linux “天气预报”

<img src="content_image/album_201707_28_123643m3x536ztt153g0tk.jpg" alt="" title="">

### 欢迎来到 Linux 天气预报

本页面是为了跟踪在不久的将来某个时间内有可能出现在主线内核和/或主要发行版中的 Linux 开发社区的进展情况。你的“首席气象学家”是 [LWN.net](http://www.lwn.net/) 执行主编 Jonathan Corbet。如果你有改进预测的建议（特别是如果你有一个你认为应该跟踪的项目或修补程序的情况下），请在下面补充你的意见。

### 预测摘要

**当前情况**：内核 4.12 于 7 月 2 日发布。它包含了许多新功能，包括：

* [BFQ 和 Kyber 块 I/O 调度器](https://lwn.net/Articles/720675/)。已经开发多年的 BFQ 在交互式系统上表现更好，这引起了移动设备领域的兴趣。相反，Kyber 是一个更简单的调度程序，旨在用于通常出现在企业配置中的快速设备。
* epoll\_wait() 系统调用现在可以执行网络套接字的繁忙轮询。
* 实时修补机制已经实现了[混合一致性模型](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d83a7cb375eec21f04c83542395d08b2f6641da2)，这将可以把更复杂的补丁应用于运行中的内核。
* [可信执行框架](https://lwn.net/Articles/717125/)应该使得内核与在 ARM TrustZone 安全世界中运行的代码之间的交互更加容易。

4.12 是最繁忙的内核开发周期之一，合并了近 15000 次更新。有关这些变化来源的概述，请参阅[这里](https://lwn.net/Articles/726950/)。

**短期预测**：4.13 内核预期在 2017 年 9 月初发布。这个内核中会出现的一些变化是：

* 更好地支持非阻塞直接块 I/O 操作。
* [结构布局随机化机制](https://lwn.net/Articles/722293/)是正在进行的内核加固防攻击项目的下一步。
* 内核现在已经[原生支持 TLS 网络协议](https://lwn.net/Articles/666509/)。
* 采取[透明大页交换](https://lwn.net/Articles/717707/)，这使得有更好的内存管理性能。
* 块子系统中回写错误的处理[已经改进](https://lwn.net/Articles/724307/)，这使得错误不太可能不告知程序而写入数据。

4.13 内核现在处于稳定时期，所以在这个开发周期的剩余时间内只会接受修复补丁。

这篇[文章](http://purl.org/dc/elements/1.1/)根据[知识共享署名 - 共享 3.0 许可证](http://creativecommons.org/licenses/by-sa/3.0/)获得许可。

---

via: <https://www.linux.com/news/2017/7/linux-weather-forecast>

作者：[JONATHAN CORBET](https://www.linux.com/users/corbet) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


一年之后，React.js 许可协议再起争端

这个博客主题真是太难看了

这很不facebook

有很多公司都開始用轉用Vue

# 一年之后，React.js 许可协议再起争端

>
> 在 2016 年 7 月，Facebook 公司的 React.js 开源许可协议曾引起激烈争论。一年过后，该协议再次成为开源社区的头条新闻。
>
>
>

<img src="content_image/album_201707_28_210036ozbse4fr1y1sofrb.jpg" alt="" title="">

### 背景介绍

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库，起源于 Facebook 的内部项目，用来架设 Instagram 的网站。

* 2013 年 5 月，[Facebook 将 React.js 开源](https://code.facebook.com/projects/176988925806765/react/)。
* 2016 年 7月，React.js 开源许可协议中的附加专利条款引发争议。
* 2016 年 11 月，Facebook [发布官方问答](https://react-etc.net/entry/react-patents-facebook-license-faq-adoption-by-apple-and-microsoft)，对附加专利条款进行澄清。
* 2017 年 7 月，Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

### Apache 基金会的立场

2017 年 7 月，针对 Facebook 公司的 BSD 许可证 + 专利开源协议，Apache 基金会提出了如下建议：

1. 任何新项目、子项目或代码库都不允许使用遵循 Facebook 公司 “BSD 许可证 + 专利开源协议”的 jar 包。换句话说，如果你之前没有使用过，之后也不允许去使用。这种许可协议被 Apache 基金会列为 X 类别（Cat-X）。
2. 如果你一直在使用，并且在 **release** 中已经这么做了，那么在 2017 年 8 月 31 日之前，你将暂时从 X 类别中被排除。在此之后，任何和所有使用 Facebook 公司 “BSD 许可证+专利开源协议”的产品都将被 Apache 基金会禁止使用，你必须找到采用了合适许可证的替代品，或者放弃使用。这种情况没有例外。
3. 上述条款没有涵盖的任何其他情形也禁止使用。

X 类别被定义为“Apache 产品中可能不允许的许可证”，目前包括 GNU GPL、GNU LGPL、BCL、BSD-4-Clause 等许可证。有关[禁用许可证列表](https://www.apache.org/legal/resolved.html#category-x)可以在 Apache 基金会网站上[查询](https://www.apache.org/legal/resolved.html#category-x)。

### Facebook 的 “BSD 许可证 + 专利开源协议”

React 是一种流行的用于创建丰富用户界面的 JavaScript 技术，最初来源于 Facebook，并被广泛使用。该技术依据 BSD 许可证进行开源，但是，它的附加专利条款需要特别注意（以下为节选）。

>
> Facebook, Inc.（Facebook）特此授予软件的每个接收人（“你”）基于任何<ruby> “必要权利要求” <rp>  （ </rp> <rt>  Necessary Claims </rt> <rp>  ） </rp></ruby>的永久的、全球范围的、免版税的、非排他的、不可撤销的许可（遵守以下终止条款），可以制造、曾经制造、使用、销售、许诺销售、进口以及转移软件。
>
>
> 如果您（或任何您的子公司、关联方或代理商）直接或间接地启动了专利主张，或从专利主张中直接获取经济利益，本协议授予的许可将自动终止，恕不另行通知：（i）针对 Facebook 或其任何子公司或关联方；（ii）全部或部分来自于 Facebook 或其任何子公司或关联方的任何软件、技术、产品或服务的专利主张针对任何一方；或（iii）与软件相关的任何一方。尽管如此，如果 Facebook 或其任何子公司或关联方首先对你提起专利侵权诉讼指控，你在该诉讼中针对与软件无关的一方提起专利侵权反诉，你所被授予的许可不会因反诉而在本段第（i）款的规定下终止。
>
>
>

如果你的项目中正在使用或打算使用 React，你可能需要去咨询律师了。由于专利条款的限制，你不能做任何构成与 Facebook 竞争的事情。如果你采取法律行动或者以其他方式挑战 Facebook，那么你使用 React 的许可会被立即撤销。

如果你与其他使用 React 的公司发生法律纠纷，那你使用 React 的许可也会被撤销。Aurelia 框架创建者、Angular 2 开发团队前成员 [Rob Eisenberg 表示](https://react-etc.net/entry/rob-eisenberg-compares-angularjs-angular-2-aurelia-ember-polymer-and-react)，这就是 Google 公司和 Microsoft 公司的员工在工作中不允许使用 React.js 的原因。

虽然这只是在理论上对大多数采用 React 的项目可能产生的影响，但仍然值得特别注意，并且，类似 WordPress Calypso 这种已经与 React.js 建立了深刻联系的项目，可能会受到限制。运营 WordPress 的 Automattic 公司对一些小官司并不陌生，但这次很可能成为 Facebook 这个大公司的诉讼对象。

Drupal 和 WordPress 等许多开源产品都在采用 Facebook 公司的 React.js 技术。对于 Automattic 公司这种拥有开源产品的公司来说，未来如果被 Facebook 认定与 Facebook 构成竞争，将会是一个棘手的问题。

目前 Facebook 正如日中天，以上可能性发生的几率比较小，但如同 Yahoo 公司一样，Facebook 总有一天会从神坛跌落。到那时，Facebook 公司很有可能会从竞争角度充分利用许可协议所赋予的权利。所以，如果你打算利用 React.js 创建一个有可能终结 Facebook 神话的产品，最好先咨询你的律师。

但是，美国专利法非常复杂，尤其是在知识产权相关问题上，往往难以解释。从 Google 和 Oracle 公司有关安卓使用 Java 的争议可以看出，解决此类问题往往需要好几年时间。这意味着你必须要财大气粗，即使是你最后赢了官司。

### Facebook 公司的官方问答

React 的技术优势难以挑战。从开发者构建 web 用户界面方面来说，React 引发了一场变革。Facebook 在某些方面不太清楚的许可协议（BSD 许可证+专利）在开源开发者中间引发了激烈争论。开源社区继续坚持对“邪恶公司”的抵制，而 Facebook 很容易被归为此类公司。

2016 年 11 月，Facebook 澄清了其在 React、React Native 和其他许多项目中广泛采用的开源许可协议方面的立场。与任何法律文本一样，软件许可协议非常难以解释。Facebook 提供了一个 [FAQ](https://code.facebook.com/pages/850928938376556) 来回应经常被问到的问题。其中包括：

1. 如果我创建了一个竞争性产品，那么 Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权是否会被终止？
2. 如果我用专利侵权以外的理由起诉 Facebook，那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止？
3. 如果 Facebook 公司首先起诉我专利侵权，而我反诉 Facebook 公司专利侵权，那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止？
4. Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权的终止是否也会导致版权许可的终止？

对 1、2、4 的回答是明确的“**否**”，而对于第 3 个问题，FAQ 中规定，反诉主张不得与 Facebook 任何专利相关。上述官方说法比较可靠，在这个 Facebook 即便成为专利流氓也所获甚微的时刻，Facebook 仍然坚持其对 React 许可协议的看法。

### 使用 React.js 的开发者怎么办？

Apple 和 Microsoft 等行业巨头对于采用 React 的态度令人关注。有报道称，由于担心法律纠纷，这些巨头们已经禁止在项目中使用 React UI 库。但显然这是一个引发争议的问题，因为两家巨头都发布了使用 React 的网络资源或库。

Microsoft 提供了一个用于扩展 PowerPoint 和其他 Office365 产品的 React UI 组件库。Apple 开发者网站上的 API 文档采用 React.js 构建。

以上两款产品都不是两家公司的核心产品，Apple 也不太可能发布一款利用 React Native 编写的 iOS 邮件客户端。值得注意的是，虽然两家公司都看到了利用 React 创建 web 用户界面的价值，但它们的法律部门也没有因此遇到麻烦。

所以对大多数应用案例来说，似乎专利诉讼被严格限制在使用中的具体工具上，在这种情况下无需过分担心。由于使用了宽松的 BSD 许可证，对于开发者来说，React 实际上比使用传染性的 GPL 许可证的库更为安全。

Facebook 公司的数据库引擎 RocksDB 正准备[将许可证更改为 Apache 2.0](https://github.com/facebook/rocksdb/commit/3c327ac2d0fd50bbd82fe1f1af5de909dad769e6)。但 React.js 是一个特殊的项目，Facebook 公司似乎有意继续保留专利条款。

虽然商业实体很乐意在产品中使用 React 授权代码，尽管 WordPress 等许多受欢迎的开源项目仍将继续采用 React，但开源社区对 Facebook 不断捍卫和澄清这种特殊授权感到了厌倦。

因此，如果你想找到类似 [Solr](https://lucene.apache.org/solr/) 这种采用 React UI 的 Apache 项目，可能还需要很长时间。幸运的是，React 本身并非独一无二，你的项目可以采用与 React 类似的替代品，例如 [Preact](https://preactjs.com/) 或 [Inferno](https://infernojs.org/)，而不用担心遇到 React 的专利授权问题。

### 参考来源

* <https://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook>
* <https://react-etc.net/entry/react-patents-facebook-license-faq-adoption-by-apple-and-microsoft>
* <https://react-etc.net/entry/apache-foundation-bans-use-of-facebook-bsd-patents-licensed-libraries-like-react-js>
* <https://github.com/facebook/react/blob/master/PATENTS>

 （题图：facebook.github.io）

---

编译：

薛亮，北京集慧智佳知识产权管理咨询股份有限公司互联网事业部 高级咨询师，擅长专利检索，专利分析，竞争对手跟踪，FTO分析，开源软件知识产权风险分析，致力于为互联网企业，高科技公司提供知识产权咨询服务。


GPL 没落了吗？

主要是GPL可以绕过去了

发重了。

关键最大的GPL2支持者还有linux，所以不可能没落的

# GPL 没落了吗？

不久之前我看到了 RedMonk 的 Stephen O'Grady 发了一个[关于开源协议](https://twitter.com/sogrady/status/820001441733607424)的有趣的推特，那个推特里面有这张图。

这张图片显示了从 2010 到 2017 年间各种开源协议之间的使用率的变化。在这张图片里，显然 GPL 2.0 —— 最纯净的 copyleft 协议之一 —— 的使用率降低了一多半。该图表表明，开源项目中 [MIT](https://opensource.org/licenses/MIT) 协议和 [Apache](http://apache.org/licenses/) 协议开始受欢迎。[GPL 3.0](https://www.gnu.org/licenses/gpl-3.0.en.html) 的使用率也有所上涨。

这些意味着什么？

为什么 GPL 2.0 的使用率跌的这么多但是 GPL 3.0 仅仅是涨了一丁点？为什么 MIT 协议和 Apache 协议的使用率涨了那么多?

当然，有很多原因可以解释这件事情，但是我想这是因为商业开源项目的增多，以及商业社会对于 GPL 协议的担心导致的，我们细细掰扯。

### GPL 协议与商业社会

我知道我要说的可能会激怒一些 GPL 粉，所以在你们开始喷之前，我想说明的是：我支持 GPL，我也是 GPL 粉丝。

我写过的所有软件都使用的是 GPL 协议，我也是一直是积极出资支持 [自由软件基金会](http://www.fsf.org/) 以及 [软件自由保护组织](https://sfconservancy.org/) 以及他们的工作的，我支持使用 GPL 协议。我在这说的无关 GPL 的合法性或者 GPL 的巨大价值 —— 毫无疑问这是一个好协议 —— 我在这要说的是业内对于这个协议的看法。

大概四年之前，我参加了一个叫做<ruby> 开源智库 <rt>  Open Source Think Tank </rt></ruby>的峰会。这个峰会是一个私人小型峰会，每年都会把各大开源企业的管理人员请到加利福尼亚的酒庄。这个峰会聚焦于建立关系、构建联盟，找到并解决行业问题。

在这个峰会上，有一个分组研究，在其中，与会者被分成小组，被要求给一个真实存在的核心的开源技术推荐一个开源协议。每个小组都给出了回应。不到十分之一的小组推荐了宽容许可证，没有人推荐 GPL 许可证。

我看到了开源行业对于 Apache 协议以及 MIT 协议的逐步认可，但是他们却对花时间理解、接受和熟悉 GPL 这件事高高挂起。

在这几年里，这种趋势仍在蔓延。除了 Black Duck 的调查之外， 2015 年 [GitHub 上的开源协议调查](https://github.com/blog/1964-open-source-license-usage-on-github-com) 也显示 MIT 是人们的首选。我还能看到，在我工作的 XPRIZE （我们为我们的 [Global Learning XPRIZE](http://learning.xprize.org/) 选择了开源协议），在我作为[社区领导顾问](http://www.jonobacon.org/consulting)的工作方面，我也能感觉到那种倾向，因为越来越多的客户觉得把他们的代码用 GPL 发布不舒服。

随着 [大约 65% 的公司对开源事业做贡献](https://opensource.com/business/16/5/2016-future-open-source-survey) ，自从 2010 年以后显然开源行业已经引来了不少商业兴趣和投资。我相信，我之前说的那些趋势，已经表明这行业不认为 GPL 适合搞开源生意。

### 连接社区和公司

说真的，GPL 的没落不太让人吃惊，因为有如下原因。

首先，开源行业已经转型升级，它要在社区发展以及……你懂的……真正能赚钱的商业模型中做出均衡，这是它们要做的最重要的决策。在开源思想发展之初，人们有种误解说，“如果你搞出来了，他们就会用”，他们确实会来使用你的软件，但是在很多情况下，都是“如果你搞出来了，他们不是一定要给你钱。”

随着历史的进程，我们看到了许多公司，比如 Red Hat、Automattic、Docker、Canonical、Digital Ocean 等等等等，探索着在开源领域中赚钱的法子。他们探索过分发模式、服务模式，核心开源模式等等。现在可以确定的是，传统的商业软件赚钱的方式已经不再适用开源软件；因此，你得选择一个能够支持你的公司的经营方式的开源协议。在赚钱和免费提供你的技术之间找到平衡在很多情况下是很困难的一件事。

这就是我们看到那些变化的原因。尽管 GPL 是一个开源协议，但是它根本上是个自由软件协议，作为自由软件协议，它的管理以及支持是由自由软件基金会提供的。

我喜欢自由软件基金会的作品，但是他们已经把观点局限于软件必须 100% 绝对自由。对于自由软件基金会没有多少可以妥协的余地，甚至很多出名的开源项目（比如很多 Linux 发行版）仅仅是因为一丁点二进制固件就被认为是 “非自由” 软件。

对于商业来说，最复杂的是它不是非黑即白的，更多的时候是两者混合的灰色，很少有公司有自由软件基金会（或者类似的组织，比如软件自由保护组织）的那种纯粹的理念，因此我想那些公司也不喜欢选择和那些理念相关的协议。

我需要说明，我不是在这是说自由软件基金会以及类似的组织（比如软件自由保护组织）的错。他们有着打造完全自由的软件的目标，对于他们来说，走它们选择的路十分合理。自由软件基金会以及软件自由保护组织做了*了不起*的工作，我将继续支持这些组织以及为他们工作的人们。我只是觉得这种对纯粹性的高要求的一个后果就是让那些公司认为自己难以达到要求，因此，他们使用了非 GPL 的其他协议。

我怀疑 GPL 的使用是随着开源软件增长而变化的。在以前，启动（开源）项目的根本原因之一是对开放性和软件自由的伦理因素的严格关注。GPL 无疑是项目的自然选择，Debian、Ubuntu、Fedora 和 Linux 内核以及很多都是例子。

近年来，尽管我们已经看到了不再那么挑剔的一代开发者的出现，但是如果我说的过激一些，他们缺少对于自由的关注。对于他们来说开源软件是构建软件的务实、实用的一部分，而无关伦理。我想，这就是为什么我们发现 MIT 和 Apache 协议的流行的原因。

### 未来 ?

这对于 GPL 意味着什么？

我的猜想是 GPL 依然将是一个主要选项，但是开发者将将之视为纯粹的自由软件协议。我想对于软件的纯粹性有高要求的项目会优先选择 GPL 协议。但是对于商业软件，为了保持我们之前讨论过的那种平衡，他们不会那么做。我猜测， MIT 以及 Apache 依然会继续流行下去。

不管怎样，好消息是开源/自由软件行业确实在增长。无论使用的协议会发生怎样的变化，技术确实变得更加开放，可以接触，人人都能使用。

---

作者简介：

Jono Bacon - Jono Bacon 是一位领袖级的社区管理者、演讲者、作者和播客主。他是 Jono Bacon 咨询公司的创始人，提供社区战略和执行、开发者流程和其它的服务。他之前任职于 GitHub、Canonical 和 XPRIZE、OpenAdvantage 的社区总监，并为大量的组织提供咨询和顾问服务。

---

via: <https://opensource.com/article/17/2/decline-gpl>

作者：[Jono Bacon](https://opensource.com/users/jonobacon) 译者：[name1e5s](https://github.com/name1e5s) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


网络分析利器：在 Ubuntu 16.04 上安装 Bro

# 网络分析利器：在 Ubuntu 16.04 上安装 Bro

[<img src="content_image/album_201707_30_110852kjgkm5pkdygk5jep.jpg" alt="Bro Network Analysis Logo" title="brologo">](https://www.unixmen.com/wp-content/uploads/2017/07/brologo.jpg)

### 简介：Bro 网络分析框架

Bro 是一个开源的网络分析框架，侧重于网络安全监控。这是一项长达 15 年的研究成果，被各大学、研究实验室、超级计算机中心和许多开放科学界广泛使用。它主要由伯克利国际计算机科学研究所和伊利诺伊大学厄巴纳-香槟分校的国家超级计算机应用中心开发。

Bro 的功能包括：

* Bro 的脚本语言支持针对站点定制监控策略
* 针对高性能网络
* 分析器支持许多协议，可以在应用层面实现高级语义分析
* 它保留了其所监控的网络的丰富的应用层统计信息
* Bro 能够与其他应用程序接口实时地交换信息
* 它的日志全面地记录了一切信息，并提供网络活动的高级存档

本教程将介绍如何从源代码构建，并在 Ubuntu 16.04 服务器上安装 Bro。

### 准备工作

Bro 有许多依赖文件:

* Libpcap ([http://www.tcpdump.org](http://www.tcpdump.org/))
* OpenSSL 库 ([http://www.openssl.org](http://www.openssl.org/))
* BIND8 库
* Libz
* Bash (BroControl 所需要)
* Python 2.6+ (BroControl 所需要)

从源代码构建还需要：

* CMake 2.8+
* Make
* GCC 4.8+ or Clang 3.3+
* SWIG
* GNU Bison
* Flex
* Libpcap headers
* OpenSSL headers
* zlib headers

### 起步

首先，通过执行以下命令来安装所有必需的依赖项：

```
# apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev

```

#### 安装定位 IP 地理位置的 GeoIP 数据库

Bro 使用 GeoIP 的定位地理位置。安装 IPv4 和 IPv6 版本：

```
$ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
$wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz

```

解压这两个压缩包：

```
$ gzip -d GeoLiteCity.dat.gz
$ gzip -d GeoLiteCityv6.dat.gz

```

将解压后的文件移动到 `/usr/share/GeoIP` 目录下：

```
# mvGeoLiteCity.dat /usr/share/GeoIP/GeoIPCity.dat
# mv GeoLiteCityv6.dat /usr/share/GeoIP/GeoIPCityv6.dat

```

现在，可以从源代码构建 Bro 了。

### 构建 Bro

最新的 Bro 开发版本可以通过 `git` 仓库获得。执行以下命令：

```
$ git clone --recursive git://git.bro.org/bro

```

转到克隆下来的目录，然后使用以下命令就可以简单地构建 Bro：

```
$ cd bro
$ ./configure
$ make

```

`make` 命令需要一些时间来构建一切。确切的时间取决于服务器的性能。

可以使用一些参数来执行 `configure` 脚本，以指定要构建的依赖关系，特别是 `--with-*` 选项。

### 安装 Bro

在克隆的 `bro` 目录中执行：

```
# make install

```

默认安装路径为 `/usr/local/bro`。

### 配置 Bro

Bro 的配置文件位于 `/usr/local/bro/etc` 目录下。 这里有三个文件:

* `node.cfg`，用于配置要监视的单个节点（或多个节点）。
* `broctl.cfg`，BroControl 的配置文件。
* `networks.cgf`，包含一个使用 CIDR 标记法表示的网络列表。

#### 配置邮件设置

打开 `broctl.cfg` 配置文件:

```
# $EDITOR /usr/local/bro/etc/broctl.cfg

```

查看 `Mail Options` 选项，并编辑 `MailTo` 行如下:

```
# Recipient address for emails sent out by Bro and BroControl
MailTo = admin@example.com

```

保存并关闭。还有许多其他选项，但在大多数情况下，默认值就足够好了。

#### 选择要监视的节点

开箱即用，Bro 被配置为以独立模式运行。在本教程中，我们就是做一个独立的安装，所以没有必要改变。但是，也请查看 `node.cfg` 配置文件：

```
# $EDITOR /usr/local/bro/etc/node.cfg

```

在 `[bro]` 部分，你应该看到这样的东西：

```
[bro]
type=standalone
host=localhost
interface=eth0

```

请确保 `inferface` 与 Ubuntu 16.04 服务器的公网接口相匹配。

保存并退出。

#### 配置监视节点的网络

最后一个要编辑的文件是 `network.cfg`。使用文本编辑器打开它：

```
# $EDITOR /usr/local/bro/etc/networks.cfg

```

默认情况下，你应该看到以下内容：

```
# List of local networks in CIDR notation, optionally followed by a
# descriptive tag.
# For example, "10.0.0.0/8" or "fe80::/64" are valid prefixes.

10.0.0.0/8          Private IP space
172.16.0.0/12       Private IP space
192.168.0.0/16      Private IP space

```

删除这三个条目（这只是如何使用此文件的示例），并输入服务器的公用和专用 IP 空间，格式如下：

```
X.X.X.X/X        Public IP space
X.X.X.X/X        Private IP space

```

保存并退出。

### 使用 BroControl 管理 Bro 的安装

管理 Bro 需要使用 BroControl，它支持交互式 shell 和命令行工具两种形式。启动该 shell：

```
# /usr/local/bro/bin/broctl

```

要想使用命令行工具，只需将参数传递给上一个命令，例如：

```
# /usr/local/bro/bin/broctl status

```

这将通过显示以下的输出来检查 Bro 的状态：

```
Name         Type       Host          Status    Pid    Started
bro          standalone localhost     running   6807   20 Jul 12:30:50

```

### 结论

这是一篇 Bro 的安装教程。我们使用基于源代码的安装，因为它是获得可用的最新版本的最有效的方法，但是该网络分析框架也可以下载预构建的二进制格式文件。

下次见！

---

via: <https://www.unixmen.com/how-to-install-bro-ubuntu-1604/>

作者：[Giuseppe Molica](https://www.unixmen.com/author/tutan/) 译者：[firmianay](https://github.com/firmianay) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


使用 Kdump 检查 Linux 内核崩溃

命令都是错的，"kexec -p /boot/vmlinux --initrd=/boot/initramfs-4.19.190-12.el8.x86_64kdump.img  --reuse-cmdline -d" 是--reuse-cmdline，用心点啊编辑。

# 使用 Kdump 检查 Linux 内核崩溃

>
> 让我们先看一下 kdump 的基本使用方法，和 kdump/kexec 在内核中是如何实现。
>
>
>

[kdump](https://www.kernel.org/doc/Documentation/kdump/kdump.txt) 是获取崩溃的 Linux 内核转储的一种方法，但是想找到解释其使用和内部结构的文档可能有点困难。在本文中，我将研究 kdump 的基本使用方法，和 kdump/kexec 在内核中是如何实现。

[kexec](https://linux.die.net/man/8/kexec) 是一个 Linux 内核到内核的引导加载程序，可以帮助从第一个内核的上下文引导到第二个内核。kexec 会关闭第一个内核，绕过 BIOS 或固件阶段，并跳转到第二个内核。因此，在没有 BIOS 阶段的情况下，重新启动变得更快。

kdump 可以与 kexec 应用程序一起使用 —— 例如，当第一个内核崩溃时第二个内核启动，第二个内核用于复制第一个内核的内存转储，可以使用 `gdb` 和 `crash` 等工具分析崩溃的原因。（在本文中，我将使用术语“第一内核”作为当前运行的内核，“第二内核” 作为使用 kexec 运行的内核，“捕获内核” 表示在当前内核崩溃时运行的内核。）

kexec 机制在内核以及用户空间中都有组件。内核提供了几个用于 kexec 重启功能的系统调用。名为 kexec-tools 的用户空间工具使用这些调用，并提供可执行文件来加载和引导“第二内核”。有的发行版还会在 kexec-tools 上添加封装器，这有助于捕获并保存各种转储目标配置的转储。在本文中，我将使用名为 distro-kexec-tools 的工具来避免上游 kexec 工具和特定于发行版的 kexec-tools 代码之间的混淆。我的例子将使用 Fedora Linux 发行版。

### Fedora kexec-tools 工具

使用 `dnf install kexec-tools` 命令在 Fedora 机器上安装 fedora-kexec-tools。在安装 fedora-kexec-tools 后可以执行 `systemctl start kdump` 命令来启动 kdump 服务。当此服务启动时，它将创建一个根文件系统（initramfs），其中包含了要挂载到目标位置的资源，以保存 vmcore，以及用来复制和转储 vmcore 到目标位置的命令。然后，该服务将内核和 initramfs 加载到崩溃内核区域内的合适位置，以便在内核崩溃时可以执行它们。

Fedora 封装器提供了两个用户配置文件：

1. `/etc/kdump.conf` 指定修改后需要重建 initramfs 的配置参数。例如，如果将转储目标从本地磁盘更改为 NFS 挂载的磁盘，则需要由“捕获内核”所加载的 NFS 相关的内核模块。
2. `/etc/sysconfig/kdump` 指定修改后不需要重新构建 initramfs 的配置参数。例如，如果只需修改传递给“捕获内核”的命令行参数，则不需要重新构建 initramfs。

如果内核在 kdump 服务启动之后出现故障，那么“捕获内核”就会执行，其将进一步执行 initramfs 中的 vmcore 保存过程，然后重新启动到稳定的内核。

### kexec-tools 工具

编译 kexec-tools 的源代码得到了一个名为 `kexec` 的可执行文件。这个同名的可执行文件可用于加载和执行“第二内核”，或加载“捕获内核”，它可以在内核崩溃时执行。

加载“第二内核”的命令：

```
# kexec -l kernel.img --initrd=initramfs-image.img –reuse-cmdline

```

`--reuse-command` 参数表示使用与“第一内核”相同的命令行。使用 `--initrd` 传递 initramfs。 `-l` 表明你正在加载“第二内核”，其可以由 `kexec` 应用程序本身执行（`kexec -e`）。使用 `-l` 加载的内核不能在内核崩溃时执行。为了加载可以在内核崩溃时执行的“捕获内核”，必须传递参数 `-p` 取代 `-l`。

加载捕获内核的命令：

```
# kexec -p kernel.img --initrd=initramfs-image.img –reuse-cmdline

```

`echo c > /pros/sysrq-trigger` 可用于使内核崩溃以进行测试。有关 kexec-tools 提供的选项的详细信息，请参阅 `man kexec`。在转到下一个部分之前，请看这个 kexec\_dump 的演示：

### kdump: 端到端流

下图展示了流程图。必须在引导“第一内核”期间为捕获内核保留 crashkernel 的内存。您可以在内核命令行中传递 `crashkernel=Y@X`，其中 `@X` 是可选的。`crashkernel=256M` 适用于大多数 x86\_64 系统；然而，为崩溃内核选择适当的内存取决于许多因素，如内核大小和 initramfs，以及 initramfs 中包含的模块和应用程序运行时的内存需求。有关传递崩溃内核参数的更多方法，请参阅 [kernel-parameters 文档](https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt)。

您可以将内核和 initramfs 镜像传递给 `kexec` 可执行文件，如（`kexec-tools`）部分的命令所示。“捕获内核”可以与“第一内核”相同，也可以不同。通常，一样即可。Initramfs 是可选的；例如，当内核使用 `CONFIG_INITRAMFS_SOURCE` 编译时，您不需要它。通常，从第一个 initramfs 中保存一个不一样的捕获 initramfs，因为在捕获 initramfs 中自动执行 vmcore 的副本能获得更好的效果。当执行 `kexec` 时，它还加载了 `elfcorehdr` 数据和 purgatory 可执行文件（LCTT 译注：purgatory 就是一个引导加载程序，是为 kdump 定作的。它被赋予了“炼狱”这样一个古怪的名字应该只是一种调侃）。 `elfcorehdr` 具有关于系统内存组织的信息，而 purgatory 可以在“捕获内核”执行之前执行并验证第二阶段的二进制或数据是否具有正确的 SHA。purgatory 也是可选的。

当“第一内核”崩溃时，它执行必要的退出过程并切换到 purgatory（如果存在）。purgatory 验证加载二进制文件的 SHA256，如果是正确的，则将控制权传递给“捕获内核”。“捕获内核”根据从 `elfcorehdr` 接收到的系统内存信息创建 vmcore。因此，“捕获内核”启动后，您将看到 `/proc/vmcore` 中“第一内核”的转储。根据您使用的 initramfs，您现在可以分析转储，将其复制到任何磁盘，也可以是自动复制的，然后重新启动到稳定的内核。

### 内核系统调用

内核提供了两个系统调用：`kexec_load()` 和 `kexec_file_load()`，可以用于在执行 `kexec -l` 时加载“第二内核”。它还为 `reboot()` 系统调用提供了一个额外的标志，可用于使用 `kexec -e` 引导到“第二内核”。

`kexec_load()`：`kexec_load()` 系统调用加载一个可以在之后通过 `reboot()` 执行的新的内核。其原型定义如下：

```
long kexec_load(unsigned long entry, unsigned long nr_segments,
struct kexec_segment *segments, unsigned long flags);

```

用户空间需要为不同的组件传递不同的段，如内核，initramfs 等。因此，`kexec` 可执行文件有助于准备这些段。`kexec_segment` 的结构如下所示：

```
struct kexec_segment {
    void *buf;
    /* 用户空间缓冲区 */
    size_t bufsz;
    /* 用户空间中的缓冲区长度 */
    void *mem;
    /* 内核的物理地址 */
    size_t memsz;
    /* 物理地址长度 */
};

```

当使用 `LINUX_REBOOT_CMD_KEXEC` 调用 `reboot()` 时，它会引导进入由 `kexec_load` 加载的内核。如果标志 `KEXEC_ON_CRASH` 被传递给 `kexec_load()`，则加载的内核将不会使用 `reboot(LINUX_REBOOT_CMD_KEXEC)` 来启动；相反，这将在内核崩溃中执行。必须定义 `CONFIG_KEXEC` 才能使用 `kexec`，并且为 `kdump` 定义 `CONFIG_CRASH_DUMP`。

`kexec_file_load()`：作为用户，你只需传递两个参数（即 `kernel` 和 `initramfs`）到 `kexec` 可执行文件。然后，`kexec` 从 sysfs 或其他内核信息源中读取数据，并创建所有段。所以使用 `kexec_file_load()` 可以简化用户空间，只传递内核和 initramfs 的文件描述符。其余部分由内核本身完成。使用此系统调用时应该启用 `CONFIG_KEXEC_FILE`。它的原型如下：

```
long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
cmdline_len, const char __user * cmdline_ptr, unsigned long
flags);

```

请注意，`kexec_file_load` 也可以接受命令行，而 `kexec_load()` 不行。内核根据不同的系统架构来接受和执行命令行。因此，在 `kexec_load()` 的情况下，`kexec-tools` 将通过其中一个段（如在 dtb 或 ELF 引导注释等）中传递命令行。

目前，`kexec_file_load()` 仅支持 x86 和 PowerPC。

#### 当内核崩溃时会发生什么

当第一个内核崩溃时，在控制权传递给 purgatory 或“捕获内核”之前，会执行以下操作：

* 准备 CPU 寄存器（参见内核代码中的 `crash_setup_regs()`）;
* 更新 vmcoreinfo 备注（请参阅 `crash_save_vmcoreinfo()`）;
* 关闭非崩溃的 CPU 并保存准备好的寄存器（请参阅 `machine_crash_shutdown()` 和 `crash_save_cpu()`）;
* 您可能需要在此处禁用中断控制器；
* 最后，它执行 kexec 重新启动（请参阅 `machine_kexec()`），它将加载或刷新 kexec 段到内存，并将控制权传递给进入段的执行文件。输入段可以是下一个内核的 purgatory 或开始地址。

#### ELF 程序头

kdump 中涉及的大多数转储核心都是 ELF 格式。因此，理解 ELF 程序头部很重要，特别是当您想要找到 vmcore 准备的问题。每个 ELF 文件都有一个程序头：

* 由系统加载器读取，
* 描述如何将程序加载到内存中，
* 可以使用 `Objdump -p elf_file` 来查看程序头。

vmcore 的 ELF 程序头的示例如下：

```
# objdump -p vmcore
vmcore:
file format elf64-littleaarch64
Program Header:
NOTE off 0x0000000000010000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0 filesz
0x00000000000013e8 memsz 0x00000000000013e8 flags ---
LOAD off 0x0000000000020000 vaddr 0xffff000008080000 paddr 0x0000004000280000 align 2**0 filesz
0x0000000001460000 memsz 0x0000000001460000 flags rwx
LOAD off 0x0000000001480000 vaddr 0xffff800000200000 paddr 0x0000004000200000 align 2**0 filesz
0x000000007fc00000 memsz 0x000000007fc00000 flags rwx
LOAD off 0x0000000081080000 vaddr 0xffff8000ffe00000 paddr 0x00000040ffe00000 align 2**0 filesz
0x00000002fa7a0000 memsz 0x00000002fa7a0000 flags rwx
LOAD off 0x000000037b820000 vaddr 0xffff8003fa9e0000 paddr 0x00000043fa9e0000 align 2**0 filesz
0x0000000004fc0000 memsz 0x0000000004fc0000 flags rwx
LOAD off 0x00000003807e0000 vaddr 0xffff8003ff9b0000 paddr 0x00000043ff9b0000 align 2**0 filesz
0x0000000000010000 memsz 0x0000000000010000 flags rwx
LOAD off 0x00000003807f0000 vaddr 0xffff8003ff9f0000 paddr 0x00000043ff9f0000 align 2**0 filesz
0x0000000000610000 memsz 0x0000000000610000 flags rwx

```

在这个例子中，有一个 note 段，其余的是 load 段。note 段提供了有关 CPU 信息，load 段提供了关于复制的系统内存组件的信息。

vmcore 从 `elfcorehdr` 开始，它具有与 ELF 程序头相同的结构。参见下图中 `elfcorehdr` 的表示：

`kexec-tools` 读取 `/sys/devices/system/cpu/cpu%d/crash_notes` 并准备 `CPU PT_NOTE` 的标头。同样，它读取 `/sys/kernel/vmcoreinfo` 并准备 `vmcoreinfo PT_NOTE` 的标头，从 `/proc/iomem` 读取系统内存并准备存储器 `PT_LOAD` 标头。当“捕获内核”接收到 `elfcorehdr` 时，它从标头中提到的地址中读取数据，并准备 vmcore。

#### Crash note

Crash notes 是每个 CPU 中用于在系统崩溃的情况下存储 CPU 状态的区域；它有关于当前 PID 和 CPU 寄存器的信息。

#### vmcoreinfo

该 note 段具有各种内核调试信息，如结构体大小、符号值、页面大小等。这些值由捕获内核解析并嵌入到 `/proc/vmcore` 中。 `vmcoreinfo` 主要由 `makedumpfile` 应用程序使用。在 Linux 内核，`include/linux/kexec.h` 宏定义了一个新的 `vmcoreinfo`。 一些示例宏如下所示：

* `VMCOREINFO_PAGESIZE()`
* `VMCOREINFO_SYMBOL()`
* `VMCOREINFO_SIZE()`
* `VMCOREINFO_STRUCT_SIZE()`

#### makedumpfile

vmcore 中的许多信息（如可用页面）都没有用处。`makedumpfile` 是一个用于排除不必要的页面的应用程序，如：

* 填满零的页面；
* 没有私有标志的缓存页面（非专用缓存）;
* 具有私有标志的缓存页面（专用缓存）;
* 用户进程数据页；
* 可用页面。

此外，`makedumpfile` 在复制时压缩 `/proc/vmcore` 的数据。它也可以从转储中删除敏感的符号信息； 然而，为了做到这一点，它首先需要内核的调试信息。该调试信息来自 `VMLINUX` 或 `vmcoreinfo`，其输出可以是 ELF 格式或 kdump 压缩格式。

典型用法：

```
# makedumpfile -l --message-level 1 -d 31 /proc/vmcore makedumpfilecore

```

详细信息请参阅 `man makedumpfile`。

### kdump 调试

新手在使用 kdump 时可能会遇到的问题：

#### `kexec -p kernel_image` 没有成功

* 检查是否分配了崩溃内存。
* `cat /sys/kernel/kexec_crash_size` 不应该有零值。
* `cat /proc/iomem | grep "Crash kernel"` 应该有一个分配的范围。
* 如果未分配，则在命令行中传递正确的 `crashkernel=` 参数。
* 如果没有显示，则在 `kexec` 命令中传递参数 `-d`，并将输出信息发送到 kexec-tools 邮件列表。

#### 在“第一内核”的最后一个消息之后，在控制台上看不到任何东西（比如“bye”）

* 检查 `kexec -e` 之后的 `kexec -l kernel_image` 命令是否工作。
* 可能缺少支持的体系结构或特定机器的选项。
* 可能是 purgatory 的 SHA 验证失败。如果您的体系结构不支持 purgatory 中的控制台，则很难进行调试。
* 可能是“第二内核”早已崩溃。
* 将您的系统的 `earlycon` 或 `earlyprintk` 选项传递给“第二内核”的命令行。
* 使用 kexec-tools 邮件列表共享第一个内核和捕获内核的 `dmesg` 日志。

### 资源

#### fedora-kexec-tools

* GitHub 仓库：`git://pkgs.fedoraproject.org/kexec-tools`
* 邮件列表：[kexec@lists.fedoraproject.org](mailto:kexec@lists.fedoraproject.org)
* 说明：Specs 文件和脚本提供了用户友好的命令和服务，以便 `kexec-tools` 可以在不同的用户场景下实现自动化。

#### kexec-tools

* GitHub 仓库：git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
* 邮件列表：[kexec@lists.infradead.org](mailto:kexec@lists.infradead.org)
* 说明：使用内核系统调用并提供用户命令 `kexec`。

#### Linux kernel

* GitHub 仓库： `git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git`
* 邮件列表：[kexec@lists.infradead.org](mailto:kexec@lists.infradead.org)
* 说明：实现了 `kexec_load()`、`kexec_file_load()`、`reboot()` 系统调用和特定体系结构的代码，例如 `machine_kexec()` 和 `machine_crash_shutdown()`。

#### Makedumpfile

* GitHub 仓库： `git://git.code.sf.net/p/makedumpfile/code`
* 邮件列表：[kexec@lists.infradead.org](mailto:kexec@lists.infradead.org)
* 说明：从转储文件中压缩和过滤不必要的组件。

（题图：[Penguin](https://pixabay.com/en/penguins-emperor-antarctic-life-429136/)、 [Boot](https://pixabay.com/en/shoe-boots-home-boots-house-1519804/)，修改：Opensource.com. [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)）

---

作者简介：

Pratyush Anand - Pratyush 正在以以为 Linux 内核专家的身份与 Red Hat 合作。他主要负责 Red Hat 产品和上游所面临的几个 kexec/kdump 问题。他还处理 Red Hat 支持的 ARM64 平台周围的其他内核调试、跟踪和性能问题。除了 Linux 内核，他还在上游的 kexec-tools 和 makedumpfile 项目中做出了贡献。他是一名开源爱好者，并在教育机构举办志愿者讲座，促进了 FOSS。

---

via: <https://opensource.com/article/17/6/kdump-usage-and-internals>

作者：[Pratyush Anand](https://opensource.com/users/pratyushanand) 译者：[firmianay](https://github.com/firmianay) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


使用统一阻止列表和白名单来更新主机文件

这个机翻也是醉了

# 使用统一阻止列表和白名单来更新主机文件

<img src="content_image/album_201707_30_155717leiystiieyuu8cie.jpg" alt="" title="">

网上有许多持续维护的含有不同垃圾域的有用列表。将这些列表复制到你的主机文件中可以轻松阻止大量的域，你的系统将根本不用去连接它们。此方法可以在不安装浏览器插件的情况下工作，并且将为系统上任何浏览器（和任何其他程序）提供阻止操作。

在本教程中，我将向你展示如何在 Linux 中启动并运行 Steven Black 的[统一主机脚本](https://github.com/StevenBlack/hosts)。该脚本将使用来自多个来源的最新已知的广告服务器、网络钓鱼网站和其他网络垃圾的地址来更新你的计算机主机文件，同时提供一个漂亮、干净的方式来管理你自己的黑名单/白名单，其分别来自于该脚本管理的各个列表。

在将 30,000 个域放入主机文件之前，需要注意两点。首先，这些巨大的列表包含可能需要解除封锁的服务器，以便进行在线购买或其他一些临时情况。如果你弄乱了你的主机文件，你要知道网上的某些东西可能会出现问题。为了解决这个问题，我将向你展示如何使用方便的打开/关闭开关，以便你可以快速禁用你的阻止列表来购买喜马拉雅盐雾灯（它是等离子灯）。我仍然认为这些列表的目的之一是将所有的一切都封锁（有点烦人，直到我想到了做一个关闭开关）。如果你经常遇到你需要的服务器被阻止的问题，只需将其添加到白名单文件中即可。

第二个问题是性能受到了轻微的影响, 因为每次调用一个域时, 系统都必须检查整个列表。只是有一点点影响, 而没有大到让我因此而放弃黑名单，让每一个连接都通过。你具体要怎么选择自己看着办。

主机文件通过将请求定向到 127.0.0.1 或 0.0.0.0（换句话说定向到空地址）来阻止请求。有人说使用 0.0.0.0 是更快，问题更少的方法。你可以将脚本配置为使用 `-ip nnn.nnn.nnn.nnn` 这样的 ip 选项来作为阻止 ip，但默认值是 0.0.0.0，这是我使用的值。

我曾经将 Steven Black 的脚本做的事每隔一段时间就手动做一遍，进到每一个站点，将他们的列表拷贝/粘贴到我的主机文件中，做一个查找替换将其中的 127 变成 0 等等。我知道整件事情可以自动化，这样做有点傻，但我从来没有花时间解决这个问题。直到我找到这个脚本，现在这事已经是一个被遗忘的杂务。

让我们先下载一份最新的 Steven Black 的代码拷贝（大约 150MB），以便我们可以进行下一步。你需要安装 git，因此如果还没安装，进入到终端输入：

```
sudo apt-get install git

```

安装完之后，输入：

```
mkdir unifiedhosts
cd unifiedhosts
git clone https://github.com/StevenBlack/hosts.git
cd hosts

```

当你打开了 Steven 的脚本时，让我们来看看有什么选项。该脚本有几个选项和扩展，但扩展我不会在这里提交，但如果你到了这一步并且你有兴趣，[readme.md](https://github.com/StevenBlack/hosts/blob/master/readme.md) 可以告诉你所有你需要知道的。

你需要安装 python 来运行此脚本，并且与版本有关。要找到你安装的 Python 版本，请输入：

```
python --version

```

如果你还没安装 Python:

```
sudo apt-get install python

```

对于 Python 2.7，如下所示，输入 `python` 来执行脚本。对于 Python 3，在命令中的 `python` 替换成 `python3`。执行后，该脚本会确保它具有每个列表的最新版本，如果没有，它会抓取一个新的副本。然后，它会写入一个新的主机文件，包括了你的黑名单/白名单中的任何内容。让我们尝试使用 `-r` 选项来替换我们的当前的主机文件，而 `-a` 选项可以脚本不会问我们任何问题。回到终端：

```
python updateHostsFile.py -r -a

```

该命令将询问你的 root 密码，以便能够写入 `/etc/`。为了使新更新的列表处于激活状态，某些系统需要清除 DNS 缓存。在同一个硬件设备上，我观察到不同的操作系统表现出非常不同的行为，在没有刷新缓存的情况下不同的服务器变为可访问/不可访问所需的时间长度都不同。我已经看到了从即时更新（Slackware）到重启更新（Windows）的各种情况。有一些命令可以刷新 DNS 缓存，但是它们在每个操作系统甚至每个发行版上都不同，所以如果没有生效，只需要重新启动就行了。

现在，只要将你的个人例外添加到黑名单/白名单中，并且只要你想要更新主机文件，运行该脚本就好。该脚本将根据你的要求调整生成的主机文件，每次运行文件时会自动追加你额外的列表。

最后，我们来创建一个打开/关闭开关，对于打开和关闭功能每个都创建一个脚本，所以回到终端输入下面的内容创建关闭开关（用你自己的文本编辑器替换 leafpad）：

```
leafpad hosts-off.sh

```

在新文件中输入下面的内容：

```
#!/bin/sh
sudo mv /etc/hosts /etc/hostsDISABLED

```

接着让它可执行：

```
chmod +x hosts-off.sh

```

相似地，对于打开开关：

```
leafpad hosts-on.sh

```

在新文件中输入下面的内容：

```
#!/bin/sh
sudo mv /etc/hostsDISABLED /etc/hosts

```

最后让它可执行：

```
chmod +x hosts-on.sh

```

你所需要做的是为每个脚本创建一个快捷方式，标记为 HOSTS-ON 和 HOSTS-OFF，放在你能找到它们的地方。

---

via: <https://www.darrentoback.com/this-script-updates-hosts-files-using-a-multi-source-unified-block-list-with-whitelisting>

作者：[dmt](https://www.darrentoback.com/about-me) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出