还有什么：Haiku应用程序包？

TL; DR ：Haiku能否获得对应用程序包的适当支持，例如应用程序目录（如Mac上的.app ）和/或应用程序映像（Linux AppImage ）？ 在我看来，这将是一个值得的补充，因为大多数基础结构已经存在，因此与其他系统相比，它更容易正确实施。

一周前，我发现了Haiku，一个出乎意料的好系统。 好吧，由于我对目录和应用程序映像一直很感兴趣（受Macintosh的简单性启发），所以想到一个主意就不足为奇了……

全面了解：我是AppImage的创建者和作者，AppImage是一种Linux应用程序分发格式，旨在简化Mac，并为应用程序作者和最终用户提供完全的控制权（想要了解更多信息，请参阅Wiki和文档 ）。

如果我们为Haiku做一个AppImage怎么办？

让我们从理论上考虑一下：为了在Haiku上获得AppImage或类似的东西，需要做什么？ 不必立即创建任何东西，因为Haiku中已经存在的系统运行异常，但是通过虚构的实验证明它是不错的。 与Linux桌面环境相比，他还展示了Haiku的先进性，在Linux桌面环境中，此类事情非常困难（我有权这样说：我已经调试了10年）。

在Macintosh系统1上，每个应用程序都是一个单独的文件，在Finder中进行“管理”。 我使用AppImage尝试在Linux上重新创建相同的用户体验。

首先，什么是AppImage？ 这是一个用于发布第三方应用程序的系统（例如Ultimaker Cura ），该系统使您可以在何时何地狩猎应用程序：他们不需要了解各种发行版的功能，构建策略或构建基础结构，它们不需要维护者的支持，也不会告诉用户什么（不是）可以安装在计算机上。 AppImage应该被理解为类似于.dmg磁盘映像中.app格式的Mac软件包。 主要区别在于应用程序不会被复制，而是始终保留在AppImage中，就像安装Haiku .hpkg软件包一样，并且从不按通常的意义安装。

十多年来，AppImage赢得了一定的吸引力和人气：Linus Torvalds本人公开批准了它，并且广泛的项目（例如LibreOffice，Krita，Inkscape，Scribus，ImageMagick）将其作为分发连续或夜间组件的主要方式，而不是干扰已安装或未安装的用户应用程序。 但是，Linux桌面和发行版通常仍然坚持基于维护者的传统集中式发行模型，并且/或者促进基于Flatpak （RedHat，Fedora，GNOME）和Snappy （Canonical，Ubuntu）的自己的公司业务和/或工程程序。 变得有趣 。

如何运作

• 每个AppImage包含两部分：双击可执行的小型ELF（即所谓的runtime.c ），然后是SquashFS文件系统映像。

• SquashFS文件系统包含应用程序形式的有效负载以及运行它所需的一切，在您看来，不能将其视为每个相当新的目标系统（Linux发行版）的默认安装的一部分。 它还包含元数据，例如，应用程序名称，图标，MIME类型等。

• 当由用户启动时，运行时使用FUSE和squashfuse挂载文件系统，之后它在已挂载的AppImage中处理某些入口点（所谓的AppRun）的启动。
  该过程完成后，将卸载文件系统。

似乎一切都很简单。

这些使事情变得复杂：

