2019年1月

JSON 已经占领了全世界。当今，任何两个应用程序彼此通过互联网通信时，可以打赌它们在使用 JSON。它已被所有大型企业所采用：十大最受欢迎的 web API 接口列表中（主要由 Google、Facebook 和 Twitter 提供），仅仅只有一个 API 接口是以 XML 的格式开放数据的。 1 这个列表中的 Twitter API 为此做了一个鲜活的注脚：其对 XML 格式的支持到 2013 年结束，其时发布的新版本的 API 取消 XML 格式，转而仅使用 JSON。JSON 也在程序编码级别和文件存储上被广泛采用：在 Stack Overflow（LCTT 译注：一个面向程序员的问答网站）上，现在更多的是关于 JSON 的问题，而不是其他的数据交换格式。 2

XML 仍然在很多地方存在。网络上它被用于 SVG 和 RSS / Atom 信息流。Android 开发者想要获得用户权限许可时，需要在其 APP 的 manifest 文件中声明 —— 此文件是 XML 格式的。XML 的替代品也不仅仅只有 JSON，现在有很多人在使用 YAML 或 Google 的 Protocol Buffers 等技术，但这些技术的受欢迎程度远不如 JSON。目前来看，JSON 是应用程序在网络之间通信的首选协议格式。

考虑到自 2005 年来 Web 编程世界就垂涎于 “异步 JavaScript 和 XML” 而非 “异步 JavaScript 和 JSON” 的技术潜力，你可以发现 JSON 的主导地位是如此的让人惊讶。当然了，这可能与这两种通信格式的受欢迎程度无关，而仅反映出缩写 “AJAX” 似乎比 “AJAJ” 更具吸引力。但是，即使在 2005 年有些人（实际上没有太多人）已经用 JSON 来取代 XML 了，我们不禁要问 XML 的噩运来的如此之快，以至于短短十来年，“异步 JavaScript 和 XML” 这个名称就成为一个很讽刺的误称。那这十来年发生了什么？JSON 怎么会在那么多应用程序中取代了 XML？现在被全世界工程师和系统所使用、依赖的这种数据格式是谁提出的？

JSON 之诞生

2001 年 4 月，首个 JSON 格式的消息被发送出来。此消息是从旧金山湾区某车库的一台计算机发出的，这是计算机历史上重要的的时刻。Douglas Crockford 和 Chip Morningstar 是一家名为 State Software 的技术咨询公司的联合创始人，他们当时聚集在 Morningstar 的车库里测试某个想法，发出了此消息。

在 “AJAX” 这个术语被创造之前，Crockford 和 Morningstar 就已经在尝试构建好用的 AJAX 应用程序了，可是浏览器对其兼容性不好。他们想要在初始页面加载后就将数据传递给应用程序，但其目标要针对所有的浏览器，这就实现不了。

这在今天看来不太可信，但是要记得 2001 年的时候 Internet Explorer（IE）代表了网页浏览器的最前沿技术产品。早在 1999 年的时候，Internet Explorer 5 就支持了原始形式的 XMLHttpRequest，开发者可以使用名为 ActiveX 的框架来访问此对象。Crockford 和 Morningstar 能够使用此技术（在 IE 中）来获取数据，但是在 Netscape 4 中（这是他们想要支持的另一种浏览器）就无法使用这种解决方案。为此 Crockford 和 Morningstar 只得使用一套不同的系统以兼容不同的浏览器。

第一条 JSON 消息如下所示：

<html><head><script>
    document.domain = 'fudco';
    parent.session.receive(
        { to: "session", do: "test",
          text: "Hello world" }
    )
</script></head></html>

消息中只有一小部分类似于今天我们所知的 JSON，本身其实是一个包含有一些 JavaScript 的 HTML 文档。类似于 JSON 的部分只是传递给名为 receive() 的函数的 JavaScript 对象字面量。

Crockford 和 Morningstar 决定滥用 HTML 的帧（<frame>）以发送数据。他们可以让一个帧指向一个返回的上述 HTML 文档的 URL。当接收到 HTML 时，JavaScript 代码段就会运行，就可以把数据对象字面量如实地传递回应用程序。只要小心的回避浏览器保护策略（即子窗口不允许访问父窗口），这种技术就可以正常运行无误。可以看到 Crockford 和 Mornginstar 通过明确地设置文档域这种方法来达到其目的。（这种基于帧的技术，有时称为隐藏帧技术，通常在 90 年代后期，即在广泛使用 XMLHttpRequest 技术之前使用。 3 ）

