现在（LCTT 译注：本文发表于 1 月初），每个人都知道一件关乎电脑安全的“大事”发生了，真见鬼，等每日邮报报道的时候，你就知道什么是糟糕了...

不管怎样，除了告诉你这篇写的及其出色的披露该问题的 Zero 项目的论文之外，我不打算去跟进这个问题已经被报道出来的细节。他们应该现在就直接颁布 2018 年的 Pwnie 奖，干的太棒了。

如果你想了解我们如何在内核中解决这些问题的技术细节，你可以保持关注了不起的 lwn.net，他们会把这些细节写成文章。

此外，这有一条很好的关于这些公告的摘要，包括了各个厂商的公告。

至于这些涉及的公司是如何处理这些问题的，这可以说是如何不与 Linux 内核社区保持沟通的教科书般的例子。这件事涉及到的人和公司都知道发生了什么，我确定这件事最终会出现，但是目前我需要去关注的是如何修复这些涉及到的问题，然后不去点名指责，不管我有多么的想去这么做。

你现在能做什么

如果你的 Linux 系统正在运行一个正常的 Linux 发行版，那么升级你的内核。它们都应该已经更新了，然后在接下来的几个星期里保持更新。我们会统计大量在极端情况下出现的 bug ，这里涉及的测试很复杂，包括庞大的受影响的各种各样的系统和工作任务。如果你的 Linux 发行版没有升级内核，我强烈的建议你马上更换一个 Linux 发行版。

然而有很多的系统因为各种各样的原因（听说它们比起“传统”的企业发行版更多）不是在运行“正常的” Linux 发行版上。它们依靠长期支持版本（LTS）的内核升级，或者是正常的稳定内核升级，或者是内部的某人打造版本的内核。对于这部分人，这篇介绍了你能使用的上游内核中发生的混乱是怎么回事。

Meltdown – x86

现在，Linus 的内核树包含了我们当前所知的为 x86 架构解决 meltdown 漏洞的所有修复。开启 CONFIG_PAGE_TABLE_ISOLATION 这个内核构建选项，然后进行重构和重启，所有的设备应该就安全了。

然而，Linus 的内核树当前处于 4.15-rc6 这个版本加上一些未完成的补丁。4.15-rc7 版本要明天才会推出，里面的一些补丁会解决一些问题。但是大部分的人不会在一个“正常”的环境里运行 -rc 内核。

因为这个原因，x86 内核开发者在 页表隔离 page table isolation 代码的开发过程中做了一个非常好的工作，好到要反向移植到最新推出的稳定内核 4.14 的话，我们只需要做一些微不足道的工作。这意味着最新的 4.14 版本（本文发表时是 4.14.12 版本），就是你应该运行的版本。4.14.13 会在接下来的几天里推出，这个更新里有一些额外的修复补丁，这些补丁是一些运行 4.14.12 内核且有启动时间问题的系统所需要的（这是一个显而易见的问题，如果它不启动，就把这些补丁加入更新排队中）。

我个人要感谢 Andy Lutomirski、Thomas Gleixner、Ingo Molnar、 Borislav Petkov、 Dave Hansen、 Peter Zijlstra、 Josh Poimboeuf、 Juergen Gross 和 Linus Torvalds。他们开发出了这些修复补丁，并且为了让我能轻松地使稳定版本能够正常工作，还把这些补丁以一种形式融合到了上游分支里。没有这些工作，我甚至不敢想会发生什么。

对于老的长期支持内核（LTS），我主要依靠 Hugh Dickins、 Dave Hansen、 Jiri Kosina 和 Borislav Petkov 优秀的工作，来为 4.4 到 4.9 的稳定内核代码树分支带去相同的功能。我同样在追踪讨厌的 bug 和缺失的补丁方面从 Guenter Roeck、 Kees Cook、 Jamie Iles 以及其他很多人那里得到了极大的帮助。我要感谢 David Woodhouse、 Eduardo Valentin、 Laura Abbott 和 Rik van Riel 在反向移植和集成方面的帮助，他们的帮助在许多棘手的地方是必不可少的。

这些长期支持版本的内核同样有 CONFIG_PAGE_TABLE_ISOLATION 这个内核构建选项，你应该开启它来获得全方面的保护。

从主线版本 4.14 和 4.15 的反向移植是非常不一样的，它们会出现不同的 bug，我们现在知道了一些在工作中遇见的 VDSO 问题。一些特殊的虚拟机安装的时候会报一些奇怪的错，但这是只是现在出现的少数情况，这种情况不应该阻止你进行升级。如果你在这些版本中遇到了问题，请让我们在稳定内核邮件列表中知道这件事。

如果你依赖于 4.4 和 4.9 或是现在的 4.14 以外的内核代码树分支，并且没有发行版支持你的话，你就太不幸了。比起你当前版本内核包含的上百个已知的漏洞和 bug，缺少补丁去解决 meltdown 问题算是一个小问题了。你现在最需要考虑的就是马上把你的系统升级到最新。

与此同时，臭骂那些强迫你运行一个已被废弃且不安全的内核版本的人，他们是那些需要知道这是完全不顾后果的行为的人中的一份子。

Meltdown – ARM64

