2018年11月

大型企业里 SRE 角色比较常见,不过小公司也需要 SRE。

虽然 站点可靠性工程师 site reliability engineer (SRE)角色在近几年变得流行起来,但是很多人 —— 甚至是软件行业里的 —— 还不知道 SRE 是什么或者 SRE 都干些什么。为了搞清楚这些问题,这篇文章解释了 SRE 的含义,还有 SRE 怎样关联 DevOps,以及在工程师团队规模不大的组织里 SRE 该如何工作。

什么是站点可靠性工程?

谷歌的几个工程师写的《SRE:谷歌运维解密》被认为是站点可靠性工程的权威书籍。谷歌的工程副总裁 Ben Treynor Sloss 在二十一世纪初创造了这个术语。他是这样定义的:“当你让软件工程师设计运维功能时,SRE 就产生了。”

虽然系统管理员从很久之前就在写代码,但是过去的很多时候系统管理团队是手动管理机器的。当时他们管理的机器可能有几十台或者上百台,不过当这个数字涨到了几千甚至几十万的时候,就不能简单的靠人去解决问题了。规模如此大的情况下,很明显应该用代码去管理机器(以及机器上运行的软件)。

另外,一直到近几年,运维团队和开发团队都还是完全独立的。两个岗位的技能要求也被认为是完全不同的。SRE 的角色想尝试把这两份工作结合起来。

在深入探讨什么是 SRE 以及 SRE 如何和开发团队协作之前,我们需要先了解一下 SRE 在 DevOps 范例中是怎么工作的。

SRE 和 DevOps

站点可靠性工程的核心,就是对 DevOps 范例的实践。DevOps 的定义有很多种方式。开发团队(“dev”)和运维(“ops”)团队相互分离的传统模式下,写代码的团队在将服务交付给用户使用之后就不再对服务状态负责了。开发团队“把代码扔到墙那边”让运维团队去部署和支持。

这种情况会导致大量失衡。开发和运维的目标总是不一致 —— 开发希望用户体验到“最新最棒”的代码,但是运维想要的是变更尽量少的稳定系统。运维是这样假定的,任何变更都可能引发不稳定,而不做任何变更的系统可以一直保持稳定。(减少软件的变更次数并不是避免故障的唯一因素,认识到这一点很重要。例如,虽然你的 web 应用保持不变,但是当用户数量涨到十倍时,服务可能就会以各种方式出问题。)

DevOps 理念认为通过合并这两个岗位就能够消灭争论。如果开发团队时刻都想把新代码部署上线,那么他们也必须对新代码引起的故障负责。就像亚马逊的 Werner Vogels 说的那样,“谁开发,谁运维”(生产环境)。但是开发人员已经有一大堆问题了。他们不断的被推动着去开发老板要的产品功能。再让他们去了解基础设施,包括如何部署、配置还有监控服务,这对他们的要求有点太多了。所以就需要 SRE 了。

开发一个 web 应用的时候经常是很多人一起参与。有用户界面设计师、图形设计师、前端工程师、后端工程师,还有许多其他工种(视技术选型的具体情况而定)。如何管理写好的代码也是需求之一(例如部署、配置、监控)—— 这是 SRE 的专业领域。但是,就像前端工程师受益于后端领域的知识一样(例如从数据库获取数据的方法),SRE 理解部署系统的工作原理,知道如何满足特定的代码或者项目的具体需求。

所以 SRE 不仅仅是“写代码的运维工程师”。相反,SRE 是开发团队的成员,他们有着不同的技能,特别是在发布部署、配置管理、监控、指标等方面。但是,就像前端工程师必须知道如何从数据库中获取数据一样,SRE 也不是只负责这些领域。为了提供更容易升级、管理和监控的产品,整个团队共同努力。

当一个团队在做 DevOps 实践,但是他们意识到对开发的要求太多了,过去由运维团队做的事情,现在需要一个专家来专门处理。这个时候,对 SRE 的需求很自然地就出现了。

SRE 在初创公司怎么工作

如果你们公司有好几百位员工,那是非常好的(如果到了 Google 和 Facebook 的规模就更不用说了)。大公司的 SRE 团队分散在各个开发团队里。但是一个初创公司没有这种规模经济,工程师经常身兼数职。那么小公司该让谁做 SRE 呢?其中一种方案是完全践行 DevOps,那些大公司里属于 SRE 的典型任务,在小公司就让开发者去负责。另一种方案,则是聘请专家 —— 也就是 SRE。

