Debian 与塞壬

# Debian与海妖之歌 来源：https://joeyh.name/blog/entry/Debian_and_the_sirens/ 三十年前，我成为了Debian开发者。十二年前，我离开了这个项目。离开的原因是Debian这艘船似乎变得过于沉重难以转向，一系列看似合理的决策不断累积，既增添了负担也削弱了灵活性。这使得Debian成为今天的模样，却也阻止了它去探索更广阔的可能性空间。 Debian很可能在今天（https://www.debian.org/vote/2026/vote_002）表决通过允许在Debian开发中使用大型语言模型（LLM）。我写这篇文章时投票尚未结束，但会在结果公布后发布。（更新：如预期所料）我已不再是掌舵者，但作为仍在船上的乘客，我依然怀有个人观点，依然会经过那些我数十年前亲手搭建的、熟悉的桅杆绳索，并回忆起当初的构想。 当思考LLM在Debian开发中的角色时，我主要想到的是debhelper（https://joeyh.name/code/debhelper/）及其成就。在我刚加入项目时，`debian/rules`文件冗长复杂，充斥着奇怪的样板代码，开发者往往需要复制一个模板再进行修改，才能让包构建工作不那么费力。Debhelper首先规范了样板代码，让规则文件变成一系列`dh_`命令的有序排列；随后它几乎消除了所有冗余，将文件精简到最少。最终只剩三行并非必需的样板代码，仅仅为了满足对某个规范文档的刻板解读。即便修改这部分会为成千上万的软件包带来显著益处，但当时已无法做出改变。 我担忧的是，LLM在Debian开发中的应用，将消除精简样板代码或改革那些需要大量无意义人工操作的规范的动力。如果三十年前我就能使用LLM，或许会直接让它们生成复杂的规则文件。因此，LLM会让Debian更固守当前形态，更不可能探索它可能成为的模样。 不幸的是，Debian的特性之一就是几乎无法有效管理现代依赖树的打包工作。像Guix这样的现代发行版可以从十几种编程语言的包仓库（https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix-import.html）递归导入依赖，并得到通常可直接加入发行版的结果；而Debian的规范让这类自动化流程难以实现。或许有人会利用LLM来完成这项工作。如果他们成功了，Debian将在开发过程中变得依赖专有软件，同时仍然需要人工参与，从事更令人不快的琐碎工作。 我还能举出其他危害，但仅这一点就足以让我确信：如果十二年前我没有离开这个项目，现在也即将离开。作为乘客，我仍会不时在此停留，但确实该到不同的港口登陆，四处探索，享受别样的风景。 昨日我失去了父亲（https://kitenet.net/~errol/），此刻我正竭力避免将今天的局面比作失去孩子——尽管我曾耗费十八年时光陪伴Debian成长。这种联想太过沉痛。我理解Debian正面临一个可能并无标准答案的选择。无论今天达成何种具体妥协，个人仍需决定自己的行为与选择。Debian从来不只是规范的集合体，不仅是一艘船，更是一群船员。我将永远爱着你们。