现在 ARM64 为解决 Meltdown 问题而开发的补丁还没有并入 Linus 的代码树，一旦 4.15 在接下来的几周里成功发布，他们就准备阶段式地并入 4.16-rc1，因为这些补丁还没有在一个 Linus 发布的内核中，我不能把它们反向移植进一个稳定的内核版本里（额……我们有这个规矩是有原因的）

由于它们还没有在一个已发布的内核版本中，如果你的系统是用的 ARM64 的芯片（例如 Android ），我建议你选择 Android 公共内核代码树，现在，所有的 ARM64 补丁都并入 3.18、4.4 和 4.9 分支 中。

我强烈建议你关注这些分支，看随着时间的过去，由于测试了已并入补丁的已发布的上游内核版本，会不会有更多的修复补丁被补充进来，特别是我不知道这些补丁会在什么时候加进稳定的长期支持内核版本里。

对于 4.4 到 4.9 的长期支持内核版本，这些补丁有很大概率永远不会并入它们，因为需要大量的先决补丁。而所有的这些先决补丁长期以来都一直在 Android 公共内核版本中测试和合并，所以我认为现在对于 ARM 系统来说，仅仅依赖这些内核分支而不是长期支持版本是一个更好的主意。

同样需要注意的是，我合并所有的长期支持内核版本的更新到这些分支后通常会在一天之内或者这个时间点左右进行发布，所以你无论如何都要关注这些分支，来确保你的 ARM 系统是最新且安全的。

Spectre

现在，事情变得“有趣”了……

再一次，如果你正在运行一个发行版的内核，一些内核融入了各种各样的声称能缓解目前大部分问题的补丁，你的内核可能就被包含在其中。如果你担心这一类的攻击的话，我建议你更新并测试看看。

对于上游来说，很好，现状就是仍然没有任何的上游代码树分支合并了这些类型的问题相关的修复补丁。有很多的邮件列表在讨论如何去解决这些问题的解决方案，大量的补丁在这些邮件列表中广为流传，但是它们尚处于开发前期，一些补丁系列甚至没有被构建或者应用到任何已知的代码树，这些补丁系列彼此之间相互冲突，这是常见的混乱。

这是由于 Spectre 问题是最近被内核开发者解决的。我们所有人都在 Meltdown 问题上工作，我们没有精确的 Spectre 问题全部的真实信息，而四处散乱的补丁甚至比公开发布的补丁还要糟糕。

因为所有的这些原因，我们打算在内核社区里花上几个星期去解决这些问题并把它们合并到上游去。修复补丁会进入到所有内核的各种各样的子系统中，而且在它们被合并后，会集成并在稳定内核的更新中发布，所以再次提醒，无论你使用的是发行版的内核还是长期支持的稳定内核版本，你最好并保持更新到最新版。

这不是好消息，我知道，但是这就是现实。如果有所安慰的话，似乎没有任何其它的操作系统完全地解决了这些问题，现在整个产业都在同一条船上，我们只需要等待，并让开发者尽快地解决这些问题。

提出的解决方案并非毫不重要，但是它们中的一些还是非常好的。一些新概念会被创造出来来帮助解决这些问题，Paul Turner 提出的 Retpoline 方法就是其中的一个例子。这将是未来大量研究的一个领域，想出方法去减轻硬件中涉及的潜在问题，希望在它发生前就去预见它。

其他架构的芯片

现在，我没有看见任何 x86 和 arm64 架构以外的芯片架构的补丁，听说在一些企业发行版中有一些用于其他类型的处理器的补丁，希望他们在这几周里能浮出水面，合并到合适的上游那里。我不知道什么时候会发生，如果你使用着一个特殊的架构，我建议在 arch-specific 邮件列表上问这件事来得到一个直接的回答。

结论

再次说一遍，更新你的内核，不要耽搁，不要止步。更新会在很长的一段时间里持续地解决这些问题。同样的，稳定和长期支持内核发行版里仍然有很多其它的 bug 和安全问题，它们和问题的类型无关，所以一直保持更新始终是一个好主意。

现在，有很多非常劳累、坏脾气、缺少睡眠的人，他们通常会生气地让内核开发人员竭尽全力地解决这些问题，即使这些问题完全不是开发人员自己造成的。请关爱这些可怜的程序猿。他们需要爱、支持，我们可以为他们免费提供的他们最爱的饮料，以此来确保我们都可以尽可能快地结束修补系统。

via: http://kroah.com/log/blog/2018/01/06/meltdown-status/

作者：Greg Kroah-Hartman 译者：hopefully2333 校对：wxy

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

如果你不改变 MySQL 的缺省配置，你的服务器的性能就像题图的坏在一档的法拉利一样 “虎落平阳被犬欺” …

我并不期望成为一个专家级的 DBA，但是，在我优化 MySQL 时，我推崇 80/20 原则，明确说就是通过简单的调整一些配置，你可以压榨出高达 80% 的性能提升。尤其是在服务器资源越来越便宜的当下。

警告

1. 没有两个数据库或者应用程序是完全相同的。这里假设我们要调整的数据库是为一个“典型”的 Web 网站服务的，优先考虑的是快速查询、良好的用户体验以及处理大量的流量。
2. 在你对服务器进行优化之前，请做好数据库备份！

