ARU里linuxqq大家都用哪个啊？
archlinux wiki中有linuxqq 和linuxqq-nt-bwrap
这个你看两个包在AUR的票数(Votes)也就知道了
票数越高越受欢迎
目前
linuxqq-nt-bwrap的票数是49
linuxqq是111
显然linuxqq更受欢迎
另一个可参考的字段是Popularity, 表示最近的热度
linuxqq-nt-bwrap是0.30
linuxqq是0.81
我用的linuxqq-appimage，仅250M包体比较省空间
Bwrap结尾的包套了一层轻量化容器，可以避免qq任意读文件之类的，linuxqq 没做任何别的操作，就只运行原始二进制文件了。选哪个看你需求吧
AppImage 格式的优点不是轻量, 他的优点是便携
为了实现便携, 他会打包许多依赖, 所以更重, 而且更慢一点
而linuxqq因为使用系统库, 所以更轻, 更快一点
启动速度稍慢一点，但确实轻量省空间，比标准包体小很多，也无需考虑依赖 Flatpak/snap同样无需考虑依赖问题，但空间占用比标准包大
❮ pacman -Qi linuxqq-appimage
Installed From : 无
名字 : linuxqq-appimage
版本 : 3.2.33_20260902-1
描述 : New Linux QQ based on Electron
架构 : x86_64
URL : https://im.qq.com/linuxqq/
软件许可 : custom
组 : 无
提供 : qq linuxqq
依赖于 : zlib hicolor-icon-theme fuse2
可选依赖 : 无
依赖它 : 无
被可选依赖 : 无
与它冲突 : linuxqq linuxqq-nt-bwrap
取代 : 无
安装后大小 : 258.62 MiB
打包者 : Unknown Packager
编译日期 : 2026年09月02日 星期三 18时43分08秒
安装日期 : 2026年09月02日 星期三 18时43分13秒
安装原因 : 单独指定安装
安装脚本 : 否
验证者 : 无
这两句话感觉逻辑上有点冲突……AppImage 的体积，到底是比标准包大还是小？
去官网下了 QQ Linux 的 3.2.34 版，情况如下：
| 打包格式 | 包文件大小 | 包解压后大小 |
|---|---|---|
.AppImage |
271.4 MB | 639.1 MB |
.deb |
187.2 MB | 638.8 MB |
他的意思应该是: AppImage比标准包更小, Flatpak/snap 比标准版包更大
懂了，这两句话应该是连着的：
个人认为，最好的说法应该是：
也无需考虑依赖 Flatpak/snap，它们同样无需考虑依赖问题，但空间占用比标准包大
补充一个主语，可避免歧义。
这个对比是不合理的
AppImage不会被解压, 实际占用大小是AppImage文件本身的大小
运行时也是以挂载的形式, 不会解压
确实。我这里给出的 "解压后大小"，是执行 [appimage文件名] --appimage-extract 后释放的全部文件的大小。
AppImage 正常运行时确实不需要释放文件。那么 AppImage 应用运行时的性能损失，可能就是来自 AppImage 软件包的压缩算法？
好吧, 是我着急回复, 没有确认, 导致判断出错了 :-)
软件包 (1) linuxqq-5:3.2.34_53644-1
全部安装大小： 623.63 MiB
软件包 (1) linuxqq-appimage-3.2.34_20260924-1
全部安装大小： 258.81 MiB
确实占用空间更小
是一部分, 但更大的影响来自 FUSE 本身
对于不同软件会有不一样的结果。
对于商业闭源软件来说，自带了一堆自己的依赖库（特定版本、修改版本或者静态链接），所以不管怎么打包都无法与系统中的包共享，依旧那么大。
对于开源软件来说，通常它们可以使用系统提供的共享库，能够与其它软件共享依赖，减少重复数据，因此本体会更小。
其实这么比较不合理——要么都比较压缩前的大小，要么都比较压缩后的大小。一个有压缩一个没压缩，这样对比不公平。
我觉得比较安装后大小没什么问题, 因为我们看的就是这个
压缩与不压缩是两个包的特性区别
我们做这个比较只是为了看看哪个包占用的空间更小, 以便在不同情景使用
例如在空间有限的设备使用linuxqq-appimage而不是linuxqq
如果这样比较的话, 对于我们来说, 这个比较结果没有帮助
但比较安装后大小对我们有帮助
那你的对比很不完整——代价是什么呢？
你不要忘记了有些文件系统支持透明压缩。
这个不是他的疑问, 而是他不清楚square想要表达的意思是AppImage 的体积比标准包大还是AppImage 的体积比标准包小
他的疑问是square的表述, 而不是 AppImage 的体积
哦这样。我没觉得square用户表达的意思有歧义所以后续理解错了……
还有什么是没提及的吗?
性能损失已经提到了
有文件系统支持透明压缩不代表这个比较结果没有意义
如果用户的文件系统是ext4, 并且不打算更换btrfs, 那么这个结果就对他有帮助