中文 
qiye
deepin
2025-04-25 11:57 deepin 
Reply Like 0 View the author
#1
lyhdzxf
deepin
2025-04-25 12:06 deepin 与楼主有同样的疑惑
高度白
Reply Like 1 View the author
mozixun
2025-04-25 12:07 Moderator
准确地说,如果A和B应用都是玲珑应用,那么你甚至不需要下载依赖9,因为它已经内置在安装包或者Runtime里
Reply Like 1 View the author
克亮
2025-04-25 12:38 Moderator
如意玲珑基于标准化沙箱 Runtime，通过文件共享技术允许多个 Runtime 版本共存，已加载的资源可通过动态库共享复用，应用启动的速度特别的快，避免冲突，应用及其依赖在沙箱内是隔离的，这在一定程度上保护了依赖不被其他应用或系统的变动所影响。
标准化沙箱 Runtime已经包含了常用的基础依赖和桌面常用的库，封包格式为.layer 容量相对比deb 要略大，但是安装速度（如果之前A应用的Runtime 已经安装了，再安装B应用 所需要的相同前提下Runtime 就不用安装，直接安装应用本身-相当于解包释放相应目录） 、卸载应用速度更快（基本上不超过1-2秒）。
玲珑最大的优点就是应用一次构建即可覆盖所有 Linux 发行版。不用担心各版本缺少依赖，或者应用之间安装依赖冲突问题。
目前已经支持如下图，后续会继续适配主流发行版。
Reply Like 2 View the author
qiye deepin
2025-04-25 13:23 deepin mozixun：
准确地说,如果A和B应用都是玲珑应用,那么你甚至不需要下载依赖9,因为它已经内置在安装包或者Runtime里
如此说来，还将所有有的依赖打包在软件中，完全没有必要呀，常用的已经在机器了，还打包那么多做什么？
就如依赖9，作为常用依赖，你还打包做什么？？？
Reply Like 1 View the author
qiye deepin
2025-04-25 13:26 deepin 克亮：
如意玲珑基于标准化沙箱 Runtime，通过文件共享技术允许多个 Runtime 版本共存，已加载的资源可通过动态库共享复用，应用启动的速度特别的快，避免冲突，应用及其依赖在沙箱内是隔离的，这在一定程度上保护了依赖不被其他应用或系统的变动所影响。
标准化沙箱 Runtime已经包含了常用的基础依赖和桌面常用的库，封包格式为.layer 容量相对比deb 要略大，但是安装速度（如果之前A应用的Runtime 已经安装了，再安装B应用 所需要的相同前提下Runtime 就不用安装，直接安装应用本身-相当于解包释放相应目录） 、卸载应用速度更快（基本上不超过1-2秒）。
玲珑最大的优点就是应用一次构建即可覆盖所有 Linux 发行版。不用担心各版本缺少依赖，或者应用之间安装依赖冲突问题。
目前已经支持如下图，后续会继续适配主流发行版。
明白了，所有为什么还要将一个应用的所有依赖都打包做什么？增加下载的时间，增加文件体积？只为解决那极个别没有的依赖？而这些不是普遍使用的依赖不能依靠商店或库的形式解决吗？
不是略大，像坛里那位朋友说的是从100涨到300呀，是倍增。
Reply Like 1 View the author
HualetWang
deepin
2025-04-25 13:33 deepin 楼主提出的改进建议，就是现在 deb 的现状，缺依赖装依赖就行。 看着简单，但是问题很多：
- 依赖不是 A 依赖 B C D， 而是 A 依赖 B C D E F G……， B 可能又依赖 BA BB BC BD… 一个复杂的依赖树，这也是为什么现在的包管理容易出现依赖缺失或者冲突的地方
- 再给每个依赖加上版本的维度……
- 不同发行版使用包管理工具不一致的问题
- 不同发行版可能报名不一样的维度
- ……
玲珑要改进的是 Runtime 包含哪些包能尽量减少上层应用重复下载的问题，以至于拆分不同的 Runtime 扩展包，比如 Runtime.qt Runtime.gtk 之类的。
Reply Like 7 View the author
流星追月
deepin
2025-04-25 14:02 deepin HualetWang：
楼主提出的改进建议，就是现在 deb 的现状，缺依赖装依赖就行。 看着简单，但是问题很多：
- 依赖不是 A 依赖 B C D， 而是 A 依赖 B C D E F G……， B 可能又依赖 BA BB BC BD… 一个复杂的依赖树，这也是为什么现在的包管理容易出现依赖缺失或者冲突的地方
- 再给每个依赖加上版本的维度……
- 不同发行版使用包管理工具不一致的问题
- 不同发行版可能报名不一样的维度
- ……
玲珑要改进的是 Runtime 包含哪些包能尽量减少上层应用重复下载的问题，以至于拆分不同的 Runtime 扩展包，比如 Runtime.qt Runtime.gtk 之类的。
解析的正确到位！
Reply Like 1 View the author
克亮
2025-04-25 15:06 Moderator
qiye：
明白了，所有为什么还要将一个应用的所有依赖都打包做什么？增加下载的时间，增加文件体积？只为解决那极个别没有的依赖？而这些不是普遍使用的依赖不能依靠商店或库的形式解决吗？
不是略大，像坛里那位朋友说的是从100涨到300呀，是倍增。
关于容量的倍增的问题 一个是 基础包压缩比 ，deb安装完毕后所占用的磁盘空间未必会小，只是可以直接拉取系统库里面的依赖，如果依赖比较多，安装过程可能会久一点。玲珑包是 runtime 自身库+依赖 +应用包元数据加应用依赖 然后再压缩格式成玲珑包，安装释放容量肯定也会变大。
目前针对容量问题，貌似已经有非常大的优化。
估计下一阶段玲珑包的会比现阶段小的多。
Reply Like 1 View the author
qiye deepin
2025-04-25 15:15 deepin HualetWang：
楼主提出的改进建议，就是现在 deb 的现状，缺依赖装依赖就行。 看着简单，但是问题很多：
- 依赖不是 A 依赖 B C D， 而是 A 依赖 B C D E F G……， B 可能又依赖 BA BB BC BD… 一个复杂的依赖树，这也是为什么现在的包管理容易出现依赖缺失或者冲突的地方
- 再给每个依赖加上版本的维度……
- 不同发行版使用包管理工具不一致的问题
- 不同发行版可能报名不一样的维度
- ……
玲珑要改进的是 Runtime 包含哪些包能尽量减少上层应用重复下载的问题，以至于拆分不同的 Runtime 扩展包，比如 Runtime.qt Runtime.gtk 之类的。
我的天呀，这么麻烦，这就是大家所说的linux碎块化吗？果然够碎呀。
唉，linux发展真容易，有种想全当垃圾处理重新建房的冲动了。（当然，那样的困难更加不可想像。）
Reply Like 0 View the author
把一切操作变成GUI
deepin
2025-04-25 16:49 deepin Backbone of ecological co-construction group
相比于硬盘空间，你觉得用户宁愿占用点空间节省下载依赖的麻烦，还是说自己手动下载依赖还不一定成功呢？
而且储存成本都已经逐渐降低了。
相比于带宽和用户时间来说，硬盘成本算是最低了的。
有人说把常用的依赖都装在系统里面就好，你知道华为的openeuler系统包吗，24GB。
Reply Like 3 View the author
qiye deepin
2025-04-25 16:55 deepin 把一切操作变成GUI：
相比于硬盘空间，你觉得用户宁愿占用点空间节省下载依赖的麻烦，还是说自己手动下载依赖还不一定成功呢？
而且储存成本都已经逐渐降低了。
相比于带宽和用户时间来说，硬盘成本算是最低了的。
有人说把常用的依赖都装在系统里面就好，你知道华为的openeuler系统包吗，24GB。
你说的对。
Reply Like 0 View the author
玄圭SwenGway deepin
2025-04-25 18:38 deepin 玲珑确实不错，继续努力
Reply Like 0 View the author
mozixun
2025-04-25 20:31 Moderator
qiye：
明白了，所有为什么还要将一个应用的所有依赖都打包做什么？增加下载的时间，增加文件体积？只为解决那极个别没有的依赖？而这些不是普遍使用的依赖不能依靠商店或库的形式解决吗？
不是略大，像坛里那位朋友说的是从100涨到300呀，是倍增。
不是打包GTK+AppImage类似把跨平台图形框架内嵌的应用,不会遇到体积骤增的情况
Reply Like 0 View the author
mozixun
2025-04-25 20:33 Moderator
qiye：
明白了，所有为什么还要将一个应用的所有依赖都打包做什么？增加下载的时间，增加文件体积？只为解决那极个别没有的依赖？而这些不是普遍使用的依赖不能依靠商店或库的形式解决吗？
不是略大，像坛里那位朋友说的是从100涨到300呀，是倍增。
大部分依赖已经集成在Runtime里,应用不需要再进行集成,应用需要内置的是需要特定版本依赖的
Reply Like 0 View the author
mozixun
2025-04-25 20:39 Moderator
克亮：
关于容量的倍增的问题 一个是 基础包压缩比 ，deb安装完毕后所占用的磁盘空间未必会小，只是可以直接拉取系统库里面的依赖，如果依赖比较多，安装过程可能会久一点。玲珑包是 runtime 自身库+依赖 +应用包元数据加应用依赖 然后再压缩格式成玲珑包，安装释放容量肯定也会变大。
目前针对容量问题，貌似已经有非常大的优化。
估计下一阶段玲珑包的会比现阶段小的多。
这个不是对比对象,只是玲珑导出layer的时候默认没7z压缩,经过7z压缩跟deb包差不多,除了GIMP一类需要自带GTK运行库的
Reply Like 0 View the author
mozixun
2025-04-25 22:48 Moderator
玄圭SwenGway：
玲珑确实不错，继续努力
你用time命令对比一下同一款软件的启动速度就晓得了
Reply Like 1 View the author
玄圭SwenGway deepin
2025-04-26 08:24 deepin mozixun：
你用time命令对比一下同一款软件的启动速度就晓得了
不过毕竟使用了沙盒，deb直接启动，理论上玲珑的速度应该比不上deb包，不过这两者侧重点不同，也不能直接比较
Reply Like 0 View the author
mozixun
2025-04-26 11:11 Moderator
玄圭SwenGway：
不过毕竟使用了沙盒，deb直接启动，理论上玲珑的速度应该比不上deb包，不过这两者侧重点不同，也不能直接比较
不一定,因为本质上都是加载一些库,以我又测试的QQNT为例:
直接命令启动:
启动玲珑版:
因为玲珑的base极限精简过,几乎就没慢多少
Reply Like 2 View the author
Please sign in first
Popular Ranking
Change
install zfs on upgraded v23.1 Popular Events
More
用deepin有些日子，时常听到对玲珑的讨论，也吃了不少玲珑的苦果，今天看到坛里有人说GIMP3的deb包很小，但玲珑包很大，下面有朋友回复说是因为玲珑包包括了相关的依赖，确实，在我在安装一些deb包时遇到了依赖不足，无法安装的问题。但是作为外行，我不知道如何去安装这些依赖。所以从这方面来说玲珑好象确实不错。但爆增的包在下载时确实有些影响，特别是在一下网速不好时，反正我经常因为下载速度慢，文件体积大放弃过下载和安装。
所以想问一下，玲珑包不能不包含那些依赖，在安装之时检测到依赖不足时引导用户去商店下载相关的依赖吗？是技术上有难题吗？
此外，我也了解到玲珑的包的依赖安装后是独立的，不会因其他应用的问题相互产生破坏，这里我也好奇，这些依赖不能保护起来吗？磐石这个时候应该起关键作用了吧。
说真白点吧，假定依赖有十种，A和B都要用上第9种，在安装A时会引导去商店下载9号依赖，B安装时就不用去下载了，而9号依赖下载后就受磐石保护，所以不管是删除A和B那一个都不会删除9号依赖，应该也就不会影响A和B了吧，当A和B应用都从系统删除时，9号依赖会跟着最后一个要使用到它的应用的删除而自动删除。
以上假设有很大难度吗？是依赖种类太多？还是技术上不能实现呢？不知有没有高手可以解惑，纯外行小白百思不得其解的问题，说的不对的地方就谅解。