1、 使用 InnoDB 存储引擎

如果你还在使用 MyISAM 存储引擎，那么是时候转换到 InnoDB 了。有很多的理由都表明 InnoDB 比 MyISAM 更有优势，如果你关注性能，那么，我们来看一下它们是如何利用物理内存的：

• MyISAM：仅在内存中保存索引。
• InnoDB：在内存中保存索引和数据。

结论：保存在内存的内容访问速度要比磁盘上的更快。

下面是如何在你的表上去转换存储引擎的命令：

ALTER TABLE table_name ENGINE=InnoDB;

注意：你已经创建了所有合适的索引，对吗？为了更好的性能，创建索引永远是第一优先考虑的事情。

2、 让 InnoDB 使用所有的内存

你可以在 my.cnf 文件中编辑你的 MySQL 配置。使用 innodb_buffer_pool_size 参数去配置在你的服务器上允许 InnoDB 使用物理内存数量。

对此（假设你的服务器仅仅运行 MySQL），公认的“经验法则”是设置为你的服务器物理内存的 80%。在保证操作系统不使用交换分区而正常运行所需要的足够内存之后 ，尽可能多地为 MySQL 分配物理内存。

因此，如果你的服务器物理内存是 32 GB，可以将那个参数设置为多达 25 GB。

innodb_buffer_pool_size = 25600M

*注意：（1）如果你的服务器内存较小并且小于 1 GB。为了适用本文的方法，你应该去升级你的服务器。 （2） 如果你的服务器内存特别大，比如，它有 200 GB，那么，根据一般常识，你也没有必要为操作系统保留多达 40 GB 的内存。 *

3、 让 InnoDB 多任务运行

如果服务器上的参数 innodb_buffer_pool_size 的配置是大于 1 GB，将根据参数 innodb_buffer_pool_instances 的设置， 将 InnoDB 的缓冲池划分为多个。

拥有多于一个的缓冲池的好处有：

在多线程同时访问缓冲池时可能会遇到瓶颈。你可以通过启用多缓冲池来最小化这种争用情况：

对于缓冲池数量的官方建议是：

为了实现最佳的效果，要综合考虑 innodb_buffer_pool_instances 和 innodb_buffer_pool_size 的设置，以确保每个实例至少有不小于 1 GB 的缓冲池。

因此，在我们的示例中，将参数 innodb_buffer_pool_size 设置为 25 GB 的拥有 32 GB 物理内存的服务器上。一个合适的设置为 25600M / 24 = 1.06 GB

innodb_buffer_pool_instances = 24

注意！

在修改了 my.cnf 文件后需要重启 MySQL 才能生效：

sudo service mysql restart

还有更多更科学的方法来优化这些参数，但是这几点可以作为一个通用准则来应用，将使你的 MySQL 服务器性能更好。

作者简介:

我喜欢商业技术以及跑车 | 集团 CTO @ Parcel Monkey， Cloud Fulfilment & Kong。

via: https://medium.com/@richb_/tuning-mysql-3-simple-tweaks-6356768f9b90

作者：Rich Barrett 译者：qhwdw 校对：wxy

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

便宜的物联网板的普及意味着它不仅会控制应用程序，还会控制整个软件平台。 那么，如何构建一个针对特定用途的交叉编译应用程序的自定义发行版呢？ 正如 Michael J. Hammel 在这里解释的那样，它并不像你想象的那么难。

为什么要定制？

以前，许多嵌入式项目都使用现成的发行版，然后出于种种原因，再将它们剥离到只剩下基本的必需的东西。首先，移除不需要的包以减少占用的存储空间。在启动时，嵌入式系统一般不需要大量的存储空间以及可用存储空间。在嵌入式系统运行时，可能从非易失性内存中拷贝大量的操作系统文件到内存中。第二，移除用不到的包可以降低可能的攻击面。如果你不需要它们就没有必要把这些可能有漏洞的包挂在上面。最后，移除用不到包可以降低发行版管理的开销。如果在包之间有依赖关系，意味着任何一个包请求从上游更新，那么它们都必须保持同步。那样可能就会出现验证噩梦。

然而，从一个现有的发行版中去移除包并不像说的那样容易。移除一个包可能会打破与其它包保持的各种依赖关系，以及可能在上游的发行版管理中改变依赖。另外，由于一些包原生集成在引导或者运行时进程中，它们并不能轻易地简单地移除。所有这些都是项目之外的平台的管理，并且有可能会导致意外的开发延迟。

一个流行的选择是使用上游发行版供应商提供的构建工具去构建一个定制的发行版。无论是 Gentoo 还是 Debian 都提供这种自下而上的构建方式。这些构建工具中最为流行的可能是 Debian 的 debootstrap 实用程序。它取出预构建的核心组件并允许用户去精选出它们感兴趣的包来构建用户自己的平台。但是，debootstrap 最初仅在 x86 平台上可用，虽然，现在有了 ARM（也有可能会有其它的平台）选项。debootstrap 和 Gentoo 的 catalyst 仍然需要从本地项目中将依赖管理移除。

一些人认为让别人去管理平台软件（像 Android 一样）要比自己亲自管理容易的多。但是，那些发行版都是多用途的，当你在一个轻量级的、资源有限的物联网设备上使用它时，你可能会再三考虑从你手中被拿走的任何资源。

