Linux 打包工具 Flatpak 的未来
在四月份的Linux 应用峰会 (LAS)上，Sebastian Wick 说，从许多指标来看，Flatpak 做得很好。Flatpak 应用程序打包格式受到上游开发人员和许多用户的欢迎。越来越多的应用程序被发布到Flathub 应用程序商店，该格式甚至被 Fedora 等 Linux 发行版所采用。不过，他担心 Flatpak 项目本身的工作已经停滞不前，能够审查和合并基本维护之外的代码的开发人员太少。我无法亲自参加 LAS 或观看现场直播，所以我在 YouTube 上观看了演讲。幻灯片可从talk page获取。Wick 是 GNOME 项目的成员，也是红帽公司的员工，从事 “各种桌面管道 ”的开发，包括 Flatpak 和桌面门户。
Flatpak 基础知识
Flatpak 最初 是由 Alexander Larsson 开发的，他早在 2007 年就参与了类似的项目。其首次发布是在 2015 年作为 XDG-App 发布的。2016 年，它更名为 Flatpak，与宜家用于运送家具的“flatpacks ”相呼应。Flatpak 项目提供用于管理和运行 Flatpak 应用程序的命令行工具、用于构建 Flatpak 捆绑程序的工具，以及为 Flatpak 应用程序提供组件的运行时。该项目使用控制组、命名空间、绑定挂载、seccomp和Bubblewrap来提供应用程序隔离（“沙箱化”）。Flatpak内容主要使用OSTree交付，不过自2018年起，Fedora已支持使用Open Container Initiative (OCI) images可用，并将其用于Flatpak应用。Flatpak 文档中的“Under the Hood ”页面很好地概述了这些组件是如何组合在一起的。
发展缓慢
Wick 在演讲开始时说，Flatpak 项目看起来一切都很好，但如果深入研究，“你会发现它的开发不再活跃”。例如，有人在维护代码库和修复安全问题，但 “更大的变化并没有真正发生”。他说，有很多新功能的合并请求，但没有人觉得有责任审查它们，这就有点问题了。缺少审核人员的原因是拉尔森等关键人物已经离开了项目。威克说，拉尔森偶尔会在必要时参与进来，但他基本上不参与项目的日常开发。威克说，很难让新的 Flatpak 参与者参与进来，因为要花几个月的时间才能得到对重大改动的反馈，然后再花几个月的时间才能得到另一次审查。“这确实不是一个让人快速上手的好方法，也不是一个很好的处境。” 他说，“也许我抱怨的东西实际上并不是什么大问题”。Flatpak 可以工作，它能完成任务，“我们只是使用它，并没有考虑太多”。从这个意义上说，这个项目的情况还不错。但他仍在思考项目是如何 “受制于人 ”的，因为贡献者没有机会进行更大的改变。威克举例说，红帽公司一直在努力使 Flatpaks 成为基础安装的一部分。供应商或管理员可以指定要安装的应用程序，然后一个名为 flatpak-preinstall 的程序就可以完成剩下的工作。该功能已经实现，并计划纳入 Red Hat Enterprise Linux (RHEL) 10。这项工作由 Kalev Lember 和 Owen Taylor 于去年 6 月开始，但由于 Lember 即将离开红帽，不再参与这项工作，他于今年 2 月关闭了最初的拉取请求。Wick 在 2 月份以新请求 的形式接收了该请求，但直到 5 月初才对其进行审查。
OSTree 和 OCI
Wick 的下一个主题是 Flatpak 中的 OCI 支持。虽然 OSTree 在某些方面取得了成功，而且仍在维护之中，但它并没有得到积极的开发。他指出，开发人员使用 OSTree 的工具 “非常狭窄”，因此构建使用 OSTree 的 Flatpak 需要非标准和定制的工具，但有一整套实用程序可用于处理 OCI 映像。更妙的是，用于处理 OCI 图像的工具 “都是由我们以外的人开发的，这意味着如果我们接受这些工具，实际上就不需要做这些工作”。遗憾的是，还有一些与 OCI 相关的改进正在等待审核，以便合并到 Flatpak 中。例如，Wick 提到 OCI 容器标准增加了 zstd:chunked 支持。zstd:chunked图像使用zstd进行压缩，并具有skippable frames，其中包含额外的元数据（如目录），可实现文件级重复数据删除，而不是使用gzipped tarballs的原始OCI图像格式。简而言之，在更新容器镜像或 Flatpak 时，zstd:chunked 只允许提取自上次更新以来发生变化的文件，而不是整个 OCI 层。泰勒在 2023 年 9 月提交了一个pull request，为 Flatpak 添加对 zstd 压缩层的支持。从那时起，该请求就鲜有人关注，“目前只是放在那里”。
缩小权限范围
Flatpak 的主要功能之一是沙盒应用程序，并限制它们对系统的访问。Wick 说，该项目增加了一些功能，以 “缩小 ”沙箱的范围，并提供更多受限权限。举例来说，Flatpak 现在有 -device=input 功能，允许应用程序访问输入设备，而无需访问所有设备。他说，这样做的一个问题是，系统安装的 Flatpak 可能不支持更新的功能。用户的 Linux 发行版可能仍然提供旧版本的 Flatpak，不支持 -device=input 或 Flatpak 开发者希望使用的任何新功能。Wick 说，需要有一种方法让应用程序默认使用新权限，但如果在使用旧版 Flatpak 的系统上使用，就会退回到旧的权限模型。他说，这并不是一种全新的情况。“我们以前在 Wayland 和 X11 上也遇到过这种情况”，如果系统运行的是 Wayland，那么 Flatpak 就不应该绑定挂载 X11 socket。现在，用于 USB 访问的xdg-desktop 门户也出现了类似情况，该门户于 2021 年添加到 xdg-desktop 项目中。对该门户的支持几经反复，于 2024 年被 合并 到 Flatpak 中。现在缺少的是指定向后兼容权限的能力，这样，Flatpak 应用程序就可以通过较新版本的 Flatpak 获得 USB 访问权限（-device=usb），但在必要时保留 -device=all 权限。有一个pull request（来自 Hubert Figuière）再次实现了这一点，但 Wick 说 “它也只是放在那里”。Wick 还希望改进 Flatpak 处理音频访问的方式。目前，即使主机系统使用 PipeWire，Flatpak 仍然使用 PulseAudio。这样做的问题在于，PulseAudio 将扬声器和麦克风的访问捆绑在一起–你可以同时访问这两个设备，也可以两者都不访问，但不能只访问其中一个。因此，如果一个应用程序可以播放声音，它也可以捕捉音频，Wick 轻描淡写地说，这 “并不好”。他希望能够使用 PipeWire，这样就可以限制对扬声器的访问。Wick 说，嵌套沙箱在 Flatpak 中不起作用，这是一个令人头疼的问题。例如，应用程序不能在 Flatpak 中使用 Bubblewrap。许多应用程序（如网络浏览器）都大量使用沙箱。
他们非常喜欢把自己的标签页放入自己的沙箱，因为如果其中一个标签页正在运行某些代码，而这些代码又设法利用了沙箱，并突破了沙箱中的进程，至少它被控制住了，不会扩散到浏览器的其他部分。
目前，Flatpak 所做的是提供一种侧沙箱，应用程序可以调用该沙箱并生成另一个 Flatpak 实例，从而进一步对其进行限制。“因此，从这个意义上说，这是一种解决问题的方法，但也有点脆弱。” 他说，这种方法存在问题已经有一段时间了，但没人知道如何解决这些问题。理想情况下，Flatpak 只需支持嵌套命名间距和嵌套沙箱，但目前还不支持。Flatpak 使用 seccomp 来防止沙箱中的应用程序直接访问用户命名空间。有一个应用程序接口可用于创建子沙箱，但限制更多。他说，对用户命名空间的限制已经过时： 他说：“长期以来，暴露用户命名空间并不是一个真正的好主意，因为这样会向用户空间暴露一个很大的内核应用程序接口，可能会被人利用”。Wick 认为，如今，用户命名空间是一个久经考验、使用广泛的接口。他认为，反对用户命名空间的理由已经不多了。
xdg-dbus-proxy
Flatpak 应用程序不会直接与 D-Bus 对话。取而代之的是，flatpak-run 会为每个 Flatpak 实例生成一个 xdg-dbus-proxy，它 “并不完全在同一个沙盒中，基本上只是在一旁”。代理负责根据 flatpak-run 启动应用程序时处理的规则设置过滤。在设置代理时，Flatpak 从拒绝所有状态开始，然后添加允许的特定连接。这样，应用程序就不会暴露其他应用程序不应使用的内容。Wick 说，他希望将过滤功能从 xdg-dbus-proxy 直接转移到 D-Bus 消息代理，并提供基于 cgroups 路径的策略。这不是已经实现的东西，但他说他计划在 busd中开发一个原型，这是用 Rust 实现的 D-Bus 代理。这也将允许采用更动态的策略，从而让应用程序可以随时向其他应用程序输出服务。目前，策略是在运行 Flatpak 时设置的，之后就无法修改了。顺便提一句，这意味着 Flatpak 应用程序无法通过 D-Bus 相互通信。它们仍然可以与其他应用程序通信；例如，Wick 说，应用程序可以通过主机的共享网络命名空间进行通信，“这意味着你可以使用 HTTP 或其他方式，只要你愿意，你可以使用成千上万的旁路”。Wick 说，Flatpak 的网络命名空间 “有点难看，我也没有什么好的解决方案”，但他想指出，这是项目应该考虑的问题。“比如，你在本地主机上绑定了一些东西，突然间所有的应用程序都可以戳它了”。他举例说，AusweisApp 是德国身份证的官方认证应用，可用于政府网站的身份验证。它在本地主机上公开了一项服务，使系统上的所有 Flatpak 应用程序都能使用这项服务。
这就是我觉得我们真的需要看看的一些东西。我不确定这是否可以直接利用，但至少有点可怕。
威克说，项目需要为 Flatpak 应用程序创建一个网络命名空间，“但我们身边没有网络专家，这有点尴尬，我们真的必须找到一个解决方案”。他说，该项目的另一个尴尬之处在于英伟达（NVIDIA）驱动程序。该项目必须为支持的多个运行时构建多个版本的英伟达驱动程序，这就给用户带来了大量的网络开销，因为他们必须下载每个版本的驱动程序–即使他们并不需要所有的驱动程序。(Linux Mint 论坛上的投诉 很好地说明了这个问题）。这也意味着打包成 Flatpaks 的游戏需要根据新的运行环境不断更新，否则最终就会因为驱动程序停止更新而无法运行，游戏也就无法支持当前的 GPU。Wick 建议借鉴 Valve 软件公司的做法。他说，Valve 使用与 Flatpak 类似的模式来运行游戏，但它使用的是主机系统的驱动程序，并在游戏沙盒中加载驱动程序的所有依赖项。Valve使用libcapsule库来实现这一功能，但这个库 “有点脆弱”，很难确保其良好运行。他希望不使用 libcapsule，而是静态编译驱动程序，并在所有 Flatpak 应用程序之间共享。目前这还只是设想阶段，但 Wick 说他希望最终能解决驱动程序问题。
门户
门户是 D-Bus 接口，为文件访问、打印、打开 URL 等提供 API。Flatpak 可以授予沙盒应用程序访问门户的权限，以便进行 D-Bus 调用。Wick 指出，门户网站并不是 Flatpak 项目的一部分，但它们对 Flatpak 项目至关重要。他说：“无论我们在门户网站上做什么，都会直接改进 Flatpak，我们需要改进的门户网站有很多”。他举例说，Documents 门户可以让 Flatpak 应用程序访问沙盒之外的文件。文档 “门户非常适合共享单个文件，但对于 Blender、GIMP 或音乐应用程序等可能需要访问整个文件库的其他应用程序来说，它过于细粒度，限制太多。“在某些情况下，你需要一个更粗粒度的文件权限模型。他说，还有一些可能性，比如将用户选择的主机位置绑定到沙盒中。Wick 提出了许多他希望在门户网站上实现的想法，如支持自动填写密码、快速身份在线（FIDO）安全密钥、语音合成等。他承认，现在为门户网站编写代码 “有点难”，但有工作可以通过使用libdex使之变得更容易。(请参阅 Christian Hergert 关于 libdex 的博文）。他说，用 Rust 重写甚至可能更有意义。
Flatpak-next
Wick 说，假设现在是十年后，没有人再开发 Flatpak。“如果你能重写 Flatpak，你会怎么做？我认为，我们的愿景应该是几乎所有东西都用 OCI。Larsson 在创建 Flatpak 时所作的选择在当时是正确的技术决策，但最终却 “与其他人的做法大相径庭”。这是一个问题，因为只有少数人了解 Flatpak 的作用，而项目必须自己做所有的事情。但他说，如果该项目 “做所有 OCI 的事情”，它就能免费获得很多东西，比如 OCI 注册表和工具。这样一来，Flatpak-run 需要做的事情就不多了。他说，利用现代容器工具重新思考Flatpak，并与更广泛的容器生态系统保持一致，会让一切变得更容易，值得探索。他再次提出了使用 Rust 进行重写的想法。
问答
Wick 的会议结束时有一些提问时间。第一个问题是，如果项目转移到 OCI 工具，现有的 Flatpaks 会发生什么。“我是否需要扔掉应用软件并重新下载，还是说这在未来太麻烦了，你们还没有考虑过这个问题？Wick 说，这将是客户端的一个问题，但 Flathub（例如）拥有其 Flatpaks 的所有构建说明，可以简单地重建它们。另一位听众对使用容器基础设施表示担忧。他们说，存储映像的 OCI 注册表缺少索引和元数据，而这些数据正是 Flatpaks 的 GNOME 软件等应用程序所需要的。怎样才能确保它们能保持相同的用户体验？Wick 说，现在已经有了在 OCI 注册表中存储非图像的标准，这将允许为 Flatpak 存储 “与我们目前存储的相同的内容”，但编写代码并将其合并将是困难的部分。最后一个问题是，是否计划在 Flatpak 中直接使用 PipeWire 而不是 PulseAudio 路由。Wick 说，他一直在与 PipeWire 的创建者 Wim Taymans 讨论如何在 Flatpak 中添加对 PipeWire 的支持。他说，这主要是关于 “添加 PipeWire 策略，使其在知道自己是 Flatpak 实例时做正确的事情”。
本文文字及图片出自 The future of Flatpak
你也许感兴趣的：
- 为什么 Debian 会变成这样？
- RockyLinux 在 RL10 中正式支持 RISC-V！
- Debian APT 3.0 的新功能
- Rust 和 C 文件系统 API
- Fedora 变革的目标是实现 99% 的软件包可重复性
- chroot 技术–Linux 系统的瑞士军刀
- 20 年前的 exe 现在仍然可以在 Windows 上运行，linux 呢？
- Linux 内核 6.14 在性能和 Windows 兼容性方面实现了巨大飞跃
- Android 15 上的原生 linux 开发环境
- 早期的 Linux
> Wick 在演讲开始时说，Flatpak 项目看起来一切都很好，但如果深入研究，“”你会发现它已经不再积极开发了”。例如，有人在维护代码库和修复安全问题，但“”更大的变化并没有真正发生”。他说，有很多新功能的合并请求，但没有人觉得有责任审查它们，这有点问题。
我认为红帽应该在这方面加大力度，尤其是在 RHEL 10 之后，他们停止了对大量桌面软件包的维护，对这些软件包用户的建议是 “从 Flathub 而不是从我们这里获取软件包”（参见 https://docs.redhat.com/en/documentation/red_hat_enterprise_… 搜索 Flathub）。如果这就是红帽对桌面软件的态度，那么他们就应该提供资源，让 Flatpak 成为一个可行的替代方案。
> 用户的 Linux 发行版可能仍在提供旧版本的 Flatpak，该版本不支持 –device=input 或 Flatpak 开发者希望使用的任何新功能。Wick 说，需要有一种方法让应用程序默认使用新权限，但如果在使用旧版 Flatpak 的系统上使用，就会退回到旧的权限模式。
我很高兴他提出了这个问题。我在 Flathub 上维护一款支持音频和控制器的游戏。由于权限粒度有限，这意味着游戏显示为需要任意设备访问（–device=input 太新了，所以 Flathub 维护者还不允许在软件包中使用），并能监听设备的麦克风（音频权限不允许只访问扬声器而不访问麦克风）。我希望 Flatpak 能为权限添加向后兼容性，这样较新的 Flatpak 版本就能开始拥有更细粒度的权限。
红帽公司后来又收回了一部分。Firefox 和 Thunderbird 本应只在 RHEL 10 中使用 Flatpak，但他们最终为 GA 提供了 rpms。
造成这种情况的原因似乎有很多，包括缺乏本地消息传递、无法集中部署策略，以及与桌面生态系统其他各个部分的集成出现问题。
他们收回了 Firefox 和 Thunderbird，但 Evolution、LibreOffice、GIMP、Inkscape 和 Totem 都被放弃了。红帽不再为 RHEL 打包办公套件、光栅图像编辑器、矢量图像编辑器或媒体播放器。这意味着，即使是把 RHEL 用作开发工作站的人，如果不想用第二台电脑来完成所有一般办公任务，也必须从 Flathub 下载软件。
桌面对 Red Hat 来说不是一个大市场。即使是他们的员工也大多使用 Fedora。
我真正看到 RHEL 工作站的唯一地方是在特殊用途的应用程序中，而在大多数这些应用程序中，用户要么有一个单独的 Windows 操作系统，要么他们通过 Citrix/RDP 进入公司的 Windows 环境来完成正常的办公任务。
大约十年前，我在一家生物信息学实验室工作。所有的工作机器都是集中管理的 RHEL 机器。我猜现在情况不同了？
Ubuntu基本上吃掉了他们的桌面午餐。过去，商业软件需要在桌面上安装SuSE或RedHat才能获得支持。但与其他桌面发行版相比，尤其是RedHat总是受到 “古老 ”的诅咒。当 Ubuntu 成为足够大的商业软件的目标时，人们选择了 Ubuntu，因为 Ubuntu 更新颖。
此外，早在几个版本之前，RedHat 就已经开始收敛他们在桌面方面的努力，只留下服务器/容器/云作为 RHEL 的主要用途，而桌面只是 “这也可以用”。最新决定放弃大量与桌面相关的内容只是这一政策的合理延续。
Ubuntu更易于安装，免费提供，而且有商业模式。Redhat已经放弃了家用市场，Suse卖给了微软，而Fedora似乎只是一个尽力而为的分叉，随时都有可能消失。另外，我们中的许多人已经喜欢上了Debian，并推荐人们使用Ubuntu作为更友好的Debian。更新版 “与此并无多大关系。
鉴于 RHEL 的目标，我不能说我不同意他们不为 RHEL 10 打包这些应用程序的决定。RHEL 并不是真正为用户桌面而设计的。自从 RH 分拆出工作站和服务器版本的操作系统后，RHEL 就一直以服务器为目标。我不认为缺少办公套件会对用户造成什么影响。
如果有像 Flathub 这样的工具可供选择，那就更能说明问题了。
> 如果这些工具有其他来源，比如 Flathub，那么这一点就更加正确了。
我想说的是，Red Hat 在 RHEL 上废弃了图形桌面程序，并告诉他们的客户转而从 Flathub 获取这些程序，而 Red Hat 的一名员工在发表关于 Flatpak 未来的演讲时却说，Flatpak 已经不再积极开发，而且没有人负责审核新功能的 MR。我并不是说红帽停止打包图形程序一定是件坏事。我想说的是，既然他们已经认可 Flatpak 作为图形化程序打包的替代方案，我希望红帽公司能把不再打包/支持这些图形化程序而节省下来的一些开发资源用于帮助改进 Flatpak。
> 我希望红帽公司能把不再打包/支持这些图形程序后节省下来的部分开发资源用于帮助改进 Flatpak。
我非常同意这一点。如果能有更好的协调和支持就更好了，尤其是对那些能够利用 Flatpak 来减少自己开销的人来说。
> 自从 RH 分拆工作站和服务器版本的操作系统后
RHEL 8 不是已经取消了吗？
你说得没错。我还是不太明白。
我很想知道 Redhat 到底卖出了多少工作站许可证。时间太久了，我都不知道他们还有单独的工作站许可证可供购买。当你为服务器和工作站设置了相同的发行版时，在我看来，其中一种会占据主导地位，而另一种最终会被忽视。谁是购买和使用工作站许可证的用户？
但归根结底，我还是不明白他们为什么要为 RHEL 打包 Office 套件。或者，更重要的是，用户为什么要使用它。RHEL 是为稳定性而设计的。它是一个优秀的服务器操作系统，支持良好。正因为如此，众所周知，它也有一些旧版本的库和程序。这没关系，因为许多新功能和修复都会得到回传，但通常还是会包含旧版本（稳定）的软件。你为什么想要旧版本的办公套件？他们为什么要打包一个可以安装在服务器上的较新（风险更大）版本？在我看来，这根本说不通……这是好的服务器操作系统与好的工作站操作系统之间的根本对立。
注：几十年来，服务器上的 Linux 与桌面上的 Linux 一直存在着这样的取舍。可能还会持续几十年。一种使用情况下所需要的东西，对其他使用情况来说并不合理。这就是为什么我们有不同的发行版，这是件好事。我不明白的是，RH 公司为什么要把两者重新合并在一起。这就是为什么我认为从 RHEL 的角度来看，弃用工作站应用程序（RHEL 打包的）而改用 Flatpak 版本是件好事。
>谁是购买和使用工作站许可证的用户？
有时是坚持要求签订支持合同的机构和企业，有时是发布软件的供应商。有时会有实际的法律规定要求他们这样做，但通常只是管理层在做管理方面的事情。这种要求会立即减少他们的大部分选择，即使在这种标准下存在我认为更合理的选择。
我能猜到谁买了许可证……我更好奇的是谁在使用它们。真正的问题是–用户使用的是什么应用程序？我相信 RH 有关于客户群安装了哪些软件包的数据（拥有一个集中的软件库确实有其优势）。因此，他们可能更容易找出需要放弃的软件包。
许多公司使用 RHEL 工作站运行专有 GUI 应用程序。应用程序通常在 RHEL 服务器上运行，并使用 X11 转发在工作站上显示图形用户界面。
在客户端和服务器上运行相同的操作系统使支持工作变得更加简单。ISV 甚至可能不支持 Fedora 或 Ubuntu 等更现代的操作系统。
这些公司不需要办公套件，因为他们有可以运行 Microsoft Office 的 Windows 机器。他们只需要一个易于使用的 Linux 桌面环境，并且在通过 VNC 访问工作站时不碍事。
我的服务器依赖 libreoffice 的部分功能来处理文档。
为了防止有人认真考虑新的设计，这里有一个轶事：
几年前，当 Flatpak 还是一个全新的项目时，我遇到了一些最初的开发者。我试图说服他们改变设计中的一个基本部分，但没有成功。在最初和现在的设计中，安装的 Flatpak 都有一个名称，权限与该名称绑定，你运行该 Flatpak，它就会拥有分配给它的权限，如果有其他东西与它对话，它也会用该名称与它对话。如果我将 VSCode Flatpak 安装为我的 UID，并授予它访问文档目录的权限，那么以我的身份运行的 VSCode 就可以访问文档。
我认为这是错误的设计。如果我以我的身份安装 VSCode，那么就应该有一个已安装的副本，而这应该没有任何意义。如果我运行 VSCode，那么正在运行的实例就应该有某个 ID（可能是短暂的），而且该实例应该有一组权限。如果我想运行 VSCode 并访问 ~/project_a，而另一个实例则访问 ~/project_b，那么即使它们同时运行，也应该可以正常工作，而且实例之间应该无法访问彼此的数据。如果我想运行两个 Tailscales，应该可以正常工作。如果我想启动一个短暂的 Firefox 实例，也应该可以。
不管过了多少年，我仍然认为我是对的。Flatpak 弄错了，微软和苹果的应用商店弄错了，Mac OS（非常非常）弄错了，等等。我们有很多机会可以做得更好。
(从 bug 缓解的角度来看，这一点很重要：实现了 RCE 的 LibreOffice 文档不应该能够访问我的其他文档。从供应商完全不在乎的角度来看，这一点也很重要： VScode 从一开始就基本上不具备安全性，而 Flatpak 中的 VSCode 则应该具备一定程度的真正安全性（这是 Flatpak 提供的）。
继续咆哮。
我非常不喜欢这些以安全为名的复杂性。电脑是通用设备，是我的。我不需要每个实例都有权限，我不需要不能与其他应用程序共享文件的沙盒，我也不希望 “万物皆文件 ”的概念在我的电脑中消失。我的电脑不是单窗口设备，也不运行面向互联网的服务器。请模拟威胁并相应调整安全性和可用性。
我这样做是有原因的： Ubuntu 上的 Thunderbird 和 firefox 现在无法访问 /tmp 目录，而是在一些非常规的地方拥有自己的目录。当我想做一些简单的事情，比如在雷鸟中保存一个附件，然后在另一个程序中打开它时，我无法访问/tmp目录，而需要将它放在某个永久存储空间中。但由于沙盒的存在，情况变得更糟了。现在，thunderbird 也不能向我显示查看器应用程序了，因为它被沙盒化了，而且还能向我推荐其他已安装的应用程序。
电脑不再是我的了，它成了建筑宇航员的游乐场，他们认为程序的可用性总是不如安全性重要。对于这些人，我希望他们能在地球上最安全的设备[1]上修修补补，这样他们就不会打扰正在努力工作的人们了。
[1] https://en.wikipedia.org/wiki/Useless_machine
整个 “服务器面向互联网 ”的攻击模式是真实存在的，但它已经过时了。特别是如果你是一名程序员，你机器上的软件很可能会试图攻击你。
无论如何，从 Thunderbird 中保存文件的正确解决方案早已为人所知： “门户 “或任何特定沙盒系统的叫法。Thunderbird 中的沙盒代码会要求权限更高的代码弹出文件选择器，然后 Thunderbird 会保存所选文件。零摩擦，安全性极高。遗憾的是，没有人让整个生态系统都参与进来。安卓系统已支持该功能多年，但应用程序开发者却抱怨并拒绝使用正确的应用程序接口。我认为 Flatpak 可以做到这一点，但几乎没人这么做。
感谢您的回答。
程序员的威胁模型可能比普通用户复杂得多，但与沙箱无关。
关于 “面向互联网的服务器是真实的”，我不太明白你的意思。你能详细解释一下吗？
你关于门户网站的观点，以及支持如何存在，但 Flatpack/IOS 或 Android 生态系统都没有做到这一点，这很能说明问题：当没有人做到这一点时，就很可能意味着设计出了问题。即使是 Fuscia 也失败了，它是一个从零开始构建的操作系统，专注于用户空间隔离以及 IPC 和系统调用合约。
总之，如果设计取代了现有的设计，破坏了曾经有效的东西，这对用户来说是非常不公平的。同样，我们谈论的是几十年来一直存在的最基本的计算机使用模式。
> 关于 “面向互联网的服务器是真实的”，我不太明白你的意思。能详细说明一下吗？
我的意思是：从前，计算机通常无法真正接入互联网，端口开放的服务器是主要的攻击载体。当然，你也可能通过打开别人通过电子邮件发送给你或给你的恶意文档而受到攻击，但这是一种移动速度较慢、较为特殊的攻击载体。你故意执行的代码主要是你购买的东西，可能是离线的，也可能是在线的，安装后长期使用。
如今，每样东西都有网络浏览器，但幸运的是，它有一个不错的内部沙箱。但人们运行的是 “应用程序”，而 “应用程序 ”拥有广泛的权限，并按照设计执行来自其假定供应商的代码。人们实际上是在收买流行应用程序的供应商，以便向其用户群部署可能是恶意的代码。其中一些 “应用程序 ”和大量的开发者应用程序，在设计上会运行来自第三方的代码或等同于本地代码的代码（感谢苹果公司关于代码完整性的不连贯政策），也可能是来自这些第三方选择的第四方等，并自动更新这些代码。越来越多的人开始运行 MCP，这基本上是一种让远程系统对你的系统进行远程控制的工具。在我看来，在客户端机器上（例如可能使用 Flatpak 或类似系统的机器），所有这些都是比面向互联网的服务器更重要的攻击载体。
> 我认为 Flatpak 可以做到这一点，但几乎没人这么做。
Flatpak 可以做得很差。我看到的情况是，打开文件读取一次后，沙盒应用程序就能永远写入该路径名。
这就是问题所在。它从来不是你的。它属于应用程序开发者，其中有些开发者可能很邪恶。当你有成千上万的软件包支持你的桌面环境时，唯一合理的安全模式就是把所有东西都当做威胁来对待，让权限选择进入，而不是选择退出。例如，X 就允许每个程序监视你的键盘输入、内存/帧缓冲区样本等。
归根结底，在安全问题上，普通用户并不是最懂的，应该让懂的人来设计系统。这就是我们制定安全带和儿童危险法的原因。
> 这就是问题所在。它从来不是你的。它属于应用程序开发者，其中有些开发者可能是邪恶的。
但几十年来，它一直是我的，而且在我的发行版软件源中，邪恶开发者并不是一个真正的问题。这是一个自找的问题。
只要你依赖发行版，供应链攻击就一直是个问题。我可以举出大量的实例，但你不必等到事件发生后才去创建一个更安全的用户空间。
你说得没错，但实际上，我认为你应该更进一步，建立一个你的方法和他们的方法的混合体：
对于你的文档，你通常需要你的方法。也许可以为有用的东西提供一些选择余地，比如 “最近使用的文档 ”菜单什么的。
但对于环境方面的东西，我希望至少能允许所有实例都有相同的访问权限，而不需要大量的权限提示。例如，我的 git 配置、字体文件夹、代码片段库等。
你可能是对的。甚至有可能 flatpak 开发人员认为你是对的。
但这仍然不是一个正确的决定，因为当涉及到 Flatpak 这样的产品时，除了技术上最正确的选择之外，还有很多其他的考虑因素。
例如，仅从你的评论来看，基本上所有其他操作系统都采用了与 Flatpak 相同的方法。因此，如果 Flatpak 开发人员按照你建议的技术上正确的方式来做，可能会给应用程序开发人员，尤其是多平台应用程序解码器开发人员带来足够的负担，以至于他们一开始就不会使用 Flatpak。
按照这种说法，Flatpak 根本就不应该存在。如果它做了什么不同的事情，那就是不好的；如果它没有做什么不同的事情，那为什么要存在呢？
虽然有点题外话，但我也一直渴望在安卓系统中实现这种应用程序的可移植性。几年前，小米等一些原始设备制造商显然注意到了这一点，在其操作系统中提供了内置的应用程序 “复制 ”功能，但仅限于 WhatsApp 等少数流行应用程序。
是的，如果运行程序的特定实例拥有一组权限，那就更好了。不过，我认为这并不是唯一的问题。
这也是我想要的，而不仅仅是你想要的。
我认为整个操作系统都需要重新设计，原因有很多（我之前提到过如何设计一个更好的操作系统），这样做的效果是，运行中程序的特定实例将作为参数（或通过其他能力，但第一个能力必须作为参数）被赋予能力，这些能力可以具有受限制的权限，也可以具有更多功能，例如记录访问、通过代理或设置磁盘配额等。
即使你对软件包应该如何工作的看法是对的（我倾向于同意），Flatpak 是否应该执行这种模式也是另一个问题。
据我所知，像 dnf/yum 和 apt 这样的旧版打包系统也允许使用 Flatpak 允许使用的功能。
也许开发者只是想把精力放在成为一个好的打包系统上，而不是改变打包系统的权限模型。看起来合理吗？
我确实认为这对那些希望在不同应用实例之间实现严格隔离的高级用户来说是件好事（我也很希望看到更好的 QubesOS 类型方法，即使用管理程序），但也许大部分此类工作都应优先在应用本身内部进行，使用嵌套沙箱。这样，根据应用程序的正常行为，障碍就会准确地出现在用户期望的位置。当然，前提是将其连接在一起的代码中的漏洞不会爆炸。
网络浏览器已经使用了多种沙盒技术来实现标签页之间的隔离。其中一些技术可以在 Flatpak 中使用，但也有一些会被 Flatpak 破坏：
> 理想情况下，Flatpak 只需支持嵌套名称间距和嵌套沙箱即可，但目前还不支持。Flatpak 使用 seccomp 来防止沙箱中的应用程序直接访问用户命名空间。
对于希望使用应用程序接口的应用程序开发人员来说，Flatpak 会取代其中一些应用程序接口：
> 目前，Flatpak 所做的是提供一种侧沙箱，应用程序可以调用该沙箱，并生成另一个 Flatpak 实例，对其进行进一步限制。
幸运的是，Wick 似乎对 UID 命名间隔持乐观态度，而这正是阻碍 Firefox 和 Chrome 浏览器解决这一问题的主要原因：
> Wick 认为，如今用户命名空间已经是一个经过充分测试且使用广泛的接口。他认为反对用户命名空间的理由已经不充分了。
回到实例化 Flatpaks 的话题，据我所知，其中一个障碍是（应用程序商店/平台普遍）长期希望将完整的启动到用户空间代码签名设置与沙箱绑定在一起。每个应用程序的身份都应保持不变（除非被高级用户特别覆盖），这样，如果不符合代码签名要求，伪造版本的应用程序就无法采用现有应用程序的机密加密文件。我想，一种解决方案是将隔离实例嵌套在应用程序的标识中，但这将变得相当复杂。我们甚至还没有加密技术，也没有任何有效的安全启动和保密计算实现–目前我们在这方面真正拥有的只是 Flathub 正在验证的反向域名符号，以及文件系统访问沙盒，以保持这些文件夹的独立性。
我可能误解了这部分内容，xdg-portal 的作用不就是提供对实例的短暂访问权限吗？
比如 VirtualBox 快照？那你就需要分支、合并和回滚这些快照。
这就像 Qubes TemplateVM vs AppVM。
这个问题对我来说很接近。
Flatpak 可能是在 Linux 上发布桌面应用程序的最佳方式。我是以应用程序开发者、打包者和用户的身份说这番话的。有一次，我维护了将近一打软件包。
我焦急地等待了几个月，看他们下一步会做什么，会推出什么神奇的功能。我在论坛上积极帮助其他用户打包应用程序，帮助审查 Flathub 提交的程序（因为每次都是同样的问题），并开始查看 PR 的进展情况。沉默。
几个月变成了几年，随着时间的推移，我慢慢地不再使用 Flatpak。现在，我又开始使用 AUR（Arch）来处理大部分事情，但我很难过听到这种情况的出现。Flatpak 确实是革命性的；它为所有桌面带来了现代应用程序和无障碍发布（无论是 LTS 还是滚动发布）。但自从多年前它首次起飞以来，它并没有真正发生任何变化。
作为 Flatpaks 的用户，除了安装方便外，我几乎从未有过良好的使用体验。它们几乎从未与系统正确集成过。错误的主题、错误的光标、错误的文件选择器、权限问题、拖放问题。因为某些功能无法正常运行，你往往需要额外的工具来扩大安装后应用程序的权限（Discord 中的全局推送对讲总是很有趣，尤其是在 Wayland 中）。
如果用户体验因此而变得糟糕，我也不在乎沙盒。
如果二进制的可移植性在 Linux 上不是个大笑话，我们就不需要 Flatpak 了，但现在就是这样。
我觉得 Appimage 是 Flatpak 的更好替代品：无需安装，可在 Linux 安装过程中持续运行，主题、图标、Xorg 配置都没有问题；实际上，它的存储空间只有 Flatpak 的几分之一，可选择使用 firejail 等外部工具进行沙盒处理，更容易从终端/dmenu/rofi 运行，非常容易修补和修复。
但有一个问题：如果没有额外的应用程序，它们无法与桌面集成。我们需要一个功能，把 AppImage 放到“~/.local/share/applications ”中，它就会自动检测为“.desktop ”文件，并出现在 DE 菜单中。
> 只有一个问题：如果没有额外的应用程序，它们就无法与桌面整合。
它们最大的问题是无法在不同发行版之间真正实现可移植性。由于用户空间的差异（不同版本、编译标志等），两个发行版的二进制文件有可能互不兼容。内核开发者可能不会在更新之间破坏用户空间，但用户空间开发者肯定会毫无顾忌地破坏用户空间。
当你离开 Ubuntu/Debian 时（因为 Linux 是一个被忽视的平台，当他们想到 Linux 就会想到 Ubuntu），开发者通常会在 Ubuntu/Debian 上构建 AppImage，但这些 AppImage 通常无法运行或出现错误（例如在 Fedora 上）。还有更多问题，比如鼓励人们在从网上下载的二进制文件上设置执行标志的糟糕做法。
Flatpak 完全避免了依赖性问题，因为它使用运行时和命名空间来确保运行时环境的可重现性和稳定性。
对于桌面集成，你可以使用 Gear Lever https://github.com/mijorus/gearlever。它还可以通过一些配置更改来更新 AppImages。
我不同意。Flatpak 优点
– 安装：易于定位、安装，并对更新进行集中管理。
– flatpak 还具有持久性。用户安装在主目录下。
– 内置沙盒。
其他方面无可奉告。没有遇到过问题。
内置沙盒
这既是优点也是缺点。例如，这种方法的一大弊端是会使安装第三方插件和脚本变得更加困难。
在 Ubuntu 上，你可以将 Appimages 与 AppImageLauncher 集成。
https://www.omgubuntu.co.uk/2022/10/appimagelauncher-install…
是的！如果你能在你的发行版上使用它，它会对你很有帮助。
GitHub 链接：https://github.com/TheAssassin/AppImageLauncher
不过我发现 AppImages 的功能并不普遍。有些软件在启动时会出现故障，或者后来出现一些其他奇怪的问题，而它们在作者的系统上应该运行得很好。
但 flatpak 在任何系统上都能正常运行，而且我认为它能提供更多的系统信息，因此运行几率更高。
> 我觉得 Appimage 比 Flatpak 更好。
我也这么认为。
但我认为有一个 “大局观 ”很重要，也很相关：
– AppImage 使用来自 ROX 桌面的应用程序捆绑格式来封装应用程序的需求：https://rox.sourceforge.net/desktop/
– ROX 从 Acorn 的 RISC OS 中借鉴了应用程序捆绑的理念，RISC OS 现在仍然存在，并且是自由和开放源码软件：https://www.riscosopen.org/content/。
– RISC OS 桌面会特别处理名称以 pling（`！`，感叹号）开头的文件夹。它希望文件夹内有一个包含图标、启动脚本等的结构。
– RISC OS 还有一个 “图标栏”，它是 Windows 任务栏的前身
– 一位开发 RISC OS 的 Acorn 工程师被加州的 NeXT Computer 公司挖走。他带走了他的阿基米德。
资料来源：我安排的一次采访：https://www.theregister.com/2022/06/23/how_risc_os_happened/
– 大约一年后，史蒂夫-乔布斯用 Dock 演示了 NeXTstep 0.8
– NeXTstep 还拥有应用程序捆绑包，以名为 $NAME.app 而非 !$NAME 的文件夹为标志。
这是一个普遍且有影响力的想法。这就是 macOS 应用程序的工作方式，也可以追溯到 RISC OS。
如果你有 GNUstep，NeXT 风格的捆绑程序也可以在 Linux 上运行。目前有两种现存的 GNUstep 桌面：
https://onflapp.github.io/gs-desktop/index.html
https://github.com/trunkmaster/nextspace
但有一个发行版更进一步，将整个 Linux 操作系统打包到应用程序捆绑目录中：
https://gobolinux.org/
我认为 Flatpak、Nix、Guix 和 Spack — https://spack.io/ — 的制作者都应该深入研究一下 ROX、AppImage 和 GoboLinux。
如果摒弃古老的 UNIX 对文件系统目录层次结构的假设，所有这些软件都能以更人性化的方式做得更好。
这在很大程度上不是设计出来的，而且在历史上也是偶然的：
https://lists.busybox.net/pipermail/busybox/2010-December/07…
Flatpak 确实能解决这个问题，但更多的是其中的程序没有使用正确的 API，它们本应使用门户的文件拾取器 api，从而使用系统文件拾取器，并通过沙箱安全地拾取门户的内容。但许多应用程序就是不这样做。
主题也是一个奇怪的问题。一般来说，图形用户界面设计已经从操作系统主题转向应用程序/产品主题，不同平台上的产品主题保持一致。例如，Discord 在 Linux、Windows、iOS 和 Web 上的外观大体相同。
即使是那些不使用 GTK 或 Qt 等原生工具包的应用程序（几十年来这一直是个难题），如果可以的话，它们至少也应该响应暗/亮模式标记。Flatpaks 大多不会。
在很多时候，它们甚至没有与系统相同的光标。尤其是在运行显示缩放时，由于系统整合不佳，某些应用程序会将光标缩小到极小的尺寸。
我认为直到最近几年，才有一种标准化的方式来发布系统是在亮模式还是暗模式下。
我认为在 Firefox 中打开 HTML 文件目录是行不通的：它只能打开一个文件，因此样式表和链接都会丢失。
我通过运行本地网络服务器来解决这个问题，但我更希望它能正常工作。有些应用程序通过直接调用网页浏览器来打开文件，也会出现这个问题。
如果里面的应用程序需要专门为其编码，那么为什么它被 “推销 ”为沙盒现有应用程序的一种方式？
我不确定 flatpak 是否有市场。用户可能会这样描述它。
据我所知，如果你使用 GTK 或 QT，它就能正常工作，但许多程序都有自己的自定义文件选择器，当文件系统访问受到限制时，这些选择器就无法工作了。
要充分利用 flatpak，最好将其视为一个新的沙盒发行版，存在于你的主机系统中。例如，你可以检查某个特定主题是否可以作为 flatpak 应用程序进行安装。
flatpak 并不完美，我对 flatpak 也有不满，但唯一的选择就是 Ubuntu 的 snaps。
Ubuntu 的 Snaps 严重依赖 AppArmor，而其他许多使用 SELinux 的顶级发行版都没有 AppArmor，所以它不是替代方案。
语义。Ubuntu 是其他 “顶级 ”发行版的替代品。
你提到的很多问题都已经解决了。
例如，“在 Discord 中使用全局推送对话总是很有趣，尤其是在使用 Wayland 时”，通过使用 [全局快捷方式门户](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr…) 就可以解决。
大多数桌面环境/窗口管理器都支持该入口，Electron 等产品也是如此。例如，使用 Slack（安装在 Flatpak 上）时，即使我不关注 Slack，也能切换静音。
Fedora 上的 STEAM 需要在 CLI 上念一堆咒语，才能在 Flatpak 安装后获得控制器支持。这几乎巩固了它作为一种格式的缺陷。“赌注 “应用程序应该可以正常运行。
例如，如果一个应用程序试图查询环境并询问 “主题是什么”，当它从一个 flatpak 中运行时，怎么会得到不同的答案？
不同的问题有不同的答案，但基本上有两个原因。
首先，flatpak 中的库/软件/数据版本可能会与外部版本不同。因此，flatpak 可能会问 “当前的 Qt5 主题是什么”，而得到的答案是 “不知道 Qt5，但 Qt6 的主题是 cute-cats-qt6”，这是它无法解释的。在 flatpak 中可能根本就没有主题之类的东西，因此即使答案可以解析，cute-cats-qt6 也可能只是在内部不可用。
其次，flatpak 是沙箱式的，因此会过滤一些东西。这意味着查询可能无法通过，答案可能无法通过，两者都可能被修改。或者，答案可能毫无用处，因为 “你可以在 /usr/share/themes/cute-cats-qt6 获取主题 ”指向的路径是 flatpak 不允许访问的。
这也许是个矫揉造作的例子，但如果 Qt5 应用程序询问主题是什么，Qt6 难道不应该给出兼容的答案吗？难道应用程序不应该问 “主题 ”是什么，而不是 Qt5 的主题是什么吗？这似乎是为不同版本 Qt 构建的应用程序之间的根本兼容性问题，而不是 flatpak 的问题？
如果应用程序无法从环境中访问它们需要的东西，那么沙盒是否走得太远了？
如果 Linux 库如此尊重向后兼容性，那么 Flatpak 就不会有任何需求。Flatpak（和 snap）不过是一种变通办法，用来解决缺乏一个通用的 “Linux 平台 ”的问题，这个平台拥有类似于 Windows API 或 Android API 的全面的、版本化的 API。毕竟，Flatpak 本质上提供了一种在主机发行版中运行发行版（由 Flatpak 运行时提供）的方法。
我认为发行版的作用就是为不同版本的 gtk 和 qt 集成一个共同的主题。 是的，它经常是用胶带粘起来的。但除了 freedesktop 之外，我们还没有一个组织为图形应用程序如何与发行版交互之类的事情规定一个通用的 API。
其实我也不知道，但我猜问题在于主题/gui 库也是沙盒的。
你根本不需要 Flatpak 就能解决这些可用性问题，问题远不止于此： 例如，如果你在 Linux Mint Cinnamon 文件资源管理器中挂载了一个 samba 共享，从那里使用它就很好。从 “外部 ”应用程序访问已挂载共享中的文件却很麻烦（共享被挂载到某个模糊路径（权限问题），应用程序的文件拾取器从未获得共享已被挂载的信息，等等）。如果你想对 samba 共享进行有用的访问，就必须通过终端来加载它；这样至少通向共享的路径很短。
我认为这是因为很多 gtk 应用程序都使用 gvfs[0]。而大多数 kde 应用程序使用 kio[1]。但如果你想通过标准系统调用访问文件。就必须使用标准挂载程序或 fuse。
0: https://en.wikipedia.org/wiki/GVfs
1: https://en.wikipedia.org/wiki/KIO
这不是用户体验，而是主题。如果主题影响了用户体验，那就没法取悦你了。
的确，我对 flatpak 很满意，但我从不偏离默认的 GTK 主题。
在发现 Flatseal 之前，我一直对 flatpak 不满意，现在我在所有的工作站设置中都使用了它。
但遗憾的是，我在主题方面帮不了你，我想这是很多喜欢自定义 Linux DE 的用户的痛点。
我也有同感。就像几年前，Fedora + GNOME + Flatpak 是神奇的调味汁。现在已经不是那么回事了。我现在又回到了 Arch，它的软件包库似乎只增不减。虽然 AUR 还在，但我对它的需求之少感到震惊。
问题，因为你维护了很多软件包：
> 我又开始使用 AUR 了。
那你有没有试过把 makedeb 作为第二渠道？https://www.makedeb.org/ 它使用 PKGBUILDs，所以很容易翻译。它似乎非常适合帮助打包者，我不知道为什么没有听说过它。
我并不完全同意他的观点，但我总觉得德鲁-德沃特在这个问题上很有思想：
https://news.ycombinator.com/item?id=32936114
https://drewdevault.com/2021/09/27/Let-distros-do-their-job….
基本上，他认为在发行版之外发布应用程序（如 flatpak、snap、appimage）是一种糟糕的模式。正确的模式是发行版多年来一直使用的模式： 你通过发行版的软件包管理器获取软件，而这些软件是由代表发行版工作的人员打包的。正如他所说：”软件发行版通常由志愿者运营，代表用户的利益；从某种意义上说，它们是一种用户联盟。
当然，另一个问题是，在实践中，flatpaks/snaps/appimages 似乎从未像发行版软件包那样 100% 运行良好。
我不同意这种说法。在我看来，为应用程序创建软件包的最佳人选是该软件的原始开发者。如果该软件是专有的，那么无论如何，这也是唯一可以合法地这样做的一方。因为这通常需要获取源代码，而软件的再分发需要得到许可。
因此，你提到的模式只适用于开源软件包。我认为，即使在应用程序 100% 开源的情况下，让不属于核心开发团队的人去猜测应用程序的许多事情也不是一个好主意。
这会导致很多不必要的问题。比如在开发者发布新软件和第三方进行他们认为必要的不请自来的调整，或添加他们自己的错误和新问题之间出现不必要的滞后。
这就是为什么我总是直接从 Mozilla 安装焦油球形式的 Firefox。一旦开发人员确定了某个补丁，它就会自动更新。这种情况经常发生，主要是出于安全和稳定性的考虑。他们一发布补丁，我就想要。外部发行版维护者所做的事情都是多余的。我相信 Mozilla 会做正确的事，并且最了解有关他们自己软件的任何问题。对于专有软件，我只希望它们能在运行时尽量减少麻烦。
Flatpak 试图做的事情太多了。它试图模仿应用程序商店。我并不一定喜欢应用商店。它们是把关人。Windows 和苹果的开发者会怎么做？他们把二进制文件放到自己的网站上。你下载它们。你安装它们。然后运行。下载的应用程序与通过应用程序商店提供的应用程序拥有相同的权利。应用商店不会重新打包应用，而只是分发它们。这是一项附加服务。可有可无的附加服务。所有提供安全性的基本要素都已植入操作系统和应用程序软件包。Windows 和 Mac 提供了一些机制来确保安全。二进制文件都经过签名，操作系统有一个权限模型，用于处理需要这样做的事情（屏幕共享、目录访问某些内容、使用网络摄像头等）。这才是正确的模式。这也适用于 Linux。它不应该要求第三方控制发行或打包。
Flatpak 更像是一套工具和框架。我认为它不是一个存储库，而是一个分发系统。Flathub 是一个资源库，Fedora 有自己的资源库，任何人都可以创建自己的资源库（我不会称其为商店，因为没有货币化的概念）。
我不认为 flatpak 是一个看门人，因为没有一个 “团队 ”会通过任意的程序来允许或不允许一个应用程序。
我也不同意 macos 和 windows 所做的事情是正确的这一说法，我在一家公司管理笔记本电脑时发现，该公司的笔记本电脑中大约有 1/3 是 windows，1/3 是 linux，1/3 是 macos： – windows 教会用户的是随意下载，如果没有签名，就绕过警告屏幕。除非有公司政策和第三方软件来更新安装的软件，否则默认情况下安装的软件都是最新和未更新的混合体。- Macos 用户不安装操作系统和软件更新，除非安装了第三方软件并强制他们安装；Linux 用户安装的软件都是最新的，只有发行版更新（如 fedora 41 到 fedora 42）不一致。
因此，我的看法是，即使 flatpak、rpm/dnf、fwupdmgr 和软件包管理器并不完美，但这总比在 macos 和 windows 中因为缺乏在操作系统层面分发和维护应用程序的好方法而不得不花钱购买第三方工具要好得多。
据推测，只有 fedora 可以把东西放到他们的 flatpak 仓库中。这让他们成了守门人。为什么需要版本库？如果情况相同，Mozilla 就可以在自己的网站上为 Firefox 安装 flatpak 文件，这将是安装 Firefox 的首选方式。
当然，每个人（包括 Mozilla）都可以创建自己的版本库，然后你可以从任何你喜欢的版本库中进行安装。但这与随便下载安装有什么区别呢？这更像是一种假设。Mozilla 并没有这样做，而且这样做并不常见。
苹果和微软通过签名强制执行的是，你所安装和运行的内容是由某个拥有有效证书并通过其筛选的人制作的。
flatpak 没有解决的问题是，像 Mozilla 这样的公司仍然没有好办法向所有 Linux 用户发布其应用程序的最新版本。因此，他们只能把焦油球放在网站上。
Mozilla 在 Flathub 上发布了 firefox，任何人都可以从那里安装。之后，我不知道他们为什么不做广告，因为大多数以这种方式发布的应用程序都有一个安装按钮。
Fedora 有自己的 repo，他们负责管理，我看不出有什么问题。这并不妨碍添加其他软件，比如 flathub，而且从用户角度来看，体验也是一样的。
你也可以提供一个 flatpak ref 文件，用户可以用它来安装。
签名应用程序并不意味着什么，除了有人为此付费并经历了一个过程之外，从用户的角度来看并没有什么价值，尤其是当 Windows 用户学会的第一件事就是忽略签名警告时。
你试过使用 flatpak 吗？
我认为你说得很对，不要依赖一个开源操作系统来为每个应用程序提供适当的部署、定制和训练轮。我在台式机上使用 Linux 已经有 20 年了，使用 Mint 大约 10 年，使用 Fedora 也是 10 年。作为一个好奇但挑剔的人，我安装了很多软件，看看哪些有效，我发现大约每 18 到 24 个月就需要安装一个全新的操作系统。
我想，总有一些程序不会被 “sudo dnf update ”更新，但却会被共享库的更新所困扰。也许有些配置文件会因为软件错误、断电、系统崩溃或我自己的失误和粗心而损坏。我还发现，如果一个人丢失了 dnf 程序，就会发现自己是多么不可能自力更生。
薄荷的情况也很类似。对于一个循规蹈矩的人来说，也许情况还不算太糟，但在过去的那些日子里，有人建议从 ubuntu 或 debian 软件仓库中下载更新版本来更新 Mint 程序，这不失为一个好主意。由于 Mint 的更新速度很慢，我会尝试通过下载源代码并在这里构建和安装来更新一些应用程序。
去年，当我把 Fedora 从 39 升级到 41 时，这是我第一次成功升级操作系统，而不是擦除磁盘，重新安装新版本的操作系统，然后花一周或一个月的时间从备份中获取已安装应用程序（如网络浏览器和电子邮件）的数据。但是，升级所花的时间远远超过了它应该花的时间，因为一旦我开始运行升级程序，我就不知道电脑静静地坐在那里，屏幕上没有任何动静，持续了大约 30 个小时，这就是一切顺利的标志。电脑真是邪恶。
在 flatpak 中，除了 flathub，还有其他版本库，因此理论上，开发人员可以在自己的版本库中打包应用程序，并告诉用户进行安装
问题是，现在你必须为 N 个发行版打包。而运行发行版的人可能不想花时间在这上面，所以你必须自己动手。
不一定非得由 “运行发行版的人 ”来把关。我开始为我使用的发行版打包一些软件，是因为我想使用这些软件，我并没有以任何身份 “运行 ”发行版。软件包维护者并不是生来就是这样的，他们是自愿成为这样的人的，就像 Linux 中的大多数东西一样。
如果连一个用户都不愿意为他们使用的发行版做这样的事，那你的发行版可能无论如何也不会有用户了。
> 软件包维护者并非天生如此，他们是通过志愿服务才成为这样的人，就像 Linux 中的大多数东西一样。
我觉得在这个问题上一直存在着拉锯战。如果让应用开发者来做，他们就必须为 N 个发行版打包他们的应用。如果让发行版维护者来做，他们就得为自己的发行版编译 N 个应用程序。考虑到发行版的不同以及应用程序在质量、方法等方面的差异，我并不羡慕这两类人。
我看看 Podman。在我看来，它本可以（本来也可以？）成为一个巨大的颠覆者，但它的 RedHat（或 Fedora 或 CentOS，或那些家伙现在做的什么鬼东西）版本远远高于其他发行版的版本，这给我（只是一个家庭用户）的所有不同 Linux 盒子之间的互操作性造成了问题。如果有人说 RedHat 有能力解决这个问题，但我猜他们更愿意用这个问题来强迫用户采用他们的发行版。我都不知道。
应用程序和发行版都是志愿者的天下。对任何一方来说，应用程序打包都是一项艰巨的任务。我仍然希望 Flatpak 能对这项工作有所帮助
这是对资源和时间的巨大浪费。
例如，在一个没有 Flatpak 的世界里，只有拥有 X 用户的发行版才能存在。而在有 Flatpak 的世界里，则可以有 X/10 用户的发行版。
换个角度想：如果你想制作/使用自己的发行版，那么使用 Flatpak 将使你的工作量大大减少。你有不使用它的自由，就像你有在家里安装定制插座的自由，也有为你购买的每件电器制作定制适配器的自由。
标准化/集中化的存在是有原因的。
你说的与原意正好相反，原意是：你不应该为发行版打包，发行版应该为自己打包。你只需发布你的源代码。
你是为你的发行版打包的好人选，所以这就是问题所在。对于一个随机发行版来说，如果没有人愿意为它打包，那么它就是不存在的。要么是对你的项目没有足够的兴趣，要么是对发行版本身没有足够的兴趣。
> 发行版应该自己打包。你只需发布源代码。
Devault 的基本意思是不是说，应用程序开发者应该把源代码扔到墙上，希望其他各方注意到并找出正确的构建方法？作为开发者，我认为这种软件发布模式并不令人满意，因为仅仅发布源代码压缩包，而将其余部分留给中间商，这让我很难预测用户将如何体验最终产品。即使我的产品是完全开源的，可以自由分叉，但一旦出现问题，我的声誉也会受到影响。我更愿意与用户建立更直接的关系，亲自在我支持的所有环境中构建和测试我的软件，并在用户遇到问题时直接听取他们的意见。
> 即使我的产品是完全开源的，可以自由分叉，但如果不能按预期运行，我的声誉也会受到影响。
我认为，每个担心这个问题的人都希望在开源模式上应用企业思维。也就是说，他们想成为一个特殊的东西，所有东西都应该是可以互换的。就在昨天，我还在编译一个程序，该程序仅有 2 个函数依赖于 GNU C 库，其中甚至没有关键函数。为了公平起见，作者说他们只在 Debian 上进行了测试。
虽然 linux 世界可能是支离破碎的，但真正的差异大多微乎其微（systemd 与其他 init 系统、glibc 与 musl、网络管理器……）。但开发者往往会依赖于他们偏好的发行版团队的决定，并创建一个复杂的构建脚本，而这个脚本只能在发行版中运行。
我不知道 Devault 是怎么说的，但我的观点是：不要发布你自己都不理解/测试/使用的东西。
发行版不应该随意打包他们不使用/不理解的开源项目，开发者也不应该为他们不使用/不理解的发行版打包他们的项目。对这两者来说，这就像运送未经测试的代码，结论总是 “你们都应该运行和我一样的系统 ”或 “我们都应该拥有完全相同的系统，让我们实施 Flatpak 吧”。
开发者应该为他们支持的发行版（通常只是 Ubuntu）打包他们的项目。随意的人应该把他们想用的开源项目打包到他们选择的发行版中（发行版越受欢迎，别人已经打包的可能性就越大）。所有这些都要在发行版维护者的监督下进行。
> 发行版应自行打包。你只需发布你的源代码。
这就是过去在 Ubuntu/Debian 上 Erlang 被分成 20 多个软件包的原因。因为打包它的人对 Erlang 一知半解，而且可能时间太紧。
这就是主要问题所在：你想让发行版维护者编译和打包阳光下的每一个软件，但他们不可能了解每一个软件，不可能知道它是如何工作的，也不可能知道它应该如何工作。用发行版的数量乘以这个数字。
> 你想让发行版维护者编译和打包天下所有软件？
不，我希望真正使用软件包的人来打包他们需要的软件，并由发行版维护者来监督。
> 因为它是由对 erlang 一知半解的人打包的
没错，不会使用 Erlang 的人不应该打包 Erlang。但另一方面，不会在 X 平台上使用 Erlang 的开发者也不应该在 X 平台上打包 Erlang。
在我看来，“我们绝对需要 flatpak，否则它从根本上就行不通 ”的理念与 “我们必须把所有东西都整合到一个操作系统下。每个人都应该使用完全相同的东西，否则就行不通”。这不是我想要的。我想要自由，而自由的代价是我可能不得不时不时地打包一些东西。
如果你不想为你的发行版做贡献，那就选择一个超级流行的发行版，那里所有的东西都已经打包好（而且已经用过！）。或者使用 macOS。或者使用 Windows。你没资格抱怨 Alpine Linux 没有你想要的软件包：你选择了 Alpine，这就是交易的一部分。
对于那些不必要依赖 glibc 和 systemd 的程序来说，Alpine 是一块很好的试金石。通常情况下，使用 Arch 构建脚本并为 Alpine 创建一个软件包很容易。如果失败了，通常就是因为上述原因。
> 我希望人们能真正使用软件包来打包他们需要的软件，并由发行版维护者来监督。
呃… 你最初的评论说 “你不应该为发行版打包，发行版应该为自己打包。你只需发布你的源代码”。
> 是的，不使用 Erlang 的人不应该打包 Erlang。但另一方面，不会在 X 平台上使用 Erlang 的开发者也不应该在 X 平台上打包 Erlang。
那么……如果你说发行版应该打包，那么谁来打包呢？
> 在我看来，“我们绝对需要flatpak，否则它从根本上就行不通 ”的理念非常接近于 “我们必须把所有东西都整合到一个操作系统下”。
胡说八道。
你主张的是 “何必考虑易用性和便利性，每个人都应该学会如何从头开始编译和打包一切”。
> 如果你不想为你的发行版做贡献
软件包的用户并不一定知道如何打包，也不需要知道。
> 呃… 你最初的评论说 “你不应该为发行版打包，发行版应该为自己打包。你只需发布你的源代码”。
是的，我说的是 “发行版”，而不是 “发行版维护者”。发行版是维护者+打包者，打包者可以是随机贡献者（我在需要时为我的发行版打包，但我不是发行版维护者）。
> 那么……如果你说发行版应该打包，谁来打包？
会在该发行版上使用 Erlang 的人。在发行版维护者的监督下。通常会有某种等级制度，其中有 “社区 ”软件包，它们只是 “未经测试的”（有时它们会被提升到更可信的级别），而 “核心 ”软件包则由发行版维护者负责。
> 你的主张是 “何必考虑易用性和便利性，每个人都应该学会如何从头开始编译和打包一切”。
完全不是，但你似乎不知道传统发行版目前是如何工作的，也不明白我在说什么（可能是我没说清楚，那是我的问题）。
我所主张的似乎是绝对的常识：“软件包维护者应该了解并在为其打包的发行版上使用软件包”。
Ubuntu 或 Arch 的绝大多数（可能几乎是全部）用户从来都不需要打包任何东西，因为所有东西都已经在那里了。因为这些发行版非常受欢迎。根据你所选择的发行版，可能会出现某个软件包尚未被贡献，甚至无法编译的情况（例如，如果你使用的是 musl）。在这种情况下，如果你想要它，就需要贡献它。但如果你使用 musl，你就默认接受了这一点，并且应该知道自己在做什么。
> 软件包的用户不一定知道如何打包，也不需要知道。
这是你的观点。我认为，Gentoo用户应该对编译软件包有所了解，否则他们就不应该使用Gentoo。Ubuntu的目标用户是那些不想知道它是如何工作的人，这也很好。多样化是好事。
我不喜欢的是那些有Windows思维的人（“我不应该了解我的电脑是如何工作的”），他们来到Linux，并要求每个人都像他们一样。“我们都应该使用 systemd 和 Flatpak，并支付一个由 50 人组成的团队的费用，让他们了解系统是如何工作的，而我们其他人只需使用它，不必了解它” -> 我不同意这种说法。有这种想法的人应该使用 Ubuntu/Windows/macOS，别来烦我。至于那些使用 Ubuntu 的人，他们下次说 “它是狗屎，因为它不能完全满足我的要求 ”时，应该记住他们并没有为 Ubuntu 付过钱。
> 打包者可以是随机贡献者
那么谁来维护软件包？谁来针对其他软件包进行测试？针对发行版的升级？谁来修复问题？
> 根本不是这样，但你似乎不知道传统发行版目前是如何运作的。
我知道。打包、维护、修复、测试大量软件包的工作只有少数人在做，而他们的工作却不必要地重复。
而他们的工作却不必要地在多个打包系统中重复。
> 我不喜欢的是那些有 Windows 思维的人（“我不应该去了解我的电脑是如何工作的”），他们来到 Linux，并要求每个人都像他们一样。
我不喜欢的是人们在 “你知道什么会很棒吗？如果我们不假定每个用户都必须在 15 种不兼容的打包系统中打包他们自己的软件包”。
> 那么谁来维护这些软件包？谁来测试它们是否与其他软件包兼容？针对发行版的升级？谁来修复问题？
我觉得你没看懂我在写什么。社区。
这就是开源的工作方式：如果你使用了一个开源项目，而它有一个 Bug，你可以修复它，然后打开一个 MR。如果上游项目不想要你的修正，你可以 fork。没有什么能强迫上游项目接受你的贡献。如果上游项目接受了你的贡献，他们就会对你的贡献负责（在某种程度上，你的贡献现在是他们代码库的一部分）。
如果你的发行版没有你想要的软件包，你可以自己在本地制作。你可以把它贡献到社区软件仓库（大多数发行版都有这样的仓库）。也许在某个时候，发行版的维护者会决定将你的软件包放到更官方的 repo 中，也许不会。即使你不是软件包的官方维护者，如果你在使用它时发现了问题，你也可以贡献一个修复程序。
在开源世界中，大多数人都是自由主义者。有一部分人（很大一部分）觉得自己有权利，简直就是混蛋。也有少数人不是自由使用者，而是真正的贡献者。这就是问题所在。
> 他们的努力在多个包装系统中被无谓地重复。
不！不不不！如果他们不想为此付出努力，大可不必。他们可以使用 Ubuntu、Windows 或 macOS。如果他们为 Alpine 或 Gentoo 做贡献，那是因为他们愿意。我使用 Gentoo 并不是希望它变成 Ubuntu，那样就太奇怪了。但听你的口气，你是想通过让 Gentoo 看起来更像 Ubuntu（在想法上）来解决 “我的 Gentoo 问题”。如果你不想用 Gentoo，那就别用，别来烦我！不要试图解决我的问题，你甚至都不是 Gentoo 用户。
> 这就是开放源代码的工作原理：
有趣的是，实际上开源并不是这样的。软件包是由极少数的维护者集体打包和维护的，他们的工作是吃力不讨好的。而不是由某个 “社区”，即 “使用软件包的人 ”突然醒悟过来，说 “你知道，我要把这个软件打包”。
这就是我在最初评论中以 Erlang 为例的原因。
> 在开源世界里，大多数人都是自由爱好者。
我已经厌倦了你的咆哮和喋喋不休
> 不 不，不，不，不！如果他们不想在这方面下功夫，也没必要。他们可以使用 Ubuntu
你是在故意错过和/或忽略重点。
有多少软件包管理器和软件包格式？为它们中的每一个打包一些代码都是在浪费/重复劳动，因为这是在为同样的代码（例如 Erlang）做同样的事情（打包），而且是在字面上相同的操作系统（Linux）上，而这仅仅是因为某人对 “唯一正确的方法 ”有一种非常主观的看法。
所以，现在有人把 Erlang 打包成 dpkg、flatpack、nix、pacman、rpm、snap，可能还有其他一些，因为 “人们不是白吃白喝的人 ”或 “没有 Windows 意识的人”，或者其他一些意识流。
> 如果你不想用 Gentoo，就不要用，别来烦我！不要试图解决我的问题，你甚至都不是 Gentoo 用户。
我该说的都说了。你故意只跟你脑子里的声音说话。对不起，我不知道这些声音。
那么，再见了。
> 有趣的是，在现实中开源并不是这样运作的。
让我复制完整的句子，把你顺手截掉的部分也复制下来： “这就是开源的运作方式：如果你使用了一个开源项目，而它有一个 bug，你可以修复它，然后打开一个 MR。如果上游项目不想要你的修正，你可以 fork。没有什么能强迫上游项目接受你的贡献。如果上游项目接受了你的贡献，他们就会对你的贡献负责（在某种程度上，就像：你的贡献现在是他们代码库的一部分）”。
你能解释一下这有什么错吗？
> 我已经厌倦了你的咆哮和切入点
这怎么会是咆哮呢？这几乎是我的设计： 我将我的代码开放源代码，这样人们就可以在某些条件下免费使用。就拿运行 Linux 的数十亿台电脑来说吧。你认为其中有多大比例是由真正为 Linux 做出贡献的人运行的？一个很好的近似值是 ~0%。几乎所有的 Linux 用户都不会为 Linux 做出贡献。这是事实，不是咆哮。
我可没说人们应该为 Linux 做出贡献。
> 有多少软件包管理器和软件包格式？
谁在乎？如果我想用新的软件包格式创建一个新的软件包管理器，你为什么要禁止我这么做？我就是这个意思：人们可以自由地做他们想做的事。你的意思是，我必须使用 Flatpak 而不是我最喜欢的软件包管理器，因为你认为它对所有人都更好？
为什么只限于软件包管理器？在你看来，使用不同的操作系统难道不是浪费/重复劳动吗？难道我们都应该使用 Windows 系统，因为它是你的最爱，而你却不理解为什么其他人会有其他偏好？
> 对不起，我不了解这些声音。
我的观点是，每当有人说 “这很愚蠢，我们都应该使用 X ”时，我的回答总是 “如果 Y、Z、A、B、C……存在，那是因为其他人出于某些原因不想要 X。因此，还有其他选择。多样性是好事”。
多样性是好事。我不是说 Flatpak 不应该存在。我只是说，不管是谁想让我使用 Flatpak，从根本上讲，他都缺少了一些东西。
应用程序开发者应该能够打包和发布应用程序。看看普通用户在 Windows 上下载和安装任何应用程序有多容易。维护者无法扩大规模，依赖他们只会阻碍桌面 Linux 的发展。
未经审查的应用程序商店的最大优点是任何人都可以发布软件！
未经审查的应用程序商店最糟糕的一点是，任何人都可以发布软件！
Flathub 并非未经审查。每个提交的软件都要经过人工审核。如果一个软件需要不必要的权限（例如，如果有人提交的闹钟程序需要访问家庭文件夹和互联网），它就会被拒绝。如果开发者更新了软件并更改了所需权限，那么在通过人工审核之前，更新不会推送给用户。
此外，对于开源软件包，代码会在 Flathub 的构建服务器上构建，无需互联网访问。与特定 Flathub 软件包版本相关的源代码必须是特定的 Git 提交（通过提交哈希值验证）或发布压缩包（通过 sha256 哈希值验证）。这意味着始终可以验证开发者发布的代码是否与发送给用户的二进制文件一致。封闭源代码包的 Flathub 页面上会有一个很大的警告，说明程序代码是专有的，不可审计。
在传统的发行版打包模式中，成为维护者的要求非常严格，在添加软件包时会有人工审核，但之后通常就没有审核了。如果您想了解这一系统弊端的最新实例，请参阅：https://security.opensuse.org/2025/05/07/deepin-desktop-remo… 。在 OpenSUSE 安全团队以 Deepin DE 包含重大安全问题（包括多个 root 权限升级漏洞）为由拒绝了 Deepin DE 的某些组件之后，Deepin 的维护者还是通过一个名为 “deepin-feature-enable ”的看似无害的软件包将其偷偷塞了进去，而安全团队几年来都没有人注意到这一点。我并不是想在这里指责 OpenSUSE 安全团队，我相信他们没有足够的资源来审查随机的软件包。我想说的是，传统发行版打包模式的一个弱点是，期望维护者不会因为他们通过了成为维护者的程序而发送恶意代码。
在阅读了所有关于崩溃和一般不起作用的东西后……我觉得似乎不太可靠。
发行版软件包维护者不是安全研究人员，他们不会审核自己维护的代码。
在较大的发行版中，他们会在一定程度上进行审计，但对于专有/二进制软件包，除非他们愿意进行一些相当耗时的取证工作，否则他们根本没有什么机会。
对每个软件包都进行取证将是一项艰巨的工作，大多数情况下只是版本+哈希值更新，也许还要进行测试。
是的，我在一家安全公司工作。不过还是谢谢你比我自己还了解我的生活，随机的互联网人。
这是假的。
另外，应用程序开发者至少要承担一定程度的责任。就像 JWZ 与 Debian 的冲突一样（此处无法链接）。你可能以为自己运行的是伟大的 Zawinski 的 XScreensaver，但实际上你运行的是 godknowswho 的某个奇怪的分叉，但愿不是 Jia Tan。
XScreensaver 应该是用来隐藏桌面的，而 Jia Tan 是隐藏东西的专家，所以我觉得他们是绝配。
你被降权了，但没错，当发行版发布一个与原版同名的软件包，但却打上了自己的补丁时，这是很可悲的。我认为他们应该重新命名软件包，哪怕只是加上发行版名称的前缀/后缀也不错。
没有用户会在意。如果他们在乎，他们就会从头开始构建一切：)
> 软件是由代表发行版工作的人员打包的。
指望发行版能够打包世界上所有软件是完全不合理的。
我很高兴 flaptaks 被更多人采用。应用程序发行版需要从发行版中分离出来，因为它们做得很烂。这不是他们的错。开发者应该可以选择在没有中间商的情况下发布自己的应用程序。
事实上，我认为发行版的稳定性更胜一筹。例如：我对 Debian 的意见一直是，你不能（很容易，我知道有反向移植）拥有稳定的系统和新鲜的软件。有了 Flatpack，你就可以了。
现在，我可以在稳定的发行版上运行最新的用户软件。这很酷。
用户体验仍有问题。尤其是当你正在使用的应用程序没有足够的权限来完成工作时，你没有任何关于它的信息，而当你自己猜测它的时候，改变它是很困难的。
我希望 Flatpack 能够允许应用程序实时或在尝试访问外部资源时专门请求权限，就像在 macOS 中那样：只需公开 API，但让它们等待用户批准即可。
> 现在我可以在稳定的发行版上运行我最新的用户软件了。这很酷。
我有点不知所措。稳定发行版的全部意义不就是没有最先进的用户空间吗？这本来就是一把双刃剑。
如果你只想混搭，你总能在 debian 稳定版下运行（比如）一个 debian 测试 chroot。像 Nix 这样的东西就是这种情况的极端版本。Flatpak 之类的东西，要么是沙盒，要么是发行模式（即从原作者那里获取软件）。
这些天，我对 Debian 稳定版情有独钟，因为人们在软件更新方面玩起了 “牛仔 ”游戏，破坏了工作流程。对于边缘软件来说，总是有虚拟机的。
分解得不错。我是 Linux 新手，不知道这些：
> 即使主机系统使用 PipeWire，Flatpak 仍然使用 PulseAudio。问题在于 PulseAudio 将扬声器和麦克风的访问权限捆绑在一起–你可以同时访问这两个设备，也可以两者都不访问，但不能只访问其中一个。因此，如果一个应用程序有播放声音的权限，那么它也有捕捉音频的权限。
这是一个相当大的漏洞。
我有时会看到 Linux 用户对 Windows 和 Mac 的设计错误或缺乏 “自由 ”嗤之以鼻……但就是有这样的事情发生。
当然，Linux 又会被重新定义，让人觉得没有人可以为此负责，在每个问题上都指手画脚，而不承认像这样的设计缺陷困扰着整个 Linux。
我知道你已经先发制人了，但是： Flatpack 是 Linux 上的一个奇怪的额外层。大多数发行版的软件包管理器都能正常工作。这些软件包管理器早于 Flatpack，而且基本上是发行版提供的主要功能（当然，除了社区之外）。
但从这个角度来看，这些应用程序就更糟糕了，我无法控制哪些应用程序可以访问我的摄像头或麦克风。
我个人很失望，沙盒在 Linux 中并不那么容易实现。我希望它能超越 Windows 和 Mac，想象一下，在这个世界上，大多数库也都是沙盒化的，我们只允许压缩和解压库读取一个数据流并写入另一个数据流，这将提高安全性。谷歌（在 Android 中）和苹果（在 iOS 和 Mac OS X 中）都已经这样做了，但在 Linux 中还没有得到普遍接受（据我所知）。
也许如果有人制作了付费的 Linux 桌面版本，他们就可以花钱雇人来设计沙盒和商店。
听起来似乎没有多少志愿者觉得这很有趣（这并不奇怪，因为这听起来非常乏味、高风险，而且工作起来很烦人）。这不是人们会免费做的事情，而且商业模式也不明显……激励机制不在这里。
因为在 Linux 上，一切都以可信安全为基础，因为你可以访问源代码，而在 iOS 和 Android 上，你安装的每一个应用程序都可能是恶意软件，所以这些系统以不可信安全为基础。
这是在假设从未出现过零日或其他未修补漏洞的情况下。您不应该因为可以访问源代码而信任应用程序。没有人会主动审核绝大多数的开源代码，除了恶意行为者，他们可能在很多 RSS 阅读器、聊天应用、微博客户端等中都有少量的远程控制，他们可以利用这些远程控制来控制激进分子和天真到相信桌面 Linux 的记者。
很多 Android 漏洞都是未受信任数据的开源解析器（如 AOSP 或更广泛使用的开源库中的开源解析器）中的漏洞。但影响较小，因为 Android 有适当的安全边界。如果桌面 Linux 像 Android 一样流行，我们将面临一场史诗级的安全灾难。
但与此同时，当涉及到我的私人数据时，我仍然更信任 Linux 发行版，而不是我的手机。
我的 Linux 发行版没有内置的广告 ID，没有我连看都不敢看的未知制造商修改，也没有比我更强大的黑幕进程。
我认为，现在是时候让科技界超越技术层面，明白安全也是一种社会契约了。
在手机上安装 GrapheneOS，问题就解决了？您将获得安卓系统的所有安全沙盒和分层功能（加上 Titan M2 安全元素）。你还可以决定使用哪些应用商店，以及是否接受沙盒谷歌游戏服务。
这只是一个支点，如果你没有良好的安全性，那么你的隐私就一文不值。
具有讽刺意味的是，Mac OS X 是目前商业操作系统中隐私保护做得最好的。
在当今世界，对你的数据的攻击比对内核的针对性攻击要常见得多，因此我认为两者的顺序正好相反。没有隐私就没有安全。
> 具有讽刺意味的是，Mac OS X 是目前商业操作系统中隐私保护做得最好的。
这个标准很低，OSX 仍远低于 Linux 发行版
哈哈哈，你的态度太搞笑了，你真的认为 F/OSS 意味着整个供应链都可以给予隐性信任。我可以访问源代码，这对发现漏洞或利用漏洞有什么区别？
有一次，我在大学里慷慨激昂地为开源辩护时引用了莱纳斯定律。我得到了应有的纠正。因为莱纳斯定律确实没有任何现实依据。
https://en.wikipedia.org/wiki/Linus%27s_law
Linux 之所以有这样一种盲目信任系统服务和应用程序的模式，是因为它基于 Unix，而 Unix 的模式更加天真，因为大多数情况下，都是管理员和授权用户在安装这些东西，有更多的自上而下的监视和控制，只是赤裸裸的恶意事件比较少。
这与我们在早期版本的 Windows、macOS 或互联网中看到的情况如出一辙。看看 90 年代中期的互联网。它安全吗，上面运行的都是开放源代码？当然不安全。每个操作系统和协议都会受到攻击，每个操作系统和协议都会根据现代威胁修改安全模型。F/OSS 谁也救不了，几乎什么也减轻不了。
要回答 GP 的问题，沙箱技术必须在事后被安装到 Linux 中。Linux 的 POSIX 模型是如此古老，需要如此兼容。在 SVR3 Unix 中，唯一的沙箱功能就是 chroot(2)，你知道吗？Docker 支持、cgroups 和虚拟化都是新的层级，需要仔细整合。没人说 F/OSS 不需要沙箱。也没人说 F/OSS 安全到可以偏离更好的安全模式。恰恰相反。
大部分情况下，安卓和 iOS 都是干净的起点；不需要向后兼容，因此它们能适应你所描述的对抗性计算的最新威胁模式。但你在 Linux 上安装的每一个应用程序也都可能是恶意软件。我不知道什么是 “可信安全 ”或 “不可信安全”，但它们并不是网络安全领域的真正术语，也无法描述 Linux 安全的起源或演变（Linux 安全通常有很多未使用的缓解措施，如 AppArmor 或 SELinux，但很快就会被关闭）。
这是一种诡辩，当然它并不完美（没有什么是完美的），但我仍然相信这种模式，而不是 Android 或 iOS，因为它们有内置的广告 ID、我甚至无法查看的制造商修改以及比我更有权力的黑幕进程。
安全也是一种社会契约。
是的，大多数房子的门锁都经不起一脚重踢，但在安全系数较高的社区，人们也只能这样做。但在信任度较低的社区，每个人都会在窗户上装上钢条，并为每扇木门加装一扇钢门。
因此，在软件包管理器模式下，仍然会有坏人出现，但像 Adobe 这样蔑视用户代理的情况就不太可能发生了。
因此，我对发行版及其维护者的信任超过了对苹果公司的信任。而苹果公司已经通过 iOS 掌握了我的大部分数据。
在我看来，flatpak 也应该是不可信任的，除非它是一个经过严格审查/控制的发行版专用代码库（如 Fedora Flatpak repo 等）。
如果运行正常，就不需要 flatpak 了
可以说它们运行得很好，不需要 flatpak。这是我的个人经验。
这篇文章讲的是 Flatpack 的工作确实放缓了。因此，我们有理由怀疑，是否没有人觉得它有用，以至于要继续开发它。
许多 Ubuntu 或 Debian 用户仍在使用 Flatpak，不是吗？尽管已经有了 apt-get。
我不这么认为。
我用的是 Ubuntu，主要使用 debs（apt），如果这是获取更新的最简单方法，我会使用 Snaps。我用 Appimages 来获取一些短暂的信息，或者当开发者只能通过这种方式发布信息时（一些 3d 打印的信息）。我完全没有安装 Flatpaks，因为它与整个发行版不符。
乌班图？我想不会。Snap就在那里，而且同样简单，你为什么要装？
Debian：可能是的。
Ubuntu的衍生版本，如Mint、Zorin OS和ArduinOS，则使用Flatpak。
其他衍生版本，如 Asmi 和 Linux Lite，则移除了 snap，用户可以根据自己的意愿选择将其添加回去。
啊，我还以为 Ubuntu 只有 Debian 软件包管理器，但现在不是了。
天哪，不是这样的。十多年前就不是这样了！
第一个标配 snap 的版本是 2016 年的 16.04：
https://ubuntu.com/blog/canonical-unveils-6th-lts-release-of…
然而，Ubuntu Core（完全由 snap 软件包构建的不可变发行版）于 2014 年推出，Ubuntu 12 也有一个 Core 版本：
https://old-releases.ubuntu.com/releases/ubuntu-core/release…
Linux 的跨发行版打包方案大约有六种，包括 Nix、Guix、AppImage、Flatpak、Snap 和 0install。
不过，有两个是主流方案，得到了大型供应商的支持： Flatpak 来自 GNOME 组织，得到了 Red Hat 和 Fedora 的支持；Snap 是 Canonical 的一个项目，是 Ubuntu 的一部分，而 Ubuntu 是目前使用最广泛的发行版。
某种程度上，你没有太多选择。软件包数以千计，工作量很大。此外，随着 Linux 的不断普及，越来越多的厂商在发布软件时不愿意使用新的库，因此 Flatpack 可以很好地处理这个问题。
我只在服务器上使用 Linux，所以我需要的东西都是传统的 apt-get，但我一直以为在个人电脑上使用 Linux 会涉及大量 snap 或 flatpak 应用程序，他们不想处理复杂的依赖关系。
好吧，我车库里确实有一台闲置的 Linux 笔记本电脑，但我几乎没用过，而且我很确定我是用 snap 安装 Chromium 的。
根据我的经验，大多数应用程序，甚至是桌面应用程序，仍由发行版打包。
Flatpack 对于少数没有打包的应用程序，或者那些积极开发、经常获得新功能的应用程序非常有用。
我主要在笔记本电脑上使用 Linux。我以为你们服务器用户需要这种功能–你们必须，比如，提供服务、在网络上可见、为业务需要安装奇怪的软件，对吗？作为个人，我可以安装防火墙，信任所有使用我笔记本电脑的人（就我一个人），也不用安装一些小软件。
我不是服务器专家，我只是在工作中使用一些开发服务器，并拥有家庭服务器。我做得最多的是管理小型初创公司的开发服务器，在那里我主要是一名 SWE。所以我的意思是，我主要只使用过 Linux 远程+无头服务器，而没有在笔记本电脑/台式机上使用过。
我不认识使用它的人。
当然，但不是我的首选。
>Flatpack是Linux之上的一个奇怪的额外层
我的天哪，systemd、x11 甚至 GNU 都是 Linux 之外的奇怪附加层。Linux 只是内核。这正是 “重新定义 Linux，让它永远不为 99% 的东西负责 ”的意义所在。
看，这就是为什么称它为 “linux ”而不是 “gnu/linux ”会让人感到困惑，并产生像你这样困惑的评论:)
我在你部分引用的另半句话中明确承认了这一点。
我还解释了为什么我认为把重点放在 Flatpack 的缺陷上是不对的……所以，我不知道重复这一点有什么意义。总之、
> Linux […]正是 […]你所需要的
我同意！
在 Windows 上如何实现？
我真希望有这样一种东西，只要在电脑上 “安装 Linux”，开机时就会显示企鹅。
有是有，但你不能用它做任何事情，因为你基本上没有用户空间实用程序？
鉴于人们对 “GNU/Linux ”一词的褒贬不一，如今有一些基于 Linux 的操作系统并不使用 GNU 实用程序，这一点就更加正确了。
gjsman-1000 在上文谈到了 Linux 的 “设计缺陷”，但 Linux 只是内核。尽管每个人，甚至是 Linus 可能都在使用 “Linux ”这个词，但并不存在 “Linux ”操作系统。
如果你把启动 init 并出现黑屏称为 “操作系统”，那么……我想这很酷。
我怀疑莱纳斯是否曾与 GTK 人员或其他桌面环境作者进行过任何有意义的交流。那么，是什么设计缺陷呢？
你会因为梯子没有水平平台就说它是设计糟糕的脚手架吗？不，这完全是两码事。
> 我怀疑莱纳斯是否与 GTK 的人进行过任何有意义的交谈。
有趣的是，多年来他与他们有过争论，最激烈的争论与 https://subsurface-divelog.org/ 的开发有关。
哈！我纠正过来了。谢谢。我总是忘记他的潜水软件。
“GNU/Linux “仍然有太多不同的含义。就连 ChromeOS 也是如此。如果你想得到 GNU/Linux 的帮助，就需要说明是什么 DE 以及所有内容。或者如另一条评论所说，什么蓝牙堆栈。你可以说你用的是 Manjaro Cinnamon，但要么不够具体，要么就会有人说这是你没有使用 KDE 的错。
我在拿 Windows 或 Mac 作比较。Windows 中只有一个蓝牙音频栈。如果你想得到帮助，在网上找到的任何东西都适用于你，当然，除非你不惜一切代价把它换成另一种。与 Windows 不同，Linux 是开放的，人们可以创建自己的版本，但这些版本可以有自己的名字。
别跟我提 Ubuntu 把整个图形用户界面改了三次，每次都让人认不出来。不管是哪个 IT 部门，都不得不不停地重新截图说明如何操作，真替他们感到难过。
……只可惜蓝牙协议栈是有史以来最糟糕的协议栈之一，你没有任何替代选择，还得从志愿支持团队那里获得所有帮助。
蓝牙很难。但如果 Linux 社区不是在开发硬件之前就把复杂性发挥到极致，那至少会容易些。就连 Windows 也曾在驱动程序方面苦苦挣扎过一段时间。
如果你不喜欢上述系统，有几种 BSD 系统可以为你提供可用的操作系统。不过你可能需要一个桌面，但没有一个能提供。
FreeBSD 有桌面，不是吗？
几个：
https://docs.freebsd.org/en/books/handbook/desktop/
FreeBSD 可以运行多个桌面之一。但它没有桌面 – 它们都是独立的第三方桌面。这是一个微妙的区别，只有在极少数情况下才重要
好吧，我记得它因为某种原因预装了一个桌面，但既然你提到了，我记得是我自己安装的。
是的，现在（以前？ 我有段时间没查了）甚至还有专门用于桌面的 FreeBSD “发行版”。FreeBSD 的主要缺点是它不会为了迎合大众而降低自己的功能，因此虽然它对有经验的用户来说很不错，但对新手来说就有点痛苦了。
上次使用 FreeBSD 时，我发现它在本质上比 Linux 发行版更容易使用，主要是因为它有一本非常不错的手册（链接在一个兄弟姐妹的评论中），里面有很多现实的例子。另外，它似乎内置了更多的东西。
FreeBSD 最终变得更难的原因只是使用它的人更少，因此大量第三方软件对 Linux 的支持更好，而且更容易在网上找到答案。
在文档方面，它比 Linux 领先很多，主要是因为它是作为一个单独的项目开发的，而不是一堆零散的文档。每当我需要查找 POSIX 的 man 页时，我总是先阅读 FreeBSD 的 man 页。
*BSD 也有 Flatpak 想要解决的问题。(ports aint it.)
Flatpack 也不是它。当然，Flatpack 解决了一些问题，但也带来了其他问题，因此问题并没有得到解决。也许问题最终会得到解决（尽管缺乏维护意味着问题不会得到解决），但现在问题还没有得到解决。
我发现 ports 运行得很好 – 所有东西都与上游保持同步，而且他们会一直注意重建所有东西，所以很少会遇到库 ABI 问题。
我安装了 flatpak 来安装 VSCode/Codium，以便为我正在开发的 Python 项目提供一个可用的调试器。经过一段时间调整 VSCode/Codium 试图使调试器正常工作后，我才意识到 flatpak 可能是问题所在。又花了不少时间尝试不同的 flatpak 权限后，我意识到这样做并不划算。从 snap 安装了相同的软件包，一切正常。
emacs flatpak 只是一条漫长而痛苦的不归路。
Flatpak 对于应用程序而非系统工具（如 Chrom{e,ium}）来说要好得多，因为它有沙箱。
我最近换成了基于 flatpak 的不可变发行版。能用的时候感觉很好。但有很多好东西都不能用了，感觉我的电脑并不是一个真正的神奇工具。举个例子
– 为了运行戈多的外部工具，我不得不在运行 WINE 的发行版盒子上跑来跑去，还得处理一大堆权限和笨办法。
– 我放弃了 Firefox 的 flatpak，因为它无法与我的 KeepassDX flatpak 对话。
– Godot和Krita的flatpak很不稳定，比在Windows上更容易崩溃（可能只是Gnome什么的原因吧）
– 非 flatpak 工具，如 AppImages 和 .rpms 感觉非常粗糙
我希望看到 Flatpak 能带来更多很酷的东西，所以看到它现在的状态有点扫兴。
权限问题确实存在。
因为没有权限，所以仍然无法将 Tailscale 或任何创建虚拟接口的东西打包成 Flatpak。
得益于上述 API，MacOS 上的 Tailscale 甚至可以作为沙盒应用程序通过 Mac App Store 发布[1]。Flatpak 的限制使得某些类别的软件难以在 Silverblue 或 Bluefin 等 “原子 ”Linux 发行版上使用，这些发行版提供只读基础系统，并希望用户通过 Flatpak 获取软件。
[1] https://tailscale.com/kb/1016/install-mac
如果我想安装 Tailscale，我很可能会通过 `rpm-ostree` 将其添加到基础镜像中，而不是尝试使用 Flatpak，这并不是因为我意识到了问题所在，而是因为在基础镜像中添加更多系统范围的网络层对我来说更有意义。尽管如此，还是有很多应用程序没有打包成 Flatpak，我最终不得不将其添加到基础层，而我本希望将其用作 Flatpak。
即使有可能，我也不确定是否会将 tailscale 安装为 flatpak。我一直认为 flatpak 是一种安装大型、可能很糟糕的桌面应用程序的方式，不会污染系统。OBS studio 就是一个很好的例子，它是一个很棒的应用程序，但它是我使用的唯一一个使用 QT 的应用程序，多亏了 flatpak，我甚至没有在系统中安装 QT 库。
Tailscale 更像是一个系统服务，我更希望有一个发行版软件包（Arch Linux 软件仓库中就有 Tailscale）。
你的系统上并没有安装 QT 库。你只是在某个归档文件中安装了 QT 库，以及一堆你已经安装在系统上的东西的副本。
这有什么关系？几个库的副本根本不是问题。
如果这不重要，那为什么不把它们和其他一堆重复的东西放在一个存档里就是一件坏事呢？
> 将 Tailscale 或任何创建虚拟接口的程序打包成 Flatpak 仍然是不可能的，因为没有这方面的权限。
这是可能的，但并不理想。应用程序可以使用 flatpak-spawn（脱离沙盒），然后使用 polkit-exec（向用户索取 root 权限以任意使用）来获取主机上的 root 权限，但这几乎会移除所有沙盒。
我不是一个真正的 flatpak 用户，但在我看来，Linux 上的权限系统是一项艰巨的任务。既要解决打包问题，又要改造权限系统，这似乎是一块难以下咽的大饼。我不知道权限系统是否扼杀了这一势头，并导致了这种看似倦怠的状态。但它似乎复杂得令人难以置信。
对我来说，Linux 并没有一个精细的现代权限系统，我也不指望我的软件包管理器能帮我解决这个问题。我仍然在 Linux 上运行专有软件，因为我不得不这么做。这种情况理想吗？但我宁愿有一个分发系统并对供应商进行审查（无论如何我都在这么做），也不愿再等十年，等待权限的完善。在我看来，分发、包装和更新才是当务之急。
也许 Tailscale 应该是一个 sysext 而不是一个 Flatpak。
多年前，我用 Java 编写了一个屏幕显示（OSD），用于显示按键和鼠标点击[1]。有人认为扁平封装会很有用[2]。我不认为这有什么意义。这意味着：(a) 要维护两个安装过程；(b) 要整理两个来源的下载统计数据；(c) 要相信第三方系统会长期维护软件包索引[3]；(d) 要在已经有软件包管理器的系统中再添加一个软件包管理器；(e) 要在软件仓库中再添加一个软件仓库。
多年之后，我仍然只看到了缺点。
[1]: https://gitlab.com/DaveJarvis/KmCaster
[2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster
[3]: https://flathub.org/apps/search?q=kmcaster – 呜呼！
优点是
– 易于在不可变的发行版上使用 – 用户无需确保安装了正确版本的 Java – 即使没有特定发行版的软件仓库，也能自动更新
我猜你也可以通过在 Flathub 上搜索找到它
> 我猜你也可以通过在 Flathub 上搜索找到它
您是否点击了我发布的第三个链接，在 Flathub 上搜索 KmCaster 却一无所获？这是第(c)点： 你必须相信他们的搜索引擎是正确的、得到维护和更新的。这不是免费的，需要付出努力，也会出错。
这不是一个错误。Kmcaster 缺乏维护，已从 flathub 中删除。
[0] https://flathub.org/apps/com.whitemagicsoftware.kmcaster
这只是支持了我关于有更多东西需要维护的观点。现在这个 GitHub 页面上有一个很大的 “在 Flathub 上下载 ”链接，但因为软件包无人维护，这个链接完全没有用武之地。是谁让 GitHub 页面消失的？
https://github.com/flathub/com.whitemagicsoftware.kmcaster?t…
而且，该页面上的图片已经过时，这就又多了一个需要维护的地方。此外，安装说明需要运行四行代码，而不使用 Flathub 时只需下载三行代码。我的观点是正确的： Flathub 给某些项目增加了不必要的维护负担。
因为软件包被标记为未维护，所以显示为 “干”。
https://flathub.org/apps/com.whitemagicsoftware.kmcaster
https://github.com/flathub/com.whitemagicsoftware.kmcaster/p…
我不是开源维护者，甚至也不是开发人员，但在我看来，既然有这么多发行版都面临着同样的软件包管理问题，他们却不能集中精力改进 Flatpak，并引导它走向普及，这实在是太荒唐了。
也许许多 “发行版 ”存在的一个原因是，它们觉得 “发行 ”的方式不一样：-）。
多样性是好事。我不想要 “一个发行版 ”来选择启动系统、发行版、合成器、窗口管理器等。我希望有选择。
说到发布软件包，我个人喜欢系统软件包管理器。我不太喜欢 flatpak。
按照这种逻辑，只允许 GNOME 存在。不，谢谢。当权者经常会做出很多社区不同意的决定。
很多人不同意 flatpack 有用的观点。
例如，它对我来说完全没用。你为什么希望我在我不用的东西上提供帮助？
比起 flatpak、snap 或 containers，我更愿意选择单个 appimage 二进制文件。它实在是太便携、太友好了！
我目前使用的是 Slackware current。我使用的方法是从源代码编译或使用 AppImage。像 Flatpak 和 Snaps 这样的东西对我来说就是一个不透明的黑盒子。
我有 Zoom、KeePass 和 LibreOffice 等软件的 AppImage。我不需要不断更新它们。它们能做我想做的事。我把它们放在一个单独的分区中。如果我重新安装系统，它们就可以随时使用。
简单得令人发指。
我曾经试过 Fedora，但觉得它不适合我。为什么所有东西都是 Flatpak？使用软件仓库机制就好了。
我的系统也是这样。在没有 systemd 或 pulseaudio 的情况下运行 gentoo，Flatpak 和 Snap 完全不适合我。我从 gentoo 的官方软件仓库编译了我的大部分东西，并用精选的 AppImages 作为补充，这些 AppImages 开箱即用，效果奇佳。
我在我的 Fedora 主机箱上没有使用 flatpak，而是使用了 rpmfusion。
我一直不明白 flatpak、snap 等软件有什么用。就不能直接发布静态二进制文件吗？编译它们并不难。
(我是说，从发布的角度来看。沙箱和资源管理是操作系统的事情，应该是一个正交问题。用户必须能够对他们不信任的程序进行沙箱管理，无论这些程序是如何打包和发布的）。
我发现打包一个跨发行版和版本兼容的 AppImage 并不那么简单，而且我们甚至没有使用 Qt 或 GTK/libadwaita。根据您的经验，这有什么难的？
> 根据你的经验，这有什么难的？
在链接标志中添加 -static？有时需要稍微调整一下库的顺序，但仅此而已。
在最理想的情况下，为了实现最大的可移植性，我希望使用 αpε 格式！
你真的尝试过在 Linux 上制作一个完全静态链接的图形用户界面应用程序吗？
刚做过！
我不得不在 LDFLAGS 中添加“-static”，在 LDLIBS 中添加“-lxcb -lXau -lXdmcp”，这样二进制文件的大小就从 1MB 增加到了 3MB。这是一个普通的 X 程序，我想如果你使用花哨的工具包，可能会更难。
如果你觉得除了普通 X 之外的任何东西都很花哨的话…
> 你就不能发布静态二进制文件吗？编译它们并不难。
绝对不行，因为你需要链接到系统 libGL.so 和用于 GPU 加速的朋友、用于视频加速的 libva.so，等等。
说白了，flatpak 不就是封装了 mesa 的用户空间部分，与其他 chroot 类似吗？在这种情况下，苹果与苹果之间的比较应该是在发布应用程序的同时发布自己的 mesa。
这让我不禁要问，常识是否有误？如果我费尽周折，是否真的可以静态链接 opengl？
你需要与实际图形驱动程序相匹配的正确版本。因此，flatpak 会在沙盒中安装匹配的驱动程序。
有吗？我经常看到这种情况，但有一次我在一个极度（即多年）过时的设备上尝试了最先进的 chroot，结果 opengl 似乎能正常工作。这让我大吃一惊，不过我对 mesa 在引擎盖下的工作原理了解不多。
这太可怕了，与 “驱动程序 ”应有的概念背道而驰
公平地说，图形应用程序接口是作为库提供的，尽可能在用户空间完成。要在没有任何耦合的情况下实现沙盒化，很可能需要新的内核 API 或非常可疑的虚拟内存诡计。
在任何大型复杂系统上，这些都不是小事。
我工作的代码也有可加载插件。
任何复杂的软件都是文件的集合，而不是单一的静态二进制文件。
题外话，我想在 flatpak 上构建一个 cli 程序，但有点做不到。
遗憾的是，我还没有读完整本书，但我只想要这两样东西：
更好的 cli 支持
更好的权限支持，因为我在权限方面遇到了一些问题。目前我使用 nix-shell 作为 flatpak 的替代品，因为我只想使用短暂环境，而不想有权限问题。比如，我使用 nix-shell -p obs-studio 运行 obs，然后关闭 shell 并保持平静，因为我很少使用 obs 和依赖性地狱。我以前可能写过完全相同的评论，但我太想使用 archlinux 了，但在 nix 上使用 nix-shell 要舒服得多（我知道它在 arch 上也可用），而且 nix 有相同的名字，但 arch 可能有不同的名字，所以我也不知道。
如果没有 Flatpak，Linux 上可移植的沙盒应用程序的前景如何？我希望能有一种解决方案，让我可以运行半信任或不信任的应用程序（例如 vscode+扩展），并确信它不会不受控制地访问我的用户名权限所允许的任何内容。
解决不信任代码的办法就是不运行它。
太复杂了。一种应用格式不应该依赖 5 种不同的应用程序接口来保证安全。而且应用程序也不具备可移植性。我认为类似 WebAssembly 的东西才是未来的方向。
希望你是对的。但 WASM 要如何回答 “应用程序如何播放声音？”或 “应用程序如何从系统钥匙串中请求密码？”这样的问题呢？
WASM 解决了很多问题，但我并不认为它能比 Snap/Flatpak 更好地为类似问题提供统一的 API，因为这些问题从根本上说与运行时/打包系统无关。它们是由操作系统功能的碎片化和移动目标造成的。直接可执行的应用程序必须自己处理这些复杂问题。WASM/Docker/Snap/Flatpak/whatever 中的容器化应用则依赖容器层来完成。但是，有人的软件必须追逐这个移动的目标，而且它移动得非常快。
我认为flatpak就是要把安卓的局限性引入主流Linux。
我使用 Fedora 41 已经有半年了，flatpak 并没有让它变得更好。
Fedora 41 一开始以 rpm 的形式发布了很多应用程序，但后来当我运行 “sudo dnf update ”时，其中一些已经以 flatpak 的形式更新了。这可能是好的，也可能是坏的，但这也解释了为什么我的桌面上到处都是同一个应用程序的重复图标，而且要分辨哪个是哪个，哪个更好，或者如何管理所有的差异和冲突，这让人非常困惑，而 Fedora 41 却让这些差异和冲突变得不再那么容易分辨。
在 TFA 中解释的麦克风和扬声器缠绕的问题，也是我在使用老式方法遇到问题并决定将 musescore 安装为 flatpak 时没有意识到也没有准备好的。
我一直在考虑升级到 Fedora 42，但这篇文章让我预感到了额外的不便和绝望。有谁控制住了这些东西？
有没有一个活跃的 Flatpack 社区对它真正感兴趣，就像围绕发行版和它们的 repos 形成的社区一样？好像没有…
我也不知道。到目前为止，我对这些第三方商店（或其他什么东西）的体验是，Firefox 偶尔会被切换到 Snap，需要主动干预，如果我做错了，可能会删除我的配置文件。这……挺烦人的。
有一个 Flathub Discourse[0]，但它已经没落了很多
[0] https://discourse.flathub.org/
我看到这些工具为许多人提供了真正的实用性，但……
感觉太难看了。方枘圆凿。
我们构建了所有这些工具，为用户安装的应用程序定义安全边界，结果发现 Linux 的打包/发布环境是一片荒地，人们花了大量时间将软件发布的可重现性粘贴到安全边界工具上。
因此，我们现在就处于这种最糟糕的怪圈中：
我们花费了数十年的时间，使开发直接在用户界面上运行的强大应用程序变得简单易行、性能卓越，但现在却出现了两极分化/三极分化，变得一团糟。我想运行一个动态链接密码学库的应用程序；该库由发行版提供，我知道它已打补丁并与发行版的其他部分兼容 “或 ”我的应用程序可以访问/path/to/whatever 处的文件/设备，并在有权限的情况下使用这些资源”，这两句话的可读性被大量的间接容器所掩盖。
与此同时，正如 TFA 详细解释的那样，这些工具最初所针对的实际安全/encapsuation 边界被证明是一个快速发展的目标，多年后仍缺少大量支持。
在其他系统中，我们也能看到这样的可能性。以 BSD 的 pledge(2)为例：它的方法是如此积极地以解决安全问题为导向，以至于我真的无法想象在这样一个世界里，“承诺”/“能力 ”系统会像 Snap 和 Flatpak 那样 “发展 ”出一个打包/发布生态系统。或者以 plan9 的方法为例：如果我们对整个操作系统进行建模时，采用的基本 SysV 权限模型（用户、群组、文件、权限）能够尽可能满足应用程序的安全沙箱需求，那么 SElinux/snap/flatpak 这样的东西最终就没有存在的必要了。
不过，让我们陷入这种境地的最大原因并不是工具，而是人的因素： 发行版/软件包仓库的维护者已经筋疲力尽，只想支持相对较少的依赖目标，以及在特定操作系统上向软件包图中添加内容的方式“；”应用程序开发者希望尽快向用户提供复杂的软件“；”用户非常愿意做不安全的事情来运行新的应用程序，但一般不愿意做复杂的事情（配置/make、自定义 AUR 源、了解 nix 是什么）来安装软件”，这三者之间的矛盾。
快进到几年前，由于桌面环境/编译器/音频系统的对决，我们又经历了许多错误的开始和其他扯淡的事情，最终的结果并不理想。
目前的情况基本上是
“当应用程序想要与操作系统的其他部分对话时，会出现大量脆性（对用户来说很糟糕–但只有当应用程序需要罕见的高级功能时才会如此，比如……）。uuuh 基本音频播放等稀有高级功能时才会出现），所有这些都被嵌入到高度复杂的容器系统中（对应用程序作者来说很糟糕），目的是在 “实际上不是静态链接，我保证 ”的大型镜像中提供应用程序，这些应用程序各自封装了自己的外观/感觉/操作系统集成（对发行版维护者和用户体验一致性来说很糟糕），其中每个镜像都包含 75% 的操作系统，运行在泄漏的隔离区上（对安全补丁程序来说很糟糕），更新故事是 “再下载一次宇宙”（对带宽/CDN 成本来说很糟糕）”。
我明白我们是怎么走到这一步的。我知道这比以前 “但哪个 autoconf？”/“我只是想更新浏览器，但 glibc-2.11-compat-compat-compat-but-forreal-this-time-FINAL 更新了，弄坏了我的引导加载器 ”要好得多。我也明白，随着时间的推移，其中一些方面可能会有所改善（例如，OCI 图像有助于重新下载世界；Wayland 最终会渗透到各个领域，容器运行时 X 合成器几何复杂性爆炸也会随之平息；总有一天，有人会第 18 次修复通用 D-Bus 的可发现性和安全性……）。
但总的来说，从根本上、哲学层面上讲，它现在和将来都是一团糟。看起来，Linux 生态系统是以一种最缓慢、最分散的方式实现了这一点，这并不是什么新鲜事。但结果却是 “人人都是输家”，这就很糟糕了。
如果 30 年前能有一种尊重虚拟化的打包机制，我们现在就有了。现在，鉴于断裂线的运行方式，我们注定会有三个或更多。
这是 pythons 虚拟环境和 pip-is-weak 问题的放大。自制软件、Mac ports、fink 或 pkgsrc。
在 fork 之后设计的机制，从来都不是中立的。
常见的跨分叉打包机制都与虚拟化无关。核心问题在于软件依赖性。
一种可以将依赖关系捆绑到隔离运行时的机制意味着，除了底层操作系统的 ABI 之外，依赖关系不会命运共享。
虚拟化容器应用程序的依赖性更简单。
Flatpak 最大的错误不在于代码，而在于总线因素。
> 如果我们不把一些 “+1 ”换成实际的公关审查（或资金），我们就会在 2030 年发布应用程序，而沙盒则会在 2024 年冻结，而其他一切都会搭上 OCI 的顺风车。
> Flatpak 现在有了 –device=input 功能，允许应用程序访问输入设备，而无需访问所有设备。
哦，嘿… 这个功能是我做的。很高兴看到其他人也想要更窄的权限。
有趣的阅读。虽然 Flatpak 在很多方面确实很好用，但它的缺点也是实实在在的，让我在大多数情况下几乎更喜欢 Snap。Flatpak 终端应用程序很烦人，权限问题也很烦人，还有声音等等……
有趣的是，创造者已经在考虑下一个产品了。
更有可能的是，它不是 RedHat 的优先项目，而在大规模裁员或解雇的时代，非优先项目更难开展。
> Flatpak 终端应用程序很烦人、
他们本可以做得很好，但他们选择不走这条路。这是 Snap 的一个闪光点。Flathub 拒绝终端应用程序也是出于这个原因。
然而，也有少数几个非gui平板应用。我常用的一个是 Zola [0]，它是一个静态网站生成器，因为使用 “zola serve ”创建网站的速度明显快于原生的 Alpine Linux 软件包。为方便起见，我只需将 flatpak run org.getzola.zola 别名为 zola。
[0]: https://flathub.org/apps/org.getzola.zola
用例是 Podman/Docker
AppImages （毫无疑问是更好的选择）之所以没有比 Flatpak 或 Snap 更成功，完全是因为 Linux 用户（以他们特有的懒惰）只习惯于从单一的商店和软件源中获取软件，这仍然让我感到恼火。
至少就Snap而言，我觉得Canonical本身在使其在Ubuntu中占据主导地位以便控制生态系统方面起到了一定的作用。
就我个人而言，只要有AppImage可选，我就会使用它。它是最接近 Windows 和 MacOS 的可执行应用程序。
我喜欢 AppImages，但 Flatpak 试图做得更好–集中更新、沙箱/权限系统、一次打包、在多个发行版上运行……
从软件源获取软件并不只是懒惰，你会自动获取更新，软件源中的软件应该与你的发行版兼容，但显然 AppImages 并不总是如此。
我认为 D-bus 有很多问题，而且不是很好。我还认为（Flatpak 和其他系统的）沙箱也有问题，例如缺乏某些类型的权限（如依赖于命令行开关的权限、通过 popen 执行用户指定的外部程序的权限（这些程序也不会受到限制的影响）等等）、无法正确使用字符编码等。还有其他一些问题，尽管我认为沙箱执行总体上不是一个坏主意。
对我来说，flatpak 最大的问题是它不适合服务器端软件，而 Snap 对服务器端软件支持得很好。是否计划在某个时候使用？
我使用 NixOS，我发现 Flatpak 是安装和更新应用程序的最简单方法。Nix 模式非常适合系统软件，但并不是更新和安装桌面应用程序的理想方式。
我遇到的唯一问题是系统安装的字体在沙盒中不可用，但这是由于 NixOS 导出字体的方式造成的，只要告诉 NixOS 在 /usr/share/fonts 中发布字体即可解决。
在 Windows 的世界里，我无法理解为什么需要 Flatpak 这样的东西来让用户可靠地启动和运行程序。我的意思是，相信我，我知道Linux太糟糕了，需要Flatpak这样的东西。但试想一下，如果你对 Windows 可执行文件格式没有发展感到失望，你会怎么想？运行一个 exe 不应该需要几十年的维护。它不应该那么复杂。不必如此。
> 运行一个 exe 不应该需要几十年的维护。不应该那么复杂。没必要那么复杂。
你认为 C:Program Files、C:Program Files (x86)、c:WindowsSystem、C:WindowsSystem32、C:WindowsSysWOW64、%USERPROFILES%%APPDATA%%Local 和 %USERPROFILE%%APPDATA%%LocalLow 中的那些东西是什么，还是你安装的七个版本的 C/C++ VS Redistributable？
编辑：错别字
在现实中，用户根本不需要查看一堆东西。在 Windows 上，任何人都可以点击一个 20 年前的可执行文件，而且很有可能它就能正常运行，因为微软的好心人关心的是如何为用户提供像样的库和稳定的 ABI，以及人们可以构建的真正的操作系统。
在这方面，Linux 世界则是一塌糊涂。你在一个 LTS 版本上构建的东西，不知道能否在下一个版本上执行。就像一个笑话所说的那样（这甚至都算不上是个笑话），情况糟糕到 Win32 是 Linux 上唯一稳定的 ABI
> 运行一个 exe 不应该需要几十年的维护。
运行静态链接的精灵就不需要。与此同时，现代 Windows 会尽最大努力将用户集中到微软商店。主要区别在于单一的集中式生态系统与真正的用户自由以及由此产生的无政府状态。
老实说，你说得有道理。曾经有人提议建立一个 “Linux 标准基础”，但没有一个发行版真正关心这个问题（他们有自己的特殊调料），所以这个提议也就夭折了。如果 Linux 应用程序开发人员能以 “LSB-2020 ”之类的版本为目标，那就类似于 Windows 开发人员以特定的 Windows 版本为目标。Flatpak 基本上是发行版的一种变通办法。
(请注意，出于兼容性原因，Windows 也会进行生命化）。
从另一个角度看，也许这只是 “名正言顺”。Windows 可以让你运行图形用户界面窗口程序，而且所有程序都能正常运行。GNU/Linux 允许你运行 1990 个基本的行业标准 API 程序，所有这些都能正常运行，但对于其他程序来说，一切都无法正常运行。
> 运行一个 exe 不应该需要几十年的维护。
这就是为什么 Windows 系统充满恶意软件和病毒的原因。
> 但是，试想一下，如果说你对 Windows 可执行文件格式没有发展感到失望，你会怎么想？
事实上，我对这一点非常失望。PC 操作系统仍然没有像智能手机那样良好的权限/沙盒机制。(说白了，我并不是要求在个人电脑上实行类似智能手机的自由限制，只是要求对应用程序的功能进行更多控制）。
这也是 Flatpak 试图在 Linux 上解决的问题之一。据我所知，Windows Store 的理念与 Flatpak 非常相似（权限、解决分发问题……），但也没有人使用它。所以微软也不是不想发展 exe。
微软肯定想发展，据我所知，他们正试图吸引人们打包自己的应用程序，并在应用程序未签名的情况下设置与 macOS 类似的障碍。
但由于没有人会更新打包旧版应用程序，我想很多用户都会禁用所有警告。
问题是，WINDOWS 上的 .exe 在很多层面上都被破坏了。没有沙盒，应用程序并不总是按照标准来存储数据，没有依赖性管理，但如果你没有安装正确版本的 Java 等软件，你的应用程序就无法运行。等等。
希望通过销售应用程序获得的资金能像其他应用程序商店一样为开发提供资金。
Flathub 几年前就引入了捐赠，但并没有什么实际效果。
编辑：我可能记错了，但曾经有人试图增加捐款。也许被拒绝了
它确实是用于跨桌面图形用户界面的桌面应用程序。我看到它被用在没有图形用户界面的嵌入式 Linux 项目中，因为其便携性代价很高（flatpak 很肥，需要安装一个完整的沙盒）。
前段时间，我选择了 flatpak 而不是 snaps 来打包图形界面应用程序，我不记得为什么了。我认为这样打包软件有很多好处（尤其是对于不可变的操作系统镜像），但同时也有很多不利因素。我希望他们能更加重视这一点。或者有更好的东西出现。
该死 这是不是意味着 Fedora 完了？我并不太关注 Linux 上的 metastories…
我更担心的是 Fedora Silverblue 和 Kinoite，它们的变种更依赖于 Flatpak，因为它们的重点是尝试使用一个最小的不可变的基础操作系统，并在上面以 Flatpak 的形式安装所有面向用户的应用程序。
只要红帽公司还想继续销售 RHEL，Fedora 作为一个发行版可能就不会消失，也不会失去开发重点。
flatpak 支持 qemu 仿真吗？我可以在 arm 上使用它来运行 x64 映像吗？
不支持。元数据文件包含可用的架构，Flathub 会在用户界面中公开这些架构[0]。
[0] 示例 https://flathub.org/apps/vet.rsc.OpenRSC.Launcher
这有点遗憾。Flatpak 完全是比 Snap 更好的工具。(我在使用 Docker-via-Snap 时遇到过噩梦般的故事）。
我确实更喜欢 AppImage（它更简单），但 FlatHub 并非等价物，它的可发现性实在太差了。
另外，根据 TFA：https://m.xkcd.com/2347/
20 年前： “哦，不，发行版正在为打包而苦恼！我们有 apt、yum、dnf、rpm、nix、docker……”
https://m.xkcd.com/927/
在我的世界里，有很长一段时间存在着 “大同世界”（pax debiana）。我主要使用 Ubuntu（后来换成了 Debian，最后又加上了 Fedora），软件包管理真的很不错。APT 是个很好的工具，我和它相处得很愉快。保持系统更新和解决依赖性问题非常简单。它比其他任何更新系统都要顺畅，即使是在重大系统升级时也是如此。
当 snap 开始篡夺我的东西时，我有点失去了它。我知道这一天即将到来，因为 docker 已经开始大举进攻。后来又有了 flatpak 和 company。作为一名管理员，作为一名系统架构师，我觉得我失去了对系统的控制。我再也不可能知道系统的更新状态了。无法集中管理或监控这些更新。它变成了一个由自我更新和影子更新组成的自由市场。Ubuntu还引入了不属于apt模式的实时补丁和内核更新。
我认为，对于主要发行版来说，打包所有自己的下游软件包可能是一个太大的负担。也许他们看到了一个机会，那就是让一个真正专业的服务来分担打包负担，该服务可以打包一切，并提供泛发行版软件包。如果 Debian 和 RHEL 的打包人员减少了下游打包工作，那么他们或许就能专注于自己的核心竞争力。我注意到，几乎每一个 Ubuntu 软件包都需要包含 Ubuntu 特有的调整，而且基本上 Ubuntu 已经是 Debian 的下游，为什么 Canonical 还要自己维护每一个该死的软件包呢？
那么，这一切的结局是什么？apt 或 dnf/rpm 最终会被抛弃，让他们全心投入新的系统吗？还是继续扩散和分裂？我们中的许多人都说过，Linux 的魅力在于我们的自由选择。但选择太多了。看看 Distrowatch，你就会因不知该如何选择而陷入瘫痪。桌面上的 Windows 或 macOS 很容易选择，因为……各有一个。
我去加泰罗尼亚旅游时，朋友带我去了家乐福。我们在过道里闲逛，我发现每个柜台上都有猪腿肉（jamon serrano）。鸡蛋种类繁多。我的胃想吃什么就有什么。她把我领到橄榄货架前，指指点点地介绍那里的橄榄。她说，随便挑。橄榄有很多。它们都装在精美的罐子里。我对橄榄一无所知。我什么也没选就走了。
Linux将死于千刀万剐，直到内核之外的一些整合和统一得以实现。
>软件本身的功能对于那些没有使用过更现代的软件包管理器的人来说基本没问题，但一旦你开始需要发行版默认仓库之外的东西，用户体验本身就是一场噩梦。
听着，这里没有任何幻想或夸张；APT 是一个不完美的工具，有时它错综复杂、难以驾驭。但请考虑一下现状。我运行过 Minix-286、OpenBSD、NetBSD、SunOS、HP/UX 和 Linux，在 1990-2003 年间，使用的软件包管理器为零。
就像 APT 根本不存在，它的前身也不存在，这些系统完全没有软件包管理。即使有，也是通过脚本或下载应用程序时附带的定制框架。我的电脑上安装了什么东西，100% 没有全系统管理。
我一直处于从源代码重新编译内核的状态。我运行过 GNU 自带的“./configure ”脚本。我曾摆弄过自定义的内核配置文件和试图跟踪一切的 Tripwire 数据库。我打上了 Sun Microsystems 发布的补丁。
以上这些杂乱无章的东西绝对无法与我们今天使用 APT 的方式相提并论。我很遗憾你遭受了噩梦，需要第三方的东西。但是，只需输入一句话，系统就能自动升级，考虑到所有依赖关系，替换所有必要文件，了解所有配置更新，留下审计跟踪和版本文件，这简直是梦想成真。在这一点上，简直就像从日志上掉下来一样。
谁还会回头呢？还有比这更简单的吗？只是这种统一控制的退化和单一管理点的丧失开始让我们感到不安。
这是我的 0.03 欧元：
我真希望 Linux 发行版开始采用与 BSD 类似的模式。发布一个最小化但坚如磐石的基本系统；坚持使用 LTS 内核等。只针对安全问题发布补丁/更新。每年发布一到两次重大版本。(Fedora Silverblue 正朝这个方向发展）。
其他？可以从 Flatpak、Snap 或 AppImage 中选择，但要全力以赴。将所有开发工作都集中在打造一流的体验上。让 Gnome、KDE 等推出自己的构建版本。
棘手的问题是，在基本系统与 Flatpak 中应包含多少内容。对于工作站来说，安装介质必须包含足够的图形用户界面，以便为你提供一个正常运行的桌面、一个网络浏览器和一个应用程序管理器（“商店”），这是显而易见的。OpenBSD 的基本系统包括 X11 和几个基本的 WM，但如果目标用户的技术水平较低，情况就会复杂一些。
这种做法会淡化发行版之间的差异，但实际上这对发行版是有好处的。我已经告诉朋友们，如果你想尝试 Linux，就在 Ubuntu 和 Fedora 之间选一个。它们都还不错。
服务器？那就用 Docker/Podman 吧。现在有很多发行版都能做到这一点。
> 在内核之外进行整合和统一。
正在进行中，这就是 systemd。
很快，类似模态 systemd 安装程序的东西就会出现： systemd-msid
分解得不错。
flatpak 和 snap 的行为不一致、权限 Bug 以及一堆我从未弄明白的问题都是祸根。我对它们感到非常沮丧，所以我清除了它们，装上了 Debian，只使用旧的软件包系统。
我基本同意。在计算器应用加载花了很长时间之后，Snap 就成了我离开 Ubuntu 的原因。计算器 在Snap化之前，它是即时的。
我曾经尝试过使用FlatPak，虽然它看起来比Snap更快，但由于权限或沙箱的原因，我总是会遇到一些无法正常运行的问题。很多问题的答案似乎都是 “不要使用 FlatPak 版本”。
我所使用的软件非常复杂，既需要 FlatPak 这样的软件，又不需要与其他软件交互，但这些软件的规模基本上非常非常小。
这是什么时候的事？
Snap 早期的运行速度有点慢。现在已经不慢了。
我使用 Ubuntu 22.04、24.04 和 25.04。现在Snap的运行速度相当快。
我已经清理了我所有的自定义软件仓库和PPA，删除这些应用程序，然后重新安装Snap版本。这样既简单又有效。
我使用的是三台相当老旧的 Thinkpads，几乎每天都在使用：X220、T420 和 W520。它们都是酷睿 i7 处理器，内存都已用完，都装有固态硬盘。它们完全可以满足我的需求，而且键盘也很好用，现代的 Thinkpads 都没有这样的键盘。
现在，13 年前的 Thinkpad 上的 Ubuntu 22.04 加载快照应用程序只需一眨眼的时间。与原生打包的应用程序相比，我感觉不到任何延迟。
是的，它会占用更多的磁盘空间。
我以前会删除所有快照，然后 “apt purge snapd”，但现在已经不值得多此一举了。
哦，那是很久以前的事了，可能是 18.04 或更早的版本，那时他们刚引入 Snaps。
很高兴听到他们解决了速度问题，我刚转到 PopOS。
你看，我真不明白我的体验为何与你的如此不同。不是在速度方面，而是在工作方面。我的经历总是这样，比如缺少或配置错误的 apparmor 配置文件导致 snap 和/或 flatpak 出错，沙盒需要以 root 用户身份运行/被拥有的错误信息，无法在我的一个主文件夹中保存文档，为此我调整了权限，但仍然无法运行……诸如此类。
这得看你用的是什么浏览器了。
我用的是原生打包的浏览器： Waterfox和Chrome。
在 Snaps 中，我运行的是不太重要但实用的东西： Ferdium（我的多协议消息客户端）、Slack、Signal、Telegram、Skype（RIP）、Spotify。我不在乎它们是否能访问我的文件系统；我也不希望它们访问我的文件系统。
所有这些对我来说都没有问题。
我曾小心翼翼地移除所有 Snap，然后执行 “apt purge snapd”，然后阻止它被重新安装。之后，我安装了 deb-get：
https://github.com/wimpysworld/deb-get
然后我就用它来获取、安装和更新所有我需要的、不在 Ubuntu 软件仓库中的应用程序。
这样做效果很好，但 Ubuntu 版本升级很危险：最好的结果是 “do-release-upgrade ”工具将它们全部禁用，升级工作正常进行，然后你必须去手动重新启用它们，必要时编辑 apt `.list`文件以指向每个应用程序的 repo 的新版本。
这很麻烦，所以我现在建议把 snap 放在那里。
好极了，在带来 Pulse（+ Limewire 修复）、systemd、wayland、dbus、flatpak 以稀释和过度复杂化一切之后，RHEL 现在又要彻底放弃桌面了。与此同时，二十年来为 Linux 开发的新桌面应用程序为零。如今，即使是 Ubuntu 和 Fedora 上的火狐浏览器也无法访问团队/会议的网络摄像头，因为分层容器框架存在权限问题，而这些框架只是为了保护虚构的应用程序（如不存在的应用程序）访问你的文件。说真的，唯一的出路和已经取得进展的地方似乎是使用 wine/proton 支持 win32 应用程序，但也许可以使用 SteamOS/Arch 代替，因为 bazzite 是基于 fedora 的。
在所有操作系统中，Linux 是面向大众的软件分发模式最差的。WINDOWS（可能还有MacOS，但我不甚了解）也存在很多问题，但仍然比LINUX好得多。如果把发行版的数量、版本数量、软件数量和版本数量放在一起比较，就会发现由发行版或软件作者管理发行版是不可持续的。相比之下，windows 和 mac 最多只需要两个版本的软件，就能覆盖 90% 的用户。
我不知道 flatpak 或 appimage 是否是一种解决方案，我自己也无法提出这样的方案。但我真的认为，如果不加以改进，Linux 模式终将彻底失败。
顺便说一句，我并不是说 linux 模式总是低劣的。事实上，它往往更胜一筹：在服务器领域，有专业人士打理一切；在资源稀缺的嵌入式领域，可以配置和选择一切细枝末节，这使它大放异彩。
这就是为什么世界上使用最广泛的台式机/笔记本电脑 Linux 发行版有一个简单、出色的应用程序打包解决方案：
它没有打包。你无法安装新的应用程序。
这就是 ChromeOS。从 ChromeBooks 的销售量和支持的使用寿命来看，它拥有大约 25 亿到 5 亿用户。
真正的 ChromeBook 可以让你安装安卓应用，但这只是题外话。
我使用的 PC 上的 ChromeOS Flex 并不提供这种功能。不过你可以打开 Debian shell 并在其中安装 Debian 软件包。这对 VLC 来说很方便。
从 Ubuntu 自身的数据来看，其用户数量约为 2,000 万至 3,000 万。Debian 大约是其三分之一。所有的 RH 发行版都比 Debian 少，可能只有十分之一。
在中国，UnionTech 称其 UOS 的付费用户去年已超过 300 万，这意味着其用户数量可能与 Ubuntu 相当。这反过来又意味着，中国大部分地区仍在使用盗版的 MS Windows。
所有其他发行版加起来的用户数量约为过去三四年 ChromeBook 销售量的 10%。
Linux包装的制胜之道似乎是：根本不做。
“一个奇怪的游戏。唯一的制胜之道就是不玩”。
作为一名 Linux 的长期用户，我还发现了一个具有讽刺意味的现象：多年来，Linux 的书呆子们一直沉浸在他们的软件包管理器的 “优越性 ”中，而 Mac OS 上的 Homebrew 在通用性和易用性方面却让他们黯然失色。例如，比较一下 kubectl 的安装说明：
Linux DEB/RPM (https://kubernetes.io/docs/tasks/tools/install-kubectl-linux…)：
1. sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
2. curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg –dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # 允许无权限的 APT 程序读取此密钥。
echo ‘deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /’ | sudo tee /etc/apt/keyrings/kubernetes-apt-keyring.gpg. | sudo tee /etc/apt/sources.list.d/kubernetes.list 5.
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # 帮助命令未找到等工具正常工作
Mac OS (https://kubernetes.io/docs/tasks/tools/install-kubectl-macos…)：
brew install kubectl