|
以下是关于AppImage、.snap、.deb、Flatpak区别的理解，也做了相关的解释。
Appimage某种程度上你可以理解为windows某些软件的“便携版”，它的做法有点类似于docker镜像，把软件运行的所有依赖环境都打包在一起，包装成一个Appimage，运行的时候会将打包到一起的内容释放到/tmp/下运行，运行完毕之后通常会自动清理。参考下载运行AppImage：简单、可靠、快速的特性。
deb是debian系列传统的打包方式，取自debian的前三个字母，deb包你可以认为就是一个压缩包，同时还包含了一个元数据部分，声明了这个包的依赖，所以通过包管理系统就可以很方便的安装deb以及相关的依赖项了，这也是debian系列简化Linux软件安装方案做的巨大的贡献。RHEL的yum+rpm的管理方式实际就是借鉴了apt+deb的方式，debian是第一个将包管理系统引入Linux系列的发行版。
snap、flatpak要解决的是一类问题，Linux的包管理系统很大程度上简化了软件部署安装的操作，通过包依赖可以最大限度的减少系统冗余，减少了操作系统软件的容量，有好处也有坏处，繁杂的依赖方式也让底层依赖的软件包变得难以迁移，牵一发而动全身，比如经常有人因为手工升级了底层的python导致整个系统上层应用全挂的问题，依赖问题最终变成了严重问题，比如也有用户因为误删某个软件包导致依赖的dde被一并删除，结果deepin的桌面就没了。
snap是Ubuntu于2016年前后推出的新型包管理方案，用于替代传统的apt方案，在Ubuntu 16.04及以上版本内置支持，它提供了沙箱运行环境，一定程度上隔离依赖地狱的问题，你可以理解为windows的msi安装包的方案，windows的软件安装包通常很大，但一定程度上也避免了依赖地狱的问题，通常不会因为一两个软件包卸载搞崩溃其他应用，但是snap最大的问题就是它的软件仓库协议上不允许镜像，只能通过官方软件仓库Snappy走，并且支持私有收费的软件部署，所以目前并未大规模使用，因为官方仓库实在太慢了，而且不允许镜像。参考在Ubuntu 18.04/Debian上安装和使用Snap的方法。
Flatpak是在Ubuntu推出snap当年也正是宣布推出的新型包管理方案，这俩的路数大同小异。不过无论是snap还是Flatpak都是比较新的包管理方案，目前支持的软件包并不多，一定程度上也限制了推广和使用。参考在Linux系统上安装并使用Flatpak的方法。
补充：Appimage不是什么通用的标准，只是snap和flatpak还没出现的一种替代方案，可以把它当做“便携版”来看待，对于不需要持久化存储的应用程序来说，有那么点用途，对于一些需要持久化存储数据的应用来说，需要单独为Appimage做一些特殊的逻辑处理，所以也并非能做到绝对的无侵入性。同时可以把它当成自解压包，运行前将压缩文件释放到/tmp，然后cd /tmp/xxxx.appimage/目录之后执行可执行权限，所以启动速度也不算太快，越大的文件越需要更长的解压缩时间，对于运行速度敏感的程序体验不是太好。deb包通常需要结合包管理器一起使用，安装的时候会自动解决依赖，所以会出现不符合目标操作系统的安装包混入搞坏依赖，甚至因为卸载了底层依赖导致删掉上层应用的现象，这也就是依赖的问题，windows的安装包通常都会将自己的运行环境一并打包进入安装包，以规避依赖问题，缺点是安装包通常很大，好处就是规避了依赖问题，所以可以认为snap和flatpak借鉴了windows的安装程序的设计，并且进行了加强，比如使用了内核提供的沙箱环境运行，这一点在windows上是原生不自带的。
目前大部分服务器产品环境部署方案还是用的apt，大开发商基本都会针对主流发行版提供对应的软件包(rpm、deb)，或者提供软件仓库，比如postgresql、mysql、docker、google-chrome等等。
相关主题 |
