Linux服务器几乎从不采用Arch Linux？

滚动更新是Arch Linux最大的优势，但同时也是最大的劣势之一。鉴于Linux属于一类完全开放的项目，技术人员的能力参差不齐，贡献的代码质量当然也是参差不齐的。对于其它的发行版来说，软件包需要经过社区完善的测试才会被发布至软件源从而被用户更新；然而，Arch Linux的滚动更新机制过分激进，而Arch社区对软件包的测试并非绝对完善（有多少人滚挂过？）。

假如一台Arch服务器在更新时滚挂了，技术人员顶着Boss的压力，不仅要一边努力恢复服务器，还要一边向Arch社区的上游反馈Bug、提Issue。这种事情谁都不愿意干的吧。

很多Linux桌面用户不止一次地问过我，为什么他们的桌面Linux在更新的时候不会像Arch一样立即删除旧的内核？这样不是会浪费空间吗？这种立即删除旧内核的更新机制也是Arch作为服务器的劣势之一。首先，新的内核不一定都能正常工作。万一你的新内核造成崩溃，你没有办法立即加载旧的内核，而必须重新安装旧的内核。这个过程是非常麻烦的，你不仅需要从安装介质启动，还必须设法弄到旧版内核的软件包。对于远程服务器来说，几乎无解。下面是来自Arch Wiki的解决方案。可以看得出来这有多么麻烦：图1：为什么Arch Linux不适合作为服务器操作系统其次，立即删除旧的内核要求系统必须重启来加载新的内核，否则容易发生诡异的问题。这是因为Linux所谓的“内核”包含有大量的动态加载模块，如果在某次启动后，某个模块没有被加载过，然后系统内核更新了，删除了旧的内核，那么这些模块将永远不能被加载了——除非你重启系统完整切换到新的内核——因为它们随着旧内核被删掉了。如果你手头有Arch系统，你可以尝试一下在某次启动之后不插任何USB设备，然后更新内核。你会发现，如果你不重启系统，无论你怎么努力，新插上去的USB设备总是不会被加载——因为需要被加载的模块已经随着旧内核删掉了。重新启动系统能完整切换到新的内核，以使用新版的动态加载模块。但是对于服务器来说，不可能三天两头重启；然而Arch Linux却又是一个一周一小更，一月一大更的快速迭代的操作系统。这就使Arch不适合作为服务器操作系统。

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支持：安装一个就必须删除另一个。对于服务器来说这就相当尴尬了：并不能保证所有的程序都能找到完美的依赖。

虽然最近几年有所改善，但是Arch Linux的打包粒度对于服务器来说还是过分大了。我们也许只会用到某软件包的一部分，但是pacman会把整个软件包给你装上——你还没得选。对于服务器来说，为实现功能所安装的软件包越少越好——一来节省资源，二来可以减少由软件体系带来的漏洞。这也是Arch不适合作为服务器操作系统的原因之一。就我目前的经验，以上理由可以充分打消在服务器上使用Arch Linux的想法。但是对于桌面系统，特别是对于开发人员，Arch还是相当不错的选择。汝等虔诚的Arch教徒们，切勿忍耐；想安装什么的时候便装，想做什么研究的时候便做就好——因为明天并不见得还能正常运行。