Flatpak 不是未来

admin 管理员组

文章数量: 887021

原文日期：2021-11-18
最后更新：2021-11-23
Ref: https://ludocode/blog/flatpak-is-not-the-future

为 Linux 桌面部署应用程序很困难。历史上的一个主要问题是库兼容性。不同的 Linux 发行版，甚至同一发行版的不同版本，都有不兼容的库。不幸的是，Linux 桌面上并不总是存在向后兼容的文化。

这终于改变了。近年来，Linux 桌面的稳定性有了显着提高。核心库开发人员终于看到了保持兼容性的好处。尽管如此，许多开发人员对依赖稳定的二进制软件库库并不感兴趣。相反，他们决定忽略和覆盖几乎所有预安装在用户系统上的库。

当前的解决方案涉及在容器化环境中打包整个备用运行时。Flatpak、Snap、AppImage、Docker和Steam：这些都提供了一种应用程序打包机制，可以替换大部分或全部系统运行时库，现在它们都使用容器化来实现这一点。

Flatpak 称自己为“应用程序分发的未来”。我不是粉丝。我将在这里概述 Flatpak 和其他一些技术、安全和可用性问题。我会尽量避免解决“可修复”的问题（如主题），而是专注于设计中固有的基本问题。我的目标是让你相信这些不是桌面 Linux 应用程序的未来。

尺寸

假设您想制作一个简单的计算器应用程序。下载量应该有多大？

在撰写本文时，最新的KCalc AppImage（如果您甚至能弄清楚如何下载它）是 152 MB。对于计算器。

计算器应用程序 KCalc 的屏幕截图。

从表面上看，这与 Windows 没有竞争力。如果我发布适用于 Windows 的应用程序，则不必在我的应用程序中包含整个 Win32 或 .NET 运行时。我只是使用用户系统上已有的东西。

Flatpak 或 Steam 等其他解决方案单独下载运行时。您的应用程序元数据指定了它想要使用的运行时，服务会下载它并针对它运行您的应用程序。

那么这些运行时有多大呢？在新机器上，从 Flathub安装KCalc。您正在查看近 900 MB 的下载量以获得您的第一个运行时。对于计算器。

        ID                                      Branch    Op   Remote    Download
 1.     org.freedesktop.Platform.GL.default     20.08     i    flathub   < 106.4 MB
 2.     org.freedesktop.Platform.VAAPI.Intel    20.08     i    flathub    < 11.6 MB
 3.     org.freedesktop.Platform.openh264       2.0       i    flathub     < 1.5 MB
 4.     org.kde.KStyle.Adwaita                  5.15      i    flathub     < 6.6 MB
 5.     org.kde.Platform.Locale                 5.15      i    flathub   < 341.4 MB (partial)
 6.     org.kde.Platform                        5.15      i    flathub   < 370.1 MB
 7.     org.kde.kcalc.Locale                    stable    i    flathub   < 423.1 kB (partial)
 8.     org.kde.kcalc                           stable    i    flathub     < 4.4 MB

请注意，应用程序包本身只有 4.4 MB。其余的是我系统上已经存在的所有冗余库。我只是kcalc直接从未沙箱的 Flatpak 安装路径中运行二进制文件，让它使用我的本机库。它运行得很好，因为它使用的所有库都是向后兼容的。

Flatpak 想要下载 3D 驱动程序、获得专利的视频编解码器、主题、语言环境、Qt 5、KDE 5、GTK 3、ICU、LLVM、ffmpeg、Python 以及org.kde.Platform. 因为与 AppImage 不同的是，运行时并没有被精简到应用程序所需要的。它具有任何应用程序的所有依赖项。它是您现有操作系统之上的一个完整的通用操作系统。

共享运行时？

Flatpak 说这是为了让应用程序可以共享运行时。但他们的运行时系统的重点是让应用程序使用不同的运行时。运行时的每个分支（例如，代表 Ubuntu 的不同基础版本）都是一个完全独立的运行时映像。

他们声称他们对运行时进行了重复数据删除。我质疑重新编译所有内容后，不同分支之间真正可以共享多少。/usrUbuntu 版本之间有多少变化？我大概猜到了所有这些。

至少 Steam 的票价要好一些。士兵运行时是一个 610 MB 的下载，仍然很大。但是 Steam 只发布几个官方运行时，所以大多数游戏确实共享运行时。