系统引导的基石

一个定制的 Linux 发行版要求许多软件组件。其中第一个就是 工具链 toolchain 。工具链是用于编译软件的一套工具集。包括（但不限于）一个编译器、链接器、二进制操作工具以及标准的 C 库。工具链是为一个特定的目标硬件设备专门构建的。如果一个构建在 x86 系统上的工具链想要用于树莓派，那么这个工具链就被称为交叉编译工具链。当在内存和存储都十分有限的小型嵌入式设备上工作时，最好是使用一个交叉编译工具链。需要注意的是，即便是使用像 JavaScript 这样的需要运行在特定平台的脚本语言为特定用途编写的应用程序，也需要使用交叉编译工具链编译。

图 1. 编译依赖和引导顺序

交叉编译工具链用于为目标硬件构建软件组件。需要的第一个组件是 引导加载程序 bootloader 。当计算机主板加电之后，处理器（可能有差异，取决于设计）尝试去跳转到一个特定的内存位置去开始运行软件。那个内存位置就是保存引导加载程序的地方。硬件可能有内置的引导加载程序，它可能直接从它的存储位置或者可能在它运行前首先拷贝到内存中。也可能会有多个引导加载程序。例如，第一阶段的引导加载程序可能位于硬件的 NAND 或者 NOR 闪存中。它唯一的功能是设置硬件以便于执行第二阶段的引导加载程序——比如，存储在 SD 卡中的可以被加载并运行的引导加载程序。

引导加载程序能够从硬件中取得足够的信息，将 Linux 加载到内存中并跳转到正确的位置，将控制权有效地移交到 Linux。Linux 是一个操作系统。这意味着，在这种设计中，它除了监控硬件和向上层软件（也就是应用程序）提供服务外，它实际上什么都不做。Linux 内核 中通常是各种各样的固件块。那些预编译的软件对象，通常包含硬件平台使用的设备的专用 IP（知识资产）。当构建一个定制发行版时，在开始编译内核之前，它可能会要求获得一些 Linux 内核源代码树没有提供的必需的固件块。

应用程序保存在根文件系统中，这个根文件系统是通过编译构建的，它集合了各种软件库、工具、脚本以及配置文件。总的来说，它们都提供各种服务，比如，网络配置和 USB 设备挂载，这些都是将要运行的项目应用程序所需要的。

总的来说，一个完整的系统构建要求下列的组件：

1. 一个交叉编译工具链
2. 一个或多个引导加载程序
3. Linux 内核和相关的固件块
4. 一个包含库、工具以及实用程序的根文件系统
5. 定制的应用程序

使用适当的工具开始构建

交叉编译工具链的组件可以手工构建，但这是一个很复杂的过程。幸运的是，现有的工具可以很容易地完成这一过程。构建交叉编译工具链的最好工具可能是 Crosstool-NG，这个工具使用了与 Linux 内核相同的 kconfig 菜单系统来构建工具链的每个细节和方面。使用这个工具的关键是，为目标平台找到正确的配置项。配置项通常包含下列内容：

1. 目标架构，比如，是 ARM 还是 x86。
2. 字节顺序：小端字节顺序（一般情况下，Intel 采用这种顺序）还是大端字节顺序（一般情况下，ARM 或者其它的平台采用这种顺序）。
3. 编译器已知的 CPU 类型，比如，GCC 可以使用 -mcpu 或 --with-cpu。
4. 支持的浮点类型，如果有的话，比如，GCC 可以使用 -mfpu 或 --with-fpu。
5. 二进制实用工具 binutils 、C 库以及 C 编译器的特定版本信息。

图 2. Crosstool-NG 配置菜单

前四个一般情况下可以从处理器制造商的文档中获得。对于较新的处理器，它们可能不容易找到，但是，像树莓派或者 BeagleBoards（以及它们的后代和分支），你可以在像 嵌入式 Linux Wiki 这样的地方找到相关信息。

二进制实用工具、C 库、以及 C 编译器的版本，将与任何第三方提供的其它工具链分开。首先，它们中的每一个都有多个提供者。Linaro 为最新的处理器类型提供了最先进的版本，同时致力于将该支持合并到像 GNU C 库这样的上游项目中。尽管你可以使用各种提供者的工具，你可能依然想去使用现成的 GNU 工具链或者相同的 Linaro 版本。

在 Crosstool-NG 中的另外的重要选择是 Linux 内核的版本。这个选择将得到用于各种工具链组件的 头文件 headers ，但是它没有必要一定与你在目标硬件上将要引导的 Linux 内核相同。选择一个不比目标硬件的内核更新的 Linux 内核是很重要的。如果可能的话，尽量选择一个比目标硬件使用的内核更老的长周期支持（LTS）的内核。

对于大多数不熟悉构建定制发行版的开发者来说，工具链的构建是最为复杂的过程。幸运的是，大多数硬件平台的二进制工具链都可以想办法得到。如果构建一个定制的工具链有问题，可以在线搜索像 嵌入式 Linux Wiki 这样的地方去查找预构建工具链。

引导选项

