Merge remote-tracking branch 'LCTT/master'

This commit is contained in:
Xingyu.Wang 2019-01-10 11:19:31 +08:00
commit b4c985a30d
10 changed files with 381 additions and 382 deletions

View File

@ -1,40 +1,38 @@
[#]: collector: (lujun9972)
[#]: translator: (qhwdw)
[#]: reviewer: ()
[#]: publisher: ()
[#]: url: ()
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-10429-1.html)
[#]: subject: (Computer Laboratory Raspberry Pi: Lesson 0 Introduction)
[#]: via: (https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html)
[#]: author: (Robert Mullins http://www.cl.cam.ac.uk/~rdm34)
计算机实验室 树莓派:课程 0简介
计算机实验室之树莓派:课程 0 简介
======
这个课程简介不包含实践内容,但它解释了一个操作系统的基本概念、汇编代码、和其它很重要的一些基本原理。如果你想直接进入实践环节,跳过本课程并不会有什么问题。
### 1、操作系统
一个操作系统就是一个非常复杂的程序。它的任务就是组织安排计算机上的其它程序,包括共享计算机的时间、内存、硬件和其它资源。你可能听说过的一些比较大的桌面操作系统家族有 GNU/Linux、Mac OS X 和 Microsoft Windows。其它的设备比如电话也需要操作系统它可能使用的操作系统是 Android、iOS 和 [Windows Phone][https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html#note1]
操作系统就是一个非常复杂的程序。它的任务就是组织安排计算机上的其它程序,包括共享计算机的时间、内存、硬件和其它资源。你可能听说过的一些比较大的桌面操作系统家族有 GNU/Linux、Mac OS X 和 Microsoft Windows。其它的设备比如电话也需要操作系统它可能使用的操作系统是 Android、iOS 和 [Windows Phone](https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html#note1)。
由于操作系统是用来与计算机系统上的硬件进行交互的,所以它必须有系统上硬件专有的内容。为了能让操作系统适用于各种类型的计算机,发明了 **驱动程序** 的概念。驱动程序是为了能够让操作系统与特定的硬件进行交互而添加(并可删除)到操作系统上的一小部分代码。在本课程中,我们并不涉及如何创建可删除的驱动程序,而是专注于特定的一个硬件:树莓派。
由于操作系统是用来与计算机系统上的硬件进行交互的,所以它必须了解系统上硬件专有的信息。为了能让操作系统适用于各种类型的计算机,发明了 **驱动程序** 的概念。驱动程序是为了能够让操作系统与特定的硬件进行交互而添加(并可删除)到操作系统上的一小部分代码。在本课程中,我们并不涉及如何创建可删除的驱动程序,而是专注于特定的一个硬件:树莓派。
操作系统有各种不同的设计方式,在本课程中,我们只触及操作系统设计的皮毛。本课程中,我们主要专注于操作系统与各种硬件的交互部分,因为这经常是比较棘手的部分,并且也是在网络上文档和帮助最少的部分。
### 2、汇编代码
```
一个处理器每秒可以执行上百万的指令,但是这些指令必须要简单。
```
> 处理器每秒可以执行上百万的指令,但是这些指令必须要简单。
本课程几乎要完全靠汇编代码来写。汇编代码非常接近计算机的底层。计算机其实是靠一个叫处理器的设备来工作的,处理器能够执行像加法这样的简单任务,还有一组叫做 **RAM** 的芯片,它能够用来保存数字。当计算机通电后,处理器执行程序员给定的一系列指令,这将导致内存中的数字发生变化,以及与连接的硬件进行交互。汇编代码只是将这些机器命令转换为人类可读的文本。
本课程几乎要完全靠汇编代码来写。汇编代码非常接近计算机的底层。计算机其实是靠一个叫处理器的设备来工作的,处理器能够执行像加法这样的简单任务,还有一组叫做 RAM 的芯片,它能够用来保存数字。当计算机通电后,处理器执行程序员给定的一系列指令,这将导致内存中的数字发生变化,以及与连接的硬件进行交互。汇编代码只是将这些机器命令转换为人类可读的文本。
常规的编程就是,程序员使用编程语言,比如 C++、Java、C#、Basic等等来写代码,然后一个叫编译器的程序将程序员写的代码转换成汇编代码,然后进一步转换为[二进制代码][https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html#note2]。二进制代码才是计算机真正能够理解的东西,但它是人类无法读取的东西。汇编代码比二进制代码好一点,至少它的命令是人类可读的,但它仍然让人很沮丧。请记住,你用汇编代码写的每个命令都是处理器可以直接认识的,因此这些命令设计的很简单,因为物理电路必须能够处理每个命令。
常规的编程就是,程序员使用编程语言,比如 C++、Java、C#、Basic 等等来写代码,然后一个叫编译器的程序将程序员写的代码转换成汇编代码,然后进一步转换为[二进制代码](https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html#note2)。二进制代码才是计算机真正能够理解的东西,但它是人类无法读取的东西。汇编代码比二进制代码好一点,至少它的命令是人类可读的,但它仍然让人很沮丧。请记住,你用汇编代码写的每个命令都是处理器可以直接认识的,因此这些命令设计的很简单,因为物理电路必须能够处理每个命令。
![Compiler process][1]
和普通编程一样,也有很多不同的汇编代码编程语言,但与普通编程不一样的是,每个汇编编程语言是面对不同的处理器的,每种处理器设计为去理解不同的语言。因此,用一个针对某种机器设计的汇编语言所写的汇编代码,是不能在其它种类的机器上运行的。很多情况下,这都是一个大灾难,因此每个程序都必须在使用它的不同种类的机器上重写一遍,但对于操作系统,这不是个问题,因为在不同的硬件上它必须得重写。尽管如此,大多数操作系统都是用 C++ 或 C 来写的,这样它们就可以很容易地在不同种类的硬件上使用,只需要重写那些必须用汇编代码来实现的部分即可。
现在,你已经准备好进入第一节课了,它是 [课程 1OK01][2]
现在,你已经准备好进入第一节课了,它是 [课程 1 OK01][2]
--------------------------------------------------------------------------------
@ -43,7 +41,7 @@ via: https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.htm
作者:[Robert Mullins][a]
选题:[lujun9972][b]
译者:[qhwdw](https://github.com/qhwdw)
校对:[校对者ID](https://github.com/校对者ID)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出

View File

@ -1,25 +1,26 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-10428-1.html)
[#]: subject: (Use your Linux terminal to celebrate a banner year)
[#]: via: (https://opensource.com/article/18/12/linux-toy-figlet)
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
使用你的 Linux 终端庆祝新年
======
想让你的终端被记住么?将它打在横幅上,不要错过。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/uploads/linux-toy-figlet.png?itok=o4XmTL-b)
> 想让你的终端被记住么?将它打在横幅上,不要错过。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/uploads/linux-toy-figlet.png?itok=o4XmTL-b)
欢迎再次来到为期 24 天的 Linux 命令行玩具日历。如果这是你第一次访问该系列,你甚至可能会问自己什么是命令行玩具。我们也在思考,但一般来说,它可能是一个游戏,或任何简单的消遣,可以帮助你在终端玩得开心。
很可能你们中的一些人之前已经看过我们日历中的各种玩具,但我们希望每个人至少见到一件新事物。
今天的玩具是 **figlet**,一个在 Linux 终端上以横幅形式打印文本的程序。
今天的玩具是 `figlet`,一个在 Linux 终端上以横幅形式打印文本的程序。
你可能会再标准仓库中找到 **figlet**。在我的 Fedora 上,这意味着安装就像下面这样简单:
你可能会再标准仓库中找到 `figlet`。在我的 Fedora 上,这意味着安装就像下面这样简单:
```
$ sudo dnf install figlet
@ -36,7 +37,7 @@ echo "Hello world" | figlet
|_| |_|\___|_|_|\___/ \_/\_/ \___/|_| |_|\__,_|
```
**figlet** 有许多不同的字体。要查看可用的字体,请尝试使用命令 **showfigfonts**。在我这里显示了十几个。我在下面复制了一些我的最爱。
`figlet` 有许多不同的字体。要查看可用的字体,请尝试使用命令 `showfigfonts`。在我这里显示了十几个。我在下面复制了一些我的最爱。
```
block :
@ -74,9 +75,9 @@ script :
\|
```
你可以在项目的[主页][1]上找到有关 **figlet** 的更多信息。我下载的版本是以 MIT 许可开源的。
你可以在项目的[主页][1]上找到有关 `figlet` 的更多信息。我下载的版本是以 MIT 许可开源的。
你会发现 **figlet** 不是唯一的 Linux 终端横幅打印机。另外一个你可以选择的是 [toilet][2],它有自己的一套 ASCII 艺术风格的打印选项。
你会发现 `figlet` 不是唯一的 Linux 终端横幅打印机。另外一个你可以选择的是 [toilet][2],它有一套自己的 ASCII 艺术风格的打印选项。
你有特别喜欢的命令行小玩具需要我介绍的吗?我们的日历基本上满了,但我们仍然希望在新的一年中展示一些很酷的命令行玩具。请在评论中留言,我会查看的。记得让我知道你对今天玩具的看法。
@ -89,7 +90,7 @@ via: https://opensource.com/article/18/12/linux-toy-figlet
作者:[Jason Baker][a]
选题:[lujun9972][b]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
@ -97,4 +98,4 @@ via: https://opensource.com/article/18/12/linux-toy-figlet
[b]: https://github.com/lujun9972
[1]: http://www.figlet.org/
[2]: http://caca.zoy.org/wiki/toilet
[3]: https://opensource.com/article/18/12/linux-toy-asciiquarium
[3]: https://opensource.com/article/18/12/linux-toy-asciiquarium

View File

@ -1,102 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (runningwater)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: subject: (The Rise and Rise of JSON)
[#]: via: ( https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html)
[#]: author: (https://twobithistory.org)
[#]: url: ( )
The Rise and Rise of JSON
======
JSON has taken over the world. Today, when any two applications communicate with each other across the internet, odds are they do so using JSON. It has been adopted by all the big players: Of the ten most popular web APIs, a list consisting mostly of APIs offered by major companies like Google, Facebook, and Twitter, only one API exposes data in XML rather than JSON. Twitter, to take an illustrative example from that list, supported XML until 2013, when it released a new version of its API that dropped XML in favor of using JSON exclusively. JSON has also been widely adopted by the programming rank and file: According to Stack Overflow, a question and answer site for programmers, more questions are now asked about JSON than about any other data interchange format.
![][1]
XML still survives in many places. It is used across the web for SVGs and for RSS and Atom feeds. When Android developers want to declare that their app requires a permission from the user, they do so in their apps manifest, which is written in XML. XML also isnt the only alternative to JSON—some people now use technologies like YAML or Googles Protocol Buffers. But these are nowhere near as popular as JSON. For the time being, JSON appears to be the go-to format for communicating with other programs over the internet.
JSONs dominance is surprising when you consider that as recently as 2005 the web world was salivating over the potential of “Asynchronous JavaScript and XML” and not “Asynchronous JavaScript and JSON.” It is of course possible that this had nothing to do with the relative popularity of the two formats at the time and reflects only that “AJAX” must have seemed a more appealing acronym than “AJAJ.” But even if some people were already using JSON instead of XML in 2005 (and in fact not many people were yet), one still wonders how XMLs fortunes could have declined so precipitously that a mere decade or so later “Asynchronous JavaScript and XML” has become an ironic misnomer. What happened in that decade? How did JSON supersede XML in so many applications? And who came up with this data format now depended on by engineers and systems all over the world?
### The Birth of JSON
The first JSON message was sent in April of 2001. Since this was a historically significant moment in computing, the message was sent from a computer in a Bay-Area garage. Douglas Crockford and Chip Morningstar, co-founders of a technology consulting company called State Software, had gathered in Morningstars garage to test out an idea.
Crockford and Morningstar were trying to build AJAX applications well before the term “AJAX” had been coined. Browser support for what they were attempting was not good. They wanted to pass data to their application after the initial page load, but they had not found a way to do this that would work across all the browsers they were targeting.
Though its hard to believe today, Internet Explorer represented the bleeding edge of web browsing in 2001. As early as 1999, Internet Explorer 5 supported a primordial form of XMLHttpRequest, which programmers could access using a framework called ActiveX. Crockford and Morningstar could have used this technology to fetch data for their application, but they could not have used the same solution in Netscape 4, another browser that they sought to support. So Crockford and Morningstar had to use a different system that worked in both browsers.
The first JSON message looked like this:
```
<html><head><script>
document.domain = 'fudco';
parent.session.receive(
{ to: "session", do: "test",
text: "Hello world" }
)
</script></head></html>
```
Only a small part of the message resembles JSON as we know it today. The message itself is actually an HTML document containing some JavaScript. The part that resembles JSON is just a JavaScript object literal being passed to a function called `receive()`.
Crockford and Morningstar had decided that they could abuse an HTML frame to send themselves data. They could point a frame at a URL that would return an HTML document like the one above. When the HTML was received, the JavaScript would be run, passing the object literal back to the application. This worked as long as you were careful to sidestep browser protections preventing a sub-window from accessing its parent; you can see that Crockford and Mornginstar did that by explicitly setting the document domain. (This frame-based technique, sometimes called the hidden frame technique, was commonly used in the late 90s before the widespread implementation of XMLHttpRequest.)
The amazing thing about the first JSON message is that its not obviously the first usage of a new kind of data format at all. Its just JavaScript! In fact the idea of using JavaScript this way is so straightforward that Crockford himself has said that he wasnt the first person to do it—he claims that somebody at Netscape was using JavaScript array literals to communicate information as early as 1996. Since the message is just JavaScript, it doesnt require any kind of special parsing. The JavaScript interpreter can do it all.
The first ever JSON message actually ran afoul of the JavaScript interpreter. JavaScript reserves an enormous number of words—there are 64 reserved words as of ECMAScript 6—and Crockford and Morningstar had unwittingly used one in their message. They had used `do` as a key, but `do` is reserved. Since JavaScript has so many reserved words, Crockford decided that, rather than avoid using all those reserved words, he would just mandate that all JSON keys be quoted. A quoted key would be treated as a string by the JavaScript interpreter, meaning that reserved words could be used safely. This is why JSON keys are quoted to this day.
Crockford and Morningstar realized they had something that could be used in all sorts of applications. They wanted to name their format “JSML”, for JavaScript Markup Language, but found that the acronym was already being used for something called Java Speech Markup Language. So they decided to go with “JavaScript Object Notation”, or JSON. They began pitching it to clients but soon found that clients were unwilling to take a chance on an unknown technology that lacked an official specification. So Crockford decided he would write one.
In 2002, Crockford bought the domain [JSON.org][2] and put up the JSON grammar and an example implementation of a parser. The website is still up, though it now includes a prominent link to the JSON ECMA standard ratified in 2013. After putting up the website, Crockford did little more to promote JSON, but soon found that lots of people were submitting JSON parser implementations in all sorts of different programming languages. JSONs lineage clearly tied it to JavaScript, but it became apparent that JSON was well-suited to data interchange between arbitrary pairs of languages.
### Doing AJAX Wrong
JSON got a big boost in 2005. That year, a web designer and developer named Jesse James Garrett coined the term “AJAX” in a blog post. He was careful to stress that AJAX wasnt any one new technology, but rather “several technologies, each flourishing in its own right, coming together in powerful new ways.” AJAX was the name that Garrett was giving to a new approach to web application development that he had noticed gaining favor. His blog post went on to describe how developers could leverage JavaScript and XMLHttpRequest to build new kinds of applications that were more responsive and stateful than the typical web page. He pointed to Gmail and Flickr as examples of websites already relying on AJAX techniques.
The “X” in “AJAX” stood for XML, of course. But in a follow-up Q&A post, Garrett pointed to JSON as an entirely acceptable alternative to XML. He wrote that “XML is the most fully-developed means of getting data in and out of an AJAX client, but theres no reason you couldnt accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data.”
Developers indeed found that they could easily use JSON to build AJAX applications and many came to prefer it to XML. And so, ironically, the interest in AJAX led to an explosion in JSONs popularity. It was around this time that JSON drew the attention of the blogosphere.
In 2006, Dave Winer, a prolific blogger and the engineer behind a number of XML-based technologies such as RSS and XML-RPC, complained that JSON was reinventing XML for no good reason. Though one might think that a contest between data interchange formats would be unlikely to engender death threats, Winer wrote:
> No doubt I can write a routine to parse [JSON], but look at how deep they went to re-invent, XML itself wasnt good enough for them, for some reason (Id love to hear the reason). Who did this travesty? Lets find a tree and string them up. Now.
Its easy to understand Winers frustration. XML has never been widely loved. Even Winer has said that he does not love XML. But XML was designed to be a system that could be used by everyone for almost anything imaginable. To that end, XML is actually a meta-language that allows you to define domain-specific languages for individual applications—RSS, the web feed technology, and SOAP (Simple Object Access Protocol) are examples. Winer felt that it was important to work toward consensus because of all the benefits a common interchange format could bring. He felt that XMLs flexibility should be able to accommodate everybodys needs. And yet here was JSON, a format offering no benefits over XML except those enabled by throwing out the cruft that made XML so flexible.
Crockford saw Winers blog post and left a comment on it. In response to the charge that JSON was reinventing XML, Crockford wrote, “The good thing about reinventing the wheel is that you can get a round one.”
### JSON vs XML
By 2014, JSON had been officially specified by both an ECMA standard and an RFC. It had its own MIME type. JSON had made it to the big leagues.
Why did JSON become so much more popular than XML?
On [JSON.org][2], Crockford summarizes some of JSONs advantages over XML. He writes that JSON is easier for both humans and machines to understand, since its syntax is minimal and its structure is predictable. Other bloggers have focused on XMLs verbosity and “the angle bracket tax.” Each opening tag in XML must be matched with a closing tag, meaning that an XML document contains a lot of redundant information. This can make an XML document much larger than an equivalent JSON document when uncompressed, but, perhaps more importantly, it also makes an XML document harder to read.
Crockford has also claimed that another enormous advantage for JSON is that JSON was designed as a data interchange format. It was meant to carry structured information between programs from the very beginning. XML, though it has been used for the same purpose, was originally designed as a document markup language. It evolved from SGML (Standard Generalized Markup Language), which in turn evolved from a markup language called Scribe, intended as a word processing system similar to LaTeX. In XML, a tag can contain what is called “mixed content,” or text with inline tags surrounding words or phrases. This recalls the image of an editor marking up a manuscript with a red or blue pen, which is arguably the central metaphor of a markup language. JSON, on the other hand, does not support a clear analogue to mixed content, but that means that its structure can be simpler. A document is best modeled as a tree, but by throwing out the document idea Crockford could limit JSON to dictionaries and arrays, the basic and familiar elements all programmers use to build their programs.
Finally, my own hunch is that people disliked XML because it was confusing, and it was confusing because it seemed to come in so many different flavors. At first blush, its not obvious where the line is between XML proper and its sub-languages like RSS, ATOM, SOAP, or SVG. The first lines of a typical XML document establish the XML version and then the particular sub-language the XML document should conform to. That is a lot of variation to account for already, especially when compared to JSON, which is so straightforward that no new version of the JSON specification is ever expected to be written. The designers of XML, in their attempt to make XML the one data interchange format to rule them all, fell victim to that classic programmers pitfall: over-engineering. XML was so generalized that it was hard to use for something simple.
In 2000, a campaign was launched to get HTML to conform to the XML standard. A specification was published for XML-compliant HTML, thereafter known as XHTML. Some browser vendors immediately started supporting the new standard, but it quickly became obvious that the vast HTML-producing public were unwilling to revise their habits. The new standard called for stricter validation of XHTML than had been the norm for HTML, but too many websites depended on HTMLs forgiving rules. By 2009, an attempt to write a second version of the XHTML standard was aborted when it became clear that the future of HTML was going to be HTML5, a standard that did not insist on XML compliance.
If the XHTML effort had succeeded, then maybe XML would have become the common data format that its designers hoped it would be. Imagine a world in which HTML documents and API responses had the exact same structure. In such a world, JSON might not have become as ubiquitous as it is today. But I read the failure of XHTML as a kind of moral defeat for the XML camp. If XML wasnt the best tool for HTML, then maybe there were better tools out there for other applications also. In that world, our world, it is easy to see how a format as simple and narrowly tailored as JSON could find great success.
If you enjoyed this post, more like it come out every two weeks! Follow [@TwoBitHistory][3] on Twitter or subscribe to the [RSS feed][4] to make sure you know when a new post is out.
--------------------------------------------------------------------------------
via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html
作者:[Two-Bit History][a]
选题:[lujun9972][b]
译者:[runningwater](https://github.com/runningwater)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://twobithistory.org
[b]: https://github.com/lujun9972
[1]: https://twobithistory.org/images/json.svg
[2]: http://JSON.org
[3]: https://twitter.com/TwoBitHistory
[4]: https://twobithistory.org/feed.xml

View File

@ -1,10 +1,10 @@
[#]: collector: (lujun9972)
[#]: translator: (seriouszyx)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: subject: (What the open source community means to me)
[#]: via: (https://opensource.com/article/18/11/what-open-source-community-means-me)
[#]: author: ([Florian Effenberger](https://opensource.com/users/floeff))
[#]: author: (Florian Effenberger https://opensource.com/users/floeff)
[#]: url: ( )
What the open source community means to me

View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

View File

@ -1,52 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Snake your way across your Linux terminal)
[#]: via: (https://opensource.com/article/18/12/linux-toy-snake)
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
Snake your way across your Linux terminal
======
Python isn't the only snake you'll find at the Linux command line with this classic 1970s game remake.
![](https://opensource.com/sites/default/files/styles/image-full-size/public/uploads/linux-toy-snake.png?itok=oNhqUTDu)
Welcome back to the Linux command-line toys advent calendar. If this is your first visit to the series, you might be asking yourself what a command-line toy even is. It's hard to say exactly, but my definition is anything that helps you have fun at the terminal.
We've been on a roll with games over the weekend, and it was fun, so let's look at one more game today, Snake!
Snake is an oldie but goodie; versions of it have been around seemingly forever. The first version I remember playing was one called [Nibbles][1] that came packaged with [QBasic][2] in the 1990s, and was probably pretty important to my understanding of what a programming language even was. Here I had the source code to a game that I could modify and just see what happens, and maybe learn something about what all of those funny little words that made up a programming language were all about.
Today's [Snake][3] is written in Go, and while it's simple, it's just as much fun as the original. Like most simple old games, there are a ton of versions to choose from. In Snake's case, there's even a version in the classic [bsdgames][4] package that's almost certainly packaged for your distribution.
But what I like about this version of Snake is that it's packaged for Docker so I can easily run it in one line from my terminal without worrying about anything disto-specific. That, and it makes use of 15 randomized food emojis for the snake to eat. I'm a sucker for food emojis. Anyway, give it a try using:
```
$ docker run -ti dyego/snake-game
```
This Snake is licensed as open source under an MIT license, and you can check out the source code [on GitHub][3].
![](https://opensource.com/sites/default/files/uploads/linux-toy-snake-animated.gif)
Do you have a favorite command-line toy that you think I ought to profile? The calendar for this series is mostly filled out but I've got a few spots left. Let me know in the comments below, and I'll check it out. If there's space, I'll try to include it. If not, but I get some good submissions, I'll do a round-up of honorable mentions at the end.
Check out yesterday's toy, [Powers of two, powers of Linux: 2048 at the command line][5], and check back tomorrow for another!
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/12/linux-toy-snake
作者:[Jason Baker][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/jason-baker
[b]: https://github.com/lujun9972
[1]: https://en.wikipedia.org/wiki/Nibbles_(video_game)
[2]: https://en.wikipedia.org/wiki/QBasic
[3]: https://github.com/DyegoCosta/snake-game
[4]: https://github.com/vattam/BSDGames
[5]: https://opensource.com/article/18/12/linux-toy-2048

View File

@ -1,200 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: ( dianbanjiu )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (An Easy Way To Remove Programs Installed From Source In Linux)
[#]: via: (https://www.ostechnix.com/an-easy-way-to-remove-programs-installed-from-source-in-linux/)
[#]: author: (SK https://www.ostechnix.com/author/sk/)
An Easy Way To Remove Programs Installed From Source In Linux
======
![](https://www.ostechnix.com/wp-content/uploads/2018/12/stow-1-720x340.jpg)
Not all programs available in the official or third-party repositories, so you cant install them using the regular package managers. Some times, you have to install the programs by manually compiling from source. As you may already know, when you install programs from source, the package files will be copied to multiple locations, such as **/usr/local/bin** , **/usr/local/etc/** , on the filesystem. If the installed program from source doesnt have a built-in uninstaller, it is going to be a tedious task to remove the packages when you dont need it anymore. You may need to spend couple (or several) minutes to find those package files and remove them manually. This is what I have been doing up until I stumbled upon a utility named **“GNU Stow”**. Thankfully, Stow has a fantastic way to easily manage programs installed from source.
To quote the official website,
> **GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place.**
To put this simply, Stow helps you to keep the package files organized in a way to easily manageable. In this method, the files will not be copied to multiple locations. Instead, all files are saved in a specific folder, usually under the program name itself, and Stow creates symbolic links to all the programs files into the appropriate places. For example, **/usr/local/bin** could contain symlinks to files within **/usr/local/stow/vim/bin** , **/usr/local/stow/python/bin** etc., and likewise recursively for any other subdirectories such as **…/share** , **…/man** , and so on. In this tutorial, I will show you how to easily manage programs installed from source using Stow with a practical example. Read on.
### Installing GNU Stow
GNU Stow is available in the default repositories of popular Linux operating systems.
On **Arch Linux** and its variants, run the following command to install Stow.
```
$ sudo pacman -S stow
```
On **Debian** , **Ubuntu** , **Linux Mint** :
```
$ sudo apt install stow
```
On **Fedora** :
```
$ sudo dnf install stow
```
On **RHEL/CentOS** :
```
$ sudo yum install epel-release
$ sudo yum install stow
```
### Easily Remove Programs Installed From Source In Linux
As I already mentioned earlier, all program files of a package will be saved in a root folder located in **/usr/local/stow/**. Under this root or parent directory, each package will be saved in its own private sub-directory. For example, if we install Vim editor from source, all program files and directories related to Vim will be saved under **/usr/local/stow/vim** folder. If you install python from source, all files related to python will be kept under **/usr/local/stow/python** and so on.
Let me install a program, for example **hello** , from source.
First download the hello programs tarball.
```
$ wget http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz
```
Extract the downloaded tarball using command:
```
$ tar -zxvf hello-2.10.tar.gz
```
The above command will create a directory named hello-2.10 in the current working directory and extract all contents in it.
Switch to the extracted directory:
```
$ cd hello-2.10/
```
Run the following command with prefix option.
```
$ ./configure --prefix=/usr/local/stow/hello
```
The above command will save the build files in the specified location i.e **/usr/local/stow/hello** in our case.
Finally, build and install the hello program using the following commands:
```
$ make
$ sudo make install
```
Thats it. The hello program has been installed in **/usr/local/stow/hello/** location. You can verify it with ls command as shown below.
```
$ ls /usr/local/stow/hello/
bin share
```
Finally, go to the **/usr/local/stow/** directory and run the following command to generate the necessary symlinks.
```
$ cd /usr/local/stow/
$ sudo stow hello
```
All done!
What just happened is all the files and directories contained in the hello package have been symlinked to the directory **/usr/local/**. In other words, **/usr/local/stow/hello/bin** has been symlinked to **/usr/local/bin** and **/usr/local/stow/hello/share** has been symlinked to **/usr/local/share** and **/usr/local/stow/hello/share/man** has been symlinked to **/usr/local/share/man** and so on.
You can verify them using ls command:
```
$ ls /usr/local/bin/
hello
```
Let us check if the hello program is working or not using command:
```
$ hello
Hello, world!
```
Yeah, it is working!!
Similarly, you can install programs as described above under its own sub-directory.
Here is the contents of the Stow root directory:
```
$ tree /usr/local/stow/
```
![][2]
See? The hello program is installed /usr/local/stow/hello/ location. Like wise, all packages will be kept under their own directory.
Here comes the main part. Let us remove the hello program. To do so, go to **/usr/local/stow/** directory:
```
$ cd /usr/local/stow/
```
..and run the following command:
```
$ sudo stow --delete hello
```
The hello program has just been removed. You can verify if it is really removed using command:
```
$ hello
-bash: /usr/local/bin/hello: No such file or directory
```
![][3]
See? Hello program is removed!
Please note that Stow has removed the symlinks only. All program files and directories related to hello program are still available in **/usr/local/stow/hello** folder. So, you can install the hello program again without having to download the actual source file. If you dont want it anymore, simply delete the folder.
```
$ sudo rm -fr /usr/local/stow/hello/
```
To know more details about Stow, refer the man pages.
```
$ man stow
```
Stow helps you to uninstall the programs as easily as you install them. If you are wondering how to effectively manage a lot of programs installed from source, GNU Stow is one such program to make this task a lot easier. Give it a try, you wont be disappointed.
And, thats all for now. Hope this was useful. More good stuffs to come. Stay tuned!
Cheers!
--------------------------------------------------------------------------------
via: https://www.ostechnix.com/an-easy-way-to-remove-programs-installed-from-source-in-linux/
作者:[SK][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.ostechnix.com/author/sk/
[b]: https://github.com/lujun9972
[1]: data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
[2]: http://www.ostechnix.com/wp-content/uploads/2018/12/tree-command.png
[3]: http://www.ostechnix.com/wp-content/uploads/2018/12/hello-world.png

View File

@ -0,0 +1,102 @@
[#]: collector: (lujun9972)
[#]: translator: (runningwater)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: subject: (The Rise and Rise of JSON)
[#]: via: ( https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html)
[#]: author: (https://twobithistory.org)
[#]: url: ( )
JSON 的兴起与崛起
======
JSON 已经占领了全世界。当今,任何两个应用程序彼此通过网络通信时,它们很有可能在使用 JSON。它已被所有大型企业所采用十大最受欢迎的 web API 接口(主要由 Google、Facebook 和 Twitter 提供的)列表中,仅仅只有一个 API 接口是以 XML 的格式开放数据的。Twitter 给这个 API 添加了一个说明性示例XML 格式的支持到 2013 年结束,到时候会发布一个新版本的 API取消 XML 格式,转而使用 JSON。JSON 也在程序编码级别和文件存储上被广泛采用:在 Stack Overflow一个面向程序员的问答网站现在更多的是关于 JSON 的问题,而不是其他的数据交换格式。
![][1]
XML 仍然在很多地方存在。在网页上有 SVG 和 RSS 订阅服务、Atom 提供商。Android 开发者想要获得用户权限许可时,需要在其 APP 的 `manifest` 文件中声明。此文件是 XML 格式的。XML 的替代品也不仅仅只有 JSON现在有很多人在使用 YAML 或 Google 的 Protocol Buffers 等技术,但这些技术的受欢迎程度远不如 JSON。目前来看JSON 是应用程序在网络之间通信的首选协议格式。
考虑到自 2005 年来网站编程世界对 “异步 JavaScript 和 XML” 而非 “异步 JavaScript 和 JSON” 技术潜力的垂涎欲滴状态,你可以发现 JSON 在其中的主导地位是如此让人惊讶。当然了,这可能与这两种通信格式的受欢迎程度无关,仅反映出 “AJAX” 似乎比 “AJAJ” 更具吸引力。但是,即使在 2015 年时有好些人已经用 JSON 来取代 XML 了(实际上还没有很多人),我们不禁要问 XML 的噩运来的如此之快,以至于短短十年左右,“异步 JavaScript 和 XML” 这个名称就成为一个很讽刺的误称。那个十年发生了什么JSON 怎么会在那么多应用程序中取代了 XML现在被全世界工程师和系统所使用、依赖的这种数据格式是谁提出的
### JSON 之诞生
2001 年 4 月,首个 JSON 格式的消息被发送。此消息是从旧金山湾区某车库的一台计算机发出的这是计算机历史上重要的的时刻。Douglas Crockford 和 Chip Morningstar 是一家名为 State Software 的技术咨询公司的联合创始人,他们当时聚集在 Morningstar 的车库里测试某个想法,发出了此消息。
在 “AJAX” 这个术语被创造之前, Crockford 和 Morningstar 就已经在尝试构建好用的 AJAX 应用程序了。可是浏览器对其兼容性不好。他们想要在初始页面加载后就将数据传递给应用程序,但其目标要针对所有的浏览器,这就实现不了。
这在今天看来不太可信,但是要记得 2001 年的时候 Internet ExplorerIE代表了网页浏览器的最前沿技术产品。早在 1999 年的时候Internet Explorer 5 就支持 `XMLHttpRequest 对象原型`,开发者可以使用名为 ActiveX 的框架来访问此对象。 Crockford 和 Morningstar 可能是使用此技术来获取数据,但是在 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以发送数据。敲入 URL 返回的 HTML 文档(如上所示)可以指向一个 frame 标签。当接收到 HTML 时JavaScript 代码段一运行,就可以把数据对象如实地传递回应用程序。只要小心的回避浏览器保护策略,即子窗口不允许访问父窗口,这种技术就可以正常运行无误。可以看到 Crockford 和 Mornginstar 通过明确地设置文档域这种方法来达到其目的。(这种基于 frame 的技术,有时称为隐藏 frame 技术通常在90年代后期即广泛使用 XMLHttpRequest 技术之前使用。)
关于第一个 JSON 消息的惊人之处在于它显然不是第一次就使用新的数据格式。它仅仅是 JavaScript实际上以此使用 JavaScript 的想法如此简单Crockford 自己也说过他不是第一个这样做的人。他声称 Netscape 公司的某人早在 1996 年就使用 JavaScript 数组文字来交换信息。因为消息就是 JavaScript 本身其不需要任何特殊解析工作JavaScript 解释器就可搞定一切。
最初的 JSON 信息实际上与 JavaScript 解释器发生了冲突。JavaScript 使用了大量的单词来做为保留字ECMAScript 6 版本的就有 64 个保留字Crockford 和 Morningstar 无意中在其 JSON 中引入了一个保留字。他们使用了 `do` 这个关键字,但 `do` 是解释器中的保留字。因为 JavaScript 使用的保留字太多了Crockford 做了决定:既然不可避免的要使用到这些保留字,那就要求所有的 JSON 关键字都加上引号。被引起来的关键字会被 JavaScript 解释器识别成字符串,其意味着那些保留字也可以放心安全的使用。这就为什么今天 JSON 关键字都要用引号引起来的原因。
Crockford 和 Morningstar 意识到这技术可以应用于各类应用系统。想给其命名为 “JSML”即 JavaScript 标记语言,但发现这个缩写已经被叫做 Java 标记语言的所使用了。因此他们决定采用 “JavaScript Object Notation” 或 JSON 命名。他们开始向客户推销,但很快发现客户不愿意冒险使用缺乏官方规范的未知技术。所以 Crockford 决定写一个规范。
2002 年Crockford 买下了 [JSON.org][2] 域名,放上了 JSON 语法及一个解释器的实例例子。网站仍然在运行,现在已经包含有 2013 年正式批准的 JSON ECMA 标准的显著链接。在网站建立后Crockford 并没有过多的推广,但很快发现很多人都在提交各种不同编程语言的 JSON 解析器实现。JSON 的血统明显与 JavaScript 相关联,但很明显 JSON 非常适合于不同语言之间的数据交换。
### AJAX 导致的误会
2005 年JSON 有了一次大扩展。那一年,一位名叫 Jesse James Garrett 的网页设计师和开发人员在博客文章中创造了 “AJAX” 一词。他很谨慎地强调AJAX 并不是新技术,而是 “好几种技术以某种强大的新方式汇集,其中的各技术各自发展。” AJAX 是 Garrett 给 Web 应用程序开发的新方法(其正获得青睐)的命名。他的博客文章接着描述了开发人员如何利用 JavaScript 和 XMLHttpRequest 对象构建新的应用程序,这些应用程序比传统的网页更具响应性和状态性。 他还举了 Gmail 和 Flickr的网站已经使用 AJAX 技术的例子。
当然了“AJAX” 中的 “X” 代表 XML。但在随后的问答帖子中Garrett 指出JSON 可以完全替代 XML。他写道虽然 XML 是 AJAX 客户端进行数据输入输出的最完善的技术,但要实现同样的效果,也可以使用像 JavaScript Object Notation JSON或任何类似的结构数据方法等技术。
开发者确实发现在构建 AJAX 应用程序时可以很容易的使用 JSON并且很多人也开始喜欢上 XML。具有讽刺意味的是对 AJAX 的兴趣逐渐的导致了 JSON 的普及。大约在这个时候JSON 引起了博客圈的注意。
2006 年Dave Winer一位高产的博主也是许多基于 XML 技术(如 RSS 和 XML-RPC的后端开发工程师他抱怨到 JSON 毫无疑问的正在重新发明 XML。虽然他认为数据交换格式之间的竞争不会导致某一技术的消亡其写到
> 让我们来比较下重构某结构数据的深度及难度由于某些原因我很想听听原因XML 自身做的并不好,所以毫无疑问地,我会写一个例程来解析 JSON 格式的数据。谁想干这荒谬之事?查找一棵树然后把节点串起来。可以立马试试。
很容易理解 Winer 的挫败感,事实上并没有太多人喜欢 XML。甚至 Winer 也说过他不喜欢 XML。但 XML 已被设计成一个可供任何人使用并且几乎能想象到的事情都可以做到的系统。最终XML 实际上是一门元语言,允许你为特定应用程序自定义特定域的语言。如 RSS、web feed 技术和 SOAP(简单对象访问协议)就是自定义的例子。Winer 认为由于通用交换格式所带来的好处努力达成共识就很重要了。XML 的灵活性应该能满足任何人的需求,然而这里是 JSON 格式,其并不比 XML 更具优势,但其抛弃了 XML 中不好的设计,可以使 XML 更加的灵活。
Crockford 阅读了 Winer 的这篇文章并留下了评论。为了回应 JSON 重新发明 XML 的指责Crockford 写到:重造轮子的好处是可以得到一个更好的轮子。
### JSON 与 XML 对比
到 2014 年JSON 已经由 ECMA 标准和 RFC 官方正式认可。它有自己的 MIME 类型。JSON 已经进入了大联盟时代。
为什么 JSON 比 XML 更受欢迎?
在 [JSON.org][2] 网站上Crockford 总结了一些 JSON 的优势。他写到JSON 的语法很小,其结构可预测,因此 JSON 更容易被人类和机器理解。其他博主不得不关注 XML 的冗长啰嗦及“尖括号负担”。XML 中每个开始标记都必须与结束标记匹配,这意味着 XML 文档包含大量的冗余信息。在未压缩时XML 文档的体积比同信息量 JSON 文档的体积大很多,但是,更重要的,这也使 XML 文档更难以阅读。
Crockford 还声称 JSON 的另一个巨大优势是其被设计为数据交换格式。从一开始,它的目的就是在应用程序间传递结构化信息的。而 XML 呢,虽然也可以使用来传递数据,但其最初被设计为文档标记语言。它从 SGML通用标准标记语言演变而来后来又从称为 Scribe 的标记语言是发展,旨在发展成类似于 LaTeX 一样的文字处理系统。XML 中一个标签可以包含有所谓的“混合内容”或包含有围绕单词、短语的内嵌标签的文本。这会让人浮现出一副用红蓝笔记录的手稿画面这是标记语言核心思想的形象比喻。另一方面JSON 不支持对混合内容模型清晰构建,但也意味着它的结构足够简单。一份文档最好的建模就是一棵树,但 JSON 抛弃了文档的思想Crockford 将 JSON 抽象限制为字典和数组,这是所有程序员构建程序时都会使用的最基本也最熟悉的元素。
最后,我认为人们不喜欢 XML 是因为它让人困惑。它让人迷惑的地方就是有很多不同的风格。乍一看XML 本身及其子语言(如 RSS、ATOM、SOAP 或 SVG之间的界限并不明显。通用 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 可能不会像现在一样普遍存在。但我读懂了, XHTML 的失败是 XML 阵营的一种道德失败。如果 XML 不是 HTML 的最佳工具,那么为了其他应用程序,也许会有更好的工具出现。在这个世界,我们的世界,很容易看到像 JSON 格式这样的足够简单、量体裁衣才能获得更大的成功。
如果你喜欢这博文,每两周会更新一次! 请在 Twitter 上关注 [@TwoBitHistory] [3] 或订阅 [RSS feed] [4], 以确保得到更新的通知。
--------------------------------------------------------------------------------
via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html
作者:[Two-Bit History][a]
选题:[lujun9972][b]
译者:[runningwater](https://github.com/runningwater)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://twobithistory.org
[b]: https://github.com/lujun9972
[1]: https://twobithistory.org/images/json.svg
[2]: http://JSON.org
[3]: https://twitter.com/TwoBitHistory
[4]: https://twobithistory.org/feed.xml

View File

@ -0,0 +1,52 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Snake your way across your Linux terminal)
[#]: via: (https://opensource.com/article/18/12/linux-toy-snake)
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
在 Linux 终端中玩贪吃蛇
======
有了这个 20 世纪 70 年代的经典重制游戏Python 将不再是你在 Linux 终端能发现的唯一的“蛇”。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/uploads/linux-toy-snake.png?itok=oNhqUTDu)
欢迎回到 Linux 命令行玩具日历。如果这是你第一次访问该系列,你可能会问自己甚至是命令行玩具。这很难确切地说,但我的定义是任何可以帮助你在终端玩得开心的东西。
我们这周都在介绍游戏,这很有趣,接着让我们看下今天的游戏,贪吃蛇!
贪吃蛇是一个古老又很好的游戏。它的版本似乎一直存在着。我记得我第一次玩得版本是 20 世纪 90 年代与 [QBasic][2] 一起打包发布的 [Nibbles][1],它对我理解什么是编程语言起了很重要的作用。我有游戏的源码,我可以修改并查看会发生什么,并学习到一些组成这个编程语言的有趣词汇究竟是什么意思。
今天的[贪吃蛇][3]是用 Go 写的,它很简单并且和原版的游戏一样有趣。像大多数简单的老游戏一样,它有很多版本可供选择。这今天的贪吃蛇中,甚至还有一个经典的 [bsdgames][4] 形式的包,它几乎一定为你的发行版打包了。
但我喜欢的是用 Docker 打包的贪吃蛇,因为我可以轻松地在命令行中运行,而不用担心发行版相关的问题。这个版本使用 15 个随机的食物 emoji 图案让蛇来吃。我玩得不好。不管怎样,请试一下:
```
$ docker run -ti dyego/snake-game
```
这个贪吃蛇以 MIT 许可证开源,你可在 [Github][3] 取得源码。
![](https://opensource.com/sites/default/files/uploads/linux-toy-snake-animated.gif)
你有特别喜欢的命令行小玩具需要我介绍的吗?这个系列要介绍的小玩具大部分已经有了落实,但还预留了几个空位置。请在评论区留言,我会查看的。如果还有空位置,我会考虑介绍它的。如果没有,但如果我得到了一些很好的意见,我会在最后做一些有价值的提及。
请查看昨天的玩具,[数字 2 的力量Linux 的力量:在命令行中玩 2048][5],记得明天再来!
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/12/linux-toy-snake
作者:[Jason Baker][a]
选题:[lujun9972][b]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/jason-baker
[b]: https://github.com/lujun9972
[1]: https://en.wikipedia.org/wiki/Nibbles_(video_game)
[2]: https://en.wikipedia.org/wiki/QBasic
[3]: https://github.com/DyegoCosta/snake-game
[4]: https://github.com/vattam/BSDGames
[5]: https://opensource.com/article/18/12/linux-toy-2048

View File

@ -0,0 +1,200 @@
[#]: collector: (lujun9972)
[#]: translator: ( dianbanjiu )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (An Easy Way To Remove Programs Installed From Source In Linux)
[#]: via: (https://www.ostechnix.com/an-easy-way-to-remove-programs-installed-from-source-in-linux/)
[#]: author: (SK https://www.ostechnix.com/author/sk/)
在 Linux 中移除从源中安装的程序的一种简单的方法
======
![](https://www.ostechnix.com/wp-content/uploads/2018/12/stow-1-720x340.jpg)
不是所有的程序都可以在官方或者第三方库中可用,因此你不能使用常规的包管理来安装它们。有时你不得不从源代码中手动构建这些程序。就跟你已经知道的一样,当你从源代码中安装一个程序的时候,这个包文件将会复制到本地的多个位置,例如 **/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/
```
![][2]
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
```
![][3]
看, 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][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.ostechnix.com/author/sk/
[b]: https://github.com/lujun9972
[1]: data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
[2]: http://www.ostechnix.com/wp-content/uploads/2018/12/tree-command.png
[3]: http://www.ostechnix.com/wp-content/uploads/2018/12/hello-world.png