Flatpak 允许任何人定义自己的运行时。freedesktop 发布了一些常用的Flatpak 运行时，但这些不一定是应用程序正在使用的。例如，Fedora 发布具有自己的运行时的应用程序，这些是其软件商店中默认可用的应用程序。

如果您在 Fedora 34 的软件商店中安装 GIMP，则默认为 Fedora 的 GIMP 的 Flatpak。这会引入 Fedora 35 的 650 MB 运行时，而不是任何 freedesktop 运行时。我们之前从 Flathub 安装的 freedesktop 运行时 KCalc 不会共享任何内容。在我的机器/var/lib/flatpak上，仅这两个应用程序就使用了超过 3 GB 的磁盘空间。

这显然按预期工作。他们希望运行时是免费的，为每个应用程序填满您的硬盘驱动器。我无法想象，当您有几十个应用程序存储数十 GB 的运行时，并且都希望保持最新时，系统更新会是什么样的。

“磁盘空间很便宜！”

他们说磁盘空间很便宜。这不是真的，不适用于现代计算机的根设备。内置存储实际上一直在缩小。

软件变得越来越慢，越来越臃肿，以至于操作系统不再能在旋转锈蚀上运行。笔记本电脑制造商正在转向更小的闪存驱动器以提高性能，同时保持利润。2015 年左右的廉价笔记本电脑配备 256 GB 或更大的机械驱动器。现在在 2021 年，它们配备了 120 GB 闪存。NVMe 驱动器的价格约为 100 美元/TB，笔记本电脑制造商将这些价格抬高了 500% 或更多，因此升级新笔记本电脑可能会很昂贵。

Chromebook 更小，因为它们将所有内容都推送到云存储中。智能手机开始运行成熟的 Linux 发行版。该树莓派4和400使用SD卡作为根设备，有如此神奇的表现，我们是在低成本计算革命的边缘。当然，Flatpak 应该可以在这些系统上使用！没有理由说明 16 GB 根设备不适合我们可能想要的所有可能的非游戏软件。Flatpak 不是革命的一部分；它在阻止它。

为什么存储不应该收缩？软件应该变得更高效，而不是更低。即使带宽是免费的并且硬盘驱动器长在树上，也不能原谅如此严重的膨胀。这些应用程序打包解决方案所涉及的浪费是彻头彻尾的冒犯。阿波罗以 4 kB 的 RAM 和 72 kB 的 ROM 登陆月球，但我们无法运行小于 150 MB 的计算器。任何称职的工程师都应该优化效率，而不是认为它无关紧要，尤其是当它如此明显地影响用户体验时。

内存使用，启动时间

巨大的备用运行时间的代价不仅仅是存储和带宽。

每个具有新运行时的应用程序都会增加一百兆或更多的 RAM 使用量。这加起来很快。大多数计算机没有足够的 RAM 来运行所有具有备用运行时的应用程序。Raspberry Pi 400 只有 4 GB 的 RAM。低端 Chromebook 只有 2 GB。预算笔记本电脑往往有 8 GB，这主要归功于 Windows 10 的膨胀，但这些应用程序打包解决方案正在迎头赶上。

一个更大的问题是这些应用程序实际上可能需要几秒钟才能启动。他们必须从磁盘加载他们自己的所有库，而不是使用系统上已经存在的、已经在内存中的库。

Snap 是最慢的，主要是因为它将所有数据存储在 squashfs 图像中。Snap 会在启动时挂载所有已注册的 snap，而不仅仅是事先提取它们需要的元数据，这可能是为了缓解这种缓慢的情况。它们只是将缓慢启动时间的一部分移到计算机的启动时间。各种乱七八糟的东西现在都出现在mount和 中fdisk -l。您安装的快照越多，即使您不使用它们，您的计算机启动速度也会越慢。

今天，在我的机器上，KCalc Snap 需要整整七秒钟才能启动。不仅仅是开机后的第一次；每一次，都没有失败。七秒启动计算器。

Canonical 开始将他们的基本桌面应用程序（如 GNOME 计算器）转换为 Ubuntu 18.04 中的 Snap。用户体验非常糟糕，以至于他们悄悄地将它们转换回Ubuntu 20.04 中的普通应用程序。如果这些技术甚至对他们自己的应用程序都不够好，那些像计算器这样基本的应用程序，为什么它们对你的应用程序足够好？

驱动程序

