GNU/Linux ，因為各種發行版本都可自由創立，軟體之間有各式各樣的套件與程式依賴。因此常常發生安裝新APP時，會因程式與所需的函式庫套件的依賴版本不同而無法安裝。或是升級APP時需要新的函式依賴A，而在某版本的OS中可以又要更新依賴B，或被迫更新部份OS的重要函式，甚至破壞程式依賴而導致整個OS損壞沒完沒了，一般稱為「Dependency Hell」。
安裝原生程式的方式
- 原生套件管理系統，例如APT、RPM
- 下載二進位執行檔直接執行
- 下載開發者提供的script，指令檔會自動下載並安裝程式
- 利用原始碼自行編譯安裝 make、make config、install
也因為不同 GNU/Linux 發行商有不同的原生套件管理系統，例如 Debian/Ubuntu 的 APT、Redhat 的 RPM，對開發團隊而言，還要開發不同套件系統的程式，非常累人。
AppImage
基於上述這些理由，AppImage 約在2004年左右發起，類似當年流行的 Portable App，不使用繁雜的安裝流程（尤其在Linux）,而是將所有程式與套件函式庫都包成一包，讓使用者可直接跑執行檔啟動App。沒有 Store 也沒有自動更新功能。
Snap
2014年由 Ubuntu 的維護公司 Canonical 所發行的獨立套件系統，希望解決不同發行版本的Linux都能安裝同一個軟體APP。與AppImage的概念一樣讓程式的安裝與更新不會修改到OS的函式依賴，並提供 Snap Store 讓使用者簡單安裝與更新App。
Flatpak
2016年左右的 xdg-app 專案轉變而來的獨立套件系統。與 Snap 相比基本上是一樣的東西。不同的是，Flatpak 是由社群開發維護，也有提供 Flathub Store 與自動更新功能。也因為社群自主維護，他們也可以推出自已的 App Store。
比較
細節部份不談，Snap與FlatPak基本上都是想解決 Dependency Hell 的問題，操作方式也差不同。個人的經驗來說，Flatpak 安裝的 App 啟動速度較快，與 OS 的整合性較好（例如輸入法、GTK畫面顯示等）。
因為不依賴 OS本身的共同函式，AppImage、 Snap與Flatpak 都是把所有依賴與函式庫包成一包，三者的缺點都是獨立 App 的檔案較肥大。
Comments