嗨！今天是 netdev 会议的第 2 天，我只参加了早上的会议，但它非常有趣。今早会议的主角是 Van Jacobson 给出的一场名为 “从尽可能快中变化：教网卡以时间”的演讲，它的主题是关于互联网中拥塞控制的未来！！！

下面我将尝试着对我从这次演讲中学到的东西做总结，我几乎肯定下面的内容有些错误，但不管怎样，让我们开始吧！

这次演讲是关于互联网是如何从 1988 开始改变的，为什么现在我们需要新的算法，以及我们可以怎样改变 Linux 的网络栈来更容易地实现这些算法。

什么是拥塞控制？

在网络上的任何成员总是无时无刻地发送信息包，而在互联网上的连接之间有着极其不同的速度（某些相比其他极其缓慢），而有时候它们将被塞满！当互联网的一个设备以超过它能处理的速率接收信息包时，它将丢弃某些信息包。

你所能想象的最天真的发送信息包方式是：

1. 将你必须发送的信息包一次性发送完。
2. 假如你发现其中有的信息包被丢弃了，就马上重新发送这些包。

结果表明假如你按照上面的思路来实现 TCP，互联网将会崩溃并停止运转。我们知道它会崩溃是因为在 1986 年确实发生了崩溃的现象。为了解决这个问题，专家发明了拥塞控制算法 —— 描述如何避免互联网的崩溃的原始论文是 Van Jacobson 于 1988 年发表的 拥塞避免与控制（30 年前！）。

从 1988 年后互联网发生了什么改变？

在演讲中，Van Jacobson 说互联网的这些已经发生了改变：在以前的互联网上，交换机可能总是拥有比服务器更快的网卡，所以这些位于互联网中间层的服务器也可能比客户端更快，并且并不能对客户端发送信息包的速率有多大影响。

很显然今天已经不是这样的了！众所周知，今天的计算机相比于 5 年前的计算机在速度上并没有多大的提升（我们遇到了某些有关光速的问题）。所以我想路由器上的大型交换机并不会在速度上大幅领先于数据中心里服务器上的网卡。

这听起来有些糟糕，因为这意味着客户端更容易在中间层的连接中达到饱和，而这将导致互联网变慢（而且 缓冲膨胀 将带来更高的延迟）。

所以为了提高互联网的性能且不让每个路由上的任务队列都达到饱和，客户端需要表现得更好并且在发送信息包的时候慢一点。

以更慢的速率发送更多的信息包以达到更好的性能

下面的结论真的让我非常意外 —— 以更慢的速率发送信息包实际上可能会带来更好的性能（即便你是在整个传输过程中，这样做的唯一的人），下面是原因：

假设你打算发送 10MB 的数据，在你和你需要连接的客户端之间有一个中间层，并且它的传输速率非常低，例如 1MB/s。假设你可以辨别这个慢连接（或者更多的后续中间层）的速度，那么你有 2 个选择：

1. 一次性将这 10MB 的数据发送完，然后看看会发生什么。
2. 减慢速率使得你能够以 1MB/s 的速率传给它。

现在，无论你选择何种方式，你可能都会发生丢包的现象。所以这样看起来，你可能需要选择一次性发送所有的信息包这种方式，对吧？不！！实际上在你的数据流的中间环节丢包要比在你的数据流的最后丢包要好得多。假如在中间环节有些包被丢弃了，你需要送往的那个客户端可以察觉到这个事情，然后再告诉你，这样你就可以再次发送那些被丢弃的包，这样便没有多大的损失。但假如信息包在最末端被丢弃，那么客户端将完全没有办法知道你一次性发送了所有的信息包！所以基本上在某个时刻被丢弃的包没有让你收到 ACK 信号时，你需要启用超时机制，并且还得重新发送它们。而超时往往意味着需要花费很长时间！

所以为什么以更慢的速率发送数据会更好呢？假如你发送数据的速率快于连接中的瓶颈，这时所有的信息包将会在某个地方堆积成一个队列，这个队列将会被塞满，然后在你的数据流的最末端的信息包将会被丢弃。并且像我们刚才解释的那样，处于数据流最后面的信息包很有可能丢弃！所以相比于最初以合适的速率发送信息包，一次性发送它们将会触发超时机制，发送 10MB 的数据将会花费更长的时间。

我认为这非常酷，因为这个过程并不需要与互联网中的其他人合作 —— 即便其他的所有人都已非常快的速率传送他们的信息包，对你来说以合适的速率（中间层的瓶颈速率）传送你自己的信息包仍然更有优势。

如何辨别发送数据的合适速率：BBR！

在上面我说过：“假设你可以辨别出位于你的终端和服务器之间慢连接的速率……”，那么如何做到呢？来自 Google（Jacobson 工作的地方）的某些专家已经提出了一个算法来估计瓶颈的速率！它叫做 BBR，由于本次的分享已经很长了，所以这里不做具体介绍，但你可以参考 BBR：基于拥塞的拥塞控制 和 来自晨读论文的总结 这两处链接。

（另外，https://blog.acolyer.org 的每日“晨读论文”总结基本上是我学习和理解计算机科学论文的唯一方式，它有可能是整个互联网上最好的博客之一！）

网络代码被设计为运行得“尽可能快“

所以，假设我们相信我们想以一个更慢的速率（例如以我们连接中的瓶颈速率）来传输数据。这很好，但网络软件并不是被设计为以一个可控速率来传输数据的！下面是我所理解的大多数网络软件怎么做的：

1. 现在有一个队列的信息包来临；
2. 然后软件读取队列并尽可能快地发送信息包；
3. 就这样，没有了。

这个过程非常呆板 —— 假设我以一个非常快的速率发送信息包，而另一端的连接却非常慢。假如我所拥有的就是一个放置所有信息包的队列，当我实际要发送数据时，我并没有办法来控制这个发送过程，所以我便不能减慢这个队列传输的速率。

一个更好的方式：给每个信息包一个“最早的出发时间”

BBR 协议将会修改 Linux 内核中 skb 的数据结构（这个数据结构被用来表达网络信息包），使得它有一个时间戳，这个时间戳代表着这个信息包应该被发送出去的最早时间。

对于 Linux 网络栈我不知道更多的详情了，但对于我来说，这个协议最有趣的地方是这个改动并不是一个非常大的改动！它只是添加了一个额外的时间戳而已。

用时间轮盘替换队列！！！

一旦我们将时间戳打到这些信息包上，我们怎样在合适的时间将它们发送出去呢？使用时间轮盘！

在前不久的“我们喜爱的论文”活动中（这是关于这次聚会描述的某些好的链接），有一个演讲谈论了关于时间轮盘的话题。时间轮盘是一类用来指导 Linux 的进程调度器决定何时运行进程的算法。

Van Jacobson 说道：时间轮盘实际上比队列调度工作得更好 —— 它们都提供常数时间的操作，但因为某些缓存机制，时间轮盘的常数要更小一些。我真的没有太明白这里他说的关于性能的解释。

