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 安裝相同的方式進行更新和處理......我們需要集思廣益）。
引自先生。 搖搖晃晃地飛濺：
從外部磁碟機或網路目錄執行應用程式可能很有用。 添加為 pacman 配置更多“區域”的功能絕對是一個不錯的功能。
這樣的系統將利用 hpkg、目錄和應用程式映像。 他們各自都很好，但團結起來就會所向無敵。
結論
Haiku 擁有一個為 PC 提供簡單而複雜的使用者體驗的框架，並且遠遠超出了通常為 Linux PC 提供的體驗。 封裝系統 .hpkg 就是這樣一個例子，但係統的其餘部分也充滿了複雜性。 然而，Haiku 將受益於適當的目錄和應用程式影像支援。 如何最好地做到這一點值得與比我更了解俳句、其哲學和架構的人討論。 畢竟，我使用俳句已經一個多星期了。 儘管如此，我相信 Haiku 的設計師、開發人員和建築師將從這種新鮮的視角中受益。 至少，我很樂意成為他們的「陪練」。 我在 Linux 應用程式目錄和套裝組合方面擁有超過 10 年的實務經驗，我希望在 Haiku 中找到它們的用途，我認為它們是完美的選擇。 我提出的潛在解決方案絕不是針對我所描述的問題唯一正確的解決方案，如果 Haiku 團隊決定尋找其他更優雅的解決方案，我完全支持。 基本上我已經在想如何做一個系統的想法了 hpkg 在不改變其工作方式的情況下甚至更令人驚奇。 事實證明，Haiku 團隊在實現套件管理系統時很長一段時間以來一直在考慮應用程式包，但不幸的是（我認為）這個想法變得「過時」了。 也許是時候復興它了？
自己試試吧！ 畢竟，Haiku 項目提供了從 DVD 或 USB 啟動的映像，生成 .
有問題嗎？ 我們邀請您到講俄語的 .
錯誤概述：
從 翻譯：這是俳句系列中的第八篇也是最後一篇文章。
文章列表：
只有註冊用戶才能參與調查。 ， 請。
將hpkg系統移植到Linux有意義嗎？
-
Да
-
沒有
-
已經實現了，我會寫在評論裡
20 位用戶投票。 5 名用戶棄權。
來源： www.habr.com