最近我一直在研究 Kubernetes 网络。我注意到一件事情就是，虽然关于如何设置 Kubernetes 网络的文章很多，也写得很不错，但是却没有看到关于如何去运维 Kubernetes 网络的文章、以及如何完全确保它不会给你造成生产事故。

在本文中，我将尽力让你相信三件事情（我觉得这些都很合理 :)）：

• 避免生产系统网络中断非常重要
• 运维联网软件是很难的
• 有关你的网络基础设施的重要变化值得深思熟虑，以及这种变化对可靠性的影响。虽然非常“牛x”的谷歌人常说“这是我们在谷歌正在用的”（谷歌工程师在 Kubernetes 上正做着很重大的工作！但是我认为重要的仍然是研究架构，并确保它对你的组织有意义）。

我肯定不是 Kubernetes 网络方面的专家，但是我在配置 Kubernetes 网络时遇到了一些问题，并且比以前更加了解 Kubernetes 网络了。

运维联网软件是很难的

在这里，我并不讨论有关运维物理网络的话题（对于它我不懂），而是讨论关于如何让像 DNS 服务、负载均衡以及代理这样的软件正常工作方面的内容。

我在一个负责很多网络基础设施的团队工作过一年时间，并且因此学到了一些运维网络基础设施的知识！（显然我还有很多的知识需要继续学习）在我们开始之前有三个整体看法：

• 联网软件经常重度依赖 Linux 内核。因此除了正确配置软件之外，你还需要确保许多不同的系统控制（sysctl）配置正确，而一个错误配置的系统控制就很容易让你处于“一切都很好”和“到处都出问题”的差别中。
• 联网需求会随时间而发生变化（比如，你的 DNS 查询或许比上一年多了五倍！或者你的 DNS 服务器突然开始返回 TCP 协议的 DNS 响应而不是 UDP 的，它们是完全不同的内核负载！）。这意味着之前正常工作的软件突然开始出现问题。
• 修复一个生产网络的问题，你必须有足够的经验。（例如，看这篇 由 Sophie Haskins 写的关于 kube-dns 问题调试的文章）我在网络调试方面比以前进步多了，但那也是我花费了大量时间研究 Linux 网络知识之后的事了。

我距离成为一名网络运维专家还差得很远，但是我认为以下几点很重要：

1. 对生产网络的基础设施做重要的更改是很难得的（因为它会产生巨大的混乱）
2. 当你对网络基础设施做重大更改时，真的应该仔细考虑如果新网络基础设施失败该如何处理
3. 是否有很多人都能理解你的网络配置

切换到 Kubernetes 显然是个非常大的更改！因此，我们来讨论一下可能会导致错误的地方！

Kubernetes 网络组件

在本文中我们将要讨论的 Kubernetes 网络组件有：

• 覆盖网络 overlay network 的后端（像 flannel/calico/weave 网络/romana）
• kube-dns
• kube-proxy
• 入站控制器 / 负载均衡器
• kubelet

如果你打算配置 HTTP 服务，或许这些你都会用到。这些组件中的大部分我都不会用到，但是我尽可能去理解它们，因此，本文将涉及它们有关的内容。

最简化的方式：为所有容器使用宿主机网络

让我们从你能做到的最简单的东西开始。这并不能让你在 Kubernetes 中运行 HTTP 服务。我认为它是非常安全的，因为在这里面可以让你动的东西很少。

如果你为所有容器使用宿主机网络，我认为需要你去做的全部事情仅有：

1. 配置 kubelet，以便于容器内部正确配置 DNS
2. 没了，就这些！

如果你为每个 pod 直接使用宿主机网络，那就不需要 kube-dns 或者 kube-proxy 了。你都不需要一个作为基础的覆盖网络。

这种配置方式中，你的 pod 们都可以连接到外部网络（同样的方式，你的宿主机上的任何进程都可以与外部网络对话），但外部网络不能连接到你的 pod 们。

这并不是最重要的（我认为大多数人想在 Kubernetes 中运行 HTTP 服务并与这些服务进行真实的通讯），但我认为有趣的是，从某种程度上来说，网络的复杂性并不是绝对需要的，并且有时候你不用这么复杂的网络就可以实现你的需要。如果可以的话，尽可能地避免让网络过于复杂。

运维一个覆盖网络

我们将要讨论的第一个网络组件是有关覆盖网络的。Kubernetes 假设每个 pod 都有一个 IP 地址，这样你就可以与那个 pod 中的服务进行通讯了。我在说到“覆盖网络”这个词时，指的就是这个意思（“让你通过它的 IP 地址指向到 pod 的系统）。

所有其它的 Kubernetes 网络的东西都依赖正确工作的覆盖网络。更多关于它的内容，你可以读 这里的 kubernetes 网络模型。

Kelsey Hightower 在 kubernetes 艰难之路 中描述的方式看起来似乎很好，但是，事实上它的作法在超过 50 个节点的 AWS 上是行不通的，因此，我不打算讨论它了。

有许多覆盖网络后端（calico、flannel、weaveworks、romana）并且规划非常混乱。就我的观点来看，我认为一个覆盖网络有 2 个职责：

1. 确保你的 pod 能够发送网络请求到外部的集群
2. 保持一个到子网络的稳定的节点映射，并且保持集群中每个节点都可以使用那个映射得以更新。当添加和删除节点时，能够做出正确的反应。

Okay! 因此！你的覆盖网络可能会出现的问题是什么呢？

• 覆盖网络负责设置 iptables 规则（最基本的是 iptables -A -t nat POSTROUTING -s $SUBNET -j MASQUERADE），以确保那个容器能够向 Kubernetes 之外发出网络请求。如果在这个规则上有错误，你的容器就不能连接到外部网络。这并不很难（它只是几条 iptables 规则而已），但是它非常重要。我发起了一个 拉取请求，因为我想确保它有很好的弹性。
• 添加或者删除节点时可能会有错误。我们使用 flannel hostgw 后端，我们开始使用它的时候，节点删除功能 尚未开始工作。
• 你的覆盖网络或许依赖一个分布式数据库（etcd）。如果那个数据库发生什么问题，这将导致覆盖网络发生问题。例如，https://github.com/coreos/flannel/issues/610 上说，如果在你的 flannel etcd 集群上丢失了数据，最后的结果将是在容器中网络连接会丢失。（现在这个问题已经被修复了）
• 你升级 Docker 以及其它东西导致的崩溃
• 还有更多的其它的可能性！

我在这里主要讨论的是过去发生在 Flannel 中的问题，但是我并不是要承诺不去使用 Flannel —— 事实上我很喜欢 Flannel，因为我觉得它很简单（比如，类似 vxlan 在后端这一块的部分 只有 500 行代码），对我来说，通过代码来找出问题的根源成为了可能。并且很显然，它在不断地改进。他们在审查拉取请求方面做的很好。

到目前为止，我运维覆盖网络的方法是：