让开发人员做 SRE 最显著的优点是,团队规模变大的时候也能很好的扩展。而且,开发人员将会全面地了解应用的特性。但是,许多初创公司的基础设施包含了各种各样的 SaaS 产品,这种多样性在基础设施上体现的最明显,因为连基础设施本身也是多种多样。然后你们在某个基础设施上引入指标系统、站点监控、日志分析、容器等等。这些技术解决了一部分问题,也增加了复杂度。开发人员除了要了解应用程序的核心技术(比如开发语言),还要了解上述所有技术和服务。最终,掌握所有的这些技术让人无法承受。

另一种方案是聘请专家专职做 SRE。他们专注于发布部署、配置管理、监控和指标,可以节省开发人员的时间。这种方案的缺点是,SRE 的时间必须分配给多个不同的应用(就是说 SRE 需要贯穿整个工程部门)。 这可能意味着 SRE 没时间对任何应用深入学习,然而他们可以站在一个能看到服务全貌的高度,知道各个部分是怎么组合在一起的。 这个“三万英尺高的视角”可以帮助 SRE 从系统整体上考虑,哪些薄弱环节需要优先修复。

有一个关键信息我还没提到:其他的工程师。他们可能很渴望了解发布部署的原理,也很想尽全力学会使用指标系统。而且,雇一个 SRE 可不是一件简单的事儿。因为你要找的是一个既懂系统管理又懂软件工程的人。(我之所以明确地说软件工程而不是说“能写代码”,是因为除了写代码之外软件工程还包括很多东西,比如编写良好的测试或文档。)

因此,在某些情况下让开发人员做 SRE 可能更合理一些。如果这样做了,得同时关注代码和基础设施(购买 SaaS 或内部自建)的复杂程度。这两边的复杂性,有时候能促进专业化。

总结

在初创公司做 DevOps 实践最有效的方式是组建 SRE 小组。我见过一些不同的方案,但是我相信初创公司(尽早)招聘专职 SRE 可以解放开发人员,让开发人员专注于特定的挑战。SRE 可以把精力放在改善工具(流程)上,以提高开发人员的生产力。不仅如此,SRE 还专注于确保交付给客户的产品是可靠且安全的。


via: https://opensource.com/article/18/10/sre-startup

作者:Craig Sebenik 选题:lujun9972 译者:BeliteX 校对:wxy

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

通过 Markdown 和 Pandoc,可以做到编写一次,发布两次。

Pandoc 是一个命令行工具,用于将文件从一种标记语言转换为另一种标记语言。在我 对 Pandoc 的简介 一文中,我演示了如何把 Markdown 编写的文本转换为网页、幻灯片和 PDF。

在这篇后续文章中,我将深入探讨 Pandoc,展示如何从同一个 Markdown 源文件生成网页和 ePub 格式的电子书。我将使用我即将发布的电子书《面向对象思想的 GRASP 原则》为例进行讲解,这本电子书正是通过以下过程创建的。

首先,我将解释这本书使用的文件结构,然后介绍如何使用 Pandoc 生成网页并将其部署在 GitHub 上;最后,我演示了如何生成对应的 ePub 格式电子书。

你可以在我的 GitHub 仓库 Programming Fight Club 中找到相应代码。

设置图书结构

我用 Markdown 语法完成了所有的写作,你也可以使用 HTML 标记,但是当 Pandoc 将 Markdown 转换为 ePub 文档时,引入的 HTML 标记越多,出现问题的风险就越高。我的书按照每章一个文件的形式进行组织,用 Markdown 的 H1 标记()声明每章的标题。你也可以在每个文件中放置多个章节,但将它们放在单独的文件中可以更轻松地查找内容并在以后进行更新。

元信息遵循类似的模式,每种输出格式都有自己的元信息文件。元信息文件定义有关文档的信息,例如要添加到 HTML 中的文本或 ePub 的许可证。我将所有 Markdown 文档存储在名为 parts 的文件夹中(这对于用来生成网页和 ePub 的 Makefile 非常重要)。下面以一个例子进行说明,让我们看一下目录,前言和关于本书(分为 toc.mdpreface.mdabout.md 三个文件)这三部分,为清楚起见,我们将省略其余的章节。

关于本书这部分内容的开头部分类似:

# About this book {-}

## Who should read this book {-}

Before creating a complex software system one needs to create a solid foundation.
General Responsibility Assignment Software Principles (GRASP) are guidelines to assign
responsibilities to software classes in object-oriented programming.

