程序包管理器提供了一种在操作系统中打包，分发，安装和维护应用程序的方法。
借助Linux操作系统的现代台式机，服务器和IoT应用程序以及现有的数百种发行版，有必要从特定于平台的打包方法转移到与平台无关的打包方法。
这篇文章探讨了3种这样的工具，即AppImage，Snap和Flatpak，它们各自旨在成为Linux中软件部署和管理的未来。
最后，我们总结了一些关键发现。

1. AppImage

AppImage遵循一个概念，即“一个应用=一个文件”。
这应理解为AppImage是一个常规的独立“文件”，其中包含一个应用程序，该应用程序需要在所述文件中运行的所有内容。
一旦成为可执行文件，只需在用户文件系统中双击即可将AppImage像计算机中的任何应用程序一样运行。
[1]

它是一种用于为Linux创建可移植软件而无需用户安装上述应用程序的格式。
该格式允许软件的原始开发人员（上游开发人员）创建其应用程序的平台和独立于发行版（也称为与发行版无关的二进制文件）的版本，该版本基本上可以在任何Linux上运行。

AppImage已经存在很长时间了。
Klik是AppImage的前身，由西蒙·彼得（Simon Peter）于2004年创建。
该项目在未通过Beta阶段后于2011年关闭。
Simon大约在同一时间创建了一个名为PortableLinuxApps的项目，该格式被一些为Linux用户提供软件的门户采用。
该项目在2013年再次重命名为当前名称AppImage，并在GitHub（项目链接）中维护了一个存储库，并自2016年以来对其进行了最新更改。
[2] [3]

AppImage主要由C语言编写，自2013年以来已获得MIT许可证，目前由The AppImage项目开发。
如以下功能所示，这是使用应用程序的一种非常方便的方式：

• AppImages几乎可以在任何Linux系统上运行。如前所述，应用程序从操作系统和一些通用库中派生出许多功能。这是软件界的一种普遍做法，因为如果已经完成某件事，那么如果我们可以从同一部分中选择要使用的部分，则没有必要再做一次。问题在于，许多Linux发行版可能没有特定应用程序需要运行的所有文件，因为该发行版的开发人员不得不将其包含必要的软件包。因此，开发人员需要为要为其发布应用程序的每个Linux发行版分别包含应用程序的依赖项。使用AppImage格式，开发人员可以选择包括他们不可能希望目标操作系统拥有的所有库和文件作为AppImage文件的一部分。因此，相同的AppImage格式文件可以在不同的操作系统和计算机上工作，而无需进行精细控制。
• 一个应用程序一个文件的理念意味着用户体验简单而优雅，因为用户只需要下载并执行一个文件即可满足他们使用该应用程序的需求。
• 无需root访问权限。系统管理员将要求人们具有root用户访问权限，以防止他们与计算机及其默认设置混为一谈。这也意味着没有root访问权限或者超级用户特权的人无法按需安装所需的应用程序。在公共场所（例如库 或者大学计算机或者企业系统中），这种做法很常见。 AppImage文件不需要用户“安装”任何文件，因此用户只需要下载所述文件并使其可执行即可开始使用它。这消除了系统管理员所面临的访问难题，并使他们的工作更加轻松而又不牺牲用户体验。
• 对核心操作系统没有影响。 AppImage应用程序格式允许使用具有全部功能的应用程序，而无需更改甚至访问大多数系统文件。意味着无论应用程序做什么，核心操作系统设置和文件都保持不变。
• 开发人员可以为他们的应用程序的特定版本制作一个AppImage。任何更新的版本都将作为其他AppImage进行制作。因此，如果需要，用户可以通过使用不同的AppImage运行不同的实例来测试同一应用程序的多个版本。当我们需要从最终用户POV测试应用程序以注意到差异时，这是一项非常宝贵的功能。
• 将应用程序带到任何地方。如前所述，AppImages是应用程序所需的所有文件的存档文件，可以在不安装甚至不打扰系统使用的发行版的情况下使用它们。因此，如果我们有一组经常使用的应用程序，则甚至可以在拇指驱动器上安装一些AppImage文件，并将其随身携带，以在运行多个不同发行版的多台计算机上使用，而不必担心它们是否会正常工作。

