本文会比较详细地描述玲珑是什么,它诞生的背景和它要解决的问题

文章参考了deepin官方对玲珑的大致介绍:https://www.deepin.org/zh/deepin-linglong/

玲珑诞生的背景

众所周知,计算机安装软件,都需要一个类似助理的系统组件,如同Windows的应用与功能选项,告诉用户这台电脑"装了什么软件",能让用户"卸载这个软件",运行安装程序后还能识别"升级了这个软件",这样用户才能顺利安装/卸载/升级软件

但是在远古的Linux发行版,由于没有很好的GUI支持,安装软件靠的是先下载.tar源码文件,解压并进入文件夹,在超级用户权限下输入make install先编译再安装,输入make uninstall才能卸载。这对非技术用户来说是一项几乎不可能完成的任务。

于是在这个背景下,dpkg/rpm/pacman这一类一级包管理器诞生了:

一级包管理器的诞生

软件包(package)（LCTT 译注：下文简称“包”）这个概念是用来解决在软件安装、升级过程中的复杂性的。包将软件安装升级中需要的多个数据文件合并成一个单独的文件，这将便于传输和（通过压缩文件来）减小存储空间（LCTT 译注：减少存储空间这一点在现在已经不再重要），包中的二进制可执行文件(就是程序文件)已根据开发者所选择的编译标识预编译。包本身包括了所有需要的元数据，如软件的名字、软件的说明、版本号，以及要运行这个软件所需要的依赖包等等。

这些一级包管理器负责将开发者已经编译好的程序中对应路径的二进制文件放到对应的目录下(比如安装QQ,需要把编译好的QQ程序文件放置到/opt/QQ下,于是dpkg在安装QQ软件包的时候就会按照开发者写好的路径将安装包中的程序文件自动放到/opt/QQ目录下),于是安装软件就变得很简单

但这又带来一个问题,比如有个A软件需要.NET 4.5版本而不是5.0或者6.0,而安装.NET也要像A软件一样又需要别的组件才能运行,安装软件的时候会发生:

于是dpkg/rpm这些又专门发明了一个叫"依赖关系解决器"的功能,以dpkg的.deb软件包为例,开发者在debian/control文件中写入这个包和谁冲突,依赖谁,然后dpkg就可以在应用安装时先检查这个应用和它所需要的组件会不会和计算机现有的系统与应用组件产生冲突,如果有问题就会像上图一样进行报错,但即使如此面对这种情况时光有dpkg会心有余而力不足:

接着再去安装别的依赖又发现

所以apt/yum/dnf这些工具随即出现,它们的作用是与dpkg/rpm等一级包管理器搭配,从对应的软件仓库直接下载安装目标应用需要的所有依赖,而不需要开启浏览器去一个个专门查询和下载,紧接着就产生了"黄金搭档":apt和dpkg专门管理.deb格式的安装包;yum/dnf跟rpm专门管理.rpm格式的应用包,让应用安装变得更加方便

一级包管理器遇到的问题

但dpkg等包管理器因为使用依赖关系解决器又会带来三个严重的问题,举个简单的例子:1.有一个叫XXX的软件依赖一个叫作shenmo且版本为99的软件,接着用户又需要一个叫作YYY的软件,而YYY软件依赖shenmo软件,但是版本为100;由于dpkg安装软件时是直接放置程序文件进入系统目录,故只能安装shenmo的一个版本,而产生用了XXX就不能用YYY,用了YYY就不能用XXX的尴尬处境

2.比如有个叫作爱兔兔的软件,依赖一个版本为113,名称叫作xserver的软件,而且依赖软件不能升级,一升级软件就炸;结果有一天,xserver依赖的开发者Gfdgd_xi灵感大爆发,改了一大堆代码并推送了114版本,同样由于dpkg是直接放置程序文件进系统目录,所以只能安装xserver的一个版本,最终导致用户一升级xserver软件,然后爱兔兔就打不开了,这两个问题也就是所谓的"依赖地狱"的其中一面