• 学习它的工作原理的详细内容以及如何去调试它（比如，Flannel 用于创建路由的 hostgw 网络后端，因此，你只需要使用 sudo ip route list 命令去查看它是否正确即可）
• 如果需要的话，维护一个内部构建版本，这样打补丁比较容易
• 有问题时，向上游贡献补丁

我认为去遍历所有已合并的拉取请求以及过去已修复的 bug 清单真的是非常有帮助的 —— 这需要花费一些时间，但这是得到一个其它人遇到的各种问题的清单的好方法。

对其他人来说，他们的覆盖网络可能工作的很好，但是我并不能从中得到任何经验，并且我也曾听说过其他人报告类似的问题。如果你有一个类似配置的覆盖网络：a) 在 AWS 上并且 b) 在多于 50-100 节点上运行，我想知道你运维这样的一个网络有多大的把握。

运维 kube-proxy 和 kube-dns？

现在，我有一些关于运维覆盖网络的想法，我们来讨论一下。

这个标题的最后面有一个问号，那是因为我并没有真的去运维过。在这里我还有更多的问题要问答。

这里的 Kubernetes 服务是如何工作的！一个服务是一群 pod 们，它们中的每个都有自己的 IP 地址（像 10.1.0.3、10.2.3.5、10.3.5.6 这样）

1. 每个 Kubernetes 服务有一个 IP 地址（像 10.23.1.2 这样）
2. kube-dns 去解析 Kubernetes 服务 DNS 名字为 IP 地址（因此，my-svc.my-namespace.svc.cluster.local 可能映射到 10.23.1.2 上）
3. kube-proxy 配置 iptables 规则是为了在它们之间随机进行均衡负载。Kube-proxy 也有一个用户空间的轮询负载均衡器，但是在我的印象中，他们并不推荐使用它。

因此，当你发出一个请求到 my-svc.my-namespace.svc.cluster.local 时，它将解析为 10.23.1.2，然后，在你本地主机上的 iptables 规则（由 kube-proxy 生成）将随机重定向到 10.1.0.3 或者 10.2.3.5 或者 10.3.5.6 中的一个上。

在这个过程中我能想像出的可能出问题的地方：

• kube-dns 配置错误
• kube-proxy 挂了，以致于你的 iptables 规则没有得以更新
• 维护大量的 iptables 规则相关的一些问题

我们来讨论一下 iptables 规则，因为创建大量的 iptables 规则是我以前从没有听过的事情！

kube-proxy 像如下这样为每个目标主机创建一个 iptables 规则：这些规则来自 这里）

-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.20000000019 -j KUBE-SEP-E4QKA7SLJRFZZ2DD[b][c]  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-LZ7EGMG4DRXMY26H  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-RKIFTWKKG3OHTTMI  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CGDKBCNM24SZWCMS 
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -j KUBE-SEP-RI4SRNQQXWSTGE2Y 

因此，kube-proxy 创建了许多 iptables 规则。它们都是什么意思？它对我的网络有什么样的影响？这里有一个来自华为的非常好的演讲，它叫做 支持 50,000 个服务的可伸缩 Kubernetes，它说如果在你的 Kubernetes 集群中有 5,000 服务，增加一个新规则，将需要 11 分钟。如果这种事情发生在真实的集群中，我认为这将是一件非常糟糕的事情。

在我的集群中肯定不会有 5,000 个服务，但是 5,000 并不是那么大的一个数字。为解决这个问题，他们给出的解决方案是 kube-proxy 用 IPVS 来替换这个 iptables 后端，IPVS 是存在于 Linux 内核中的一个负载均衡器。

看起来，像 kube-proxy 正趋向于使用各种基于 Linux 内核的负载均衡器。我认为这只是一定程度上是这样，因为他们支持 UDP 负载均衡，而其它类型的负载均衡器（像 HAProxy）并不支持 UDP 负载均衡。

但是，我觉得使用 HAProxy 更舒服！它能够用于去替换 kube-proxy！我用谷歌搜索了一下，然后发现了这个 thread on kubernetes-sig-network，它说：

kube-proxy 是很难用的，我们在生产系统中使用它近一年了，它在大部分的时间都表现的很好，但是，随着我们集群中的服务越来越多，我们发现它的排错和维护工作越来越难。在我们的团队中没有 iptables 方面的专家，我们只有 HAProxy & LVS 方面的专家，由于我们已经使用它们好几年了，因此我们决定使用一个中心化的 HAProxy 去替换分布式的代理。我觉得这可能会对在 Kubernetes 中使用 HAProxy 的其他人有用，因此，我们更新了这个项目，并将它开源：https://github.com/AdoHe/kube2haproxy。如果你发现它有用，你可以去看一看、试一试。

因此，那是一个有趣的选择！我在这里确实没有答案，但是，有一些想法：

• 负载均衡器是很复杂的
• DNS 也很复杂
• 如果你有运维某种类型的负载均衡器（比如 HAProxy）的经验，与其使用一个全新的负载均衡器（比如 kube-proxy），还不如做一些额外的工作去使用你熟悉的那个来替换，或许更有意义。
• 我一直在考虑，我们希望在什么地方能够完全使用 kube-proxy 或者 kube-dns —— 我认为，最好是只在 Envoy 上投入，并且在负载均衡&服务发现上完全依赖 Envoy 来做。因此，你只需要将 Envoy 运维好就可以了。

正如你所看到的，我在关于如何运维 Kubernetes 中的内部代理方面的思路还是很混乱的，并且我也没有使用它们的太多经验。总体上来说，kube-proxy 和 kube-dns 还是很好的，也能够很好地工作，但是我仍然认为应该去考虑使用它们可能产生的一些问题（例如，”你不能有超出 5000 的 Kubernetes 服务“）。

入口

如果你正在运行着一个 Kubernetes 集群，那么到目前为止，很有可能的是，你事实上需要 HTTP 请求去进入到你的集群中。这篇博客已经太长了，并且关于入口我知道的也不多，因此，我们将不讨论关于入口的内容。

有用的链接

几个有用的链接，总结如下：

• Kubernetes 网络模型
• GKE 网络是如何工作的：https://www.youtube.com/watch?v=y2bhV81MfKQ
• 上述的有关 kube-proxy 上性能的讨论：https://www.youtube.com/watch?v=4-pawkiazEg

我认为网络运维很重要

我对 Kubernetes 的所有这些联网软件的感觉是，它们都仍然是非常新的，并且我并不能确定我们（作为一个社区）真的知道如何去把它们运维好。这让我作为一个操作者感到很焦虑，因为我真的想让我的网络运行的很好！:) 而且我觉得作为一个组织，运行你自己的 Kubernetes 集群需要相当大的投入，以确保你理解所有的代码片段，这样当它们出现问题时你可以去修复它们。这不是一件坏事，它只是一个事而已。

