撰文當下的Flatpak版本：1.14.4
「Flatpak，Linux應用程式的未來」Flatpak官方網站上如是說。
為何有時候Linux安裝應用程式是一大惡夢？為什麼Flatpak能有效舒緩這個問題？
這篇文章Ivon簡介為什麼會產生Flatpak，以及Flatpak技術的優缺點。
名詞解釋：
- 「系統程式」指的是編譯器、runtime、函式庫等軟體。
- 「圖形程式」指的是有圖形界面的文書軟體、影像處理、瀏覽器等軟體。
＊ 本文Ivon主要討論的是Flatpak技術的優缺點，關於Flatpak套件與指令的實際用法請看這篇。
1. Linux發行版的應用程式安裝問題#
先來談Flatpak的產生背景。
我們都知道Linux安裝應用程式，只要透過套件管理員(package manager)下載安裝即可，應用商店背後做的也就是這些事情。
Linux現在少說有100個以上的發行版(distribution)，這就造成了軟體打包問題。
不同的發行版有各種套件管理員，安裝應用程式指令都不一樣，有時候還會發生套件相依性(dependencies)衝突。
再者，各個發行版會維護自己的線上套件庫(repository)，受歡迎的發行版會收錄很多程式，比方說Ubuntu、Arch Linux AUR幾乎是什麼都有。相較之下，小眾發行版(Void、Alpine)要等社區成形後套件庫數量才會累積起來，不然就得手動從原始碼編譯了。
不同發行版打包會導致應用程式版本不一致，像新版本Ubuntu會收錄最新的程式，而LTS版則要稍後，造成更新不同步。
所以試圖統一跨發行版安裝應用程式的技術就出現了，Flatpak就是其中一個例子，其他的有Snap和AppImage。
2. Flatpak是什麼#
Flatpak，以前叫做xdg-app，是由RedHat發起的跨發行版套件管理員和套件部署系統。大部份Linux發行版 (Debian系、Fedora系、openSUSE系、Arch系) 都已經支援Flatpak，連ChromeOS都有，甚至Fedora Silverblue就是幾乎全Flatpak環境。
Flathub是最受歡迎的Flatpak套件庫，已經有數千款應用程式上架。
最近幾年Linux的 圖形 應用程式逐漸走向統一發行的趨勢，依賴Snap、Flatpak、AppImage這類跨發行版的技術，而非依賴各發行版套件管理員自行打包，防止程式版本不一的問題。
Flatpak主攻的對象為桌面圖形應用程式，例如瀏覽器、文書處理、影像處理、遊戲這類。Flatpak引入了沙盒(sandbox) 機制隔離APP，並設計了一套權限系統加強安全性。
3. 用Flatpak安裝應用程式的優點#
3.1. Flathub方便開發者部署發布#
Flathub對開發者有好處，Flatpak官方文檔有詳細說明如何將應用程式打包成Flatpak，並鼓勵開發者遵守XDG標準。開發者在分發應用程式時能提供穩定版和測試版給使用者下載，以及提供x86 / ARM等不同架構的版本，Flatpak的安裝程式會自動判斷。
通常使用者是從Flathub儲存庫下載Flatapk套件，有些組織會自行經營Flatpak儲存庫，例如RedhHat。Flathub跟Canonical的Snap Store不太一樣，它不是一間私人企業平台，而是由GNOME基金會經營的網站 (來源)，提交應用程式無需費用，可自由在Github提交Flatpak套件。使用者還可以自由更換Flatpak的遠端儲存庫，不需要遷就Flathub單一平台來下載應用程式。
Flathub網站會顯示應用程式下載量、AppStream的使用者評分、軟體授權條款、權限等資訊。應用程式下載頁面除了顯示大大的「捐贈」按鈕外，未來還可能推出付費管道。
對終端使用者而言，Flatpak解決了各發行版應用程式版本不一的問題。不管你是滾動更新的Arch Linux，還是萬年更新一次的Debian，都可以透過Flatpak享受到版本一致的應用程式。此外，Flatpak可以選擇將應用程式安裝到系統，或者只安裝給特定使用者，這樣可以讓一般使用者免root密碼安裝、刪除程式。
3.2. Runtime與系統隔離#
Flatpak會盡可能複用現有的runtime，減少空間佔用。所以Flatpak的應用程式裝的越多，空間佔用就越不是問題。依照開發者說法，裝越多Flatpak，空間利用就越有效率(efficient)。
Flatpak把runtime包一起有好處，它能確保每個應用程式都使用一樣的runtime，而不是依賴發行版的系統套件，防止發行版給runtime打patch導致出現奇怪bug。還有，Flatpak的舊版runtime就算EOL後照樣提供，緩解了依賴性地獄問題。
比方說某個應用程式需要依賴特定版本的Python，若用系統套件管理員安裝就會導致需要全域安裝Python，搞不好還會因為系統更新而壞掉。如果用Flatpak安裝的話，Python就是自動跟應用程式包在一起，跟系統的Python套件分開。
Flatpak甚至能讓依賴glibc的應用程式在musl libc的Linux發行版上執行，這就是不依賴系統套件的好處。
Flatpak跟Snap一樣有套件管理的功能，它們可以跟應用程式商店(KDE Discover、GNOME Software)整合在一起，用圖形化介面管理。而AppImage相對來說就難以管理，不使用AppImage Launcher的情況下使用者必須記住執行檔的存放位置。另外AppImage更大程度依賴系統底層的runtime，所以它也不是真的所有發行版都能用，像musl libc的系統就會有一堆AppImage開不起來，需要重新編譯；而Flatpak將runtime包在一起的做法解決了這個問題。
3.3. 沙盒提高安全性#
下圖是Flatpak官方文檔所描述的沙盒運作原理，Flatpak應用程式的依賴套件和runtime是由Flatpak控管，安裝應用程式時會自動下載。
從安全角度來看，Flatpak引入的權限機制跟Android有類似之處。Google近來年規定Android APP只能存取部份常用目錄，保證系統安全與整潔。用Flatpak安裝的應用程式也有這類效果，防止應用程式在家目錄亂塞一堆設定檔。Flatpak可以限制應用程式存取網路服務和特定硬體設備。
理想情況下，開發者在打包為Flatpak程式的時候，應善用Flatpak提供的一套Portal API來存取使用者檔案。
部份Linux的應用商店會在安裝頁面列出該Flatpak APP會用到的權限，圖為KDE Discover列出的Firefox權限。
Flatseal可用於編輯Flatpak程式的權限，免打指令。
最後，Flatpak安裝的程式資料統一放在~/var/app，這樣透過Flatpak解除安裝程式時，能把相關應用程式資料一鍵刪除。
我們能夠透過Flatseal這類程式來開關應用程式的權限，在必要的時候允許應用程式存取使用者全部的檔案。
4. 用Flatpak安裝應用程式的缺點#
4.1. 應用程式肥大#
Flatpak應用程式很肥，尤其是不常使用Flatpak安裝應用程式的情況下。安裝Flatpak等同裝了第二個套件管理員，所以要另外下載依賴套件。
舉例來說，在新安裝的Linux系統上，用Flatpak下載Firefox瀏覽器，還需要500MB空間安裝Nvidia、GNOME等依賴。但若透過系統本身的套件管理員可能不到200MB而已。
多使用Flatpak來安裝應用程式，這個問題就不會那麼嚴重。Flatpak軟體之間有部份runtime是共享的，不會每裝一個程式就要全部重新安裝一堆依賴。設定每日自動更新Flatpak也是個解法，避免久久一次更新導致要下載一大堆依賴。此外Flatpak支援增量更新。
4.2. 沙盒權限設計不當#
Flathub的程式並非都是原作者上架的，有些是非官方打包，導致有些應用程式版本陳舊或是有奇怪bug。
部份Flatpak程式打包後的沙盒權限設計不當，導致無法正常存取檔案、找不到系統執行檔，或是無法跟桌面主題整合。還有亂丟設定檔的問題，某些Flatpak程式還是會因為各種因素把資料放在~/.var/app以外的地方，不遵守XDG規範。
目前Flatpak調整權限的方式很容易讓使用者困惑，誰想知道這些bus是幹嘛的呀？搭個公車有那麼難嗎？
若開發者願意放點心思在Flatpak版的程式上，就應該像Android加入「權限請求」對話框，讓使用者能更明白權限的用處。
就安全性而言，Flatpak其實不是最安全的解決方案。Flatpak的沙盒並非完全與系統隔離。考量Flatpak權限限制，Firefox、GIMP這類程式不得不請求存取使用者家目錄的全部檔案，不然file picker根本無法選取檔案。還有Visual Studio Code、QT Creator一定得存取系統執行檔，不然無法編譯程式。
若要更安全的沙盒執行環境，Docker、chroot、虛擬機的方案可能會是更好選擇。
但有安全機制總比沒有好，至少Flatpak程式看不到彼此之間的資料目錄。
如果未來程式開發者願意以Flatpak的Portal API為優先開發考量，那就能進一步強化安全性。
4.3. 與系統整合的問題#
部份Flatapk程式不遵守桌面環境的主題，導致QT程式在GNOME看起來很詭異；反之GTK程式在KDE也是一樣。使用者得手動設定環境變數才能套用主題，很是麻煩。
Flatpak執行程式指令會變很長，過去在終端機打firefox就會開啟；而Flatpak變成要打flatpak run org.mozilla.firefox才行。
還有Flatpak不會把程式加到環境變數(PATH)，因此若用一般套件管理員的方式執行firefox指令，系統是找不到Flatpak版Firefox的，得另外將/var/lib/flatpak/exports/bin加到PATH，並設定alias才能暫時解決。
最後是系統程式與伺服器應用。上面說了，Flatpak主攻的是圖形應用程式，系統程式方面的就比較少見，雖然有Fcitx5輸入法和ffmpeg，但目前還沒聽過有人用Flatpak裝Java和PHP的。這樣導致在伺服器方面Flatpak沒什麼優勢，相較之下Canonical力推的Snap還做的比較完善。
雖然Flatpak使用了一些容器化的技術，但它畢竟不是Docker或Podman，不適合用來跑headless的伺服器服務。
Flatpak困境在於其設計本身不能變更系統設定，說白了就是不能有sudo權限去動系統檔案。跳出沙盒在宿主機執行flatpak-spawn指令能作到的也有限。這導致部分軟體從技術上來說就不可能有Flatpak版，例如遠端桌面伺服器和虛擬機軟體這類的。
Flatpak適合安裝的應用程式主要為桌面程式，還有Steam這類不需要動到系統設定的應用程式。
5. 總結#
Flatpak對開發者的好處是顯而易見的，對使用者來說亦是簡化了APP安裝程序。不過容量和沙盒問題仍要看未來Linux社群會怎樣改進。
若跟應用程式商店前端整合好的話，應該可以改善使用者安裝程式的體驗。