LWN：不可变发行版的另一条路！

关注了就能看到更多这么棒的文章哦～

Daroc Alden
 Gemini translation
 原文链接：https://lwn.net/Articles/1054216/ 

近年来，LWN 刊登了许多关于不可变发行版（immutable distributions）的文章，例如 Bluefin 和 Bazzite。这些发行版采用了多种方法，包括使用 rpm-ostree、文件系统快照以及可引导容器（bootable container，简称 bootc）镜像。但这些方法，特别是后者，会导致用户在尝试安装新软件时面临额外的复杂性，而不能像往常一样直接使用现有的软件包管理器。AshOS（Any Snapshot Hierarchical OS）是一个实验性的、采用 AGPL-3 许可的元发行版（meta-distribution），它尝试了一种更符合传统软件包管理模式的不同方法。尽管该项目已不再更新，但它仍然可以使用，并且对于那些担心采用基于 bootc 方法的用户来说，它依然能为潜在的替代路径提供一些启发。 

不可变发行版之所以具有吸引力，有几个原因。更新可以原子化（atomic）地应用和回滚，这可能是最主要的原因；此外，它们还使得通过少量配置文件重现相应的安装变得更加容易。不可变性意味着对配置的更改被清晰地分离了出来，因此很容易查看一个长期运行的不可变系统是如何被修改的，并根据这些更改重现一个新系统。问题一如既往：这些好处是否值得付出 A/B 更新带来的磁盘占用、任何自定义镜像的构建时间、复杂性以及不便。AshOS 试图通过将不可变性添加到现有发行版中，同时保持现有发行版的软件包管理器处于控制地位，来改变这种权衡。 

为了实现这一目标，AshOS 创建并管理根文件系统（包括已安装的软件和配置文件，但不包括用户的家目录）的快照。这些快照可以相互叠加，从而使软件包管理操作可以被分离并命名（类似于系统扩展（systemd-sysext）镜像）。例如，用户可能为一个基础操作系统安装分配一个快照，为他们的图形用户环境分配另一个快照，为他们的邮件服务器分配第三个快照。为了尝试新软件或配置更改，他们会在现有快照之上创建一个新的快照来工作。在那个快照中，他们可以使用发行版正常的软件包管理器来安装软件。如果事实证明这产生了糟糕的后果，他们可以删除最新的快照并返回到之前的（正常运行的）配置。 

其他不可变发行版确实提供了类似的功能。例如，基于 Fedora Silverblue 的发行版可以使用 rpm-ostree 在基础镜像之上叠加软件包。但与直接使用 dnf 相比，这样做充满了棘手的边缘情况——例如，如果基础镜像更新后包含了一个之前叠加安装的软件包，那么使用 rpm-ostree 移除现有的叠加层将会非常困难。 

尝试一下

这是一个迷人的想法。我已经使用 Silverblue 一年多了，发现它确实有些麻烦，以至于 AshOS 承诺的简化具有很大的诱惑力。遗憾的是，AshOS 正处于开源项目“可用但仍需一番折腾”的阶段。推荐的安装过程是获取一个你首选发行版的 live ISO，用它来下载 AshOS 源码并配置磁盘分区，然后运行 AshOS 的设置脚本。AshOS 试图在不同发行版之间保持可移植性，但它仍然包含少量特定于发行版的代码（以方便安装并在快照之间生成智能差异）。目前支持的发行版有 Alpine、Arch、CachyOS、Debian、Endeavourous、Fedora、Kicksecure、Proxmox 和 Ubuntu——尽管文档暗示 Gentoo 也可以工作，其他与受支持发行版类似的系统也可能可行。 

我下载了 Arch 的 2026.01.01 live ISO 镜像，并在虚拟机中进行了安装。我尝试了几次才成功：AshOS 并没有特别强制要求你以合理的方式设置分区表，但它必须准确地知道每个分区的用途，以便正确设置快照。我第一次尝试时，最终得到了一个无法启动的系统。最终，我成功地将我选择的磁盘布局与 AshOS 的理解匹配到了分区表上，情况才开始变得顺利。 

安装程序是基于文本的，有些简陋，但并不特别复杂。在解决了困难的分区相关问题后，它会询问常见的细节，如用户名、密码和时区。完成后，它会从宿主操作系统（在我的例子中是 Arch）安装一个最小软件包集，并指示用户重启。在默认的安装配置中，它在根磁盘上使用 Btrfs 来创建快照，但文档建议，如果愿意尝试，也可以让它在其他文件系统上工作。 