第一个 JSON 消息的惊人之处在于，它显然不是一种新的数据格式的首次使用。它就是 JavaScript！实际上，以此方式使用 JavaScript 的想法如此简单，Crockford 自己也说过他不是第一个这样做的人。他说 Netscape 公司的某人早在 1996 年就使用 JavaScript 数组字面量来交换信息。 4 因为消息就是 JavaScript，其不需要任何特殊解析工作，JavaScript 解释器就可搞定一切。

最初的 JSON 信息实际上与 JavaScript 解释器发生了冲突。JavaScript 保留了大量的关键字（ECMAScript 6 版本就有 64 个保留字），Crockford 和 Morningstar 无意中在其 JSON 中使用了一个保留字。他们使用了 do 作为了键名，但 do 是解释器中的保留字。因为 JavaScript 使用的保留字太多了，Crockford 做了决定：既然不可避免的要使用到这些保留字，那就要求所有的 JSON 键名都加上引号。被引起来的键名会被 JavaScript 解释器识别成字符串，其意味着那些保留字也可以放心安全的使用。这就为什么今天 JSON 键名都要用引号引起来的原因。

Crockford 和 Morningstar 意识到这技术可以应用于各类应用系统。想给其命名为 “JSML”，即 JavaScript 标记语言 JavaScript Markup Language 的意思，但发现这个缩写已经被一个名为 Java Speech 标记语言的东西所使用了。因此他们决定采用 “JavaScript Object Notation”，缩写为 JSON。他们开始向客户推销，但很快发现客户不愿意冒险使用缺乏官方规范的未知技术。所以 Crockford 决定写一个规范。

2002 年，Crockford 买下了 JSON.org 域名，放上了 JSON 语法及一个解释器的实例例子。该网站仍然在运行，现在已经包含有 2013 年正式批准的 JSON ECMA 标准的显著链接。在该网站建立后，Crockford 并没有过多的推广，但很快发现很多人都在提交各种不同编程语言的 JSON 解析器实现。JSON 的血统显然与 JavaScript 相关联，但很明显 JSON 非常适合于不同语言之间的数据交换。

AJAX 导致的误会

2005 年，JSON 有了一次大爆发。那一年，一位名叫 Jesse James Garrett 的网页设计师和开发者在博客文章中创造了 “AJAX” 一词。他很谨慎地强调：AJAX 并不是新技术，而是 “好几种蓬勃发展的技术以某种强大的新方式汇集在一起。 5 ” AJAX 是 Garrett 给这种正受到青睐的 Web 应用程序的新开发方法的命名。他的博客文章接着描述了开发人员如何利用 JavaScript 和 XMLHttpRequest 构建新型应用程序，这些应用程序比传统的网页更具响应性和状态性。他还以 Gmail 和 Flickr 网站已经使用 AJAX 技术作为了例子。

当然了，“AJAX” 中的 “X” 代表 XML。但在随后的问答帖子中，Garrett 指出，JSON 可以完全替代 XML。他写道：“虽然 XML 是 AJAX 客户端进行数据输入、输出的最完善的技术，但要实现同样的效果，也可以使用像 JavaScript Object Notation（JSON）或任何类似的结构数据方法等技术。 ” 6

开发者确实发现在构建 AJAX 应用程序时可以很容易的使用 JSON，许多人更喜欢它而不是 XML。具有讽刺意味的是，对 AJAX 的兴趣逐渐的导致了 JSON 的普及。大约在这个时候，JSON 引起了博客圈的注意。

2006 年，Dave Winer，一位高产的博主，他也是许多基于 XML 的技术（如 RSS 和 XML-RPC）背后的开发工程师，他抱怨到 JSON 毫无疑问的正在重新发明 XML。尽管人们认为数据交换格式之间的竞争不会导致某一技术的消亡。其写到：

毫无疑问，我可以编写一个例程来解析 JSON，但来看看他们要重新发明一个东西有多大的意义，出于某种原因 XML 本身对他们来说还不够好（我很想听听原因）。谁想干这荒谬之事？查找一棵树然后把节点串起来。可以立马试试。 7

我很理解 Winer 的挫败感。事实上并没有太多人喜欢 XML。甚至 Winer 也说过他不喜欢 XML。 8 但 XML 已被设计成一个可供任何人使用，并且可以用于几乎能想象到的所有事情。归根到底，XML 实际上是一门元语言，允许你为特定应用程序自定义该领域特定的语言。如 Web 信息流技术 RSS 和 SOAP（简单对象访问协议）就是例子。Winer 认为由于通用交换格式所带来的好处，努力达成共识非常重要。XML 的灵活性应该能满足任何人的需求，然而 JSON 格式呢，其并没有比 XML 提供更多东西，除了它抛弃了使 XML 更灵活的那些繁琐的东西。