替代运行时的一个主要问题是驱动程序。新的图形硬件需要具有大量依赖项的新图形库。Mesa 依赖 LLVM 来编译着色器。NVidia 驱动程序依赖于内核模块，其版本必须与库的版本完全匹配。所有这些库都有自己的传递依赖项，如 libdrm、libstdc++ 和 glibc。如果你想让新硬件工作，你需要使用所有这些库的新版本。

Linux 发行版，尤其是那些带有滚动发行版或硬件支持包的发行版，在使这些库为新硬件保持最新方面做得很好。捆绑的运行时没有。

看看Steam 为让驱动程序在 Steam 运行时工作所经历的痛苦。他们使用各种启发式方法来确定是否在运行时用主机系统的库覆盖每个库，因此每个应用程序都运行在一个 Frankenstein 库的大杂烩上。这不是构建稳定软件的方法。

Flatpak 认识到将库与主机系统混合是一团糟。相反，他们希望在运行时中捆绑他们自己的图形驱动程序，让它们定期更新以适应新硬件。但是他们无法控制最重要的部分，即内核，因此他们无法直接打包依赖于特定内核版本或专有内核模块的驱动程序。因此，运行时被分解为扩展，并且扩展可以走 Steam 拉入本机驱动程序的路线，甚至可以即时下载特定的 NVidia 驱动程序以匹配内核模块。

AppImage 也将主机库与运行时混合，但不是动态混合的；他们只是在打包时决定排除什么，所以它比 Steam 更不可靠。Docker 有一个 NVidia 工具包，它必须安装在主机系统和容器化运行时才能使驱动程序正常工作。Snap 在做什么，谁知道呢。这些都不是正确的解决方案。

驱动程序应该是操作系统的责任。这是它擅长的。为什么我们如此努力地绕过操作系统默认为原生应用程序提供的内容？

顺便说一下，这不是视频游戏特有的问题。许多现代应用程序现在直接使用硬件加速图形，甚至终端和文本编辑器。许多应用程序需要 GPU 进行后台计算。视频编辑器等生产力应用程序、使用机器学习的应用程序、空间/天文可视化等科学工具，以及 Google 地球等任何 3D 功能……所有这些都需要访问现代视频硬件。这只会随着应用程序变得更快并提供更多功能和更丰富的用户界面而增长。

安全

Flatpak 允许应用程序声明他们需要完全访问您的文件系统或您的主文件夹，但图形软件商店仍然声称此类应用程序是沙盒的。这个之前已经讨论过了。当我在全新安装的 Fedora 34 上的软件应用程序中搜索 GIMP 时，会发生以下情况：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-meYbKMsj-1637677518727)(https://ludocode/assets/blog/flatpak-gimp-sandboxed.png)]Fedora 声称 GIMP 是沙盒的。如果单击“权限”旁边的“高”，您会看到一个小感叹号，表示它具有“文件系统”权限。

这样的应用程序可以将恶意软件可执行文件放置在您的主文件夹中的任何位置，并在您~/.profile或桌面条目中添加一行，~/.config/autostart/使其在您下次登录时自动启动。它不仅会在任何容器之外运行，甚至会在应用卸载后持续存在。

这正是恶意应用程序为摆脱沙箱所做的事情。这也是病毒利用沙盒应用程序中的安全漏洞所做的事情。

假设 libjpeg 有一个零日远程代码执行漏洞。您在 Flatpak GIMP 中打开一个看似无害的 JPEG，它会将其有效负载设置为自动启动到您的主文件夹中。沙箱在这里有什么帮助？无论 GIMP 是否被沙盒化，该病毒的行为都是相同的。唯一的区别是 a) 备用运行时中的 libjpeg 可能比 Linux 发行版中的 libjpeg 过时时间更长；b) 该病毒更有可能对沙盒应用程序起作用，因为所有安装都将使用完全相同的 libjpeg 二进制文件。

值得称赞的是，Snap Store 应用程序显示了一条警告：“此应用程序不受限制。它可以访问所有个人文件和系统资源。” 您会问哪些应用程序会显示此警告？他们都。KCalc 有。所有的编辑精选都有它。在我对这篇博文的测试中，我找不到不显示警告的应用程序。

“有总比没有好！”

Flatpak 和 Snap 的辩护者声称，安全总比没有好。这不是真的。从纯粹的技术角度来看，对于具有文件系统访问权限的应用程序来说，安全性完全等于零。实际上，这实际上比没有更糟糕，因为它使人们对他们在互联网上找到的随机应用程序产生了比应有的更多信任。

