现如今作为linux生态环境最重要一环的应用软件,正在appimage、Canonical和redhat(其实是两位开发者,不是官方推动)的三强争霸赛中,如火如荼的争夺“谁才是linux上的exe”这一地位。目的都是在未来,linux上的软件可以像windows或mac一样,脱离发行版维护打包的现状,可以方便更新软件版本的目的,并且一次打包,可以在任何发行版上运行。
appimage由开发者probonopd领导,号称“Linus已点赞”。技术思路是把所有的应用文件和依赖打包成一个只读的bin格式,也就是说一个文件就是一个应用,优点是下载方便,无需安装直接运行,但是组织比较小,没有大一点的公司去支持,影响力有限。另外还有两个问题,在某些发行版上(例如ubuntu)运行appimage的包会运行不起来,原因竟然是缺少某些依赖,这太讽刺了;appimage也没有统一的软件仓库,
snappy是由Canonical公司提供支持,ubuntu 16.04开始带有的一种新的软件安装方式,其安装包的格式为.snap,后端为snapd,打包工具为snapcraft,原理是在根目录创建一个snap子目录,软件安装后就放在了这个子目录,每个软件都以一个目录形式存在,目录里包含独立的依赖库、应用文件、图标等。canonical还运营管理着一个软件仓库和app store(网页版的,ubuntu手机系统有个软件中心应用)。snappy目前是被控制在canonical手中,ubuntu系统默认安装的snappy源就是官方仓库,要想上传自己打包的应用需要注册账号。当然snappy也支持本地安装.snap包,有个半官方的图形界面叫snapcraft-gui。
flatpak是redhat两位员工创建的项目,和snappy技术原理非常类似,软件以沙盒形式运行,每个软件带有独立的runtime。软件包格式为.flatpak,每个软件厂商或社区可以自己搭建仓库,方便的更新软件版本。Gnome的多数附带软件已可通过flatpak自更新版本(gnome-shell本身不可以)。
KDE也一直考虑如何能够绕过发行版社区,主动让客户在当前kde桌面环境中更新软件,而不必非要等到下一个系统版本。目前,kde重要维护者已经发话,倾向于考虑flatpak,因为snappy控制权在canonical手中,而且snapd对其他发行版支持也不积极(反过来也可以说其他发行版对支持snappy不热情)。并且KDE-flatpak-runtime已经在构建中,有兴趣的朋友可以使用这一runtime做基础,打包kde应用。
appimage由开发者probonopd领导,号称“Linus已点赞”。技术思路是把所有的应用文件和依赖打包成一个只读的bin格式,也就是说一个文件就是一个应用,优点是下载方便,无需安装直接运行,但是组织比较小,没有大一点的公司去支持,影响力有限。另外还有两个问题,在某些发行版上(例如ubuntu)运行appimage的包会运行不起来,原因竟然是缺少某些依赖,这太讽刺了;appimage也没有统一的软件仓库,
snappy是由Canonical公司提供支持,ubuntu 16.04开始带有的一种新的软件安装方式,其安装包的格式为.snap,后端为snapd,打包工具为snapcraft,原理是在根目录创建一个snap子目录,软件安装后就放在了这个子目录,每个软件都以一个目录形式存在,目录里包含独立的依赖库、应用文件、图标等。canonical还运营管理着一个软件仓库和app store(网页版的,ubuntu手机系统有个软件中心应用)。snappy目前是被控制在canonical手中,ubuntu系统默认安装的snappy源就是官方仓库,要想上传自己打包的应用需要注册账号。当然snappy也支持本地安装.snap包,有个半官方的图形界面叫snapcraft-gui。
flatpak是redhat两位员工创建的项目,和snappy技术原理非常类似,软件以沙盒形式运行,每个软件带有独立的runtime。软件包格式为.flatpak,每个软件厂商或社区可以自己搭建仓库,方便的更新软件版本。Gnome的多数附带软件已可通过flatpak自更新版本(gnome-shell本身不可以)。
KDE也一直考虑如何能够绕过发行版社区,主动让客户在当前kde桌面环境中更新软件,而不必非要等到下一个系统版本。目前,kde重要维护者已经发话,倾向于考虑flatpak,因为snappy控制权在canonical手中,而且snapd对其他发行版支持也不积极(反过来也可以说其他发行版对支持snappy不热情)。并且KDE-flatpak-runtime已经在构建中,有兴趣的朋友可以使用这一runtime做基础,打包kde应用。