每一章完成后,下一步就是添加元信息来设置网页和 ePub 的格式。

生成网页

创建 HTML 元信息文件

我创建的网页的元信息文件(web-metadata.yaml)是一个简单的 YAML 文件,其中包含 <head> 标签中的作者、标题、和版权等信息,以及 HTML 文件中开头和结尾的内容。

我建议(至少)包括 web-metadata.yaml 文件中的以下字段:

---
title: <a href="/grasp-principles/toc/">GRASP principles for the Object-oriented mind</a>
author: Kiko Fernandez-Reyes
rights: 2017 Kiko Fernandez-Reyes, CC-BY-NC-SA 4.0 International
header-includes:
- |
  ```{=html}
  <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">
  <link href="https://fonts.googleapis.com/css?family=Gentium+Basic|Inconsolata" rel="stylesheet">
  ```
include-before:
- |
  ```{=html}
  <p>If you like this book, please consider
      spreading the word or
      <a href="https://www.buymeacoffee.com/programming">
        buying me a coffee
      </a>
  </p>
  ```
include-after:
- |
  ```{=html}
  <div class="footnotes">
    <hr>
    <div class="container">
        <nav class="pagination" role="pagination">
          <ul>
          <p>
          <span class="page-number">Designed with</span> ❤️  <span class="page-number"> from Uppsala, Sweden</span>
           </p>
           <p>
           <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a>
           </p>
           </ul>
        </nav>
    </div>
  </div>
  ```
---

下面几个变量需要注意一下:

  • header-includes 变量包含将要嵌入 <head> 标签的 HTML 文本。
  • 调用变量后的下一行必须是 - |。再往下一行必须以与 | 对齐的三个反引号开始,否则 Pandoc 将无法识别。{= html} 告诉 Pandoc 其中的内容是原始文本,不应该作为 Markdown 处理。(为此,需要检查 Pandoc 中的 raw_attribute 扩展是否已启用。要进行此检查,键入 pandoc --list-extensions | grep raw 并确保返回的列表包含名为 + raw_html 的项目,加号表示已启用。)
  • 变量 include-before 在网页开头添加一些 HTML 文本,此处我请求读者帮忙宣传我的书或给我打赏。
  • include-after 变量在网页末尾添加原始 HTML 文本,同时显示我的图书许可证。

这些只是其中一部分可用的变量,查看 HTML 中的模板变量(我的文章 Pandoc简介 中介绍了如何查看 LaTeX 的模版变量,查看 HTML 模版变量的过程是相同的)对其余变量进行了解。

将网页分成多章

网页可以作为一个整体生成,这会产生一个包含所有内容的长页面;也可以分成多章,我认为这样会更容易阅读。我将解释如何将网页划分为多章,以便读者不会被长网页吓到。

为了使网页易于在 GitHub Pages 上部署,需要创建一个名为 docs 的根文件夹(这是 GitHub Pages 默认用于渲染网页的根文件夹)。然后我们需要为 docs 下的每一章创建文件夹,将 HTML 内容放在各自的文件夹中,将文件内容放在名为 index.html 的文件中。

例如,about.md 文件将转换成名为 index.html 的文件,该文件位于名为 aboutabout/index.html)的文件夹中。这样,当用户键入 http://<your-website.com>/about/ 时,文件夹中的 index.html 文件将显示在其浏览器中。

下面的 Makefile 将执行上述所有操作:

# Your book files
DEPENDENCIES= toc preface about

# Placement of your HTML files
DOCS=docs

all: web

web: setup $(DEPENDENCIES)
        @cp $(DOCS)/toc/index.html $(DOCS)


# Creation and copy of stylesheet and images into
# the assets folder. This is important to deploy the
# website to Github Pages.
setup:
        @mkdir -p $(DOCS)
        @cp -r assets $(DOCS)


# Creation of folder and index.html file on a
# per-chapter basis

$(DEPENDENCIES):
        @mkdir -p $(DOCS)/$@
        @pandoc -s --toc web-metadata.yaml parts/[email protected] \
        -c /assets/pandoc.css -o $(DOCS)/$@/index.html

clean:
        @rm -rf $(DOCS)

.PHONY: all clean web setup

选项 - c /assets/pandoc.css 声明要使用的 CSS 样式表,它将从 /assets/pandoc.cs 中获取。也就是说,在 <head> 标签内,Pandoc 会添加这样一行:

<link rel="stylesheet" href="/assets/pandoc.css">

使用下面的命令生成网页:

make

根文件夹现在应该包含如下所示的文件结构:

