PC-BSD PBI，是什麼原因導致它被廢棄？
PC-BSD 團隊面臨哪些詳細的具體技術/組織原因最終導致他們放棄 PBI 並返回埠？
是因為編譯和打包的困難嗎？是因為他們創建的硬連結有問題嗎？還是因為收集依賴項並一起編譯的工作量很大？
我很想知道為什麼創建軟體的同一個團隊（比如GNUCash）會花時間和精力為 Windows 提供一個獨立的版本，而將 *NIX 留給編譯器/安裝程序。
我不是在問為什麼埠和庫是好的（簡單的安全升級，……）。我也不是詢問軟體包與 Windows 的偏好或意見，只是導致廢棄 PBI 的技術原因。我特別問為什麼 PBI（0install，NixOS）的路線在技術上不可行或被廣泛採用。
PBI 文件格式在 PC-BSD 上停止使用的原因實際上有 3 個：
- 創建 PBI 格式是為了為 FreeBSD 提供一種打包格式（在pkg之前不存在“真正的”包系統- 只有埠集合）。
一旦pkg最終在 FreeBSD 本身中開發/實現（9.2/10.0？），幾乎沒有理由維持競爭格式，因為與輔助軟體包格式相比，更多人會為修復“官方”FreeBSD pkgs 做出貢獻。 2. PBI 文件格式是 PC-BSD 上使用者問題的第一大原因。
大多數 PC-BSD 使用者都是前 Linux 使用者，他們不理解自包含/受限應用程序範圍的概念 - 所以當應用程序“A”無法找到/啟動應用程序“B”時（因為“A”正在執行受限容器）他們假設應用程序/系統出現故障。這也是在所有各種基於 Linux 的應用程序都在穩步朝著與系統集成的方向發展（遠離獨立應用程序的概念）的時候，因此越來越多的應用程序根本無法在受限環境中執行。當我們決定從 PBI 切換到 pkg 時，FreeBSD 上只有大約 200 個應用程序可以在受限 PBI 容器中成功打包/執行，而通過切換到標準化pkg我們可以立即訪問 FreeBSD 上的所有 23000 多個軟體包。這也減少了開發人員的成本，因為整個 FreeBSD 社區將測試/修復應用程序，而不是讓（兩個）PC-BSD 開發人員也嘗試維護所有內容的單獨版本。 3. 技術問題
除了通用容器系統和由此施加的限制/限制之外，還有一些其他技術錯誤幫助我們放棄了整個文件格式：
- 載入時間
啟動 PBI 需要約 30-45 秒，而 pkg 需要約 2 秒。這主要是由於初始化容器和載入容器內的庫。
- 應用程序編譯
PBI 需要使用與正常情況不同的執行時前綴（應該支持哪些應用程序）進行編譯，但應用程序本身通常具有硬編碼的路徑/設置，這會阻止應用程序實際建構/正常執行。這也意味著當我們在建構應用程序時遇到問題時，我們永遠無法從應用程序開發人員或 FreeBSD 移植者那裡獲得任何支持，因為我們使用了不同的建構設置。
- 開發者維護
正如我之前提到的，PBI 系統的維護工作非常繁重。建構系統在建構應用程序時總是遇到奇怪的故障（由於執行時前綴的變化），然後當一個應用程序確實建構時，它必須由開發人員手動載入/測試以確保它真正啟動（擷取內置-在路徑問題中），然後還需要更新/維護應用程序的元資訊（我們現在仍然保留這些額外資訊 - 但將其視為對 pkg 系統的附加資訊覆蓋）。因此，這不僅需要兩個人進行大量的維護工作，而且最終應用程序本身只能勉強發揮作用，因為它們沒有像大多數 Linux 應用程序設計的那樣集成到基本系統環境中。
請注意，雖然 PBI 文件格式已從 PC-BSD 中刪除，但我們仍致力於應用程序劃分。相反，我們一直專注於使用預先存在的 FreeBSD 子系統（例如 jails 框架）來確保可靠/安全的執行時容器，而使用者安裝的“標準”應用程序將像在其他作業系統上一樣正常/可靠地執行。