他说道：关于时间轮盘的一个关键点是你可以很轻松地用时间轮盘实现一个队列（但反之不能！）—— 假如每次你增加一个新的信息包，在最开始你说我想让它现在就被发送走，很显然这样你就可以得到一个队列了。而这个时间轮盘方法是向后兼容的，它使得你可以更容易地实现某些更加复杂的对流量非常敏感的算法，例如让你针对不同的信息包以不同的速率去发送它们。

或许我们可以通过改善 Linux 来修复互联网！

对于任何影响到整个互联网规模的问题，最为棘手的问题是当你要做出改善时，例如改变互联网协议的实现，你需要面对各种不同的设备。你要面对 Linux 的机器、BSD 的机器、Windows 的机器、各种各样的手机、瞻博或者思科的路由器以及数量繁多的其他设备！

但是在网络环境中 Linux 处于某种有趣的位置上！

• Android 手机运行着 Linux
• 大多数的消费级 WiFi 路由器运行着 Linux
• 无数的服务器运行着 Linux

所以在任何给定的网络连接中，实际上很有可能在两端都有一台 Linux 机器（例如一个 Linux 服务器、或者一个 Linux 路由器、一台 Android 设备）。

所以重点是假如你想大幅改善互联网上的拥塞状况，只需要改变 Linux 网络栈就会大所不同（或许 iOS 网络栈也是类似的）。这也就是为什么在本次的 Linux 网络会议上有这样的一个演讲！

互联网仍在改变！酷！

通常我以为 TCP/IP 仍然是上世纪 80 年代的东西，所以当从这些专家口中听说这些我们正在设计的网路协议仍然有许多严重的问题时，真的是非常有趣，并且听说现在有不同的方式来设计它们。

当然也确实是这样 —— 网络硬件以及和速度相关的任何设备，以及人们使用网络来干的各种事情（例如观看 Netflix 的节目）等等，一直都在随着时间发生着改变，所以正因为这样，我们需要为 2018 年的互联网而不是为 1988 年的互联网设计我们不同的算法。

via: https://jvns.ca/blog/2018/07/12/netdev-day-2--moving-away-from--as-fast-as-possible/

作者：Julia Evans 译者：FSSlc 校对：wxy

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

在这个关于混合多云陷阱的系列文章的最后一篇当中，让我们来学习一下如何设计一个低风险的云迁移战略。

在这四篇系列文章中，我们了解到了每个组织在做云迁移的时候所应该避免的陷阱 —— 特别是混合多云的情况下。

在第一部分，我们介绍了一些基本的定义以及我们对于混合云以及多云的观点，确保展示了两者之间的区别。在第二部分，我们会对三个陷阱之一进行讨论：为什么成本并不是迁移到云端的显然的推动因素。而且，在第三部分，我们考察了将所有工作向云端进行迁移的可行性。

最后，在这个第四部分中，我们来看看数据上云要做什么。您应该把数据向云端迁移吗？迁移多少？什么数据可以放在云端？又是什么会造成上云风险很大？

数据…数据…数据

影响您对云端数据的所有决策的关键因素在于确定您的带宽以及存储需求。 Gartner 预计 “数据存储在 2018 年将成为一项$173 亿美元的业务”，并且大部分资金是浪费在一些不必要的存储容量上：“但是只需要优化一下工作负载，全球的所有公司就可以节约 620 亿美元的不必要 IT 成本。”根据 Gartner 的研究，非常令人惊讶的是，全球所有的公司“为云服务器平均支付的费用比他们实际的费用多达 36% 。”

如果你已经阅读了本系列的前三个章节，那么你应该不会为此感到惊讶。然而令人更惊讶的是 Gartner 的结论是 “如果全球的公司将他们的服务器数据直接迁移到云端上，仅仅只有 25% 的公司能够做到省钱。”

等一下……工作负载是可以针对云进行优化的，但是只有一小部分公司能通过将数据向云端迁移而节省资金吗？这个又是什么意思？

如果你去认为云服务商会根据带宽来收取云产生的费用，那么将所有的公司内部数据移至云端很快就会成为他们的成本负担。在以下三种情况，公司才可能会觉得值得把数据放在云端中：

• 单个云包括存储和应用程序
• 应用程序在云端，存储在本地
• 应用程序在云端，而且数据缓存也在云端，存储在本地

在第一种情况下，通过将所有的内容都放在单个云服务商来节省带宽成本，但是这会产生一些（供应商）锁定，这个通常与 CIO 的云战略或者风险防范计划所冲突。

第二种方案是仅仅保留应用程序在云端所收集的数据，并且以最小的方式传输到本地存储。这就需要仔细的考虑策略，其中只有最少使用数据的应用程序部署在云端。

第三种情况就是将数据缓存在云端，应用程序和存储的数据被存储在本地。这也就意味着分析、人工智能、机器学习可以在内部运行而无需把数据向云服务商上传，然后处理之后再返回。缓存的数据仅仅基于应用程序对云的需求，甚至进行跨多云的部署缓存。

要想获得更多信息，请下载红帽案例研究，其中描述了跨混合多云环境下的阿姆斯特丹的史基浦机场的数据以及云和部署策略。

数据危险

大多数公司都认识到了他们的数据是在其市场中的专有优势以及知识能力。因此他们会非常仔细的考虑它在云存储的地点。

想象一下这种情况：如果你是一个零售商，全球十大零售商之一。而且你已经计划了很长一段时间云存储战略，并且考虑使用亚马逊的云服务。但是突然间， 亚马逊收购了全食超市，并且准备进入你的市场。

一夜之间，亚马逊已经增长了 50% 的零售规模，你是否还会去信任把零售数据放到他们的云上？如果您的数据已经就在亚马逊云中，你会打算怎么做？您创建云计划时是否考虑过退出策略？虽然亚马逊可能永远不会去利用您的数据潜在价值 —— 该公司可能甚至有针对此的条款 —— 但你能相信世界上任何人的话吗？

陷阱分享，避免陷阱

分享我们在以前经验中看到的一些陷阱来帮助您的公司规划更安全、更持久的云端策略。了解了成本不是显然的推动因素，并非一切东西都应该在云端，而是你必须在云端有效管理数据才是您成功的关键所在。

via: https://opensource.com/article/18/8/data-risky-cloud

作者：Eric D.Schabell 选题：lujun9972 译者：geekmar 校对：wxy

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

这篇文章受到了我与同事讨论使用 切片 slice 作为 栈 stack 的一次聊天的启发。后来话题聊到了 Go 语言中的切片是如何工作的。我认为这些信息对别人也有用，所以就把它记录了下来。

数组

任何关于 Go 语言切片的讨论都要从另一个数据结构也就是 数组 array 开始。Go 的数组有两个特性：

1. 数组的长度是固定的；[5]int 是由 5 个 int 构成的数组，和 [3]int 不同。
2. 数组是值类型。看下面这个示例：

package main

import "fmt"

func main() {
        var a [5]int
        b := a
        b[2] = 7
        fmt.Println(a, b) // prints [0 0 0 0 0] [0 0 7 0 0]
}

语句 b := a 定义了一个类型是 [5]int 的新变量 b，然后把 a 中的内容 复制 到 b 中。改变 b 对 a 中的内容没有影响，因为 a 和 b 是相互独立的值。 ¹

