世界上有几百个还在更新的 Linux 发行版。新手常常感叹挑花了眼，换来换去也找不到自己满意的。维护一个发行版需要花费很多时间、精力，为何人们要这样“重复劳动”呢？
-
“强迫症患者”
我小时候追求整齐、秩序，无论是家里的电灯开关还是电脑上的图标，一定要排列的整整齐齐，不惜自己接电线、一个个重命名文件。“我的电脑”、“我的文档”、“网上邻居”，下面的蓝色 e 名字太长，就改叫“上网浏览”吧……然而随着安装了越来越多的软件，这些“秩序”被不断破坏，自己不断妥协。有的程序在我的文档里乱放目录——忍。有的程序会自动下载更新，然后在我代码写到一半的时候弹出来更新提示——忍。有的程序会带各种运行时包安装、替换系统文件导致另外一个程序运行不了——忍。
每次出了大问题的时候，所有人都告诉我：“现在只能重装了。”
2008年的时候，厌倦了折腾各种魔改定制 WinPE 的我首次下定决心安装了 Ubuntu 8.04，从此打开了新世界的大门。
不再需要依赖猜测。手握源代码，就如同掌握了施工的图纸，一切不符合心中秩序的地方都能找到原理。一群志同道合的前辈早已构建了井井有条的目录结构、依赖关系、软件仓库、……一切都显得那么美好。和每个第一次玩 Linux 桌面的折腾狂一样，我花了很多时间试图让 GTK+ 和 Qt 的程序界面一样而且好看，以及折腾 compiz 特效。
然而事情也不是那么完美。当时我在压片组用 x264 压片，采用的方案是使用加上一些特别 filter、并且带 lavf 输入的 x264 命令行。我用 wxPython 做了一些小工具，比如音轨提取、mkv 合成等，但是自动压片脚本需要的 x264 不能用仓库里的版本。我注册了 Launchpad 帐号并创建了一个 PPA，接下去，我花了很长很长时间都没有学会打出一个靠谱的包。别说各种 macro 的使用，就连拆包的部分都让我焦头烂额了。
长久以来折腾的零碎结果——各种经验、配置文件、补丁、翻译，散落在各种网站、论坛、聊天工具，而自己真正想分享出去的成果——软件包，又不知如何下手。我想要为这份秩序做点贡献，怎么办呢？后来群里的大牛们给我了一个简单一些的方法——AUR。
我在 2011 年安装了 Arch，从此找到了贡献之路。
-
共识社区
使用 Ubuntu 的时候，我有过很多想打包的软件，也曾经用简单的 checkinstall 打出过数个“勉强算是包”的包，但是这个过程一直十分痛苦，以至于我搁置了大量的 TODO。
而在 AUR 里，一个简单的十几二十行普通 bash 语法的 PKGBUILD 文件，就描述完了一个包。字体、游戏、输入法，开发中用到的 python 库，都被我轻松地打成了 Arch 的软件包。2012 年，我申请成为了 Arch 的 Trusted User，将这些包中使用率高的部分加入了官方仓库。在 IRC 和 TU 们的闲聊中，我能感受到或多或少大家都是因为 pacman / PKGBUILD 体系的简洁、维护轻松而走到了一起。
一个人的力量是有限的，我很高兴我找到了这样一群和我类似的“强迫症患者”。开源软件千千万万，自己选择费心费力。有的作者很马虎，有的作者不喜欢条条框框，有的作者对安全更新嗤之以鼻——而发行版的打包者们，则成为了一道防线。我们形成了一些共识，无论是代码里的编译选项还是软件的默认行为，都会尽力向上游作者们争取、提供修改意见，或者直接提交补丁。这样的共识或许不完全和内心的秩序一致，但也已经相当接近了。每人维护一部分的软件包，承担起相应的责任，而其他人就可以坐享这份成果，大家的“强迫症”都得到了满足。
在我看来，这就是一个发行版存在的意义。轻易切换发行版使用的用户们，可能只是不像我们这么傻，这么认真。
近年来每每被问起诸如“Flatpak 会让发行版大一统”、“Docker 会让发行版大一统”、“把 npm 仓库里的包打成 Linux 软件包毫无意义”等等问题时，我时常会感到难以回答。不是没有道理可讲，实在是不知如何讲起。这些都是很有意义的理念和技术，只是它们取代不了形成一个发行版的共识。所谓共识，无非是在取舍时看重哪边更多一点。
Linux 发行版，作为基于共识形成的社区，正是由我这样的“强迫症患者”所组成。
以前在用 openSUSE 的時候，望着 OBS，其實是想學着打些 RPM 包的，甚至記得當時還建了幾個目錄，結果一搜文檔……
總之現在用上 Arch 後，也是想爲 Arch 出份力，而且 PKGBUILD 腳本真的太簡易了。讚美（
被猫大代入ubuntu的坑。。（逃
好久不见呀，最近在哪高就？
还在网易。。
最喜欢的大概是Arch的简洁和秩序。目录不会乱。包管理系统很难也没有必要一统吧，当一个发行版积累了很多风格和基因，甚至能影响上游开发者，促其保持规范（虽然类似XDG的规范很早就有了），就已经很美好了。
然而总是在win用户面前不敢随意说些什么……千言万语～年轻人，用Arch吧。
你好！我是上海易玩的HR，我们公司前身开发的产品是电驴，目前的产品叫做TapTap，这边看到你的博客，我最近手头有一些高级开发类岗位，不知道最近是否有考虑新机会的打算呢？希望和你取得联系？
我的电话/微信17682310732
不好意思，暂不考虑……
看了后, 勾起很多回忆, 有很多感触啊.
确实是折腾过的, 最后都落在这个点上了.
毕竟还是有”精神方向”指引着发展方向, 然后同好者聚在一起, 没什么不好.
围观肥猫大佬～
Arch / Parabola 用了这么一阵子以后，大概就是喜欢上了那种离核心越来越近的感觉，以及自然而然的想为她做点什么的样子 😶😊
hi Felix, I used to work for SUSE for 10 years, way back in time. When I read your blog I thought of the OpenSUSE Buildservice.
It used to be called autobuild, and while at SUSE I always considered it our major asset, and I still think it differentiates SUSE Linux from all other distros.
Here is what happens. You have “Consensus Agents” like yourself for every package in the distro. Then, after all of them agree to have their projects / packages patched to be compatible, the packages get built automatically, for various hardware architectures, languages, configurations etc., layer upon layer of dependencies.
I think this concept can be extended to more specific solution stacks, and provide a much more efficient approach to software production than current workload container lego.
best, Juergen
I have tried it several times before, the only real issue for me is that it’s just too much work to build RPMs as “good” as the existing ones (to name a few: macros, patch policy, supported architectures, split packages, writing everything it installs…).
It’s also not trivial to be tuned to build packages for other platforms, for example Arch is not good at strict repository hierarchy or no-internet during build().
absolutely.
my background is in mechanical engineering, and there are two names that come to mind when I read your reply:
1) Henry Ford
2) Carl Edvard Johansson
The latter invented “Joe Blocks”, what we call Normalmass in German. With these blocks the industrialization that started in England, defines Germany, and now China came.
In computing we don’t have the ability to build on top of what the giants before us built to the extend possible – and in my mind necessary! – available in the mechanical engineering world.
The reason is simply that computing is young, and we are only starting. Part of the challenge is putting in the extra effort to make things repeatable.
And you rightfully quote the necessary investment. But it pays off to know where you came from, and to go further by not having to worry about foundations all the time. Microsoft technology would be a good example …
原来是加泰的。。
你好像说漏了一个东西，就是Windows的Linux子系统
如果要这样比较的话，那还有虚拟机里的 Linux、容器里的 Linux、以及虚拟机里的 Windows 的 Linux 子系统 🙂
深度的打包的flatpack应用，能访问的宿主的目录都有限，连tmp目录都读取不到。
比如深度截图，设置保存文件在临时目录，浏览器上传的时候去临时目录一看，发现不在那里。
帮你转发给开发者啦 🙂
这是flatpack的结构基础决定的，因为不会全部开放挂载的。flatpack有自己的一套“根目录”，比如深度看图的flatpack版，你用它是打不开深度系统下面的/usr/下面的那些图片，因为对应用程序来说，我的/usr/下面没有这张图片，虽然这问题不是完全无解。
能不能用PKGBUILD来生成deb的包。。。deb打包太繁琐了。或者能不用简洁的写法生成所有发行版的包。肥猫大佬见多识广，有没有这种工具？
不会有，真的有也不会靠谱的。因为打包理念不一样，自动生成出来的最多是能用而已，还不如用现成的工具，比如 flatpak……
fpm-cookery 了解一下？虽然个人认为没吹的那么好。
难得的更新。
肥猫是没抢到felix.cat的域名吗
是因为当年嫌加泰罗尼亚的域名政策麻烦而懒得注册……
肥猫看过 https://12factor.net/ 么？flatpak、snap 和 Docker 等技术显示的是用户减少一个服务给宿主系统「副作用」的需求吧。比如给某个系统有问题的主机排除故障，一般要先知道出故障前系统有了那些状态（包括硬件、软件以及软件的配置等）变更。如果是易失（比如内存里的状态）的变动，简单的重启往往就能解决问题，但如果是写了某些错误的配置文件，或者装了有问题的硬件，这种情况就不能单靠重启解决咯。正是由于系统层次的状态依赖比较复杂，包管理才是一个不容易的事情。
nix、guix 和 Debian 的可重现构建就是为了减少包管理复杂度而做的一些尝试。当然如果所有状态变化都事务化，并且状态变更随时可以撤销，那是解决包管理问题的一个进步。然而现实世界本身是有副作用的，光（信息）的传播都需要时间，如何保证状态操作是原子的，如何避免状态冲突，是个超难的课题。
我没有否定这些技术和尝试，只是采用这些技术在现实使用中也是有代价的。
这篇文章说的主要是由此产生“大一统”不大可能。可能未来会基于这些技术出现更多的发行版，各自偏向解决了一部分问题。
无论用什么技术，发行版维护人员的工作价值（识别、规范、整理等，这本质上是个熵减的过程）都是不可替代的。docker 也只是一种技术，否则怎么会有那么长的 Best practices for writing Dockerfiles。