• 在如此众多的Linux发行版中，没有什么“在他们的头脑中”可以称为“每个新目标系统默认安装的一部分”。 我们通过组合一个excludelist来解决此问题，该列表使我们可以确定将在AppImage中打包的内容以及需要在其他地方获取的内容。 同时，尽管总的来说一切正常，但有时我们还是会怀念。 因此，我们建议程序包创建者在所有目标系统（发行版）上检查AppImage。
• 有效负载形式的应用程序必须在文件系统中漫游。 不幸的是，在许多应用程序中，硬编码到/usr/share资源的绝对路径。 这需要以某种方式解决。 另外，您必须导出LD_LIBRARY_PATH或修复rpath以便加载程序可以找到相关的库。 第一种方法有其缺点（以复杂的方式进行管理），第二种方法很麻烦。
• 用户最大的UX陷阱是下载后将可执行位设置为AppImage文件。 信不信由你，对某些人来说，这是一个真正的障碍。 即使对于高级用户，也需要设置可执行位。 作为一种解决方法，我们建议安装一个小型服务来监视AppImage文件并为其设置可执行位。 以其纯粹的形式，不是最佳的解决方案，因为它将无法立即使用。 Linux发行版不提供此服务，因此，开箱即用的用户表现不佳。
• Linux用户希望新应用程序在启动菜单中具有一个图标。 您无法告诉系统：“看，有一个新的应用程序，让我们开始工作。”相反，根据XDG规范，您需要将.desktop文件复制到/usr的所需位置以进行系统范围的安装，或者将$HOME .desktop复制到$HOME以进行单独安装。根据规范，某些尺寸的图标XDG，您需要将其放在usr或$HOME中的某些位置，然后在工作环境中运行命令以更新图标缓存，或者希望工作环境管理器可以解决该问题并自动检测所有内容（与MIME类型类似）。作为一种解决方法，它提供了 若要使用相同的服务，除了设置执行标志之外，如果AppImage中有图标等，还将根据XDG将它们从AppImage复制到正确的位置，则假定该服务在删除或移动它时将清除所有内容。当然，每个服务的行为都存在差异工作环境中的图形文件格式，其大小，存储位置以及更新缓存的方式，这会产生问题，简而言之，此方法是一个cr脚。
• 如果以上还不够，则文件管理器中没有AppImage图标。 在Linux世界中，他们仍然没有决定实现elficon（尽管进行了讨论和实现 ），因此不可能将图标直接嵌入应用程序中。 因此，事实证明文件管理器中的应用程序没有它们自己的图标（没有区别，AppImage或其他），它们只是在开始菜单中。 作为一种解决方法，我们使用缩略图-一种最初开发的机制，使桌面管理器可以显示缩略图以预览图形文件作为其图标。 因此，用于设置可执行位的服务还可以用作“微型化程序”，在相应的位置/usr和$HOME创建和记录图标的缩略图。 如果删除或移动了AppImage，此服务还将执行剥离。 由于每个桌面管理器的行为都有一些不同，例如，它接受图标的格式，大小和位置都有些不同，这确实很痛苦。
• 如果发生错误（例如，有一个库不是基本系统的一部分，也不在AppImage中提供），则该应用程序仅在运行时崩溃，并且没有人告诉GUI发生了什么。 我们开始使用桌面上的通知来解决此问题，这意味着我们需要从命令行捕获错误，将其转换为用户可理解的消息，然后仍然需要在桌面上显示这些消息。 当然，每个工作环境对它们的处理方式也有所不同。
• 目前（2019年9月，大约翻译），我还没有找到一种简单的方法来告诉系统1.png使用Krita打开1.png文件以及使用GIMP打开1.png文件。

GNOME ， KDE和Xfce使用的跨桌面规范的存储位置是freedesktop.org。

很难（即使不是不可能）实现扎根于Haiku工作环境的复杂程度，这是由于freedesktop.org针对跨桌面的XDG规范以及基于这些规范的桌面管理器的实现。 例如，我们可以举一个系统范围内的Firefox图标：显然，XDG的作者甚至没有认为用户可以拥有同一应用程序的多个版本。

不同版本的Firefox的图标

我想知道Linux世界可以从Mac OS X中学到什么，以免搞乱系统集成。 如果您有时间并且正在这样做，请务必阅读Mac OS X最早的工程师之一Arno Gourdol所说的话：

我们希望像将应用程序图标从某处（服务器，外部驱动器）拖到计算机磁盘一样容易地安装该应用程序。 为此，所有信息都存储在应用程序包中，包括图标，版本，正在处理的文件类型以及系统处理该应用程序必须知道的URL方案的类型。 这还包括Icon Services和Launch Services数据库中“集中存储”的信息。 为了保持性能，会在多个“知名”位置“发现”应用程序：在系统目录和用户目录中，如果用户已将Finder移至包含应用程序的目录，则会自动在其他目录中找到应用程序。 实际上，这非常有效。

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000会话144-Mac OS X：打包应用程序和打印文档。

在Linux桌面上没有与此基础设施类似的东西，因此我们正在寻找有关AppImage项目中结构限制的解决方法。

Haiku是否急于提供帮助？

还有另外一件事：作为工作环境基础的Linux平台通常没有被指定，以至于在具有完整堆栈的一致系统中非常简单的许多事情使Linux的碎片化和复杂性令人失望。 我专门针对与工作环境Linux平台相关的问题撰写了一份完整的报告（知识丰富的开发人员已确认：一切都会保留很长时间）。

我关于2018年Linux桌面环境的报告

甚至Linus Torvalds也承认，由于环境分散，工作环境的想法失败了。

很高兴见到Hai句！

使用Haiku，一切都变得非常简单。

尽管将AppImage移植到Haiku的幼稚方法只是尝试构建（主要是runtime.c和service）其组件（甚至有可能！），但它不会给Haiku带来太多好处。 因为实际上这些问题大多数已经由Haiku解决，并且在概念上是合理的。 Haiku正是为我在Linux桌面环境中寻找了很长时间的系统基础结构提供了那些积木，并且不敢相信它们不存在。 即：

信不信由你，许多Linux用户无法克服这一点。 在Haiku，一切都是自动完成的！

• 当您在文件管理器中双击时，没有可执行位的ELF文件会自动接收它。
• 应用程序可以具有嵌入式资源，例如，出现在文件管理器中的图标。 您无需将一堆图像复制到特殊图标目录，因此，在删除或移动应用程序后无需清理它们。
• 有一个用于将应用程序与文档链接的数据库，因此无需复制任何文件。
• 在可执行文件旁边的lib /目录中，默认情况下会搜索库。
• 没有很多发行版和桌面环境，所有这些都可以工作-随处可用。
• 没有与Applications目录不同的单独的启动模块。
• 应用程序没有到其资源的内置绝对路径；有一些特殊功能可在运行时确定位置。
• 引入了压缩文件系统映像的概念：这是任何hpkg软件包。 所有这些都由内核安装。
• 除非您明确指定其他内容，否则每个文件都会由创建它的应用程序打开。 太棒了！