此外，AppImageKit允许所有背景的用户从已经拥有的应用程序或者上游开发人员未提供AppImage的应用程序构建自己的AppImage。

程序包管理器是独立于平台的，但主要致力于通过专用守护程序AppImaged将软件分发给最终用户在其台式机上，以将AppImage格式集成到各自的台式机环境中。
现在，各种发行版（例如Ubuntu，Debian，openSUSE，CentOS，Fedora等）都原生支持AppImage，其他人也可以根据自己的需要进行设置。
还可以通过随附的CLI工具在功能受限的服务器上运行AppImage。

要了解有关AppImage的更多信息，请转到正式的AppImage文档页面。

建议阅读：

• 在AppImage，Flathub和Snapcraft平台上搜索Linux应用程序

2.活泼

Snappy是一个软件部署和程序包管理系统，例如AppImage或者该实例的任何其他程序包管理器。
它最初是为现已失效的Ubuntu Touch操作系统设计的。
Snappy使开发人员可以创建软件包，以在各种基于Linux的发行版中使用。
创建Snappy并在基于Ubuntu的系统上部署“快照”的最初目的是获得一种统一的单一格式，该格式可用于从IoT设备到运行某些版本的Ubuntu以及从更广泛的意义上讲Linux本身的各种功能的计算机系统中。
。
[4]

该项目的主要开发人员是Canonical，该是Ubuntu项目的试点。
目前，Ubuntu从16.04 LTS版本开始就提供了本机快照支持，如今有越来越多的发行版通过简单的设置来支持它。
如果我们使用Arch或者Debian或者openSUSE，我们会发现很容易使用终端中的简单命令来安装对软件包管理器的支持，如本节稍后所述。
通过在相应的存储库中提供必要的快照平台文件，也可以做到这一点。
[5]

Snappy具有构成整个程序包管理器系统的以下重要组件。
[6]

• Snap –是软件包本身的文件格式。使用Snappy部署的各个应用程序称为“快照”。可以使用提供的工具打包任何应用程序，以制作旨在在运行Linux的其他系统上运行的快照。 Snap与AppImage相似，是一个包含所有内容的文件，并且包含应用程序需要运行的所有依赖关系，而无需假定它们依赖于目标系统的一部分。
• Snapcraft –是使开发人员可以对其应用程序进行快照的工具。基本上，它是快照系统的一部分，也是框架的一部分，可让我们构建自己的快照。
• Snapd –是后台守护程序，用于维护系统中安装的所有快照。它集成到桌面环境中，并管理与使用快照有关的所有文件和过程。除非另外设置，否则snapd守护程序通常一天也通常检查4次更新。
• 快照存储–是一种在线画廊，使开发人员可以将快照上传到存储库中。

快照存储也是用户的应用程序发现介质，可让用户在下载和安装应用程序库之前先查看并体验它们。

捕捉的组件主要用C和Golang编写，而Snapcraft框架是使用Python构建的。
尽管两个模块都使用GPLv3许可证，但要注意的是，snapd拥有Canonical的专有代码，可用于其服务器端操作，而客户端仅在GPL许可证下发布。
这是与开发人员争论的主要问题，因为这涉及开发人员签署CLA表单以参与快照开发。
[7]

深入了解Snappy软件包管理器的详细信息时，可能会注意到以下几点：

