“依赖艺术”是Linux桌面端软件长期混乱难用的根源- Community

[Feelings & Sharing] “依赖艺术”是Linux桌面端软件长期混乱难用的根源

deepin Talks 1226 views · 6 replies ·

dpusr0248

deepin

2023-08-08 19:06

Author

Linux 安装软件有4种方式，按易用程度排序：

包管理器，apt/yum 等，可以自动解决查找、安装、卸载包的依赖，对已安装的包进行管理，是最常用最强大的方式；
本地 rpm/deb 等安装包，包内脚本会注明依赖条件，方便自动安装，或者自带依赖，甚至有二进制包，解压即用。但缺少打包和开发规范，无法和 msi 或 exe 相提并论；
二进制，等同于 Windows 的“绿色软件”，无需安装，即开即用，然而缺点也和 Windows 上一样，不便管理；
源码编译。普通用户一般不会安装开发环境，无法编译源码。

可见，唯一需要讨论的就是包管理器。为什么这么多年了，强大的包管理器依然无法解决依赖问题，让无数 Linux “用户” 头疼？大概有如下几个原因：

软件源由发行版维护者管理，可以说所有的包都是维护者通过统一渠道二次发行的，因此他们有意愿也有能力去玩“依赖艺术”，而 Windows 上软件来源无法预知，Windows 也无法管理包的依赖，因此也不可能有系统级的依赖管理；
Windows 上的软件多是商业软件，不可能交给用户去解决依赖，软件商必须在发行时就已经解决所有问题；自由软件的开发者和用户无法产生这种需求。
Linux 哲学，每个包只用一份。

包管理器是广泛存在的技术，比如编程语言很多都有包机制，也就有包管理，Java，Go，JS 有 npm，Python 有 pip，C# 也有 NuGet，各有特色。
Go 和 Java 会把引用的包全部编译进去，除非声明为外部引用。
Python 无法管理多版本，开发者必须自己想办法减少依赖特定版本，用户往往也无法解决。
NuGet 具有强制名称，每个包不同版本的名称不同，发行时可以严格指定版本，不会产生多版本依赖问题。

那为什么这些编程语言各式各样的包管理，就是可接受的呢？

对编程语言来说，包管理是一种技术，也是一种面向用户（软件开发者）的可选的产品特性。而对 Linux 来说，包管理仅仅是一种哲学、一种艺术，无需面向任何用户，连很多开发者都感到畏惧，只有非常强大的 Linux 研究者才能驾驭它。虽然已经想出了 AppImage、Flatpak、Snap 等方案，然而它们本身也只是 Linux 哲学的产物，只是对包管理器的一个补充，不是也不可能是包管理器的替代品，这是它们无法普及的重要原因。

综上，Linux 桌面端软件混乱难用的根本问题就在于没有系统级产品级的软件包方案，让商业开发者和用户都很迷茫。

最后从这一点上讲，玲珑是有前途的，无论使用、管理还是文档，都显示出产品级软件的前景，希望将来能做成好用实用的桌面端 Linux 应用商店。

更新：

我的文笔不太好，确实没有突出重点。我无意批评包管理器，也肯定了它的价值，但重点是“产品”。什么是产品呢？我想一句话总结就是“你敢教用户做事？”，确实只要提高自己的见识和能力，就能把 Linux 运用地更好，但这是对我们这些“专业”的人而言。对普通用户，别说去钻研，根本就不想知道任何技术细节，比如 Windows 安装已经非常傻瓜化，大量的提示和下一步，然而生活中会装的人有很多吗？

从“专业用户”的角度去考虑，是做 Linux 软件必须要摒弃的一种思维，普通用户的思维应该是什么样呢，应该是：看到 Linux 用户输入了 ls，然后“我去，还要输命令，太高深了，我永远也学不会”。

因此，我不会希望玲珑变成 apt/yum，更不要是 flatpak，appimage。为什么我说玲珑有产品级的前景，就是因为我看到它和真正的应用商店一样，就要查找安装卸载更新打开4个功能，别的什么东西也别显示，也别教我，我作为用户压根不想知道。

以上。

Reply Like 1 Favorite View the author

All Replies

铁山老道孔乙己

deepin

2023-08-08 19:37

Windows 是单独一家公司发行的，所以兼容性好。而 Linux 有大大小小的公司或者民间组织，甚至是个人发行的，没法统一。
这和哲学，或者技术没有关系，和组织模式有关系。
如果你使用 ubuntu 或者 debian 这些大的发行版，而且只从官方源获取软件，那么这些都不是问题。

Reply Like 3 View the author

盘灶车站

deepin

2023-08-08 19:47

铁山老道孔乙己：

Reply Like 0 View the author

depend

deepin

2023-08-08 19:48