Crockford 阅读了 Winer 的这篇文章并留下了评论。为了回应 JSON 重新发明 XML 的指责，Crockford 写到：“重造轮子的好处是可以得到一个更好的轮子。” 9

JSON 与 XML 对比

到 2014 年，JSON 已经由 ECMA 标准和 RFC 官方正式认可。它有了自己的 MIME 类型。JSON 已经进入了大联盟时代。

为什么 JSON 比 XML 更受欢迎？

在 JSON.org 网站上，Crockford 总结了一些 JSON 的优势。他写到，JSON 的语法极少，其结构可预测，因此 JSON 更容易被人类和机器理解。 10 其他博主一直关注 XML 的冗长啰嗦及“尖括号负担”。 11 XML 中每个开始标记都必须与结束标记匹配，这意味着 XML 文档包含大量的冗余信息。在未压缩时，XML 文档的体积比同等信息量 JSON 文档的体积大很多，但是，更重要的，这也使 XML 文档更难以阅读。

Crockford 还声称 JSON 的另一个巨大优势是其被设计为数据交换格式。 12 从一开始，它的目的就是在应用程序间传递结构化信息的。而 XML 呢，虽然也可以使用来传递数据，但其最初被设计为文档标记语言。它演变自 SGML（通用标准标记语言），而它又是从被称为 Scribe 的标记语言演变而来，其旨在发展成类似于 LaTeX 一样的文字处理系统。XML 中，一个标签可以包含有所谓的“混合内容”，即带有围绕单词、短语的内嵌标签的文本。这会让人浮现出一副用红蓝笔记录的手稿画面，这是标记语言核心思想的形象比喻。另一方面，JSON 不支持对混合内容模型的清晰构建，但这也意味着它的结构足够简单。一份文档最好的建模就是一棵树，但 JSON 抛弃了这种文档的思想，Crockford 将 JSON 抽象限制为字典和数组，这是所有程序员构建程序时都会使用的最基本的、也最熟悉的元素。

最后，我认为人们不喜欢 XML 是因为它让人困惑。它让人迷惑的地方就是有很多不同的风格。乍一看，XML 本身及其子语言（如 RSS、ATOM、SOAP 或 SVG）之间的界限并不明显。典型的 XML 文档的第一行标识了该 XML 的版本，然后该 XML 文档应该符合特定的子语言。这就有变化需要考虑了，特别是跟 JSON 做比较，JSON 是如此简单，以至于永远不需要编写新版本的 JSON 规范。XML 的设计者试图将 XML 做为唯一的数据交换格式以支配所有格式，就会掉入那个经典的程序员陷阱：过度工程化。XML 非常笼统及概念化，所以很难于简单的使用。

在 2000 年的时候，发起了一场使 HTML 符合 XML 标准的活动，发布了一份符合 XML 标准的 HTML 开发规范，这就此后很出名的 XHTML。虽然一些浏览器厂商立即开始支持这个新标准，但也很明显，大部分基于 HTML 技术的开发者不愿意改变他们的习惯。新标准要求对 XHTML 文档进行严格的验证，而不是基于 HTML 的基准。但大多的网站都是依赖于 HTML 的宽容规则的。到 2009 年的时候，试图编写第二版本的 XHTML 标准的努力已经流产，因为未来已清晰可见，HTML 将会发展为 HTML5（一种不强制要求接受 XML 规则的标准）。

如果 XHTML 的努力取得了成功，那么 XML 可能会成为其设计者所希望的通用数据格式。想象一下，一个 HTML 文档和 API 响应具有完全相同结构的世界。在这样的世界中，JSON 可能不会像现在一样普遍存在。但我把 HTML 的失败看做是 XML 阵营的一种道义上的失败。如果 XML 不是 HTML 的最佳工具，那么对于其他应用程序，也许会有更好的工具出现。在这个世界，我们的世界，很容易看到像 JSON 格式这样的足够简单、量体裁衣的才能获得更大的成功。

如果你喜欢这博文，每两周会更新一次！ 请在 Twitter 上关注 @TwoBitHistory 或订阅 RSS feed，以确保得到更新的通知。

  1. http://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html#software ↩
  2. https://insights.stackoverflow.com/trends?tags=json%2Cxml%2Cprotocol-buffers%2Cyaml%2Ccsv ↩
  3. Zakas, Nicholas C., et al. “What Is Ajax?” Professional Ajax, 2nd ed., Wiley, 2007. ↩
  4. https://youtu.be/-C-JoyNuQJs?t=32s ↩
  5. http://adaptivepath.org/ideas/ajax-new-approach-web-applications/ ↩
  6. 同上 ↩
  7. http://scripting.com/2006/12/20.html ↩
  8. http://blogoscoped.com/archive/2009-03-05-n15.html ↩
  9. https://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26383 ↩
  10. http://www.json.org/xml.html ↩
  11. https://blog.codinghorror.com/xml-the-angle-bracket-tax ↩
  12. https://youtu.be/-C-JoyNuQJs?t=33m50sgg ↩

