在 Linux 内核中发现了一个名为 “Stack Clash” 的严重安全问题，攻击者能够利用它来破坏内存数据并执行任意代码。攻击者可以利用这个及另一个漏洞来执行任意代码并获得管理帐户（root）权限。

在 Linux 中该如何解决这个问题？

Qualys 研究实验室在 GNU C Library（CVE-2017-1000366）的动态链接器中发现了许多问题，它们通过与 Linux 内核内的堆栈冲突来允许本地特权升级。这个 bug 影响到了 i386 和 amd64 上的 Linux、OpenBSD、NetBSD、FreeBSD 和 Solaris。攻击者可以利用它来破坏内存数据并执行任意代码。

什么是 CVE-2017-1000364 bug？

来自 RHN：

在用户空间二进制文件的堆栈中分配内存的方式发现了一个缺陷。如果堆（或不同的内存区域）和堆栈内存区域彼此相邻，则攻击者可以使用此缺陷跳过堆栈保护区域，从而导致进程堆栈或相邻内存区域的受控内存损坏，从而增加其系统权限。有一个在内核中减轻这个漏洞的方法，将堆栈保护区域大小从一页增加到 1 MiB，从而使成功利用这个功能变得困难。

据原研究文章：

计算机上运行的每个程序都使用一个称为堆栈的特殊内存区域。这个内存区域是特别的，因为当程序需要更多的堆栈内存时，它会自动增长。但是，如果它增长太多，并且与另一个内存区域太接近，程序可能会将堆栈与其他内存区域混淆。攻击者可以利用这种混乱来覆盖其他内存区域的堆栈，或者反过来。

受到影响的 Linux 发行版

1. Red Hat Enterprise Linux Server 5.x
2. Red Hat Enterprise Linux Server 6.x
3. Red Hat Enterprise Linux Server 7.x
4. CentOS Linux Server 5.x
5. CentOS Linux Server 6.x
6. CentOS Linux Server 7.x
7. Oracle Enterprise Linux Server 5.x
8. Oracle Enterprise Linux Server 6.x
9. Oracle Enterprise Linux Server 7.x
10. Ubuntu 17.10
11. Ubuntu 17.04
12. Ubuntu 16.10
13. Ubuntu 16.04 LTS
14. Ubuntu 12.04 ESM (Precise Pangolin)
15. Debian 9 stretch
16. Debian 8 jessie
17. Debian 7 wheezy
18. Debian unstable
19. SUSE Linux Enterprise Desktop 12 SP2
20. SUSE Linux Enterprise High Availability 12 SP2
21. SUSE Linux Enterprise Live Patching 12
22. SUSE Linux Enterprise Module for Public Cloud 12
23. SUSE Linux Enterprise Build System Kit 12 SP2
24. SUSE Openstack Cloud Magnum Orchestration 7
25. SUSE Linux Enterprise Server 11 SP3-LTSS
26. SUSE Linux Enterprise Server 11 SP4
27. SUSE Linux Enterprise Server 12 SP1-LTSS
28. SUSE Linux Enterprise Server 12 SP2
29. SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

我需要重启我的电脑么？

是的，由于大多数服务依赖于 GNU C Library 的动态连接器，并且内核自身需要在内存中重新加载。

我该如何在 Linux 中修复 CVE-2017-1000364？

根据你的 Linux 发行版来输入命令。你需要重启电脑。在应用补丁之前，记下你当前内核的版本：

$ uname -a
$ uname -mrs

示例输出：

Linux 4.4.0-78-generic x86_64

Debian 或者 Ubuntu Linux

输入下面的 apt 命令 / apt-get 命令来应用更新：

$ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

示例输出：

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 linux-compiler-gcc-6-x86 linux-headers-4.9.0-3-amd64 linux-headers-4.9.0-3-common linux-image-4.9.0-3-amd64
  linux-kbuild-4.9 linux-libc-dev locales multiarch-support
