Fedora Atomic Desktops 最容易被误读的时刻，往往发生在它们被包装成“不可变 Linux”时。更适合采用决策的理解方式窄一些，也更实用：它们让工作站的行为更接近一个部署目标。基础操作系统作为一张连贯镜像更新，图形应用转向 Flatpak，开发工具进入 Toolbx 或其他容器，主机级包改动从日常计算的默认形态，转为需要明确理由的例外。[1][2]

因此，这篇文章采取采用笔记的写法，避开宣传式语气。2026 年 7 月 8 日，Fedora 的 Atomic Desktops 页面把 Fedora 44 列为当前版本，并把 Silverblue、Kinoite、Sway Atomic、Budgie Atomic 与 COSMIC Atomic 放在同一个产品家族中呈现，而没有把它们收缩成一个只属于 GNOME 的实验。[1] 现实问题也已经从“我能启动它吗”转向“我的笔记本上，哪些部分应当视为基础 OS、应用层、开发工作区和本地覆盖”。

配图说明：封面采用 Fedora Magazine 提供的 Fedora 社区在 FOSDEM 的真实展台照片。它适合本文，因为基于镜像的工作站仍然是一项发行版工程：发布工程、打包政策、用户支持与贡献者反馈，共同决定这套技术模型能否保持日常可用。[9]

实际改变了什么

核心变化在默认写入路径上。机器仍可调整，只是默认落笔的位置变了。在 Fedora Silverblue 的公开定位里，更新会在下一次重启时生效，整个系统一次性更新，前一个版本会保留以便回滚，图形应用预期以 Flatpak 形式存在，开发工具则预期放在 Toolbx 容器中，而不是塞进主机包集合。[2]

这带来更清楚的运维切分。基础 OS 应当小、平实、可恢复。面向用户的桌面软件，应当在不改动主机的前提下更新。项目专用的编译器、语言运行时、SDK 和 CLI，应当放进可以重建或丢弃的容器。主机改动应当留给驱动、shell、VPN hooks、安全代理、输入法、内核模块，以及其他确实需要位于应用层和容器层之下的东西。[2][4]

如果一个团队采用 Fedora Atomic Desktops 后，又把过去用 dnf 安装的每个包都改成层叠安装，它基本上只是用新的更新命令复刻了旧工作站模型。迁移真正起效的地方，在于团队能够说清自己的边界。“浏览器是 Flatpak 或厂商包”，这是应用决策。“Go、Python、Node 和某个云 SDK 放在 Toolbx image 里”，这是开发决策。“这个智能卡守护进程或硬件驱动必须层叠进主机”，这是例外决策。

今天的 rpm-ostree 契约

当前 Fedora Atomic 桌面模型仍以 rpm-ostree 为基础。上游文档把它描述为一种混合的镜像/包系统：以 libostree 作为基础镜像格式，同时通过 Fedora 打包栈处理 RPM。[3] 对工作站采用而言，关键特性超过了 rollback 本身；它让包层叠仍然可行，同时让基础镜像保持一个有名称、连贯的部署。

管理员手册通过命令展示了这份契约。rpm-ostree status 显示可启动的部署。rpm-ostree upgrade 为下一次启动准备新部署。rpm-ostree rollback 切回前一个部署。rpm-ostree install <pkg> 创建一份带有层叠包的新部署，而这些层叠包会跨 upgrade、rebase 与 deploy 持续存在。[4]

这很有力，也正是漂移风险的主要来源。同一份手册说明，/usr 是只读的，/etc 和 /var 保持可写，其中 /var 会跨升级共享。[4] 这能避免基础镜像滑向可变包堆，却无法替团队补上模糊的策略。如果每个开发者都有一组不同的层叠包，调试“Fedora 工作站”就会变成调试十个私人变体。

