我们很高兴地宣布，第二次减少50%的Guix引导二进制文件现在已经正式发布了！
最初用来构建软件包的二进制文件集现在的重量约为60~MiB，是以前的四分之一。
在之前的一篇博文中，我们详细阐述了为什么这种缩减和自举能力在总体上是如此重要。一个原因是消除-或者大大减少-“信任”攻击的攻击面。去年夏天，在“打破比特币”大会上，董卡尔做了一个有趣而非常温和的介绍，在FOSDEM2020上我也做了一个简短的演讲。如果您选择相信从源开始构建是进行计算的正确方式，那么“信任信任”攻击只是不完整或缺少引导故事的表现。
去年，第一次减产移除了GCC、Glibc和Binutils二进制种子。新的进一步简化的二进制种子引导程序(Mergedin Guix Master)上个月删除了包含GNU Awk、Bash、Bzip2、GNU核心实用程序、grep、gzip、GNU make、Patch、sed、Tar和xz的“静态二进制文件tarball”，其中包含GNUAwk、Bash、Bzip2、GNU Core Utilities、grep、gzip、GNU make、Patch、sed、Tar和xz。它用Gash和GashCore实用程序取代了它们。Gash是用Guile Scheme编写的最简约的POSIX shell，而Gash Core Utilis是GNU和Coreutils中的大多数工具以及Awk、grep和sed中最重要的部分的一个Scheme实现。
经过三个带有大量MES C库更新和修复的新GNU MES版本、Gash的重大更新和第一个官方的Gash Utils版本，以及17个新的引导源包和版本的微妙平衡之后，包图形的底部现在看起来如下所示(Woohoo！)：
GCC-mesboot(4.9.4)^|(.)^|binutils-mesboot(2.14)，glibc-mesboot(2.2.5)，GCC-core-mesboot(2.95.3)^|bash-mesboot(2.05)，bzip2-mesboot，gawk-mesboot(3.0.0)disutils-mesboot(2.7)，patch-mesboot(2.5.9)，sed-mesboot(1.18)^|gnu-make-mesboot(3.82)^|gzip-mesboot(1.2.4)^|tcc-boot^|me-boot^|gash-boot，gash-utils-boot^|*bootstrap-mescc-tools，bootstrap-me(~12 MiB)bootstrap-guile(~48 MiB)。
可重复构建和可引导软件的概念并不是很新，其中大部分是在20世纪90年代初为GNU工具实现的。现在重新创建它的工作表明，许多实践已经被遗忘了。
熟悉GNU工具链的读者可能已经在这个伟大的新引导中注意到了*-mesboot源包的版本号：它们很古老了！这是个问题。
通常，工具链的较新版本修复了所有类型的错误，使软件更容易构建，并增加了对新CPU架构的支持，这很棒。然而-通常情况下-同时引入新特性或添加依赖项，这些对于引导来说不是必需的，并且可能增加引导障碍。有时，较新的工具更为严格，或者旧的配置脚本无法识别较新的工具版本。
GNU sed就是一个微不足道的例子。在当前的引导中，我们使用的是1993年发布的版本1.18。直到最近，我们希望引导的sed的最新版本是sed-4.2.2(2012)。Newer仅发布了XZ压缩的tarball格式，而XZ是出了名的难以引导(它需要一个相当新的GCC，并尝试在没有sed的情况下构建它)。
幸运的是，sed的维护者(Jim Meyering)很高兴纠正了这个错误，从sed-4.8(2020)版本开始，也将发布gzip压缩的tarball。GNU CoreUtils也是如此：2011到2019年间发布的版本很可能对引导毫无用处。面对这个信息，reutils的维护者(Pádraig Brady)也很高兴从现在开始以gzip压缩的形式发布coreutils-8.32。
即使是这些简单的案例也表明，解决引导问题只能一起完成：对于GNU来说，这确实是一个需要解决的项目范围的责任。
大多数引导问题或循环不是那么容易解决的，有时没有明显的答案，例如：
在2013年，也就是ReducibleBuilds开始取得一些进展的那一年，GNU编译器集合发布了edgcc-4.8.0，使C++成为构建要求，并且。
虽然从自举能力的角度来看，这些例子构成了一个令人愉快的谜团，但我们希望看到GNU软件的维护者考虑自举能力，并开始为他们软件包的自举故事承担更多的责任。
我们的下一个目标是第三次减少约50%；Full-Sourcebootstrap将使用Stage0和M2-Planet替换MesCC-Tools和GNU MES二进制文件。
Jeremy Orians的Stage0项目从大约512字节开始，几乎什么都没有。如果你还没有这样做，那就来看看这个令人难以置信的项目吧。
我们非常感谢和激动NlnetFoundation再次决定赞助这项工作！
虽然简化的引导程序目前只适用于i686-linux和x86_64-linux架构，但我们很高兴ARM很快就会加入进来。可信的ARM引导工作进展顺利，GNU mes现在已经在本机ARMv7上通过了整个mescc测试套件，并且几乎通过了本机ARMv7上的整个GCC测试套件。使用GNU MES编译TCC工作正在进行中。添加第二个体系结构对于创建通用引导是非常重要的！
即将发布的GASH和GASH-Utils将允许我们清理包图的底部并删除许多“老式”包，特别是下一版本的Gash-Utils将足够复杂，只使用旧版本的GNU make和Gzip就可以构建到GCC-mesboot。这在很大程度上要归功于对Awk实现的改进，它现在几乎包括了所有的标准功能。
展望更远的未来，我们很可能不得不去掉GCC-2.95.3的“古董”，这是安德烈直接为GCC-4.6.4做的一个很有帮助的垫脚石。有趣的时刻在前方！
当软件不依赖于不能从源代码构建的二进制种子时，软件是可引导的。不可引导的软件-即使它是自由软件-出于各种原因是一个严重的安全风险。可引导构建项目旨在将二进制种子的数量和大小减少到最低限度。
GNU MES与Bootstrapable Builds项目密切相关。MES的目标是为Guix系统和其他感兴趣的GNU/Linux发行版创建一个完全基于源代码的引导路径。我们的目标是从最小的、易于检查的二进制文件(应该是可读的源代码)开始，然后引导到接近R6RS方案的地方。
目前，MES由互助式自托管模式解释器和C编译器组成。它还实现了一个C库。模式解释器MES是用SIMPLE C.MesCC的大约5000行代码编写的，C编译器是用SCHEMA编写的。MES和MesCC可以一起编译一个自托管的打了轻量级补丁的TinyCC。使用此TinyCC和MES C库，可以引导i686-Linux和x86_64-Linux的整个Guix系统。
GNU Guix是一个事务性的包管理器，是GNU系统的高级发行版，可以在任何运行内核Linux的系统上使用，也可以作为i686、x86_64、ARMv7和AArch64机器的独立操作系统发行版使用。
除了标准的包管理功能外，Guix还支持事务升级和回滚、非特权包管理、按用户配置文件和垃圾收集。当作为一个独立的GNU/Linux发行版使用时，Guix提供了一种声明性的、无状态的操作系统配置管理方法。通过Guile编程接口和对Scheme语言的扩展，GUI是高度可定制和可破解的。