via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html

作者：Two-Bit History 选题：lujun9972 译者：runningwater 校对：wxy

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

Beamer 将 LaTeX 强大的排版功能和生态系统带进创建幻灯片中。

Beamer 是用于生成幻灯片的 LaTeX 包。它最棒的功能之一是它可以利用 LaTeX 强大的排版系统和其生态系统中的所有其他软件包。例如，我经常在包含代码的 Beamer 演示文稿中使用 LaTeX 的 listings 包。

创建演示文稿

要创建一个 Beamer 文档，输入：

\documentclass{beamer}

与任何其他 LaTeX 文档一样，添加你要使用的任何包。例如，要使用 listings 包，请输入：

\usepackage{listings}

将所有内容放在 document 环境中：

\begin{document}

Beamer 文档通常时是一系列的 frame 环境。包含代码的 frame 应该被标记为 fragile：

\begin{frame}[fragile]

使用标题开始你的 frame：

\frametitle{Function to Do Stuff}

开始演示前测试你的代码

世上最糟糕的感受之一你在演讲中说到代码时，突然发现了一个 bug —— 也许是拼错了关键词或者漏掉了括号。

解决方法之一就是测试演示的代码。在多数演示环境中，这意味着创建一个单独的文件、编写测试接着拷贝和粘贴。

然而，在 Beamer 中有一种更好的方法。想象一下，你有一个名为 do_stuff.py 的文件，其中包含代码。你可以在第二个文件中编写 do_stuff.py 代码的测试，你可以将其命名为 test_do_stuff.py，并且可以使用 pytest 测试。但是，do_stuff.py 中的大多数行都缺乏教学价值，比如定义辅助函数。

要简化你受众看到的东西，你可在演示文稿中只导入你要讨论的行到 frame 中：

\lstinputlisting[
    language=Python,
    firstline=8,
    lastline=15
]{do_stuff.py}

由于你会对这几行（从 8 到 15）进行讨论，因此幻灯片上不需要任何其他内容。结束 frame：

\end{frame}

在下一张幻灯片中，你想展示刚才的 do_stuff() 函数的用法示例：

\begin{frame}[fragile]
\frametitle{Calling Function to Do Stuff}
\lstinputlisting[
    language=Python,
    firstline=17,
    lastline=19
]{do_stuff.py}
\end{frame}

你使用相同的文件，但这次显示调用该函数的行。最后，结束 document：

\end{document}

假设你在 do_stuff.py 中有一个合适的 Python 文件，这将生成一个含有 2 页的幻灯片。

Beamer 还支持必要的功能如渐进式演示，每次给观众展示一部分以免受到前面的打扰。在行中放入 \pause 会将页面分成不同的部分：

\begin{frame}
Remember:
\begin{itemize}
\item This will show up on the first slide. \pause
\item This will show up on the
      second slide, as well as the preceding point. \pause
\item Finally, on the third slide,
       all three bullets will show up.
\end{frame}

创建讲义

Beamer 中我最喜欢的功能是可以用 \documentclass[ignorenonframetext]{beamer} 设置忽略 frame 外的所有内容。当我准备演示文稿时，我离开顶部（声明文档类的位置）并自动生成它的两个版本：我的演示稿使用 Beamer 忽略任何 frame 之外的所有文本，另一个含有类似这样的头：

\documentclass{article}
\usepackage{beamerarticle}

这会生成一份讲义：一份含有所有 frame 和它们之间文字的 PDF。

当会议组织者要求我发布我的幻灯片时，我会包含原始幻灯片作为参考，但我希望人们拿到的是讲义，它包含了所有我不想在幻灯片上写的解释部分。

在创建幻灯片时，人们经常会考虑是为演讲优化讲稿还是为之后想要阅读它的人们优化。幸运的是，Beamer 提供了两全其美的办法。

via: https://opensource.com/article/19/1/create-presentations-beamer

作者：Moshe Zadka 选题：lujun9972 译者：geekpi 校对：wxy

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

不是所有的程序都可以在官方或者第三方库中找到，因此你不能使用常规的包管理来安装它们。有时你不得不从源代码中手动构建这些程序。就如你已经知道的一样，当你从源代码中安装一个程序的时候，这个软件包所包含的文件将会复制到本地的多个位置，例如 /usr/local/bin、/usr/local/etc/。如果从源代码中安装的程序没有内置的卸载程序，当你不再需要这个程序的时候，卸载它就会很麻烦。你可能会花费双倍（甚至更多）的时间找出这些文件然后手动删除它们。我以前一直是这样做的，直到我发现了 GNU Stow。谢天谢地，Stow 有一个很棒的方法可以轻松管理从源代码安装的程序。