看看这位作者一边抱怨 AppImages 的安全性一边称赞 Flatpak 和 Snap：

我通过 source、apt、Snap 和 Flatpak 安装应用程序——我不歧视。只要应用程序按预期安装和运行，我就会安装它，而不管包格式如何。

除了一个例外：AppImages。

[…]

在极少数情况下，我愿意使用 AppImage，只有在我绝对信任开发人员时才会这样做。为什么？请记住，AppImage 是您只需下载并运行的应用程序。任何人都可以构建一个 AppImage，宣称它是必备软件，将一些邪恶的东西放入其中，并使其可供下载。

他对 AppImages 表达了深深的怀疑，但对 Flatpaks 或 Snaps 不持怀疑态度，因为他相信他们的安全措施可以保证他的安全。这就是在沙箱问题上撒谎的危险。

权限和门户

Flatpak 正在开发一个细粒度的权限系统，以提高其沙箱的安全性。权限是指是否允许应用访问麦克风或打印机。门户就像在沙箱外运行的文件打开对话框一样，因此沙箱中的应用程序仅获取用户选择的文件。

Flatpak 记录了这些门户并提供libportal，这是一个访问它们的客户端库。然而，这并不是真正适用于单个应用程序。这一切都意味着要集成到工具包中。从文档：

像 GTK3 和 Qt5 这样的接口工具包实现了对门户的透明支持，这意味着应用程序不需要做任何额外的工作来使用它们（值得检查每个工具包支持哪些门户）。

显然，为应用程序本身开发客户端 API 与 Flatpak 的使命背道而驰。他们希望在 Flatpak 上运行的应用程序不知道 Flatpak。他们宁愿修改像 GTK 这样的核心库来与 Flatpak 集成。例如，如果你想打开一个文件，你不需要调用 Flatpak API 函数来获取文件或请求权限。相反，您调用一个普通的 GTK 文件打开对话框，并且您的 Flatpak 运行时的 GTK 在内部与 Flatpak 服务进行门户交互（使用各种技巧让您“正常”访问文件并假装您没有被沙盒化。）

这是实现这一点的最复杂和最脆弱的方法。这也完全不是其他沙盒平台的工作方式。如果我想要在 Android 上获得文件访问权限，我不会只是尝试使用 Java File API 打开文件并期望它神奇地提示用户。我必须先调用Android 特定的 API 来请求权限。iOS也是一样。那么为什么我不能flatpak_request_permission(PERMISSION)在用户批准或拒绝时打电话并获得回电呢？

这就是为什么。Fedora 正在将他们所有的 rpm 应用程序自动转换为 Flatpak。为了使其工作，他们需要 Flatpak 权限系统和 Flatpak 通常不需要任何应用程序更改。

他们究竟为什么要对应用程序进行大规模自动转换？你的猜测和我的一样好。该视频声称 Fedora 的应用程序质量高于上游，并且 Fedora 在较旧的发行版上提供他们的 Flatpaks。我认为他们更有可能只是想要大量自动转换的应用程序，以使其看起来像 Flatpak 很有用。不管是什么原因，很明显，这个要求影响了他们许多糟糕的设计决策。

标识符冲突

因此 Fedora 会自动将其所有应用程序转换为 Flatpak。它是否至少将它们命名为特定于 Fedora 的东西？

不，它没有。Fedora 将其 GIMP 的 Flatpak 发布为org.gimp.GIMP. 这与org.gimp.GIMPGIMP 开发人员在 Flathub 上发布的官方信息相冲突。在全新安装的 Fedora 34 中，如果添加 Flathub 存储库并键入flatpak install org.gimp.GIMP，则会提示您安装哪个：

[nick@fedora active]$ flatpak install org.gimp.GIMP
Looking for matches…
Remotes found with refs similar to ‘org.gimp.GIMP’:

   1) ‘fedora’ (system)
   2) ‘flathub’ (system)

Which do you want to use (0 to abort)? [0-2]:

如果您选择选项 1，您将获得带有 Fedora 补丁的 GIMP 构建，该补丁使用 650 MB Fedora 35 运行时。如果您选择选项 2，您将获得使用 1.8 GB freedesktop GNOME 运行时的 GIMP 的不同版本。

