Question

为什么 Archlinux 不适合服务器使用

Answer 1

JTTI服务器整体性能是非常不错的，拥有CN2 GIA+BGP优化线路，多个节点可选，套餐配置支持自定义，经过第三方站长测评之后，获得了站长和客户的一致认可，无论是硬件性能，网络线路，还是带宽品质，都能够满足大陆用户的使用需求，以下是Jtti的服务器测评总结：

①三网去程和回程情况：电信去程和回程都是走59.43的双向CN2 GIA直连线路；联通去程和回程走的是双向AS9929联通优化线路；移动去程和回程走的是移动双向CMI直连线路。

②在本地ping和全球各地网络数据图来看，延迟低，基本上没有丢包的情况，中国香港地区ping值50ms，新加坡节点的ping值77ms，美国节点的ping值158ms，整体网络很稳定。

③服务器速度测评情况，上传和下载速度国内和海外节点基本跑满了整个主机的带宽，跟官网宣传的一致。

整体来说，Jtti服务器性能是很不错的，三网网络状况良好，网络稳定，延迟低，速度快，性价比也很高，适合海内外用户使用！服务器租用推荐Jtti，一家全球网络基础服务商，总部位于新加坡，致力于为广大用户提供优质的一站式互联网服务解决方案，包括云服务器、服务器租赁、服务器托管、安全技术开发等产品与服务，自营中国香港，新加坡、美国等多个数据中心，不仅具备丰富的机房管理经验，还提供7*24h中文技术支持，实现7/24/365全天候在线运维，凭借出色的基础设施和网络技术，专业的研发能力和运维技术，已累计为全球上万家企业提供互联网基础服务和网络托管服务。

Answer 2

　　Archlinux 也并非完全没有测试，它也有自己的 testing 分支和完善的 tracking system 。然而由于 Archlinux 的哲学，更新速度非常之快，甚至 GNOME 2 到 3 这样的大型更新它都只用了不到一个月就正式发布了。而 Archlinux 毕竟不算是一个大型发行版，工作人员有限，这么短的时间之内很难进行彻底的测试。发布之后再遇到大小 bug 都是再常见不过的事情，除了一般软件 bug 甚至还有内核和硬件之间的兼容问题……比如我的上一篇博客就提到了两个相当严重的 bug 。想看更多的例子？去 官方论坛 看看就知道了。

　　由于 Archlinux 的特点和哲学，其实这不是什么大问题。折腾 Archlinux 的都不是小白，在社区的配合之下一般最后都能顺利找到问题根源（大多数时候是上游 bug ……）然后找到 workaround 并向上游反馈。包括我在内的不少用户其实是乐在其中的（虽然嘴上抱怨不断）。 Archlinux 的“用户”在一些大型发行版里其实应该是“志愿者”之类的存在……

　　但这在生产环境之下是不能容忍的。你让一个生产服务器更新之后遇到 bug 然后运维顶着上司压力满头大汗地找问题、提 issue ？对这一点抱有疑问的人一定没有在商业公司做过运维。不要和我说什么你的个人博客 VPS 用的是 Archlinux 。

　　更新内核后竟一定要重启？

　　这应该是 Archlinux 最大的问题了。很多 Linux 用户都不理解为何 Debian 和红帽系都要把每个内核版本分开打包，然后再做一个虚包指向最新版内核，更新内核时不会自动删掉旧版本，还得之后手动删除……

　　这其实是有非常重要的理由，而且不限于是“保险起见”，新内核启动不起来的时候可以选择旧内核。更重要的原因是—— Linux Kernel 是模块式的、动态加载的，而 /usr/lib/modules/LINUX-KERNEL 是属于内核软件包的。如果在更新内核的时候删掉了旧版内核的软件包（也就删掉了模块目录），就会使得还未加载的模块无法再被加载了。觉得没有影响？那么我告诉你——硬件驱动都是以内核模块形式存在的。举个例子，如果你使用 Archlinux ，在某此启动之后都没有插过 U 盘，然后更新了内核，你就发现 U 盘插进去以后怎么都认不出来（USB EHCI 模块和 vfat 文件系统模块都没挂载……）。你说服务器上不会有硬件变动？那么你一定是忘记了 OpenVPN 之类的软件，在启动之后需要建立一个虚拟设备（比如 OpenVPN 的 TAP 或者 TUN ），如此一来也就无法使用了。