引用官方网站里的一段介绍，

GNU Stow 是一个符号链接归集管理器，它可以收集文件系统上不同目录中的不同软件和/或数据包，使它们看起来像是一个整体。

简单来说，Stow 帮助你把这些程序文件以一种容易管理的方式组织在了一起。在这个方法中，文件将不会被复制到多个位置。所有的这些文件都会被保存在一个特定的文件夹中，通常是以程序名命名的，然后 Stow 会在一个合适的位置为所有的程序文件创建符号连接。比如 /usr/local/bin 中会包含 /usr/local/stow/vim/bin、/usr/local/stow/python/bin 中文件的符号链接。并且同样递归地用于其他的任何的子目录，例如 .../share、.../man，等等。在这篇教程中，我将会举例教你如何轻松地使用 Stow 管理从源中安装的程序。

安装 GNU Stow

GNU Stow 在流行 Linux 操作系统的默认库中都可用。

在 Arch Linux 及它的衍生版本中，运行下面的命令安装 Stow。

$ sudo pacman -S stow

在 Debian、Ubuntu、Linux Mint 上：

$ sudo apt install stow

在 Fedora 上：

$ sudo dnf install stow

在 RHEL/CentOS 上：

$ sudo yum install epel-release
$ sudo yum install stow

在 Linux 上轻松移除从源代码安装的程序

就像我之前提到的，所有包的程序文件都将被保存在位于 /usr/local/stow/ 的一个根文件夹。在这个根文件夹或者父目录之下，每个包都将保存在对应的子目录中。例如，如果我们从源代码中安装了 Vim 编辑器，所有关联到 Vim 的程序文件和目录都将保存在 /usr/local/stow/vim 文件夹之下。如果你从源代码中安装了 Python，所有关联到 python 的文件都会保存在 /usr/local/stow/python 之下。

我现在从源代码中来安装一个叫做 hello 的程序。

首先下载 hello 程序的压缩包。

$ wget http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

使用下面的命令解压压缩包：

$ tar -zxvf hello-2.10.tar.gz

上面的命令将会在当前工作目录下创建一个叫做 hello-2.10 的目录，并且提取压缩包中的所有内容到其中去。

切换到这个目录当中：

$ cd hello-2.10/

运行下面的命令，并且添加 -prefix 选项。

$ ./configure --prefix=/usr/local/stow/hello

上面的命令将会保存构建文件到一个指定位置，在这个例子中是 /usr/local/stow/hello。

最后，使用下面的命令构建并安装 hello 这个程序：

$ make
$ sudo make install

就这样。hello 这个程序就已经安装在 /usr/local/stow/hello/ 这个位置了。你可以使用下面的 ls 命令确认一下。

$ ls /usr/local/stow/hello/
bin share

最后，进入 /usr/local/stow/ 目录，运行下面的命令来生成必要的符号链接。

$ cd /usr/local/stow/
$ sudo stow hello

大功告成！

刚才那一步是将包含在 hello 这个程序中的所有文件或者目录创建了链接到 /usr/local/ 目录中。换一种说法， /usr/local/stow/hello/bin 链接到 /usr/local/share，以及 /usr/local/stow/hello/share/man 链接到 /usr/local/share，还有 /usr/local/stow/hello/share/man 链接到 /usr/local/share/man。

你可以使用 ls 命令来确认一下：

$ ls /usr/local/bin/
hello

可以使用下面的命令来确认 hello 这个程序是否可以正常工作了：

$ hello
Hello, world!

很好，它已经开始工作了！！

类似地，你可以像上面描述的那样安装程序到它对应的子目录下。

下面是 Stow 根目录包含的内容：

$ tree /usr/local/stow/

看，hello 这个程序已经安装在 /usr/local/stow/hello/ 下。同样地，所有的包都将保存在它们对应的目录之下。

下面进入主要环节，移除 hello 这个程序。首先进入 /usr/local/stow/ 目录：

$ cd /usr/local/stow/

然后运行下面的命令：

$ sudo stow --delete hello

hello 这个程序就会被移除了。你可以使用下面的命令确认它是否真的被移除了：

$ hello
-bash: /usr/local/bin/hello: No such file or directory

看， Hello 已经被移除了！

请注意 Stow 仅仅只移除了符号链接。所有与 hello 这个程序相关的文件或者目录还保存在 /usr/local/stow/hello 目录下。所以你无需再次下载源文件就可以再次安装 hello 这个程序。如果你不再需要它了，直接删除这个文件夹即可。

