我已经认识到在 ubuntu 中更新软件需要比 windows 和 android 更多的数据传输。例如，今天我将 firefox 88 更新到 firefox 88.0.1。在 ubuntu 中，它下载了大约 55 MB 的数据，在 windows 10 中将 firefox 88 更新到 firefox 88.0.1 大约需要下载 15 MB 或更少的数据。或者，在 ubuntu 中将 chrome 从 90.xx1 更新到 90.xx2 将下载大约 88 MB 的数据，而在 windows 10 中大约需要下载 10 MB 或更少的数据。此外，在 android 中它与 windows 更相似，与 ubuntu 相比，它更新软件所需的数据要少得多。
那么，为什么会存在这种差异？这背后有什么逻辑吗？如果没有，是否有计划使软件更新变得更好？
答案1
在某些平台上，众所周知的大型软件似乎都是逐步更新的。这很合理：互联网浏览器非常庞大，它们经常更新，但二进制差异可能没那么大。
https://wiki.mozilla.org/UpdateGeneration
这样做的好处是节省带宽，但代价是在服务器端生成版本之间的二进制差异。如果用户跳过了一个或多个更新，则必须将从一个旧版本到下一个版本的每个差异都保留在服务器上，或者该用户无论如何都会获得完整包，在这种情况下，与始终复制大型完整包相比，没有任何优势。因此，服务器需要为每个包保留至少两个版本：最新差异和完整包。实际上，可能还会更多。
Linux 软件包管理器的工作方式有所不同：它们不仅通常总是传输整个新软件包，而不仅仅是差异软件包。它们还允许在此过程中执行脚本：
- 软件包安装前的预安装脚本
- 软件包安装完成后的安装后脚本
- 软件包卸载（删除）之前的预卸载脚本
- 软件包卸载后的卸载后脚本
例如，这可用于将现有数据库从旧格式转换为新格式，或从正在运行的系统收集信息（例如硬件信息）并将其存储在该包的配置数据库中；或者在最终卸载包时安全地删除其中任何一个。
升级到较新的软件包版本意味着卸载旧版本并安装新版本；因此在这种情况下，所有这四个脚本（如果软件包定义了它们）都会被执行。
但在增量升级的情况下，情况变得更加复杂：不再需要彻底卸载旧软件包，从而删除所有旧文件；必须保留这些文件，以便应用传入的二进制差异。因此，任何这些脚本都不能再依赖于这些文件的存在或不存在；它们必须应对更多场景。
目前将所有内容打包到 snap 或 flatpaks 中的趋势使情况变得更糟：在这种情况下，您不仅可以获得新的软件包，还可以获得它周围的所有内容；基本上是底层操作系统的较好部分，至少是所有使用的库（直接和间接依赖项）。
我不知道这些全包软件包格式是否可以处理增量升级；如果不能，那么可能值得考虑一下。