logo标签列表

Snaps、AppImage、Flatpak和其他的区别是什么？

snapappimageflatpak
我最近收到了很多学生提出的这个问题，虽然我有很多信息可以提供，但我还没有找到一个可以指引人们阅读更新答案的来源（我发现了很多错误和过时的信息）。所以，在这个通用打包系统的演进中，对于像snap、appimage、flatpak等软件包格式，我有一些问题：
- 是谁创建了这个软件包格式？ - 它提供了哪些功能？ - 它有哪些独特的功能？（其他格式尚未具备的） - 谁支持它？ - 哪些发行版使用它？ - 这个软件包的重点是什么？（桌面、云端、移动等） - 哪些格式正在积极开发中？
5个回答
这里是一个关于AppImage、Snap和Flatpak功能的长表格比较。它来自于GitHub上的AppImage Wiki。 请注意，这个比较主要是从AppImage的角度来看的，尽管它试图公正地代表每个项目。
特性 AppImage Snap Flatpak
打包桌面GUI应用程序 ✅ 是 ✅ 是 ✅ 是
打包终端CLI工具 ✅ 是 ✅ 是 ✅ 是（如果您编辑了PATH，则带有App ID别名）[1]
打包服务器进程 ✅ 是 ✅ 是 ⚠️ 可能，但不是主要目标[1]
打包系统服务 ❌ 否 ✅ 是[1] ❌ 否
打包内核 ❌ 否 ✅ 是[1] ❌ 否
正确的应用程序主题 ✅ 是（如果正确完成） ✅ 是（如果当前系统主题已被Snapped）[1] ✅ 是（如果当前系统主题已被Flatpak'ed）[1] [2] [3]
使用库和依赖项 从基本系统或与AppImage捆绑 从基本系统，基础snap, 平台snap (KDE, GNOME, Wine, ..) 或与Snap捆绑 从Freedesktop、GNOME、KDE主要运行时或与Flatpak捆绑
企业支持 ❌ 否（社区项目） ✅ 是（Canonical） ✅ 是（Endless、Red Hat）
领养
特点 AppImage Snap Flatpak
主要商店中的应用数量 1126（2020年8月14日[1] 历史） +6400（2020年8月6日[1]） 约1100（2020年8月14日）
使用该格式的知名商业应用供应商 Adobe, IBM, KDAB, Microsoft, Prusa, Ultimaker, ... Microsoft, Spotify, Slack, JetBrains, Skype, nodesource, ... Xamarin, Codethink, Igalia, ...
内置于第三方应用开发工具中 electron-builder electron-builder, GNOME Builder GNOME Builder

易用性

AppImage 从网站下载，然后将单个文件拖放到文件管理器中的所需安装位置。 drag-and-drop Snap 通过发行版应用商店安装（在Ubuntu、Zorin OS、KDE Neon等系统中支持开箱即用），或通过命令行界面安装：

$ snap install gimp

Flatpak 通过发行版应用商店安装（在 Fedora、EndlessOS 等发行版中提供开箱即用支持）或使用命令行界面 (CLI) 安装:

$ flatpak install --user flathub org.gimp.GIMP

沙盒化/限制
功能 AppImage Snap Flatpak
可以在没有沙盒的情况下运行 ✅ 是（不是必需的，打包人员可选择） ✅ 是（如果Snap构建并获得批准使用“classic”约束）[1] [2] ❌ 否（出于设计目的限制应用程序访问权限）
可以与不同的沙盒一起使用 ✅ 是（例如Firejail [1]，AppArmor [2]，Bubblewrap） ❌ 否（与AppArmor紧密耦合） ❌ 否（与Bubblewrap紧密耦合）

应用程序安装/执行