我现在的计划是，继续不断地学习关于它们都是如何工作的，以尽可能多地减少对我动过的那些部分的担忧。

一如继往，我希望这篇文章对你有帮助，并且如果我在这篇文章中有任何的错误，我非常喜欢你告诉我。

via: https://jvns.ca/blog/2017/10/10/operating-a-kubernetes-network/

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

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

通常，Ubuntu 和其他 Linux 中的默认软件中心会处理系统固件的更新。但是如果你遇到了错误，你可以使用 fwupd 命令行工具更新系统的固件。

我使用 Dell XPS 13 Ubuntu 版本作为我的主要操作系统。我全新安装了 Ubuntu 18.04，我对硬件兼容性感到满意。蓝牙、外置 USB 耳机和扬声器、多显示器，一切都开箱即用。

困扰我的一件事是软件中心出现的一个固件更新。

单击“更新”按钮会在几秒钟后出现错误。

错误消息是：

Unable to update “Thunderbolt NVM for Xps Notebook 9360”: could not detect device after update: timed out while waiting for device

在这篇文章中，我将向你展示如何在 Ubuntu 中更新系统固件。

在 Ubuntu 18.04 中更新固件

有一件事你应该知道 GNOME Software（即 Ubuntu 18.04 中的软件中心）也能够更新固件。但是在由于某种原因失败的情况下，你可以使用命令行工具 fwupd。

fwupd 是一个开源守护进程，可以处理基于 Linux 的系统中的固件升级。它由 GNOME 开发人员 Richard Hughes 创建。戴尔的开发人员也为这一开源工具的开发做出了贡献。

基本上，它使用 LVFS —— Linux 供应商固件服务 Linux Vendor Firmware Service 。硬件供应商将可再发行固件上传到 LVFS 站点，并且多亏 fwupd，你可以从操作系统内部升级这些固件。fwupd 得到了 Ubuntu 和 Fedora 等主要 Linux 发行版的支持。

首先打开终端并更新系统：

sudo apt update && sudo apt upgrade -y

之后，你可以逐个使用以下命令来启动守护程序，刷新可用固件更新列表并安装固件更新。

sudo service fwupd start

守护进程运行后，检查是否有可用的固件更新。

sudo fwupdmgr refresh

输出应如下所示：

Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading…                         [****************************]
Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc

在此之后，运行固件更新：

sudo fwupdmgr update

固件更新的输出可能与此类似：

No upgrades for XPS 13 9360 TPM 2.0, current is 1.3.1.0: 1.3.1.0=same
No upgrades for XPS 13 9360 System Firmware, current is 0.2.8.1: 0.2.8.1=same, 0.2.7.1=older, 0.2.6.2=older, 0.2.5.1=older, 0.2.4.2=older, 0.2.3.1=older, 0.2.2.1=older, 0.2.1.0=older, 0.1.3.7=older, 0.1.3.5=older, 0.1.3.2=older, 0.1.2.3=older
Downloading 21.00 for XPS13 9360 Thunderbolt Controller…
Updating 21.00 on XPS13 9360 Thunderbolt Controller…
Decompressing…    [***********]
Authenticating…      [***********] 
Restarting device… [***********]

这应该处理了在 Ubuntu 18.04 中的固件更新。我希望这篇文章可以帮助你在 Linux 中进行固件更新。

如果你有任何问题或建议，请在下面的评论栏留言。

via: https://itsfoss.com/update-firmware-ubuntu/

作者：Abhishek Prakash 选题：lujun9972 译者：geekpi 校对：wxy

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

用这个方便的工具来更有效的运行和编译你的程序。

当你需要在一些源文件改变后运行或更新一个任务时，通常会用到 make 工具。make 工具需要读取一个 Makefile（或 makefile）文件，在该文件中定义了一系列需要执行的任务。你可以使用 make 来将源代码编译为可执行程序。大部分开源项目会使用 make 来实现最终的二进制文件的编译，然后使用 make install 命令来执行安装。

本文将通过一些基础和进阶的示例来展示 make 和 Makefile 的使用方法。在开始前，请确保你的系统中安装了 make。

基础示例

依然从打印 “Hello World” 开始。首先创建一个名字为 myproject 的目录，目录下新建 Makefile 文件，文件内容为：

say_hello:
        echo "Hello World"

在 myproject 目录下执行 make，会有如下输出：

$ make
echo "Hello World"
Hello World

在上面的例子中，“say\_hello” 类似于其他编程语言中的函数名。这被称之为 目标 target 。在该目标之后的是预置条件或依赖。为了简单起见，我们在这个示例中没有定义预置条件。echo ‘Hello World' 命令被称为 步骤 recipe 。这些步骤基于预置条件来实现目标。目标、预置条件和步骤共同构成一个规则。

总结一下，一个典型的规则的语法为：

目标: 预置条件
<TAB> 步骤

作为示例，目标可以是一个基于预置条件（源代码）的二进制文件。另一方面，预置条件也可以是依赖其他预置条件的目标。

final_target: sub_target final_target.c
        Recipe_to_create_final_target
        
sub_target: sub_target.c
        Recipe_to_create_sub_target

目标并不要求是一个文件，也可以只是步骤的名字，就如我们的例子中一样。我们称之为“伪目标”。

再回到上面的示例中，当 make 被执行时，整条指令 echo "Hello World" 都被显示出来，之后才是真正的执行结果。如果不希望指令本身被打印处理，需要在 echo 前添加 @。

say_hello:
        @echo "Hello World"

重新运行 make，将会只有如下输出：

$ make
Hello World

接下来在 Makefile 中添加如下伪目标：generate 和 clean：

say_hello:
        @echo "Hello World"

generate:
        @echo "Creating empty text files..."
        touch file-{1..10}.txt

clean:
        @echo "Cleaning up..."
        rm *.txt

随后当我们运行 make 时，只有 say_hello 这个目标被执行。这是因为Makefile 中的第一个目标为默认目标。通常情况下会调用默认目标，这就是你在大多数项目中看到 all 作为第一个目标而出现。all 负责来调用它他的目标。我们可以通过 .DEFAULT_GOAL 这个特殊的伪目标来覆盖掉默认的行为。

在 Makefile 文件开头增加 .DEFAULT_GOAL：

.DEFAULT_GOAL := generate

make 会将 generate 作为默认目标：

$ make
Creating empty text files...
touch file-{1..10}.txt

顾名思义，.DEFAULT_GOAL 伪目标仅能定义一个目标。这就是为什么很多 Makefile 会包括 all 这个目标，这样可以调用多个目标。

下面删除掉 .DEFAULT_GOAL，增加 all 目标：

all: say_hello generate

say_hello:
        @echo "Hello World"

generate:
        @echo "Creating empty text files..."
        touch file-{1..10}.txt

clean:
        @echo "Cleaning up..."
        rm *.txt

