说到Ubuntu的Snap包，这可真是个让Linux社区又爱又恨的话题。记得我第一次在Ubuntu 20.04上遇到Snap应用启动慢的问题时，还以为是自己的机器出了问题，后来才发现这是Snap包普遍存在的”特色”。不得不说，Canonical推动Snap的初衷是好的——解决依赖地狱问题、实现跨发行版部署，但实际落地时却引发了不少争议。
性能问题首当其冲
Snap应用的启动速度慢得让人抓狂，特别是第一次运行时。我测试过，同一个Chromium浏览器，Snap版启动要3-4秒，而deb包版本基本秒开。这个问题在机械硬盘上更明显，因为Snap包默认会被解压到只读的squashfs文件系统中运行，每次启动都要经历挂载过程。
更让人不解的是，Canonical居然把一些关键系统组件也变成了Snap包。还记得去年系统更新后，我的Ubuntu服务器上的网络管理工具莫名其妙变成了snap版的network-manager，结果导致一堆自定义配置失效，折腾了半天才搞明白原因。
强制推广引发不满
最让老用户反感的是Canonical的”强制”策略。从Ubuntu 20.04开始，apt install chromium-browser会默认安装Snap版本，这操作简直像是在耍小聪明。社区里有人挖出代码发现，apt居然被修改成了会偷偷将deb请求转成snap安装的”特洛伊木马”。
更夸张的是，连最基本的命令行工具如htop、vim也开始被Snap化。我在一台服务器上通过apt安装vim，结果得到的居然是snap包，这完全违背了Linux用户对包管理器的信任预期。
沙箱安全的两面性
理论上说，Snap的强制沙箱机制能提升安全性，但在实际使用中却带来了不少麻烦。比如，Snap版的Firefox默认无法访问/home目录下的文件，要上传附件时才发现没权限，得先通过snap connect命令授权。
有些应用的沙箱配置更离谱——我遇到过Snap版的Spotify无法访问蓝牙设备，而deb版完全正常。这种”过度保护”导致用户得花大量时间研究snap权限系统，反而降低了易用性。
社区生态的分裂
最令人担忧的是，Snap正在造成Ubuntu生态的分裂。Canonical掌控着唯一的Snap商店，这与Linux世界崇尚的开源精神背道而驰。相比之下，Flatpak虽然也是容器化方案，但至少允许用户自建仓库。
有趣的是，现在很多Ubuntu衍生版如Linux Mint，都在主动移除Snap支持。我认识的一位系统管理员甚至专门写了脚本，用来在新装Ubuntu上彻底清除所有Snap组件，这足以说明社区对Snap的不满程度。
说到底，Snap的技术理念并不差，问题出在Canonical的推广方式太过强硬。如果当初能保持deb和snap的平等竞争，让用户自由选择，可能就不会引发这么多争议了。现在每次Ubuntu更新，我都要提心吊胆，生怕又有什么重要组件被偷偷换成了Snap版本…
评论