在构建完工具链之后，接下来的工作是引导加载程序。引导加载程序用于设置硬件，以便于越来越复杂的软件能够使用这些硬件。第一阶段的引导加载程序通常由目标平台制造商提供，它通常被烧录到类似于 EEPROM 或者 NOR 闪存这类的在硬件上的存储中。第一阶段的引导加载程序将使设备从这里（比如，一个 SD 存储卡）开始引导。树莓派的引导加载程序就是这样的，它样做也就没有必要再去创建一个定制引导加载程序。

尽管如此，许多项目还是增加了第二阶段的引导加载程序，以便于去执行一个多样化的任务。在无需使用 Linux 内核或者像 plymouth 这样的用户空间工具的情况下提供一个启动动画，就是其中一个这样的任务。一个更常见的第二阶段引导加载程序的任务是去提供基于网络的引导或者使连接到 PCI 上的磁盘可用。在那种情况下，一个第三阶段的引导加载程序，比如 GRUB，可能才是让系统运行起来所必需的。

最重要的是，引导加载程序加载 Linux 内核并使它开始运行。如果第一阶段引导加载程序没有提供一个在启动时传递内核参数的机制，那么，在第二阶段的引导加载程序中就必须要提供。

有许多的开源引导加载程序可以使用。U-Boot 项目 通常用于像树莓派这样的 ARM 平台。CoreBoot 一般是用于像 Chromebook 这样的 x86 平台。引导加载程序是特定于目标硬件专用的。引导加载程序的选择总体上取决于项目的需求以及目标硬件（可以去网络上在线搜索开源引导加载程序的列表）。

现在到了 Linux 登场的时候

引导加载程序将加载 Linux 内核到内存中，然后去运行它。Linux 就像一个扩展的引导加载程序：它进行进行硬件设置以及准备加载高级软件。内核的核心将设置和提供在应用程序和硬件之间共享使用的内存；提供任务管理器以允许多个应用程序同时运行；初始化没有被引导加载程序配置的或者是已经配置了但是没有完成的硬件组件；以及开启人机交互界面。内核也许不会配置为在自身完成这些工作，但是，它可以包含一个嵌入的、轻量级的文件系统，这类文件系统大家熟知的有 initramfs 或者 initrd，它们可以独立于内核而创建，用于去辅助设置硬件。

内核操作的另外的事情是去下载二进制块（通常称为固件）到硬件设备。固件是用特定格式预编译的对象文件，用于在引导加载程序或者内核不能访问的地方去初始化特定硬件。许多这种固件对象可以从 Linux 内核源仓库中获取，但是，还有很多其它的固件只能从特定的硬件供应商处获得。例如，经常由它们自己提供固件的设备有数字电视调谐器或者 WiFi 网卡等。

固件可以从 initramfs 中加载，也或者是在内核从根文件系统中启动 init 进程之后加载。但是，当你去创建一个定制的 Linux 发行版时，创建内核的过程常常就是获取各种固件的过程。

轻量级核心平台

Linux 内核做的最后一件事情是尝试去运行一个被称为 init 进程的专用程序。这个专用程序的名字可能是 init 或者 linuxrc 或者是由加载程序传递给内核的名字。init 进程保存在一个能够被内核访问的文件系统中。在 initramfs 这种情况下，这个文件系统保存在内存中（它可能是被内核自己放置到那里，也可能是被引导加载程序放置在那里）。但是，对于运行更复杂的应用程序，initramfs 通常并不够完整。因此需要另外一个文件系统，这就是众所周知的根文件系统。

图 3. 构建 root 配置菜单

initramfs 文件系统可以使用 Linux 内核自身构建，但是更常用的作法是，使用一个被称为 BusyBox 的项目去创建。BusyBox 组合许多 GNU 实用程序（比如，grep 或者 awk）到一个单个的二进制文件中，以便于减小文件系统自身的大小。BusyBox 通常用于去启动根文件系统的创建过程。

但是，BusyBox 是特意轻量化设计的。它并不打算提供目标平台所需要的所有工具，甚至提供的工具也是经过功能简化的。BusyBox 有一个“姊妹”项目叫做 Buildroot，它可以用于去得到一个完整的根文件系统，提供了各种库、实用程序，以及脚本语言。像 Crosstool-NG 和 Linux 内核一样，BusyBox 和 Buildroot 也都允许使用 kconfig 菜单系统去定制配置。更重要的是，Buildroot 系统自动处理依赖关系，因此，选定的实用程序将会保证该程序所需要的软件也会被构建并安装到 root 文件系统。

Buildroot 可以用多种格式去生成一个根文件系统包。但是，需要重点注意的是，这个文件系统是被归档的。单个的实用程序和库并不是以 Debian 或者 RPM 格式打包进去的。使用 Buildroot 将生成一个根文件系统镜像，但是它的内容不是单独的包。即使如此，Buildroot 还是提供了对 opkg 和 rpm 包管理器的支持的。这意味着，虽然根文件系统自身并不支持包管理，但是，安装在根文件系统上的定制应用程序能够进行包管理。

交叉编译和脚本化

Buildroot 的其中一个特性是能够生成一个临时树。这个目录包含库和实用程序，它可以被用于去交叉编译其它应用程序。使用临时树和交叉编译工具链，使得在主机系统上而不是目标平台上对 Buildroot 之外的其它应用程序编译成为可能。使用 rpm 或者 opkg 包管理软件之后，这些应用程序可以在运行时使用包管理软件安装在目标平台的根文件系统上。