运行之前，我们再增加一些特殊的伪目标。.PHONY 用来定义这些不是文件的目标。make 会默认调用这些伪目标下的步骤，而不去检查文件名是否存在或最后修改日期。完整的 Makefile 如下：

.PHONY: all say_hello generate clean

all: say_hello generate

say_hello:
        @echo "Hello World"

generate:
        @echo "Creating empty text files..."
        touch file-{1..10}.txt

clean:
        @echo "Cleaning up..."
        rm *.txt

make 命令会调用 say_hello 和 generate：

$ make
Hello World
Creating empty text files...
touch file-{1..10}.txt

clean 不应该被放入 all 中，或者被放入第一个目标中。clean 应当在需要清理时手动调用，调用方法为 make clean。

$ make clean
Cleaning up...
rm *.txt

现在你应该已经对 Makefile 有了基础的了解，接下来我们看一些进阶的示例。

进阶示例

变量

在之前的实例中，大部分目标和预置条件是已经固定了的，但在实际项目中，它们通常用变量和模式来代替。

定义变量最简单的方式是使用 = 操作符。例如，将命令 gcc 赋值给变量 CC：

CC = gcc

这被称为递归扩展变量，用于如下所示的规则中：

hello: hello.c
    ${CC} hello.c -o hello

你可能已经想到了，这些步骤将会在传递给终端时展开为：

gcc hello.c -o hello

${CC} 和 $(CC) 都能对 gcc 进行引用。但如果一个变量尝试将它本身赋值给自己，将会造成死循环。让我们验证一下：

CC = gcc
CC = ${CC}

all:
    @echo ${CC}

此时运行 make 会导致：

$ make
Makefile:8: *** Recursive variable 'CC' references itself (eventually).  Stop.

为了避免这种情况发生，可以使用 := 操作符（这被称为简单扩展变量）。以下代码不会造成上述问题：

CC := gcc
CC := ${CC}

all:
    @echo ${CC}

模式和函数

下面的 Makefile 使用了变量、模式和函数来实现所有 C 代码的编译。我们来逐行分析下：

# Usage:
# make        # compile all binary
# make clean  # remove ALL binaries and objects

.PHONY = all clean

CC = gcc                        # compiler to use

LINKERFLAG = -lm

SRCS := $(wildcard *.c)
BINS := $(SRCS:%.c=%)

all: ${BINS}

%: %.o
        @echo "Checking.."
        ${CC} ${LINKERFLAG} $< -o $@

%.o: %.c
        @echo "Creating object.."
        ${CC} -c $<

clean:
        @echo "Cleaning up..."
        rm -rvf *.o ${BINS}

• 以 # 开头的行是评论。
• .PHONY = all clean 行定义了 all 和 clean 两个伪目标。
• 变量 LINKERFLAG 定义了在步骤中 gcc 命令需要用到的参数。
• SRCS := $(wildcard *.c)：$(wildcard pattern) 是与文件名相关的一个函数。在本示例中，所有 “.c”后缀的文件会被存入 SRCS 变量。
• BINS := $(SRCS:%.c=%)：这被称为替代引用。本例中，如果 SRCS 的值为 'foo.c bar.c'，则 BINS的值为 'foo bar'。
• all: ${BINS} 行：伪目标 all 调用 ${BINS} 变量中的所有值作为子目标。
• 规则：

%: %.o
  @echo "Checking.."
  ${CC} ${LINKERFLAG} $< -o $@

下面通过一个示例来理解这条规则。假定 foo 是变量 ${BINS} 中的一个值。% 会匹配到 foo（%匹配任意一个目标）。下面是规则展开后的内容：

foo: foo.o
  @echo "Checking.."
  gcc -lm foo.o -o foo

如上所示，% 被 foo 替换掉了。$< 被 foo.o 替换掉。$<用于匹配预置条件，$@ 匹配目标。对 ${BINS} 中的每个值，这条规则都会被调用一遍。

• 规则：

%.o: %.c
  @echo "Creating object.."
  ${CC} -c $<

之前规则中的每个预置条件在这条规则中都会都被作为一个目标。下面是展开后的内容：

foo.o: foo.c
  @echo "Creating object.."
  gcc -c foo.c

• 最后，在 clean 目标中，所有的二进制文件和编译文件将被删除。

下面是重写后的 Makefile，该文件应该被放置在一个有 foo.c 文件的目录下：

# Usage:
# make        # compile all binary
# make clean  # remove ALL binaries and objects

.PHONY = all clean

CC = gcc                        # compiler to use

LINKERFLAG = -lm

SRCS := foo.c
BINS := foo

all: foo

foo: foo.o
        @echo "Checking.."
        gcc -lm foo.o -o foo

foo.o: foo.c
        @echo "Creating object.."
        gcc -c foo.c

clean:
        @echo "Cleaning up..."
        rm -rvf foo.o foo

关于 Makefile 的更多信息，GNU Make 手册提供了更完整的说明和实例。

via: https://opensource.com/article/18/8/what-how-makefile

作者：Sachin Patil 选题：lujun9972 译者：Zafiry 校对：wxy

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

了解 ext4 的历史，包括其与 ext3 和之前的其它文件系统之间的区别。

目前的大部分 Linux 文件系统都默认采用 ext4 文件系统，正如以前的 Linux 发行版默认使用 ext3、ext2 以及更久前的 ext。

对于不熟悉 Linux 或文件系统的朋友而言，你可能不清楚 ext4 相对于上一版本 ext3 带来了什么变化。你可能还想知道在一连串关于替代的文件系统例如 Btrfs、XFS 和 ZFS 不断被发布的情况下，ext4 是否仍然能得到进一步的发展。

在一篇文章中，我们不可能讲述文件系统的所有方面，但我们尝试让你尽快了解 Linux 默认文件系统的发展历史，包括它的诞生以及未来发展。

我仔细研究了维基百科里的各种关于 ext 文件系统文章、kernel.org 的 wiki 中关于 ext4 的条目以及结合自己的经验写下这篇文章。

ext 简史

MINIX 文件系统

在有 ext 之前，使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史，那么可以理解为 MINIX 是用于 IBM PC/AT 微型计算机的一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它，并于 1987 年发布了源代码（以印刷版的格式！）。

IBM 1980 中期的 PC/AT，MBlairMartin，CC BY-SA 4.0

虽然你可以细读 MINIX 的源代码，但实际上它并不是自由开源软件（FOSS）。出版 Tannebaum 著作的出版商要求你花 69 美元的许可费来运行 MINIX，而这笔费用包含在书籍的费用中。尽管如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 的安装在世界各个大学里面非常流行。而此时，年轻的 Linus Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布，而后在 1992 年 12 月在 GPL 开源协议下发布。

但是等等，这是一篇以 文件系统 为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。跟 MINIX 一样，Linux 的文件系统也如同玩具那般小 —— MINIX 文件系统最多能处理 14 个字符的文件名，并且只能处理 64MB 的存储空间。到了 1991 年，一般的硬盘尺寸已经达到了 40-140 MB。很显然，Linux 需要一个更好的文件系统。

