ARM 上的 Outline：选哪个构建版本，谁来维护？

ARM64 标签解决了一个兼容性问题，却留下三个更难的问题。它没有说明谁生成了可执行文件、它来自哪次源码修订，也没有说明谁会发布下一个安全修复。当一条旧的论坛回答指向某个社区构建时，正是这些问题决定这次安装是否站得住脚。在下载任何东西之前，先把它们分开。

管理器还是客户端：先选对产物

Outline 提供用于管理服务器的管理器，以及用于连接设备的客户端，二者是彼此独立的应用。上游仓库区分这两种角色，并分别链接到各自的安装渠道。在 Raspberry Pi 上安装管理器，并不会让你得到适用于那台 Pi 的客户端。这两个渠道的更新节奏也不同。两种角色都存在，所以问题在于这台设备该扮演哪一种。

请检查你所运行操作系统的当前客户端渠道。通用的 Linux 条目不是一张架构矩阵，也不是对每块板子的承诺。把下载页面当作现有之物的清单来读，而不是应有之物的清单。

一个要求 ARM 支持的历史问题，说明不了今天发布了什么。把它当作过去缺口的记录，而不是关于现在的声明。你能下载的那个渠道，才是唯一算数的证据。

已安装的系统实际运行哪种架构？

记录版本和受审查的产物，而不只是板子的名称。把可执行文件及其原生组件与目标匹配起来，因为 64 位内核可以运行 32 位用户空间，而包装盒上的标签不会告诉你到底是哪一种。

客户端源码包含共享的界面代码和平台专属组件。只重新构建界面不算平台移植，无论它编译得多干净。原生部分才是架构真正显现的地方。只改动界面的重新构建会跑起来，却仍会在原生一侧失败。

uname -m以及已安装系统的软件包架构，是这里重要的两个事实。要在设备上读取它们，而不是在你用来构建的机器上。这一步对不上，之后所有比较都会失效。

社区构建多了一位发布负责人

如果官方渠道没有适用于你的目标的受支持产物，社区构建就变成一项部署决策，而不是安装。确认发布者、源码修订、相对上游的改动以及构建说明。

然后问：未来的修复如何到达这次安装。更新可能来自上游、来自分支，也可能来自一次需要有人记得去执行的重新构建。第三种选项正是会悄悄停止发生的那一种。

一个看起来还在维护的仓库，说明不了你手上那个二进制文件出自哪次修订。把构建说明与产物自述的内容对照一下。如果两者不一致，该被怀疑的是产物。

校验和能证明什么，不能证明什么

校验和标识的是特定的字节。由同一个非官方构建者发布的校验和，并不会让该构建者变成上游项目，也不会告诉你那些字节里有什么。它回答的是下载是否完整到达，这是一个有用但范围很窄的问题。那是文件本身的属性，而不是发布者的属性。

一张成功启动的截图，只是一台机器上的证据。它不是对二进制文件或其更新渠道的审查。这两样东西都替代不了阅读源码。

在来源和所需权限经过审查之前，把不熟悉的构建挡在生产秘密之外。先在一个用后即弃的环境里运行它，并使用它自己的账户。这很便宜，而且能把一个观点变成一次测试。

判断这是实验品还是设备

管理员可以刻意针对受支持的目标构建经过审查的源码，并承担依赖、打包和更新的责任。这与安装一个受维护的上游产物是两种不同的支持模式。对于无人看管的设备，要选负责的拥有者能长期维持的那种模式。

把产物标识、平台、验证结果和更新负责人记录在部署旁边。当这些彼此一致时，决策才算完成，而不是当某个 ARM 二进制文件启动过一次的时候。