大多数定制系统的构建都是围绕着用脚本语言构建应用程序的想法去构建的。如果需要在目标平台上运行脚本，在 Buildroot 上有多种可用的选择，包括 Python、PHP、Lua 以及基于 Node.js 的 JavaScript。对于需要使用 OpenSSL 加密的应用程序也提供支持。

接下来做什么

Linux 内核和引导加载程序的编译过程与大多数应用程序是一样的。它们的构建系统被设计为去构建一个专用的软件位。Crosstool-NG 和 Buildroot 是 元构建 metabuild 。元构建是将一系列有自己构建系统的软件集合封装为一个构建系统。可靠的元构建包括 Yocto 和 OpenEmbedded。Buildroot 的好处是可以将更高级别的元构建进行轻松的封装，以便于将定制 Linux 发行版的构建过程自动化。这样做之后，将会打开 Buildroot 指向到项目专用的缓存仓库的选项。使用缓存仓库可以加速开发过程，并且可以在无需担心上游仓库变化的情况下提供构建快照。

一个实现高级构建系统的示例是 PiBox。PiBox 就是封装了在本文中讨论的各种工具的一个元构建。它的目的是围绕所有工具去增加一个通用的 GNU Make 目标架构，以生成一个核心平台，这个平台可以构建或分发其它软件。PiBox 媒体中心和 kiosk 项目是安装在核心平台之上的应用层软件的实现，目的是用于去产生一个构建平台。Iron Man 项目 是为了家庭自动化的目的而扩展了这种应用程序，它集成了语音管理和物联网设备的管理。

但是，PiBox 如果没有这些核心的软件工具，它什么也做不了。并且，如果不去深入了解一个完整的定制发行版的构建过程，那么你将无法正确运行 PiBox。而且，如果没有 PiBox 开发团队对这个项目的长期奉献，也就没有 PiBox 项目，它完成了定制发行版构建中的大量任务。

via: http://www.linuxjournal.com/content/custom-embedded-linux-distributions

作者：Michael J.Hammel 译者：qhwdw 校对：wxy

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

VI 编辑器是一个基于命令行的、功能强大的文本编辑器，最早为 Unix 系统开发，后来也被移植到许多的 Unix 和 Linux 发行版上。

在 Linux 上还存在着另一个 VI 编辑器的高阶版本 —— VIM（也被称作 VI IMproved）。VIM 只是在 VI 已经很强的功能上添加了更多的功能，这些功能有：

• 支持更多 Linux 发行版，
• 支持多种编程语言，包括 python、c++、perl 等语言的代码块折叠，语法高亮，
• 支持通过多种网络协议，包括 http、ssh 等编辑文件，
• 支持编辑压缩归档中的文件，
• 支持分屏同时编辑多个文件。

接下来我们会讨论 VI/VIM 的命令以及选项。本文出于教学的目的，我们使用 VI 来举例，但所有的命令都可以被用于 VIM。首先我们先介绍 VI 编辑器的两种模式。

命令模式

命令模式下，我们可以执行保存文件、在 VI 内运行命令、复制/剪切/粘贴操作，以及查找/替换等任务。当我们处于插入模式时，我们可以按下 Escape（Esc）键返回命令模式

插入模式

在插入模式下，我们可以键入文件内容。在命令模式下按下 i 进入插入模式。

创建文件

我们可以通过下述命令建立一个文件（LCTT 译注：如果该文件存在，则编辑已有文件）：

$ vi filename

一旦该文件被创建或者打开，我们首先进入命令模式，我们需要进入输入模式以在文件中输入内容。我们通过前文已经大致上了解这两种模式。

退出 Vi

如果是想从插入模式中退出，我们首先需要按下 Esc 键进入命令模式。接下来我们可以根据不同的需要分别使用两种命令退出 Vi。

1. 不保存退出 - 在命令模式中输入 :q!
2. 保存并退出 - 在命令模式中输入 :wq

移动光标

下面我们来讨论下那些在命令模式中移动光标的命令和选项：

1. k 将光标上移一行
2. j 将光标下移一行
3. h 将光标左移一个字母
4. l 将光标右移一个字母
   注意：如果你想通过一个命令上移或下移多行，或者左移、右移多个字母，你可以使用 4k 或者 5l，这两条命令会分别上移 4 行或者右移 5 个字母。
5. 0 将光标移动到该行行首
6. $ 将光标移动到该行行尾
7. nG 将光标移动到第 n 行
8. G 将光标移动到文件的最后一行
9. { 将光标移动到上一段
10. } 将光标移动到下一段

除此之外还有一些命令可以用于控制光标的移动，但上述列出的这些命令应该就能应付日常工作所需。

编辑文本

这部分会列出一些用于命令模式的命令，可以进入插入模式来编辑当前文件

1. i 在当前光标位置之前插入内容
2. I 在光标所在行的行首插入内容
3. a 在当前光标位置之后插入内容
4. A 在光标所在行的行尾插入内容
5. o 在当前光标所在行之后添加一行
6. O 在当前光标所在行之前添加一行

删除文本