3.dpkg安装.deb时必须使用超级用户执行安装脚本,如果有个黑商在脚本里加一条

rm -rf /*  

那整个系统会直接报废

因此对于开发者而言,开发者要时刻关注依赖的更新与代码提交,用户每天使用系统心惊胆战生怕一个组件一更新就有软件打不开,自然用户不会愿意使用Linux发行版,开发者也不愿意把精力花在Linux发行版上,自然Linux发行版应用生态停滞不前

二级包管理器的诞生

于是为了解决这个问题,在Linux内核支持容器化技术之后,新型二级包管理器Flatpak和Snap由此诞生:这类格式的软件包与系统环境几乎完全解耦，不再依赖系统上的库文件（AppImage 也是如此），应用分发开始逐步变得简单起来。--来自:https://www.deepin.org/zh/deepin-linglong

通俗地讲,就是Flatpak和Snap跑的应用里又有一番天地:开发者在二级包管理器的规范下打包,可以为应用"定制"一个子操作系统级别的运行环境(叫作Runtime),可以防止应用因为系统底层太新而崩溃,又能加入应用运行所需要的依赖以及各种版本,其详细原理如下图:

这样就不用担心系统和组件升级带来应用崩溃的问题,而且Flatpak不允许应用以root权限运行而使应用运行更加安全

二级包管理器当前的问题

但是像二级包管理器容器化分发应用又带来了更加严重的问题:1.磁盘IO和运行内存占用高 2.应用打开的速度被一拖再拖 3.开发者乱打包Runtime:你一个Runtime我一个Runtime,于是装了几个小软件磁盘空间却占用了N个GB,因为都装Runtime去了(Flatpak甚至需要从XServer/Wayland Client驱动开始打包,于是打包出来的应用体积不一定大,但是各种Runtime一加体积原地爆炸,比如:

其实一个KCalc的大小只有3MB不到,但是它要的Runtime环境却需要足足1GB多,而且这个Runtime只能给KDE的套件用,别的应用还要再下别的!

再加上缓慢的运行速度(后图有),因此有人狠批Flatpak和Snap:https://blog.csdn.net/leopardsaga/article/details/121504580

如果Linux发行版运行应用要如此臃肿,那么为什么不直接用Windows一步到位?

于是在这个背景下玲珑应运而生

---

玲珑要解决什么问题?

(玲珑工作原理)

玲珑就是如同Flatpak/Snap一类的二级包管理器(其实玲珑在介绍时有失偏颇,玲珑目标不是取代dpkg,而是让通过dpkg安装但是与操作系统却毫无关联的应用可以跨发行版运行),玲珑的目标是1.解决二级包管理器应用体积过度膨胀,Runtime乱用导致占用过度膨胀、应用打开速度过慢的问题 2.解决应用安装时权限过大问题,严格规范应用权限 3.解决应用运行依赖问题

1.玲珑统一发布Runtime(20和23两种版本,20就是deepin v20子运行环境,23就是deepin v23子运行环境),而极大缩减应用所需Runtime在磁盘的占用

2.玲珑对Runtime深度优化,对Runtime里一些无关应用的组件进行剔除而减少Runtime体积并提升应用打开速度,同时开发者能直接基于现有Runtime开发更加省力

3.跨发行版的支持始终是玲珑的重要任务之一,玲珑目前对于跨发行版有着不错的支持

玲珑的应用性能测试有如下数据:

玲珑的诞生和改进将带来什么

玲珑包管理器将会真正实现应用安装=能打开,极大改进容器化应用打开的速度;给用户带来更加稳定快速的体验;让应用更易于打包与分发,给开发者带来便捷的应用开发体验,极大推进Linux应用生态建设,为操作系统国产化与Linux社区项目添砖加瓦,造就Linux发行版更好的未来!