为什么快照这么笨重?

apa*_*ana 10 package-management snap

例如,在我的系统上apt-get,安装 IDE geany 需要下载 3.5 MB,而 snap 的下载大小为 100 MB。这太大了,不能接受!即使是 geany 的 Windows 安装程序,大小也不超过 15.4 MB!

软件使用的哪些库包含在其快照文件中?假设操作系统上已经存在什么?snap 文件是否包含所有必需的库?如果是这样,为什么?我认为没有理由在一个系统上应该存在库的每个特定版本的多个副本,比如 GTK。

可能我对snap系统还不够了解。也许每个快照的下载大小取决于已安装的快照。例如,如果 snap 安装的另一个应用程序使用相同版本的 GTK,那么 geany 的 snap 安装下载大小将小于 100 MB。

Art*_*ild 7

我想你回答了你自己的问题。Snap 体积庞大,因为它们还包含一些依赖项,因此是“自包含”应用程序。有利有弊。

您在系统上拥有多个库实例的原因是可能需要不同的版本,尤其是在您运行较旧的应用程序时。我认为对于使用最新依赖项的较新应用程序,这应该很少成为问题。

如果您没有依赖性问题,就没有真正的理由使用 snaps——这对于服务器来说尤其如此。就我自己而言,我几乎没有理由在 apt 包上安装 snaps(也因为我尝试的 snap 没有得到维护,因此功能比相应的 apt 包少)。


Vij*_*ema 5

正确,Snaps比常规包大得多,因为它们是分发和安装应用程序的另一种方式,通过将所有依赖项包含在其自身中来实现自包含。

快照的优点:

  • 始终包含开发人员预期的正确版本依赖项 - 这可以避免依赖项问题,尤其是 Linux 上未维护的应用程序中常见的依赖项问题。
  • 在 PC 上以独立的方式运行,在某些情况下这是更好的安全性
  • 后台自动更新
  • 适用于任何 Linux 发行版
  • 对新用户友好

Snap 的缺点:

  • 由于捆绑了所有特定的软件包,而不是重用系统上可能已经存在的软件包,因此下载和安装的大小更大。
  • 某些 Snaps 的 3rd 方维护不是很好(所有包管理器确实如此,但通常 Snap 更新时间可能晚于单个包,有时由随机的 3rd 方可能会在某些时候停止。通常,流行的已建立的应用程序如果组织使用 Snap 作为主要的分发方法,那么他们背后有强大的组织可以很好地与 Snap 合作,而年轻/较小的应用程序则不然)。
  • 虽然依赖项是开发人员想要的,但可能会经常出现应用程序不会使用的更新更好的版本。
  • 可能有一些额外的步骤来允许权限(就像类似容器化的 Android 或 Windows 应用商店应用程序)。
  • 由 Canonical 集中控制(即只有一个中央 Snap 存储库,没有人可以自己启动。相比之下,Flatpak 是一种没有此限制的替代方案)。对于希望只拥有一个可能的商店的简单性的新用户来说,这可能是一个优势。
  • 由于在自己的容器中运行,有时 Snap 应用程序并不能反映当前的操作系统主题和风格。虽然我相信这可以通过安装将容器化应用程序与当前操作系统主题相匹配的“通用主题”Snaps 来部分解决。

我个人使用 Snap 的目的

  • 当它是由大型组织支持的流行应用程序并且 Snap 由该组织直接发布时。示例:Blender、Inkscape、VLC。 这对我个人来说很关键:开发者必须直接并强烈支持使用 Snap 作为主要的分发方式。
  • 当我遇到错误时,这些错误通常是由于新版本的依赖项中不可预见的变化引起的。在这种情况下,我将尝试切换到该应用程序的自包含包,如 Snap 或 Flatpak。

所有其他实例我更喜欢 Ubuntu apt 包管理器。

另请注意,在某些情况下,如果 Canonical 认为 Snap 软件包在所有方面都比您通过 apt 安装的应用程序版本更好,Ubuntu 将自动安装 Snap 而不会通知您(!)