　　最终的结果就是，使用 Archlinux ，要么你就别更新内核，要么更新了内核以后就立即重启以免遇到奇怪的问题。这种粗暴的更新方式难道不是比 Windows Update 还要糟糕么？（用过 Windows Server 的人一定遇到过更新以后要求你重启，甚至如果你正好处于一个活跃会话，那么如果你不立即取消掉那个对话框， 15 分钟后就直接给你重启了……）

　　糟糕的 Pacman

　　比起复杂甚至臃肿的 yum/rpm 和 apt-get/dkpg ， Archlinux 的包管理器要简单许多，一个 pacman 就搞定了“源”和“包”两头，完成了别的发行版两个软件才能做到的事情。

　　可如果真要是这么简单的一个程序就能做好的事情，为什么别的发行版都要这么“笨”地开发如此复杂的工具？答案其实很简单——软件包管理本来就是非常复杂的事情。我不是一个包管理者，在这方面没有什么发言权，但单从一个用户角度来看也足够意识到其存在的不足了。依赖、推荐不够灵活，只有 depends opt-depends suggestions 三种，缺乏“虚包”的支持。一些常见的需求比较难以优雅地实现，比如：一个软件有多个不同的实现时，只能通过设置相同的 provides 然后再互相 conflicts 实现，这样一来每加一个新的实现就要修改之前所有的相同 provides 的包，而且也缺乏 dpkg-reconfigure 之类的工具来选择一个虚包到底使用哪一个实包从而实现灵活地在不同实现之间切换的功能（比如 Oracle JDK 和 OpenJDK 之间的切换，在 Archlinux 里只能安装一个然后删除掉另一个）。

　　另外， Archlinux 的打包粒度太大（比如一个 php 包就包括了大量非必须模块，得靠修改配置文件来启用或禁用，而在 Debian 和红帽里则是被拆成了很多个包）。当然，也有人认为 Debian 的粒度太细就是了。不过就我两年的使用经历看来 Archlinux 的包的确偏大，对于桌面版没有什么问题，这年头大家的硬盘也都挺大，但在服务器上一般都是希望安装尽可能少的软件以尽可能减少漏洞和 bug 。

　　当然，比较简单的包管理器也有一个好处，就是降低了打包的门槛。这也是 AUR 能够这么方便易用、内容丰富的部分原因。

　　最后，吐槽一下 pacman 不会自动清理包缓存，哪怕是很早以前的。我在用了两年之后包缓存有30多个G，直接把我的根分区都占满了……

Answer 3

因为Arch Linux 的源没有充分的审核和测试，要知道在生产环境下甚至不应该随意更新任何系统软件，除非是某个软件爆出漏洞需要紧急修复（例如 OpenSSH）。何况还是每一次更新都冒着很大风险的 Arch Linux。
而 RHEL、CentOS 和 Debian 这类系统就非常适合当做生产环境使用，它们的更新相对来说是最安全的，风险最低的，频率自然也慢很多。
因为生产环境最重要的就是这个字：稳。
并且对于生产环境来说频繁的更新是毫无意义的，这也是为什么像 CentOS 5/6 这样的老旧系统仍然能占一大片天。
如果 Arch Linux 要往服务器上发展，肯定会推出极其稳定的源，显然它没有这样做。它是最前列的激进派。
Arch 就好像是一个速度飞快的小艇，虽然各种先进（软件版本新）的配件，但是容易翻船。安全载人的话是绝对比不上那些速度不快（软件版本较低）却稳如泰山的大游轮的。