TL博士：Haiku 是一款专门为 PC 设计的操作系统，因此它有几个技巧使其桌面环境比其他操作系统好得多。 但它是如何运作的呢？
我发现了俳句，一个意想不到的好系统。 我仍然对它的运行如此流畅感到惊讶，特别是与 Linux 桌面环境相比。 今天我将深入了解一下。 在需要深入理解的地方，我将与原始的 Macintosh、Mac OS X 和 Linux 桌面环境（来自 freedesktop.org 的 XDG 标准）进行比较。
ELF 文件中的资源
昨天我了解到 IconOMatic 可以将图标保存在 ELF 可执行文件中的 rdef 资源中。 今天我想看看它到底是如何运作的。
资源？ 从 Macintosh Finder 的原作者、Macintosh 资源管理器的“之父”：
我担心传统编码的僵化性质。 对我来说，将应用程序冻结在代码中而无法动态更改任何内容的想法是最疯狂的。 应该可以在运行时尽可能多地进行更改。 当然，应用程序代码本身无法更改，但肯定可以在不重新编译代码的情况下更改某些内容吗？
在最初的 Macintosh 上，他们使这些文件具有“数据部分”和“资源部分”，这使得保存图标、翻译等内容变得非常容易。 在可执行文件中。
在 Mac 上使用这个 ，一个用于突然编辑资源的图形程序。
原始 Macintosh 上的 ResEdit
结果，编辑图标、菜单项、翻译等成为可能。 很容易，但他们仍然与应用程序一起“旅行”。
无论如何，这种方法有一个很大的缺点：它只适用于Apple文件系统，这也是Apple在转向Mac OS X时放弃“资源部分”的原因之一。
在 Mac OS X 上，Apple 想要一个独立于文件系统的解决方案，因此他们采用了包的概念（来自 NeXT），即被文件管理器视为“不透明对象”的目录，就像文件而不是目录一样。 任何带有以下格式的应用程序的包 .app 除其他外，还有一个文件 Info.plist （在 Apple 的 JSON 或 YAML 等价物中）包含应用程序元数据。
Mac OS X 应用程序包中的 Info.plist 文件的键。
资源（例如图标、UI 文件等）作为文件存储在包中。 这个概念实际上可以追溯到 NeXT 中。
1.0 年 NeXTSTEP 1989 上的 Mathematica.app：在终端中显示为文件目录，但在图形文件管理器中显示为单个对象。
让我们回到 BeOS，俳句所基于的概念。 其开发人员在从 PEF (PowerPC) 切换到 ELF (x86)（与 Linux 上使用的相同）时，决定在 ELF 文件的末尾添加一个资源部分。 它没有使用自己正确的 ELF 部分，它只是附加到 ELF 文件的末尾。 由于该计划 strip binutils 中的其他人不知道这一点，只是将其切断。 因此，在BeOS上向ELF文件添加资源时，最好不要使用Linux工具对其进行操作。
俳句现在怎么样了？ 基本上，或多或少是一样的。
理论上，可以将资源放置在 ELF 的所需部分。 根据 irc.freenode.net 上 #haiku 频道的开发人员的说法：
有了 ELF，这一部分就更有意义了……我们不这样做的唯一原因是我们在 BeOS 中就是这样做的。”
现在没有必要改变这一点。
资源管理
资源以结构化“资源”格式编写：本质上是资源的列表，其中包含大小及其内容。 我记得 .
如何查看俳句资源？ 有没有类似ResEdit的东西？
根据 :
要查看应用程序包中提供的资源，您可以将可执行文件拖到诸如 。 您也可以转到终端并运行命令
listres имя_файла.
Resourcer 在 HaikuDepot 中可用，但它对我来说崩溃了。
如何管理ELF文件中的资源？ 使用 rsrc и rdef. rdef 文件收集在 rsrc。 文件 rdef 以纯文本格式存储，因此更容易使用。 文件格式 rsrc 附加到 ELF 文件的末尾。 我们来尝试玩一下：
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and license您可以使用该程序 xres 用于检查和控制：
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)好吧，我们试试？
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSION有关资源和格式的更多信息 rdef 你可以读 .
标准资源类型
尽管您可以将任何内容放入资源中，但有一些定义的标准类型：
app_signature：MIME应用程序类型，用于文件打开映射、启动、IPC等。app_name_catalog_entry：由于应用程序名称通常为英文，因此您可以指定翻译名称所在的位置，以便不同语言的用户根据需要看到翻译的应用程序名称。app_version: 正是你所想的app_flags: 表示registrar如何处理申请。 我认为事情远不止表面上看到的那样。 例如，有B_SINGLE_LAUNCH，这会强制系统在每次用户请求时启动一个新的应用程序进程（Linux 上的大多数应用程序都使用相同的原理）。 吃B_MULTIPLE_LAUNCH，导致进程运行 每个文件。 最后有B_EXCLUSIVE_LAUNCH，这会强制系统一次仅启动一个进程，无论用户启动的频率如何（例如，这就是 Firefox 在 Linux 上运行的方式；使用该函数在 Qt 应用程序中可以实现相同的结果 ）。 应用程序与B_EXCLUSIVE_LAUNCH当用户尝试再次运行它们时会收到通知：例如，它们会收到用户想要在其帮助下打开的文件的路径。vector_icon：矢量应用程序图标（BeOS 没有矢量图标，大多数应用程序在其可执行文件中都有两个光栅图标）。
当然，您可以添加具有任何所需 ID 和类型的资源，然后在应用程序本身或使用该类的其他应用程序中读取它们 BResources。 但首先，让我们来看看图标这个有趣的话题。
俳句风格的矢量图标
当然，不仅仅是Haiku选择了最好的图标格式；在这一部分，Linux桌面环境的情况也很不理想：
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cache看到这个你就已经能感觉到这是一个什么样的作品了。
当然，还有可扩展的，正如您所理解的，其中包含矢量图标。 那为什么还有别的事呢？ 因为以小尺寸绘制矢量图形的结果可能不太理想。 我想要针对不同尺寸优化不同的选项。 在 Linux 桌面环境中，这是通过在整个文件系统中分散不同大小的图标来实现的。
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png请注意：Firefox 没有不同版本的概念。 因此，不可能优雅地处理系统上存在应用程序的多个版本的情况。
不同版本的 Firefox 图标不同。 目前，如果没有各种拐杖，在 Linux 中处理这个问题是不可能的。
Mac OS X 处理得更巧妙一些：
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns可以看到有一个文件 firefox.icns 包装内 Firefox.app，包含所有尺寸，以便同一应用程序的不同版本具有不同的图标。
好多了！ 图标随应用程序一起移动，所有资源都在一个文件中。
让我们回到俳句。 一个令人兴奋的解决方案，无一例外。 根据 :
开发了一种特殊的 HVIF 格式，针对小尺寸和快速渲染进行了高度优化。 因此，我们的图标大部分都比光栅或广泛使用的 SVG 格式小得多。
并且它们仍在优化：
HVIF 中的图标大小与其他格式的比较。
差别是一个数量级！
但魔法并没有就此结束。 即使它是矢量格式，相同的 HVIF 也可以根据显示的大小显示不同级别的细节。
根据渲染大小不同的细节级别 (LOD)
现在谈谈缺点：你不能将 SVG 放入 ImageMagick 中然后就到此为止；你必须经过几个周期才能创建 HVIF 格式的图标。 解释。 然而，IconOMatic 导入 SVG 的能力相当不完善； 大约 90% 的 SVG 详细信息有一定概率导入，其余 10% 需要手动配置和更改。 详细了解 HVIF 如何发挥其魔力 在博客中
向应用程序添加图标
现在我可以向创建的包添加一个图标 ，考虑到收到的所有信息。
好吧，由于我现在并不特别渴望为我的“Hello, World”QtQuickApp 绘制自己的图标，所以我将其从 Qt Creator 中取出。
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator让我们检查一下图标是否已被复制：
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICON看起来不错，但是为什么复制新图标后不显示？
复制的 VICN:101:BEOS:ICONs 尚未在文件管理器中用作应用程序图标
我错过了什么？
开发者评论：
我们需要创建一个文件
rdef拥有所有资源，然后执行命令rc имя.rdef，这将创建文件.rsrc。 然后你需要运行命令resattr -o имя_бинарника имя.rsrc。 至少，我使用这样的命令将图标添加到我的脚本中。
嗯，我想创建一个资源，而不是一个属性。 我真的很困惑。
使用文件系统的智能缓存
打开和读取ELF属性很慢。 正如我上面所写，图标作为资源写入文件本身。 此方法更可靠，并且允许您在复制到另一个文件系统时幸存下来。 但是，它随后也会被复制到文件系统属性，例如 BEOS:ICON。 这只适用于某些文件系统，例如 BFS。 系统（在跟踪器和桌面栏中）显示的图标是从该扩展属性中读取的，因为该解决方案运行速度很快。 在某些地方（速度并不重要，例如典型的“关于”窗口），系统直接从文件中的资源接收图标。 但这还没有结束。 请记住，在 Mac 上，用户可以用自己的图标替换应用程序、目录、文档的图标，因为在 Mac 上可以执行这些“重要”操作，例如 。 在俳句中，您应该将资源（在文件中）视为应用程序附带的原始图标，将属性（在 BFS 文件系统中）视为允许用户随意进行更改的东西（不过，提示，用于在图标顶部插入自定义图标的 GUI 是可选的）。默认情况下尚未实现）。
检查文件系统属性
同 resaddr 可以检查和设置文件系统属性。
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)它本质上是执行（可靠）资源和（快速）文件系统属性之间来回转换的“粘合剂”。 由于系统期望接收资源并自动进行复制，因此我不会再担心它。
hpkg 软件包的魔力
目前（最常）使用软件包来获取 Haiku 上的节目 .hpkg。 不要被简单的名称所迷惑：.hpkg 格式的工作方式与您遇到的具有类似名称的其他格式完全不同，它具有真正的超能力。
对于传统的包格式，我因为以下事实而烦恼了很长一段时间：您下载了一个东西（包），而系统上安装了另一个东西（包内的文件）。 以传统方式安装软件包时，管理文件（例如删除它们）是相当困难的。 而这一切都是因为包装中的内容 分散在整个文件系统中，包括普通用户可能没有写访问权限的地方。 这产生了一整类程序—— 包管理器。 但是，将已安装的软件转移到另一台机器、可移动磁盘或文件服务器上，即使不是完全不可能，也会变得更加困难。 在典型的基于 Linux 的系统上，很容易就有数十万到数百万个单独的文件。 不用说，这既脆弱又缓慢，例如在最初安装系统时，安装、更新和卸载常规软件包时，以及将启动卷（根分区）复制到另一个介质时。
我正在开发 AppImage 项目，这是最终用户应用程序的部分拐杖。 这是一种软件分发格式，它将应用程序及其所有依赖项收集到应用程序启动时安装的单个文件系统映像中。 显着简化了事情，因为同一个 ImageMagick 突然变成一个文件，由普通人在文件管理器中管理。 所提出的方法仅适用于软件，正如项目名称所反映的那样，并且也有其自身的一系列问题，因为参与为 Linux 提供软件的人总是将箭头指向我。
让我们回到俳句。 是否有可能在传统软件包系统和基于镜像的软件交付之间找到最佳平衡点？ 她的包裹 .hpkg 实际上是压缩的文件系统映像。 当系统启动时，内核会挂载所有已安装和活动的软件包，并显示大约以下内核消息：
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"很酷，是吗？ 坚持住，会更酷！
有一个很特别的包：
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"它包含一个非常简约的操作系统，包括内核。 不管你信不信，甚至内核本身也没有从启动卷（根分区）中删除，而是从包中小心地加载到其位置 .hpkg。 哇！ 我已经提到过，我认为 Haiku 的整体复杂性和一致性部分来自于这样一个事实：整个系统，从内核和核心用户空间到包管理和运行时基础设施，都是由一个团队协作开发的。 想象一下需要多少个不同的团体和团队才能在 Linux 上运行这样的东西 [我想象 PuppyLinux 项目 - 大约。 译者]。 然后想象一下这种方法需要多长时间才能被采用到发行版中。 他们说：把一个简单的问题分给不同的执行者，它就会变得如此复杂，以至于无法解决。 俳句在这种情况下让我大开眼界。 我认为这正是 Linux 上现在正在发生的事情（这里的 Linux 是 Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu 堆栈的统称）。
使用hpkg进行系统回滚
以下情况多久会发生：更新成功，然后发现某些功能无法正常工作？ 如果您使用传统的包管理器，则很难将系统状态返回到安装新包之前的某个时间点（例如，在出现问题时）。 有些系统以文件系统快照的形式提供了解决方法，但它们相当麻烦，并且并非在所有系统上都使用。 Haiku 使用包解决了这个问题 .hpkg。 每当系统中的包发生更改时，旧包不会被删除，而是存储在系统中的子目录中，例如 /Haiku/system/packages/administrative/state-<...>/ 不断地。 未完成的操作将其数据存储在子目录中 /Haiku/system/packages/administrative/transaction-<...>/.
内容 /Haiku/system/packages/administrative。 “state...”目录包含带有活动包名称的文本文件，“transaction...”目录包含包本身。
“旧的活动状态”，即列表 .hpkg 在文件管理器中的每个操作之后，将更改之前处于活动状态的软件包记录在文本文件中 /Haiku/system/packages/administrative/state-<...>/activated-packages。 以类似的方式，将新的“活动状态”写入文本文件中 /Haiku/system/packages/administrative/activated-packages.
目录 /Haiku/system/packages/administrative/state-<...>/ 仅包含一个文本文件，其中包含此状态的活动软件包列表（在安装软件包而不删除的情况下），并且如果软件包被删除或更新 - 状态目录包含旧版本的软件包。
当系统启动时，根据软件包列表，决定激活（安装）软件包。 就这么简单！ 如果下载过程中出现问题，您可以告诉下载管理器使用不同的旧列表。 问题解决了！
俳句下载器。 每个入口点显示相应的“活动状态”
我喜欢将简单的文本文件作为“活动状态”列表的方法，并使用易于理解的名称 .hpkg。 这与为机器而不是为人而构建形成鲜明对比。 来自文件系统中的 OSTree 或 Flatpak（与 Microsoft GUID 处于同一级别）。
每个时间点的活动包列表
配置数据
显然，在目录中 /Haiku/system/packages/administrative/writable-files 包含包的配置文件，但它们是可写的。 毕竟，正如你所记得的， .hpkg 以只读方式安装。 所以在写入之前必须从包中复制这些文件。 有其意义。
.hpkg 系统的 GUI 集成
现在让我们看看这些闪亮的包包如何 .hpkg 应对与用户工作环境 (UX) 的集成。 毕竟俳句是供个人使用的。 就我个人而言，在将用户体验与套餐进行比较时，我设定了很高的标准 .app 在 Macintosh 上有相同的体验 .hpkg。 我什至不会将这种情况与 Linux 上的工作环境进行比较，因为与其他任何环境相比，它绝对是糟糕的。
我想到了以下场景：
- 我想查看包裹的内容
.hpkg - 我想安装一个包
- 我想删除该包
- 我想删除作为包的一部分进入系统的某些内容
- 我想复制作为包的一部分进入系统的内容
- 我想下载一个包的所有依赖项，这可能不是每个 Haiku 安装的一部分（例如，我有一台物理隔离的计算机，无法访问互联网。）
- 我想将我的包（或其中的一部分）单独移动到另一个位置，与启动卷（根分区）分开（因为，例如，我没有足够的空间）。
这应该涵盖了我日常工作中的大部分主要案例。 好吧，让我们开始吧。
检查包裹内容
在 Mac 上 我只需右键单击该包即可将其打开并在 Finder 中查看内容。 毕竟，实际上它只是一个伪装的目录！ （我知道有包 .pkg 对于系统的一部分，不是应用程序，但普通用户通常不与它们交互）。
论俳句 我右键单击该包，然后单击“内容”以查看里面的内容。 但这里只是文件列表，无法通过双击打开它们。
如果有办法（暂时）挂载包就更好了 .hpkg 通过文件管理器查看，用户不必担心实现细节。 （顺便说一句，你可以打开 .hpkg 封装在 Expander，它可以像任何其他存档一样解压它）。
HaikuDepot 的界面允许查看包文件列表，但无法通过双击 README.md 等方式查看内容
Mac 在这一类别中获胜，但添加您想要的 HaikuDepot 功能应该不会太困难。
通过 GUI 安装软件包
在 Mac 上, 大多数磁盘映像 .dmg 包含包 .app。 双击磁盘映像，然后复制包，例如将其拖入 /Applications 在查找器中。 这对我来说是不言而喻的，但我听说有些新手可能无法处理这个问题。 默认情况下，Apple“建议”系统范围的目录 /Applications （在 NeXT 上它既是联网的也是单独的），但是您可以轻松地将应用程序放在文件服务器或子目录中 $HOME/Applications，如果你喜欢这样的话。
论俳句，双击该软件包，然后单击“安装”，这再简单不过了。 我想知道如果某个包具有 HaikuPorts 中可用但尚未安装的依赖项，会发生什么情况。 在 Linux 上，他们真的不知道在这种情况下该怎么办，但解决方案很明显 - 询问用户是否需要下载并安装依赖项。 这正是俳句所做的。
我手动下载了“理智”包并单击它，包管理器知道从哪里获取其依赖项（假设存储库已在系统上注册）。 并不是每个 Linux 发行版都能做到这一点。
另一种方法是使用文件管理器，只需拖放即可 .hpkg 包装或在 /Haiku/system/packages （对于系统范围的安装，默认情况下），或者在 /Haiku/home/config/packages （对于个人安装；双击时不可用 - 我仍然对这个地方的“配置”一词感到恼火，在这种情况下，对我来说，它与“设置”同义）。 多用户的概念甚至还不适用于俳句（这可能就是它如此简单的原因 - 我不知道，也许多用户功能会让桌面环境变得不必要的复杂化）。
Haiku 在这一类别中获胜是因为它不仅可以与应用程序一起使用，还可以与系统程序一起使用。
从 GUI 中删除包
在 Mac 上，您只需将应用程序图标拖到垃圾桶即可。 容易地！
论俳句，首先，您需要找到该软件包在系统上的位置，因为您很少将其安装在正确的位置（系统会做所有事情）。 通常你需要查看 /Haiku/system/packages （系统范围内的默认安装），或者在 /Haiku/home/config/packages （我有没有提到“配置”是一个用词不当？）。 然后，只需将应用程序拖到垃圾箱即可。
容易地！ 不过，我不会这么说。 这是真正发生的事情：
如果您将应用程序拖到垃圾桶中，就会发生这种情况 /Haiku/system/packages
刚刚尝试将昨天 QtQuickApp 上的“Hello World”应用程序移至垃圾箱。 我没有尝试移动系统目录， 由于所有软件包都安装在系统目录中，因此无法删除该软件包 .hpkg 没有改变 “其内容”。 普通用户会感到害怕并按下默认分配的“取消”按钮。
解释 :
这篇文章已有 10 多年历史了。 我们很可能需要对其进行配置，以便仅在移动包本身时才会出现警告。 无论如何，普通用户不需要这样做。
好吧，也许我应该使用 HaikuDepot 来做到这一点？ 我双击该包 /Haiku/system/packages，等待“卸载”按钮出现。 不，只有“安装”。 “卸载”，你在哪里？
只是为了好玩，我尝试看看如果在已安装的软件包上单击“安装”会发生什么。 结果是这样的：
如果您尝试安装已安装的软件包，就会发生这种情况。
接下来出现：
如果您在上一个窗口中单击“应用更改”，它将如下所示
我认为这是一个软件错误；应用程序的链接已经存在。 [作者没有提供链接 - 大约。 译者]
快速解决方案：如果软件包已存在，则添加“卸载”按钮
/Haiku/system/packages，或/Haiku/home/config/packages.
当查看 HaikuDepot 中安装的软件包列表时，我在列表中看到我的软件包，并且可以将其删除。
Mac 在这一类别中获胜。 但我可以想象，通过正确的设置，Haiku 上的用户体验将比 Mac 上更好。 （其中一位开发人员这样评价它：“如果你懂一点 C++，不到一个小时就可以将指定的功能添加到 HaikuDepot”，有志愿者吗？）
从包裹中取出物品
让我们尝试删除应用程序本身，而不是包 .hpkg，它来自哪里（我怀疑对于“凡人”来说有什么区别）。
在 Mac 上，用户实际上通常使用该文件 .dmg应用程序包从哪里来 .app。 通常是图像 .dmg 累积在下载目录中，包由用户复制到 /Applications。 相信很多用户自己都不知道自己在做什么，这一假设得到了苹果前员工的证实。 （我在 Mac 上不喜欢的事情之一。例如，对于 AppImage，应用程序和它所在的包之间没有区别。将图标拖到垃圾桶 = 就是这样。简单！）
论俳句，之间也有一个划分 apps/ и packages/，所以我怀疑这是否会让用户更清楚。 但是，如果您将应用程序从 apps/ 添加到购物车：
当您尝试删除从文件中获取的应用程序时会发生这种情况 .hpkg
从技术上讲，它是正确的（毕竟，应用程序首先托管在只读文件系统上），但它对用户来说并不是特别有用。
快速解决方案：建议使用GUI来删除
.hpkg
只是为了好玩，我尝试按 Alt+D 来复制应用程序。 我收到消息“无法移动或复制只读卷上的对象”。 而这一切都是因为 /system （除了 /system/packages и /system/settings) 是 packagefs 挂载点（记住它在输出中的显示方式 df？）。 不幸的是，该命令的输出 mount 没有澄清情况（正如之前的一篇文章所述）， mountvolume 不显示您正在寻找的内容（显然是通过循环安装的包 .hpkg 不被视为“卷”），而且我也忘记了替代命令。
除了 AppImage 之外，没有人在这个类别中获胜（但说实话，这是一个有偏见的观点）。 不过可以想象，经过调整后，Haiku 上的用户体验会比 Mac 上更好。
注意：您需要找出“卷”与“节”的关系。 这可能类似于“文件夹”与“目录”的关系：大多数目录在文件管理器中显示为文件夹，但并非全部目录（例如，将包视为文件）。 这种展示会让我成为正式的书呆子吗？
将包的内容复制到另一个系统
在 Mac 上，我傻乎乎的拖着包 .app，并且由于依赖项位于包内部，因此它们一起移动。
论俳句，我拖动应用程序，但依赖项根本没有处理。
快速解决方案：我们建议拖动整个 `.hpkg 包以及任何依赖项（如果有）。
Mac 显然在这一类别中获胜。 至少对我来说，这个范式的爱好者。 我应该把它复制到俳句 .hpkg 而不是应用程序，但系统没有为我提供这个......
下载包含所有依赖项的包
并非每台机器都始终连接到网络。 相反，有些机器（是的，我正在看你，现代 Windows、Mac 和 Linux）会忘记这一点。 对我来说，重要的是我可以去网吧，将软件下载到可移动驱动器上，将该驱动器插入我的家用计算机，并确保一切正常[有风险的家伙，在 Windows 上执行此操作... - 大约。 译者].
因此，我倾向于比平常更频繁地遇到对 Windows 和 Linux 的未满足的依赖关系。
在 Mac 上 这通常是一个文件，您所需要做的就是下载 .dmg。 大多数情况下，除了 MacOS 本身默认提供的依赖项之外，它没有任何依赖项。 一个例外是复杂的应用程序，需要适当的执行环境，例如 java。
论俳句 下载包 .hpkg 例如，对于 Java 中的相同应用程序，可能还不够，因为目标计算机上可能存在也可能不存在 Java。 有没有办法下载给定包的所有依赖项 .hpkg，除了俳句中默认安装的那些，因此应该在每个俳句系统上？
Mac 以微弱优势赢得了这一类别。
评论先生摇摇晃晃地飞溅：
编写一个程序来收集应用程序的所有依赖项作为一组包
.hpkg对于熟悉俳句内部运作的人来说，大约 15 分钟就足够了。 如果确实需要的话，添加对此的支持并不那么困难。 但对我来说，这是一种罕见的情况。
让我们屏住呼吸，等待本系列的下一篇文章。
将包移动到单独的位置
正如我之前写的，我想放置我的包裹 .hpkg （或者其中的一部分）到一个特殊的位置，与启动卷（根分区）上的通常位置分开。 在通常（不是那么理论上）的情况下，其原因是我的（内置）磁盘上的可用空间不断耗尽，无论它们有多大。 我通常连接应用程序所在的外部驱动器或网络共享。
在 Mac 上 我只是搬运包裹 .app 到 Finder 中的可移动驱动器或网络目录，仅此而已。 我仍然可以像平常一样从启动卷中双击打开应用程序。 只是！
论俳句，正如我被告知的，这可以通过移动我的 .hpkg 软件包到可移动驱动器或网络目录，但是您需要在控制台中使用一些未记录的命令才能将它们安装到系统上。 我不知道如何仅使用 GUI 来做到这一点。
Mac 在这一类别中获胜。
据先生说。 摇摇晃晃地飞溅：
这是在正常使用的基础上进行的优化。 如果有多个用户提出需求，我们将予以实施。 无论如何，都有第三方实施的可能性。
我们将在下一篇文章中讨论这个问题。
说到网络目录，如果有简单的、可发现的、网络范围内的应用程序（如 Zeroconf）可以复制到本地计算机或直接从本地网络运行，那就太好了（我猜是 LAN 方）。 当然，开发人员可以选择通过以下方式退出 app_flags.
关于 hpkg 系统与 GUI 集成的最终报告
我认为这主要是由于集成相对较新 .hpkg GUI 仍有很多不足之处。 无论如何，在用户体验方面有一些可以改进的地方......
还有一件事：内核调试之地
例如，如果能够在内核恐慌期间输入命令，那就太好了 syslog | grep usb。 嗯，在 Haiku 上，这要归功于 Kernel Debug Land。 如果一切都按预期运行而不陷入内核恐慌，您如何才能看到这种神奇的作用呢？ 按 Alt+PrintScn+D（调试助记符）即可轻松完成。 我立刻想起来 ，它允许最初的 Macintosh 开发人员进入调试器（当然，如果安装了的话）。
结论
我开始明白俳句系统的复杂性来自于这样一个事实：工作是由一个小团队进行的，他们明确关注工作环境，并且系统的所有层都可以访问。
与 Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu 的世界形成鲜明对比，其中一切都被分解成小块，以至于抽象依赖于抽象，拄着拐杖驱动。
也了解了系统如何 .hpkg 结合了传统包管理器、Snappy、Flatpak、AppImage，甚至 btrfs 的最佳实践，并将它们与 Mac 的“Just Works”方法相融合。
就好像我脑子里有什么东西“切换”了，我明白了系统是如何 .hpkg 只要看着她，就知道如何滚开。 但这不是我，而是系统的美丽和简单。 其中大部分灵感来自初代 Mac 的精神。
是的，在浏览器中浏览可能会很不稳定并且像蜗牛一样运行，可能会缺少应用程序（没有 Gtk、Electron - 开发人员得出的结论是它们与复杂性不相容），视频和 3d 加速可能完全不存在，但我还是喜欢这个系统。 毕竟这些事情是可以纠正的，迟早会出现。 这只是时间问题，也许会有点红眼。
我无法提供帮助，但我想从现在开始 桌面上的俳句年.
随机问题
也许已经有请求，或者我应该打开它们？
- BeScreenCapture 应该能够像 Peek 一样导出为 GIF。 这可以使用 ffmpeg 来完成，它已经可用于 Haiku。 .
- 屏幕截图软件无法捕获模态窗口，而是捕获整个屏幕
- 您无法使用 WonderBrush 的裁剪工具裁剪屏幕截图，然后将结果保存到文件中
- 我不太喜欢俳句中的手形光标，但我认为这与温暖的怀旧感觉有关。 在 Krita 中使用裁剪工具时，这尤其令人烦恼，因为它会导致裁剪不准确（请参阅本文中的模式对话框的屏幕截图）。 十字准线光标会很棒。 .
自己尝试一下吧！ 毕竟，Haiku 项目提供了从 DVD 或 USB 启动的映像，生成 。 要安装，只需下载映像并将其写入闪存驱动器
你有任何问题吗？ 我们邀请您参加俄语 .
错误概述：
从 翻译：这是俳句系列的第六篇文章。
文章列表：
来源： habr.com