不是反向 DNS的全部意义在于org.gimp前缀是为实际拥有gimp域的人保留的吗？Fedora 如何在伪装成上游开发者的同时证明发布应用程序的合理性？如果主要的 Linux 发行版甚至不尊重 DNS，谁会呢？

顺便说一下，Flathub 也不强制执行 DNS 所有权。他们让任何人发表任何东西；他们只是更喜欢应用程序由他们的作者控制。一个合理的安全策略是要求 DNS 质询以允许发布者使用特定的应用程序前缀。

复杂

关于简单性在软件设计中的重要性的文章层出不穷。越差越好也许是最早的例子。现代格言是“软件复杂性正在扼杀我们”。2021 年的软件开发状况非常悲惨。

如果它们想吸引软件开发人员，您会认为这些打包机制会采用简单性。事实上，他们正在做相反的事情。我们讨论的驱动程序、沙盒和许可/门户问题几乎没有触及使这一切正常工作所涉及的复杂性的表面。用“更糟更好”的说法，它们甚至不再是“正确的事情”。在这一点上，他们只是为了自己的利益而推动复杂性。

容器化的支持者认为它是解决所有问题的方法，是钉钉子的锤子。我们现在有多个基于容器化一切的 Linux 发行版（例如 Fedora CoreOS、MocaccinoOS。）我们有一个重大的运动来采用嵌入式 Docker 和 Snap（例如 balenaOS、Ubuntu Core。）Docker 可能很快就会在你的冰箱和你的汽车上运行.

继续观看之前链接的视频以了解疯狂的下降：Steam 嵌套在 Flatpak 中；嵌套在士兵运行时中的 Scout 运行时从 Freedesktop 运行时拉取驱动程序；Steam 对其 Flatpak 容器进行 IPC 调用，以制作具有更多运行时间的并行容器。

Steam 和 Flatpak 容器和运行时的各种组合。未图示：Steam 和游戏直接在用户的本机环境中运行，就像它们在其他所有操作系统上一样。

复杂性甚至比上面的视频显示的还要糟糕。Flatpak 使用libostree将其所有数据存储在文件系统上方的内容可寻址重复数据删除层中。Steam 现在使用使用命名空间的libcapsule，dlmopen()以便游戏可执行文件和驱动程序库可以将不同版本的 libstdc++ 加载到同一进程中。我们甚至还没有谈到 Wine/Proton，这是另一层疯狂。

这是将我们带到崩溃边缘的软件复杂性的生动例子。这是可以想象的最复杂的软件分发方式。当大量依赖此脚手架的应用程序发布时会发生什么？这将如何维护？地球上有多少人会真正理解这一切是如何运作的？

服务

所有这些应用打包系统都要求用户在他们的 PC 上安装一些服务，然后才能安装任何包。

值得称赞的是，AppImage 在技术上不需要服务来运行应用程序，但如果没有它，它就不会与桌面集成。我需要使用 AppImage 应用程序一段时间，我的解决方案是将它留在我的~/Downloads文件夹中，然后在我的文件管理器中双击它来运行它。这是一种糟糕的用户体验。

所有桌面集成（启动器条目、mimetypes、图标、更新）均由appimagedAppImageLauncher 或 AppImageLauncher提供，用户必须安装其中之一才能使其正常工作。所以在实践中，AppImage 与我们的任何其他解决方案没有什么不同：它需要一个可用的服务。

如果用户没有该服务，那么这是他们安装应用程序必须跳过的另一个环节。一些发行版，特别是 Fedora，预安装了 Flatpak。一些发行版，特别是 Ubuntu，预安装了 Snap。SteamOS 预装 Steam。除了这些特殊情况，用户必须在安装应用程序之前安装正确的服务。开发人员必须教他们这样做，并失去所有无法弄清楚或无法打扰的用户。

应用商店

大多数这些技术的一个主要目标是支持“应用商店”体验：Docker Hub、Flathub、Steam Store、Snapcraft和AppImageHub（但不是AppImageHub？）这些技术都是围绕这个模型设计的，因为所有者想要一个削减销售收入或企业分销费用。（Flathub只是说他们没有处理支付目前，它的到来。）

这就是 Ubuntu 希望每个人都使用 Snap 而不是帮助我们构建在 Ubuntu 上本地运行的应用程序的真正原因。这也是他们关闭 Snap 服务器源代码的原因。他们希望它像 Android 的“开放”方式一样“开放”，其中只有一个官方商店，并且侧载应用程序尽可能烦人。