实用规则很简单：层叠包应当像基础设施例外一样被审查。团队应当能回答，为什么某个包不能成为 Flatpak、Toolbx/Distrobox 依赖、dev-container 层，或项目本地二进制文件。如果答案只是“我们的旧笔记本脚本就是这么做的”，迁移还没有完成。

bootc 是方向，迁移不能压进一个周末

下一个重要信号是 bootc。bootc 项目把自己描述为使用 OCI/Docker container images 的事务性、就地操作系统更新，把容器层模型用于可启动的主机系统，而不是只用于应用。[5] 其文档也说明，CLI 和 API 现在已经被视为稳定，底层逻辑仍建立在 ostree 之上。[5]

对工作站运维者来说，吸引力很直接。基础 OS 可以被构建、测试、签名、推送到 registry，再用一套更接近容器交付的工具部署，而不是沿用经典包管理方式。LWN 面向工作站的独立文章同时捕捉了两面：bootc 能让已经使用容器工具的人更熟悉定制镜像交付，但构建定制桌面镜像仍是一项专家工作流，尤其在内核模块、registries 和部署机制进入讨论以后。[8]

Fedora 自己的路线图语言说明了为什么这应当作为分阶段迁移处理。Fedora Atomic Desktops SIG 路线图列出了尚未解决的工作，包括 rebase 到 Fedora bootc manifests 或 container images、图形更新器集成、本地包层叠、安装器与磁盘镜像工作、签名 container images、更新体积和文档。[7] 这类路线图语言并未把 bootc 排除在外；它说明试点需要有意安排。

因此，2026 年的采用姿态最好分成两条轨道。普通笔记本上，把 rpm-ostree Atomic Desktops 当作稳定运作模型。平台团队、课堂实验室、kiosk 式部署、可复现开发工作站和托管机群，则可以从一个 bootc 原型开始，前提是目标状态已经具有镜像形态。第一个试点应当回答一组朴素问题：Containerfile 放在哪里，谁批准镜像改动，哪个 registry 保存镜像，rollback 如何测试，主机 secrets 如何留在镜像之外，Secure Boot 或专有驱动改变启动路径时会发生什么。[5][7][8]

sealed-image 信号

Fedora 在 2026 年 4 月关于 sealed Atomic Desktop bootable container images 的说明，值得当作边界标记来读，而不是默认建议。文章宣布了测试镜像，并描述了方向：bootable containers、UKIs 与 composefs 协同工作，朝向一条经过验证的启动链。[6] 它对当前门槛也写得同样明确：这些镜像是 testing images，sshd 为调试而启用，root 账号没有设置密码，并且不应进入生产使用。[6]

这正是采用计划应当尊重的信号类型。sealed images 对托管端点、实验室、敏感开发机器，或者希望获得更强证据来确认已启动基础层与预期镜像一致的环境，具有意义。它不是随手给笔记本加上的调校项。讨论也会从“更新后能不能回滚”，移动到“我能不能验证自己原本想启动的基础系统”。

这同时带来治理问题，而不只是技术问题。锁定或验证过的基础层可以减少意外漂移，也会让确实需要本地控制权的用户感到受阻。Fedora sealed-image 文章下的评论串直接呈现了这类担忧，包括关于 Secure Boot 的问题，以及 sealed images 是否会成为强制项；维护者的回应表示，用户不需要使用 sealed images，也没有计划放弃当前分离 kernel 和 initramfs 的设置。[6] 工程团队在自己的 rollout 中也应当保留这一区分：验证是一项策略选择，不能直接等同于用户信任。

谁应当先迁移

最强的早期采用者，是已经被工作站漂移困扰的团队。一个支持十名开发者的小平台团队，如果机器本来就可替换，开发环境也已经容器化，对这套模型的需求会较低。一个规模更大的工程组织，如果同时面对受监管依赖、硬件差异、VPN 代理、安全工具，以及反复出现的“在我笔记本上能跑”故障，就更有理由认真评估。