以下的这些命令都只能在命令模式下使用，所以首先需要按下 Esc 进入命令模式，如果你正处于插入模式：

1. dd 删除光标所在的整行内容，可以在 dd 前增加数字，比如 2dd 可以删除从光标所在行开始的两行
2. d$ 删除从光标所在位置直到行尾
3. d^ 删除从光标所在位置直到行首
4. dw 删除从光标所在位置直到下一个词开始的所有内容

复制与黏贴

1. yy 复制当前行，在 yy 前添加数字可以复制多行
2. p 在光标之后粘贴复制行
3. P 在光标之前粘贴复制行

上述就是可以在 VI/VIM 编辑器上使用的一些基本命令。在未来的教程中还会继续教授一些更高级的命令。如果有任何疑问和建议，请在下方评论区留言。

via: http://linuxtechlab.com/working-vi-editor-basics/

作者：Shusain 译者：ljgibbslf 校对：wxy

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

删除文件和复制/移动文件一样，都是很基础的操作。在 Linux 中，有一个专门的命令 rm，可用于完成所有删除相关的操作。在本文中，我们将用些容易理解的例子来讨论这个命令的基本使用。

但在我们开始前，值得指出的是本文所有示例都在 Ubuntu 16.04 LTS 中测试过。

Linux rm 命令概述

通俗的讲，我们可以认为 rm 命令是用于删除文件和目录的。下面是此命令的语法：

rm [选项]... [要删除的文件/目录]...

下面是命令使用说明：

GUN 版本 rm 命令的手册文档。rm 删除每个指定的文件，默认情况下不删除目录。

当删除的文件超过三个或者提供了选项 -r、-R 或 --recursive（LCTT 译注：表示递归删除目录中的文件）时，如果给出 -I（LCTT 译注：大写的 I）或 --interactive=once 选项（LCTT 译注：表示开启交互一次），则 rm 命令会提示用户是否继续整个删除操作，如果用户回应不是确认（LCTT 译注：即没有回复 y），则整个命令立刻终止。

另外，如果被删除文件是不可写的，标准输入是终端，这时如果没有提供 -f 或 --force 选项，或者提供了 -i（LCTT 译注：小写的 i） 或 --interactive=always 选项，rm 会提示用户是否要删除此文件，如果用户回应不是确认（LCTT 译注：即没有回复 y），则跳过此文件。

下面这些问答式例子会让你更好的理解这个命令的使用。

Q1. 如何用 rm 命令删除文件？

这是非常简单和直观的。你只需要把文件名（如果文件不是在当前目录中，则还需要添加文件路径）传入给 rm 命令即可。

（LCTT 译注：可以用空格隔开传入多个文件名称。）

rm 文件1 文件2 ... 

如：

rm testfile.txt

Q2. 如何用 rm 命令删除目录?

如果你试图删除一个目录，你需要提供 -r 选项。否则 rm 会抛出一个错误告诉你正试图删除一个目录。

（LCTT 译注：-r 表示递归地删除目录下的所有文件和目录。）

rm -r [目录名称]

如：

rm -r testdir

Q3. 如何让删除操作前有确认提示?

如果你希望在每个删除操作完成前都有确认提示，可以使用 -i 选项。

rm -i [文件/目录]

比如，你想要删除一个目录“testdir”，但需要每个删除操作都有确认提示，你可以这么做：

rm -r -i testdir

Q4. 如何让 rm 忽略不存在的文件或目录?

如果你删除一个不存在的文件或目录时，rm 命令会抛出一个错误，如：

然而，如果你愿意，你可以使用 -f 选项（LCTT 译注：即 “force”）让此次操作强制执行，忽略错误提示。

rm -f [文件...]

Q5. 如何让 rm 仅在某些场景下确认删除？

选项 -I，可保证在删除超过 3 个文件时或递归删除时（LCTT 译注： 如删除目录）仅提示一次确认。

比如，下面的截图展示了 -I 选项的作用——当两个文件被删除时没有提示，当超过 3 个文件时会有提示。

Q6. 当删除根目录是 rm 是如何工作的?

当然，删除根目录（/）是 Linux 用户最不想要的操作。这也就是为什么默认 rm 命令不支持在根目录上执行递归删除操作。（LCTT 译注：早期的 rm 命令并无此预防行为。）

然而，如果你非得完成这个操作，你需要使用 --no-preserve-root 选项。当提供此选项，rm 就不会特殊处理根目录（/）了。

假如你想知道在哪些场景下 Linux 用户会删除他们的根目录，点击这里。

Q7. 如何让 rm 仅删除空目录？

假如你需要 rm 在删除目录时仅删除空目录，你可以使用 -d 选项。

rm -d [目录]

下面的截图展示 -d 选项的用途——仅空目录被删除了。

Q8. 如何让 rm 显示当前删除操作的详情?

如果你想 rm 显示当前操作完成时的详细情况，使用 -v 选项可以做到。

rm -v [文件/目录]

如：

结论

考虑到 rm 命令提供的功能，可以说其是 Linux 中使用频率最高的命令之一了（就像 cp 和 mv 一样）。在本文中，我们涉及到了其提供的几乎所有主要选项。rm 命令有些学习曲线，因此在你日常工作中开始使用此命令之前 你将需要花费些时间去练习它的选项。更多的信息，请点击此命令的 man 手册页。