14 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/62.0 MB of archives.
After this operation, 4,096 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../libc6-i386_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6-i386 (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../libc6-dev_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6-dev:amd64 (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../libc-dev-bin_2.24-11+deb9u1_amd64.deb ...
Unpacking libc-dev-bin (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../linux-libc-dev_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-libc-dev:amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../libc6_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6:amd64 (2.24-11+deb9u1) over (2.24-11) ...
Setting up libc6:amd64 (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.24-11+deb9u1_amd64.deb ...
Unpacking libc-bin (2.24-11+deb9u1) over (2.24-11) ...
Setting up libc-bin (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../multiarch-support_2.24-11+deb9u1_amd64.deb ...
Unpacking multiarch-support (2.24-11+deb9u1) over (2.24-11) ...
Setting up multiarch-support (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../0-libc-l10n_2.24-11+deb9u1_all.deb ...
Unpacking libc-l10n (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../1-locales_2.24-11+deb9u1_all.deb ...
Unpacking locales (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../2-linux-compiler-gcc-6-x86_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-compiler-gcc-6-x86 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../3-linux-headers-4.9.0-3-amd64_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-headers-4.9.0-3-amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../4-linux-headers-4.9.0-3-common_4.9.30-2+deb9u1_all.deb ...
Unpacking linux-headers-4.9.0-3-common (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../5-linux-kbuild-4.9_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-kbuild-4.9 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../6-linux-image-4.9.0-3-amd64_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Setting up linux-libc-dev:amd64 (4.9.30-2+deb9u1) ...
Setting up linux-headers-4.9.0-3-common (4.9.30-2+deb9u1) ...
Setting up libc6-i386 (2.24-11+deb9u1) ...
Setting up linux-compiler-gcc-6-x86 (4.9.30-2+deb9u1) ...
Setting up linux-kbuild-4.9 (4.9.30-2+deb9u1) ...
Setting up libc-l10n (2.24-11+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libc-dev-bin (2.24-11+deb9u1) ...
Setting up linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
cryptsetup: WARNING: failed to detect canonical device of /dev/md0
cryptsetup: WARNING: could not determine root device from /etc/fstab
W: initramfs-tools configuration sets RESUME=UUID=054b217a-306b-4c18-b0bf-0ed85af6c6e1
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/md1p1
I: (UUID=bf72f3d4-3be4-4f68-8aae-4edfe5431670)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-4.9.0-3-amd64
Found kernel: /boot/vmlinuz-3.16.0-4-amd64
Updating /boot/grub/menu.lst ... done

Setting up libc6-dev:amd64 (2.24-11+deb9u1) ...
Setting up locales (2.24-11+deb9u1) ...
Generating locales (this might take a while)...
  en_IN.UTF-8... done
Generation complete.
Setting up linux-headers-4.9.0-3-amd64 (4.9.30-2+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...

使用 reboot 命令重启桌面/服务器：

$ sudo reboot

Oracle/RHEL/CentOS/Scientific Linux

输入下面的 yum 命令：

$ sudo yum update
$ sudo reboot

Fedora Linux

输入下面的 dnf 命令：

$ sudo dnf update
$ sudo reboot

Suse Enterprise Linux 或者 Opensuse Linux

输入下面的 zypper 命令：

$ sudo zypper patch
$ sudo reboot

SUSE OpenStack Cloud 6

$ sudo zypper in -t patch SUSE-OpenStack-Cloud-6-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Server for SAP 12-SP1

$ sudo zypper in -t patch SUSE-SLE-SAP-12-SP1-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Server 12-SP1-LTSS

$ sudo zypper in -t patch SUSE-SLE-SERVER-12-SP1-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Module for Public Cloud 12

$ sudo zypper in -t patch SUSE-SLE-Module-Public-Cloud-12-2017-996=1
$ sudo reboot

验证

你需要确认你的版本号在 reboot 命令之后改变了。

$ uname -a
$ uname -r
$ uname -mrs

示例输出：

Linux 4.4.0-81-generic x86_64

给 OpenBSD 用户的注意事项

见此页获取更多信息。

给 Oracle Solaris 的注意事项

见此页获取更多信息。

参考

• 堆栈冲突

作者简介:

Vivek Gite

作者是 nixCraft 的创始人，对于 Linux 操作系统/Unix shell脚本有经验丰富的系统管理员和培训师。他曾与全球客户及各行各业，包括 IT、教育、国防和空间研究以及非营利部门合作。在 Twitter、Facebook、Google + 上关注他。

via: https://www.cyberciti.biz/faq/howto-patch-linux-kernel-stack-clash-vulnerability-cve-2017-1000364/

作者：Vivek Gite 译者：geekpi 校对：wxy

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

很多 Linux 爱好者喜欢用他们的 Linux 系统玩游戏，看起来似乎并不需要一个可以玩游戏的操作系统。UALinux 是一家推广使用 GNU/Linux 的乌克兰公司。UALinux 开发了一个 Ubuntu 版本填补了这一空白，并把这个基于 Ubuntu 16.04 的操作系统（OS）命名为 Ubuntu GamePack。

内容

（Linux 上的）游戏现在已经相当丰富，而游戏公司宣称可以访问超过 22,381 款游戏。

这个 GamePack 包括 Lutris 和 Steam 两部分，允许您访问发行版厂商提供的特定游戏服务。

对于基于 Windows 的游戏，可以用 PlayOnLinux，WINE 和 CrossOver 转换到 Linux 上运行。

对于 DOS 游戏，您可以在 DosBox 中运行游戏，这是一个 Linux 的 DOS 模拟器。

也安装了 Sparky APTus Gamer ，可以访问众多主机游戏模拟器。 模拟器包括：

• AdvanceMENU - AdvanceMAME、 AdvanceMESS、 MAME、 MESS、 xmame、 Raine 以及其他的模拟器的前端
• Atari800 - Atari 8 位系统、XE 游戏系统和 Atari 5200 超级系统的模拟器
• DeSmuME - 任天堂 DS 模拟器
• Desura - 支持 Windows、Linux 和 X 系统的数字化分发平台 - 在线安装器
• DOSBox - 支持 BeOS、Linux、Mac X、OS2 和 Windows 的 DOS 模拟器
• DOSEMU - 支持 Linux 的 DOS 模拟器
• ePSXe - 增强的 PSX 模拟器
• FCEUX - 任天堂娱乐系统（NES）、红白机（Famicom）和红白机磁盘系统（FDS）模拟器（仿真器）
• FS-UAE - 跨平台的 Amiga 模拟器
• GNOME Video Arcade - 简化的 MAME 前端
• Hatari - 支持 Linux 和其他系统的 Atari ST、STE、TT 和 Falcon 模拟器（仿真器）
• Higan - 任天堂 SNES、NES、Gameboy、Gameboy Color 和 Gameboy Advance 的模拟器
• Kega\_Fusion - 世嘉 SG/SC/SF，主系统、Master System、 Game Gear、 Genesis/Megadrive、 SVP、 Pico、 SegaCD/MegaCD 模拟器
• MAME - 忠实重现了许多街机效果的硬件模拟器
• Mednafen - Atari Lynx、GameBoy、NES、SNES、PC-FX、世嘉，索尼游戏站等系统
• MESS - 各种主机和计算机游戏的模拟器
• Nestopia - 任天堂娱乐系统/红白机模拟器
• PCSX - 索尼游戏站模拟器
• PlayOnLinux - Wine 前端
• PPSSPP - PPSSPP 是支持 Windows、MacOS、Linux 和 Android 的开源 PSP 仿真器
• Steam - Steam 软件分发服务的启动器 - 在线安装程序
• Stella -用于 SDL 和 X Window 系统的 Atari 2600 仿真器
• VisualBoyAdvance - 全功能 Game Boy Advance 的模拟器
• Virtual Jaguar - 用于 Atari 的 infamous Jaguar 主机游戏的跨平台模拟器
• Wine - Windows 二进制在 Linux 中运行
• Winetricks - 一个用于 WINE 的 POSIX shell 脚本的软件包管理器，能够很容易安装一些 Windows软件
• Yabause - 世嘉土星32位游戏机模拟器
• ZSNES - 超级任天堂娱乐系统模拟器

GamePack 还包括被一些游戏所必须的 Oracle java 和 Adobe Flash。

如果这是一个你感兴趣的操作系统，请继续阅读，看看如何下载它。

下载

下载此操作系统镜像的主要地方是 UALinux 。其下载链接是： https://ualinux.com/en/download/category/25-ubuntu-gamepack。由于此链接来自国外，所以下载速度很慢。另一种选择是利用种子文件下载此操作系统。如果你没有种子下载程序，你可以下载“Transmission”。有了种子下载程序后，你可以通过 https://zooqle.com/ubuntu-gamepack-16-04-i386-amd64-январь-2017-pc-vkn99.html下载。这个种子文件下载可以下载 64 位和 32 位 的 ISO 镜像文件。

（下载的）文件大小取决于您需要的架构。64 位操作系统 ISO 镜像文件大小是 2.27 GB，而 32 位的操作系统 ISO 镜像文件大小是 2.13 GB。 如果下载了你所用的 ISO 镜像文件，你可以利 ISO 文件创建一个可启动的 DVD 安装 GamePack ，或者你可以使用 “USB Image Writer”把 ISO 写入到优盘，并利用此优盘安装系统。 硬件需求和 Ubuntu 16.04 保持一致：

• 2 GHz 双核处理器或者更高
• 2 GB 系统内存
• 25 GB 的磁盘空间
• 用于安装介质的 DVD 驱动器或者 USB 端口
• 在线游戏系统（如 Steam）需要互联网接入。

不用说，对于游戏玩家来说，肯定希望拥有比这些“最低配置”要求更高的系统配置。更多的内存将是一个有把握的选择，也应该有一款显存大一点的正统显卡。

您如果有了硬件系统和系统的特定 32位 或者 64 位 ISO 文件，那么接下来就可以安装操作系统了。

安装过程

当你用安装介质的 ISO 镜像文件启动了系统，您就可以准备进行下一步了。

从 Ubuntu Gamepack 介质启动，你会看到一个类似图 1 的屏幕。

图 1

一旦加载完毕，安装程序就可以继续安装了。图 2 显示下一屏，可以定制语言，接下来是安装或者体验 Gamepack。如果你愿意，你可以点击 “Try Ubuntu” 在不改变硬盘内容的情况下把它加载到内存中来试试它。

图 2

接下来继续选择 ‘Install Ubuntu’ 进行安装了。

下一个屏幕，如图 3 所示，你可以在安装 Ubuntu 时指定是否下载 Ubuntu 的任何更新。您还可以选择安装第三方的软件，如：图形、WiFi、Flash、 MP3 和其他更新。 当定制好你的系统后，就可以点击“Continue”

图 3

接下来，您必须指定驱动器将如何配置使用，如图 4 所示。如果您计划使用整个驱动器，那么可以更容易地设置，选择此驱动器即可，然后单击“Install Now”。

图 4

接下来在图 5 中可以根据提示确认所选择硬件配置。如果同意以上的更改，请单击“Continue”。

图 5

接下来，如图 6 所示，你将按照提示选择时区，选择完毕后点击“Continue”。

图 6

接下来，如图 7 所示一个窗口，需要您设置默认的键盘布局。选择适合您的正确的布局后并按“Continue”。

图 7

最后一个配置屏幕是为您设置一个用户帐户，如图 8 所示。键入您的姓名、计算机名、用户名、密码并选择您需要键入密码登录系统的方式。您还可以为该用户设置加密主目录。

图 8

安装将按指定来设置驱动器。安装文件将从引导媒体复制到硬盘驱动器，如图 9 所示。所有内容复制到硬盘并设置好，您将被提示移除引导介质并允许重新启动系统。

图 9

重新启动后，您需要选择要求用户登录，会得到类似于图 10 的屏幕。输入指定的用户密码登录到 Ubuntu Gamepack。

图 10

当你登录到 Ubuntu Gamepack 你应该尝试执行可能需要的软件升级。打开一个终端并输入以下两个命令：

sudo apt-get update && sudo apt-get upgrade

任何没有安装的更新都应该安装，以便 GamePack 系统保持更新。

现在，只要看看菜单，找到你想玩的游戏就行了，打开模拟器或其它像 Steam 的游戏服务 。

希望你喜欢 Gamepack 并且玩得高兴！

via: https://www.linux.org/threads/ubuntu-gamepack.4559/

作者：Jarret B 译者：stevenzdg988 校对：wxy

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

让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的几代 EXT 文件系统有何不同。

在之前关于 Linux 文件系统的文章里，我写过一篇 Linux 文件系统介绍 和一些更高级的概念例如 一切都是文件。现在我想要更深入地了解 EXT 文件系统的特性的详细内容，但是首先让我们来回答一个问题，“什么样才算是一个文件系统 ？” 一个文件系统应该涵盖以下所有特点：

1. 数据存储： 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个结构化的容器来存储和获取数据。
2. 命名空间： 命名空间是一个提供了用于命名与组织数据的命名规则和数据结构的方法学。
3. 安全模型： 一个用于定义访问权限的策略。
4. API： 操作这个系统的对象的系统功能调用，这些对象诸如目录和文件。
5. 实现： 能够实现以上几点的软件。

本文内容的讨论主要集中于上述几点中的第一项，并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。

EXT 文件系统历史

虽然 EXT 文件系统是为 Linux 编写的，但其真正起源于 Minix 操作系统和 Minix 文件系统，而 Minix 最早发布于 1987，早于 Linux 5 年。如果我们从 EXT 文件系统大家族的 Minix 起源来观察其历史与技术发展那么理解 EXT4 文件系统就会简单得多。

Minix

当 Linux Torvalds 在写最初的 Linux 内核的时候，他需要一个文件系统但是他又不想自己写一个。于是他简单地把 Minix 文件系统 加了进去，这个 Minix 文件系统是由 Andrew S. Tanenbaum 写的，同时它也是 Tanenbaum 的 Minix 操作系统的一部分。Minix 是一个类 Unix 风格的操作系统，最初编写它的原因是用于教育用途。Minix 的代码是自由可用的并有适当的许可协议，所以 Torvalds 可以把它用 Linux 的最初版本里。

Minix 有以下这些结构，其中的大部分位于生成文件系统的分区中：

• 引导扇区 是硬盘安装后的第一个扇区。这个引导块包含了一个非常小的引导记录和一个分区表。
• 每一个分区的第一个块都是一个包含了元数据的 超级块 （ superblock ） ，这些元数据定义了其他的文件系统结构并将其定位于物理硬盘的具体分区上。
• 一个 inode 位图块 决定了哪些 inode 是在使用中的，哪一些是未使用的。
• inode 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息，包括其所处的数据块的位置，也就是该文件所处的区域。
• 一个 区位图 用于保持追踪数据区域的使用和未使用情况。
• 一个 数据区, 这里是数据存储的地方。

对上述了两种位图类型来说，一个 位 （ bit ） 表示一个指定的数据区或者一个指定的 inode。 如果这个位是 0 则表示这个数据区或者这个 inode 是未使用的，如果是 1 则表示正在使用中。

那么，inode 又是什么呢 ? 就是 index-node（索引节点）的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。

同时，这个 inode 还包含了位置数据，指向了其所对应的文件数据在硬盘中的位置。在 Minix 和 EXT 1-3 文件系统中，这是一个数据区和块的列表。Minix 文件系统的 inode 支持 9 个数据块，包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 Minix 文件系统结构 。同时你也可以在维基百科上对 inode 指针结构 做一个快速了解。

EXT

原生的 EXT 文件系统 (意即 扩展的 （ extended ） ) 是由 Rémy Card 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），其也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被确证的，显然这是因为其存在着严重的问题，并且它很快地被 EXT2 文件系统取代了。

EXT2

EXT2 文件系统 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 5.0 时接触的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多供将来使用的磁盘空间。

和 Minix 类似，EXT2 也有一个引导扇区 ，它是硬盘安装后的第一个扇区。它包含了非常小的引导记录和一个分区表。接着引导扇区之后是一些保留的空间，它填充了引导记录和硬盘驱动器上的第一个分区（通常位于下一个柱面）之间的空间。GRUB2 - 也可能是 GRUB1 - 将此空间用于其部分引导代码。

每个 EXT2 分区中的空间被分为 柱面组 （ cylinder group ） ，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为 8MB。 下面的图 1 显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为 4K。

图 1： EXT 文件系统中的柱面组的结构

柱面组中的第一个块是一个 超级块 （ superblock ） ，它包含了元数据，定义了其它文件系统的结构并将其定位于物理硬盘的具体分区上。分区中有一些柱面组还会有备用超级块，但并不是所有的柱面组都有。我们可以使用例如 dd 等磁盘工具来拷贝备用超级块的内容到主超级块上，以达到修复损坏的超级块的目的。虽然这种情况不会经常发生，但是在几年前我的一个超级块损坏了，我就是用这种方法来修复的。幸好，我很有先见之明地使用了 dumpe2fs 命令来备份了我的系统上的分区描述符信息。

以下是 dumpe2fs 命令的一部分输出。这部分输出主要是超级块上包含的一些元数据，同时也是文件系统上的前两个柱面组的数据。

# dumpe2fs /dev/sda1
Filesystem volume name:   boot 
Last mounted on:          /boot 
Filesystem UUID:          79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 
Filesystem magic number:  0xEF53 
Filesystem revision #:    1 (dynamic) 
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize 
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl 
Filesystem state:         clean 
Errors behavior:          Continue 
Filesystem OS type:       Linux 
Inode count:              122160 
Block count:              488192 
Reserved block count:     24409 
Free blocks:              376512 
Free inodes:              121690 
First block:              0 
Block size:               4096 
Fragment size:            4096 
Group descriptor size:    64 
Reserved GDT blocks:      238 
Blocks per group:         32768 
Fragments per group:      32768 
Inodes per group:         8144 
Inode blocks per group:   509 
Flex block group size:    16 
Filesystem created:       Tue Feb  7 09:33:34 2017 
Last mount time:          Sat Apr 29 21:42:01 2017 
Last write time:          Sat Apr 29 21:42:01 2017 
Mount count:              25 
Maximum mount count:      -1 
Last checked:             Tue Feb  7 09:33:34 2017 
Check interval:           0 (<none>) 
Lifetime writes:          594 MB 
Reserved blocks uid:      0 (user root) 
Reserved blocks gid:      0 (group root) 
First inode:              11 
Inode size:               256 
Required extra isize:     32 
Desired extra isize:      32 
Journal inode:            8 
Default directory hash:   half_md4 
Directory Hash Seed:      c780bac9-d4bf-4f35-b695-0fe35e8d2d60 
Journal backup:           inode blocks 
Journal features:         journal_64bit 
Journal size:             32M 
Journal length:           8192 
Journal sequence:         0x00000213 
Journal start:            0 

Group 0: (Blocks 0-32767) 
 Primary superblock at 0, Group descriptors at 1-1 
 Reserved GDT blocks at 2-239 
 Block bitmap at 240 (+240) 
 Inode bitmap at 255 (+255) 
 Inode table at 270-778 (+270) 
 24839 free blocks, 7676 free inodes, 16 directories 
 Free blocks: 7929-32767 
 Free inodes: 440, 470-8144 
Group 1: (Blocks 32768-65535) 
 Backup superblock at 32768, Group descriptors at 32769-32769 
 Reserved GDT blocks at 32770-33007 
 Block bitmap at 241 (bg #0 + 241) 
 Inode bitmap at 256 (bg #0 + 256)
 Inode table at 779-1287 (bg #0 + 779) 
 8668 free blocks, 8142 free inodes, 2 directories 
 Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 
 Free inodes: 8147-16288 
Group 2: (Blocks 65536-98303) 
 Block bitmap at 242 (bg #0 + 242) 
 Inode bitmap at 257 (bg #0 + 257) 
 Inode table at 1288-1796 (bg #0 + 1288) 
 6326 free blocks, 8144 free inodes, 0 directories 
 Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 
 Free inodes: 16289-24432 
Group 3: (Blocks 98304-131071)

<截断>

每一个柱面组都有自己的 inode 位图，用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了一个文件的相关信息，包括属于该文件的数据块的位置。而块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，柱面组的数据可以多达数百页的长度。柱面组的元数据包括组中所有空闲数据块的列表。

EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。

我所遇见的关于 EXT2 文件系统最大的问题是 fsck (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有的不一致性，从而导致在系统 崩溃 （ crash ） 后其会花费了数个小时来修复。有一次我的其中一台电脑在崩溃后重新启动时共花费了 28 个小时恢复磁盘，而且并且是在磁盘被检测量只有几百兆字节大小的情况下。

EXT3

EXT3 文件系统是应一个目标而生的，就是克服 fsck 程序需要完全恢复在文件更新操作期间发生的不正确关机而损坏的磁盘结构所需的大量时间。它对 EXT 文件系统的唯一新增功能就是 日志，它将提前记录将对文件系统执行的更改。 EXT3 的磁盘结构的其余部分与 EXT2 中的相同。

除了同先前的版本一样直接写入数据到磁盘的数据区域外，EXT3 上的日志会将文件数据随同元数据写入到磁盘上的一个指定数据区域。一旦这些（日志）数据安全地到达硬盘，它就可以几乎零丢失率地被合并或被追加到目标文件上。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在日志中的所有数据提交之前，系统发生故障时文件系统将保持一致状态。在下次启动时，将检查文件系统的不一致性，然后将仍保留在日志中的数据提交到磁盘的数据区，以完成对目标文件的更新。

日志功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性、安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。

日志功能将失败后检查硬盘驱动器所需的时间从几小时（甚至几天）减少到了几分钟。 多年来，我遇到了很多导致我的系统崩溃的问题。要详细说的话恐怕还得再写一篇文章，但这里需要说明的是大多数是我自己造成的，就比如不小心踢掉电源插头。 幸运的是，EXT 日志文件系统将启动恢复时间缩短到两三分钟。此外，自从我开始使用带日志记录的 EXT3，我从来没有遇到丢失数据的问题。

EXT3 的日志功能可以关闭，然后其功能就等同于 EXT2 文件系统了。 该日志本身仍然是存在的，只是状态为空且未使用。 只需在 mount 命令中使用文件系统类型参数来重新挂载即可指定为 EXT2。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，不过你也可以更改 /etc/fstab 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3 文件系统挂载为 EXT2 ，因为这会有丢失数据和增加恢复时间的潜在可能性。

EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。

tune2fs -j /dev/sda1

/dev/sda1 表示驱动器和分区的标识符。同时要注意修改 /etc/fstab 中的文件系统类型标识符并重新挂载分区，或者重启系统以确保修改生效。

EXT4

EXT4 文件系统主要提高了性能、可靠性和容量。为了提高可靠性，它新增了元数据和日志校验和。同时为了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳，并在时间戳字段中添加了两个高位来延缓时间戳的 2038 年问题 ，这样 EXT4 文件系统至少可用到 2446 年。

在 EXT4 中，数据分配从固定块改为 扩展盘区 （ extent ） 方式，扩展盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理上连续的文件，这可以显著减少描述大文件中所有数据的位置所需的指针数。其它在 EXT4 中已经实施的分配策略可以进一步减少碎片化。

EXT4 通过将新创建的文件散布在磁盘上，使其不会像早期的 PC 文件系统一样全部聚集在磁盘起始位置，从而减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地散布文件，并且当文件（由于太大）需要分段存储时，使不连续的文件扩展盘区尽可能靠近同一文件中的其他部分，以尽可能减少磁头寻道和电机旋转等待时间。当创建新文件或扩展现有文件时，使用其它策略来预先分配额外的磁盘空间。这有助于确保扩展文件时不会自动导致其分段。新文件不会紧挨这现有文件立即分配空间，这也可以防止现有文件的碎片化。

除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集到所有正在写入磁盘的数据，这可以提高数据空间连续的可能性。

较旧的 EXT 文件系统（如 EXT2 和 EXT3）可以作为 EXT4 进行 mount ，以使其性能获得较小的提升。但不幸的是，这需要关闭 EXT4 的一些重要的新功能，所以我建议不要这样做。

自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。我们可以使用 Fedora 文档中描述的 流程 将 EXT3 文件系统升级到 EXT4，但是由于仍然存留的之前的 EXT3 元数据结构，它的性能仍将受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 mkfs 命令将空 EXT4 文件系统写入分区，然后从备份中恢复所有数据。

Inode

之前介绍过的 inode 是 EXT 文件系统中的元数据的关键组件。 图 2 显示了 inode 和存储在硬盘驱动器上的数据之间的关系。 该图是单个文件的目录和 inode，在这种情况下，可能会产生高度碎片化。 EXT 文件系统可以主动地减少碎片，所以不太可能会看到有这么多间接数据块或扩展盘区的文件。 实际上，你在下面将会看到，EXT 文件系统中的碎片非常低，所以大多数 inode 只使用一个或两个直接数据指针，而不使用间接指针。

图 2 ：inode 存储有关每个文件的信息，并使 EXT 文件系统能够查找属于它的所有数据。

inode 不包含文件的名称。通过目录项访问文件，目录项本身就是文件的名称，并包含指向 inode 的指针。该指针的值是 inode 号。文件系统中的每个 inode 都具有唯一的 ID 号，但同一台计算机上的其它文件系统（甚至是相同的硬盘驱动器）中的 inode 可以具有相同的 inode 号。这对 硬链接 存在影响，但是这个讨论超出了本文的范围。

inode 包含有关该文件的元数据，包括其类型和权限以及其大小。 inode 还包含 15 个指针的空位，用于描述柱面组数据部分中数据块或扩展盘区的位置和长度。12 个指针提供对数据扩展盘区的直接访问，应该足以满足大多数文件的需求。然而，对于具有明显分段的文件，需要以间接 节点 （ node ） 的形式提供一些额外的容量——从技术上讲，这些不是真正的“inode”，所以为了方便起见我在这里使用这个术语“ 节点 （ node ） ”。

间接节点是文件系统中的正常数据块，它仅用于描述数据而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节的间接节点，允许单个文件有 12（直接）+ 512（间接）= 524 个扩展盘区。还支持双重和三重间接节点，但我们大多数人不太可能遇到需要那么多扩展盘区的文件。

数据碎片

对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理本身就成为一个行业，有各种品牌的整理软件，其效果范围从非常有效到仅仅是微乎其微。

Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 fsck 命令检查整个文件系统的碎片。 以下示例检查我的主工作站的家目录，只有 1.5％ 的碎片。 确保使用 -n 参数，因为它会防止 fsck 对扫描的文件系统采取任何操作。

fsck -fn /dev/mapper/vg_01-home

我曾经进行过一些理论计算，以确定磁盘碎片整理是否会产生任何明显的性能提升。 我做了一些假设条件，我使用的磁盘性能数据来自一个新的 300GB 的西部数字硬盘驱动器，具有 2.0ms 的轨到轨寻道时间。 此示例中的文件数是我在计算的当天的文件系统中存在的实际数。 我假设每天有相当大量的碎片化文件（约 20％）会被用到。

表 1: 碎片对磁盘性能的理论影响

我对每天的全部的额外寻道时间进行了两次计算，一次是轨到轨寻道时间，这是由于 EXT 文件分配策略而导致大多数文件最可能的情况，一个是平均寻道时间，我假设这是一个合理的最坏情况。

从表 1 可以看出，对绝大多数应用程序而言，碎片化甚至对性能适中的硬盘驱动器上的现代 EXT 文件系统的影响是微乎其微的。您可以将您的环境中的数字插入到您自己的类似电子表格中，以了解你对性能影响的期望。这种类型的计算不一定能够代表实际的性能，但它可以提供一些对碎片化及其对系统的理论影响的洞察。

我的大部分分区的碎片率都在 1.5％ 左右或 1.6％，我有一个分区有 3.3％ 的碎片，但是这是一个大约 128GB 文件系统，具有不到 100 个非常大的 ISO 映像文件；多年来，我扩展过该分区几次，因为它已经太满了。

这并不是说一些应用的环境并不需要更少的碎片的环境。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以针对特定的工作负载类型调整参数。这个工作可以在文件系统创建的时候或稍后使用 tune2fs 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上混用文件系统类型以匹配每个文件系统上的不同负载是常见的。

由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。目前，EXT 文件系统没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片程度或文件系统中剩余可用空间的碎片程度。有一个工具，e4defrag，它可以对允许使用的剩余可用空间、目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。

如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件移动从而进行碎片整理，并在确保安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全去碎片化。

总结

EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和性能。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时我发现了它们适用于任何主流负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显需要使用其它文件系统的理由。

作者简介：

David Both - David Both 是一名 Linux 于开源的贡献者，目前居住在北卡罗莱纳州的罗利。他从事 IT 行业有 40 余年并在 IBM 中从事 OS/2 培训约 20 余年。在 IBM 就职期间，他在 1981 年为最早的 IBM PC 写了一个培训课程。他已经为红帽教授了 RHCE 课程，曾在 MCI Worldcom，思科和北卡罗来纳州工作。 他使用 Linux 和开源软件工作了近 20 年。

via: https://opensource.com/article/17/5/introduction-ext4-filesystem

作者：David Both 译者：chenxinlong 校对：wxy

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

在即将到来的嵌入式 Linux 会议 + OpenIoT 峰会中，Paul Sokolovsky 将会讨论在嵌入式开发中使用脚本语言的一些挑战。

脚本语言（又称作 超高级语言 Very High-Level Languages 或 VHLLs ），例如 Python、 PHP 以及 JavaScript 常用在桌面、服务器和网页开发中。它们强大的内置功能能够让你花费少量的时间和精力来开发小型却有用的应用，Paul Sokolovsky，Linaro 公司物联网工程师如是说。然而，目前在物联网中使用超高级语言深度开发嵌入式应用相对来说有些别扭。

在即将到来的嵌入式 Linux 会议 + OpenIoT 峰会中，Sokolovsky 会讨论在嵌入式开发中使用 VHLLs 的挑战并且基于 MicroPython 的例子与 JerryScript + Zephyr.js 项目比较不同的对策。 我们与Sokolovsky 进行了一番交谈来获得更多信息。

Linux.com：您可以给我们的读者一些 VHLLs 的背景知识吗？

Paul Sokolovsky: 超高级语言成为计算机科学和信息技术风景中的一部分已经几十年了。也许第一个流行的脚本语言是 Unix shell（sh），尽管由于较小的特征集，它很少被认为是一种超高级语言，而是一种特定领域语言。所以第一个真正破纪录的 VHLLs 是 Perl（1987）和 Tcl（1988），很快紧跟着出现了 Python（1991），Ruby（1995），PHP（1995），JavaScript（1995）以及许多其它语言。

不同 VHLLs 之间的区别特性包括：它们的解析本能（从使用者的角度来看，也许是因为其中复杂的编译器作祟），内置可用的强大的数据类型如任意大小的列表和映射，可观的标准库，以及允许用户访问甚至更大的第三方库的外部模块系统。所有的这些特性都与相对容易使用的感觉（更少的输入，不需要构建等）和简单的学习曲线相耦合。

Linux.com: 使用这些语言做开发有哪些优势？

Sokolovsky: 优势的根源来自于以上描述的这些特性。一个新手可以非常轻松的开始使用脚本语言并且快速的学习它。很多 VHLLs 提供了一个强大的交互模式，所以你不需要去读那些厚厚的使用手册来开始使用脚本语言，而是直接去探索和体验它们。强大的内置功能允许你去开发小而有用的应用（脚本），而仅仅使用很少的时间和精力（这就是“脚本语言”名字的来源）。如果要转向开发大型应用，广泛的第三方库和可以轻而易举使用的模块系统使得开发变得流畅和高产。

Linux.com: 在嵌入式平台上使用脚本开发和在其他平台开发有什么区别？

Sokolovsky: 鉴于之前我们讨论过的 VHLLs 振奋人心的能力，有一个创意——为什么我们不能享受使用 VHLLs 为嵌入式设备做开发而具有所有（或者至少一部分）优势呢？这里我提到的“嵌入式设备”不仅仅是拥有 8-32 MB RAM 的小型 Linux 系统，还有运行在微控制器（MCU）上有几千字节内存的深度嵌入式系统。少量（有些时候几乎没有）的相关资源肯定使这个创意的实现变得更加复杂。 另一个问题是设备访问和交互。嵌入式设备通常没有显示屏和键盘，但是幸运的是解决这个问题的答案已经存在几十年了，这里要感谢 Unix，它提供了使用串口（UART）来搭建一个终端连接的方法。当然，在主机端，有些用户喜欢使用图形集成开发环境（IDE）来隐藏串口通信细节。

所以，由于嵌入式设备所有的这些不同特性，这个创意就是提供一个尽可能熟悉的工作环境。但熟悉只是其中一方面，另一方面，为了适应甚至最小的设备，工作环境需要尽可能的缩小。要想解决这些矛盾需要嵌入式 VHLLs 的操作可以高度配置，来适应不同的项目和硬件的需求。

Linux.com：只有在物联网中使用这些语言才会遇到的挑战有哪些？比如说你如何处理内存限制？

Sokolovsky: 当然，解释程序本身几乎不怎么消耗硬件资源。但是在当今世界，最珍贵的资源是人类的时间。不管你是一个研发工程师、一个仅仅有几个小时的周末创客、一个被 bug 和安全问题淹没的支持工程师，或者一个计划开发新产品的产品经理——你手头上大概都没有什么多余时间。因此需要将 VHLLs 的生产力提供到嵌入式工程师手上。

当前的工艺水平使得这些需求变得可行。公正的来讲，甚至于微处理器单元（MCU）平均 都有 16-32 KB RAM ， 128-256 KB ROM。这仅仅足够搭载一个核心解释程序，一个标准库类型的规范子集，一些硬件驱动，以及一个很小但是依旧有用的应用程序。假如你的硬件配置稍微越过了中间线，其能力得到了快速的增长——这实际上是由于一个从 1970 年代就闻名的技巧：使用自定义的字节码和精码（pcode）相比原始机器代码能够让你获得更大的代码/特性密度。

在这条道路上有很多挑战，RAM 不够用是主要的一个。我是在一个 16 GB RAM 的笔记本上写下的这些话（但不断切换的话依然会很卡），而刚才提到的 16KB 比它小一百万倍！不过，通过小心的选择算法和编程技巧，在这样小的 RAM 下仍有可能通过脚本语言来执行简单程序，而相当复杂的程序可能需要 128-256K。

有很多的技术挑战需要解决（它们已经被成功的解决了），这里没有足够的篇幅来涵盖它们。不过，我在 OpenIoT 峰会上的演讲会涵盖使用两种嵌入式脚本语言的经验和成就：MicroPython（Python3 的子集）和 Zephyr.js（JavaScript/Node.js 的子集），都运行在 Linux 基金会的 Zephyr 实时操作系统上，它被寄希望于在 IoT 工业界取得和 Linux 在移动互联网和服务器方面一样的成就。（相关 PPT 会为无法参加 OpenIoT 会议的朋友在会议后放出。）

Linux.com: 你能给我们一些 VHLLs 最适用的应用的例子吗？以及一些它们不适用的例子？

Sokolovsky：以上是很多关于 VHLLs 的光明前景，公正的来说：在嵌入式开发中，这里有很多一厢情愿的幻想（或者说希望其是能够自我实现的预言）。在嵌入式开发中 VHLLs 现在可以提供的是：快速成型，以及教育/创客市场上所必须的易学性和易用性。有一些先行者在其它领域使用 VHLLs，但是就目前来看，它需要在基础构造和工具开发上投入更多。重要的是，这样的投入应遵循开源原则并分享，否则会逐渐损害到 VHLLs 能够节省使用者时间和精力的优势。

谨记这些，嵌入式 VHLLs 是发育完全（“逐渐变的完整”）的语言，能够适应各种类型的应用，但是要受制于硬件。例如，假如一个微处理器的规格低于之前提到的阈值，如一个老旧的 8-bit 微处理器，那么只有同样古老而优秀的 C 语言能够为你所用。另外一个限制是当你真的想要充分利用硬件时—— C 语言或者汇编程序才是正确的选择。但是，这里有一个惊喜——嵌入式 VHLLs 的开发者也想到了这一点，例如 MicroPython 允许你将 Python 和汇编程序在同一个应用中结合起来。

嵌入式 VHLLs 的优势是其可配置性和可（重复）编程性，外加灵活的连接性支持。这恰恰是 IoT 和智能设备最需要的，很多 IoT 应用使用起来也不需要太复杂。考虑一下，例如，一个可以贴在任何地方用来完成各种任务的智能按钮。但是，如果你需要调整双击的时间时怎么办？使用脚本语言，你可以做到。也许你完全不会考虑三连击，但是现在在某些情况下四连击都可能是有用的。使用脚本语言，你可以轻易修改它。

(题图：来自 Pixabay，基于 CC0 协议)

via: https://www.linux.com/news/event/elcna/2017/2/using-scripting-languages-iot-challenges-and-approaches

作者：AMBER ANKERHOLZ 译者：xiaow6 校对：wxy

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

Calibre 电子书管理软件可以轻松地在树莓派 3 上设置电子书服务器，即使在连接较慢区域也是如此。

最近 Calibre 3.0 发布了，它让用户能够在浏览器中阅读电子书！注意 Raspbian 的仓库还没有更新它（截至写作时）。

电子书是教师、图书馆员和其他人与学生共享书籍、课堂资料或其他文件的好方法，只需要你有可靠的带宽接入即可。但是，即使你的连接速度较慢或无法连接，还有一个简单的解决方案：使用在树莓派 3 上运行的开源 Calibre 电子书管理软件创建电子书服务器。这是我所做的，你也可以。

首先我下载了最新的 Raspbian Pixel 镜像，并安装在一个新的 8GB microSD 卡上。然后我插入 microSD，连接了键盘、鼠标并用一根 HDMI 线连接到一台旧的 LCD 电视，然后启动了 Pi。在我的显示器上调整了 Pixel 环境分辨率并连接到本地网络之后，我准备开始了。我打开一个终端，并输入 sudo apt-get update 以获取操作系统的最新更新。

接下来，我在终端中输入 sudo apt-get install calibre 来安装 Calibre。

我从命令行启动了 Calibre（注意它也可以从 GUI 启动）。Calibre 的界面非常直观。第一次启动时，你会看到 Welcome to Calibre 的向导。我将默认 “Calibre Library” 更改为 “CalibreLibrary”（一个词），因为这启动内容服务器时更容易。

在选择完我的 Calibre 内容位置后，我准备好开始下载书了。

我从菜单中选择了 Get Books 选项，在这很容易输入我的搜索字词，并选择我感兴趣的电子书提供者。我正在寻找非 DRM 的材料，所以我选择 Project Gutenberg 作为我的源。（Caliber 的免责声明指出，电子书交易是在你和个人内容提供商之间。）我在作者字段中输入 “Mark Twain”，并得到10个结果。

我选择了 Adventures of Huckleberry Finn 这本书。在下一页面上，我可以选择 MOBI 和 EPUB 这两种电子书格式。我选择了 EPUB，这本书下载得很快。

你也可以从其他内容提供商向库中添加图书，而不是在 Calibre 的列表中添加图书。例如，老师可以通过该内容服务器与学生分享电子书格式的开放教育资源。要加载内容，请使用界面最左侧的 “Add Books” 选项。

根据你图书库的大小，你也许需要增加 microSD 卡的大小。

将内容添加到电子书服务器后，即可与网络中的其他人共享内容。通过在终端中输入 ifconfig 获取你的树莓派 IP 地址。我正在使用无线网络，所以我在下面的例子中使用了 wlan0 中的结果。点击界面的最右侧并展开菜单。然后点击 “Connect and Share” 并启动服务器。

我下一步是通过我的电脑客户端连接到树莓派访问我添加的电子书。我在客户端上打开一个浏览器并输入树莓的地址，后面加上 :8080 端口。在我这里是 http://192.168.1.10:8080 （根据你 Pi 的地址来适配）。

你会在浏览器中看到主页：

我已经测试，并能用 iPhone、Linux、MacOS 计算机轻易连接到服务器。

你可以在这个主页总探索选项，或者点击 All Books 显示服务器上的所有内容。

从这里，你可以下载书到你的设备并离线阅读了。

你还没有设置一台电子书服务器么？或者你考虑自己设置一台么？在评论中分享你的建议或者问题。

作者简介：

Don Watkins - 教育家、教育技术专家、企业家、开源倡导者。教育心理学硕士、教育领导硕士、Linux 系统管理员、CCNA、使用 Virtual Box 虚拟化。关注我 @Don\_Watkins。

via: https://opensource.com/article/17/6/raspberrypi-ebook-server

作者：Don Watkins 译者：geekpi 校对：wxy

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

ART——为未来提供了一个平台的安卓运行时

安卓里没有多少组件的血统能追溯到 1.0 时代，但在 2014 年， Dalvik 这个驱动安卓应用的运行时是它们中的一员。Dalvik 最初是为单核、低端性能设备设计的，而且存储和内存占用的优先级要高于性能表现。在过去的几年里，谷歌给 Dalvik 扩充了越来越多的更新，比如 JIT 支持、并发垃圾回收，以及多进程支持。但是随着多核手机的出现，它们比 T-Mobile G1 快上很多倍，而这些功能升级扩充只能帮安卓到这里了。

解决方案就是用 ART 这个安卓运行时替换 Dalvik，这是一个完全为现代智能手机硬件重写的应用引擎。ART 更强调性能表现和用户界面流畅度。ART 带来了一个从 JIT（Just-in-time，即时）编译到 AOT（Ahead-of-time，提前）编译的转变。JIT 会在每次应用运行的时候即时编译，节省存储空间，因为编译后的代码从不写入存储，但它消耗更多的 CPU 和内存资源。AOT 会将编译后的代码保存到存储，让应用启动的时候更快并减少内存使用。ART 会在设备上将编译代码作为安装的一部分进行，而不分发预编译的代码，这样编译器可以进行一些针对特定设备的优化。ART 还带来了 64 位支持，扩大了内存寻址范围，由 64 位指令集带来更佳的性能表现（特别是在媒体和加密应用上）。

而最好的部分是这个变化将这些性能优化和 64 位支持带给了每个 java 安卓应用。ART 为每个 java 应用生成代码，因此任何对 ART 的改进都自动应用到了这些应用。同时 ART 也是在未来的升级计划下写就，所以它能够和安卓一同进化。

一个系统层级的界面刷新

Material Design 带来了一个几乎对安卓所有界面的完全翻新。首先，整个核心系统界面改变了。安卓得到了一个全新的按钮集合，看起来有点像是 PlayStation 的手柄：三角形，圆形以及正方形按钮，分别代表后退，主屏幕，和最近应用。得益于全新的图标集，状态栏也是焕然一新。

“最近应用”获得了大翻新。从一个小略缩图纵向列表变成了一个巨大的，几乎全屏的略缩图串联列表。它还获得了一个新名字（也没那么守旧），“ 概览 （ Overview ） ”。这明显是受到了前面版本的 Chrome 标签页切换器效果的启发。

顺带一说，在这个安卓版本里 Chrome 的标签页切换器效果消失了。作为一种将 Web 应用与本地应用同等对待的尝试，Chrome 标签合并到了概览列表。是的：最近“应用”列表现在显示的是最近打开的应用，加上最近打开的网站。在棒棒糖中，最近应用列表还采取了一种“以文档为中心”的方法，意味着应用可以在最近应用列表中显示多个项目。比如你在 Google Docs 中打开了两个文档，它们都会显示在最近应用中，让你可以在它们之间轻松切换，而不用到应用的文件列表去来回切换。

通知面板是全新的。谷歌给通知面板带来了“卡片”主题，将每个项目归整到它自己的矩形中。单个通知条目从黑色背景变成了白色背景，有了更佳的排版和圆形图标。这些新通知来到了锁屏上，将它从一个最没用的中间屏变成了很有用的屏幕，用于展示“这里是你不在的时候发生的事情”。

全屏的通知，比如来电以及闹钟，都被抛弃了，取而代之的是在屏幕顶部弹出一个“抬头（HUD）”通知。抬头通知也对“高优先级”应用可用，最初这是为即时消息设计的。但是否是高优先级的通知这取决于开发者的决定，在开发者意识到这可以让他们的通知更显眼之后，所有人都开始使用它。之后版本的安卓通过给用户提供“高优先级”的设置解决了这个问题。

谷歌还给棒棒糖添加了一个单独的，但很相似的“优先”通知系统。“优先”通知是一个介于完全静音和“提醒一切消息”之间的模式，允许用户将特定的联系人和应用标记为重要。优先模式只会为这些重要的人发出提醒。在界面上来看，它采用了音量控制附加通知优先级控制以及设置中心添加一项优先通知新设置的形式。当你处在优先模式的时候，状态栏会有一颗星形标识。

快速设置获得了一系列的大改善。控制项现在是一块在通知上面的面板，所以它可以通过“两次下拉”手势来打开它。第一次下拉会打开通知面板，第二次下拉手势会缩小通知面板并打开快速设置。快速设置的布局变了，抛弃了平铺排列，转为一个单独面板上的一系列浮动按钮。顶部是十分方便的亮度调节条，之后是连接，自动旋转，手电筒，GPS，以及 Chromecast 的按钮。

快速设置现在还有了实际的内嵌面板。它可以在主界面显示无线网络接入点，蓝牙设备，以及移动数据使用量。

Material Design 革新给了几乎每个应用一个新图标，并带来了一个更明亮，白色背景的应用抽屉。默认应用阵容也有了很大的变化。和这些新应用问声好吧：通讯录，谷歌文档，Fit，信息，照片，Play 报亭，以及谷歌幻灯片。和这些死去的应用说再见吧：相册，G+ 照片，People，Play 杂志，电子邮件，以及 Quickoffice。

这些新应用中很多来自 Google Drive，从一个单独的大应用分割成每个产品一个应用。现在我们有了云端硬盘，文档，表格，以及幻灯片，都来自于云端硬盘团队。云端硬盘同时也要对 Quickoffice 的死亡负责，云端硬盘团队令它元气大伤。在“谷歌从来没法做好决定”分类下：通讯录从“People”改回了“Contacts”，短信应用在运营商的要求下叫回了 “Messenger”。（那些运营商不喜欢谷歌环聊插手短信的职能。）我们有项真正的新服务：谷歌健身，一个健康追踪应用，可以在安卓手机和安卓手表上工作。Play 杂志也有了新的设计，添加了网站内容，所以它改名叫“Play 报亭”。

还有更多的谷歌专有应用接管 AOSP 的例子。

• “G+ 照片”变成了“谷歌照片”，并取代了 AOSP 的相册成为默认照片应用，而相册也就随之消亡了。改名成“谷歌照片”是为照片应用退出 Google+并成为独立服务做准备。谷歌照片的发布在棒棒糖发布之后六个月——暂时应用只像是 Google+ 应用换了个图标和界面设计。
• Gmail 从电子邮件应用接管了 POP3，IMAP 以及 Exchange 邮件的任务。尽管死掉的电子邮件应用还有个图标，但那是假的——它仅仅只显示一条信息，告诉用户从 Gmail 应用设置电子邮件账户。
• “People”到“Contacts”的变化实际上是变为谷歌通讯录，又是一个取代 AOSP 对应应用的例子。

Ron Amadeo / Ron 是 Ars Technica 的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。@RonAmadeo

via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/

作者：RON AMADEO 译者：alim0x 校对：wxy

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