这与仅下载安装程序、单击“下一步”并通过完整桌面集成安装应用程序的传统 Windows 体验相去甚远。这才是真正的自由。没有任何要求，没有其他步骤，也没有安装应用程序的障碍。这就是为什么 Windows Store 甚至在某种程度上甚至 macOS App Store 都失败的原因。他们无法与自己的平台提供的自由竞争。

我知道免费软件和隐私保护人士不希望在他们的 PC 上允许专有应用程序具有这种程度的自由。但绝大多数用户和独立软件供应商并不关心。用户想要的是简单（高效！）的安装。最大的软件供应商想要的是将软件直接发送给客户的自由，而无需服务或中心的干预。

这在 Linux 桌面上确实是可能的。让我们在下一节中讨论。

向后兼容的现状

Linux 社区似乎在依赖库来保持跨发行版和版本升级的二进制兼容性方面存在集体创伤。这些替代的运行时工具显然是由拒绝考虑在用户系统上使用任何东西的人构建的（在 Flatpak 的情况下，甚至驱动程序库都没有。）确实，在过去，开源库 ABI 是不稳定的。我在这里告诉你，你不再需要害怕。

近年来，向后兼容的情况已经好得多。Linux 内核一直在缓慢地将其向后兼容的传奇文化输出到堆栈中。glibc（自 2.1 起）和 libstdc++（自 GCC 5 起）等核心库打算无限期地保持向后兼容。freedesktop在跨发行版标准化运行时环境方面取得了巨大进步。Debian 和其他公司大多已停止对其软件包进行破坏 ABI 的定制。ABI Laboratory等网站跟踪 ABI 更改以提供中断的早期警告。Linux 标准库 (LSB) 虽然现在似乎已不复存在，但在标准化功能和防止 ABI 破坏方面取得了重大进展。

就在上周，我使用了几个 Linux 应用程序，这些应用程序作为在我的本机环境中运行的纯二进制 tarball 分发。DevilutionX和OpenTTD的通用 Linux 二进制版本使用我的原生 SDL 来处理图形、声音和输入。Master PDF Editor使用一长串本机库，包括 Qt 5。QNX 软件中心是为 LSB 编译的，并使用我的本机 GTK 3。这些运行完美，不需要备用运行时。为什么？因为今天的大多数库实际上都很好地向后兼容。

GOG的 Linux 支持策略与 Steam 的策略正好相反，并且就像 Windows 的传统安装程序一样工作。每个游戏都是为特定的 Ubuntu LTS 版本构建的：14.04、16.04、18.04。只要您的库至少是新的，游戏就会运行。他们提供使用mojosetup构建的自解压安装向导，这有点像旧的基于 Windows 的WISE或InstallShield安装程序（除非它们不需要 root 访问权限。）您以普通用户身份下载并运行安装程序，点击下一步->Next->Next 你的游戏就安装好了。完整的桌面集成，没有巨大的备用运行时，不需要服务。任何 ISV 都可以通过这种方式发送软件：只需一个直接发送给用户的自安装可执行文件。

这并不完美。特别是 mojosetup 没有安装缺失的依赖项（还），GOG 没有完全遵循 XDG 安装路径的规范（还）。这些都是可以修复的小问题，与 Flatpak 的规模无关。这很简单，这才是真正的自由，用户体验的反差是惊人的。我会在一周中的任何一天通过 AppImage、Flatpak 或 Steam 安装 mojosetup 安装程序。

对于开发人员来说，是的，这可能比制作 AppImage 更难。库版本之间仍然会偶尔出现错误。分布之间仍会偶尔存在差异。这些是您可以解决的问题。一开始可能会很痛苦，但这是值得的：通过解决用户库的问题而不是尝试替换它们，您将提供更好的用户体验。

强制发行版保持兼容性

随着时间的推移，向后兼容性情况将继续变得更好。为原生 Linux 桌面提供的专有软件越多，主要发行版接受上游破坏的可能性就越小。想象一下，如果数百万上班族在 Ubuntu 上使用 Excel。如果分销升级破坏了它，您认为企业会抱怨多大？

2014 年，Linus Torvalds 建议Valve 可以拯救 Linux 桌面。他希望他们发布大量依赖 Linux 桌面核心库的专有游戏，最终迫使发行版保留他们的 ABI。不幸的是，正如他所预测的那样，这并没有发生。Steam 没有依赖本机运行时库，而是用自己的库替换了其中的大部分。