Atomic Desktops 也适合能够接受基于重启的基础更新的人群。Fedora 对 Silverblue 和 Kinoite 的定位，是更新在下一次重启时生效，而不是实时改写正在运行的基础层。[2] 当可预测性重要时，这是特性。对于期待把主机当作持续编辑草稿本的人，这种模型会显得别扭。

失败模式很具体。贴近内核的软件仍会带来摩擦。第三方 repositories 需要层叠策略。Flatpak 覆盖范围与每个团队的应用清单并不完全重合。Toolbx 会把开发工具从基础层移走，但团队仍要约定 images、mounts、secrets 和项目 bootstrap scripts。rollback 保护的是基础部署；它不会自动回滚 /var 中的数据、用户文件，或已经接触状态的应用层迁移。[4]

一条实际迁移路径

从一个匹配用户桌面环境的 Atomic 变体开始，通常 GNOME 选 Silverblue，KDE Plasma 选 Kinoite。[1][2] 把它装在备用机器上，或装在可以替换的主力机器上，然后记录第一周出现的例外。每当有人想运行 rpm-ostree install，就强制归类：主机必要项、应用打包缺口、开发环境依赖，还是旧习惯。

保持一份短的主机基线。它应包括硬件启用、身份或 VPN hooks、安全代理、shell 层必要项，除此之外尽量少放。GUI 应用在可行时移到 Flatpak。编译器和项目工具移进 Toolbx、Distrobox、dev containers，或项目专用 container images。把 rpm-ostree status 当作审计表面：它应当讲出一个很短的故事，而不是暴露一座个人包档案馆。[4]

对考虑 bootc 的团队，把试点与日常笔记本 rollout 拆开。为一个受约束的用途构建一张 bootc image，例如实验室镜像或某一类托管开发工作站。测试 bootc upgrade 和 rollback 行为、镜像签名预期、registry 可用性、更新体积，以及镜像出错时的紧急路径。[5][8] 试点要发现组织是否具备发布纪律来拥有一张 OS image；每个开发者是否都该构建 OS image，并不是这里要证明的命题。

Fedora Atomic Desktops 的价值，在于它们让工作站状态变得可以讨论。基础 OS 是一层。应用是另一层。开发者工具又是一层。覆盖项是例外。bootc 指向的未来，是基础层可以带着容器原生习惯被构建和交付；这场迁移要保持健康，用户仍要知道控制权位于哪里。把笔记本视为部署目标，Fedora 的 atomic 模型就没有那么陌生：它是一种让操作系统别把每个本地决定都吸纳进去的方法。[1][3][5][8]

来源

1. Fedora Project，“Atomic Desktops for Fedora”——当前产品家族页面，列出 Fedora Atomic Desktop 变体，并把 Fedora 44 标为最新版本。
2. Fedora Project，“Fedora Silverblue”——产品页说明重启后生效的更新、全系统 atomic updates、rollback、Flatpak、Toolbx 与 rpm-ostree。
3. rpm-ostree documentation，“A true hybrid image/package system”——涵盖 libostree、RPM 集成、事务性升级、rollback、包层叠，以及主要新开发工作转向 bootc。
4. rpm-ostree documentation，“Client administration”——涵盖 status、upgrade、rollback、deploy、包层叠、overrides、usroverlay 与文件系统布局。
5. bootc documentation，“bootc” introduction——说明使用 OCI/Docker container images 的事务性就地 OS 更新，以及 CLI/API 的稳定状态。
6. Timothee Ravier，“Sealed Fedora Atomic Desktop bootable container images”，Fedora Magazine，2026 年 4 月 28 日。
7. Fedora Atomic Desktops SIG，“Roadmap to Fedora Bootable Containers”，GitLab work item。
8. Pavel Brezina，“Bootc for workstation use”，LWN.net，2025 年 11 月 7 日。
9. Bogomil Shopov，“Fedora Project at FOSDEM 2023”，Fedora Magazine，2023 年 1 月 20 日，Fedora 展台照片来源页，照片作者为 Francesco Crippa。