本文主要是討論Snap軟體的優缺點，包含技術細節與爭議。關於Snap指令的用法請參閱 這篇。
Canocial公司在2014年推出的「Snap」套件管理系統，經過多年發展後，現在已經是旗下Ubuntu系統家族的一部分了。Snap現正逐步推廣到其他Linux發行版。
但是，Linux社群卻有很多用戶不喜歡Snap
Snap已經變成一種梗了。
當提到跨發行版的解決方案時，會有人吐槽用Snap還不如用Flatpak或Nix之類的解決方案。AskUbuntu上的用戶還提供了強制停用Snap套件的方法。
這讓人不禁懷疑，Ubuntu推動的Snap真的有那麼壞嗎？讓我們一瞧Snap運作原理，了解Snap優點和缺點，並讓讀者思考為何Snap會惹人嫌？
本篇文章中會不時將Snap與 Flatpak技術做比較，因為二者都是面向桌面用戶、軟體數量逐漸增加中的軟體安裝方案。
1. Snap軟體簡介#
Snap軟體是Canonical為了解決跨Linux發行版軟體安裝問題而出現，用Snap裝軟體有什麼優點？考慮以下情況：Ubuntu系統使用APT安裝deb套件，方便使用者取得各式各樣的軟體。但是Ubuntu和Ubuntu LTS套件是不同步的，LTS的套件雖然穩定但比較舊，這會給軟體維護造成困擾，使用LTS系統的使用者可能收不到最新版軟體，導致程式執行出bug。
還有維護困難的問題，每個Ubuntu版本都要經營一個專門的deb套件庫。從Ubuntu的發行週期可以想像開發者需要花多少心力維護套件！Ubuntu出了新版後還要維護舊版系統的套件。
雖然Ubuntu支援手動抓deb來裝，可萬一該deb依賴新版本的套件呢？這會造成套件衝突，如果再找更多deb滿足依賴，就可能會在未來apt update時出現更多衝突，導致依賴性地獄(dependency hell)發生。
為解決這個問題，Snap提供了一種全新的打包方法，保證任何版本的Ubuntu都可安裝一致的軟體版本，又不會讓套件互相干擾。甚至在舊版本Ubuntu也可以用Snap安裝最新版軟體，而不至於弄壞套件依賴。
簡單來說，軟體開發者只需要維護一個版本，便可以讓不同Ubuntu版本的使用者受惠。有了Snap就不用找PPA裝deb了。
Canonical在
官網宣稱Snap優點是「可靠」、「模組化」、「穩健性」、「最佳化」的解決方案。
在Snapcraft網站首頁，Canonical找了一些開發者來站台，比如Microsoft就大力稱讚Snap是一個很棒的平台，讓他們可以發表Linux版的.Net套件。（題外話，Canonical之前幫忙Microsoft開發過WSL呢，使得Ubuntu成為WSL的預設系統）
Canonical也一直盡力使Snap能在其他Linux發行版上運作，而非Ubuntu專屬的東西。當使用者造訪Snap Store的時候，會看到貼心的安裝引導指示。
Snap看起來很棒，那為什麼會有一堆爭議呢？下面慢慢揭曉。
在討論Snap前，必須先知道安裝Snap軟體要依賴以下項目：
- Snap：套件打包格式，附檔名為
.snap。 - SnapCraft：Snap打包程式，同時也是匯集Snap資訊的網站。
- Snapd：管理Snap套件的常駐程式，需要systemd、AppArmror、cgroups才能運作。
- Snap Store：收錄Snap軟體的商店，提供網頁及桌面版應用程式。桌面版本身也是一個Snap軟體。
這裡帶出Snap的第一個侷限，因為Snapd依賴Systemd，所以無法安裝在採用其他init系統的Linux發行版，例如Artix、Void Linux、Alpine Linux、Gentoo (OpenRC profile)等等。
還有Snap需要AppArmor才可以強化安全性，但不是每個發行版都有使用這個核心模組的說。
因此，Snap支援度不如Flatpak廣，後者只要求Linux核心支援cgroups就能裝。
2. Snap的軟體安裝管道#
不論是Snap Store還是Flathub，軟體版本都很接近上游，例如二個平台都可以取得最新版GIMP。因此除非軟體是非官方打包，否則這二個平台提供的軟體都不會有deb套件庫版本太舊的問題。
目前Snap軟體安裝管道都來自Canonical經營的「Snap Store」，方便Canonical維護版本一致的軟體。
Flatpak用戶多半從GNOME基金會經營的Flathub下載軟體，部份開發者有自行經營Flatpak軟體庫，例如Redhat、KDE、Fcitx5、elementaryOS的開發者都有自己的軟體庫。
相較於Flatpak使用者可以自由增加軟體庫，Snap比較偏中心化的設計，Snap Store是目前唯一的「官方Snap軟體庫」，上架軟體需要註冊 Ubuntu One帳號。
開發者可以在Snap Store提供穩定和測試的更新頻道，讓使用者選擇要下載什麼版本的軟體。除此之外，Snap Store還會統計使用者下載次數和系統資訊，方便開發者追蹤軟體的使用情況。
Snap Store跟Flathub一樣，無法保證上架的軟體都是開源軟體，且有混入惡意軟體的紀錄，比方說Snap Store 曾有2048遊戲暗藏挖礦程式。為此Canonical宣佈會給上架的軟體進行自動化測試，並創立認證開發者計畫(名字旁邊顯示綠勾勾)，盡量排除惡意軟體。
網友批評Snap Store後端伺服器並非開源，完全由Ubuntu掌控，上架軟體還要註冊Ubuntu One帳號。Snap已經出來10年了，基本上只有Snap Store一個管道可以取得Snap軟體；即使有開發者提供「.snap」套件，也得連線到Snap Store下載其依賴套件。
還有Snap早期是會自動下載更新的，無法關掉，這不禁讓人想到Windows 10惱人的自動更新…幸好Snap現在有指令可以關掉自動更新了。
Snap中心化固然是其優點，讓Canonical可以達成維護一致版本軟體的目的，但也讓使用者逐漸被Ubuntu的生態系綁架，變成一大缺點。
3. Snap軟體結構：可以是桌面軟體也可以是系統軟體#
Snap打包使用SquashFS，把軟體的依賴套件都包在一起，成為Snap，這樣每個軟體就不需要互相依賴。
這樣做的負面後果就是每個Snap套件都比deb版還肥，因為他們得把自身需要的runtime包在一塊。
在安裝Snap軟體後，Snapd會將Snap變成一個個loop device，掛載在系統上。
掛載點資訊能用lsblk指令查看，看了唉呦不得了，Snap會在系統上建立一堆loop device，有人不喜歡自己的磁碟結構變那麼複雜嘛。
相較於Flatpak直接把下載的程式檔案統一放到~/.var目錄下，Snap的作法實在太特別了。
來比較速度，根據
TechHut的測試，Flatpak和Snap程式執行速度是差不多的。
但因為SquashFS的機制，使得部份Snap應用程式「啟動」速度很慢。從
Linovox的測試報告可以看到，Flatpak啟動程式多半比Snap快，AppImage和原生套件管理器又更快。
此外，Snap的應用程式一更新後就必須重新啟動才能套用變更，Flatpak則可以在應用程式運作時無縫安裝新版本。
如果一個程式同時提供Snap和Flatpak版，那為何不裝Flatpak版就好？
不過，Snap相較於Flatpak有一個優勢：系統軟體。跟Flatpak主打桌面應用程式不同，Snap提供名為 daemon的界面，因此伺服器的系統程式、桌面環境、Linux核心都可以打包成Snap格式，像普通套件一樣安裝。
比方說
Snap版Nextcloud只需要一個套件，安裝後就能直接啟動了。
Snap還提供管理行程的指令，讓Snap軟體能當成系統服務執行。
為了方便備份資料，Snap支援製作完整Snap環境的快照並隨時還原。
從這點來看，Snap的守備範圍比Flatpak多了一些，它提供系統軟體、行程管理、資料備份服務，超越了Flatpak以桌面為主的使用場景，變成可以跟Docker競爭的解決方案。
4. Snap的權限機制#
權限機制是Snap的賣點之一，將應用程式沙盒化，Canonical宣稱這樣可以讓系統更安全。
Flatpak使用bubblewrap和Portal API實現權限功能。Snap則是仰賴AppArmor，限制應用程式對系統資源的存取，稱為 限制confinement。
每個Snap軟體都有
插頭Plug和插槽Slot，插槽可以接受多個插頭「連線」。Snap彼此之間是使用
界面Interfaces連接。
Snap軟體預設有沙盒隔離的作用，程式資料和設定檔都是隔離存放在~/snap，不會往使用者家目錄倒。
使用者可以在軟體商店的管理界面，控制軟體的存取權限，像是允許存取使用者家目錄、使用網路連線等權限。或是用snap connections指令控管Snap界面的連線情況。
Snap的confinement依賴AppArmor實現，當AppArmor啟用的時候，Snap啟用strict mode模式。在strict mode下，Snap軟體無法任意存取系統資源，需要透過界面存取。
然而，如果系統沒有AppArmor，則Snap會以classic mode執行，以上權限系統全部失效。Snap軟體將跟deb軟體一樣，擁有存取任意系統檔案的權限。（不要跟devmode搞混，這是Snap方便軟體開發者測試用的模式）
因此，Snap最適合在Ubunbu、Debian、Manjaro、openSUSE使用；Fedora因為使用SELinux，管控Snap權限能力較差；Arch和Gentoo要手動設定AppArmor，可能有些用戶會覺得麻煩。
5. Snap是Linux未來？Canonical強推引不滿#
早期Canonical在嵌入式Ubuntu Core率先應用Snap技術，當年要出Ubuntu touch手機的時候也裝載了Snap。
後來Canonical才把Snap拓展到桌面版上，Ubuntu 16.04以後的系統基本上都有預裝Snap了。
但裝了沒人用怎辦？Ubuntu在22.04以後，會自動把apt install指令重新導向到Snap版本。比方說安裝Firefox，會自動把apt install firefox轉換成snap install firefox。如果你硬要禁止APT安裝Snapd，套件依賴還會崩掉。
不少人認為Ubuntu強制推動Snap是個錯誤。
2022年後，Ubuntu官方flavor都預裝了Snap，包含Kubuntu、Lubuntu、Xubuntu。有 報導稱，未來Ubuntu可能會逐步把自家系統全面Snap化。
但是基於Ubnutu開發的發行版，例如Linux Mint、ZorinOS、elementaryOS、KDE neon，由於他們並非Canonical直接控制的組織，有些發行版選擇不內建Snap。
Linux Mint 20甚至 禁止APT自動安裝Snap，他們認為Snap會導致開發者不願意釋出其他打包格式的軟體，長久以來對Linux社群是有害的。
Linux Mint在
官方文件指出，他們無法監管Snap Store上的軟體，軟體庫完全是由Ubuntu控制的。
與之相對的是，許多Linux發行版選擇內建Flatpak。部份發行版Manjaro和openSUSE內建Snap，但他們也會內建Flatpak。
那麼Canonical創辦人Mark Shuttleworth怎麼說呢？他在 2022年的訪談說Ubuntu不打算像Fedora一樣，跟隨趨勢內建Flatpak：
「我可以說現在Flatpak不適合我們。我不認為Flatpak有我們要的安全功能，而且我也不認為他們有能力在未來提供與Snap相同的執行完整性，我們已經內建這些功能到Snap了。」
儘管Mark Shuttleworth承認Snap在桌面系統仍有不足之處，但他堅持Ubuntu應該繼續採用Snap。
起碼Ubuntu沒有禁止安裝Flatpak啦。
Snap會不會像Canonical以前推動的 Mir、 Unity、 Upstart技術一樣，哪天就突然掛掉呢？還是會變成UFW一樣廣為使用的技術？目前是未知數。
6. 實際用了Snap之後的想法#
雖然受到批評，但Snap軟體數量確實是有在增加的，常見的Linux軟體都開始有了Snap版本。得益於Ubuntu的高人氣，越來越多開發者願意釋出Snap套件支援。
在架設雲端的時候，我發現Snap可以大大簡化 Nextcloud的安裝程序，且很多非開源的軟體都逐步出現在Snap Store，連 foobar2000都在Snap Store上架了(雖然只是跟Wine包在一起)。某些沒有圖形界面的程式也可以靠Snap取得最新版，例如 Hugo靜態網頁生成器、FFmpeg、ImageMagick。
我覺得Snap有點在重複造輪子的感覺，感覺跟Docker功能重複。有趣的是Canonical確實寫過一篇 Snap vs Docker的對比，二者功能很像，Docker偏向伺服器用途，Snap也是偏向伺服器用途但又順便提供了對桌面系統的支援。
不過如果若真的要跨Linux發行版安裝套件，我還是比較偏好用Flatpak安裝桌面圖形軟體，Snap偶爾作為系統軟體的補充來源。若想把Docker拿來跑圖形軟體，我們還有 Distrobox。
撰文時我主要用的系統是Arch Linux，因為AUR太方便，Snap和Flatpak反而沒那麼必要了。