.---parts
|    |--- toc.md
|    |--- preface.md
|    |--- about.md
|
|---docs
    |--- assets/
    |--- index.html
    |--- toc
    |     |--- index.html
    |
    |--- preface
    |     |--- index.html
    |
    |--- about
          |--- index.html
   

部署网页

通过以下步骤将网页部署到 GitHub 上:

  1. 创建一个新的 GitHub 仓库
  2. 将内容推送到新创建的仓库
  3. 找到仓库设置中的 GitHub Pages 部分,选择 Source 选项让 GitHub 使用主分支的内容

你可以在 GitHub Pages 的网站上获得更多详细信息。

我的书的网页 便是通过上述过程生成的,可以在网页上查看结果。

生成电子书

创建 ePub 格式的元信息文件

ePub 格式的元信息文件 epub-meta.yaml 和 HTML 元信息文件是类似的。主要区别在于 ePub 提供了其他模板变量,例如 publishercover-image 。ePub 格式图书的样式表可能与网页所用的不同,在这里我使用一个名为 epub.css 的样式表。

---
title: 'GRASP principles for the Object-oriented Mind'
publisher: 'Programming Language Fight Club'
author: Kiko Fernandez-Reyes
rights: 2017 Kiko Fernandez-Reyes, CC-BY-NC-SA 4.0 International
cover-image: assets/cover.png
stylesheet: assets/epub.css
...

将以下内容添加到之前的 Makefile 中:

epub:
        @pandoc -s --toc epub-meta.yaml \
        $(addprefix parts/, $(DEPENDENCIES:=.md)) -o $(DOCS)/assets/book.epub