$ sudo rm -fr /usr/local/stow/hello/

想了解更多 Stow 的细节，请参阅 man 手册。

$ man stow

Stow 可以像安装程序一样轻松地帮你移除它。如果你想知道如何高效的管理很多从源代码中安装的程序，GNU Stow 就是一个使得这个任务更加轻松的一个选择，尝试一下，你一定不会失望的。

这就是所有的内容了，希望对你有所帮助。还有更多干活即将到来，可以期待一下的！

祝近祺！

via: https://www.ostechnix.com/an-easy-way-to-remove-programs-installed-from-source-in-linux/

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

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

使用这些工具从远程了解天气、阅读资料等。

我们即将结束为期 24 天的 Linux 命令行玩具日历。希望你有一直在看，如果没有，请回到开始，从头看过来。你会发现 Linux 终端有很多游戏、消遣和奇怪之处。

虽然你之前可能已经看过我们日历中的一些玩具，但我们希望每个人都遇见一个新事物。

今天的玩具（实际是玩具集合）有点不同。到目前为止，我主要是想把重点放在那些独立的玩具上，并且完全可在开源许可下使用。但是我从读者那里得到了一些很好的建议，利用开源工具远程访问一些开源或者不开源的东西。今天，我将介绍其中的一些。

第一个是经典之作：使用 Telnet 观看星球大战的 ASCII 演绎版本。你的系统可能已经安装了 Telnet，因此你只需运行：

$ telnet towel.blinkenlights.nl

我第一次看到它是十年之前，因此我对于它还存在有点惊奇。如果你还没看过，请留出一点时间看一下。你不会后悔的。

接下来，Opensource.com 的撰稿人 Manuel Dewald 提出了一种从终端获取当地天气的方法。它很简单，你只需安装 curl（或者，wget）。

$ curl wttr.in

最后，在假期中虽然你可以从命令行 Web 浏览器浏览你喜欢的网站（包括 Opensource.com），但有一些我最喜欢的网站可以通过专用客户端更轻松地浏览。其中两个是 Reddit 和 Hacker News，有人推荐给我一些它们的客户端，你可能也想尝试，它们都使用开源许可。我尝试过 haxor-news （Hacker News） 和 rtv （Reddit），它们都还不错。

你有特别喜欢的命令行小玩具需要我介绍的吗？提交今年的建议有点晚了，但我们仍然希望在新的一年里有一些很酷的命令行玩具。请在下面的评论中告诉我，我会查看的。让我知道你对今天的玩具有何看法。

一定要看看昨天的玩具，在 Linux 终端收看 Youtube 视频，明天还要再来！

via: https://opensource.com/article/18/12/linux-toy-remote

作者：Jason Baker 选题：lujun9972 译者：geekpi 校对：wxy

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

有了这个 20 世纪 70 年代的经典重制游戏，Python 将不再是你在 Linux 终端能发现的唯一的“蛇”。

欢迎回到 Linux 命令行玩具日历。如果这是你第一次访问该系列，你可能会问什么是命令行玩具。这很难确切地说，但我的定义是任何可以帮助你在终端玩得开心的东西。

我们这周都在介绍游戏，这很有趣，接着让我们看下今天的游戏，贪吃蛇！

贪吃蛇是一个古老又很好的游戏，这些年一直有各种版本。我记得我第一次玩得版本是 20 世纪 90 年代与 QBasic 一起打包发布的 Nibbles)，它对我理解什么是编程语言起了很重要的作用。我有游戏的源码，我可以修改并查看会发生什么，并学习到一些组成这个编程语言的有趣词汇究竟是什么意思。

今天的贪吃蛇是用 Go 写的，它很简单并且和原版的游戏一样有趣。像大多数简单的老游戏一样，它有很多版本可供选择。这今天的贪吃蛇中，甚至还有一个经典的 bsdgames 形式的包，它的发行版几乎一定有它。

但我喜欢的是用 Docker 打包的贪吃蛇，因为我可以轻松地在命令行中运行，而不用担心发行版相关的问题。这个版本使用 15 个随机的食物 emoji 图案让蛇来吃。我玩得不好。不管怎样，请试一下：

$ docker run -ti dyego/snake-game

这个贪吃蛇以 MIT 许可证开源，你可在 Github 取得源码。

你有特别喜欢的命令行小玩具需要我介绍的吗？这个系列要介绍的小玩具大部分已经有了落实，但还预留了几个空位置。请在评论区留言，我会查看的。如果还有空位置，我会考虑介绍它的。如果没有，但如果我得到了一些很好的意见，我会在最后做一些有价值的提及。

请查看昨天的玩具，数字 2 的力量，Linux 的力量：在命令行中玩 2048，记得明天再来！