• 如前所述，快照包含所有内容，并且包含应用程序需要运行的所有必需文件（依赖项）。因此，开发人员无需针对他们所针对的不同发行版进行不同的快照。如果基本运行时已从快照中排除，则必须注意运行时。
• Snappy软件包旨在支持事务更新。这样的事务性更新是原子性的，并且是完全可逆的，这意味着我们可以在应用程序被更新时使用它，并且，如果更新的行为不符合其应有的方式，则可以在没有其他影响的情况下将其撤消。该概念也称为增量编程，其中仅将对应用程序的更改作为更新而不是整个程序包进行传输。一个名为Ubuntu Core的Ubuntu衍生产品实际上向操作系统本身承诺了快速的更新协议。[8]
• 捕捉和AppImage之间区别的关键点是它们如何处理版本差异。使用AppImages的不同版本的应用程序将具有不同的AppImages，使我们可以同时同时使用同一应用程序的2个或者更多不同版本。但是，使用快照意味着符合事务或者增量更新系统。虽然这意味着更新速度更快，但可以防止我们同时运行同一应用程序的两个实例。如果我们需要使用旧版本的应用，则需要撤消或者卸载新版本。 Snappy确实支持称为“并行安装”的功能，该功能将使用户实现类似的目标，但是，它仍处于试验阶段，不能认为是稳定的实现。

Snappy还利用渠道，这意味着我们可以同时使用Beta或者应用的夜间版本以及稳定版本。[9]

• 来自主要Linux发行版和主要开发人员的广泛支持，包括Google，Mozilla，Microsoft等。[4]
• 快照桌面集成工具支持对系统中所有已安装快照的当前状态进行“快照”。这将使用户保存通过Snappy软件包管理器安装的所有应用程序的当前配置状态，并让用户在需要时恢复到该状态。也可以将同一功能设置为以用户认为必要的频率自动拍摄快照。可以使用快照框架中的snap save命令创建快照。[10]
• 快照被设计为在操作过程中被沙盒化。这为用户提供了非常需要的安全性和隔离层。用户不必担心基于快照的应用程序会与计算机上其余软件混为一谈。沙盒使用三种隔离级别来实现，即经典，严格和开发模式。每个隔离级别都允许该应用在文件系统和计算机内进行不同级别的访问。[11]

另一方面，快照被指责为围绕Canonical的作案手法。
该项目的大部分承诺都是由Canonical员工或者承包商提供的，其他贡献者必须签署发布表格（CLA）。
从安全的角度来看，沙盒功能确实是一个非常重要的功能，但存在缺陷：沙盒实际上需要运行某些其他核心服务（例如Mir），而运行X11桌面的应用程序将不支持上述隔离，因此表示安全功能无关紧要。
Canonical以及“中央”和封闭式应用程序存储库中可疑的新闻稿和其他营销工作也受到Snappy的广泛批评。
此外，与使用AppImage制作的程序包的应用程序大小相比，不同快照的文件大小也相对较大。
[7]

有关更多详细信息，请查看Snap官方文档。

相关阅读：

• 在Arch Linux和Fedora中安装Snap软件包

3. Flatpak

像上面列出的Snap/Snappy一样，Flatpak还是一种软件部署工具，旨在简化Linux中的软件分发和使用。
Flatpak以前被称为“ xdg-app”，它基于Lennart Poettering在2004年提出的概念。
该想法是将应用程序包含在安全的虚拟沙箱中，从而允许使用应用程序而无需root特权，并且不会损害系统安全性。
。
亚历克斯开始与Klik（应该是AppImage的旧版本）进行修补，并希望更好地实现这一概念。
当时与Red Hat合作的Alexander Larsson在2014年编写了名为xdg-app的实现，该实现充当了当前Flatpak格式的前兆。

Flatpak在Red Hat，Endless Computers和Collabora的支持下于2015年正式问世。
Flathub是所有Flatpak应用程序包的官方存储库。
Flatpak与其他平台一样，是一个用于为Linux构建和打包与发行无关的应用程序的框架。
它仅要求开发人员遵守一些桌面环境准则，以便将应用程序成功集成到Flatpak环境中。

