Flatpak 将依赖于 Systemd

Home > Linux > Flatpak 将依赖于 systemd 如果您今天访问 Flatpak 网站，它列出了该项目的第一个优势：“为每个发行版构建：创建一个应用程序并将其分发到整个 Linux 桌面市场。”如果您继续查看受支持的发行版列表，您会看到常见的发行版，但也会看到 Void Linux、Guix 和 Alpine 等发行版。最后三个都有一个共同点：它们使用 systemd 之外的 init 系统，因为 Flatpak 不关心你使用什么 init 系统。然而，对于 Flatpak 的下一个主要版本来说，这种情况似乎将会改变：systemd 可能会成为 Flatpak 的依赖项。在 Linux 应用峰会上，Arian Vovk 和 Sebastian Wick 就 Flatpak 的未来进行了精彩的讨论。当前版本的 Flatpak 将继续进行大量改进，但与此同时，其数十年历史设计的局限性变得越来越难以解决。因此，他们还在计划和开发他们所谓的 Flatpak Next，或者可能是 Flatpak 2.0，它实际上是根据他们多年来学到的知识重写的 Flatpak，利用了自 Flatpak 1.x 最初设计以来已经取得进展的现代技术和想法。需要注意的是，演讲中讨论的所有内容都在计划中，还没有编写任何代码。这意味着所有这些计划都可能会发生变化，并且随着未来几年工作的进展，最终结果可能与谈话中详细说明的结果有很大不同。此外，我必须强调这一点：如果本次讨论中的任何内容让您有哪怕是最微小的暗示，可以去骚扰、攻击、侮辱或以其他方式骚扰涉及 Flatpak、systemd 或相关技术的任何人，请善意地预约瑜伽课或其他课程。看来你需要它。在演讲一开始，Vovk 和 Wick 解释说，他们希望通过一项名为 systemd-appd 的新服务将权限管理从 Flatpak 转移到服务层。 Systemd-appd 为应用程序提供一个标识符并存储它们的权限，然后系统的其余部分可以查询该数据。反过来，这又实现了一系列其他功能，其中最重要的是子沙箱。目前，计划在当前版本的 Flatpak 中引入此功能，从而将对 systemd 的依赖引入到 Flatpak 中。据我从 Vovk 了解到的，他们打算对发行版和不使用 systemd 的人“超级体贴”，我认为这意味着我们最终会遇到与 systemd-logind 非常相似的情况，它从 systemd 中提取到一个单独的守护进程 elogind 中，以便使用其他 init 系统的发行版仍然可以根据 systemd-logind 使用桌面环境。我想 Flatpak 开发人员希望为 systemd-appd 发生的类似情况提供尽可能多的功能可供性，从而确保 Flatpak 在不使用 systemd 的发行版上仍然可用。显然，使用 Void 或 Alpine 等发行版的人们担心 Flatpak 在他们的系统上的未来。如果 Flatpak 对 systemd 产生了严格的依赖，Flatpak 将不再在没有 systemd 的发行版上工作，所以这次演讲提出了一些问题——遗憾的是，这些问题似乎是针对那些在技术上不参与 Flatpak 开发的人，而他的回答并不是特别有帮助，而且通常只是彻头彻尾的侮辱和煽动性。尽管他没有参与 Flatpak 的开发，但足够多的人认为他参与了，并且有毒的发酵液搅拌了。对于 Flatpak 在其系统上的未来提出真诚、友好的问题的用户遭到了嘲笑和侮辱，事情从此失控，吸引了狂热的反 systemd 红帽阴谋疯子（甚至更糟）。对于所有相关人员来说，情况都变得越来越糟，尤其是 Flatpak 的开发人员。因此，我们最终陷入了这样的境地：每个人都很生气，而 Flatpak 的开发人员在为发行版和不使用 systemd 的人们提供容纳和支持方面“不愿意再把时间花在那些狗屎上”。最终结果很可能是，未来 Flatpak 对 systemd 的依赖将更加严格，并且制作任何独立的类似 elogind 的守护进程将比原来困难得多。没有人赢，每个人都输，这一切都是因为有些人认为侮辱性和煽动性是必要且有效的。从目前的情况来看，未来几年，Flatpak 很可能会依赖于 systemd，但可能无法提供独立的守护进程来在不使用 systemd 的发行版上复制 systemd-appd 功能。换句话说，Flatpak 将不再能够吹嘘它能够“为每个发行版构建：创建一个应用程序并将其分发到