我们见得多的 Linux 服务器系统一般都是什么 Ubuntu Server 啊, 什么 Cent OS 啊, 什么 Fedora 啊, 或者企业采用的 Red Hat 啊, 为什么几乎没有 Arch Linux 呢? 下面我将从若干个方面指出 Arch Linux 在服务方面的劣势.
我前面好几篇文章都有关 Arch Linux, 我本人也是虔诚的 Arch 邪教教徒, 但是有人经常会问: 为什么 Linux 服务器几乎从不采用 Arch Linux? 我们见得多的 Linux 服务器系统一般都是什么 Ubuntu Server 啊, 什么 Cent OS 啊, 什么 Fedora 啊, 或者企业采用的 Red Hat 啊, 为什么几乎没有 Arch Linux 呢? 下面我将从若干个方面指出 Arch Linux 在服务方面的劣势.
1, 过分激进的滚动更新
滚动更新是 Arch Linux 最大的优势, 但同时也是最大的劣势之一. 鉴于 Linux 属于一类完全开放的项目, 技术人员的能力参差不齐, 贡献的代码质量当然也是参差不齐的. 对于其它的发行版来说, 软件包需要经过社区完善的测试才会被发布至软件源从而被用户更新; 然而, Arch Linux 的滚动更新机制过分激进, 而 Arch 社区对软件包的测试并非绝对完善(有多少人滚挂过?). 从某种意义上来讲, Arch 这个发行版, 相当依赖其用户群体作为测试对象; 它的用户群体就是类似测试人员的存在. Arch 社区鼓励用户向上游反馈 Bug, 也是这种特殊的体系的表现. 下图是 Arch 官网时不时会发布的, 用以帮助技术人员手动解决更新问题的 "临时解决方案":
图 0: 为什么 Arch Linux 不适合作为服务器操作系统
假如一台 Arch 服务器在更新时滚挂了, 技术人员顶着 Boss 的压力, 不仅要一边努力恢复服务器, 还要一边向 Arch 社区的上游反馈 Bug, 提 Issue. 这种事情谁都不愿意干的吧.
2, 激进的内核更新机制
很多 Linux 桌面用户不止一次地问过我, 为什么他们的桌面 Linux 在更新的时候不会像 Arch 一样立即删除旧的内核? 这样不是会浪费空间吗?
这种立即删除旧内核的更新机制也是 Arch 作为服务器的劣势之一. 首先, 新的内核不一定都能正常工作. 万一你的新内核造成崩溃, 你没有办法立即加载旧的内核, 而必须重新安装旧的内核. 这个过程是非常麻烦的, 你不仅需要从安装介质启动, 还必须设法弄到旧版内核的软件包. 对于远程服务器来说, 几乎无解. 下面是来自 Arch Wiki 的解决方案. 可以看得出来这有多么麻烦:
图 1: 为什么 Arch Linux 不适合作为服务器操作系统
其次, 立即删除旧的内核要求系统必须重启来加载新的内核, 否则容易发生诡异的问题. 这是因为 Linux 所谓的 "内核" 包含有大量的动态加载模块, 如果在某次启动后, 某个模块没有被加载过, 然后系统内核更新了, 删除了旧的内核, 那么这些模块将永远不能被加载了 -- 除非你重启系统完整切换到新的内核 -- 因为它们随着旧内核被删掉了.
如果你手头有 Arch 系统, 你可以尝试一下在某次启动之后不插任何 USB 设备, 然后更新内核. 你会发现, 如果你不重启系统, 无论你怎么努力, 新插上去的 USB 设备总是不会被加载 -- 因为需要被加载的模块已经随着旧内核删掉了. 重新启动系统能完整切换到新的内核, 以使用新版的动态加载模块.
但是对于服务器来说, 不可能三天两头重启; 然而 Arch Linux 却又是一个一周一小更, 一月一大更的快速迭代的操作系统. 这就使 Arch 不适合作为服务器操作系统.
3, 软件包管理体系
Arch Linux 被推崇很大一部分的原因是便于使用的软件包管理体系. 不同于 Debian 系列的 apt/dpkg 和 Red Hat 系列的 dnf(yum)/rpm 包管理体系, Arch Linux 只用了一个工具 pacman 就解决了获取和安装两个功能. 这降低了为 Arch Linux 制作软件包的门槛, 这也是 AUR 几乎能涵盖整个 Linux 软件生态的主要原因.
既然一个工具就能完成工作, 那为什么另外两个主流系列都依然存在两个工具来管理软件包体系? 这是因为, 这种两个工具来管理软件包的体系中, 那个负责处理本地依赖和本地包的部分, 不仅仅是为了管理依赖, 安装软件包而存在的. 它还有更有用的功能: 提供 "虚包" 支持. 提到 "虚包" 就不得不提到 Java 这个平台, 因为 Java 的开放, 常见的 Java 运行时环境有两种: 一个是 Oracle 官方的 JRE, 另一个是开源社区创建的 Open JRE. 它们都对 Java 提供很高程度的支持, 但是依然存在微妙的差别. 比如 Android Studio 使用 Open JRE 运行就会偶尔出现奇怪的 Bug, 而另外有一小部分软件则不能正常运行在 Oracle JRE 上. 它们都提供 JRE 的支持, 但是对于 Debian 或者 Red Hat 来说, 二者是能共存的: dpkg 或者 yum 可以决定对于哪些应用程序选取哪个 JRE 为应用程序提供 JRE 依赖.
但是对于 pacman 来说, 虚包支持什么的, 不存在的. 只能有一个软件包提供 JRE 支持: 安装一个就必须删除另一个. 对于服务器来说这就相当尴尬了: 并不能保证所有的程序都能找到完美的依赖.
4, 打包粒度
虽然最近几年有所改善, 但是 Arch Linux 的打包粒度对于服务器来说还是过分大了. 我们也许只会用到某软件包的一部分, 但是 pacman 会把整个软件包给你装上 -- 你还没得选. 对于服务器来说, 为实现功能所安装的软件包越少越好 -- 一来节省资源, 二来可以减少由软件体系带来的漏洞. 这也是 Arch 不适合作为服务器操作系统的原因之一.
就我目前的经验, 以上理由可以充分打消在服务器上使用 Arch Linux 的想法. 但是对于桌面系统, 特别是对于开发人员, Arch 还是相当不错的选择.
汝等虔诚的 Arch 教徒们, 切勿忍耐; 想安装什么的时候便装, 想做什么研究的时候便做就好 -- 因为明天并不见得还能正常运行.
来源: http://server.51cto.com/sOS-579026.htm