Flatpak框架主要针对三种流行的桌面实现FreeDesktop，KDE和GNOME，它本身是用C编写的，并且使用LGPL许可证。
可以通过此处的GitHub链接访问维护资源库。

下面介绍Flatpak使其脱颖而出的一些功能。
请注意，此处省略了Flatpak与AppImage和Snappy共享的功能。

• 与流行的Linux桌面环境（如GNOME和KDE）进行了深度集成，因此用户可以使用图形化软件管理工具简单地使用Flatpaks，而不必求助于终端。现在可以从主要桌面环境的默认存储库中安装Flatpak，并且一旦设置了应用程序本身，就可以使用它们并提供与普通桌面应用程序类似的功能。[12] [13]
• 前向兼容性– Flatpaks是从头开始构建的，牢记了操作系统的核心内核和运行时。因此，即使我们升级或者更新了发行版Flatpaks，除非有核心更新，否则我们仍然应该可以使用。对于喜欢继续使用发行版Beta或者发行版的人们来说，这一点尤其重要。对于这类人来说，由于通常无法消除操作系统本身的缺陷，因此Flatpak应用程序可以无缝运行，而不必依赖操作系统文件或者库来进行操作。[13]
• 使用Bubblewrap的沙箱-默认情况下，快照也被沙箱化，因为它们与我们使用计算机时正在运行的其余应用程序隔离运行。但是，默认情况下，Flatpaks完全阻止了应用程序在其运行期间访问OS文件和用户文件。这从本质上讲意味着系统管理员可以肯定，安装在其系统中的Flatpaks无法利用计算机及其包含的文件，而对于最终用户而言，这意味着要访问一些特定功能或者需要用户数据root权限。 [14]
• Flatpak本身就支持分散应用程序的分发，但是Flatpak背后的团队仍然维护着一个名为Flathub的中央应用程序/Flatpaks在线存储库。实际上，用户可以根据需要将Flatpak配置为使用多个远程存储库。与快照不同，我们可以有多个存储库。[13]
• 通过沙箱的模块化访问。尽管此功能为系统的完整性带来了巨大的潜在成本，但Flatpak框架允许通过沙箱创建通道，以将特定信息从沙箱内部交换到主机系统，反之亦然。在这种情况下，该通道称为门户。稍后在本节中将讨论与此功能有关的问题。[14]

Flatpak最受批评的方面之一是沙盒功能本身。
沙盒是Snappy和Flatpak等软件包管理器实现重要安全功能的方式。
沙盒从本质上将应用程序与系统中的所有其他功能隔离开，仅允许用户定义的信息从沙盒内部到外部进行交换。
该概念的缺陷在于，沙盒不能固有地不可渗透。
最终必须在两个域之间传输数据，并且简单的Linux命令可以摆脱沙箱限制，这意味着恶意应用程序可能会从所述沙箱中跳出。
[15]

加上对Flatpak推出安全更新的承诺比预期的差，导致对该团队提出的提供安全框架的崇高主张引起了广泛的批评。
实际上，在本教程末尾链接的教程 （名为Flatkill）提到了一些漏洞，Flatpak团队一经发现就没有解决这些漏洞。
[15]

有关更多详细信息，建议我们阅读Flatpak官方文档。

AppImage vs Snap vs Flatpak

下表附上了以上所有发现，并对这三个框架进行了简要的技术比较。

这是AppImage，Snap和Flatpak功能的长列表比较。
请注意，比较是从AppImage角度进行的。

总结

虽然这三个平台彼此之间有很多共同点，并且旨在成为与方法无关的平台，但它们在某些领域提供了不同级别的能力。
尽管Snap可以在包括嵌入式设备在内的各种设备上运行，但AppImages和Flatpaks的构建是针对桌面用户的。
另一方面，流行应用程序的AppImage具有出色的包装尺寸和可移植性，而Flatpak与其配套使用而忘却它的系统时，确实具有其前向兼容性。