切片

Go 语言的切片和数组的主要有如下两个区别：

1. 切片没有一个固定的长度。切片的长度不是它类型定义的一部分，而是由切片内部自己维护的。我们可以使用内置的 len 函数知道它的长度。 ²
2. 将一个切片赋值给另一个切片时 不会 对切片内容进行复制操作。这是因为切片没有直接持有其内部数据，而是保留了一个指向 底层数组 ³ 的指针。数据都保留在底层数组里。

基于第二个特性，两个切片可以享有共同的底层数组。看下面的示例：

1. 对切片取切片

package main

import "fmt"

func main() {
        var a = []int{1,2,3,4,5}
        b := a[2:]
        b[0] = 0
        fmt.Println(a, b) // prints [1 2 0 4 5] [0 4 5]
}

在这个例子里，a 和 b 享有共同的底层数组 —— 尽管 b 在数组里的起始偏移量不同，两者的长度也不同。通过 b 修改底层数组的值也会导致 a 里的值的改变。

2. 将切片传进函数

package main

import "fmt"

func negate(s []int) {
        for i := range s {
                s[i] = -s[i]
        }
}

func main() {
        var a = []int{1, 2, 3, 4, 5}
        negate(a)
        fmt.Println(a) // prints [-1 -2 -3 -4 -5]
}

在这个例子里，a 作为形参 s 的实参传进了 negate 函数，这个函数遍历 s 内的元素并改变其符号。尽管 nagate 没有返回值，且没有访问到 main 函数里的 a。但是当将之传进 negate 函数内时，a 里面的值却被改变了。

大多数程序员都能直观地了解 Go 语言切片的底层数组是如何工作的，因为它与其它语言中类似数组的工作方式类似。比如下面就是使用 Python 重写的这一小节的第一个示例：

Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = [1,2,3,4,5]
>>> b = a
>>> b[2] = 0
>>> a
[1, 2, 0, 4, 5]

以及使用 Ruby 重写的版本:

irb(main):001:0> a = [1,2,3,4,5]
=> [1, 2, 3, 4, 5]
irb(main):002:0> b = a
=> [1, 2, 3, 4, 5]
irb(main):003:0> b[2] = 0
=> 0
irb(main):004:0> a
=> [1, 2, 0, 4, 5]

在大多数将数组视为对象或者是引用类型的语言也是如此。 ⁴

切片头

切片同时拥有值和指针特性的神奇之处在于理解切片实际上是一个 结构体 struct 类型。通常在 反射 reflect 包内相应部分之后的这个结构体被称作 切片头 slice header 。切片头的定义大致如下：

package runtime

type slice struct {
        ptr   unsafe.Pointer
        len   int
        cap   int
}

这很重要，因为和 map 以及 chan 这两个类型不同，切片是值类型，当被赋值或者被作为参数传入函数时候会被复制过去。

程序员们都能理解 square 的形参 v 和 main 中声明的 v 的是相互独立的。请看下面的例子：

package main

import "fmt"

func square(v int) {
        v = v * v
}

func main() {
        v := 3
        square(v)
        fmt.Println(v) // prints 3, not 9
}

因此 square 对自己的形参 v 的操作没有影响到 main 中的 v。下面这个示例中的 s 也是 main 中声明的切片 s 的独立副本， 而不是 指向 main 的 s 的指针。

package main

import "fmt"

func double(s []int) {
        s = append(s, s...)
}

func main() {
        s := []int{1, 2, 3}
        double(s)
        fmt.Println(s, len(s)) // prints [1 2 3] 3
}

Go 的切片是作为值传递而不是指针这一点不太寻常。当你在 Go 内定义一个结构体时，90% 的时间里传递的都是这个结构体的指针 ⁵ 。切片的传递方式真的很不寻常，我能想到的唯一与之相同的例子只有 time.Time。

切片作为值传递而不是作为指针传递这一特殊行为会让很多想要理解切片的工作原理的 Go 程序员感到困惑。你只需要记住，当你对切片进行赋值、取切片、传参或者作为返回值等操作时，你是在复制切片头结构的三个字段：指向底层数组的指针、长度，以及容量。

总结

我们来用引出这一话题的切片作为栈的例子来总结下本文的内容：

package main

import "fmt"

func f(s []string, level int) {
        if level > 5 {
               return
        }
        s = append(s, fmt.Sprint(level))
        f(s, level+1)
        fmt.Println("level:", level, "slice:", s)
}

func main() {
        f(nil, 0)
}

在 main 函数的最开始我们把一个 nil 切片传给了函数 f 作为 level 0 。在函数 f 里我们把当前的 level 添加到切片的后面，之后增加 level 的值并进行递归。一旦 level 大于 5，函数返回，打印出当前的 level 以及它们复制到的 s 的内容。

level: 5 slice: [0 1 2 3 4 5]
level: 4 slice: [0 1 2 3 4]
level: 3 slice: [0 1 2 3]
level: 2 slice: [0 1 2]
level: 1 slice: [0 1]
level: 0 slice: [0]

你可以注意到在每一个 level 内 s 的值没有被别的 f 的调用影响，尽管当计算更高的 level 时作为 append 的副产品，调用栈内的四个 f 函数创建了四个底层数组 ⁶ ，但是没有影响到当前各自的切片。

扩展阅读

如果你想要了解更多 Go 语言内切片运行的原理，我建议看看 Go 博客里的这些文章：

• Go Slices: usage and internals (blog.golang.org)
• Arrays, slices (and strings): The mechanics of 'append' (blog.golang.org)

相关文章：

1. If a map isn't a reference variable, what is it?
2. What is the zero value, and why is it useful?
3. The empty struct
4. Should methods be declared on T or *T

1. 这不是数组才有的特性，在 Go 语言里中 一切 赋值都是复制过去的。 ↩
2. 你也可以在对数组使用 len 函数，但是其结果本来就人尽皆知。 ↩
3. 有时也叫做 后台数组 backing array ，以及更不严谨的说法是后台切片。 ↩
4. Go 语言里我们倾向于说值类型以及指针类型，因为 C++ 的 引用 reference 类型这个词产生误会。但在这里我认为调用数组作为引用类型是没有问题的。 ↩
5. 如果你的结构体有定义在其上的方法或者用于满足某个接口，那么你传入结构体指针的比率可以飙升到接近 100%。 ↩
6. 证明留做习题。 ↩

via: https://dave.cheney.net/2018/07/12/slices-from-the-ground-up

作者：Dave Cheney 译者：name1e5s 校对：pityonline

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

对于 Linux 图形界面用户和 Windows 用户来说获取系统硬件信息都不算问题，但是对命令行用户来说想要获取这些细节时有点儿麻烦。

甚至我们中的大多数都不知道获取这些信息最好的命令是什么。Linux 中有许多可用的工具集来获取诸如制造商、型号和序列号等硬件信息。

在这里我尝试写下获取这些细节的可能的方式，你可以挑选一种最好用的。

你必须知道所有这些信息，因为当你向硬件制造商提交任何硬件问题时，你会需要它们。

这可以通过 6 种方法来实现，下面我来演示一下怎么做。

