六個發行版，六種讓同一個程式裝不起來的方式

在 Linux 上散佈桌面應用，每次都會撞上同一道牆：相依性。同一個程式編譯一次，換到另一個發行版上可能就裝不起來，因為它期待的程式庫版本不在那裡，或者路徑的慣例不一樣。失敗的訊息通常沒什麼意思，就是一個版本號和一個找不到的名字，剩下的判斷留給使用者。

慣常的解法是為每個發行版各做一份套件，工作量隨目標數量成倍增加，而奇怪的組合仍然覆蓋不到。Flatpak 走的是另一條路。

把執行環境跟應用一起打包

它的做法是把應用連同它需要的執行環境一起打包，並且讓這個執行環境與底下的系統互相獨立。應用不再借用發行版的程式庫，而是自己帶一份。於是同一份套件，在彼此共同點很少的系統上，也能用同樣的方式安裝、用同樣的方式啟動。

這份獨立正是整個構想的核心，值得說清楚它換到了什麼。它並沒有讓應用變得抽象地可攜；它只是把執行環境變成一個固定的量，於是只需要對一件事，而不是對一整串系統套件。代價在另一邊：執行環境本身要散佈、要更新，佔用的空間與更新次數都比原生套件多。

應用與系統之間隔著一層沙箱

應用與系統之間隔著一層沙箱。預設情況下應用看不到整個檔案系統，也不直接握有裝置的存取權。當它需要讀寫某個目錄，或使用某個裝置，必須在權限裡明確宣告。

這個模型讓應用的行為邊界清楚一些，也讓使用者在安裝之前就能大致看出一個程式會碰到哪些資源。實務上這是小小的收穫，原則上卻是真的：從此「這東西會伸到哪裡」這個問題，不必只靠信任來回答。

1.18 把裝置權限切得更細

1.18 版為裝置權限加了更細的條件項。應用可以只申請它真正需要的那一類裝置，而不必把全部的門都打開。這個改動聽起來很小，其實不然：一次申請所有裝置，正是沙箱容易被當成裝飾的原因之一；把它收窄，宣告才有意義，而不是替安裝畫面加一行字。

這裡有一個通用的道理。一套權限制度會被人認真對待，前提是每一項請求都具體到足以判斷；如果一次就要走全部，使用者只會被訓練成不看內容直接按下去。

應用從哪裡來

最常見的來源是 Flathub，一個聚集了大量應用的中央倉庫。在命令列裡下一道安裝指令就夠，圖形介面的軟體中心通常也內建了它，所以同一份目錄從兩邊都走得到。

官方倉庫之外，也可以自行加入第三方倉庫。這件事值得一句警告，而不是一份說明：第三方倉庫不經過同樣的審核流程，加入之前應該先確認來源可信。1.18 版還支援直接從 OCI 映像安裝，並且改善了更新失敗時的提示訊息。後者只有在本來就出了問題時才有意義，而那正是它最有意義的時候。

其他幾種做法，差別在哪

有幾個專案在解同一類問題，只是重心不同。有一類把應用放進附帶審核流程的中央商店，覆蓋的發行版很多。有一類與單一發行版綁得很緊，帳號與更新機制都由那個平台提供。還有一類最簡單：一個檔案就能執行，但不帶集中更新，也沒有共同的目錄。

它們都不取代系統的套件管理，把這場比較讀成一場比賽是誤會。真正的差別是力氣放在哪裡：覆蓋範圍與審核、與某個平台的整合，或者把打包做到最少而把維護留給使用者。

比較穩妥的搭配

對多數桌面使用者，穩定的組合是把它當成補充渠道，系統層級的工具仍然走發行版的原生套件。發行版沒有收、或收得太慢的應用，從套件包來；會碰到系統本身的東西，留在系統期待的位置。

日常大致是三件事：安裝、更新，以及查看一個應用被授予了什麼。第三件最常被跳過，而它正是沙箱值得存在的理由。

Flatpak 的價值在於把「應用能在哪台機器上跑」從發行版的差異裡拆開，再用沙箱與權限讓安裝這件事可以被檢視。它不取代系統的套件管理，而是補上跨發行版散佈這塊短板。