via: https://opensource.com/article/18/12/linux-toy-snake

作者：Jason Baker 选题：lujun9972 译者：geekpi 校对：wxy

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

在这个系列的第一篇中，学习一下管理笔记本电脑和台式机配置的基础内容。

配置管理是服务器管理和 DevOps 的一个非常重要的方面。“ 基础架构即代码 infrastructure as code ”方法可以轻松地以各种配置部署服务器，并动态扩展组织的资源以满足用户需求。但是，对于希望自动设置自己的笔记本电脑和台式机（工作站）的个人管理员的关注较少。

在本系列中，我将向你展示如何通过 Ansible 自动化你的工作站设置，如果你想要或需要重新安装你的机器，这可以让你轻松恢复整个配置。此外，如果你有多个工作站，则可以使用相同的方法在每个工作站上进行相同的配置。在第一篇文章中，我们将为个人或工作计算机设置基本的配置管理，并为本系列的其余部分奠定基础。到本文结束时，你将会因此得到一个可以工作的环境。本系列之后的每篇文章都会自动化更多内容并增加复杂性。

为什么用 Ansible？

有许多配置管理解决方案，包括 Salt Stack、Chef 和 Puppet。我更喜欢 Ansible，因为它在资源利用方面更轻量级，语法更容易阅读，并且如果正确使用它可以彻底改变你的配置管理。Ansible 的轻量级特性与这个主题特别相关，因为我们可能不希望运行一整台服务器而只是为了自动化我们的笔记本电脑和台式机的设置。一般我们总是想要快一些；我们可以使用某些东西来快速启动和运行，以在我们需要恢复的工作站或在多台机器之间同步我们的配置。我使用 Ansible 的具体方法（我将在本文中演示）非常适用于此，而不需要维护服务器。你只需下载配置并运行它。

我的方法

通常，Ansible 运行于中央服务器。它使用一个 库存清单 inventory 文件，该文件是一个文本文件，其中包含我们希望 Ansible 管理的所有主机及其 IP 地址或域名的列表。这对于静态环境非常有用，但对于工作站来说并不理想。原因是我们真的不知道我们的工作站在某一时刻的状态。也许我关闭了台式电脑，或者笔记本电脑可能会被挂起并放在我的包里。在任何一种情况下，Ansible 服务器都会抱怨，因为如果它们处于脱机状态，Ansible 就无法联系到我的机器。我们更需要的是按需方式，我们通过利用 ansible-pull 来实现这一目标。ansible-pull 命令是 Ansible 的一个命令，允许你从 Git 仓库下载配置并立即应用它。你不需要维护服务器或库存清单；你只需运行 ansible-pull 命令，给它一个 Git 仓库 URL，它将为你完成剩下的工作。

起步

首先，在要管理的计算机上安装 Ansible。有一个问题是许多发行版都附带了旧版本的 Ansible。根据经验，你肯定希望获得最新版本。Ansible 中经常引入新功能，如果你运行的是旧版本，则你在网上找到的示例语法可能无法正常运行，因为它使用的功能未在你安装的版本中实现。甚至发布的小版本都有很多新功能。其中一个例子是 dconf 模块，它是从 Ansible 2.4 开始的新功能。如果你尝试使用使用此模块的语法，除非你使用 2.4 或更新版本，否则会失败。在 Ubuntu 及其衍生产品中，我们可以使用官方个人包存档（PPA）轻松安装最新版本的 Ansible。以下命令可以解决这个问题：

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

如果你没有使用 Ubuntu，请参阅 Ansible 的文档 了解如何为你的平台获取它。

接下来，我们需要一个 Git 仓库来保存我们的配置。满足此要求的最简单方法是在 GitHub 上创建一个空的仓库，或者如果有的话，也可以使用自己的 Git 服务器。为了简单起见，我假设你正在使用 GitHub，因此如果你正在使用其他仓库，请相应调整命令。在 GitHub 中创建一个仓库；你最终会得到一个与此类似的仓库 URL：

[email protected]:<your_user_name>/ansible.git

将该仓库克隆到你的本地工作目录（忽略任何抱怨仓库为空的消息）：

git clone [email protected]:<your_user_name>/ansible.git

现在我们有了一个可以使用的空仓库。将你的工作目录切换到仓库（例如 cd ./ansible），并在你喜欢的文本编辑器中创建名为 local.yml 的文件。将以下配置放在该文件中：

- hosts: localhost
  become: true
  tasks:
  - name: Install htop
    apt: name=htop