功能 AppImage Snap Flatpak
无需安装即可运行 ✅ 是（在设置可执行位之后） ❌ 否（需要通过snapd进行安装） ❌ 否（需要通过Flatpak客户端工具进行安装）
无需root访问权限即可运行 ✅ 是 ⚠️ 仅在安装后 ⚠️ 仅在安装后
从压缩源运行而不是解压 ✅ 是 ✅ 是 ❌ 否
应用程序作者可以将可下载文件放在.exe（Windows）和.dmg（macOS）旁边，用户可以在离线系统上安装 ✅ 是（.appimage - 包含运行应用程序所需的所有内容） ❌ 否（.snap - 需要安装snapd，并且如果需要其他snaps，则系统必须在线） ❌ 否（.flatpakref文件需要互联网，.flatpak捆绑包需要安装运行时）
允许应用程序作者自托管应用程序而无功能损失 ✅ 是 ❌ 否 ✅ 是 [1]
适用于空隔离（离线）机器（类似于Edward Snowden使用的那种） ✅ 是 ✅ 是（您可以离线加载应用程序和更新） ✅ 是（P2P支持允许离线安装和更新）
可以从非标准位置（如网络共享、CD-ROM等）存储和运行应用程序 ✅ 是 tbd ✅ 是（需要配置）[1]
应用程序分发
功能 AppImage Snap Flatpak
中央仓库/目录 AppImageHub Snap Store FlatHub
完全去中心化，没有中央守门人 ✅ 是 ❌ 否（一个主导的应用商店）[1] ✅ 是
个别应用程序仓库 ❌ 否（不存储在仓库中） ❌ 否（每个设备只能有一个仓库） ✅ 是
可以同时拥有多个版本（包括历史版本） ✅ 是（任意数量的任意版本） ✅ 是（每个通道一个版本） ✅ 是（OSTree 中的任何版本都可以并行安装）
一旦应用程序安装完成，仍然可以轻松复制到另一台机器上（例如，与朋友本地共享） ✅ 是（一个应用=一个文件；没有“安装”，因此应用程序始终保持相同形式） ✅ 是（但还需要复制它所依赖的 Snaps） ✅ 是（您可以使用 flatpak create-usb 将其复制到 USB 驱动器）

应用程序更新

功能 AppImage Snap Flatpak
更新机制 AppImageUpdate 来自仓库 来自仓库
二进制增量更新 ✅ 是的（使用zsync，无需提前生成增量） ✅ 是的（仅在使用需要生成增量的私有服务器端服务时） ✅ 是的（使用OSTree提供原子更新）
应用程序可以自行更新 ✅ 是的（使用嵌入信息） ✅ 是的 ✅ 是的

Linux发行版支持

特性 AppImage Snap Flatpak
最早支持的Ubuntu版本 Ubuntu 10.04 Ubuntu 14.04 Ubuntu 16.04
最早支持的OpenSUSE版本 OpenSUSE 11.3 Leap 42.2 Leap 42.1
最早支持的Fedora版本 Fedora 12 Fedora 24 Fedora 23
最早支持的Debian版本 Debian 6 Debian 9 Debian 9
最早支持的CentOS版本 CentOS 6 CentOS 7.6 CentOS 7
可直接在Ubuntu上运行 ✅ 是 ✅ 是 ❌ 否
可直接在OpenSUSE上运行 ✅ 是 ❌ 否 待定
可直接在Fedora上运行 ✅ 是 ❌ 否 ✅ 是
可直接在Debian上运行 ✅ 是 ❌ 否 待定
可直接在CentOS上运行 ✅ 是 ❌ 否 ✅ 是
可运行于实时系统（例如：实时ISO、实时USB、实时CD、实时网络引导） ✅ 完全支持 ⚠️ 部分支持（从18.04开始，但受内核限制和“我们几乎不花时间处理它”的限制） ⚠️ 部分支持（必须重新启动会话才能捕获导出内容）
可在Chrome OS（Crostini）上运行 ✅ 是（Chrome OS 73） ✅ 是（Chrome OS 73） ✅ 是

目标和治理

特点 AppImage Snap Flatpak
独立于任何特定的发行商 ✅ 是的（一个社区项目） ❌ 不是（Canonical 的倡议） ✅ 是的（一个社区项目）
不受任何主导公司业务案例的影响 ✅ 是的 ❌ 不是（Canonical 的核心业务） ❌ 不是
旨在减少发行版对桌面 Linux 生态系统的影响，避免成为中央守门人 ✅ 是的 ❌ 不是 ✅ 是的（每个人都可以托管自己的仓库）
旨在赋予应用开发者和最终用户更多权力 ✅ 是的 ✅ 是的 [1] ✅ 是的 [1]
致力于统一桌面 Linux 平台，而不是继续将用户群体分散到不同的发行版生态系统中 ✅ 是的（通过指出需要共同解决的核心问题） ❌ 不是（实际上在底层发行版之上放置了另一个发行版的基础 snap） ❌ 不是（实际上在底层发行版之上放置了一个 Yocto 发行版）