ext

当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 从事第一代的 ext 文件系统的开发工作。ext 文件系统在 1992 年首次实现并发布 —— 仅在 Linux 首次发布后的一年！—— ext 解决了 MINIX 文件系统中最糟糕的问题。

1992 年的 ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2 GB 存储空间并处理 255 个字符的文件名。

但 ext 并没有长时间占统治地位，主要是由于它原始的时间戳（每个文件仅有一个时间戳，而不是今天我们所熟悉的有 inode、最近文件访问时间和最新文件修改时间的时间戳。）仅仅一年后，ext2 就替代了它。

ext2

Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。当 ext 仍然根植于 “玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。

ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOS 和 Windows。

但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。

尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 —— 最常见的是，作为便携式 USB 驱动器的文件系统格式。

ext3

1998 年，在 ext2 被采用后的 6 年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月在 2.4.15 内核版本中被采用到 Linux 内核主线中。

20 世纪 90 年代中期的 Packard Bell 计算机，Spacekid，CC0

在大部分情况下，ext2 在 Linux 发行版中工作得很好，但像 FAT、FAT32、HFS 和当时的其它文件系统一样 —— 在断电时容易发生灾难性的破坏。如果在将数据写入文件系统时候发生断电，则可能会将其留在所谓 不一致 的状态 —— 事情只完成一半而另一半未完成。这可能导致大量文件丢失或损坏，这些文件与正在保存的文件无关甚至导致整个文件系统无法卸载。

ext3 和 20 世纪 90 年代后期的其它文件系统，如微软的 NTFS，使用 日志 来解决这个问题。日志是磁盘上的一种特殊的分配区域，其写入被存储在事务中；如果该事务完成磁盘写入，则日志中的数据将提交给文件系统自身。如果系统在该操作提交前崩溃，则重新启动的系统识别其为未完成的事务而将其进行回滚，就像从未发生过一样。这意味着正在处理的文件可能依然会丢失，但文件系统 本身 保持一致，且其它所有数据都是安全的。

在使用 ext3 文件系统的 Linux 内核中实现了三个级别的日志记录方式： 日记 journal 、 顺序 ordered 和 回写 writeback 。

• 日记 是最低风险模式，在将数据和元数据提交给文件系统之前将其写入日志。这可以保证正在写入的文件与整个文件系统的一致性，但其显著降低了性能。
• 顺序 是大多数 Linux 发行版默认模式；顺序模式将元数据写入日志而直接将数据提交到文件系统。顾名思义，这里的操作顺序是固定的：首先，元数据提交到日志；其次，数据写入文件系统，然后才将日志中关联的元数据更新到文件系统。这确保了在发生崩溃时，那些与未完整写入相关联的元数据仍在日志中，且文件系统可以在回滚日志时清理那些不完整的写入事务。在顺序模式下，系统崩溃可能导致在崩溃期间文件的错误被主动写入，但文件系统它本身 —— 以及未被主动写入的文件 —— 确保是安全的。
• 回写 是第三种模式 —— 也是最不安全的日志模式。在回写模式下，像顺序模式一样，元数据会被记录到日志，但数据不会。与顺序模式不同，元数据和数据都可以以任何有利于获得最佳性能的顺序写入。这可以显著提高性能，但安全性低很多。尽管回写模式仍然保证文件系统本身的安全性，但在崩溃或崩溃之前写入的文件很容易丢失或损坏。

跟之前的 ext2 类似，ext3 使用 16 位内部寻址。这意味着对于有着 4K 块大小的 ext3 在最大规格为 16 TiB 的文件系统中可以处理的最大文件大小为 2 TiB。

ext4

Theodore Ts'o（是当时 ext3 主要开发人员）在 2006 年发表的 ext4，于两年后在 2.6.28 内核版本中被加入到了 Linux 主线。

Ts'o 将 ext4 描述为一个显著扩展 ext3 但仍然依赖于旧技术的临时技术。他预计 ext4 终将会被真正的下一代文件系统所取代。

Dell Precision 380 工作站，Lance Fisher，CC BY-SA 2.0

ext4 在功能上与 ext3 在功能上非常相似，但支持大文件系统，提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。

ext4 vs ext3

ext3 和 ext4 有一些非常明确的差别，在这里集中讨论下。

向后兼容性

ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件系统原地升级到 ext4；也允许 ext4 驱动程序以 ext3 模式自动挂载 ext3 文件系统，因此使它无需单独维护两个代码库。

大文件系统

ext3 文件系统使用 32 位寻址，这限制它仅支持 2 TiB 文件大小和 16 TiB 文件系统系统大小（这是假设在块大小为 4 KiB 的情况下，一些 ext3 文件系统使用更小的块大小，因此对其进一步被限制）。

ext4 使用 48 位的内部寻址，理论上可以在文件系统上分配高达 16 TiB 大小的文件，其中文件系统大小最高可达 1000000 TiB（1 EiB）。在早期 ext4 的实现中有些用户空间的程序仍然将其限制为最大大小为 16 TiB 的文件系统，但截至 2011 年，e2fsprogs 已经直接支持大于 16 TiB 大小的 ext4 文件系统。例如，红帽企业 Linux 在其合同上仅支持最高 50 TiB 的 ext4 文件系统，并建议 ext4 卷不超过 100 TiB。

分配方式改进

ext4 在将存储块写入磁盘之前对存储块的分配方式进行了大量改进，这可以显著提高读写性能。

区段

