每次都在八种 Linux 环境中验证的理由

在 Linux 上，只说“可以运行”是不够的。

即使是相同的 Ubuntu，系统库和工具包也会因版本而异。显示画面的方式分为 X11 和 Wayland，韩文输入法则使用 ibus 或 fcitx5。再加上安装方式，需要确认的组合很快就会增加。

在一台开发者电脑上成功运行，只意味着确认了无数组合中的一个。

所以我们在仓库里建立了一个小型实验室。针对每种环境启动真实的虚拟机，并重复进行相同的检查。结果汇总在一张表中。

表格检查的内容很简单。

应用能否启动。能否输入韩文。

也就是由我们先体验用户安装应用后会经历的最初三十秒。

我们把一个环境做成一个文件

实验室使用 KVM 虚拟机，而不是容器。因为容器很难正确复现真实的桌面会话和输入法守护进程。

下载发行版的云镜像，并通过 cloud-init 进行准备。磁盘以原始镜像为基础创建为叠加层。出现问题时可以丢弃并重新开始。

一个环境用一个文件来声明。文件中包含发行版、镜像、会话、输入法以及要安装的软件包。如果想确认新的组合，只需添加一个文件。

输入方式会因会话而异。在 X11 中使用 xdotool，在 Wayland 中使用 ydotool。Wayland 没有窗口列表，因此会让应用在 kiosk 合成器中以全屏方式运行。这样才能每次都在相同的位置进行输入。

应用只在宿主机上构建一次。然后将该二进制文件原样复制到所有虚拟机中。

如果在每种环境中重新构建，不同的编译器和库就会混入结果中。失败时也会更难找到原因。最重要的是，用户收到的文件和实验室检查的文件必须相同。

虚拟机负责检查，宿主机负责记录

在虚拟机内部会确认三件事。

检查二进制文件能否运行、窗口能否出现，以及输入 dkssud 时是否会显示 안녕。

每项检查都会留下一行 JSON。宿主机会汇总结果，将其保存为文件并生成表格。测得的结果会保留在仓库中，以便与下一次检查进行比较。

韩文输入的确认方法会因构建类型而异。在开发构建中，可以直接确认正在组合的文字。实际发布构建中没有这一功能。作为替代，会按下 Enter 并保存文件，然后读取写入磁盘的内容。

在这个过程中，我们学到了一件事。决定检查方法的不是安装方式，而是应用的构建类型。

第一张表告诉了我们两件事

在 Ubuntu 22.04 中，使用系统工具包构建的应用无法打开。因为找不到只有最新版 libadwaita 中才有的符号。

另一方面，我们也首次确认了在 Wayland 和 ibus 的组合中可以正常输入韩文。

基于这一结果，我们决定在所有安装方式中包含相同的工具包。现在这张有八行的表格，就是用来确认这一决定没有再次被破坏的安全装置。

还有一些问题只有在真实环境中才会出现。与桌面版 Ubuntu 不同，云镜像中没有 GTK4 输入模块或初始输入模式。必须在配置过程中另行安装。

ibus 模块必须与发行版中安装的守护进程版本匹配。不同发行版的输入工具使用方法也各不相同。因此必须根据环境拆分检查脚本。

为了节省宿主机的内存，最多只同时运行两台虚拟机。收到结果的虚拟机会立即关闭。

这些都是仅靠阅读代码很难发现的问题。因为即使是相同的代码，也会因环境而产生不同的结果。所以我们需要这张表。

表格不承诺性能

表格中也会记录首屏显示所需的时间和内存使用量。但不会将它们用作性能指标。

虚拟机在没有 GPU 的情况下通过软件绘制画面，并且只在启动后测量一次。每次运行时数值都可能不同。性能基准是在配备真实 GPU 的宿主机上测量三次后，以中位数确定的。

在这张表中要看的不是毫秒，而是勾选标记。

无法确认的环境会留为空白。Fedora 和 Debian、真实的 GNOME 会话，以及文件选择等门户对话框，目前还没有列入表格。

我们不会把未经确认的格子填写成“应该可以”。

用户会选择什么样的环境，不是我们能够决定的。我们能做的，是先进入那个环境，启动应用看一看。