Human Emacs

Lobsters Hottest 新闻

摘要

Human Emacs 是 GNU Emacs 的一个分支,它承诺绝不接受 LLM 生成的贡献,以抗议可能允许此类贡献的 GNU 政策。该项目旨在保留人工编写的软件开发传统。

<p>LLM生成贡献自由(可能的)GNU Emacs分支。</p> <p><a href="https://lobste.rs/s/t0aqzy/human_emacs">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/07/13 17:54

# 人类 Emacs 来源:https://human-emacs.org/ Emacs 作为一个自由软件项目,其核心在于赋予用户力量,同时不牺牲其道德原则。作为 Emacs 的用户,我们关心的是如何确保未来能够继续真诚地使用和贡献它。 ## 背景 作为一名软件爱好者,度过 2026 年简直就是一连串的背叛;似乎每周我们都会看到新闻,又有一个我们曾以为值得信赖的人开发的程序,屈从于 LLM 的冲击。我们目睹了即使像 Vim 和 rsync 这样的中流砥柱,也积极采用 LLM 驱动的开发,疏远了其核心用户群,导致了诸如 vim-classic 这样的分支: https://vim-classic.org/ Emacs 项目的现任领导层已表示,目前不接受基于 LLM 的贡献,对此我们感到欣慰。然而,这一立场只是临时措施,旨在让我们坚持到 GNU 项目最终确定其关于 LLM 贡献的政策为止: > 我们正在等待 GNU 项目在这些问题上的决定,该决定将定义所有 GNU 软件包的政策,在此期间,作为预防措施,我们不接受 LLM 生成的代码。[…] 此类政策讨论和决定并非由 Emacs 项目来制定,它们对所有 GNU 软件包都是全局性的,因此这里不是寻找这些信息的地方。 https://lists.gnu.org/archive/html/emacs-devel/2026-03/msg00425.html 我们担心,即将出台的 GNU 政策可能无法让 Emacs 达到 GNU 历史上所坚持的高道德标准。鉴于大语言模型带来的压倒性负面外部影响,令人担忧的是,我们至今尚未看到明确的方向,并且我们担心,当政策最终出台时,可能无法保护我们免受这些问题的影响。 ## 意图 因此,我们在此宣布,无论 GNU 决定何种政策,我们都将使用并开发一个**没有** LLM 生成贡献的 Emacs 版本。我们邀请 GNU 权衡代价并做出正确决定,届时我们将继续支持他们。但如果他们不愿这样做,我们仍将继续使用和开发一个免于 LLM 的 Emacs 版本,即便它不是 GNU Emacs。 我们并非毫无犹豫地抛出“分支炸弹”(fork)。Emacs 的分支历史上一直颇具争议,且并非总能取得良好成果。然而,如果 GNU Emacs 接受 LLM 生成的贡献,我们感到别无选择;对我们许多人来说,放弃使用 Emacs 几乎等同于放弃整个计算,或者至少是放弃计算中带给我们快乐的部分。 我们还注意到,即使 GNU 的顶层政策未能解决这个问题,Emacs 维护者完全可以在 GNU 政策之上增加额外政策;与上述邮件列表帖子中的说法相反,将临时禁令永久化并不会产生任何冲突。 ## 动机 Guix 共识文档“支持人类手工创作”(https://codeberg.org/guix/guix-consensus-documents/pulls/13/files)很好地阐述了为什么我们需要这样一个针对像 Emacs 这样我们如此依赖的程序的政策。(尽管他们没有像 Emacs 那样有远见地设立临时禁令,这意味着他们被迫在其政策中留下了一些不幸的例外。) 我们认为这些危害已经足够清楚,无需在此重新列举;如果您想详细了解,请参阅该文档。 ## 不在讨论范围内 我们不是来讨论 LLM 在声称的功能上是否有效;它们的有效性与它们的使用是否能成为以用户赋权为原则的软件运动的一部分这一问题完全无关。 我们不是来讨论“开放权重”模型的;这些模型仍然建立在公司从数据中心破坏性地挖掘网络的基础上,这些数据中心破坏了社区。这样的模型不可能脱离剥削而存在。当一个模型能够完全由最终用户使用经过同意的数据训练时,我们可以讨论这一点,但眼下这不过是科幻和猜测。 我们不是来讨论恶意贡献者如何谎报他们补丁来源的。这种风险并不新鲜;恶意贡献者一直能够就补丁的许可和版权影响撒谎。将 LLM 生成的补丁与其他形式的剽窃同等对待就已经足够了。 ## 组织 讨论在邮件列表(https://lists.sr.ht/~technomancy/human-emacs)和 Libera Chat(https://libera.chat/)上的 `#human-emacs` 频道进行。您无需加入邮件列表即可发帖。 ## 签名者 - Phil Hagelberg (https://technomancy.us/colophon)(又名 technomancy) - Jon Levin (https://mhcat.ca/)(又名 mhcat) - David Bremner - Christine Lemmer-Webber (https://dustycloud.org/) - Geoff Wozniak (https://wozniak.ca/) - Shae Erisson (https://www.scannedinavian.com/)(又名 shapr) - Tushar (https://tusharhero.codeberg.page/)(又名 tusharhero) - Brit Butler (https://kingcons.io/)(又名 kingcons) - Gergely Nagy (https://gergo.csillger.hu/)(又名 algernon) - Anna Liberty (https://gracefulliberty.com/) - jamesnvc (https://occasionallycogent.com/) - Leon Henrik Plickat (https://leon_plickat.srht.site/) - Spencer Williams (https://plexwave.org/)(又名 spnw) - James Endres Howell (https://jamesendreshowell.com/) - durian (https://durian.acab.fans/) - Michel Lind (https://michel-slm.name/) - Alex Schroeder (http://alexschroeder.ch/) - Daniel Néri(又名 dne) - Bruce Durling(又名 otfrom) - aerique (https://aerique.net/) - Ashish Panigrahi (https://ashishpanigrahi.com/) - Christopher Shea - atax1a (https://infosec.exchange/@atax1a) - Dorian Vertumna - Diane Trout - Shiv J. M. - Nikola Adamus - Steve Purcell - Konrad Hinsen (https://khinsen.net/) - Mario Calcagno (https://air4x.github.io/index.html) - martianh (https://codeberg.org/martianh) - Jason McBrayer - David Maus (https://dmaus.name/)(又名 dmaus) - Joshua Suskalo (https://srasu.org/) - Avi(又名 maverick bozo) - Vivek Das Mohapatra(又名 fledermaus) - [你的名字] 要添加您的名字(以及可选的网址),请向邮件列表(https://lists.sr.ht/~technomancy/human-emacs)发帖,或在 `#human-emacs` 聊天室中询问。 查看本网站的源代码(https://git.sr.ht/~technomancy/human-emacs.org)。

相似文章

诚实导致Emacs补丁被拒

Lobsters Hottest

一名开发者使用GLM 5.2协助编写的Emacs性能补丁被GNU拒绝,原因是其禁止LLM辅助贡献的政策,此举引发了对该政策影响诚实性的批评。

还有人用 Emacs 吗?

Lobsters Hottest

作者对与 Emacs 数十年关系的个人反思,包括转向 VSCode 和 IntelliJ,最终因其独特功能回归 Emacs。

软件界的Emacs化

Hacker News Top

作者讲述了在终端中阅读 Markdown 的烦恼,并描述了如何使用 Claude 快速构建一个自定义的 macOS Markdown 查看器(MDV.app),展示了 AI 如何让人能够迅速创建个人软件工具。

Emacs 与 Bzr 的坎坷往事

Lobsters Hottest

文章回顾了 2008 年 GNU Emacs 开发者决定采用 Bazaar 而非 Git 作为版本控制系统的决策过程,重点强调了性能方面的顾虑,以及 Richard Stallman 坚持使用 GNU 软件包的立场,尽管技术基准测试显示 Git 更具优势。