TL博士答：Haiku 是專為 PC 設計的操作系統，因此它有一些技巧可以使其成為比其他操作系統更好的桌面環境。 但是它是如何工作的呢？
我發現了 Haiku，一個出乎意料的好系統。 我仍然對它運行的流暢程度感到驚訝，尤其是與 Linux 桌面環境相比時。 今天我要深入了解一下。 在需要深入理解的地方，我將與原始的 Macintosh、Mac OS X 和 Linux 桌面（來自 freedesktop.org 的 XDG 標準）進行比較。
ELF 文件中的資源
昨天了解到IconOMatic可以在ELF可執行文件中存儲rdef資源中的圖標。 今天我想看看它是如何工作的。
資源？ 從 ，Macintosh Finder 的原作者和 Macintosh Resource Manager 之父：
我擔心傳統編碼的僵化性質。 對我來說，將應用程序凍結在代碼中，無法動態更改任何內容的想法是最瘋狂的想法。 應該可以在運行時盡可能多地更改。 當然，應用程序代碼本身是不能改變的，但是不重新編譯代碼就可以改變一些東西嗎？
最初的 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，Haiku 基於它。 它的開發人員在從 PEF (PowerPC) 遷移到 ELF (x86)（與 Linux 上使用的相同）時，決定在 ELF 文件的末尾添加一個資源部分。 這並沒有使用它自己正確的 ELF 部分，它只是被添加到 ELF 文件的末尾。 作為節目的結果 strip binutils 中的其他不知道它的人只是將其切斷。 因此，在 BeOS 上為 ELF 文件添加資源後，最好不要使用 Linux 工具對其進行操作。
Haiku現在發生了什麼？ 基本上，或多或少是一樣的。
理論上，可以將資源放在 ELF 的所需部分。 根據 irc.freenode.net 上#haiku 頻道的開發人員的說法：
有了 ELF，該部分會更有意義……我們不這樣做的唯一原因是我們在 BeOS 中這樣做了。”
而且現在不需要改變。
資源管理
資源以結構化的“資源”格式編寫：實際上，這是一個資源列表，先是大小，然後是內容。 記得 .
如何查看 Haiku 中的資源？ 有沒有類似 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，它強制系統一次只啟動一個進程，無論用戶啟動它的頻率如何（例如，這就是 Linux 上的 Firefox 啟動的方式；在 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。 系統顯示的圖標（在 Tracker 和 Deskbar 中）是從這個擴展屬性中讀取的，因為這個解決方案很快。 在某些地方（速度不重要，例如典型的“關於”窗口），系統直接從文件中的資源接收圖標。 但這還沒有結束。 請記住，在 Mac 上，用戶可以用自己的圖標替換應用程序、文件夾、文檔的圖標，因為在 Mac 上可以做這些“重要”的事情，例如 . 在 Haiku 上，將資源（在文件中）視為應用程序附帶的原始圖標，將屬性（在 BFS 文件系統中）視為允許用戶隨意進行更改的東西（儘管提示，用於在圖標頂部插入自定義圖標是可選的）。默認情況下尚未實現）。
檢查文件系統屬性
同 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 安裝一部分的包依賴項（例如，我有一台物理隔離的機器，無法訪問 Internet。）
- 我想將我的包（嗯，其中的一部分）單獨移動到另一個地方，與引導卷（根分區）分開（因為，例如，我沒有足夠的空間）。
這應該涵蓋了我日常工作中的大部分主要案例。 好吧，讓我們開始吧。
檢查包裝內容
在 Mac 上 我只需右鍵單擊某個包即可將其打開並在 Finder 中查看內容。 它真的只是一個變相的目錄！ （我知道有包裹 .pkg 對於系統的一部分不是應用程序，但普通用戶通常不與它們交互）。
論俳句 我右鍵單擊包，然後單擊“內容”以查看裡面的內容。 但它只是一個文件列表，無法雙擊打開它們。
如果有辦法（臨時）掛載一個包就更好了 .hpkg 通過文件管理器查看，用戶不必擔心實現細節。 （順便說一句，你可以打開 .hpkg 包裝在 Expander，它可以像任何其他存檔一樣解壓縮它）。
在HaikuDepot界面可以查看包文件列表，但是沒有辦法查看內容，比如雙擊README.md
在這個類別中，Mac 勝出，但向 HaikuDepot 添加正確的功能應該不是什麼大問題。
通過 GUI 安裝包
在 Mac 上, 大多數磁盤映像 .dmg 包含包 .app. 雙擊打開磁盤映像，然後復制軟件包，例如將其拖到 /Applications 在訪達中。 對我來說這是不言而喻的，但我聽說有些初學者可能無法掌握這一點。 默認情況下，Apple“建議”一個系統範圍的目錄 /Applications （在 NeXT 上它既是聯網的又是獨立的），但是您可以輕鬆地將您的應用程序放在文件服務器或子目錄中 $HOME/Applications如果你非常喜歡它。
論俳句，雙擊包，然後點擊“安裝”，再簡單不過了。 我想知道如果一個包在 HaikuPorts 中有可用的依賴項，但尚未安裝，會發生什麼情況。 在 Linux 上，他們真的不知道在這種情況下該怎麼做，但解決方案很明顯——詢問用戶是否需要下載和安裝依賴項。 正是 Haiku 所做的。
我手動下載了“sanity”包並單擊它，包管理器知道從哪裡獲取它的依賴項（假設存儲庫已經在系統上）。 並非每個 Linux 發行版都能做到這一點。
另一種方法是使用文件管理器，只需拖放即可 .hpkg 包或在 /Haiku/system/packages （對於系統範圍的安裝，默認情況下），或者在 /Haiku/home/config/packages （對於個人設置；雙擊不可用 - 我仍然對這個地方的“配置”這個詞感到惱火，在這種情況下對我來說它是“設置”的同義詞）。 而且 Haiku 甚至還沒有多用戶的概念（也許這就是它如此簡單的原因——我不知道，也許多用戶功能會使桌面桌面環境不必要地複雜化）。
在這個類別中，Haiku 獲勝，因為它不僅可以與應用程序一起工作，還可以與系統程序一起工作。
從 GUI 中刪除包
在 Mac 上，您需要將應用程序圖標拖到垃圾桶，僅此而已。 容易地！
論俳句，首先，您需要找到軟件包在系統中的位置，因為您很少將其安裝在正確的位置（系統會做所有事情）。 通常你需要尋找 /Haiku/system/packages （在系統範圍的默認安裝中），或在 /Haiku/home/config/packages （我有沒有提到“config”是錯誤的名字？）。 然後應用程序被簡單地拖到垃圾桶，就是這樣。
容易地！ 但是，我不會這麼說。 這是真正發生的事情：
當您將應用程序從 /Haiku/system/packages
剛剛嘗試將我昨天在 QtQuickApp 上的“Hello world”應用移到垃圾箱。 我沒有嘗試移動系統目錄， 並且由於所有包都安裝在系統目錄中 - 無法刪除包 .hpkg 沒有變化 “它的內容”. 普通用戶會害怕，會按默認分配的“取消”按鈕。
解釋 :
這篇文章已有 10 多年曆史了。 最有可能的是，我們需要對其進行配置，以便僅在移動包本身時才會發出警告。 普通用戶無論如何都不需要這樣做。
好吧，也許你應該使用 HaikuDepot 來做？ 雙擊包 /Haiku/system/packages，等待“卸載”按鈕出現。 不，有（只有）“安裝”。 卸載，你在哪裡？
為了好玩，我試著看看如果我在一個已經安裝的包上單擊“安裝”會發生什麼。 結果是這樣的：
如果您嘗試安裝已安裝的軟件包，就會發生這種情況。
接下來出現：
如果在上一個窗口中點擊“Apply changes”，結果會是這樣
我假設這是一個軟件錯誤，應用程序的鏈接已經存在。 [作者沒有提供鏈接，-大約。 譯者]
快速修復：如果包已經存在，添加一個“卸載”按鈕
/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除了 Haiku 中默認安裝的那些之外，因此應該在每個 Haiku 系統上？
在這一類別中，Mac 以微弱優勢獲勝。
先生評論搖搖欲墜：
編寫程序以將應用程序的所有依賴項收集為一組包
.hpkg對於熟悉 Haiku 內部結構的人來說，大約 15 分鐘就足夠了。 如果確實需要，添加對此的支持並不難。 但對我來說，這很少見。
讓我們屏住呼吸，等待本系列的下一篇文章。
將包移動到單獨的位置
正如我之前寫的，我想把我的包裹 .hpkg （好吧，或者其中的一部分）到一個特殊的地方，與引導卷（根分區）上的通常放置分開。 在通常（不是那麼理論上）的情況下，原因是我的（內置）驅動器不斷用完可用空間，無論它們有多大。 我通常將外部驅動器或網絡共享映射到我的應用程序所在的位置。
在 Mac 上 我只是搬運包裹 .app 到 Finder 中的可移動驅動器或網絡目錄，僅此而已。 我仍然可以像往常一樣從啟動卷雙擊打開應用程序。 只是！
論俳句，正如我被告知的那樣，這可以通過移動我的 .hpkg 包到可移動驅動器或網絡目錄，但隨後您需要在控制台中使用一些未記錄的命令才能將它們安裝到系統上。 我不知道如何僅使用 GUI 來完成。
Mac 贏得了這一類別。
據先生說搖搖欲墜：
這是基於正常使用的優化。 如果有不止一個用戶的需求，我們會去實現。 在任何情況下，都存在第三方實施的可能性。
我們將在下一篇文章中討論這個問題。
說到網絡目錄：如果有簡單的、可發現的、網絡範圍的應用程序（例如通過 Zeroconf）可以復製到本地計算機或直接從本地網絡運行，那將是很棒的（我猜是 LAN 方）。 當然，開發人員可以選擇通過 app_flags.
關於 hpkg 系統與 GUI 集成的最終報告
我認為這主要是因為集成相對新穎 .hpkg 使用 GUI 仍然有很多不足之處。 無論如何，在用戶體驗方面有一些可以改進的地方......
還有一件事：Kernel Debug Land
能夠在內核恐慌期間輸入命令會很棒，例如 syslog | grep usb. 好吧，在 Haiku 上，這要歸功於 Kernel Debug Land。 如果一切正常而不陷入內核恐慌，你怎麼能看到這個魔法在起作用呢？ 按 Alt+PrintScn+D（調試助記符）即可輕鬆實現。 我立刻想起來 ，它允許原始 Macintosh 開發人員進入調試器（當然，如果安裝的話）。
結論
我開始意識到 Haiku 系統的複雜性來自於這樣一個事實，即工作是由一個明確關注工作環境的小團隊完成的，並且可以訪問系統的所有層。
與 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。 這可以使用 Haiku 可用的 ffmpeg 來完成。 .
- 屏幕截圖工具無法截取模態窗口的屏幕截圖，而是捕獲整個屏幕
- 您不能使用 WonderBrush 的裁剪工具裁剪屏幕截圖，然後將結果保存到文件中
- 我不是特別喜歡 Haiku 中的手形光標，但我認為它有一種溫暖的懷舊感覺。 這在 Krita 中使用裁剪工具時尤其煩人，因為它會導致裁剪不准確（請參閱本文中模態對話框的屏幕截圖）。 十字準線光標會很棒。 .
自己試試吧！ 畢竟，Haiku 項目提供了從 DVD 或 USB 啟動的映像，生成 . 要安裝，只需下載映像並將其刻錄到 USB 閃存驅動器，使用
有問題嗎？ 我們邀請您到講俄語的 .
錯誤概述：
從 翻譯：這是俳句系列的第六篇文章。
文章列表：
來源： www.habr.com