方法一：使用 dmidecode 命令

dmidecode 是一个读取电脑 DMI（ 桌面管理接口 Desktop Management Interface ）表内容并且以人类可读的格式显示系统硬件信息的工具。（也有人说是读取 SMBIOS —— 系统管理 BIOS System Management BIOS ）

这个表包含系统硬件组件的说明，也包含如序列号、制造商、发布日期以及 BIOS 修订版本号等其它有用的信息。

DMI 表不仅描述了当前的系统构成，还可以报告可能的升级信息（比如可以支持的最快的 CPU 或者最大的内存容量）。

这将有助于分析你的硬件兼容性，比如是否支持最新版本的程序。

# dmidecode -t system

# dmidecode 2.12
# SMBIOS entry point at 0x7e7bf000
SMBIOS 2.7 present.

Handle 0x0024, DMI type 1, 27 bytes
System Information
 Manufacturer: IBM
 Product Name: System x2530 M4: -[1214AC1]-
 Version: 0B
 Serial Number: MK2RL11
 UUID: 762A99BF-6916-450F-80A6-B2E9E78FC9A1
 Wake-up Type: Power Switch
 SKU Number: Not Specified
 Family: System X

Handle 0x004B, DMI type 12, 5 bytes
System Configuration Options
 Option 1: JP20 pin1-2: TPM PP Disable, pin2-3: TPM PP Enable

Handle 0x004D, DMI type 32, 20 bytes
System Boot Information
 Status: No errors detected

推荐阅读： Dmidecode –– 获取 Linux 系统硬件信息的简单方式

方法二：使用 inxi 命令

inxi 是 Linux 上查看硬件信息的一个灵巧的小工具，它提供了大量的选项来获取所有硬件信息，这是我在现有的其它 Linux 工具集里所没见到过的。它是从 locsmif 编写的古老的但至今看来都异常灵活的 infobash fork 出来的。

inxi 是一个可以快速显示系统硬件、CPU、驱动、Xorg、桌面、内核、GCC 版本、进程、内存使用以及大量其它有用信息的脚本，也可以用来做技术支持和调试工具。

# inxi -M
Machine: Device: server System: IBM product: N/A v: 0B serial: MK2RL11
 Mobo: IBM model: 00Y8494 serial: 37M17D UEFI: IBM v: -[VVE134MUS-1.50]- date: 08/30/2013

推荐阅读： inxi —— 一个很棒的查看 Linux 硬件信息的工具

方法三：使用 lshw 命令

lshw（指 硬件监听器 Hardware Lister ）是一个小巧灵活的工具，可以生成如内存配置、固件版本、主板配置、CPU 版本和速度、缓存配置、USB、网卡、显卡、多媒体、打印机以及总线速度等机器中各种硬件组件的详细报告。

它通过读取 /proc 目录下各种文件的内容和 DMI 表来生成硬件信息。

lshw 必须以超级用户的权限运行来检测完整的硬件信息，否则它只汇报部分信息。lshw 里有一个叫做 class 的特殊选项，它可以以详细的模式显示特定的硬件信息。

# lshw -C system
enal-dbo01t
 description: Blade
 product: System x2530 M4: -[1214AC1]-
 vendor: IBM
 version: 0B
 serial: MK2RL11
 width: 64 bits
 capabilities: smbios-2.7 dmi-2.7 vsyscall32
 configuration: boot=normal chassis=enclosure family=System X uuid=762A99BF-6916-450F-80A6-B2E9E78FC9A1

推荐阅读： LSHW (Hardware Lister) –– 获取 Linux 硬件信息的灵巧的小工具

方法四：使用 /sys 文件系统

内核在 /sys 目录下的文件中公开了一些 DMI 信息。因此，我们可以通过如下方式运行 grep 命令来轻易地获取机器类型。

# grep "" /sys/class/dmi/id/[pbs]*

或者，可以使用 cat 命令仅打印出特定的详细信息。

# cat /sys/class/dmi/id/board_vendor
IBM

# cat /sys/class/dmi/id/product_name
System x2530 M4: -[1214AC1]-

# cat /sys/class/dmi/id/product_serial
MK2RL11

# cat /sys/class/dmi/id/bios_version
-[VVE134MUS-1.50]-

方法五：使用 dmesg 命令

dmesg 命令是在 Linux 上 syslogd 或 klogd 启动前用来记录内核消息（启动阶段的消息）的。它通过读取内核的环形缓冲区来获取数据。在排查问题或只是尝试获取系统硬件信息时，dmesg 非常有用。

# dmesg | grep -i DMI
DMI: System x2530 M4: -[1214AC1]-/00Y8494, BIOS -[VVE134MUS-1.50]- 08/30/2013

方法六：使用 hwinfo 命令

hwinfo（ 硬件信息 hardware information ）是另一个很棒的工具，用于检测当前系统存的硬件，并以人类可读的方式显示各种硬件模块的详细信息。

它报告关于 CPU、内存、键盘、鼠标、显卡、声卡、存储、网络接口、磁盘、分区、BIOS 以及桥接器等信息。它可以比其它像 lshw、dmidecode 或 inxi 等工具显示更为详细的信息。

hwinfo 使用 libhd 库 libhd.so 来收集系统上的硬件信息。该工具是为 openSuse 特别设计的，后来其它发行版也将它包含在其官方仓库中。

# hwinfo | egrep "system.hardware.vendor|system.hardware.product"
 system.hardware.vendor = 'IBM'
 system.hardware.product = 'System x2530 M4: -[1214AC1]-'

推荐阅读： hwinfo (Hardware Info) –– 一款灵活的检测 Linux 系统硬件信息的工具

via: https://www.2daygeek.com/how-to-check-system-hardware-manufacturer-model-and-serial-number-in-linux/

作者：VINOTH KUMAR 选题：lujun9972 译者：icecoobe 校对：pityonline

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

包管理器在 Linux 软件管理中扮演了重要角色。这里对一些主要的包管理器进行了对比。

今天，每个可计算设备都会使用某种软件来完成预定的任务。在软件开发的上古时期，为了找出软件中的“虫”和其它缺陷，软件会被严格的测试。在近十年间，软件被通过互联网来频繁分发，以试图通过持续不断的安装新版本的软件来解决软件的缺陷问题。在很多情况下，每个独立的应用软件都有其自带的更新器。而其它一些软件则让用户自己去搞明白如何获取和升级软件。

Linux 较早采用了维护一个中心化的软件仓库来发布软件更新这种做法，用户可以在这个软件仓库里查找并安装软件。在这篇文章里， 笔者将回顾在 Linux 上的如何进行软件安装的历史，以及现代操作系统如何保持更新以应对软件安全漏洞（CVE）不断的曝光。

那么在包管理器出现之前在 Linux 上是如何安装软件的呢？