两个png文件。 注意不同的图标，表明它们将通过双击由不同的应用程序打开。 还请注意下拉菜单“打开方式：”，用户可以在其中选择单独的应用程序。 多么简单！

在Haiku上，Linux上AppImage所需的许多拐杖和变通方法似乎变得不必要了，因为Haiku是基于简单性和复杂性的，因此它可以满足我们的大多数需求。

Haiku最终需要应用程序包吗？

这导致了一个大问题。 如果在Haiku上创建像AppImage这样的系统比在Linux上简单一个数量级，是否值得？ 还是Haiku的hpkg软件包系统实际上消除了发展这种想法的需要？ 好吧，要找到答案，您需要查看AppImages存在的动机。

用户查看

看一下我们的最终用户：

• 我想安装该应用程序而无需询问管理员密码（root）。 在Haiku上，没有管理员的概念，用户拥有完全控制权，因为这是个人系统！ （原则上，您可以想象在多用户模式下实现这一点，希望开发人员能够保持简单性）
• 我想获取最新和最佳的应用程序版本，而不是等待它们出现在我的发行版中（通常，这意味着“从不”，至少在不更新整个操作系统的情况下）。 在Haiku上，这是通过浮动发行版“解决”的。 这意味着可以获得最新和最佳版本的应用程序，但是为此，您需要不断更新系统的其余部分，实际上将其变成“移动目标” 。
• 我想在附近找到同一应用程序的多个版本，因为您无法找到最新版本中存在的问题，或者例如，作为一名Web开发人员，我需要在不同版本的浏览器下检查我的工作。 Haiku解决了第一个问题，但没有解决第二个问题。 更新会回滚，但仅针对整个系统，不可能（例如，我知道）同时启动多个版本的WebPositive或LibreOffice。

其中一位开发人员写道：

从本质上讲，基本原理是：用例很少见，以至于优化没有意义； 在HaikuPorts将其作为特殊情况进行处理似乎是可以接受的。

• 我需要将应用程序保存在我喜欢的位置，而不是保存在启动磁盘上。 我经常会用完磁盘空间，因此需要连接外部驱动器或网络目录来存储应用程序（我下载的所有版本）。 如果连接了这样的驱动器，则需要双击来启动应用程序。 Haiku保存了较旧版本的软件包，但是我不知道如何将其移动到外部驱动器，或者以后如何从那里调用应用程序。

开发者评论：

从技术上讲，这已经可以通过mount命令实现。 当然，只要有足够的感兴趣的用户聚集起来，我们就会为此创建一个GUI。

• 我不需要分散在文件系统中的数百万个我无法手动管理的文件。 我想要每个应用程序一个文件，我可以轻松下载，移动和删除该文件。 在Haiku上，借助于.hpkg软件包解决了此问题，该软件包将python等从数千个文件传输到一个文件。 但是，如果有使用python的Scribus，那么我必须处理至少两个文件。 而且我必须注意保持它们的版本相互配合。

在单个Linux上并行运行的AppImages的众多版本

从应用程序开发人员的角度查看

让我们从应用程序开发人员的角度来看：

• 我想管理整个用户体验。 我不想依赖操作系统，操作系统会告诉我何时以及如何发布应用程序。 在Haiku，开发人员可以使用自己的hpkg系统信息库，但这意味着用户将需要手动配置它们，这使这种想法吸引力降低。
• 我在我的网站上有一个下载页面，在该页面上分发Windows的.exe ，Mac的.dmg和Linux的.AppImage 。 或者，也许我想通过访问该页面获利，可以吗？ 我需要在那里张贴Haiku的内容吗？ 仅带有.hpkg依赖项的.hpkg文件
• 我的软件需要其他软件的某些版本。 例如，已知Krita需要一个固定版本的Qt或Qt，该版本必须微调到特定版本的Krita，至少要等到修正返回Qt为止。 您可以使用.hpkg软件包将自己的Qt打包在应用程序中，但这很可能不受欢迎。

正常的应用程序下载页面。 在这里为Haiku放置什么？

捆绑包（以Apple风格的AppDir或.app类的应用程序目录存在）和/或图像（经过大量修改的Apple的AppImages或.dmg ）是否会对Haiku工作环境有用？ 还是会稀释整个图片并导致碎片化，从而增加复杂性？ 我很伤心：一方面，ku句的美丽和精致是基于这样的事实，通常有一种做某事的方法，而不是很多。 , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

结论

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

文章列表：第一， 第二， 第三， 第四， 第五， 第六， 第七，第八，第九