使用 Fedora Silverblue 进行合成器开发

# 使用 Fedora Silverblue 进行合成器开发 来源：https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/ 2026年6月5日 15:37 · 4049 词 · 20 分钟阅读 过去五年左右，我一直在桌面和笔记本电脑上使用 Fedora Silverblue (https://fedoraproject.org/atomic-desktops/silverblue/) 。Silverblue 是 Fedora 主要的原子化变体，是 Fedora Workstation 的精神对应物。我同时还开发 niri (https://github.com/YaLTeR/niri)，一个可滚动平铺的 Wayland 合成器。换句话说，这是一个核心系统组件，无法在容器或虚拟机中妥善测试——你确实希望它直接运行在宿主机上。那么，我为什么会选择...一个不可变发行版？这到底是怎么运作的？ [](https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/blur.png)Fedora Silverblue 经常出现在我的 niri 发布说明 (https://github.com/niri-wm/niri/releases) 截图中。 原子化发行版正逐渐流行起来。它们的主要卖点是可靠性：升级时不是就地修改文件，而是通过一次重启将旧系统整体替换为新系统。包冲突和其他错误会在组装新版本（在单独的文件夹中）时被发现，因此不会破坏你正在运行的系统。如果一次成功更新后出现了 Bug，原子化发行版让你可以简单地重启回旧版本，继续像什么都没发生一样使用。 "能够重启回旧版本"这个特性，一旦你意识到它甚至能跨大版本升级，就变得更加酷炫了！当下一个 Fedora Beta 版发布时，我只需将系统 rebase 到它上面来体验一下，如果有任何东西坏了，我只需重启回稳定的 Fedora（然后撤销 rebase）。 这就像学习源代码版本控制一样。每当你想摆弄操作系统时，心里负担大大减轻。你随时可以"回去"。 所以，现在有很多原子化发行版可供选择。有大量的 Fedora 原子化桌面 (https://fedoraproject.org/atomic-desktops/)，Endless OS (https://www.endlessglobal.com/foundation/access/operating-system)，面向游戏的 Bazzite (https://bazzite.gg/) 和其他 Universal Blue 镜像 (https://universal-blue.org/)。GNOME OS Nightly (https://os.gnome.org/) 是原子化的，驱动 Steam Deck 的 SteamOS (https://store.steampowered.com/steamos) 也是。其中许多是用 OSTree (https://ostreedev.github.io/ostree/) 构建的，它有点像"操作系统的 Git"。 但你可能要问：如果我开发这些操作系统二进制文件呢？原子化发行版不是不可变的吗？我该如何测试我的工作？ 事实证明，这根本不是问题！事实上，同样的技术让你在更新后可以"回去"，也能让你自由地修改宿主机系统，并在重启后安全地"回去"。我想说的是，由于这种能力，原子化发行版对系统组件开发者来说甚至比其他人更有优势，因为他们经常测试可能会破坏安装的更改。 那么，让我来展示一下我是如何在 Fedora Silverblue 上进行合成器开发的。我们将从大多数工作发生的地方——toolbox 开始，然后进入有趣的部分。 在你的不可变宿主机系统上，你需要一个可以安装开发环境的地方。Fedora Silverblue 预装了 Toolbox (https://containertoolbx.org/)，它正好提供了这个——在一个普通的、可变的 Fedora 容器中运行的终端，你可以在里面尽情地 `sudo dnf install`。 在底层，它只是一个 podman (https://podman.io/) 容器，自动挂载了宿主机上的大量内容：Wayland 套接字、网络、设备、D-Bus，以及让应用尽可能"开箱即用"所需的一切。你甚至可以通过 podman 命令与之交互： `` ┌ ~ └─ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6ceccce5581e registry.fedoraproject.org/fedora-toolbox:44 toolbox --log-lev... 2 months ago Up 41 minutes fedora-toolbox-44 `` 你的大部分开发工作都在这里完成。安装所有库、编译器、编辑器、LSP (https://microsoft.github.io/language-server-protocol/) 、调试器以及其它各种工具。由于所有这些都位于同一个容器中，它们可以相互通信并协同工作。 有一个稍微烦人的细节是：由于你完全配置好的编辑器在 toolbox 内部，你无法用它编辑仅在宿主机上才能访问的文件（例如 `/etc` 中的配置——toolbox 内部系统有自己的文件），但这在实践中小问题而已。Fedora Silverblue 附带 `nano`，能用；如果你经常需要编辑宿主机专属文件，你总可以用 `rpm-ostree install` 安装一个功能更丰富的编辑器。另一个烦人的问题是，目前 toolbox 阻止 SIGHUP 传递到应用 (https://github.com/containers/toolbox/issues/1400)，所以如果你运行你最喜欢的编辑器 (https://helix-editor.com/) 然后关闭终端窗口，它会愉快地在后台继续运行（连同它所有的 rust-analyzer (https://rust-analyzer.github.io/) 等，吃掉几个 GB 的内存）。 所以，在 toolbox 中运行东西对大多数开发来说完全没问题。CLI 工具可以正常运行，GUI 应用也可以正常运行，你可以在 toolbox 内部构建和安装库，并在同一个 toolbox 中的应用上测试它们。即使对于 Wayland 合成器，大多数也可以作为窗口运行（`gnome-shell --nested`，或者简单的 `sway` 或 `niri`），这足以测试大部分代码库。 此外，从 ~2023 年 (https://github.com/containers/toolbox/pull/997) 开始，toolbox 暴露了直接在 TTY 上运行合成器所需的一切。你可以用 Ctrl+Alt+F3 切换到另一个 VT，执行 `toolbox enter`，然后启动一个合成器，它就能正常工作。这样你可以直接测试不同的输入设备（触控板、数位板、触摸屏），测试显示器和 GPU 处理，进行适当的性能分析等。只需记住在 toolbox 内部安装一个终端和一些 GUI 应用，因为将宿主机上的应用启动到 toolbox 合成器中有点麻烦。 虽然 toolbox 在某种程度上是 Fedora 特有的，但对于其他情况，还有 distrobox (https://distrobox.it/)。它是一个独立的项目，但大体上有相同的理念——让你轻松地将不同的发行版安装为带有自动宿主机集成的 podman 容器。我主要用它来在 Arch (https://archlinux.org/) 上构建或测试东西，但我认为上面写的大部分内容也适用于 distrobox。 如果这还不够怎么办？比如，你在开发一个必须在宿主机上运行的组件，比如 NetworkManager 或 systemd。或者，你希望能够登录到你合成器的测试构建，以及完整的桌面会话的其余部分。让我们看看一个简单的方法。 ## 解锁宿主机＃(https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#unlocking-the-host) 运行 `sudo ostree admin unlock`，也称为 `rpm-ostree usroverlay`。¹ (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:1)² (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:2) 这将在 `/usr` 上挂载一个可变的覆盖文件系统，供你随意操作。该覆盖层将持续到下一次重启，届时你将回到一个干净的可用系统。 现在你可以简单地用 `sudo cp` 将你的开发构建拷贝到 `/usr/bin`，然后重启你正在测试的服务。 这也适用于库。例如，你想针对宿主机上安装的应用测试你在 GTK (https://gitlab.gnome.org/GNOME/gtk) 中的更改。³ (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:3) 在 toolbox 内构建它，然后将二进制文件拷贝到（解锁的）宿主机上，就可以了。二进制兼容性通常不是问题，因为 Silverblue 每天更新，并且与你在 toolbox 内构建时所依赖的常规 Fedora 非常接近。 然而，`sudo cp` 并不能替代真正的安装，而且你不能轻易地用于许多项目。所以，让我们在宿主机上获得一些合适的工具。 与普遍看法相反，在 Silverblue 中你可以安装包到宿主机上。这称为 layered 操作，是完全正常且受支持的操作，主要用于添加系统组件，例如终端、窗口管理器或 GPU 驱动。运行 `rpm-ostree install alacritty` 会导致 rpm-ostree 在每次更新时将此包安装（或 layered）到基础 Silverblue 镜像之上。重启后，你将拥有带有 Alacritty (https://alacritty.org/) 的 Fedora，就像你在常规的非原子系统上安装它一样。 如果改动足够小，运行 `sudo rpm-ostree apply-live` 可以让你跳过重启，新安装的程序立即可用。⁴ (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:4) 何时应该使用 layered（而不是安装在 toolbox 中）？Layered 更烦人且更慢，并且失去了丢弃 toolbox 以重新开始的优点。因此，我将 layered 限制为必须运行在宿主机上的程序，以及我经常需要在宿主机上使用的工具。 以下是我 layered 的包列表，在几个 Fedora 版本中基本保持不变： `` ┌ ~ └─ rpm-ostree status State: idle Deployments: fedora:fedora/42/x86_64/silverblue Version: 42.20250824.0 (2025-08-24T02:55:42Z) BaseCommit: d58dc92e5b05b6a95a0d9352edd864f1292c1883b9b32ac2e6f0af1a2263395a GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944 Diff: 12 upgraded RemovedBasePackages: firefox firefox-langpacks 142.0-1.fc42 LayeredPackages: alacritty distrobox dnf fastfetch fish foot fuzzel gamescope gdb gnome-console google-roboto-fonts htop hyprlock i3 kanshi labwc langpacks-ru lm_sensors lxqt-policykit mako nautilus-python netconsole-service niri perf quickshell-git rocminfo strace sway syncthing sysprof tmux trash-cli waybar wlsunset LocalPackages: edid-asus-1-1.fc34.noarch Initramfs: --include /etc/initramfs-overlay / `` 在此输出中，你可以找到： - 我用 `rpm-ostree override remove` 移除了 Firefox——我更喜欢来自 Flathub (https://flathub.org/apps/org.mozilla.firefox) 的官方构建。 - 终端（必须运行在宿主机上才能访问完整的宿主机文件系统⁵ (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:5)）：alacritty， foot， gnome-console。我首选的 shell：fish。经常需要的工具：tmux。 - 我希望无需 toolbox 即可运行的服务和工具：syncthing， distrobox， netconsole-service， trash-cli， htop， fastfetch， lm_sensors， rocminfo。 - 桌面组件：fuzzel， hyprlock， i3， kanshi， labwc， lxqt-policykit， mako， quickshell-git， sway， waybar， wlsunset。 - `edid-asus` 和 `initramfs-overlay` 在 AMDGPU 于内核 4.19 (https://bugzilla.kernel.org/show_bug.cgi?id=201497) 中搞坏它后，为我的一台显示器提供 EDID。⁶ (https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#fn:6) 除此之外，我还 layered 了一些开发工具：gdb， strace， perf， sysprof。这些工具在我需要调试或分析宿主机上运行的程序（或者在 Sysprof (https://gitlab.gnome.org/GNOME/sysprof) 的情况下进行全系统分析）时经常派上用场。 然后还有 dnf。什么？ ## Layering dnf＃(https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#layering-dnf) dnf，常规 Fedora 包管理器，出现在不可变的 Silverblue 宿主机系统上是干什么的？就其本身而言，它确实没什么用，因为它无法修改 `/usr`。（不过，它可以运行 `dnf copr enable`，这很方便。`rpm-ostree copr` 什么时候有？） 然而，宿主机上的 dnf 在与 `sudo ostree admin unlock` 结合时大放异彩。解锁后，你可以用 dnf 安装你当时需要的任何东西。这比 rpm-ostree 快得多，从来不需要重启，而且实际上重启后一切都会清理干净消失，因为所有东西都在一个临时的 `/usr` overlayfs 中。 示例工作流程： - `dnf debuginfo-install` 来调试/分析宿主机上的某些东西，使用符号进行崩溃报告等。 - `dnf install` 一些仅宿主机的程序来测试它。如果决定保留，再执行 `rpm-ostree install`。 - `dnf builddep gtk4`，然后直接在宿主机上构建并 `sudo ninja install` GTK 4，以针对宿主机应用进行测试。如果出问题，只需重启，你就回到了干净的工作状态。 解锁并 layered dnf 是一个非常强大的开发工作流程，以至于我几乎希望 dnf 默认包含在 Silverblue 中。不幸的是，这个工作流程也足够隐蔽，以至于 dnf 维护者前段时间意外地阻止了它的工作 (https://github.com/rpm-software-management/dnf/issues/2108) （谢天谢地，很快得到了纠正）。我理解让 dnf 明显可用的 UX 顾虑，因为它在这个特定工作流程之外无法工作，但也许 Silverblue 可以简单地将其隐藏，除非宿主机被解锁，或者重命名 dnf 二进制文件？ ## 持久解锁＃(https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#persistent-unlocking) 通常要持久地在宿主机上放置东西，你只需用 `rpm-ostree install` 进行 layered。然而，有时你想要的是一个*临时*更改，但*恰好也*跨重启*持久*。 这听起来很奇怪，但请考虑测试一个内核构建。你希望它是临时的并且易于回滚，但你总得重启进入新内核。而且你也不想花费额外时间构建和 layered .rpm 包。 对于这种情况，`ostree admin unlock` 提供了一个 `--hotfix` 标志。它会使临时覆盖层跨重启持久化，并且只会在你明确用 `rpm-ostree` 进行更改时重置。请注意，你永远不会失去重启回之前可用系统的能力。 ## 总结＃(https://bxt.rs/blog/using-fedora-silverblue-for-compositor-development/#summing-it-all-up) 所以，这就是我的开发工作流程。 - 大多数工作发生在一个全功能的 toolbox 中，我（喜欢但并非必须）在每个 Fedora 版本时重新安装它，以防止杂物堆积。这包括构建并在 TTY 上运行 niri。 - 完成更改后，我用 `sudo ostree admin unlock` 解锁宿主机，复制 niri 二进制文件，然后重新登录以在我的真实会话中测试它。重启后这将自动重置。 - 在处理长期分支时，我会构建一个进行中的 niri .rpm 包，并用 `rpm-ostree install` 进行 layered，以使新版本跨重启持久化。 - 当我想临时测试一些宿主机特定的东西并希望重启后自动重置时，我会在宿主机上使用 `dnf install`。 随着时间的推移，我做了几个小的生活质量调整，以平滑这个工作流程中的一些粗糙边缘。 例如，`toolbox enter` 有点啰嗦，而且总是把我丢进 *bash*。输入 `t`，我 `~/.local/bin/` 中的一个脚本，始终在 `$PATH` 中可用： `` #!/bin/bash if [ $# -eq 0 ]; then command=fish else command="$(printf "%q " "$@")" fi exec toolbox run -c fedora-toolbox-44 bash -ic "$command" `` 现在，输入 `t` 就直接把我放进 toolbox 并进入我亲爱的 fish (https://fishshell.com/) shell。输入 `` t some-program "with complex" arguments | grep "and stuff" `` 也能正常工作，得益于 `printf "%q "` 的正确参数传递。 这也适用于 .desktop 文件。例如，你在 toolbox 中安装了 VSCode，并得到了一个 .des