对于我而言，我用Archlinux主要的原因就是实用主义。我可以很负责的说，Arch真的是在我所有用过的发行版当中最符合实用主义的一个了。

很多大佬一提到Archlinux就扯些什么kiss原则，在我看来则不然。

整洁规范的系统#

规范代码为的不是为了什么Art of Code，而是可读性的提升；遵循kiss原则亦是如此。

配置文件的路径写好了，符合规范，我们就能一下子找到，我们是为了实用主义而遵守kiss原则。

同样的，我同样可以为了实用主义而破坏kiss原则。比如在我的archiso-zhullyb中，我添加了一个pacman的hook将我的定制内核重命名为linux以确保其能够正确被ventoy所识别，这也是为了实用主义。

那么，什么时候我会破坏kiss原则呢？当我认为破坏kiss原则所带来的利大于弊时，我就会考虑以一个并不规范但却有效的方法来处理问题。

但很有趣的是，由于Archlinux的官方总是将kiss奉为圣旨，这就给我们提供了一个非常nice的环境了——在一个非常规范的系统内，破坏kiss原则所带来的代价并不会很大，这就好比在一个布线整齐的机房内临时私拉两三根线并不会给维护带来多大的困难。

不同于apt在源内提供了统一软件的多个版本供用户选择，pacman剑走偏锋，默认用户系统内所有软件都是最新的。

由此带来了一个好处——不会出现由于版本过高/过低导致的依赖问题。只要我保证系统内的所有软件都是最新的，就不会出问题，非常的简单粗暴。

此外，不考虑依赖版本这一特点对于打包人来说也是一种解脱。

pacman简单的打包方式#

不同于deb以及rpm，pacman的软件包应该是所有发行版中最省事儿的。

打包软件时，我们只需要写（改）一份PKGBUILD，就可以仅仅通过在PKGBUILD所在的路径执行makepkg命令来完成一次打包，这相比起deb而言可谓是天差地别。如此简单有效的打包方式注定其将被实用主义者所青睐。

超低的社区贡献成本#

很多发行版社区开发与贡献其实并不容易参与进去，我拿Ubuntu来做个比较。

附: Archwiki是先斩后奏类型的文档，在你按下保存按钮的那一刻，wiki将立即被更新，所有访客都将看到你改动后的内容。wiki文档拥有变更记录，不担心有人恶意搞破坏，向wiki管理员提出举报后破坏者的账号会被及时封禁，wiki可以非常简单地回滚到之前的状态。

AUR同样也是，你可以随意上传自己的PKGBUILD，可以被别的用户及时看到。如果上传恶意脚本，在别的用户举报后你将迅速被封号。

Wiki方面#

Ubuntu其实是我第一个上手的Linux发行版，在为期半年的Ubuntu体验中，我对于社区做出的贡献为0。这倒也不是我不热衷于参与社区贡献，而是对Ubuntu社区的贡献成本太高了。去贡献文档翻译，需要等待漫长的审核过程，在第一篇汉化文章正式展现在别的用户眼前后，我一定会被激发出继续翻译第二篇的热情。然而，面对太长的审核周期，再高涨的热情恐怕也会被浇灭。

Arch的社区则不一样，他并不像别的社区那样严谨——只要注册个wiki的账号便可以开始贡献文档。你可以随意地编辑一篇文章或者是新增一篇自己的文章，编辑后的文章将能够立即被别的用户所阅读到，没有任何审核过程，有了这份热情，我便继续翻译别的文档，我想，这应该就是archwiki为何涵盖面如此之广的原因。

AUR方面#

同样也是拿Ubuntu对比。

在Archlinux下，我只需要简单的写一个PKGBUILD即可轻松构建一个软件包，同时，我也可以将这份有我攥写的PKGBUILD上传到AUR供别的用户使用。AUR作为一个公开的储存库，任何Arch用户都可以通过AUR Helper轻松得从AUR中获取我写的PKGBUILD并在本地打成自己的包。与此同时，我也可以创建一个私人源，直接发行我构建的二进制包。

Ubutnu则不然，他的打包方式则要麻烦得多，同时也没有类似PKGBUILD一样的东西便于用户分享自己的打包脚本。唯一能够分享自己的劳动成果的方式无非就是直接分享自己打出来的deb包，最多也不过是建立自己的ppa，这对于用户来说是极为麻烦的。用户需要处心积虑地寻找自己所需要的deb包或是含有目标包的ppa地址并手动添加，不像Archlinux有AUR这种东西能够让我们知道在哪里能够找到我们所需要的包。