赞同，linux的包有很多由社区维护上传的，部分可能存在频繁更改接口之类的，导致兼容性很差，不能像windows出标准的windows底层依赖库，

在玩了这么多类别的linux，会发现debian系列的命令始终很有魅力，用户基数也是最庞大的，包管理机制已经被大家熟悉和使用。

容器的类别我认为flatpak ,snap和玲珑应该归为一类，很相似，都是有容器沙箱的机制，在flatpak和snap发展了这么久没有什么起色，我感觉很一般，我认为玲珑的前景也不是很看好(毕竟flatpak和snap的前面发展的也一般，当然仅为个人看法)。

然后是appimage，appimage在介绍中提到了他是借鉴mac的包形式的一种包，但是我认为他有点像windows的包管理机制，打上依赖进行分发，只是是放在一个压缩包里面，使用的是哦户再挂载到tmp文件夹下的，对于商业公司，我认为他是目前较为适合的分发用法，缺陷:由于glibc的原因，都是低支持高，所以，推荐都是需要在很低版本的发行版下面打包，ubuntu16打包， 18 20能用，但在20打包，18 16都不能用，就这样，但面对日新月异的开发环境，却必须依赖很低版本的发行版打包，是一个较大的缺陷，我认为。

对于"Linux 安装软件有4种方式，按易用程度排序：",其实在作者认为最难的源码编译的形式，其实有一个包管理分支是arch的aur，aur的几乎大部分软件都依赖于源码编译，比如 yay -S 软件名称，其实是去下载该软件的源码，安装对应的依赖，进行编译到你的电脑，也是较为流行的方案(缺陷就是对于debian这类的需要稳定的电脑不太适合，因为需要最新的依赖，arch是滚动发行，所以没啥问题)，还有个缺点就是几乎这种形式就只能是开源软件来分发了，对商业软件不友好，毕竟不会提供源码。

我认为arch的命令始终是用起来没有debian的顺手，但是包管理机制，aur和appimage算是眼前一亮，但是不足都很明显，windows还是很优秀

Reply Like 2 View the author

enforcee

deepin

2023-08-08 21:08

要是没有包管理器，一个软件都别想运行

必须强制要求打包者遵守规范，软件的发布才有足够的质量；否则就是各自为政，出现只管杀不管埋或者肆意掠夺系统资源的现象。

一个软件进入系统，用户至少对他有三个期望：能安装、能运行、能卸载。软件包的依赖关系正是应对这种需求才出现的。通过安装时同时安装依赖软件包和卸载时标注不需要的软件包，包管理器尽量保证能够安装的软件就是可以运行的：能够安装的软件可以删除并且尽量让系统能恢复到之前的状态。而Windows上在各方面做得都不好，能安装的软件不一定能运行，也不一定能无痛卸载；Windows安装时确实可以自己解决依赖，但是卸载时这些多余的依赖也无法判断是否有必要留在系统上；另一方面Windows虽然有自己的包格式msi，但是开发者不愿意用，而是自己设计的五花八门的安装程序、卸载程序来代替，由于这些程序都需要修改系统目录，需要使用较高权限，并且难以预测他到底在做什么，有没有携带恶意软件，因此让系统不稳定，并带来安全隐患。

诚然各种发行版的包管理系统有各种优点，但是他也存在一些缺陷。其实可以说正是由于他太「精密」，所以反向造成了一些困境。系统软件源通常是专业的开发者所规范的，通常不会有问题，但是如果往系统中安装一些外来的质量不高或是并非为当前系统设计的包，就有可能让依赖关系变得不够严密，导致依赖问题。这些问题需要让系统管理员手动解决才能允许做进一步的动作，这也是对很多新手来说非常困惑的地方。他们不会意识到是自己的先前行为有误，而是责怪包管理器「难以使用」。我是觉得这是一个很正常的事情，因为更高级的工具确实需要更长时间的学习才能应用，而太过自信和鲁莽行事是才是自己创造陷阱的原因。

如果一个工具用不了的话，那就不要用了。这也是新型包管理出现的原因之一。flatpak走的路是对打包者提出更多限制，让他们必须使用指定的库、指定的版本开发软件，并且也控制了软件的权限，用更极端的方式确保了包的质量。而AppImage对打包者是放任的态度，强制的限制更少，只管安装时（当然卸载也是）足够容易，但是运行时的各种问题依然存在。只管安装是否顺利，而能不能运行全看天意，这样做就能获得用户和开发者的支持，听起来好像有些别扭，但是似乎这就是我所见闻的，很多人的真实想法。如果听从AppImage官方建议的话，能做出相当优质的AppImage，确实和设想中的那样好，但是现在流传的许多AppImage都十分糟心，到论坛搜索一下就能发现大家提出的各种抱怨。

Reply Like 1 View the author