深入探索“玲珑”（一）：玲珑方案的创造
<p class="md-end-block md-p"><span class="md-plain md-expand">各位伙伴们，之前我们已经对玲珑包格式的诞生、特性进行了完整的介绍，让这一独立创新的全新包格式与大家初次见面。</span></p><p class="md-end-block md-p"><span class="md-plain">而在接下来的一系列文章中，我们将带大家深入挖掘玲珑包格式的更多内容，着重向大家介绍传统包管理的问题，以及我们是如何吸取了主流通用独立包格式的优秀思路，创造了“玲珑方案”。</span></p>
<p><img class="alignnone size-medium" src="https://storage.deepin.org/thread/20220829095235277_玲珑1.jpg" width="900" height="383" /></p>
<p class="md-end-block md-p"><span class="md-pair-s"><strong><span class="md-plain">传统包管理问题</span></strong></span></p>
<p class="md-end-block md-p"><span class="md-plain">第一，不同发行版维护成本高</span><span class="md-pair-s "><strong><span class="md-plain">。</span></strong></span><span class="md-plain">由于deb与rpm这两种包格式完全分割，开发者需要针对不同发行版单独构建和维护包。 </span></p>
<p class="md-end-block md-p"><span class="md-plain">第二，兼容性问题难以解决。deb与rpm均属于强依赖性的包管理系统，同时允许各个组件之间有 </span></p>
<p class="md-end-block md-p"><span class="md-plain">复杂的交叉依赖（或循环依赖）关系。这使得维护包管理系统需要极强的专业知识，稍有不甚， 就会导致系统彻底故障，很难修复。系统升级有几率会导致应用依赖关系被破坏，从而引发兼容性问题。</span></p>
<p class="md-end-block md-p"><span class="md-plain">第三，安全性难以把控。传统linux系统下的包管理更面向系统管理员而非应用开发者和使用者，给予了包更多对系统的修改权限，应用开发者容易在不熟悉系统的情况下埋下较多安全隐患。</span></p>
<p class="md-end-block md-p"><span class="md-pair-s"><strong><span class="md-plain">选择解决方案</span></strong></span></p>
<p class="md-end-block md-p"><span class="md-plain">面对以上传统包管理的问题，业界已经有了一些通用独立包格式的解决方案。通用独立包格式致力于帮助开发者在所有Linux发行版运行同一个版本的应用。为了实现这个目的，它们会将系统与应用进行隔离，于是封装了一个独立于系统的运行环境，应用不再依赖于操作系统本身提供的运行环境。另外，通用独立包格式也在努力增强安全性，通常它们会使用“沙箱”来将应用与宿主机进行隔离，防止恶意程序携带的病毒感染整个系统。</span></p>
<p class="md-end-block md-p"><span class="md-plain">然而，这个方案也存在一些问题：通用软件包格式为了让应用独立于操作系统，从而封装了依赖关系到单独的运行环境，势必会造成应用体积变大。且为了保证通用性，需要一个庞大的运行时环境，对磁盘空间占用则会更多。对于应用来说同样存在这个问题，应用需要将部分独有的依赖加入到应用自身，会使得软件大小会比传统包格式更大，对于性能也有所损耗。</span></p>
<p class="md-end-block md-p"><span class="md-plain">另外，安全性上也有待加强。比如部分独立包格式的解决方案以root权限启动沙箱，会留下各种提权攻击的隐患，从而可能引发安全问题。 </span></p>
<p class="md-end-block md-p"><span class="md-pair-s"><strong><span class="md-plain">玲珑方案</span></strong></span></p>
<p class="md-end-block md-p md-focus"><span class="md-plain md-expand">玲珑，为兼容与安全而生。玲珑致力于治理Linux系统下传统软件包格式依赖关系复杂导致的各种兼容性问题，以及过于松散的权限管控导致的安全风险。</span></p>
<p class="md-end-block md-p"><span class="md-pair-s "><strong><span class="md-plain">在技术方案的选择上，</span></strong></span><span class="md-plain">我们吸取了主流通用独立包格式的优秀思路，将应用/运行时/系统环境进行分层管理，将应用的运行依赖独立出来构建出一个较为通用的runtime，且提供了完善的机制，支持发行版针对runtime进行深度优化，兼顾通用与轻量化，避免过多占用磁盘空间和影响性能。同时，采用“沙箱”的容器化机制运行应用，将应用与系统进行隔离，减少应用对系统造成破坏的可能性。另外，默认限制“沙箱”的root权限，防止应用运行时可获取过高权限，减少用户数据被损害的风险。 </span></p>
<p class="md-end-block md-p"><span class="md-pair-s "><strong><span class="md-plain">在软件分发方面，</span></strong></span><span class="md-plain">玲珑支持增量在线分发，同时也可支持bundle格式进行离线分发。离线分发时，无需安装应用即可双击直接运行，无需卸载应用，直接删除包文件即可，使用非常方便。 </span></p>
<p class="md-end-block md-p"><span class="md-plain md-expand">以上是历史包管理的问题及玲珑方案的介绍。在后续的两章内容中，我们将会进一步对玲珑组件、权限管理机制进行解读，敬请期待！</span></p>
</div> 看完这篇深度解析，不得不说玲珑方案确实针对当前Linux包管理的痛点提出了很有针对性的解决思路。
有几个地方让我比较感兴趣：
关于分层管理这块，感觉是个很聪明的做法。既要通用性又要轻量化确实不容易，你们提到的支持发行版针对runtime进行深度优化这个机制感觉很有弹性。
增量分发和离线bundle这两个特性也很实用。特别是离线分发可以直接双击运行这点，对于普通用户来说确实降低了使用门槛。
不过我有个小疑问：沙箱限制root权限这个设计确实能提升安全性，但在实际使用中会不会影响到某些需要特殊权限的专业应用？比如图像处理、视频编辑这类软件可能确实需要调用一些系统底层功能。
另外想请教一下，玲珑的runtime优化机制具体是怎么实现的？不同发行版在优化时需要遵循什么样的规范吗？
期待后续关于组件和权限管理机制的解读！这种技术科普性质的系列文章很有价值。
頁:
[1]