TL博士：Haiku 能否获得对应用程序包的适当支持，例如应用程序目录（例如 .app 在 Mac 上）和/或应用程序映像（Linux AppImage）？ 我认为这将是一个有价值的补充，它比其他系统更容易正确实施，因为大多数基础设施已经就位。
我发现了俳句，一个意想不到的好系统。 好吧，由于我长期以来对目录和应用程序映像感兴趣（受到 Macintosh 的简单性的启发），所以我想到一个想法也就不足为奇了......
为了充分理解，我是 AppImage 的创建者和作者，AppImage 是一种 Linux 应用程序分发格式，旨在简化 Mac 并为应用程序作者和最终用户提供完全控制权（如果您想了解更多信息，请参阅 и ).
如果我们为 Haiku 制作一个 AppImage 会怎样？
让我们纯粹从理论上思考一下：需要做什么才能获得 或类似的俳句？ 现在没有必要创建一些东西，因为俳句中已经存在的系统运行得非常好，但是一个想象中的实验会很好。 与 Linux 桌面环境相比，它还展示了 Haiku 的复杂性，在 Linux 桌面环境中，此类事情非常困难（我有权这么说：我已经在调试上苦苦挣扎了 10 年）。
在 Macintosh System 1 上，每个应用程序都是在 Finder 中“管理”的单独文件。 我尝试使用 AppImage 在 Linux 上重新创建相同的用户体验。
首先，什么是AppImage？ 这是一个发布第三方应用程序的系统（例如， ），允许应用程序在他们想要的时间和方式发布：不需要知道各种发行版的细节，构建策略或构建基础设施，不需要维护者支持，并且它们不会告诉用户他们可以安装什么（不可以安装什么）在他们的计算机上。 AppImage应该理解为类似于Mac包的格式 .app 磁盘映像内部 .dmg。 主要区别在于应用程序不会被复制，而是永远保留在 AppImage 中，与 Haiku 包非常相似 .hpkg 已安装，并且从未按通常意义上安装。
在十多年的存在过程中，AppImage 已经获得了一定的吸引力和知名度：Linus Torvalds 本人公开认可它，常见项目（例如 LibreOffice、Krita、Inkscape、Scribus、ImageMagick）都采用它作为主要方式分发连续或夜间构建，不干扰已安装或卸载的用户应用程序。 然而，Linux 桌面环境和发行版通常仍然坚持传统的、基于集中维护者的发行版模型和/或基于 （RedHat、Fedora、GNOME）和 （规范、Ubuntu）。 它来了 .
它是如何工作的
- 每个AppImage包含2部分：一个小的双击ELF（所谓的.
runtime.c），后跟文件系统映像 .
- SquashFS 文件系统包含应用程序的有效负载以及运行它所需的所有内容，如果头脑正常，则不能将其视为每个相当新的目标系统（Linux 发行版）的默认安装的一部分。 它还包含元数据，例如应用程序名称、图标、MIME 类型等。
- 当用户运行时，运行时使用 FUSE 和 squashfuse 来挂载文件系统，然后处理在挂载的 AppImage 内运行某些入口点（也称为 AppRun）。
该过程完成后将卸载文件系统。
看起来很简单。
这些事情让一切变得复杂：
- Linux 发行版种类繁多，“只要头脑清醒”，就没有什么可以称为“每个新目标系统默认安装的一部分”。 我们通过构建来解决这个问题 ，允许您确定哪些内容将打包到 AppImage 中以及哪些内容需要放在其他地方。 与此同时，我们有时会错过，尽管事实上，总的来说，一切都进展顺利。 因此，我们建议包创建者在所有目标系统（发行版）上测试 AppImage。
- 应用程序有效负载必须可在文件系统中重新定位。 不幸的是，许多应用程序都有硬编码的绝对路径，例如，
/usr/share。 这需要以某种方式解决。 此外，您必须导出LD_LIBRARY_PATH，或修复rpath以便加载器可以找到相关的库。 第一种方法有其缺点（可以通过复杂的方式克服），而第二种方法则很麻烦。 - 用户最大的用户体验陷阱是 下载后的AppImage文件。 不管你相信与否，这对某些人来说是一个真正的障碍。 即使对于有经验的用户来说，设置可执行位的需要也是很麻烦的。 作为解决方法，我们建议安装一个小型服务来监视 AppImage 文件并设置其可执行位。 就其纯粹形式而言，它不是最好的解决方案，因为它不能开箱即用。 Linux 发行版不提供此服务，因此用户的开箱即用体验很差。
- Linux 用户希望新应用程序在启动菜单中有一个图标。 你不能告诉系统：“看，有一个新的应用程序，让我们开始工作吧。” 相反，根据XDG规范，您需要复制该文件
.desktop到正确的地方/usr对于系统范围的安装，或在$HOME对于个人。 一定尺寸的图标，根据XDG规范，需要放置在特定的位置usrили$HOME，然后在工作环境中运行命令来更新图标缓存，或者希望工作环境管理器能够弄清楚并自动检测所有内容。 与 MIME 类型相同。 作为解决方法，建议使用相同的服务，除了设置可执行性标志之外，如果有图标等，还会设置该服务。 在AppImage中，根据XDG将它们从AppImage复制到正确的位置。 当删除或移动时，该服务预计会清除所有内容。 当然，每个工作环境的行为、图形文件格式、大小、存储位置和更新缓存的方法都存在差异，这会产生问题。 简而言之，这个方法就是一个拐杖。 - 如果以上还不够，文件管理器中仍然没有AppImage图标。 Linux 世界尚未决定实施 elficon（尽管 и ），所以不可能将图标直接嵌入到应用程序中。 所以事实证明文件管理器中的应用程序没有自己的图标（没有区别，AppImage或其他东西），它们只在开始菜单中。 作为一种解决方法，我们使用缩略图，这是一种最初设计用于允许桌面管理器将图形文件的缩略图预览图像显示为图标的机制。 因此，用于设置可执行位的服务也可以充当“小型化器”，创建图标缩略图并将其写入适当的位置
/usrи$HOME。 如果 AppImage 被删除或移动，此服务还会执行清理操作。 由于每个桌面管理器的行为都略有不同，例如，它接受图标的格式、大小或位置，这真的很痛苦。 - 如果发生错误（例如，有一个库不是基本系统的一部分并且 AppImage 中未提供），应用程序在执行时就会崩溃，并且没有人在 GUI 中告诉用户到底发生了什么。 我们开始通过使用来解决这个问题 在桌面上，这意味着我们需要从命令行捕获错误，将其转换为用户可以理解的消息，然后需要将其显示在桌面上。 当然，每个桌面环境处理它们的方式都略有不同。
- 目前（2019年XNUMX月-译者注）我还没有找到一种简单的方法来告诉系统该文件
1.png必须使用 Krita 打开，并且2.png- 使用 GIMP。
用于的跨桌面规范的存储位置 , и 是 freedesktop.org
由于规范的原因，实现深入融入俳句工作环境的复杂程度即使不是不可能，也是很困难的 用于跨桌面，以及基于这些规范的桌面管理器的实现。 作为一个例子，我们可以引用一个系统范围的 Firefox 图标：显然，XDG 的作者甚至没有想到用户可以安装同一应用程序的多个版本。
不同版本 Firefox 的图标
我想知道 Linux 世界可以从 Mac OS X 中学到什么以避免搞砸系统集成。 如果您有时间并且对此感兴趣，请务必阅读最早的 Mac OS X 工程师之一 Arnaud Gurdol 所说的话：
我们希望安装应用程序就像将应用程序图标从某处（服务器、外部驱动器）拖到计算机驱动器上一样简单。 为此，应用程序包存储所有信息，包括图标、版本、正在处理的文件类型、系统处理应用程序所需的 URL 方案类型。 这还包括图标服务和启动服务数据库中“中央存储”的信息。 为了支持性能，应用程序会在几个“众所周知”的位置“发现”：系统和用户应用程序目录，以及当用户导航到包含应用程序的目录中的 Finder 时自动发现的其他位置。 在实践中，这非常有效。
Apple WWDC 2000 第 144 场会议 - Mac OS X：打包应用程序和打印文档。
Linux 桌面上没有类似的基础设施，因此我们正在寻找解决 AppImage 项目结构限制的方法。
Haiku 会来救援吗？
还有一件事：作为桌面环境基础的 Linux 平台往往没有明确规定，以至于在一致的全栈系统中非常简单的许多事情在 Linux 中却令人沮丧地支离破碎且复杂。 我用整个报告来讨论与桌面环境的 Linux 平台相关的问题（知识渊博的开发人员确认一切都将在很长一段时间内保持这种状态）。
我的2018年Linux桌面环境问题报告
就连 Linus Torvalds 也承认，碎片化是工作空间想法失败的原因。
很高兴看到俳句！
俳句让一切变得异常简单
虽然将AppImage“移植”到Haiku 的简单方法是简单地尝试构建（主要是runtime.c 和服务）其组件（这甚至是可能的！），但这不会给Haiku 带来太多好处。 因为事实上，这些问题大部分都在俳句中得到了解决，并且在概念上是合理的。 Haiku 提供的正是我长期以来在 Linux 桌面环境中寻找的系统基础架构构建块，我简直不敢相信它不存在。 即：
不管你信不信，这是许多 Linux 用户无法克服的问题。 在俳句中，一切都是自动完成的！
- 在文件管理器中双击时，没有可执行位的 ELF 文件会自动获得可执行位。
- 应用程序可以具有显示在文件管理器中的内置资源，例如图标。 无需将一堆图像复制到带有图标的特殊目录中，因此在删除或移动应用程序后无需清理它们。
- 有一个数据库用于将应用程序与文档链接起来，无需为此复制任何文件。
- 在可执行文件旁边的 lib/ 目录中，默认搜索库。
- 没有大量的发行版和桌面环境；只要有效，就可以在任何地方都有效。
- 没有与应用程序目录不同的单独模块可以运行。
- 应用程序没有内置的资源绝对路径；它们具有用于在运行时确定位置的特殊函数。
- 已经介绍了压缩文件系统镜像的思想：这是任何hpkg包。 它们都是由内核挂载的。
- 每个文件都由创建它的应用程序打开，除非您明确指定。 这多酷啊！
两个 png 文件。 请注意不同的图标，表明双击时它们将由不同的应用程序打开。 另请注意“打开方式：”下拉菜单，用户可以在其中选择单个应用程序。 多么简单啊！
看起来 Linux 上的 AppImage 所需的许多拐杖和解决方法在 Haiku 上变得不必要，Haiku 的核心是简单和复杂，这使得它能够满足我们的大部分需求。
Haiku 到底需要应用程序包吗？
这就引出了一个大问题。 如果在 Haiku 上创建像 AppImage 这样的系统比在 Linux 上容易一个数量级，那么值得这样做吗？ 或者 Haiku 及其 hpkg 软件包系统是否有效地消除了开发这样一个想法的需要？ 好吧，为了回答这个问题，我们需要看看 AppImages 存在背后的动机。
用户视角
让我们看看我们的最终用户：
- 我想安装应用程序而不要求输入管理员（root）密码。 Haiku 上没有管理员的概念，用户拥有完全的控制权，因为它是个人系统！ （原则上，你可以在多人模式下想象这一点，我希望开发者保持简单）
- 我希望获得最新和最好版本的应用程序，而不是等待它们出现在我的发行版中（通常这意味着“从不”，至少除非我更新整个操作系统）。 在俳句中，这是通过浮动版本“解决”的。 这意味着您可以获得最新和最好版本的应用程序，但要做到这一点，您需要不断更新系统的其余部分，有效地将其变成“移动目标”.
- 我想要并排使用同一应用程序的多个版本，因为无法知道最新版本中出现了什么问题，或者说，我作为一名 Web 开发人员，需要在不同版本的浏览器下测试我的工作。 俳句解决了第一个问题，但没有解决第二个问题。 更新会回滚，但仅限于整个系统；（据我所知）不可能同时运行多个版本的 WebPositive 或 LibreOffice。
一位开发人员写道：
本质上，其基本原理是这样的：用例非常罕见，因此对其进行优化没有意义； 将其视为 HaikuPorts 中的一个特例似乎是可以接受的。
- 我需要将应用程序保留在我喜欢的位置，而不是放在我的启动驱动器上。 我经常用完磁盘空间，因此我需要连接外部驱动器或网络目录来存储应用程序（我已下载的所有版本）。 如果我连接这样的驱动器，我需要通过双击来启动应用程序。 Haiku 保存旧版本的软件包，但我不知道如何将它们移动到外部驱动器，或者稍后如何从那里启动应用程序。
开发者评论：
从技术上讲，这已经可以通过 mount 命令实现。 当然，一旦我们有足够多的感兴趣的用户，我们就会为此制作一个 GUI。
- 我不需要分散在文件系统中的数百万个我无法手动管理的文件。 我想要每个应用程序一个文件，我可以轻松下载、移动、删除。 在 Haiku 上，这个问题是使用包解决的
.hpkg，例如，它将 python 从数千个文件传输到一个文件。 但如果有，例如，Scribus 使用 python，那么我必须处理至少两个文件。 我必须注意保留它们的相互兼容的版本。
多个版本的 AppImages 在同一 Linux 上并行运行
应用程序开发人员的视角
让我们从应用程序开发人员的角度来看：
- 我想控制整个用户体验。 我不想依赖操作系统来告诉我应该何时以及如何发布应用程序。 Haiku 允许开发人员使用他们自己的 hpkg 存储库，但这意味着用户必须手动设置它们，这使得这个想法“不太有吸引力”。
- 我的网站上有一个下载页面，我在其中分发
.exe对于 Windows，.dmg对于 Mac 和.AppImage对于Linux。 或者也许我想通过访问此页面来获利，一切皆有可能？ 我应该在俳句中放什么？ 文件就够了.hpkg仅依赖 HaikuPorts - 我的软件需要其他软件的特定版本。 例如，众所周知，Krita 需要 Qt 的补丁版本，或者 Qt 需要针对 Krita 的特定版本进行微调，至少在补丁被推回 Qt 之前是这样。 您可以将自己的 Qt 为您的应用程序打包在一个包中
.hpkg，但很可能这不受欢迎。
常规应用程序下载页面。 我应该在这里发布什么俳句？
将捆绑（作为应用程序目录存在，如 AppDir 或 .app Apple 风格）和/或图像（以经过大量修改的 AppImages 或 .dmg 来自 Apple）应用程序是 Haiku 桌面环境的有用补充吗？ 或者它会淡化整个画面并导致碎片化，从而增加复杂性吗？ 我很左右为难：一方面，俳句的美丽和精致是基于这样一个事实：做某事通常只有一种方法，而不是多种方法。 另一方面，目录和/或应用程序套件的大部分基础设施已经到位，因此系统迫切需要剩余的百分之几到位。
据开发商介绍
在 Linux 上他们（目录和应用套件， - 大约。 翻译者）很可能是系统性问题的技术解决方案。 在 Haiku，我们更喜欢简单地解决系统问题。
你怎么看？
在你回答之前...
等等，让我们快速检查一下现实情况：事实上 应用程序目录 - 已经是俳句的一部分：
应用程序目录已存在于 Haiku 上，但文件管理器尚不支持
它们只是没有像 Macintosh Finder 那样得到很好的支持。 如果 QtCreator 目录的左上角有一个“QtCreator”名称和双击时启动应用程序的图标，那该有多酷？
早些时候我已经 :
当所有应用程序商店和分发存储库都忘记了它们及其依赖项时，您确定今天可以运行已有十年历史的应用程序吗？ 您是否有信心将来仍能胜任目前的工作？
Haiku 是否已有答案，或者目录和应用程序包可以提供帮助吗？ 我认为他们可以。
据先生说。 摇摇晃晃地飞溅：
是的，我们有这个问题的答案：我们将在必要时支持这些应用程序，直到有人可以以正确的方式读取它们的文件格式或提供一对一的功能。 我们对 Haiku 支持 BeOS R5 应用程序的承诺证明了这一点......
这是正确的！
俳句应该采取什么行动？
我可以想象 hpkg、目录和应用程序映像和平共处：
- 系统软件用途
.hpkg - 对于最常用的软件（尤其是那些需要安排滚动发布的软件），使用
.hpkg（约占所有案例的 80%） - 一些安装通过
.hpkg，应用程序将受益于移动到应用程序目录基础设施（例如 QtCreator）：它们将作为.hpkg， 像以前一样。
先生。 waddlesplash 写道：
如果您需要的只是查看应用程序
/system/apps，相反，我们应该使 Deskbar 中的目录对用户来说更易于管理，因为/system/apps不适合用户定期打开和查看（与 MacOS 不同）。 对于这种情况，俳句有不同的范式，但这种选择在理论上是可以接受的。
- Haiku 接收用于运行应用程序映像、夜间、连续和测试软件构建的基础设施，以及用户想要“及时冻结”的情况、私人和内部软件以及其他特殊用例（约 20%）全部）。 这些图像包含运行应用程序所需的文件
.hpkg，由系统挂载，应用完成后-卸载。 （也许文件管理器可以将文件.hpkg自动或根据用户的请求将其添加到应用程序图像中 - 好吧，就像将应用程序拖到网络目录或外部驱动器时一样。 这只是一首歌！ 或者更确切地说，诗歌 - 俳句。）另一方面，用户可能希望以文件的形式安装图像的内容.hpkg，之后它们将以与通过 HaikuDepot 安装相同的方式进行更新和处理......我们需要集思广益）。
引自先生。 摇摇晃晃地飞溅：
从外部驱动器或网络目录运行应用程序可能很有用。 添加为 pkgman 配置更多“区域”的功能绝对是一个不错的功能。
这样的系统将利用 hpkg、目录和应用程序映像。 他们各自都很好，但团结起来就会所向无敌。
结论
Haiku 拥有一个为 PC 提供简单而复杂的用户体验的框架，并且远远超出了通常为 Linux PC 提供的体验。 封装系统 .hpkg 就是这样一个例子，但系统的其余部分也充满了复杂性。 然而，Haiku 将受益于适当的目录和应用程序图像支持。 如何最好地做到这一点值得与比我更了解俳句、其哲学和架构的人讨论。 毕竟，我使用俳句已经一个多星期了。 尽管如此，我相信 Haiku 的设计师、开发人员和建筑师将从这种新鲜的视角中受益。 至少，我很乐意成为他们的“陪练”。 我在 Linux 应用程序目录和捆绑包方面拥有超过 10 年的实践经验，我希望在 Haiku 中找到它们的用途，我认为它们是完美的选择。 我提出的潜在解决方案绝不是针对我所描述的问题唯一正确的解决方案，如果 Haiku 团队决定寻找其他更优雅的解决方案，我完全支持。 基本上我已经在想如何做一个系统的想法了 hpkg 在不改变其工作方式的情况下甚至更令人惊奇。 事实证明，Haiku 团队在实现包管理系统时很长一段时间以来一直在考虑应用程序包，但不幸的是（我认为）这个想法变得“过时”了。 也许是时候复兴它了？
自己尝试一下吧！ 毕竟，Haiku 项目提供了从 DVD 或 USB 启动的映像，生成 .
你有任何问题吗？ 我们邀请您参加俄语 .
错误概述：
从 翻译：这是俳句系列中的第八篇也是最后一篇文章。
文章列表：
只有注册用户才能参与调查。 拜托
将hpkg系统移植到Linux有意义吗？
-
是
-
没有
-
已经实现了，我会写在评论里
20 位用户投票。 5 名用户弃权。
来源： habr.com