Arch Linux不适合当作服务器操作系统的四大原因

为什么Arch Linux不适合当作服务器操作系统?可能很多用户都发现了 , Linux服务器操作系统一般都是Ubuntu Server、Cent OS、Fedora或者Red Hat等 , 为什么很少看到Arch Linux呢?因为Arch Linux在服务方面确实存在一些劣势 , 下面我们来看看Arch Linux不适合当作服务器操作系统的四大原因 。

Arch Linux不适合当作服务器操作系统的四大原因

文章插图
为什么Arch Linux不适合当作服务器操作系统?
1、过分激进的滚动更新
滚动更新是Arch Linux最大的优势 , 但同时也是最大的劣势之一 。鉴于Linux属于一类完全开放的项目 , 技术人员的能力参差不齐 , 贡献的代码质量当然也是参差不齐的 。对于其它的发行版来说 , 软件包需要经过社区完善的测试才会被发布至软件源从而被用户更新;然而 , Arch Linux的滚动更新机制过分激进 , 而Arch社区对软件包的测试并非绝对完善(有多少人滚挂过?) 。从某种意义上来讲 , Arch这个发行版 , 相当依赖其用户群体作为测试对象;它的用户群体就是类似测试人员的存在 。Arch社区鼓励用户向上游反馈Bug , 也是这种特殊的体系的表现 。下图是Arch官网时不时会发布的、用以帮助技术人员手动解决更新问题的“临时解决方案”:
Arch Linux不适合当作服务器操作系统的四大原因

文章插图
假如一台Arch服务器在更新时滚挂了 , 技术人员顶着Boss的压力 , 不仅要一边努力恢复服务器 , 还要一边向Arch社区的上游反馈Bug、提Issue 。这种事情谁都不愿意干的吧 。
2、激进的内核更新机制
很多Linux桌面用户不止一次地问过我 , 为什么他们的桌面Linux在更新的时候不会像Arch一样立即删除旧的内核?这样不是会浪费空间吗?
这种立即删除旧内核的更新机制也是Arch作为服务器的劣势之一 。首先 , 新的内核不一定都能正常工作 。万一你的新内核造成崩溃 , 你没有办法立即加载旧的内核 , 而必须重新安装旧的内核 。这个过程是非常麻烦的 , 你不仅需要从安装介质启动 , 还必须设法弄到旧版内核的软件包 。对于远程服务器来说 , 几乎无解 。下面是来自Arch Wiki的解决方案 。可以看得出来这有多么麻烦:
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软件生态的主要原因 。

推荐阅读