你刚刚创建的文件被称为 剧本 playbook ，安装 htop 的指令（我任意选择的一个包作为例子）被称为 动作 play 。剧本本身是一个 YAML 格式的文件，它是一种易于阅读的标记语言。对 YAML 的完整讲述超出了本文的范围，但你无需专业理解即可熟练使用 Ansible。该配置易于阅读；只需查看此文件，你就可以轻松理解我们正在安装的 htop 软件包。要注意一下最后一行的 apt 模块，它只适用于基于 Debian 的系统。如果你使用的是 Red Hat 平台，你可以将其更改为 yum 而不是 apt，或者如果你正在使用 Fedora，则将其更改为 dnf。name 行只是提供有关我们任务的信息，并将显示在输出中。因此，你需要确保名称具有描述性，以便在需要对多个动作进行故障排除时很容易找到。

接下来，让我们将新文件提交到我们的仓库：

git add local.yml
git commit -m "initial commit"
git push origin master

现在我们的新剧本应该出现在我们的 GitHub 上的仓库中。我们可以使用以下命令应用我们创建的剧本：

sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git

如果执行正确，htop包应该会安装在你的系统上。你可能会在开头附近看到一些警告，抱怨缺少库存清单文件。这很好，因为我们没有使用库存清单文件（我们也不需要这样做）。在输出结束时，它将概述它做的内容。如果 htop 安装正确，你应该在输出的最后一行看到 changed = 1。

它是如何工作的呢？ansible-pull 命令使用了 -U 选项，它需要一个仓库 URL。出于安全考虑，我给它提供了仓库 URL 的 https 版本，因为我不希望任何主机对仓库具有写访问权限（默认情况下 https 是只读的）。local.yml 是预设的剧本名称，因此我们不需要为剧本提供文件名：如果它在仓库的根目录中找到名为 local.yml 的剧本，它将自动运行它。接下来，我们在命令前面使用了 sudo，因为我们正在修改系统。

让我们继续为我们的剧本添加更多的包。我将添加两个包，使它看起来像这样：

- hosts: localhost
  become: true
  tasks:
  - name: Install htop
    apt: name=htop

  - name: Install mc
    apt: name=mc
   
  - name: Install tmux
    apt: name=tmux

我添加了更多的动作（任务）来安装另外两个包，mc 和 tmux。在此剧本中选择安装的哪些软件包并不重要；我只是随意挑选这些。你应该安装你希望所有的系统都具有的软件包。唯一需要注意的是，在你分发前，你必须知道那个包存在于软件仓库中。

在我们提交并应用这个更新的剧本之前，我们应该整理一下它。它可以很好地工作，但（说实话）它看起来有点混乱。让我们尝试在一个动作中安装所有三个包。用下面这个替换你的 local.yml 的内容：

- hosts: localhost
  become: true
  tasks:
  - name: Install packages
    apt: name={{item}}
    with_items:
      - htop
      - mc
      - tmux

现在看起来更干净、更有效率了。我们使用 with_items 将我们的包列表合并为一个动作。如果我们想要添加其他包，我们只需添加另一个带有连字符和包名称的行。可以把 with_items 看做类似于 for 循环。我们列出的每个包都将安装。

将我们的新更改提交回仓库：

git add local.yml
git commit -m "added additional packages, cleaned up formatting"
git push origin master

现在我们可以运行我们的剧本以接受新的新配置：

sudo ansible-pull -U https://github.com/<your_user_name>/ansible.git

不可否认，这个例子还没有做多少事情；它所做的就是安装一些软件包。你可以使用包管理器更快地安装这些包。然而，随着这个系列的继续，这些例子将变得更加复杂，我们将自动化更多的东西。最后，你创建的 Ansible 配置将自动执行越来越多的任务。例如，我自己使用的那个配置可以自动安装数百个软件包、设置cron 作业、处理桌面配置等等。

从我们迄今为止所取得的成就来看，你可能已经有了大概了解。我们所要做的就是创建一个仓库，在该仓库中放置一个剧本，然后利用 ansible-pull 命令拉取该仓库并将其应用到我们的机器上。我们不需要设置服务器。将来，如果我们想要更改配置，我们可以拉取该仓库、更新它，然后将其推回到我们的仓库并应用它。如果我们要设置新机器，我们只需要安装 Ansible 并应用配置。

在下一篇文章中，我们将通过 cron 和一些其他项目进一步自动化。与此同时，我已将本文的代码复制到 我的 GitHub 仓库 中，以便你可以用你的语法对比一下我的。随着我们的进展，我会不断更新代码。

via: https://opensource.com/article/18/3/manage-workstation-ansible

作者：Jay LaCroix 译者：wxy 校对：wxy

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

  1. 1
  2. ...
  3. 6
  4. 7
  5. 8
  6. 9
  7. 10
  8. 11
  9. 12
  10. ...
  11. 15