默认情况下，AshOS 除了登录文本控制台所需的最低限度外，不安装任何其他东西。它确实能够安装一些“配置文件”（profiles）：即设置常见桌面环境的特殊命令。我创建了一个新快照，然后安装了 GNOME 配置文件。重启后，得到了一个极简但功能齐全的 Arch 安装。从那时起，我尝试了使用提供的命令行工具（ash）来添加、克隆、删除和更新快照，发现这个过程比安装过程要直观得多。 

AshOS 以树状结构管理快照，从基础操作系统安装开始。树的任何分支都可以在引导菜单中选择。因此，例如，可以在一组共享软件之上安装两个不同的桌面环境（也许是为了测试）。更常见的是，可以复制现有的配置（使用 AshOS 的树操作命令），尝试升级或修改，并且仍然能够轻松切换回来。每一层都被赋予一个 ID 号和一个（可选的）具有人类可读意义的描述，这两者都会显示在引导菜单中，以及在命令行操作快照树时显示。 

ash branch –snap N 命令可以用来从快照 N 创建分支；这会打印出新快照的 ID M。然后 ash chroot M 将在这个快照中生成一个新的 shell，在其中可以使用常规工具进行更改，例如 pacman -Sy firefox（pacman 有点晦涩的安装命令）或 vim /etc/resolv.conf。退出 shell 时，ash 会保存更改并更新树中快照的版本。还有一个 ash live-chroot 命令，可以在当前运行的快照以可写方式挂载的情况下打开一个 shell，以防需要直接折腾而不想先创建一个单独的快照。 

还有一些辅助命令用于在整个子树的每个快照上运行命令。例如，可以在树中某个点下方的所有快照上运行软件包管理器的更新命令。 

配置

AshOS 的快照管理显然使其符合不可变元发行版的定义，但与创建自定义可引导容器相比，纯快照方法的一个弱点是配置管理：一旦系统设置完成，你如何准确地知道更改了什么，以及如何在其他地方重现相同的设置？ 

这就是 AshOS 大部分特定于发行版代码的用武之地。AshOS 为每个受支持的软件包管理器提供了一组挂钩（hooks），用于列出已安装的软件包并将文件归属于它们。ash diff 命令使用这些挂钩来生成快照之间的差异。这些差异显示了添加了哪些软件包以及更改了哪些配置文件。虽然这与从容器描述构建操作系统镜像的可复现性（reproducibility）水平不完全相同，但只要记得为每个快照分配有意义的描述，它似乎是一种足够清晰的跟踪操作系统更改的方式。 

总的来说，AshOS 还比较粗糙。命令行工具虽然看起来很可靠，但语法略有不统一。安装过程非常繁杂，文档有点乱，而且最后的开发发生在两年多前。该项目的创建者和唯一的贡献者“i2”似乎已经失去了兴趣。尽管如此，它确实可以工作——而且可以说比 Fedora Silverblue 等传统的不可变桌面运行得更顺畅。它证明了在不放弃传统软件包管理或转向以容器为中心的方法的情况下，拥有不可变性的优点（原子升级和回滚、配置管理）是可能的。AshOS 所做的一切，对于具备一些脚本知识和支持快照的文件系统的人来说并非遥不可及，尽管它在将这些操作封装到单个工具方面做得很好。 

AshOS 目前仅适用于那些不介意依赖实验性的、无人维护的软件的人。但组织和叠加文件系统快照以将传统 Linux 系统转变为不可变系统的核心原则似乎完全正确。也许这种方法可以为那些正在苦于应对可引导容器缺点的人们提供一个有用的折衷方案——或者激励这些系统的开发人员改进安装额外软件包的用户界面。 

LWN 评论概述：

这篇文章探讨了 AshOS 这种基于快照的不可变发行版方案，引发了关于系统灵活性与可维护性的讨论。评论者指出，在 Arch Linux 上测试可能是因为该发行版在 AshOS 文档中最为常用，并分析了快照层级间的读取机制。此外，讨论中还提到了 NixOS 这种日益流行的替代方案，甚至有消息称丹麦政府正考虑将其作为公务员计算机的基础发行版。 

欢迎分享、转载及基于现有协议再创作～