普通用户只关心我能不能简单使用，置于别的一概不管。

意味着要买大容量硬盘了，硬件要整体升级换代了

这个什么意思？玲珑安装包占用空间更大了？

这个什么意思？玲珑安装包占用空间更大了？

windows系统开始时的应用软件，也是必须要安装才能运行，安装时会向系统目录system下安装很多文件，后来出现绿色应用，把exe文件拷贝过去就可以了。对于linux系统，玲珑软件就是这样的绿色软件，同时还可以支持多种linux发行版，这就是对普通用户的意义。

原本有些依赖是可以共享的，现在每个玲珑包都放1份

其实Deepin社区对于玲珑有过相对比较完整的解释:https://www.deepin.org/zh/deepin-linglong/

我觉得这个答案是最优的,所以提前预订礼品(bushi

玲珑短期对于普通用户在Linux上的感知不会很大(除非遇到依赖问题的),甚至可能运行某些应用会稍微慢0.3-0.5秒,但是对于开发者而言,这是相当利好的消息,从长远角度来看,玲珑也会为用户带来更好的Linux发行版体验。

Linux的应用生态之所以做不起来,就是因为软件包与依赖的绑定关系过强(Linux的软件包如何演化到今天的我从deepin官方摘抄下来介绍:

Linux 操作系统一直以其开源性质和灵活性而闻名，而要使 Linux 系统能够顺利安装并运行所需的软件，最关键的部分就是软件包管理器。

顾名思义，Linux 软件包管理器是一种在 Linux 操作系统上用于安装、更新和卸载软件包的工具。它的历史可以追溯到上世纪 90 年代，此时 Linux 正处于起步阶段，软件的安装必须手动下载源代码并编译，这对非技术用户来说是一项繁琐且困难的任务。

这种情况下，先后催生了 dpkg 和 rpm，然而由于不能自动解决依赖关系，其使用起来依旧不便。

直到 Debian 的 apt、Red Hat 的 up2date 的发布，包管理器可用性有了很大的提升。它们采用了一种被称为“依赖关系解决器”的算法，能够自动解决软件包之间的依赖关系，从而简化软件的安装和升级过程。但这在另一方面大大增加了复杂度，维护者们需要非常谨慎小心地处理，稍有不慎就会陷入“依赖地狱”，导致软件包系统发生故障。

此外，还有许多其他的软件包管理器，如 yum、portage 和 pacman 等。包管理器的多样性给用户带来了更多选择，但缺点也十分显著：它们的软件包无法互通，这意味着一款软件要在其他发行版上使用，可能需要被重复打包。

依赖地狱什么意思,举个还算好的例子,WPS依赖一个名称叫作shenmo、版本号为114513的软件包,没这个对应版本的软件包它不能跑,(注:此时shenmo软件就是WPS的依赖之一);

然后shenmo软件的开发者懵仙兔兔有一天推了版本号为114514的shenmo到了系统仓库,于是系统通知用户更新,于是用户一更新,shenmo软件的版本变成114514,而不是114513,所以WPS就没法跑了,接着开发者直接破防。开发者开发应用要管这个依赖多新那个依赖多新,浪费大量无意义的时间,自然不会投入于Linux开发,这也就是Linux生态疲软的根本原因

于是为了解决这个问题,在Linux内核支持容器化之后,Ubuntu推了Snap,Linux社区推了Flatpak这两个二级包管理器,它们通过一级包管理器(比如dpkg/rpm这些直接与操作系统打交道的包管理器)安装上去,并且以容器化的思想,可以让打包者把应用需要的依赖和对应版本直接加进去,应用运行时直接调用自带依赖就能启动而解决了依赖关系问题;然而,这两者带来了磁盘、内存占用较高,启动时间被不断延长的更严重问题(比如Flatpak安装一些常用的工具时，需要从X的图形驱动开始安装,下载容量动辄几百甚至上千Mb,很多应用随意采用自己做的运行时,导致小软件的体积膨胀能到100多倍,CSDN还有一篇文章专门批Flatpak:https://blog.csdn.net/leopardsaga/article/details/121504580)

在这个背景下,玲珑诞生了,它的工作原理如下(摘抄自Deepin官方文档):

• 应用沙箱 (ll-box) ：按照 OCI 标准设计的应用沙箱运行环境，利用内核 Cgroup、Namespace 特性将应用与宿主机环境隔离，限制系统资源的使用。
• 应用管理服务 (ll-service/ll-cli) ：提供应用沙箱环境创建，系统兼容性问题处理等功能。完成对应用的安装状态/运行状态管理。
• 权限管理代理服务 (ll-dbus-proxy/ll-fuse-proxy) ：提供权限管理功能，包括 DBus 接口以及文件接口。
• 应用构建工具（ll-builder）：提供容器化的应用构建环境，方便开发者在不同的环境上构建出一致性的应用。
• 单独打包格式（uab/AppBundle）：Uniontech Application Bundle，应用包封装格式，提供可直接运行的二进制包格式。
• 仓库系统（ll-repo-server）：提供包上传、下载、信息统计、查询等功能，底层存储使用 OSTree。

玲珑解决了应用容器化的问题不应该吹捧过头,这个问题Flatpak和Snap几年前就解决了,而玲珑真正做到的是同时兼顾了兼容性和应用体积,最简单的例子可以看这位坛友的帖子:https://bbs.deepin.org/post/275545

为什么会那么小?因为玲珑对Runtime严格要求(Runtime就是给应用提供一个基础运行环境),只提供官方给的Runtime(20是deepin v20基础环境,23是deepin v23基础环境),而不是像Flatpak一样从0开始打包,因此不会导致应用胡乱打包自己的Runtime而致使体积疯狂膨胀;而且玲珑的Runtime经过深度优化减小体积,对系统内组件有适当的复用,因此玲珑应用只需要保留应用本体和少部分依赖即可,同时打开速度相比Flatpak和Snap会快很多,占用也会低很多。所以玲珑如果未来着力于运行速度优化,那么我认为玲珑会是Linux二级包管理器的未来,因为相比Windows运行某些软件还会报错缺少VCRuntime/.NET xx版本,玲珑应用速度快的同时依赖全部打包到位,安装完=能正常运行

综上所述,玲珑对于没出现包管理器依赖问题的用户感知不大,但从长远来看,极大方便了开发者开发,同时又不会影响用户对于应用的体验,并且让应用开发更加规范,操作系统更加安全,最终使开发者愿意在Linux平台进行开发,用户愿意使用Linux发行版,Linux生态因此快速发展,而受益于Linux繁荣生态,甩开Windows负优化包袱的还是用户与开发者

其实Deepin社区对于玲珑有过相对比较完整的解释:https://www.deepin.org/zh/deepin-linglong/

我觉得这个答案是最优的,所以提前预订礼品(bushi

玲珑短期对于普通用户在Linux上的感知不会很大(除非遇到依赖问题的),甚至可能运行某些应用会稍微慢0.3-0.5秒,但是对于开发者而言,这是相当利好的消息,从长远角度来看,玲珑也会为用户带来更好的Linux发行版体验。

Linux的应用生态之所以做不起来,就是因为软件包与依赖的绑定关系过强(Linux的软件包如何演化到今天的我从deepin官方摘抄下来介绍:

Linux 操作系统一直以其开源性质和灵活性而闻名，而要使 Linux 系统能够顺利安装并运行所需的软件，最关键的部分就是软件包管理器。

顾名思义，Linux 软件包管理器是一种在 Linux 操作系统上用于安装、更新和卸载软件包的工具。它的历史可以追溯到上世纪 90 年代，此时 Linux 正处于起步阶段，软件的安装必须手动下载源代码并编译，这对非技术用户来说是一项繁琐且困难的任务。

这种情况下，先后催生了 dpkg 和 rpm，然而由于不能自动解决依赖关系，其使用起来依旧不便。

直到 Debian 的 apt、Red Hat 的 up2date 的发布，包管理器可用性有了很大的提升。它们采用了一种被称为“依赖关系解决器”的算法，能够自动解决软件包之间的依赖关系，从而简化软件的安装和升级过程。但这在另一方面大大增加了复杂度，维护者们需要非常谨慎小心地处理，稍有不慎就会陷入“依赖地狱”，导致软件包系统发生故障。

此外，还有许多其他的软件包管理器，如 yum、portage 和 pacman 等。包管理器的多样性给用户带来了更多选择，但缺点也十分显著：它们的软件包无法互通，这意味着一款软件要在其他发行版上使用，可能需要被重复打包。

依赖地狱什么意思,举个还算好的例子,WPS依赖一个名称叫作shenmo、版本号为114513的软件包,没这个对应版本的软件包它不能跑,(注:此时shenmo软件就是WPS的依赖之一);

然后shenmo软件的开发者懵仙兔兔有一天推了版本号为114514的shenmo到了系统仓库,于是系统通知用户更新,于是用户一更新,shenmo软件的版本变成114514,而不是114513,所以WPS就没法跑了,接着开发者直接破防。开发者开发应用要管这个依赖多新那个依赖多新,浪费大量无意义的时间,自然不会投入于Linux开发,这也就是Linux生态疲软的根本原因

于是为了解决这个问题,在Linux内核支持容器化之后,Ubuntu推了Snap,Linux社区推了Flatpak这两个二级包管理器,它们通过一级包管理器(比如dpkg/rpm这些直接与操作系统打交道的包管理器)安装上去,并且以容器化的思想,可以让打包者把应用需要的依赖和对应版本直接加进去,应用运行时直接调用自带依赖就能启动而解决了依赖关系问题;然而,这两者带来了磁盘、内存占用较高,启动时间被不断延长的更严重问题(比如Flatpak安装一些常用的工具时，需要从X的图形驱动开始安装,下载容量动辄几百甚至上千Mb,很多应用随意采用自己做的运行时,导致小软件的体积膨胀能到100多倍,CSDN还有一篇文章专门批Flatpak:https://blog.csdn.net/leopardsaga/article/details/121504580)

在这个背景下,玲珑诞生了,它的工作原理如下(摘抄自Deepin官方文档):

• 应用沙箱 (ll-box) ：按照 OCI 标准设计的应用沙箱运行环境，利用内核 Cgroup、Namespace 特性将应用与宿主机环境隔离，限制系统资源的使用。
• 应用管理服务 (ll-service/ll-cli) ：提供应用沙箱环境创建，系统兼容性问题处理等功能。完成对应用的安装状态/运行状态管理。
• 权限管理代理服务 (ll-dbus-proxy/ll-fuse-proxy) ：提供权限管理功能，包括 DBus 接口以及文件接口。
• 应用构建工具（ll-builder）：提供容器化的应用构建环境，方便开发者在不同的环境上构建出一致性的应用。
• 单独打包格式（uab/AppBundle）：Uniontech Application Bundle，应用包封装格式，提供可直接运行的二进制包格式。
• 仓库系统（ll-repo-server）：提供包上传、下载、信息统计、查询等功能，底层存储使用 OSTree。

玲珑解决了应用容器化的问题不应该吹捧过头,这个问题Flatpak和Snap几年前就解决了,而玲珑真正做到的是同时兼顾了兼容性和应用体积,最简单的例子可以看这位坛友的帖子:https://bbs.deepin.org/post/275545

为什么会那么小?因为玲珑对Runtime严格要求(Runtime就是给应用提供一个基础运行环境),只提供官方给的Runtime(20是deepin v20基础环境,23是deepin v23基础环境),而不是像Flatpak一样从0开始打包,因此不会导致应用胡乱打包自己的Runtime而致使体积疯狂膨胀;而且玲珑的Runtime经过深度优化减小体积,对系统内组件有适当的复用,因此玲珑应用只需要保留应用本体和少部分依赖即可,同时打开速度相比Flatpak和Snap会快很多,占用也会低很多。所以玲珑如果未来着力于运行速度优化,那么我认为玲珑会是Linux二级包管理器的未来,因为相比Windows运行某些软件还会报错缺少VCRuntime/.NET xx版本,玲珑应用速度快的同时依赖全部打包到位,安装完=能正常运行

综上所述,玲珑对于没出现包管理器依赖问题的用户感知不大,但从长远来看,极大方便了开发者开发,同时又不会影响用户对于应用的体验,并且让应用开发更加规范,操作系统更加安全,最终使开发者愿意在Linux平台进行开发,用户愿意使用Linux发行版,Linux生态因此快速发展,而受益于Linux繁荣生态,甩开Windows负优化包袱的还是用户与开发者

你这个举例暗藏玄机