应用程序大小

功能 AppImage Snap Flatpak
应用程序存储在磁盘上始终保持压缩状态 ✅ 是 ✅ 是 ❌ 否（服务器端压缩，客户端不压缩）[1]
应用程序使用的磁盘空间比“传统安装”的应用程序少得多 ✅ 是 ✅ 是 tbd
示例：LibreOffice下载大小（source） 约248兆字节 463兆字节 [2020年7月更新] 543兆字节
在下载之前，准确了解要下载和存储在磁盘上的大小 ✅ 是（一个应用=一个文件） ❌ 否[不考虑平台快照[1]] ❌ 只能估计最坏情况，因为去重复

执行速度

特性 AppImage Snap Flatpak
LibreOffice启动时间（来源） 3秒 13秒 7秒

软件包格式

特点 AppImage Snap Flatpak
文件格式通过官方标准机构进行标准化 ❌ 否（但一旦格式稳定下来，对此很感兴趣） ✅ 是（由Snap格式TOB[1]创建） ❌ 否（尽管存在实验性OCI支持）
概念上的灵感来源于 macOS .app内的.dmg（追溯到NeXT）；Rox AppDir Click（Ubuntu Touch软件包） klik（AppImage的前身名称）

项目代码库

功能 AppImage Snap Flatpak
贡献者无需签署CLA ✅ 是 ❌ 否 ✅ 是
开发自 2004年（当时称为klik） 2010年（前身称为Click Packages） 2013年（前身称为Glick Glick2和xdg-app）
84我认为值得指出的是，这个图表是从AppImage的角度构建的。也就是说，默认的功能集是AppImage的功能集，其他功能与其进行比较。这给了AppImage一种有偏见的优势。而且它也有点过时。例如，Snap在今年秋季添加了主题支持。 - Dan
1@Dan：如果你对Snap增加了它们的支持有所了解，为什么不直接编辑到图表中呢？此外，如果你还知道Snap和/或Flatpak中的其他功能，请随时在AppImage维基百科中添加相应的项目... - Kurt Pfeifle
1此外，亲爱的@Dan：我不同意你的看法，即“默认功能集是AppImage的功能集，其他功能集与其功能相比”。否则，你如何解释“单独的应用程序存储库”一项的条目？ - Kurt Pfeifle
18我不确定你怎么能这样说，@Kurt。以"目标"部分为例，看一下吧。它只展示了AppImage的目标，好像其他项目都没有任何目标一样。好像只有AppImage的目标才重要。 - Dan
1@丹：那你为什么不提交修改原表格，展示“其他项目的目标”呢？你知道这是一个维基百科... - Kurt Pfeifle
11我明白你的意思 - 我可以编辑维基百科。然而，你的答案是一个巨大的图片，可能会永远保持原样，即使维基百科发生变化。我认为在提及你的答案时，将偏见提到背景中对于未来的Ask Ubuntu读者来说是值得的。 - Dan
3@丹：我在7月4日编辑了答案，插入了来自网站的更新版本截图（确切地说是为了包含维基上发生的一些修改）。你对于编辑原始维基、创建新的截图，然后建议使用新截图修改答案有什么问题呢？ - Kurt Pfeifle
哇，AppImage看起来很棒。 - Nathan Basanese
13这里缺少的是为什么 Flatpaks 和 Snaps 存在的根本原因，尽管 AppImage 早在之前就存在了。使用 AppImages，开发者需要确保应用在所有条件下都能正常工作。而使用 Flatpaks（以及我相信 Snaps 也是如此），有底层运行时环境来镜像开发者机器的状态，确保应用在不同设置的发行版上都能正常工作。 - Tin Man
@TinMan：我相信你足够聪明，能够将那个陈述/观察重新表达成适合作为额外的入口点放入表格中。将其放入原始维基页面中，我会确保在我的回答中包含你的贡献，并附上更新后的截图。 - Kurt Pfeifle
在“应用程序大小”下面，你选择了“应用程序使用更少的磁盘空间”的几个选项。虽然我只能提供一些个人经验作为佐证，但根据我的经验来说，这完全是错误的。GIMP的Snap版本大小为229MB，而传统版本只有4MB。Inkscape的大小为182MB，而传统版本则只有79MB。 - aidan
@aidan: （1）我认为你对GIMP（传统版）的理解肯定是错的。也许GIMP的可执行文件只有4兆字节，但你必须计算GIMP软件包中包含的所有文件以及GIMP直接需要的所有软件包（如'gimp-data'、'libgimp-2.0'等），其中还包括相当多的库文件。例如，请参考这里：https://packages.debian.org/de/jessie/gimp 和这里：https://packages.debian.org/de/jessie/amd64/gimp/filelist。 - Kurt Pfeifle
@aidan: (2) 虽然第一个链接中有一个表格（完全向下滚动），确认了你对GIMP 软件包 的4 MByte的数量，但它也说明了这个数字是什么意思：打包、压缩字节大小。紧挨着它的是“大小（已安装）”的数字，已经达到了15.2 MByte。再加上“gimp-data”和“libgimp-2.0”的相应数字，你已经占用了63 MByte的磁盘空间。此外，你还需要安装更多的软件包才能正常使用GIMP... - Kurt Pfeifle
@KurtPfeifle 好的，我的数字有点不准确，但是一个将所有依赖项打包在一起的程序怎么可能比与主机操作系统上的其他所有程序共享依赖项的同样程序更小呢？ - aidan
@aidan：秘密就是它在磁盘上是压缩的，并且在内存中运行时仍然保持压缩状态。'经典'软件包管理系统也会将软件进行压缩，但只是在装运过程中。安装过程会将文件放置在磁盘上非压缩，因此占用更多的磁盘空间。 - Kurt Pfeifle
@aidan：相信我，表格中的数字是正确的（在“大致上”、“大约”这个意义上——不一定要精确到最后一个字节）。 - Kurt Pfeifle
1我认为这是对三者之间更加平衡的比较：Snap vs Flatpak vs AppImage 比较。它更多地提到了Snap和Flatpak设计背后的原因（而AppImage一开始并没有涉及）。它还提到了AppImage的优势。 - Koala Yeung
这里有一个追踪快照总数的网站：https://snapstats.org/ - Fuseteam
Snaps是由Canonical为Ubuntu创建的。Snaps的主要优点有：
- 独立于依赖关系 - 所有库和依赖都包含在软件包中。这样还可以拥有同一个程序的多个版本。 - 沙箱化 - Snaps使用修改后的AppArmor来沙箱应用程序。 - 增量更新 - Snaps也应该允许增量更新。
Snaps的主要缺点是软件只能使用其软件包中包含的库。这是潜在的安全风险，因为软件包的作者需要保持所有库的补丁和更新。
Snaps目前可以在Ubuntu、Arch Linux、Fedora、Linux Mint、CentOS和Gentoo上运行。它们还被用于Ubuntu Touch。Snaps专为桌面、服务器、手机、物联网和路由器而设计。
Flatpak具有与Snaps相同的优点。然而，它使用Namespaces而不是AppArmour进行沙箱化。主要区别在于Flatpaks既可以使用包中包含的库，也可以使用另一个Flatpak中的共享库。
Flatpak的开发者是Red Hat员工Alexander Larsson。Flatpak软件目前可在Arch Linux、Debian、Fedora、Mageia、Solus和Ubuntu上使用。它专注于桌面环境。
AppImages是由Simon Peter开发的。与snaps或Flatpak类似，该软件包包含运行程序所需的所有库。AppImage程序没有沙盒化，并且不需要root权限来运行。根据该项目的网站，AppImages应该可以在Arch Linux、Centos、Debian、Fedora、OpenSUSE、Red Hat Linux和Ubuntu上运行。
3Solus在2017年1月宣布支持Flatpak。 - Anthon
17他们本应该只是在AppImage的基础上进行开发。而不是重新发明相同的理念，引入碎片化和混乱。另外请注意，由于这些便携包含了所有的库文件，与通过apt或.deb安装的使用共享库的应用相比，它们的体积会更大。如果你一定要知道哪个更受欢迎，目前Flatpak正在超过Snaps。 - answerSeeker
@magma，考虑到这个答案，你知道AppImage和Flatpak包是如何更新的（像snap refresh那样手动更新还是自动更新）吗？ - Pablo Bianchi
5@answerSeeker：你关于便携包相对于通过apt或.deb安装的使用共享库的应用程序“在尺寸上要大得多”的评论并没有得到实际事实的支持。AppImages和Snaps被压缩成SquashFS镜像（Flatpak不是这样）。它们从不被解压到磁盘上，甚至在运行时也不会。当运行时，AppImages会自动挂载到一个临时创建的挂载点中，路径为/tmp/.mount_<随机字符>，并从那里运行 - 仍然是压缩的！请参见下面我回答中的LibreOffice示例截图中的数字... - Kurt Pfeifle
3@PabloBianchi: 较新的AppImages（更近期的"类型2"）可以具有内置的更新机制。一旦有新版本可用，并且用户表示希望更新，该机制将从原始AppImage位置下载二进制差分文件，从而在下载大小和时间上节省资源。工具*appimageupdatetool*（CLI）和 *AppImageUpdate-Qt*（GUI） 可以提供帮助。 - Kurt Pfeifle
我也喜欢Snap商店以及它为开发者提供的安装统计数据（包括你的应用在哪些地方被使用，哪些版本安装在哪个Ubuntu版本上等等）。 - user205301
看起来像是一个“非我所创”的情况。:( - Nathan Basanese
Linux Mint实际上放弃了对Snap的支持，转而选择了Flatpak。 - ostrokach
1@Chris，幽灵与使用共享库无关，而是指在同一CPU上运行。 - akostadinov
4Flatpack实际上是在Snap之前几个月推出的，对于那些想知道谁在什么时候发明了什么的人来说。看起来它们是为不同的原因同时被发明的。Flatpack并不是一项新技术，我的团队在00年代就使用了相似的技术（命名空间），但我无法让管理层开源它，所以那家公司倒闭了。命名空间无处不在，而Snap依赖于AppArmor，更难移植到其他发行版。 - eric.green
两个更正：（1）Ubuntu Touch目前不使用snaps，（2）现在有基础snaps，因此snaps可以共享依赖关系，其中一个副作用是snaps可以比传统安装包更小。 - Fuseteam
为什么要重复造轮子呢？他们并没有这样做。这就像说“通用汽车制造汽车，为什么丰田要重新发明轮子？”（开个玩笑）我尝试了三种（针对Gimp），从可用软件包和软件包信息、交互性和直观性来看，我清楚地看到了一个赢家：flatpak。snap也不差，而appimage则排在最后（它可能有一些有趣的功能，但更新过程、查找和版本控制等方面对我来说不太适合）。 - Déjà vu

不要忘记主要的事情，它是开源的吗？

AppImage

开源客户端 ✅ 是
开源服务器 ✅ 是

Snap

开源客户端 ✅ 是
开源服务器 ❌ 否

Flatpak

开源客户端 ✅ 是
开源服务器 ✅ 是

Snap Store不是开源的，虽然有一些尝试的实现，但目前没有可用的版本。请参阅https://forum.snapcraft.io/t/external-repositories/1760，了解关于桌面Snap应用程序服务器端的这个通用主题的非常详细的讨论。 - Ads20000
21如果刻度是统一的话，阅读起来会容易得多。 - problemofficer - n.f. Monica
很不幸，我所使用的资源中只有这些图片可用。 - pktiuk
4此外，添加一个结论也是很好的。 - Chris
如果您同时运行多个Flatpak，文件系统可能无法正常工作。 例如，如果我同时打开了Openscad和Flashprint，我可以从Openscad写入磁盘，但无法从Flashprint写入。在Snap中似乎没有这个问题。