曾几何时，软件都是通过 FTP 或邮件列表（LCTT 译注：即通过邮件列表发布源代码的补丁包）来分发的（最终这些发布方式在互联网的迅猛发展下都演化成为一个个现今常见的软件发布网站）。（一般在一个 tar 文件中）只有一个非常小的文件包含了创建二进制的说明。你需要做的是先解压这个包，然后仔细阅读当中的 README 文件， 如果你的系统上恰好有 GCC（LCTT 译注：GNU C Compiler）或者其它厂商的 C 编译器的话，你得首先运行 ./configure 脚本，并在脚本后添加相应的参数，如库函数的路径、创建可执行文件的路径等等。除此之外，这个配置过程也会检查你操作系统上的软件依赖是否满足安装要求。如果缺失了任何主要的依赖，该配置脚本会退出不再继续安装，直到你满足了该依赖。如果该配置脚本正常执行完毕，将会创建一个 Makefile 文件。

当有了一个 Makefile 文件时， 你就可以接下去执行 make 命令（该命令由你所使用的编译器提供）。make 命令也有很多参数，被称为 make 标识 flag ，这些标识能为你的系统优化最终生成出来的二进制可执行文件。在计算机世界的早期，这些优化是非常重要的，因为彼时的计算机硬件正在为了跟上软件迅速的发展而疲于奔命。今日今时，编译标识变得更加通用而不是为了优化哪些具体的硬件型号，这得益于现代硬件和现代软件相比已经变得成本低廉，唾手可得。

最后，在 make 完成之后， 你需要运行 make install （或 sudo make install）（LCTT 译注：依赖于你的用户权限） 来“真正”将这个软件安装到你的系统上。可以想象，为你系统上的每一个软件都执行上述的流程将是多么无聊费时，更不用说如果更新一个已经安装的软件将会多复杂，多么需要精力投入。（LCTT 译注：上述流程也称 CMMI 安装， 即Configure、Make、Make Install）

那么软件包是什么？

软件包 package （LCTT 译注：下文简称“包”）这个概念是用来解决在软件安装、升级过程中的复杂性的。包将软件安装升级中需要的多个数据文件合并成一个单独的文件，这将便于传输和（通过压缩文件来）减小存储空间（LCTT 译注：减少存储空间这一点在现在已经不再重要），包中的二进制可执行文件已根据开发者所选择的编译标识预编译。包本身包括了所有需要的元数据，如软件的名字、软件的说明、版本号，以及要运行这个软件所需要的依赖包等等。

不同流派的 Linux 发行版都创造了它们自己的包格式，其中最常用的包格式有：

• .deb：这种包格式由 Debian、Ubuntu、Linux Mint 以及其它的变种使用。这是最早被发明的包类型。
• .rpm：这种包格式最初被称作 红帽包管理器 Red Hat Package Manager （LCTT 译注： 取自英文的首字母）。使用这种包的 Linux 发行版有 Red Hat、Fedora、SUSE 以及其它一些较小的发行版。
• .tar.xz：这种包格式只是一个软件压缩包而已，这是 Arch Linux 所使用的格式。

尽管上述的包格式自身并不能直接管理软件的依赖问题，但是它们的出现将 Linux 软件包管理向前推进了一大步。

软件仓库到底是什么？

多年以前（当智能电话还没有像现在这样流行时），非 Linux 世界的用户是很难理解软件仓库的概念的。甚至今时今日，大多数完全工作在 Windows 下的用户还是习惯于打开浏览器，搜索要安装的软件（或升级包），下载然后安装。但是，智能电话传播了软件“商店”（LCTT 译注： 对应 Linux 里的软件仓库）这样一个概念。智能电话用户获取软件的方式和包管理器的工作方式已经非常相近了。些许不同的是，尽管大多数软件商店还在费力美化它的图形界面来吸引用户，大多数 Linux 用户还是愿意使用命令行来安装软件。总而言之，软件仓库是一个中心化的可安装软件列表，上面列举了在当前系统中预先配置好的软件仓库里所有可以安装的软件。下面我们举一些例子来说在各个不同的 Linux 发行版下如何在对应的软件仓库里搜寻某个特定的软件（输出有截断）。

在 Arch Linux 下使用 aurman：

user@arch ~ $  aurman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
aur/kate-root 18.04.0-1 (11, 1.139399)
    Advanced Text Editor, patched to be able to run as root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
    An advanced editor component which is used in numerous KDE applications requiring a text editing component

在 CentOS 7 下使用 yum：

[user@centos ~]$ yum search kate

kate-devel.x86_64 : Development files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.x86_64 : Kate kpart plugin

在 Ubuntu 下使用 apt：

user@ubuntu ~ $ apt search kate
Sorting... Done
Full Text Search... Done

kate/xenial 4:15.12.3-0ubuntu2 amd64
  powerful text editor

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
  shared data files for Kate text editor

kate-dbg/xenial 4:15.12.3-0ubuntu2 amd64
  debugging symbols for Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
  shared data files for Kate text editor

最好用的包管理器有哪些？

如上示例的输出，包管理器用来和相应的软件仓库交互，获取软件的相应信息。下面对它们做一个简短介绍。

基于 PRM 包格式的包管理器

更新基于 RPM 的系统，特别是那些基于 Red Hat 技术的系统，有着非常有趣而又详实的历史。实际上，现在的 YUM) 版本（用于 企业级发行版）和 DNF（用于社区版）就融合了好几个开源项目来提供它们现在的功能。

Red Hat 最初使用的包管理器，被称为 RPM)（ 红帽包管理器 Red Hat Package Manager ），时至今日还在使用着。不过，它的主要作用是安装本地的 RPM 包，而不是去在软件仓库搜索软件。后来开发了一个叫 up2date 的包管理器，它被用来通知用户包的最新更新，还能让用户在远程仓库里搜索软件并便捷的安装软件的依赖。尽管这个包管理器尽职尽责，但一些社区成员还是感觉 up2date 有着明显的不足。

现在的 YUM 来自于好几个不同社区的努力。1999-2001 年一群在 Terra Soft Solution 的伙计们开发了 黄狗更新器 Yellowdog Updater （YUP），将其作为 Yellow Dog Linux 图形安装器的后端。 杜克大学 Duke University 喜欢这个主意就决定去增强它的功能，它们开发了 黄狗更新器--修改版 Yellowdog Updater, Modified （YUM），这最终被用来帮助管理杜克大学的 Red Hat 系统。Yum 壮大的很快，到 2005 年，它已经被超过一半的 Linux 市场所采用。今日，几乎所有的使用 RPM 的的 Linux 都会使用 YUM 来进行包管理（当然也有一些例外）。

使用 YUM

为了能让 YUM 正常工作，比如从一个软件仓库里下载和安装包，仓库说明文件必须放在 /etc/yum.repos.d/ 目录下且必须以 .repo 作为扩展名。如下是一个示例文件的内容：