2012 年，Steam 需要替换一些库才能使游戏正常运行。如今，这已不再需要。那么为什么他们还在推动他们的运行时间呢？如果 Steam 弃用它们的运行时，放弃新游戏的容器化，让所有新游戏只使用本机系统库，我们能取得多大进展？如果发行版升级破坏了他们最喜欢的游戏，您认为游戏玩家会有多大的抱怨？

几年前，Canonical 决定从 Ubuntu 19.10 中删除 32 位库。在包括Wine 和 Steam 威胁要放弃对 Ubuntu 的支持在内的众怒之后，他们改变了决定。想象一下，如果 Steam 游戏依赖更多的系统库，Ubuntu 会有多稳定。

对于任何阅读本文的库开发人员来说，很难过分强调向后兼容性对平台流行的重要性。向后兼容性是 Windows 仍然是占主导地位的桌面操作系统的主要部分。Microsoft 已设法使 Win32 API 保持稳定超过 25 年。为 Windows 95 构建的 GUI 应用程序仍然可以在 Windows 10 上开箱即用。企业实际上关心这一点！他们使用古老的专有软件，这些软件对他们的业务至关重要，其源代码早已随时间流逝。破坏他们软件的平台根本就不是平台。

GTK 问题

我关于 Linux 库稳定性的主张有一个明显的例外。那个例外是 GTK。GTK以鲁莽的放弃破坏了他们的库而闻名。这在历史上一直是为 Linux 提供二进制应用程序的最大问题之一。

我相信这部分是由于对自由软件的激进立场。一些倡导者坚信用户应该能够重新编译他们的软件，以至于他们强迫他们这样做。他们似乎故意破坏库只是为了说：“重新编译！哦，你不能吗？那会教你使用二进制软件！” 用户当然不想重新编译他们的软件，但用户真正想要的通常在 GNOME 开发者身上丢失。

随着最近发布的 GTK 4，几乎没有理由相信情况会有所改善。有一次，他们提议在所有主要和次要版本上都使用 soname。值得庆幸的是，他们改变了方向，但他们最新的版本控制方案仍然表明他们希望加快主要版本的步伐，使他们能够更频繁地进行重大更改并删除已弃用的功能。他们至少打算在主要发布系列中保持 ABI 稳定，但鉴于他们的记录，当有人相信 GTK 4 保持稳定时，它就会过时。

这听起来像是个坏消息，但这里有一线希望：虽然他们在玩弄 GTK 4，但他们并没有破坏 GTK 3。

向 GTK 4 的持续过渡为我们提供了机会。GTK 3 ABI 终于成为一个稳定的目标，它仍然预装在大多数发行版中，因为许多内置应用程序还没有升级。如果我们能够获得足够数量的二进制应用程序依赖它，发行版将被迫维护它，甚至“永远”预安装它，就像微软“永远”维护 Win32 API 一样。

我强烈建议所有应用程序开发人员（开源或其他）尽可能延迟升级到 GTK 4。我们延迟切换的时间越长，GTK 3 就会越稳定。如果 GTK 团队希望我们使用 GTK 4，他们需要证明其多年的稳定性，而不是简单地将其替换为 GTK 5。

我并不是说 GTK 3 很好。我只想说它存在。没有其他工具包可以声称对桌面应用程序实用，并且相对稳定并预装在绝大多数 Linux 桌面上。我们都希望有一天会出现更好的东西，但同时 GTK 3 就是我们所拥有的。

现在是发布针对 Linux 桌面的二进制应用程序的最佳时机。我的意思不是针对它自己的捆绑运行时；我的意思是真正针对用户的运行时环境。就是现在。

Flatpak 是可修复的吗？

这是事情。其实，我觉得气泡布，由Flatpak（现在蒸汽）使用沙箱工具，是相当不错的。这是使应用程序沙箱足以与 Android 或 iOS 竞争的关键技术。如果它被用来隐藏敏感的东西，/home但只是将本机/usr直接安装到沙箱中，那可能会很棒。不幸的是，Flatpak 恰恰相反。

如果 Flatpak 开发者真的想要一个与 Android 和 iOS 相媲美的应用分发系统，沙盒、权限和门户系统应该是唯一的重点。

他们应该：