用于产生 ePub 格式图书的命令从 HTML 版本获取所有依赖项(每章的名称),向它们添加 Markdown 扩展,并在它们前面加上每一章的文件夹路径,以便让 Pandoc 知道如何进行处理。例如,如果 $(DEPENDENCIES 变量只包含 “前言” 和 “关于本书” 两章,那么 Makefile 将会这样调用:

@pandoc -s --toc epub-meta.yaml \
parts/preface.md parts/about.md -o $(DOCS)/assets/book.epub

Pandoc 将提取这两章的内容,然后进行组合,最后生成 ePub 格式的电子书,并放在 Assets 文件夹中。

这是使用此过程创建 ePub 格式电子书的一个 示例

过程总结

从 Markdown 文件创建网页和 ePub 格式电子书的过程并不困难,但有很多细节需要注意。遵循以下大纲可能使你更容易使用 Pandoc。

  • HTML 图书:
    • 使用 Markdown 语法创建每章内容
    • 添加元信息
    • 创建一个 Makefile 将各个部分组合在一起
    • 设置 GitHub Pages
    • 部署


  • ePub 电子书:

    • 使用之前创建的每一章内容
    • 添加新的元信息文件
    • 创建一个 Makefile 以将各个部分组合在一起
    • 设置 GitHub Pages
    • 部署



via: https://opensource.com/article/18/10/book-to-website-epub-using-pandoc

作者:Kiko Fernandez-Reyes 选题:lujun9972 译者:jlztan 校对:wxy

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

通过键盘操作的 i3 平铺窗口管理器使用 Linux 桌面。

Linux(和一般的开源软件)最美好的一点是自由 —— 可以在不同的替代方案中进行选择以满足我们的需求。

我使用 Linux 已经很长时间了,但我从来没有对可选用的桌面环境完全满意过。直到去年,Xfce 还是我认为在功能和性能之间的平和最接近满意的一个桌面环境。然后我发现了 i3,这是一个改变了我的生活的惊人的软件。

i3 是一个平铺窗口管理器。窗口管理器的目标是控制窗口系统中窗口的外观和位置。窗口管理器通常用作功能齐全的桌面环境 (如 GONME 或 Xfce ) 的一部分,但也有一些可以用作独立的应用程序。

平铺式窗口管理器会自动排列窗口,以不重叠的方式占据整个屏幕。其他流行的平铺式窗口管理器还有 wmiixmonad

 title=

带有三个的 i3 屏幕截图

为了获得更好的 Linux 桌面体验,以下是我使用和推荐 i3 窗口管理器的五个首要原因。

1、极简艺术

i3 速度很快。它既不冗杂、也不花哨。它的设计简单而高效。作为开发人员,我重视这些功能,因为我可以使用更多的功能以丰富我最喜欢的开发工具,或者使用容器或虚拟机在本地测试内容。

此外, i3 是一个窗口管理器,与功能齐全的桌面环境不同,它并不规定您应该使用的应用程序。您是否想使用 Xfce 的 Thunar 作为文件管理器?GNOME 的 gedit 去编辑文本? i3 并不在乎。选择对您的工作流最有意义的工具,i3 将以相同的方式管理它们。

2、屏幕实际使用面积

作为平铺式窗口管理器,i3 将自动 “平铺”,以不重叠的方式定位窗口,类似于在墙上放置瓷砖。因为您不需要担心窗口定位,i3 一般会更好地利用您的屏幕空间。它还可以让您更快地找到您需要的东西。

对于这种情况有很多有用的例子。例如,系统管理员可以打开多个终端来同时监视或在不同的远程系统上工作;开发人员可以使用他们最喜欢的 IDE 或编辑器和几个终端来测试他们的程序。

此外,i3 具有灵活性。如果您需要为特定窗口提供更多空间,请启用全屏模式或切换到其他布局,如堆叠或选项卡式(标签式)。

3、键盘式工作流程

i3 广泛使用键盘快捷键来控制环境的不同方面。其中包括打开终端和其他程序、调整大小和定位窗口、更改布局,甚至退出 i3。当您开始使用 i3 时,您需要记住其中的一些快捷方式才能使用,随着时间的推移,您会使用更多的快捷方式。

主要好处是,您不需要经常在键盘和鼠标之间切换。通过练习,您将提高工作流程的速度和效率。

例如, 要打开新的终端,请按 <SUPER>+<ENTER>。由于窗口是自动定位的,您可以立即开始键入命令。结合一个很好的终端文本编辑器(如 Vim)和一个以面向键盘的浏览器,形成一个完全由键盘驱动的工作流程。

在 i3 中,您可以为所有内容定义快捷方式。下面是一些示例:

  • 打开终端
  • 打开浏览器
  • 更改布局
  • 调整窗口大小
  • 控制音乐播放器
  • 切换工作区

现在我已经习惯了这个工作形式,我已无法回到了常规的桌面环境。

4、灵活

i3 力求极简,使用很少的系统资源,但这并不意味着它不能变漂亮。i3 是灵活且可通过多种方式进行自定义以改善视觉体验。因为 i3 是一个窗口管理器,所以它没有提供启用自定义的工具,你需要外部工具来实现这一点。一些例子:

  • feh 定义桌面的背景图片。
  • 使用合成器管理器,如 compton 以启用窗口淡入淡出和透明度等效果。
  • dmenurofi 以启用可从键盘快捷方式启动的可自定义菜单。
  • dunst 用于桌面通知。

i3 是可完全配置的,您可以通过更新默认配置文件来控制它的各个方面。从更改所有键盘快捷键,到重新定义工作区的名称,再到修改状态栏,您都可以使 i3 以任何最适合您需要的方式运行。

 title=

i3 与 rofi 菜单和 dunst 桌面通知。

最后,对于更高级的用户,i3 提供了完整的进程间通信(IPC)接口,允许您使用偏好的语言来开发脚本或程序,以实现更多的自定义选项。

5、工作空间

在 i3 中,工作区是对窗口进行分组的一种简单方法。您可以根据您的工作流以不同的方式对它们进行分组。例如,您可以将浏览器放在一个工作区上,终端放在另一个工作区上,将电子邮件客户端放在第三个工作区上等等。您甚至可以更改 i3 的配置,以便始终将特定应用程序分配给它们自己的工作区。

切换工作区既快速又简单。像 i3 中的惯例,使用键盘快捷方式执行此操作。按 <SUPER>+num 切换到工作区 num 。如果您养成了始终将应用程序组的窗口分配到同一个工作区的习惯,则可以在它们之间快速切换,这使得工作区成为非常有用的功能。

此外,还可以使用工作区来控制多监视器环境,其中每个监视器都有个初始工作区。如果切换到该工作区,则切换到该监视器,而无需让手离开键盘。

最后,i3 中还有另一种特殊类型的工作空间:the scratchpad(便笺簿)。它是一个不可见的工作区,通过按快捷方式显示在其他工作区的中间。这是一种访问您经常使用的窗口或程序的方便方式,如电子邮件客户端或音乐播放器。

尝试一下吧

如果您重视简洁和效率,并且不惮于使用键盘,i3 就是您的窗口管理器。有人说是为高级用户准备的,但情况不一定如此。你需要学习一些基本的快捷方式来度过开始的阶段,不久就会越来越自然并且不假思索地使用它们。

这篇文章只是浅浅谈及了 i3 能做的事情。欲了解更多详情,请参阅 i3 的文档


via: https://opensource.com/article/18/8/i3-tiling-window-manager

作者:Ricardo Gerardi 选题:lujun9972 译者:lixinyuxx 校对:wxy

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

GPL 合作承诺 GPL Cooperation Commitment 消除了开发者对许可证失效的顾虑,从而达到促进技术创新的目的。

假如能免于顾虑,技术创新和发展将会让世界发生天翻地覆的改变。 GPL 合作承诺 GPL Cooperation Commitment 就这样应运而生,只为通过公平、一致、可预测的许可证来让科技创新无后顾之忧。

去年,我曾经写过一篇文章,讨论了许可证对开源软件下游用户的影响。在进行研究的时候,我就发现许可证的约束力并不强,而且很多情况下是不可预测的。因此,我在文章中提出了一个能使开源许可证具有一致性和可预测性的潜在解决方案。但我只考虑到了诸如通过法律系统立法的“传统”方法。

2017 年 11 月,RedHat、IBM、Google 和 Facebook 提出了这种我从未考虑过的非传统的解决方案:GPL 合作承诺。GPL 合作承诺规定了 GPL 公平一致执行的方式。我认为,GPL 合作承诺之所以有这么深刻的意义,有以下两个原因:一是许可证的公平性和一致性对于开源社区的发展来说至关重要,二是法律对不可预测性并不容忍。

了解 GPL

要了解 GPL 合作承诺,首先要了解什么是 GPL。GPL 是 GNU 通用许可证 GNU General Public License 的缩写,它是一个公共版权的开源许可证,这就意味着开源软件的分发者必须向下游用户公开源代码。GPL 还禁止对下游的使用作出限制,要求个人用户不得拒绝他人对开源软件的使用自由、研究自由、共享自由和改进自由。GPL 规定,只要下游用户满足了许可证的要求和条件,就可以使用该许可证。如果被许可人出现了不符合许可证的情况,则视为违规。

按照第二版 GPL(GPLv2)的描述,许可证会在任何违规的情况下自动终止,这就导致了部分开发者对 GPL 有所抗拒。而在第三版 GPL(GPLv3)中则引入了“ 治愈条款 cure provision ”,这一条款规定,被许可人可以在 30 天内对违反 GPL 的行为进行改正,如果在这个缓冲期内改正完成,许可证就不会被终止。

这一规定消除了许可证被无故终止的顾虑,从而让软件的开发者和用户专注于开发和创新。

GPL 合作承诺做了什么

GPL 合作承诺将 GPLv3 的治愈条款应用于使用 GPLv2 的软件上,让使用 GPLv2 许可证的开发者避免许可证无故终止的窘境,并与 GPLv3 许可证保持一致。

很多软件开发者都希望正确合规地做好一件事情,但有时候却不了解具体的实施细节。因此,GPL 合作承诺的重要性就在于能够对软件开发者们做出一些引导,让他们避免因一些简单的错误导致许可证违规终止。

Linux 基金会技术顾问委员会在 2017 年宣布,Linux 内核项目将会采用 GPLv3 的治愈条款。在 GPL 合作承诺的推动下,很多大型科技公司和个人开发者都做出了相同的承诺,会将该条款扩展应用于他们采用 GPLv2(或 LGPLv2.1)许可证的所有软件,而不仅仅是对 Linux 内核的贡献。

GPL 合作承诺的广泛采用将会对开源社区产生非常积极的影响。如果更多的公司和个人开始采用 GPL 合作承诺,就能让大量正在使用 GPLv2 或 LGPLv2.1 许可证的软件以更公平和更可预测的形式履行许可证中的条款。

截至 2018 年 11 月,包括 IBM、Google、亚马逊、微软、腾讯、英特尔、RedHat 在内的 40 余家行业巨头公司都已经签署了 GPL 合作承诺,以期为开源社区创立公平的标准以及提供可预测的执行力。GPL 合作承诺是开源社区齐心协力引领开源未来发展方向的一个成功例子。

GPL 合作承诺能够让下游用户了解到开发者对他们的尊重,同时也表示了开发者使用了 GPLv2 许可证的代码是安全的。如果你想查阅更多信息,包括如何将自己的名字添加到 GPL 合作承诺中,可以访问 GPL 合作承诺的网站


via: https://opensource.com/article/18/11/gpl-cooperation-commitment

作者:Brooke Driver 选题:lujun9972 译者:HankChow 校对:wxy

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

前段时间,我们写了一篇关于 SoCLI 的文章,它是一个从命令行搜索和浏览 Stack Overflow 网站的 python 脚本。今天,我们将讨论一个名为 “how2” 的类似工具。它是一个命令行程序,可以从终端浏览 Stack Overflow。你可以如你在 Google 搜索中那样直接用英语查询,然后它会使用 Google 和 Stackoverflow API 来搜索给定的查询。它是使用 NodeJS 编写的自由开源程序。

使用 how2 从终端浏览 Stack Overflow

由于 how2 是一个 NodeJS 包,我们可以使用 Npm 包管理器安装它。如果你尚未安装 Npm 和 NodeJS,请参考以下指南。

在安装 Npm 和 NodeJS 后,运行以下命令安装 how2。

$ npm install -g how2

现在让我们看下如何使用这个程序浏览 Stack Overflow。使用 how2 搜索 Stack Overflow 站点的典型用法是:

$ how2 <search-query>

例如,我将搜索如何创建 tgz 存档。

$ how2 create archive tgz

哎呀!我收到以下错误。

/home/sk/.nvm/versions/node/v9.11.1/lib/node_modules/how2/node_modules/devnull/transports/transport.js:59
Transport.prototype.__proto__ = EventEmitter.prototype;
 ^

 TypeError: Cannot read property 'prototype' of undefined
 at Object.<anonymous> (/home/sk/.nvm/versions/node/v9.11.1/lib/node_modules/how2/node_modules/devnull/transports/transport.js:59:46)
 at Module._compile (internal/modules/cjs/loader.js:654:30)
 at Object.Module._extensions..js (internal/modules/cjs/loader.js:665:10)
 at Module.load (internal/modules/cjs/loader.js:566:32)
 at tryModuleLoad (internal/modules/cjs/loader.js:506:12)
 at Function.Module._load (internal/modules/cjs/loader.js:498:3)
 at Module.require (internal/modules/cjs/loader.js:598:17)
 at require (internal/modules/cjs/helpers.js:11:18)
 at Object.<anonymous> (/home/sk/.nvm/versions/node/v9.11.1/lib/node_modules/how2/node_modules/devnull/transports/stream.js:8:17)
 at Module._compile (internal/modules/cjs/loader.js:654:30)

我可能遇到了一个 bug。我希望它在未来版本中得到修复。但是,我在这里找到了一个临时方法。

要临时修复此错误,你需要使用以下命令编辑 transport.js

$ vi /home/sk/.nvm/versions/node/v9.11.1/lib/node_modules/how2/node_modules/devnull/transports/transport.js

此文件的实际路径将显示在错误输出中。用你自己的文件路径替换上述文件路径。然后找到以下行:

var EventEmitter = process.EventEmitter;

并用以下行替换它:

var EventEmitter = require('events');

ESC 并输入 :wq 以保存并退出文件。

现在再次搜索查询。

$ how2 create archive tgz

这是我的 Ubuntu 系统的示例输出。

如果你要查找的答案未显示在上面的输出中,请按空格键键开始交互式搜索,你可以通过它查看 Stack Overflow 站点中的所有建议问题和答案。

使用向上/向下箭头在结果之间移动。得到正确的答案/问题后,点击空格键或回车键在终端中打开它。

要返回并退出,请按 ESC

搜索特定语言的答案

如果你没有指定语言,它默认为 Bash unix 命令行,并立即为你提供最可能的答案。你还可以将结果缩小到特定语言,例如 perl、python、c、Java 等。

例如,使用 -l 标志仅搜索与 “Python” 语言相关的查询,如下所示。

$ how2 -l python linked list

要获得快速帮助,请输入:

$ how2 -h

总结

how2 是一个基本的命令行程序,它可以快速搜索 Stack Overflow 中的问题和答案,而无需离开终端,并且它可以很好地完成这项工作。但是,它只是 Stack overflow 的 CLI 浏览器。对于一些高级功能,例如搜索投票最多的问题,使用多个标签搜索查询,彩色界面,提交新问题和查看问题统计信息等,SoCLI 做得更好。

就是这些了。希望这篇文章有用。我将很快写一篇新的指南。在此之前,请继续关注!

干杯!


via: https://www.ostechnix.com/how-to-browse-stack-overflow-from-terminal/

作者:SK 选题:lujun9972 译者:geekpi 校对:wxy

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

如果不是一个命令行重度用户的话,过了一段时间之后,你就可能已经忘记了这些复杂且冗长的 Linux 命令了。当然,有很多方法可以让你 回想起遗忘的命令。你可以简单的 保存常用的命令 然后按需使用。也可以在终端里 标记重要的命令,然后在任何时候你想要的时间使用它们。而且,Linux 有一个内建命令 history 可以帮助你记忆这些命令。另外一个记住这些如此长的命令的简便方式就是为这些命令创建一个别名。你可以为任何经常重复调用的常用命令创建别名,而不仅仅是长命令。通过这种方法,你不必再过多地记忆这些命令。这篇文章中,我们将会在 Linux 环境下举例说明 aliasunalias 命令。

alias 命令

alias 使用一个用户自定义的字符串来代替一个或者一串命令(包括多个选项、参数)。这个字符串可以是一个简单的名字或者缩写,不管这个命令原来多么复杂。alias 命令已经预装在 shell(包括 BASH、Csh、Ksh 和 Zsh 等) 当中。

alias 的通用语法是:

alias [alias-name[=string]...]

接下来看几个例子。

列出别名

可能在你的系统中已经设置了一些别名。有些应用在你安装它们的时候可能已经自动创建了别名。要查看已经存在的别名,运行:

$ alias

或者,

$ alias -p

在我的 Arch Linux 系统中已经设置了下面这些别名。

alias betty='/home/sk/betty/main.rb'
alias ls='ls --color=auto'
alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'
alias update='newsbeuter -r && sudo pacman -Syu'

创建一个新的别名

像我之前说的,你不必去记忆这些又臭又长的命令。你甚至不必一遍一遍的运行长命令。只需要为这些命令创建一个简单易懂的别名,然后在任何你想使用的时候运行这些别名就可以了。这种方式会让你爱上命令行。

$ du -h --max-depth=1 | sort -hr

这个命令将会查找当前工作目录下的各个子目录占用的磁盘大小,并按照从大到小的顺序进行排序。这个命令有点长。我们可以像下面这样轻易地为其创建一个 别名:

$ alias du='du -h --max-depth=1 | sort -hr'

这里的 du 就是这条命令的别名。这个别名可以被设置为任何名字,主要便于记忆和区别。

在创建一个别名的时候,使用单引号或者双引号都是可以的。这两种方法最后的结果没有任何区别。

现在你可以运行这个别名(例如我们这个例子中的 du )。它和上面的原命令将会产生相同的结果。

这个别名仅限于当前 shell 会话中。一旦你退出了当前 shell 会话,别名也就失效了。为了让这些别名长久有效,你需要把它们添加到你 shell 的配置文件当中。

BASH,编辑 ~/.bashrc 文件:

$ nano ~/.bashrc

一行添加一个别名:

保存并退出这个文件。然后运行以下命令更新修改:

$ source ~/.bashrc

现在,这些别名在所有会话中都可以永久使用了。

ZSH,你需要添加这些别名到 ~/.zshrc文件中。Fish,跟上面的类似,添加这些别名到 ~/.config/fish/config.fish 文件中。

查看某个特定的命令别名

像我上面提到的,你可以使用 alias 命令列出你系统中所有的别名。如果你想查看跟给定的别名有关的命令,例如 du,只需要运行:

$ alias du
alias du='du -h --max-depth=1 | sort -hr'

像你看到的那样,上面的命令可以显示与单词 du 有关的命令。

关于 alias 命令更多的细节,参阅 man 手册页:

$ man alias

unalias 命令

跟它的名字说的一样,unalias 命令可以很轻松地从你的系统当中移除别名。unalias 命令的通用语法是:

unalias <alias-name>

要移除命令的别名,像我们之前创建的 du,只需要运行:

$ unalias du

unalias 命令不仅会从当前会话中移除别名,也会从你的 shell 配置文件中永久地移除别名。

还有一种移除别名的方法,是创建具有相同名称的新别名。

要从当前会话中移除所有的别名,使用 -a 选项:

$ unalias -a

更多细节,参阅 man 手册页。

$ man unalias

如果你经常一遍又一遍的运行这些繁杂又冗长的命令,给它们创建别名可以节省你的时间。现在是你为常用命令创建别名的时候了。

这就是所有的内容了。希望可以帮到你。还有更多的干货即将到来,敬请期待!

祝近祺!


via: https://www.ostechnix.com/the-alias-and-unalias-commands-explained-with-examples/

作者:SK 选题:lujun9972 译者:dianbanjiu 校对:wxy

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