[local_base]
name=Base CentOS  (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0

这是笔者本地仓库之一，这也是为什么 gpgcheck 值为 0 的原因。如果这个值为 1 的话，每个包都需要被密钥签名，相应的密钥（的公钥）也要导入到安装软件的系统上。因为这个软件仓库是笔者本人维护的且笔者信任这个仓库里的包，所以就不去对它们一一签名了。

当一个仓库文件准备好时，你就能开始从远程软件仓库开始安装文件了。最基本的命令是 yum update，这将会更新所有已安装的包。你也不需要用特殊的命令来更新仓库本身，所有这一切都已自动完成了。运行命令示例如下：

[user@centos ~]$ sudo yum update
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
local_base                             | 3.6 kB  00:00:00    
local_epel                             | 2.9 kB  00:00:00    
local_rpm_forge                        | 1.9 kB  00:00:00    
local_updates                          | 3.4 kB  00:00:00    
spideroak-one-stable                   | 2.9 kB  00:00:00    
zfs                                    | 2.9 kB  00:00:00    
(1/6): local_base/group_gz             | 166 kB  00:00:00    
(2/6): local_updates/primary_db        | 2.7 MB  00:00:00    
(3/6): local_base/primary_db           | 5.9 MB  00:00:00    
(4/6): spideroak-one-stable/primary_db |  12 kB  00:00:00    
(5/6): local_epel/primary_db           | 6.3 MB  00:00:00    
(6/6): zfs/x86_64/primary_db           |  78 kB  00:00:00    
local_rpm_forge/primary_db             | 125 kB  00:00:00    
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check

如果你确定想让 YUM 在执行任何命令时不要停下来等待用户输入，你可以命令里放 -y 标志，如 yum update -y。

安装一个新包很简单。首先，用 yum search 搜索包的名字。

[user@centos ~]$ yum search kate

artwiz-aleczapka-kates-fonts.noarch : Kates font in Artwiz family
ghc-highlighting-kate-devel.x86_64 : Haskell highlighting-kate library development files
kate-devel.i686 : Development files for kate
kate-devel.x86_64 : Development files for kate
kate-libs.i686 : Runtime files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.i686 : Kate kpart plugin

当你找到你要安装的包后，你可以用 sudo yum install kate-devel -y 来安装。如果你安装了你不需要的软件，可以用 sudo yum remove kdate-devel -y 来从系统上删除它，默认情况下，YUM 会删除软件包以及它的依赖。

有些时候你甚至都不清楚要安装的包的名称，你只知道某个实用程序的名字。（LCTT 译注：可以理解实用程序是安装包的子集）。例如，你想找实用程序 updatedb（它是用来创建/更新由 locate 命令所使用的数据库的），直接试图安装 updatedb 会返回下面的结果：

[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do

你可以搜索实用程序来自哪个包：

[user@centos ~]$ yum whatprovides *updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile

bacula-director-5.2.13-23.1.el7.x86_64 : Bacula Director files
Repo        : local_base
Matched from:
Filename    : /usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 : An utility for finding files by name
Repo        : local_base
Matched from:
Filename    : /usr/bin/updatedb

笔者在前面使用星号的原因是 yum whatprovides 使用路径去匹配文件。笔者不确定文件在哪里，所以使用星号去指代任意路径。

当然 YUM 还有很多其它的可选项。这里笔者希望你能够自己查看 YUM 的手册来找到其它额外的可选项。

时髦的 Yum Dandified Yum （DNF）是 YUM 的下一代接班人。从 Fedora 18 开始被作为包管理器引入系统，不过它并没有被企业版所采用，所以它只在 Fedora（以及变种）上占据了主导地位。DNF 的用法和 YUM 几乎一模一样，它主要是用来解决性能问题、晦涩无说明的API、缓慢/不可靠的依赖解析，以及偶尔的高内存占用。DNF 是作为 YUM 的直接替代品来开发的，因此这里笔者就不重复它的用法了，你只用简单的将 yum 替换为 dnf 就行了。

使用 Zypper

Zypper 是用来管理 RPM 包的另外一个包管理器。这个包管理器主要用于 SUSE（和 openSUSE），在MeeGo、Sailfish OS、Tizen 上也有使用。它最初开发于 2006 年，已经经过了多次迭代。除了作为系统管理工具 YaST 的后端和有些用户认为它比 YUM 要快之外也没有什么好多说的。

Zypper 使用与 YUM 非常相像。它被用来搜索、更新、安装和删除包，简单的使用命令如下：

zypper search kate
zypper update
zypper install kate
zypper remove kate

主要的不同来自于使用 Zypper 的系统在添加软件仓库的做法上，Zypper 使用包管理器本身来添加软件仓库。最通用的方法是通过一个 URL，但是 Zypper 也支持从仓库文件里导入。

suse:~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Adding repository 'vlc' [done]
Repository 'vlc' successfully added

Enabled     : Yes
Autorefresh : No
GPG Check   : Yes
URI         : http://download.videolan.org/pub/vlc/SuSE/15.0
Priority    : 99

你也能用相似的手段来删除软件仓库：

suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.

使用 zypper repos 命令来查看当前系统上的软件仓库的状态：

suse:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                                    | Enabled | GPG Check | Refresh
---|---------------------------|-----------------------------------------|---------|-----------|--------
 1 | repo-debug                | openSUSE-Leap-15.0-Debug                | No      | ----      | ----  
 2 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss        | No      | ----      | ----  
 3 | repo-debug-update         | openSUSE-Leap-15.0-Update-Debug         | No      | ----      | ----  
 4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | No      | ----      | ----  
 5 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss              | Yes     | ( p) Yes  | Yes    
 6 | repo-oss                  | openSUSE-Leap-15.0-Oss                  | Yes     | ( p) Yes  | Yes    

zypper 甚至还有和 YUM 相同的功能：搜索包含文件或二进制的包。和 YUM 有所不同的是，它在命令行里使用破折号（但是这个搜索方法现在被废除了……）

localhost:~ # zypper what-provides kate
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...

S  | Name | Summary              | Type      
---|------|----------------------|------------
i+ | Kate | Advanced Text Editor | application
i  | kate | Advanced Text Editor | package  

YUM、DNF 和 Zypper 三剑客拥有的功能比在这篇小文里讨论的要多得多，请查看官方文档来得到更深入的信息。

基于 Debian 的包管理器

作为一个现今仍在被积极维护的最古老的 Linux 发行版之一，Debian 的包管理系统和基于 RPM 的系统的包管理系统非常类似。它使用扩展名为 “.deb” 的包，这种文件能被一个叫做 dpkg 的工具所管理。dpgk 同 rpm 非常相似，它被设计成用来管理在存在于本地（硬盘）的包。它不会去做包依赖关系解析（它会做依赖关系检查，不过仅此而已），而且在同远程软件仓库交互上也并无可靠的途径。为了提高用户体验并便于使用，Debian 项目开始了一个软件项目：Deity，最终这个代号被丢弃并改成了现在的 高级打包工具 Advanced Pack Tool （APT）。

在 1998 年，APT 测试版本发布（甚至早于 1999 年的 Debian 2.1 发布），许多用户认为 APT 是基于 Debian 系统标配功能之一。APT 使用了和 RPM 一样的风格来管理仓库，不过和 YUM 使用单独的 .repo 文件不同，APT 曾经使用 /etc/apt/sources.list 文件来管理软件仓库，后来的变成也可以使用 /etc/apt/sources.d 目录来管理。如同基于 RPM 的系统一样，你也有很多很多选项配置来完成同样的事情。你可以编辑和创建前述的文件，或者使用图形界面来完成上述工作（如 Ubuntu 的“Software & Updates”），为了给所有的 Linux 发行版统一的待遇，笔者将会只介绍命令行的选项。 要想不直接编辑文件内容而直接增加软件仓库的话，可以用如下命令：

user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"

这个命令将会在 /etc/apt/sources.list.d 目录里创建一个 spideroakone.list 文件。显而易见，文件里的内容依赖于所添加的软件仓库，如果你想加一个 个人软件包存档 Personal Package Archive （PPA）的话，你可以用如下的办法：

user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktop

注意： Debian 原生并不支持本地 PPA 。

在添加了一个软件仓库后，需要通知基于 Debian 的系统有一个新的仓库可以用来搜索包，可以运行 apt-get update 来完成：

user@ubuntu:~$ sudo apt-get update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:2 http://APT.spideroak.com/ubuntu-spideroak-hardy release InRelease
Hit:3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Get:4 http://ca.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]              
Get:5 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [517 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [455 kB]      
Get:7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [221 kB]    
...

Fetched 6,399 kB in 3s (2,017 kB/s)                                          
Reading package lists... Done

现在新的软件仓库已经在你的系统里安装并更新好了，你可以用 apt-cache 来搜索你想要的包了。

user@ubuntu:~$ apt-cache search kate
aterm-ml - Afterstep XVT - a VT102 emulator for the X window system
frescobaldi - Qt4 LilyPond sheet music editor
gitit - Wiki engine backed by a git or darcs filestore
jedit - Plugin-based editor for programmers
kate - powerful text editor
kate-data - shared data files for Kate text editor
kate-dbg - debugging symbols for Kate
katepart - embeddable text editor component

要安装 kate，简单的运行下面的命令：

user@ubuntu:~$ sudo apt-get install kate

要是删除一个包，使用 apt-get remove：

user@ubuntu:~$ sudo apt-get remove kate

要探索一个包的话，APT 并没有提供一个类似于 yum whatprovides 的功能，如果你想深入包内部去确定一个特定的文件的话，也有一些别的方法能帮你完成这个目标，

如： 用 dpkg

user@ubuntu:~$ dpkg -S /bin/ls
coreutils: /bin/ls

或者： apt-file

user@ubuntu:~$ sudo apt-get install apt-file -y
user@ubuntu:~$ sudo apt-file update
user@ubuntu:~$ apt-file search kate

与 yum whatprovides 不同的是，apt-file search 的问题是因为自动添加了通配符搜索而输出过于详细（除非你知道确切的路径），最终在结果里包括了所有包含有 “kate” 的结果。

kate: /usr/bin/kate
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebacktracebrowserplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebuildplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katecloseexceptplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katectagsplugin.so

上面这些例子大部分都使用了 apt-get。请注意现今大多数的 Ubuntu 教程里都径直使用了 apt。 单独一个 apt 设计用来实现那些最常用的 APT 命令的。apt 命令看上去是用来整合那些被分散在 apt-get、apt-cache 以及其它一些命令的的功能的。它还加上了一些额外的改进，如色彩、进度条以及其它一些小功能。上述的常用命令都能被 apt 替代，但是并不是所有的基于 Debian 的系统都能使用 apt 接受安全包补丁的，你有可能要安装额外的包的实现上述功能。

基于 Arch 的包管理器

Arch Linux 使用称为 packman 的包管理器。和 .deb 以及 .rpm 不同，它使用更为传统的 LZMA2 压缩包形式 .tar.xz 。这可以使 Arch Linux 包能够比其它形式的压缩包（如 gzip）有更小的尺寸。自从 2002 年首次发布以来， pacman 一直在稳定发布和改善。使用它最大的好处之一是它支持 Arch Build System，这是一个从源代码级别构建包的构建系统。该构建系统借助一个叫 PKGBUILD 的文件，这个文件包含了如版本号、发布号、依赖等等的元数据，以及一个为编译遵守 Arch Linux 需求的包所需要的带有必要的编译选项的脚本。而编译的结果就是前文所提的被 pacman 所使用的 .tar.xz 的文件。

上述的这套系统技术上导致了 Arch 用户仓库 Arch User Respository （AUR）的产生，这是一个社区驱动的软件仓库，仓库里包括有 PKGBUILD 文件以及支持补丁或脚本。这给 Arch Linux 带了无穷无尽的软件资源。最为明显的好处是如果一个用户（或开发者）希望他开发的软件能被广大公众所使用，他不必通过官方途径去在主流软件仓库获得许可。而不利之处则是它必须将依赖社区的流程，类似于 Docker Hub、 Canonical 的 Snap Packages（LCTT 译注： Canonical 是 Ubuntu 的发行公司），或者其它类似的机制。有很多特定于 AUR 的包管理器能被用来从 AUR 里的 PGKBUILD 文件下载、编译、安装，下面我们来仔细看看怎么做。

使用 pacman 和官方软件仓库

Arch 的主要包管理器：pacman，使用标识位而不是像 yum 或 apt 一样使用命令词。例如，要搜索一个包，你要用 pacman -Ss 。和 Linux 上别的命令一样，你可以找到 pacman 的手册页和在线帮助。pacman 大多数的命令都使用了同步（-S）这个标识位。例如：

user@arch ~ $ pacman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
extra/libkate 0.4.1-6 [installed]
    A karaoke and text codec for embedding in ogg
extra/libtiger 0.3.4-5 [installed]
    A rendering library for Kate streams using Pango and Cairo
extra/ttf-cheapskate 2.0-12
    TTFonts collection from dustimo.com
community/haskell-cheapskate 0.1.1-100
    Experimental markdown processor.

Arch 也使用和别的包管理器类似的软件仓库。在上面的输出中，搜索结果前面有标明它是从哪个仓库里搜索到的（这里是 extra/ 和 community/）。同 Red Hat 和 Debian 系统一样，Arch 依靠用户将软件仓库的信息加入到一个特定的文件里：/etc/pacman.conf。下面的例子非常接近一个仓库系统。笔者还打开了 [multilib] 仓库来支持 Steam：

[options]
Architecture = auto

Color
CheckSpace

SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

[multilib]
Include = /etc/pacman.d/mirrorlist

你也可以在 pacman.conf 里指定具体的 URL。这个功能可以用来确保在某一时刻所有的包来自一个确定的地方，比如，如果一个安装包存在严重的功能缺陷并且很不幸它恰好还有几个包依赖，你能及时回滚到一个安全点，如果你已经在 pacman.conf 里加入了具体的 URL 的话，你就用用这个命令降级你的系统。

[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch

和 Debian 系统一样，Arch 并不会自动更新它的本地仓库。你可以用下面的命令来刷新包管理器的数据库：

user@arch ~ $ sudo pacman -Sy

:: Synchronizing package databases...
 core                                                                     130.2 KiB   851K/s 00:00 [##########################################################] 100%
 extra                                                                   1645.3 KiB  2.69M/s 00:01 [##########################################################] 100%
 community                                                                  4.5 MiB  2.27M/s 00:02 [##########################################################] 100%
 multilib is up to date

你可以看到在上述的输出中，pacman 认为 multilib 包数据库是更新到最新状态的。如果你认为这个结果不正确的话，你可以强制运行刷新：pacman -Syy。如果你想升级你的整个系统的话（不包括从 AUR 安装的包），你可以运行 pacman -Syu：

user@arch ~ $ sudo pacman -Syu

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (45) ceph-13.2.0-2  ceph-libs-13.2.0-2  debootstrap-1.0.105-1  guile-2.2.4-1  harfbuzz-1.8.2-1  harfbuzz-icu-1.8.2-1  haskell-aeson-1.3.1.1-20
              haskell-attoparsec-0.13.2.2-24  haskell-tagged-0.8.6-1  imagemagick-7.0.8.4-1  lib32-harfbuzz-1.8.2-1  lib32-libgusb-0.3.0-1  lib32-systemd-239.0-1
              libgit2-1:0.27.2-1  libinput-1.11.2-1  libmagick-7.0.8.4-1  libmagick6-6.9.10.4-1  libopenshot-0.2.0-1  libopenshot-audio-0.1.6-1  libosinfo-1.2.0-1
              libxfce4util-4.13.2-1  minetest-0.4.17.1-1  minetest-common-0.4.17.1-1  mlt-6.10.0-1  mlt-python-bindings-6.10.0-1  ndctl-61.1-1  netctl-1.17-1
              nodejs-10.6.0-1  

Total Download Size:      2.66 MiB
Total Installed Size:   879.15 MiB
Net Upgrade Size:      -365.27 MiB

:: Proceed with installation? [Y/n]

在前面提到的降级系统的情景中，你可以运行 pacman -Syyuu 来强行降级系统。你必须重视这一点：虽然在大多数情况下这不会引起问题，但是这种可能性还是存在，即降级一个包或几个包将会引起级联传播的失败并会将你的系统处于不一致的状态（LCTT 译注：即系统进入无法正常使用的状态），请务必小心！

运行 pacman -S kate 来安装一个包。

user@arch ~ $ sudo pacman -S kate

resolving dependencies...
looking for conflicting packages...

Packages (7) editorconfig-core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Download Size:   10.94 MiB
Total Installed Size:  38.91 MiB

:: Proceed with installation? [Y/n]

你可以运行 pacman -R kate 来删除一个包。这将会只删除这个包自身而不会去删除它的依赖包。

user@arch ~ $ sudo pacman -S kate

checking dependencies...

Packages (1) kate-18.04.2-2

Total Removed Size:  20.30 MiB

:: Do you want to remove these packages? [Y/n]

如果你想删除没有被其它包依赖的包，你可以运行 pacman -Rs：

user@arch ~ $ sudo pacman -Rs kate

checking dependencies...

Packages (7) editorconfig-core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Removed Size:  38.91 MiB

:: Do you want to remove these packages? [Y/n]

在笔者看来，Pacman 是搜索一个指定实用程序中的包名的最齐全的工具。如上所示，YUM 和 APT 都依赖于‘路径’去搜索到有用的结果，而 Pacman 则做了一些智能的猜测，它会去猜测你最有可能想搜索的包。

user@arch ~ $ sudo pacman -Fs updatedb
core/mlocate 0.26.git.20170220-1
    usr/bin/updatedb

user@arch ~ $ sudo pacman -Fs kate
extra/kate 18.04.2-2
    usr/bin/kate

使用 AUR

有很多流行的 AUR 包管理器助手。其中 yaourt 和 pacaur 颇为流行。不过，这两个项目已经被 Arch Wiki 列为“不继续开发以及有已知的问题未解决”。因为这个原因，这里直接讨论 aurman，除了会搜索 AUR 以及包含几个有帮助的（其实很危险）的选项之外，它的工作机制和 pacman 极其类似。从 AUR 安装一个包将会初始化包维护者的构建脚本。你将会被要求输入几次授权以便让程序继续进行下去（为了简短起见，笔者截断了输出）。

aurman -S telegram-desktop-bin
~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
...
~~ calculating solutions...

:: The following 1 package(s) are getting updated:
   aur/telegram-desktop-bin  1.3.0-1  ->  1.3.9-1

?? Do you want to continue? Y/n: Y

~~ looking for new pkgbuilds and fetching them...
Cloning into 'telegram-desktop-bin'...

remote: Counting objects: 301, done.
remote: Compressing objects: 100% (152/152), done.
remote: Total 301 (delta 161), reused 286 (delta 147)
Receiving objects: 100% (301/301), 76.17 KiB | 639.00 KiB/s, done.
Resolving deltas: 100% (161/161), done.
?? Do you want to see the changes of telegram-desktop-bin? N/y: N

[sudo] password for user:

...
==> Leaving fakeroot environment.
==> Finished making: telegram-desktop-bin 1.3.9-1 (Thu 05 Jul 2018 11:22:02 AM EDT)
==> Cleaning up...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) telegram-desktop-bin-1.3.9-1

Total Installed Size:  88.81 MiB
Net Upgrade Size:       5.33 MiB

:: Proceed with installation? [Y/n]

依照你所安装的包的复杂性程度的高低，有时你将会被要求给出进一步的输入，为了避免这些反复的输入，aurman 允许你使用 --noconfirm 和 --noedit 选项。这相当于说“接受所有的预定设置，并相信包管理器不会干坏事”。使用这两个选项时请务必小心！！，虽然这些选项本身不太会破坏你的系统，你也不能盲目的接受他人的脚本程序。

总结

这篇文章当然只能触及包管理器的皮毛。还有很多别的包管理器笔者没有在这篇文章里谈及。有些 Linux 发布版，如 Ubuntu 或 Elementary OS，已经在图形版的包管理器的开发上有了长远的进展。

如果你对包管理器的更高级功能有进一步的兴趣，请在评论区留言，笔者很乐意进一步的写一写相关的文章。

附录

# search for packages
yum search <package>
dnf search <package>
zypper search <package>
apt-cache search <package>
apt search <package>
pacman -Ss <package>

# install packages
yum install <package>
dnf install <package>
zypper install <package>
apt-get install <package>
apt install <package>
pacman -Ss <package>

# update package database, not required by yum, dnf and zypper
apt-get update
apt update
pacman -Sy

# update all system packages
yum update
dnf update
zypper update
apt-get upgrade
apt upgrade
pacman -Su

# remove an installed package
yum remove <package>
dnf remove <package>
apt-get remove <package>
apt remove <package>
pacman -R <package>
pacman -Rs <package>

# search for the package name containing specific file or folder
yum whatprovides *<binary>
dnf whatprovides *<binary>
zypper what-provides <binary>
zypper search --provides <binary>
apt-file search <binary>
pacman -Sf <binary>

via: https://opensource.com/article/18/7/evolution-package-managers

作者：Steve Ovens 选题：lujun9972 译者：DavidChenLiang 校对：wxy

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

台上某疑似“钢铁侠”正在宣讲“AI 监管”，遭到了群嘲——怒极之下，却暴露出了其原本是一个“AI”。

via: http://turnoff.us/geek/ai-regulation

作者：Daniel Stori 译者：wxy 合成：Bestony

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