← 返回日报
略读 预计 5 分钟

Honesty gets Emacs patch rejected

摘要

作者长期在做 Emacs macOS 性能优化,包括基准测试、代码分析,并认为主要问题在渲染、频繁内存分配导致的碎片与缓存局部性下降,以及 regexp 处理等核心路径。近期他借助 GLM 5.2(开源权重模型)辅助分析代码,生成并筛选出一个约 92 行的小补丁,经过人工审查、修改与测试后提交到 emacs-devel 邮件列表,并明确声明 LLM 参与、自己承担责任与主要作者身份。 补丁随后被拒,理由是 GNU 有不接受 LLM 辅助工作的政策。作者认为这一政策没有依据,尤其是 “诚实披露反而受惩罚” 会导致开发者更倾向于隐瞒 LLM 使用。他进一步质疑该政策对 “开源 / 开放” 的定义(例如是否在本地运行模型、是否使用闭源服务),以及对法律与版权问题的理解方式,认为 GNU 内部决策缺乏透明度。 文章最后表示,因该事件与政策分歧,作者决定停止参与 Emacs 相关开发,转向其他项目,并认为自己仍有多项未发布的性能优化补丁已或部分验证有效。

荐读理由

作者放弃了唯一选定的92行性能优化补丁,因为GNU政策禁止LLM辅助工作,尽管他已独立审查、修改、测试并承担全部责任;这表明该领域真实技术变化(GNU对AI贡献的严苛规则)会使他当前的工作失去方向感

原文

home

Honesty gets Emacs patch rejected

I’ve been working on Emacs performance on macOS for a couple of months - not continuously but for couple of months nonetheless. During that time I’ve been occupied with hooking up instrumentation and creating benchmarks. I also gave multiple LLMs the codebase and asked for it to search for specific things. Usually the results were poor. After analyzing patches, either the impact was minimal or the problem was misunderstood - something completely expected.

Though over this time I formed some opinions about the codebase I believe are true.

Opinions, that on macOS the main problem with performance consists of rendering issues and memory thrashing - happening with rapid allocations and deallocations. Opinion, that lack of memory compaction, specific to macOS due to how system malloc works, causes virtual memory bloat and loss of cache locality. Opinion, that Emacs core is not free of performance issues. One place I’ve been analyzing over and over was regexp processing. It’s used everywhere and so any improvement to regexp processing would improve the overall performance.

I’ve been re-analyzing over and over these areas. I’ve made some rough patches and was slowly narrowing down the scope with hope of getting to tangible, fixable, points.

Recently, thanks to z.ai Max plan granted to me by my friend, I’ve been able to run GLM 5.2 on projects I’m working on (these ones where I could). I discovered that GLM 5.2 is quite capable when it comes to code optimization and so I decided to ask specific questions about Emacs within the context of already amassed knowledge, and made it to search and analyze any issues.

Without going into much detail, after ~3 hours1 it came back with couple of reports. I reviewed them, the propositions and provisioned code, tested the impact of each and ran benchmarks. Because grooming code for a patch submission takes some time I picked the most promising one and started to work on it. I sent it to emacs-devel mailing list two days before writing this piece.

Day after I learned that it won’t be accepted as there is a GNU policy against accepting LLM-assisted work. I respect it but I don’t agree with it.

To give more context: in the mailing list when I was sending the patch, I noted that:

  • The issue was found and patch drafted by GLM 5.2 (a Chinese model with open weights).

  • I analyzed the issue report for correctness and impact

  • I reviewed the patch and made modifications to it

  • I tested the patch manually

  • I declared authorship of the submission for legal purposes (i.e. I’m prepared to argue that my contribution was bigger than LLMs)

  • I declared taking full, personal, responsibility for the submission

Submission size and implementation scopes are very narrow. I don’t think it can be categorized as slop, but feel free to make your own opinion (the patch is 92 lines long and includes the raison d’être in the comment).

And it bounced.


Personally, I don’t think the policy has any basis.

First of all, I could’ve hidden the fact of LLM usage, and yet decided to declare it explicitly. By being truthful I already lost my footing. This alone makes the policy stupid. If admittance is punished it’s better to push submissions without admitting. It punishes integrity, not usage per se. Because who will find out? I don’t trust LLMs at all thus I believe LLM-assisted work require actually MORE scrutiny and eyes - not less.

I don’t claim to known full context around the policy because - adding insult to the injury - this policy is discussed on the internal GNU lists. What I learned from past conversation around LLMs, however, is that the doubts about LLM contributions are around them being “open enough” and “legal to use”.

When we’re talking about open-weight models, I find the argument about being open absurd. It means that Qwen 3.6 on my local setup is fine, but if I use it from OpenRouter - then it’s not. GLM 5.2 IS Open Weights model and if I had 256 GB of RAM (which I don’t) and 24GB of VRAM (which I have), I could run it on my local machine escaping the whole “SaaS is closed” argument. By the same measure, maybe Internet access should not be available during crafting of submissions? Internet is full of non-free content, and thus patch might have been tainted? Who knows, maybe the inspiration was taken from gasp non-free book or article.

Regarding legality argument - I think it’s hubris talking.

With all the sympathy I have for GNU organization, it neither is the biggest, smartest or the most legal-wise caring organization in the world. E.g. gaming companies are way more paranoid about IP and LLMs and yet usage there is visible as well; ChatGPT has a billion of active users; hundreds of thousands, if not millions of organizations - commercial and not, are using LLMs output every day. And for them the case is clear.

I’m not an American Lawyer, but I read that:

The (Copyright) Office will not register works produced by nature, animals, or plants. Likewise, the Office cannot register a work purportedly created by divine or supernatural beings, although the Office may register a work where the application or the deposit copy(ies) state that the work was inspired by a divine spirit.

And as far as my, IANAL, personality understands is: the problem is with putting a copyright stamp on it and not other way around.

Yet GNU believes that THEIR lawyers and THEIR opinion has the most weight. I won’t deprive them from the right of deciding for they own, but this lack of self-awareness is almost caricatural.

GNU has a freedom to decide about itself - I have my freedom to criticize it. In my eyes behind the doors discussion, without as much as transparency toward users is just as open as Meta internal decisions about Facebook direction. I wouldn’t call it open, neither I would call open organization that decides to operate in such way.


With my rant about politics finished, here’s the actual effect.

I’m not going to work on Emacs anymore. I dislike when people tell me I’m holding the stick wrong - especially when I work on something out of my own volition. On my hard drive I have around 40 performance improving patches, some overlapping, some yet unproven about actual impact. I published only handful that I recently confirmed to work and have a meaningful impact.

Feel free to check them out, as they genuinely2 make a difference.

And with that I think I’ll move to more “open” waters.


  1. GLM 5.2 is sloooooow tooooo thiiiiiiinkkkkk ↩︎

  2. haha, LLM word ↩︎

Przemysław Alexander Kamiński vel xlii vel exlee

cb | gl | gh | li | rss

Powered by hugo and hugo-theme-nostyleplease.

Lobsters · 2 赞 · 3 评 讨论 → 阅读原文 →

这条对你有帮助吗?