惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
J
Java Code Geeks
N
Netflix TechBlog - Medium
Martin Fowler
Martin Fowler
A
About on SuperTechFans
腾讯CDC
B
Blog RSS Feed
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Microsoft Azure Blog
Microsoft Azure Blog
D
Docker
Y
Y Combinator Blog
Microsoft Security Blog
Microsoft Security Blog
F
Fortinet All Blogs
I
InfoQ
博客园 - 【当耐特】
美团技术团队
GbyAI
GbyAI
量子位
宝玉的分享
宝玉的分享
爱范儿
爱范儿
有赞技术团队
有赞技术团队
博客园 - Franky
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志

Hacker News: Front Page

SPICE simulation → oscilloscope → verification with Claude Code — Lucas Gerads Introducing Claude Opus 4.7 Qwen Studio The Future of Everything is Lies, I Guess: Where Do We Go From Here? GitHub - SeanFDZ/macmind: Single-layer transformer in HyperTalk for the classic Macintosh Show HN: Agent-cache – Multi-tier LLM/tool/session caching for Valkey and Redis Ancient DNA reveals pervasive directional selection across West Eurasia [pdf] AI cybersecurity is not proof of work Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus GitHub - Nightmare-Eclipse/RedSun: The Red Sun vulnerability repository GitHub - SethPyle376/hiraeth: Local AWS emulator focused on fast integration testing, with SQS support, SQLite-backed state, and a debug-friendly web UI. A Better Ludum Dare; Or, How to Ruin a Legacy GitHub - macOS26/Agent: Any AI, replaces Claude Code, Cursor, OpenClaw. Over 18 LLM providers (Claude, OpenAI, Gemini, Ollama, Zai, HF, Qwen) wired into a native Mac app that writes code, builds Xcode projects, bumps versions, manages git, automates Safari, use AppleScript, JS or Accessibility, extend Agent! w/ MCP Servers, run tasks from your iPhone via Messages. YouTube now lets you turn off Shorts I Made a Terminal Pager Burgers | マクドナルド公式 Commands — HackerNews CLI documentation ChatGPT for Excel PiCore - Raspberry Pi Port of Tiny Core Linux Live Nation illegally monopolized ticketing market, jury finds Google Broke Its Promise to Me. Now ICE Has My Data. Founding Engineer at Adaptional | Y Combinator CRISPR takes important step toward silencing Down syndrome’s extra chromosome GitHub - saffron-health/libretto: The AI toolkit for building reliable browser automations US v. Heppner (S.D.N.Y. 2026) no attorney-client privilege for AI chats [pdf] Unexpected €54k billing spike in 13 hours: Firebase browser key without API restrictions used for Gemini requests Fragments: April 14 Cal.com Goes Closed Source: Why AI Security Is Forcing Our Decision | Cal.com - Scheduling Software for Online Bookings Laravel raised money and now injects ads directly into your agent Codex Hacked a Samsung TV
Honesty gets Emacs patch rejected
2026-06-26 · via Hacker News: Front Page

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.