• 放弃与运行时相关的所有内容，而是将本机/usr（或来自 的一组受限核心库/usr）以只读方式安装到每个容器中；
• 将元数据添加到 Flatpak 以声明 Flatpak 服务将使用主机发行版的包管理器安装的库依赖项（可能带有可以干净删除的生成的元包）；
• 构建细粒度的用户交互运行时权限系统，该系统要求应用程序进行 Flatpak 特定的 API 调用以激活权限对话框；和
• 弃用安装时权限（尤其是文件系统访问权限）并从 Flathub 中删除所有使用它们的应用程序。

在此系统下，将鼓励应用程序静态链接其许多依赖项，但使用系统 GTK/Qt/SDL、OpenGL/Vulkan、OpenSSL/curl 和其他大型或安全关键库。社区可以维护指南和包装器，使应用程序能够动态链接到跨版本和跨分发的系统库。应用程序需要进行更改以直接通过 Flatpak 客户端 API 运行沙盒和请求权限。

这更类似于 iOS 和 Android 的工作方式。但这意味着放弃 95% 的 Flatpak。这将是一个如此巨大的变化，以至于他们不妨以不同的名字重新开始。我没有看到它发生。

一个基于沙盒技术的应用商店是一个合理的想法。我当然不认为它应该用于所有事情。我认为 Excel 或 Photoshop 等软件根本不需要它。用户不关心对这些类型的应用程序进行沙箱处理，他们的供应商无论如何都会拒绝进行沙箱处理。

但是对于来自独立开发者的小型应用程序和游戏，一个合适的沙盒应用程序市场理论上可以扩大他们的影响范围。它可以消除在您的计算机上运行它们所需的大部分信任，并使本机应用程序更接近于 Web 应用程序的易用性。

这对开发者来说当然并不容易，但好的原生应用仍然提供比网络应用更好的用户体验，一个合适的沙盒应用商店可能会在原生应用中复兴。微软的尝试显然失败了，但 macOS 并没有。也许有一种方式 Linux 也可以成功。

结论

目前的 Snap 和 Flatpak 已经存在至少五年了。AppImage、Steam 和 Docker 的存在时间更长。以上都不是新的。从一开始就知道备用运行时的问题，但在修复它们方面进展甚微。我不相信这些是新技术的成长之痛。这些是基本问题，大多无法修复。

所有这些技术本质上都是在另一个操作系统之上构建一个完整的操作系统，以避免向后兼容性的挑战。在这样做时，他们制造的问题远远多于他们解决的问题。兼容性问题最好由操作系统解决，真正的操作系统，而不是一些容器化的混蛋。我们需要制作本地运行的应用程序，尽可能多地使用系统库。如果我们有希望将专有软件吸引到 Linux，我们就需要彻底简化一切。

如果您是 Linux 发行版维护者，请了解所有这些解决方案试图实现的目标。您在构建软件存储库、维护库、测试无数系统配置、设计一致的用户体验方面所做的所有辛勤工作……他们正试图抛弃所有这些。这些运行时打包机制中的每一种都试图颠覆操作系统，尽可能多地用自己的方式进行替换。你为什么要支持这个？

我恳求你，不要使用这些打包工具。不要将他们的服务添加到您的 Linux 发行版中，不要使用以这种方式打包的应用程序，也不要发布使用它们的应用程序。大规模容器化和备用运行时不可能成为 Linux 桌面应用程序的未来。如果这真的是它前进的方向，那么未来将会如此糟糕，以至于我们最终都会回到 macOS 或 Windows 上。

就个人而言，我对如何在 Linux 上获得 Excel 和 Photoshop 更感兴趣，而不是不值得信赖的驱动程序和游戏，所以我并不真正关心沙盒、权限、门户、应用程序商店、备用运行时或任何真正的Flatpak 所做的事情。这些对于说服微软和 Adobe 将他们的软件套件移植到 Linux 都适得其反。吸引这些供应商只能通过为他们提供稳定的平台来吸引他们，而不是将他们锁定在一个盒子里。

在以后的文章中，我将讨论直接针对桌面 Linux 的一些问题，展示我正在研究的一些内容，并希望提出不依赖于替代运行时的真正解决方案。

更新：添加了指向 libportal 的链接，添加了对 AppImageLauncher 的引用，并且更正了 GTK 4 版本控制方案的描述。

本文标签： 未来 Flatpak