via: https://www.howtoforge.com/linux-rm-command/

作者：Himanshu Arora 译者：yizhuoyan 校对：wxy

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

如果您从未使用过 Git，甚至可能从未听说过它。莫慌张，只需要一步步地跟着这篇入门教程，很快您就会在 GitHub 上拥有一个全新的 Git 仓库。

在开始之前，让我们先理清一个常见的误解：Git 并不是 GitHub。Git 是一套版本控制系统（或者说是一款软件），能够协助您跟踪计算机程序和文件在任何时间的更改。它同样允许您在程序、代码和文件操作上与同事协作。GitHub 以及类似服务（包括 GitLab 和 BitBucket）都属于部署了 Git 程序的网站，能够托管您的代码。

步骤 1：申请一个 GitHub 账户

在 GitHub.com 网站上（免费）创建一个账户是最简单的方式。

选择一个用户名（比如说，octocat123），输入您的邮箱地址和密码，然后点击 Sign up for GitHub。进入之后，您将看到下方插图的界面：

步骤 2：创建一个新的仓库

一个仓库（ repository），类似于能储存物品的场所或是容器；在这里，我们创建仓库存储代码。在 + 符号（在插图的右上角，我已经选中它了） 的下拉菜单中选择 New Repository。

给您的仓库命名（比如说，Demo）然后点击 Create Repository。无需考虑本页面的其他选项。

恭喜！您已经在 GitHub.com 中建立了您的第一个仓库。

步骤 3: 创建文件

当仓库创建完毕后，界面将和下方一致：

不必惊慌，它比看上去简单。跟紧步骤。忽略其他内容，注意截图上的 “...or create a new repository on the command line,”。

在您的计算机中打开终端。

键入 git 然后回车。如果命令行显示 bash: git: command not found，在您的操作系统或发行版 安装 Git 命令。键入 git 并回车检查是否成功安装；如果安装成功，您将看见大量关于使用该命令的说明信息。

在终端内输入：

mkdir Demo

这个命令将会创建一个名为 Demo 的目录（文件夹）。

如下命令将会切换终端目录，跳转到 Demo 目录：

cd Demo

然后输入：

echo "#Demo" >> README.md

创建一个名为 README.md 的文件，并写入 #Demo。检查文件是否创建成功，请输入：

cat README.md

这将会为您显示 README.md 文件的内容，如果文件创建成功，您的终端会有如下显示：

使用 Git 程序告诉您的电脑，Demo 是一个被 Git 管理的目录，请输入：

git init

然后，告诉 Git 程序您关心的文件并且想在此刻起跟踪它的任何改变，请输入：

git add README.md

步骤 4：创建一次提交

目前为止，您已经创建了一个文件，并且已经通知了 Git，现在，是时候创建一次 提交 commit 了。提交可以看作是一个里程碑。每当完成一些工作之时，您都可以创建一次提交，保存文件当前版本，这样一来，您可以返回之前的版本，并且查看那时候的文件内容。无论何时您修改了文件，都可以对文件创建一个上一次的不一样的新版本。

创建一次提交，请输入：

git commit -m "first commit"

就是这样！刚才您创建了包含一条注释为 “first commit” 的 Git 提交。每次提交，您都必须编辑注释信息；它不仅能协助您识别提交，而且能让您理解此时您对文件做了什么修改。这样到了明天，如果您在文件中添加新的代码，您可以写一句提交信息：“添加了新的代码”，然后当您一个月后回来查看提交记录或者 Git 日志（即提交列表），您还能知道当时的您在文件夹里做了什么。

步骤 5: 将您的计算机与 GitHub 仓库相连接

现在，是时候用如下命令将您的计算机连接到 GitHub 仓库了：

git remote add origin https://github.com/<your_username>/Demo.git

让我们一步步的分析这行命令。我们通知 Git 去添加一个叫做 origin （起源）的，拥有地址为 https://github.com/<your_username>/Demo.git（它也是您的仓库的 GitHub 地址） 的 remote （远程仓库）。当您提交代码时，这允许您在 GitHub.com 和 Git 仓库交互时使用 origin 这个名称而不是完整的 Git 地址。为什么叫做 origin？当然，您可以叫点别的，只要您喜欢（惯例而已）。

现在，我们已经将本地 Demo 仓库副本连接到了其在 GitHub.com 远程副本上。您的终端看起来如下：

此刻我们已经连接到远程仓库，可以推送我们的代码 到 GitHub.com（例如上传 README.md 文件）。

执行完毕后，您的终端会显示如下信息：

然后，如果您访问 https://github.com/<your_username>/Demo，您会看到截图内显示的情况：

就是这么回事！您已经创建了您的第一个 GitHub 仓库，连接到了您的电脑，并且从你的计算机推送（或者称：上传）一个文件到 GitHub.com 名叫 Demo 的远程仓库上了。下一次，我将编写关于 Git 复制（从 GitHub 上下载文件到你的计算机上）、添加新文件、修改现存文件、推送（上传）文件到 GitHub。

via: https://opensource.com/article/18/1/step-step-guide-git

作者：Kedar Vijay Kulkarni 译者：CYLeft 校对：wxy

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