区段 extent 是一系列连续的物理块 (最多达 128 MiB，假设块大小为 4 KiB），可以一次性保留和寻址。使用区段可以减少给定文件所需的 inode 数量，并显著减少碎片并提高写入大文件时的性能。

多块分配

ext3 为每一个新分配的块调用一次块分配器。当多个写入同时打开分配器时，很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。

持久的预分配

在为文件预分配磁盘空间时，大部分文件系统必须在创建时将零写入该文件的块中。ext4 允许替代使用 fallocate()，它保证了空间的可用性（并试图为它找到连续的空间），而不需要先写入它。这显著提高了写入和将来读取流和数据库应用程序的写入数据的性能。

延迟分配

这是一个耐人寻味而有争议性的功能。延迟分配允许 ext4 等待分配将写入数据的实际块，直到它准备好将数据提交到磁盘。（相比之下，即使数据仍然在往写入缓存中写入，ext3 也会立即分配块。）

当缓存中的数据累积时，延迟分配块允许文件系统对如何分配块做出更好的选择，降低碎片（写入，以及稍后的读）并显著提升性能。然而不幸的是，它 增加 了还没有专门调用 fsync() 方法（当程序员想确保数据完全刷新到磁盘时）的程序的数据丢失的可能性。

假设一个程序完全重写了一个文件：

fd=open("file", O_TRUNC); write(fd, data); close(fd);

使用旧的文件系统，close(fd); 足以保证 file 中的内容刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。

如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和较新版本都可能丢失数据或损坏。如果其它进程在写入文件时访问文件，则会看到损坏的版本。如果其它进程打开文件并且不希望其内容发生更改 —— 例如，映射到多个正在运行的程序的共享库。这些进程可能会崩溃。

为了避免这些问题，一些程序员完全避免使用 O_TRUNC。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件名：

fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");

在 没有 延迟分配的文件系统下，这足以避免上面列出的潜在的损坏和崩溃问题：因为 rename() 是原子操作，所以它不会被崩溃中断；并且运行的程序将继续引用旧的文件。现在 file 的未链接版本只要有一个打开的文件文件句柄即可。但是因为 ext4 的延迟分配会导致写入被延迟和重新排序，rename("newfile", "file") 可以在 newfile 的内容实际写入磁盘内容之前执行，这出现了并行进行再次获得 file 坏版本的问题。

为了缓解这种情况，Linux 内核（自版本 2.6.30）尝试检测这些常见代码情况并强制立即分配。这会减少但不能防止数据丢失的可能性 —— 并且它对新文件没有任何帮助。如果你是一位开发人员，请注意：保证数据立即写入磁盘的唯一方法是正确调用 fsync()。

无限制的子目录

ext3 仅限于 32000 个子目录；ext4 允许无限数量的子目录。从 2.6.23 内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。

日志校验

ext3 没有对日志进行校验，这给处于内核直接控制之外的磁盘或自带缓存的控制器设备带来了问题。如果控制器或具自带缓存的磁盘脱离了写入顺序，则可能会破坏 ext3 的日记事务顺序，从而可能破坏在崩溃期间（或之前一段时间）写入的文件。

理论上，这个问题可以使用写入 障碍 barrier —— 在安装文件系统时，你在挂载选项设置 barrier=1，然后设备就会忠实地执行 fsync 一直向下到底层硬件。通过实践，可以发现存储设备和控制器经常不遵守写入障碍 —— 提高性能（和跟竞争对手比较的性能基准），但增加了本应该防止数据损坏的可能性。

对日志进行校验和允许文件系统崩溃后第一次挂载时意识到其某些条目是无效或无序的。因此，这避免了回滚部分条目或无序日志条目的错误，并进一步损坏的文件系统 —— 即使部分存储设备假做或不遵守写入障碍。

快速文件系统检查

在 ext3 下，在 fsck 被调用时会检查整个文件系统 —— 包括已删除或空文件。相比之下，ext4 标记了 inode 表未分配的块和扇区，从而允许 fsck 完全跳过它们。这大大减少了在大多数文件系统上运行 fsck 的时间，它实现于内核 2.6.24。

改进的时间戳

ext3 提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。ext4 通过提供纳秒级的时间戳，使其可用于那些企业、科学以及任务关键型的应用程序。

ext3 文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。ext4 在这里增加了两个位，将 Unix 纪元扩展了 408 年。如果你在公元 2446 年读到这篇文章，你很有可能已经转移到一个更好的文件系统 —— 如果你还在测量自 1970 年 1 月 1 日 00:00（UTC）以来的时间，这会让我死后得以安眠。

在线碎片整理

ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。ext2 有一个包含的实用程序 e2defrag，它的名字暗示 —— 它需要在文件系统未挂载时脱机运行。（显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 —— 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 e2defrag 可能会导致灾难性损坏和数据丢失。

尽管 ext3 最初被认为“不受碎片影响”，但对同一文件（例如 BitTorrent）采用大规模并行写入过程的过程清楚地表明情况并非完全如此。一些用户空间的手段和解决方法，例如 Shake，以这样或那样方式解决了这个问题 —— 但它们比真正的、文件系统感知的、内核级碎片整理过程更慢并且在各方面都不太令人满意。

ext4 通过 e4defrag 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和区段级别的碎片整理实用程序。

正在进行的 ext4 开发

ext4，正如 Monty Python 中瘟疫感染者曾经说过的那样，“我还没死呢！”虽然它的主要开发人员认为它只是一个真正的下一代文件系统的权宜之计，但是在一段时间内，没有任何可能的候选人准备好（由于技术或许可问题）部署为根文件系统。

在未来的 ext4 版本中仍然有一些关键功能要开发，包括元数据校验和、一流的配额支持和大分配块。

元数据校验和

由于 ext4 具有冗余超级块，因此为文件系统校验其中的元数据提供了一种方法，可以自行确定主超级块是否已损坏并需要使用备用块。可以在没有校验和的情况下，从损坏的超级块恢复 —— 但是用户首先需要意识到它已损坏，然后尝试使用备用方法手动挂载文件系统。由于在某些情况下，使用损坏的主超级块安装文件系统读写可能会造成进一步的损坏，即使是经验丰富的用户也无法避免，这也不是一个完美的解决方案！

与 Btrfs 或 ZFS 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和的功能非常弱。但它总比没有好。虽然校验 所有的事情 都听起来很简单！—— 事实上，将校验和与文件系统连接到一起有一些重大的挑战；请参阅设计文档了解详细信息。

一流的配额支持

等等，配额？！从 ext2 出现的那天开始我们就有了这些！是的，但它们一直都是事后的添加的东西，而且它们总是犯傻。这里可能不值得详细介绍，但设计文档列出了配额将从用户空间移动到内核中的方式，并且能够更加正确和高效地执行。

大分配块

随着时间的推移，那些讨厌的存储系统不断变得越来越大。由于一些固态硬盘已经使用 8K 硬件块大小，因此 ext4 对 4K 模块的当前限制越来越受到限制。较大的存储块可以显著减少碎片并提高性能，代价是增加“松弛”空间（当你只需要块的一部分来存储文件或文件的最后一块时留下的空间）。

你可以在设计文档中查看详细说明。

ext4 的实际限制

ext4 是一个健壮、稳定的文件系统。如今大多数人都应该在用它作为根文件系统，但它无法处理所有需求。让我们简单地谈谈你不应该期待的一些事情 —— 现在或可能在未来：

虽然 ext4 可以处理高达 1 EiB 大小（相当于 1,000,000 TiB）大小的数据，但你 真的 不应该尝试这样做。除了能够记住更多块的地址之外，还存在规模上的问题。并且现在 ext4 不会处理（并且可能永远不会）超过 50-100 TiB 的数据。

ext4 也不足以保证数据的完整性。随着日志记录的重大进展又回到了 ext3 的那个时候，它并未涵盖数据损坏的许多常见原因。如果数据已经在磁盘上被破坏 —— 由于故障硬件，宇宙射线的影响（是的，真的），或者只是数据随时间衰减 —— ext4 无法检测或修复这种损坏。

基于上面两点，ext4 只是一个纯 文件系统，而不是存储卷管理器。这意味着，即使你有多个磁盘 —— 也就是奇偶校验或冗余，理论上你可以从 ext4 中恢复损坏的数据，但无法知道使用它是否对你有利。虽然理论上可以在不同的层中分离文件系统和存储卷管理系统而不会丢失自动损坏检测和修复功能，但这不是当前存储系统的设计方式，并且它将给新设计带来重大挑战。

备用文件系统

在我们开始之前，提醒一句：要非常小心，没有任何备用的文件系统作为主线内核的一部分而内置和直接支持！

即使一个文件系统是 安全的，如果在内核升级期间出现问题，使用它作为根文件系统也是非常可怕的。如果你没有充分的理由通过一个 chroot 去使用替代介质引导，耐心地操作内核模块、grub 配置和 DKMS……不要在一个很重要的系统中去掉预留的根文件。

可能有充分的理由使用你的发行版不直接支持的文件系统 —— 但如果你这样做，我强烈建议你在系统启动并可用后再安装它。（例如，你可能有一个 ext4 根文件系统，但是将大部分数据存储在 ZFS 或 Btrfs 池中。）

XFS

XFS 与非 ext 文件系统在 Linux 中的主线中的地位一样。它是一个 64 位的日志文件系统，自 2001 年以来内置于 Linux 内核中，为大型文件系统和高度并发性提供了高性能（即大量的进程都会立即写入文件系统）。

从 RHEL 7 开始，XFS 成为 Red Hat Enterprise Linux 的默认文件系统。对于家庭或小型企业用户来说，它仍然有一些缺点 —— 最值得注意的是，重新调整现有 XFS 文件系统是一件非常痛苦的事情，不如创建另一个并复制数据更有意义。

虽然 XFS 是稳定的且是高性能的，但它和 ext4 之间没有足够具体的最终用途差异，以值得推荐在非默认（如 RHEL7）的任何地方使用它，除非它解决了对 ext4 的特定问题，例如大于 50 TiB 容量的文件系统。

XFS 在任何方面都不是 ZFS、Btrfs 甚至 WAFL（一个专有的 SAN 文件系统）的“下一代”文件系统。就像 ext4 一样，它应该被视为一种更好的方式的权宜之计。

ZFS

ZFS 由 Sun Microsystems 开发，以 zettabyte 命名 —— 相当于 1 万亿 GB —— 因为它理论上可以解决大型存储系统。

作为真正的下一代文件系统，ZFS 提供卷管理（能够在单个文件系统中处理多个单独的存储设备），块级加密校验和（允许以极高的准确率检测数据损坏），自动损坏修复（其中冗余或奇偶校验存储可用），快速异步增量复制，内联压缩等，以及更多。

从 Linux 用户的角度来看，ZFS 的最大问题是许可证问题。ZFS 许可证是 CDDL 许可证，这是一种与 GPL 冲突的半许可的许可证。关于在 Linux 内核中使用 ZFS 的意义存在很多争议，其争议范围从“它是 GPL 违规”到“它是 CDDL 违规”到“它完全没问题，它还没有在法庭上进行过测试。”最值得注意的是，自 2016 年以来 Canonical 已将 ZFS 代码内联在其默认内核中，而且目前尚无法律挑战。

此时，即使我作为一个非常狂热于 ZFS 的用户，我也不建议将 ZFS 作为 Linux 的根文件系统。如果你想在 Linux 上利用 ZFS 的优势，用 ext4 设置一个小的根文件系统，然后将 ZFS 用在你剩余的存储上，把数据、应用程序以及你喜欢的东西放在它上面 —— 但把 root 分区保留在 ext4 上，直到你的发行版明确支持 ZFS 根目录。

Btrfs

Btrfs 是 B-Tree Filesystem 的简称，通常发音为 “butter” —— 由 Chris Mason 于 2007 年在 Oracle 任职期间发布。Btrfs 旨在跟 ZFS 有大部分相同的目标，提供多种设备管理、每块校验、异步复制、直列压缩等，还有更多。

截至 2018 年，Btrfs 相当稳定，可用作标准的单磁盘文件系统，但可能不应该依赖于卷管理器。与许多常见用例中的 ext4、XFS 或 ZFS 相比，它存在严重的性能问题，其下一代功能 —— 复制、多磁盘拓扑和快照管理 —— 可能非常多，其结果可能是从灾难性地性能降低到实际数据的丢失。

Btrfs 的维持状态是有争议的；SUSE Enterprise Linux 在 2015 年采用它作为默认文件系统，而 Red Hat 于 2017 年宣布它从 RHEL 7.4 开始不再支持 Btrfs。可能值得注意的是，该产品支持 Btrfs 部署用作单磁盘文件系统，而不是像 ZFS 中的多磁盘卷管理器，甚至 Synology 在它的存储设备使用 Btrfs，但是它在传统 Linux 内核 RAID（mdraid）之上分层来管理磁盘。

via: https://opensource.com/article/18/4/ext4-filesystem

作者：Jim Salter 译者：HardworkFish 校对：wxy, pityonline

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

我是老王，可能大家有不少人知道我，由于历史原因，我有好几个生日（;o），但是这些年来，我又多了一个生日，或者说纪念日——每过两年，我就要严肃认真地写一篇 LCTT 生日纪念文章。

喏，这一篇，就是今年的了，LCTT 如今已经五岁了！

或许如同小孩子过生日总是比较快乐，而随着年岁渐长，过生日往往有不少负担——比如说，每次写这篇纪念文章时，我就需要回忆、反思这两年的做了些什么，往往颇为汗颜。

不过不管怎么说，总要总结一下这两年我们做了什么，有什么不足，也发一些展望吧。

江山代有英豪出

LCTT，如同一般的开源贡献组织，总是有不断的新老传承。我们的翻译组，也有不少成员，由于工作学习的原因，慢慢淡出，但同时，也不断有新的成员加入并接过前辈手中的旗帜（就是没人接我的）。

加入方式

请首先加入翻译组的 QQ 群，群号是：198889102，加群时请说明是“志愿者”。加入后记得修改您的群名片为您的 GitHub 的 ID。

加入的成员，请先阅读 WIKI 如何开始。

比如说，我们这两年来，oska874 承担了主要的选题工作，然后 lujun9972 适时的出现接过了不少选题工作；再比如说，qhwdw 出现后承担了大量繁难文章的翻译，pityonline 则专注于校对，甚至其校对的严谨程度让我都甘拜下风。还有 MjSeven 也同 qhwdw 一样，以极高的翻译频率从一星译者迅速登顶五星译者。当然，还有 Bestony、Locez、VizV 等人为 LCTT 提供了不少技术支持和开发工作。

硕果累累

我们并没有特别的招新渠道，但是总是时不时会有新的成员慕名而来，到目前为止，我们已经有 331 位做过贡献的成员，已经翻译发布了 3885 篇译文，合计字节达 33MB 之多！

这两年，我们不但翻译了很多技术、新闻和评论类文章，也新增了新的翻译类型：漫画，其中一些漫画得到了很多好评。

我们发布的文章有一些达到了 100000+ 的访问量，这对于我们这种技术垂直内容可不容易。

而同时，Linux 中国也发布了近万篇文章，而这一篇，应该就是第 9999 篇文章，我们将在明天，进入新的篇章。

贡献者主页和贡献者证书

为了彰显诸位贡献者的贡献，我们为每位贡献者创立的自己的专页，并据此建立了排行榜。

同时，我们还特意请 Bestony 和“一一”设计开发和”贡献者证书”，大家可以在 LCTT 贡献平台中领取。

规则进化

LCTT 最初创立时，甚至都没有采用 PR 模式。但是随着贡献者的增多，我们也逐渐在改善我们的流程、方法。

之前采用了很粗糙的 PR 模式，对 PR 中的文件、提交乃至于信息都没有进行硬性约束。后来在 VizV 的帮助下，建立了对 PR 的合规性检查；又在 pityonline 的督促下，采用了更为严格的 PR 审查机制。

LCTT 创立几年来，我们的一些流程和规范，已经成为其它一些翻译组的参考范本，我们也希望我们的这些经验，可以进一步帮助到其它的开源社区。

仓库重建和版权问题

今年还发生一次严重的事故，由于对选题来源把控不严和对版权问题没有引起足够的重视，我们引用的一篇文章违背了原文的版权规定，结果被原文作者投诉到 GitHub。而我并没有及时看到 GitHub 给我发的 DMCA 处理邮件，因此错过了处理窗口期，从而被 GitHub 将整个库予以删除。

出现这样的重大失误之后，经过大家的帮助，我们历经周折才将仓库基本恢复。这要特别感谢 VizV 的辛苦工作。

在此之后，我们对译文选文的规则进行了梳理，并全面清查了文章版权。这个教训对我们来说弥足沉重。

通证时代

在 Linux 中国及 LCTT 发展过程中，我一直小心翼翼注意商业化的问题。严格来说，没有经济支持的开源组织如同无根之木，无源之水，是长久不了的。而商业化的技术社区又难免为了三斗米而折腰。所以往往很多技术社区要么渐渐凋零，要么就变成了商业机构。

从中国电信辞职后，我专职运营 Linux 中国这个开源社区已经近三年了，其间也有一些商业性收入，但是仅能勉强承担基本的运营费用。

这种尴尬的局面，使我，以及其它的开源社区同仁们纷纷寻求更好的发展之路。

去年参加中国开源年会时，在闭门会上，大家的讨论启发了我和诸位同仁，我们认为，开源社区结合通证经济，似乎是一条可行的开源社区发展之路。

今年 8 月 1 日，我们经过了半年的论证和实验，发布了社区通证 LCCN，并已经初步发放到了各位译者手中。我们还在继续建设通证生态各种工具，如合约、交易商城等。

我们希望能够通过通证为开源社区转入新的活力，也愿意将在探索道路上遇到的问题和解决的思路、工具链分享给更多的社区。

总结

从上一次总结以来，这又是七百多天，时光荏苒，而 LCTT 的创立也近两千天了。我希望，我们的翻译组以及更多的贡献者可以在通证经济的推动下，找到自洽、自治的发展道路；也希望能有更多的贡献者涌现出来接过我们的大旗，将开源发扬光大。

wxy
2018/9/9 夜

用这个易用的媒体创建工具来创建一个可引导的 USB 盘或 SD 卡。

可启动 USB 盘是尝试新的 Linux 发行版的很好的方式，以便在安装之前查看你是否喜欢它。虽然一些 Linux 发行版（如 Fedora）可以轻松创建可启动媒体，但大多数其他发行版提供 ISO 或镜像文件，并将创建媒体决定留给用户。用户总是可以选择使用 dd 在命令行上创建媒体——但让我们面对现实，即使对于最有经验的用户来说，这仍然很痛苦。也有一些其它程序，如 Mac 上的 UnetBootIn、Disk Utility 和 Windows 上的 Win32DiskImager，它们都可以创建可启动的 USB。

安装 Etcher

大约 18 个月前，我遇到了 Etcher.io，这是一个很棒的开源项目，可以在 Linux、Windows 或 MacOS 上轻松、简单地创建媒体。Etcher.io 已成为我为 Linux 创建可启动媒体的“首选”程序。我可以轻松下载 ISO 或 IMG 文件并将其刻录到闪存和 SD 卡。这是一个 Apache 2.0 许可证下的开源项目，源代码 可在 GitHub 上获得。

进入 Etcher.io 网站，然后单击适用于你的操作系统：32 位或 64 位 Linux、32 位或 64 位 Windows 或 MacOS 的下载链接。

Etcher 在 GitHub 仓库中提供了很好的指导，可以将 Etcher 添加到你的 Linux 实用程序集合中。

如果你使用的是 Debian 或 Ubuntu，请添加 Etcher Debian 仓库：

$echo "deb https://dl.bintray.com/resin-io/debian stable etcher" | sudo tee /etc/apt/sources.list.d/etcher.list

信任 Bintray.com GPG 密钥

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 379CE192D401AB61

然后更新你的系统并安装：

$ sudo apt-get update
$ sudo apt-get install etcher-electron

如果你使用的是 Fedora 或 Red Hat Enterprise Linux，请添加 Etcher RPM 仓库：

$ sudo wget https://bintray.com/resin-io/redhat/rpm -O /etc/yum.repos.d/bintray-resin-io-redhat.repo

使用以下任一方式更新和安装：

$ sudo yum install -y etcher-electron

或者：

$ sudo dnf install -y etcher-electron

创建可启动盘

除了为 Ubuntu、EndlessOS 和其他版本的 Linux 创建可启动镜像之外，我还使用 Etcher 创建 SD 卡镜像用于树莓派。以下是如何创建可启动媒体。

首先，将要使用的 ISO 或镜像下载到计算机。然后，启动 Etcher 并将 USB 或 SD 卡插入计算机。

单击 “Select Image”。在本例中，我想创建一个可启动的 USB 盘，以便在新计算机上安装 Ubermix。在我选择了我的 Ubermix 镜像文件并将我的 USB 盘插入计算机，Etcher.io “看到”了驱动器，我就可以开始在 USB 上安装 Ubermix 了。

在我点击 “Flash” 后，安装就开始了。所需时间取决于镜像的大小。在驱动器上安装镜像后，软件会验证安装。最后，一条提示宣布我的媒体创建已经完成。

如果您需要 Etcher 的帮助，请通过其 Discourse 论坛联系社区。Etcher 非常易于使用，它已经取代了我所有其他的媒体创建工具，因为它们都不像 Etcher 那样轻松地完成工作。

via: https://opensource.com/article/18/7/getting-started-etcherio

作者：Don Watkins 选题：lujun9972 译者：geekpi 校对：wxy

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