依賴地獄：為什麼不創建可移植的應用程序
回到我使用 Windows 的時代，應用程序以獨立的方式安裝。這給最終使用者/系統管理員留下了很大的自由來決定升級什麼和在哪裡升級，修補什麼以及何時不干擾其他應用程序。
在 *NIX 中，糾纏的依賴關係令人頭疼。PC-BSD 試圖用PBI克服這個問題，方法是創建自包含的應用程序。AFAIK，這似乎現在已被棄用，它們返回到包管理方式（PBI 現在是埠的包裝器），並且所有 Linux 發行版都朝著相同的方向執行：到最後，數百個依賴項，甚至桌面環境也有望依賴關於系統管理守護程序。
基於數百個依賴項建構應用程序使程序員的生活更輕鬆，但給最終使用者和系統管理員帶來了令人震驚的問題。例如，我不能再讓一個古老的 Debian Etch 版本的應用程序在 Debian Jessie 中執行。我知道很多人會帶著安全、更新檔和最新系統的故事而來，但開源意味著自由決定更新什麼、何時何地更新。有非常正當的理由不更新系統或系統的一部分，或者至少不按照典型 *NIX 包管理器引導使用者的方式進行更新（即離線工作的機器、舊硬體、與需要更新的舊數據的兼容性）為合規而保留，…）。其他時候，系統管理員更喜歡通過幾個步驟來確保安全。
就個人而言，我認為我作為系統管理員應該決定更新什麼，何時更新，並承擔風險。以目前的情況，這是不可能的。（即在 Debian 中有一個新版本的 libc6，它到處都有依賴項）。如果我決定保留兩個或更多儲存庫來解決問題，我會產生另一個噩夢。
我知道某些依賴項（即安裝了 MySQL）是可以接受的，因為這是一個主要依賴項，但我不明白為什麼像庫這樣的微小依賴項不簡單地嵌入到程式碼中。磁碟便宜。許多移植到 Windows 的 Linux 應用程序實現了這一點。
編輯：確保它不僅僅是基於意見
在 *NIX 中安裝軟體的選項有哪些（為簡單起見，我們將其稱為 Debian/FreeBSD），以便：
- 保持軟體的單個特定版本執行多年而不升級，並確保無論後續的基本作業系統和庫升級如何，都可以保持不變，ala apt-get hold但永遠。
- 在不與其他軟體/庫發生衝突的情況下決定升級/降級。
- 安裝該軟體的兩個或多個版本。
Jails/chroot/VM 不是選項，儘管它們是明顯的變通方法。還，
- 是什麼讓 PBI 無法實現回歸埠/包管理的獨立性目標？
我無法回答為什麼 PBI 不成功，但我可以回答為什麼在 Linux 中首選共享庫。
主要論點是安全性，如果常用庫中存在漏洞，則只需更新該庫，而不是使用該庫的所有應用程序（由於 ABI 兼容性）。這也意味著（如果您主要使用主要 repos 和 PPA（在 Ubuntu 的情況下）），您不必安裝 4 個不同版本的庫，因為您的應用程序是針對這些版本編譯的（例如 Windows ，您可能會安裝不同版本的 .NET 庫，或安裝不同版本的 Visual C++ 執行時）。
話雖如此，但在某些情況下，應用程序可能不會被迫使用庫的系統版本，而是可以使用它們自己的版本。例如，Chromium 依賴於大多數發行版的儲存庫中存在的許多庫。在正常情況下，應用程序將被編譯，以便它們使用的庫是發行版編譯的庫。但是，在 Ubuntu 中（至少），Chromium 是用它自己的庫版本編譯的，因為：
- 使用庫的系統版本意味著 Chromium 必須針對每個版本的 Ubuntu 進行測試。
- Chromium 在很大程度上已經使用了最新版本的庫，這意味著存在漏洞的可能性要低得多。
至於磁碟空間參數，您可能會爭辯說安裝
debootstrap‘ed 版本的 Debian Jessie 需要不到 1 GB 的磁碟空間，這對於較小的 SD 卡來說非常有用。另一方面，Windows至少需要幾 GB 的磁碟空間。對於較舊的軟體，您可以靜態編譯應用程序並讓大部分依賴項自包含。但是，由於您的發行版可能沒有可用的靜態庫版本（Debian 和 Ubuntu 大部分情況下沒有），因此您需要自己編譯這些庫以獲取這些庫的靜態版本。
最後，Unix 的原則之一是每個應用程序只做一件事，並且擅長它。如果應用程序和庫是靜態連結的，那麼它們可能被認為是（間接地）做很多事情。