Using Fedora Silverblue for Compositor Development
Using Fedora Silverblue for Compositor Development
使用 Fedora Silverblue 进行合成器开发
I’ve been using Fedora Silverblue on my desktop and laptop for the past, what, five years? Silverblue is Fedora’s main atomic variant, a spiritual counterpart to Fedora Workstation. I also make niri, a scrollable-tiling Wayland compositor. In other words, a core system component that you cannot properly test from inside a container or VM—you really want it directly on the host. So, why would I choose an… immutable distro? How does that even work? 过去五年左右,我一直都在台式机和笔记本电脑上使用 Fedora Silverblue。Silverblue 是 Fedora 的主要原子化(atomic)变体,也是 Fedora Workstation 的精神对应版本。我还开发了 niri,这是一个可滚动的平铺式 Wayland 合成器。换句话说,它是一个核心系统组件,你无法在容器或虚拟机中对其进行妥善测试——你必须将其直接运行在宿主机上。那么,我为什么要选择一个……不可变发行版呢?这到底是怎么运作的?
Fedora Silverblue makes a frequent occurrence in my niri release notes screenshots. Atomic distributions have been slowly rising in popularity. Their main selling point is reliability: upgrades work by swapping the old system for the new one in one go across a reboot, rather than modifying the files in-place. Package conflicts and other errors are caught at the time of assembling the new version (in a separate folder), and therefore cannot break your running system. Fedora Silverblue 经常出现在我 niri 的发行说明截图中。原子化发行版正逐渐流行起来。它们的主要卖点是可靠性:升级过程是通过重启时一次性将旧系统替换为新系统来实现的,而不是原地修改文件。软件包冲突和其他错误会在组装新版本(在单独的文件夹中)时被捕获,因此不会破坏你当前运行的系统。
And if a successful update turns out buggy, atomic distros let you simply reboot back into the old version and keep using it as if nothing happened. This “being able to reboot back” thing becomes even cooler once you realize that it works even across major distro upgrades! When the next Fedora Beta rolls around, I can just rebase my system on top of it to kick the tires, and if anything is broken, I can simply reboot back to stable Fedora (and then undo the rebase). This is like learning about source code version control. A big weight off your mind any time you want to mess around with your OS. You can just go back. 如果一次成功的更新出现了 Bug,原子化发行版允许你简单地重启回旧版本,并像什么都没发生一样继续使用。当你意识到这种“重启回退”功能甚至适用于跨大版本升级时,它就变得更酷了!当下一个 Fedora Beta 版本发布时,我可以将其作为基础重新部署(rebase)我的系统来尝鲜,如果出现问题,我可以简单地重启回稳定的 Fedora(然后撤销重新部署)。这就像学习源代码版本控制一样。每当你想要折腾操作系统时,这都会让你卸下心理负担。你随时可以回退。
So, by now there are plenty of atomic distributions to choose from. There’s a whole host of Fedora atomic desktops, Endless OS, the gaming-focused Bazzite and other Universal Blue images. GNOME OS Nightly is atomic, as well as SteamOS powering the Steam Deck. Many of these are built with OSTree which is something of a “git for operating system binaries”. But, you may ask. What if I develop these operating system binaries? Aren’t atomic distros immutable and all, how do I test my work? 目前,有很多原子化发行版可供选择。包括各种 Fedora 原子化桌面、Endless OS、专注于游戏的 Bazzite 以及其他 Universal Blue 镜像。GNOME OS Nightly 是原子化的,为 Steam Deck 提供动力的 SteamOS 也是如此。其中许多是基于 OSTree 构建的,这可以被看作是“操作系统二进制文件的 git”。但是,你可能会问:如果我开发这些操作系统二进制文件怎么办?原子化发行版不是不可变的吗,我该如何测试我的工作?
Turns out, this is not a problem at all! In fact, the same tech that lets you go back after an update can also let you freely tinker with your host system and safely go back after a reboot. I’d say that thanks to this ability, atomic distributions provide even more benefit for system component developers than for others, given that they’re constantly testing changes that may break their install. So, let me show you how I do compositor development on Fedora Silverblue. We’ll start with toolbox where most of the work happens, then proceed to the fun stuff. 事实证明,这根本不是问题!事实上,让你在更新后能够回退的同一项技术,同样能让你自由地折腾宿主机系统,并在重启后安全地恢复。我认为,得益于这种能力,原子化发行版对系统组件开发者来说比其他人更有优势,因为他们需要不断测试可能破坏安装环境的更改。那么,让我来展示一下我是如何在 Fedora Silverblue 上进行合成器开发的。我们将从大部分工作所在的 toolbox 开始,然后再进入有趣的部分。
Toolbox
Toolbox
On your immutable host system, you need a place where you can install the development environment. Fedora Silverblue comes pre-installed with Toolbox, which provides just that—a terminal in a normal, mutable Fedora where you can sudo dnf install to your heart’s content. Under the hood, it’s just a podman container with a whole range of things auto-mounted from the host: the Wayland socket, networking, devices, D-Bus, and everything else needed for apps to “just work” as much as possible from inside the container.
在不可变的宿主机系统上,你需要一个可以安装开发环境的地方。Fedora Silverblue 预装了 Toolbox,它正好提供了这一点——一个在普通、可变 Fedora 环境下的终端,你可以在其中随心所欲地使用 sudo dnf install。在底层,它只是一个 podman 容器,自动挂载了宿主机的各种资源:Wayland 套接字、网络、设备、D-Bus 以及应用程序在容器内尽可能“正常工作”所需的一切。
You can even interact with it through podman commands: 你甚至可以通过 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
Most of your development work happens here. Install all the libraries, compilers, editors, LSPs, debuggers, and the rest of the kitchen sink. Since all of this resides inside the same container, it can all talk to each other and work together. One slightly annoying detail is that since your fully-configured editor is inside the toolbox, you can’t use it to edit files accessible only on the host (e.g. configs in /etc—the system inside the toolbox has its own files there), but that is honestly a fairly minor problem in practice. 大部分开发工作都在这里进行。安装所有的库、编译器、编辑器、LSP、调试器以及其他所有需要的工具。由于所有这些都驻留在同一个容器内,它们可以相互通信并协同工作。一个稍微令人烦恼的细节是,由于你配置完善的编辑器位于 toolbox 内部,你无法用它编辑仅在宿主机上可访问的文件(例如 /etc 中的配置——toolbox 内部的系统有其自己的一套文件),但在实践中,这老实说是一个相当小的问题。
Fedora Silverblue comes with nano, which works, and if editing host-only files is a frequent occurrence for you, you can always rpm-ostree install a more featureful editor. Another annoying problem is that currently, toolbox prevents SIGHUP from reaching apps, so if you run your favorite editor then close the terminal window, it will happily keep running in the background (along with all its rust-analyzers and such, eating several gigabytes of RAM).
Fedora Silverblue 自带 nano,它完全够用。如果你经常需要编辑仅限宿主机的文件,你总是可以使用 rpm-ostree install 安装一个功能更强大的编辑器。另一个令人烦恼的问题是,目前 toolbox 会阻止 SIGHUP 信号到达应用程序,所以如果你运行了你喜欢的编辑器然后关闭了终端窗口,它会愉快地在后台继续运行(连同它所有的 rust-analyzer 等进程,吃掉好几 GB 的内存)。
So, running things in a toolbox works perfectly well for most development. CLI tools will run fine, GUI apps will run fine, you can build and install libraries inside the toolbox and test them on apps inside the same toolbox. Even with Wayland compositors, most of them can run as a window (gnome-shell —nested, or simply sway or niri), which is enough to test the majority of the code base.
因此,在 toolbox 中运行程序对于大多数开发工作来说效果非常好。CLI 工具可以正常运行,GUI 应用程序也可以正常运行,你可以在 toolbox 内构建和安装库,并在同一个 toolbox 内的应用程序上进行测试。即使是 Wayland 合成器,大多数也可以作为窗口运行(gnome-shell --nested,或者简单的 sway 或 niri),这足以测试大部分代码库。
Moreover, since ~2023, toolbox exposes everything necessary to run compositors on a TTY directly. You can switch to a different VT with CtrlAltF3, toolbox enter, then start a compositor, and it will work as is. This way you can test different input devices directly (trackpad, tablet, touchscreen), test monitor and GPU handling, do proper performance profiling, and so on. Just remember to install a terminal and some GUI apps inside the toolbox because launching the host ones into a toolbox compositor is a bit annoying. 此外,自 2023 年左右起,toolbox 暴露了在 TTY 上直接运行合成器所需的一切。你可以使用 Ctrl+Alt+F3 切换到不同的虚拟终端(VT),进入 toolbox,然后启动合成器,它就能直接运行。通过这种方式,你可以直接测试不同的输入设备(触控板、数位板、触摸屏)、测试显示器和 GPU 处理、进行适当的性能分析等等。只需记得在 toolbox 内安装一个终端和一些 GUI 应用程序,因为在 toolbox 合成器中启动宿主机的程序会有点麻烦。
While toolbox is somewhat Fedora-specific, for everything else there’s distrobox. It’s a separate project, but by and large has the same idea—let you easily install different distros as podman containers with automatic host integration. I mainly use it to build or test things on Arch, but I imagine most of what I wrote above works just as well with distrobox. What if this isn’t enough, though? Say, you’re working on a component like NetworkManager or systemd that must run on the host system. Or, you want to be able to log in to a test build of your compositor along with the rest of the full desktop session. Let’s… 虽然 toolbox 在某种程度上是 Fedora 特有的,但对于其他需求,还有 distrobox。它是一个独立的项目,但大体上有着相同的理念——让你能够轻松地将不同的发行版安装为 podman 容器,并实现自动的宿主机集成。我主要用它在 Arch 上构建或测试东西,但我相信我上面写的大部分内容在 distrobox 上同样适用。不过,如果这些还不够呢?比如,你正在开发像 NetworkManager 或 systemd 这样必须在宿主机系统上运行的组件。或者,你希望能够登录到你合成器的测试版本,并同时运行完整的桌面会话。让我们……