Bản vá Emacs bị từ chối vì công khai việc vibecoding
(xlii.space)- Một bản vá nhỏ được tạo ra để cải thiện hiệu năng Emacs trên macOS đã được gửi lên
emacs-devel, nhưng không được chấp nhận vì chính sách của GNU không nhận các đóng góp có hỗ trợ từ LLM - Tác giả cho biết GLM 5.2 đã tìm ra vấn đề và soạn bản nháp, đồng thời khẳng định chính mình chịu trách nhiệm về độ chính xác, phân tích tác động, chỉnh sửa, kiểm thử thủ công và trách nhiệm cá nhân
- Bản vá bị từ chối chỉ là một thay đổi 92 dòng với phạm vi hẹp; ông cho rằng vì hoàn toàn có thể giấu việc dùng LLM, nên chính sách này đang khiến những ai công khai trung thực bị bất lợi hơn chính việc sử dụng
- Mối lo từ phía GNU dường như gần với tính mở và khả năng sử dụng hợp pháp của đầu ra LLM, nhưng ông không đồng tình và viện dẫn các mô hình open-weight cùng các trường hợp sử dụng thực tế trong ngành
- Ông nói sẽ không tiếp tục làm việc với Emacs nữa, và chỉ công khai một phần trong khoảng 40 bản vá cải thiện hiệu năng đang có trên ổ cứng mà ông mới xác nhận gần đây
Công việc cải thiện hiệu năng Emacs trên macOS
- Przemysław Alexander Kamiński đã dành vài tháng để cải thiện hiệu năng Emacs trên macOS, bỏ thời gian cho việc gắn công cụ đo đạc và viết benchmark
- Ông đã đưa codebase Emacs cho nhiều LLM khác nhau để tìm các vấn đề cụ thể, nhưng nhìn chung kết quả không tốt
- Khi phân tích các bản vá, nhiều cái có tác động nhỏ hoặc hiểu sai vấn đề
- Đánh giá của ông về các nút thắt hiệu năng khi đó như sau
- Vấn đề chính trên macOS là lỗi kết xuất và hiện tượng thrashing bộ nhớ do cấp phát/giải phóng quá nhanh
- Cách
mallochệ thống của macOS hoạt động, do thiếu nén bộ nhớ, gây phình bộ nhớ ảo và làm mất tính cục bộ của cache - Bản thân lõi Emacs vẫn còn các vấn đề hiệu năng
- Xử lý regexp được dùng ở nhiều nơi nên nếu cải thiện có thể ảnh hưởng đến hiệu năng tổng thể
Bản vá được tìm bằng GLM 5.2 và quá trình gửi lên
- Nhờ được một người bạn cho gói Max của z.ai, ông có thể dùng GLM 5.2, và đánh giá mô hình này khá giỏi trong tối ưu hóa mã
- Dựa trên lượng kiến thức đã tích lũy sẵn, ông đặt các câu hỏi cụ thể liên quan đến Emacs và giao cho GLM 5.2 việc dò tìm, phân tích vấn đề
- Sau khoảng 3 giờ, ông nhận được một số báo cáo, rồi xem lại đề xuất và mã, kiểm thử tác động của từng mục và chạy benchmark
- Vì việc chuẩn bị để gửi bản vá tốn thời gian, ông chọn một mục hứa hẹn nhất để xử lý và gửi lên mailing list
emacs-develhai ngày trước khi viết bài - Ngày hôm sau, ông biết được rằng GNU có chính sách không nhận các đóng góp có hỗ trợ từ LLM, nên bản vá không được chấp nhận
Phạm vi sử dụng LLM được công khai trong email gửi bản vá
- Khi gửi bản vá lên mailing list, ông đã nêu rõ việc dùng LLM và phạm vi phần việc do mình trực tiếp rà soát
- Việc phát hiện vấn đề và viết bản nháp bản vá do GLM 5.2 thực hiện; ông cũng nói rõ GLM 5.2 là một mô hình open-weight của Trung Quốc
- Ông trực tiếp phân tích độ chính xác và tác động của báo cáo vấn đề
- Ông rà soát và chỉnh sửa bản vá
- Ông kiểm thử bản vá thủ công
- Với mục đích pháp lý, ông tuyên bố mình là tác giả của phần nộp lên và sẵn sàng khẳng định đóng góp của mình lớn hơn LLM
- Ông tuyên bố chịu hoàn toàn trách nhiệm cá nhân đối với phần nộp
- Phạm vi triển khai của phần nộp rất hẹp và quy mô cũng nhỏ
- Bản vá được công khai chỉ có 92 dòng, và phần chú thích đã nêu lý do tồn tại của nó
- Ông cho rằng bản vá này không thể bị xếp vào loại “slop”, dù cũng nói mọi người có thể tự đánh giá
Phản bác đối với chính sách của GNU
- Ông nói mình tôn trọng chính sách của GNU nhưng không đồng ý, và cho rằng chính sách đó không có đủ cơ sở
- Dù hoàn toàn có thể che giấu việc dùng LLM, ông đã công khai rõ ràng, và kết quả là phần nộp bị bất lợi
- Vì vậy, ông chỉ trích rằng chính sách này đang trừng phạt sự công khai trung thực hơn là bản thân việc sử dụng LLM
- Vì ông hoàn toàn không tin tưởng LLM, ông cho rằng các đóng góp có hỗ trợ từ LLM cần nhiều rà soát và nhiều cặp mắt hơn, chứ không phải ít hơn
- Ông nói không thể biết toàn bộ bối cảnh chính sách vì việc này được thảo luận trong danh sách nội bộ của GNU; từ các trao đổi trước đây, ông hiểu rằng nghi ngại chủ yếu xoay quanh việc đóng góp từ LLM có đủ mở hay có thể dùng hợp pháp hay không
- Ông không đồng ý với lập luận cho rằng mô hình open-weight là chưa đủ mở
- Ví dụ, ông cho rằng việc phân biệt kiểu như dùng Qwen 3.6 cục bộ thì được nhưng dùng qua OpenRouter thì không là phi lý
- GLM 5.2 là một mô hình open-weight, và ông nói nếu có 256GB RAM cùng 24GB VRAM thì có thể chạy cục bộ để tránh lập luận “SaaS là đóng”
- Trên Internet có rất nhiều nội dung không tự do, nên theo cùng logic đó thì có phải cũng nên cấm truy cập Internet khi tạo phần nộp hay không, ông đặt câu hỏi
- Ông cũng không đồng tình với các lo ngại pháp lý
- Ông nói các công ty game còn nhạy cảm hơn với IP và LLM nhưng vẫn có dấu hiệu sử dụng LLM; ChatGPT có 1 tỷ người dùng hoạt động, và từ hàng trăm nghìn đến hàng triệu tổ chức đang dùng đầu ra LLM mỗi ngày
- Dù nói rõ mình không phải luật sư Mỹ, ông hiểu rằng vấn đề đăng ký bản quyền nằm ở phía gắn thông báo bản quyền
- Ông không đồng ý với thái độ cho rằng GNU nên đặt trọng số lớn nhất vào luật sư và quan điểm pháp lý của riêng họ
Dừng làm việc với Emacs và các bản vá được công khai
- Ông nói GNU có quyền tự quyết, và ông cũng có quyền phê phán
- Ông chỉ trích việc thảo luận chính sách trong nội bộ theo cách không minh bạch với người dùng, và cho rằng mức độ cởi mở đó chỉ ngang với việc Meta quyết định hướng đi của Facebook trong nội bộ
- Kết quả là ông tuyên bố sẽ không tiếp tục làm việc với Emacs nữa
- Ông nói mình không thích tình huống khi làm việc tự nguyện mà lại bị bảo là đang “cầm nhầm cây gậy”
- Trên ổ cứng của ông có khoảng 40 bản vá cải thiện hiệu năng; một số chồng lấn nhau, một số khác thì tác động thực tế vẫn chưa được chứng minh
- Ông chỉ công khai một số bản vá mà gần đây đã xác nhận là hoạt động và có tác động đáng kể, và nói rằng các bản vá đó thực sự tạo ra khác biệt
1 bình luận
Ý kiến trên Lobste.rs
Có vẻ tác giả đã hiểu sai open trong "open weight" nghĩa là gì
Việc các khối ma trận cuối cùng được công khai và có thể tinh chỉnh ở một mức độ nào đó không có nghĩa là cả dữ liệu huấn luyện dùng để tạo ra nó cũng là mã nguồn mở. Có vẻ OSI seems to agree cũng nhìn nhận tương tự, và nếu vậy thì vấn đề bản quyền hoàn toàn chưa được giải quyết
Tôi có thể đồng cảm với người muốn đóng góp thiện chí, không nhận thù lao, nhưng GNU đã viết quy định rất rõ ràng, và nếu đến đó rồi nói "tôi chỉ vi phạm một chút thôi, đây là bản vá" thì bị từ chối cũng chẳng có gì lạ. Lý do bị từ chối không phải là vì thành thật, mà vì đã làm điều bị nói rõ là không được làm
Mong là hôm nay tác giả sẽ học được rằng hàng tỷ người cũng có thể sai. Normalization of deviance không biện minh cho hành vi lệch chuẩn, mà chỉ mô tả cách hành vi đó tiếp tục lan rộng
Một trong những khuôn mẫu thấy trong chatbot psychosis là coi những con người phản đối hoặc đưa ra ý kiến khác là kẻ thù. Các narremes mà chatbot được huấn luyện trên đó bao gồm góc nhìn trong đó người dùng là nhân vật chính, với camera over-the-shoulder và một câu chuyện cá nhân dễ đọc. Kiểu tự sự được hậu xử lý theo sở thích của chatbot tác động trực tiếp đến người dùng bằng cách củng cố cảm giác mình là nhân vật chính, và khi người dùng bị ion hóa đủ mức thì họ không còn chấp nhận được cả những lập trường trung lập
Trong trường hợp này, tôi khuyên tác giả nên đọc cuộc thảo luận gốc mà họ không liên kết hoặc trích dẫn. Cộng đồng Emacs đã tử tế, cởi mở, đặt câu hỏi, thể hiện sự quan tâm và đón nhận tác giả. Ngay cả khi từ chối bản vá, họ cũng nói nhẹ nhàng, tập trung vào chính sách của GNU hơn là công kích tác giả
[incomprehensible]Dù vậy, theo ngữ cảnh thì tôi hiểu họ muốn nói gì, và ở đây nó có vẻ là một khái niệm hữu ích, phù hợp
GNU Project phải cân nhắc lo ngại bản quyền trên toàn thế giới, chứ không chỉ vấn đề bản quyền ở Mỹ. Ngay cả luật Mỹ cũng chưa hoàn toàn ngã ngũ
GNU muốn chắc chắn rằng họ nắm giữ 100% bản quyền đối với các đóng góp quan trọng. Cách diễn giải pháp lý của tác giả ở đây không quan trọng, GNU Project đang chọn hướng an toàn. Những lo ngại khác mà họ có lẽ còn có về LLM thậm chí còn chưa được tính đến
Hơn nữa, nếu trong kho mã có mã do LLM tạo ra mà không được phân biệt và ghi chú rõ ràng, thì toàn bộ kho có thể bị xem là không thể được bảo hộ bản quyền cũng như không thể cấp phép
Nói cách khác, nếu tác giả nói dối để mã được commit, thì họ có thể đã đặt hiệu lực giấy phép của toàn bộ codebase Emacs vào tình thế rủi ro
Tất cả những điều này còn chưa tính đến thái độ ngạo mạn gần như hoang tưởng kiểu "tôi không phải luật sư nhưng các luật sư rõ ràng là sai". Họ đang nhìn vào vài điều khoản luật riêng lẻ, đồng thời chỉ trích các luật sư là ngạo mạn
[1] Đây là thông tin mới nhất tính đến cuộc trao đổi tương tự với bộ phận pháp lý công ty tôi khoảng hai tháng trước
Tôi không chắc lập luận "nếu nói dối thì đã được chấp nhận" có ý nghĩa gì
Nhưng điều đó chẳng nói tốt đẹp gì về chính những người đó, đúng không?
Tôi không nghĩ việc quấy rầy các maintainer vì chính sách ủng hộ hay phản đối LLM là điều hay. Họ đang làm công việc của mình, và họ có quyền lựa chọn sẽ đánh giá, chấp nhận hay từ chối loại đóng góp nào
Tất nhiên, phàn nàn thì tôi thấy vẫn ổn. Người này đang nêu quan điểm của mình trên blog, và đó là cách các cuộc thảo luận được định hình. Chỉ là tôi không đồng ý với cách framing. Vấn đề ở đây không phải là "sự thành thật". Nếu chính sách no-LLM đã được thông báo, thì trách nhiệm thuộc về chính người đó khi đã tốn thời gian cố đóng góp bằng LLM cho một dự án vốn không muốn loại đóng góp như vậy
Chuyện này chẳng khác gì mang đồ ăn có thịt hoặc phô mai cho một người ăn chay thuần rồi phàn nàn rằng họ không ăn dù bạn đã "thành thật" nói nguyên liệu. Câu "nếu không nói thì họ đã không biết có sữa" nghe không hề ổn, và câu "nếu không nói thì họ đã không biết tôi dùng LLM" cũng vậy
GNU và FSF đầu tư khá nhiều vào việc nhận tư vấn pháp lý chuyên nghiệp. Thế nhưng người đóng góp tiềm năng này về cơ bản lại đang khuyên họ phớt lờ tư vấn chuyên môn đó chỉ vì lời của một ai đó trên Internet
Nếu đã bỏ tiền để nhận tư vấn chuyên môn thì việc làm theo lời khuyên đó là hợp lý, và nếu không đồng ý thì nên tìm một chuyên gia khác. Bỏ qua nó vì lời khuyên của một người bình luận ngẫu nhiên trên mạng không phải là "gần như châm biếm" mà đơn giản là ngu ngốc
Tách biệt với chuyện từ chối, có vẻ trong tương lai sẽ xuất hiện khá nhiều án lệ thú vị. Các nhà cung cấp mô hình lớn có thể đưa ra một dạng miễn trừ trách nhiệm nào đó và nói rằng "đây là mã mà chúng tôi đã giúp tạo ra nên bạn có thể tự do khẳng định bản quyền theo ý muốn", hoặc ngược lại họ có thể đẩy vấn đề đi xa hơn, tuyên bố rằng họ sở hữu nó và phải cấp phép cho những mục đích sử dụng nhất định. Hiện tại Claude giao mã cho người dùng, nhưng tôi không rõ họ cung cấp dạng miễn trừ trách nhiệm nào. Các mô hình khác thì tôi cũng không rõ
Bạn có biết rằng tội phạm chỉ là bất hợp pháp khi bị bắt không
Tôi hoàn toàn không phải fan cuồng của GNU, nhưng chẳng phải công cụ lập trình LLM là thứ nằm ở thái cực đối lập với triết lý GNU sao? Cảm giác như mang chó vào quán cà phê mèo rồi tức giận vì bị đuổi ra
Tôi cho rằng việc đổi tiêu đề từ "Honesty gets Emacs patch rejected" thành Vibecoding gets Emacs patch rejected là cực kỳ thiếu trung thực
Ngay cả khi như tác giả có nhận hỗ trợ từ công cụ AI, nếu đã bỏ ra chừng ấy thời gian và mức độ hiểu biết cho đoạn mã thì rõ ràng đó không phải vibe coding. Nếu tác giả chỉ quăng cho AI câu "hãy làm Emacs nhanh hơn" rồi nhắm mắt nộp kết quả thì mới là vibe coding, nhưng đọc bài thì rõ ràng chuyện đó đã không xảy ra
Nếu là tôi thì có lẽ tôi sẽ đặt là "Breaking contribution policy gets Emacs patch rejected". Vẫn còn hơi mỉa mai, nhưng khó bác bỏ hơn
Điều gây chú ý ở đây là tác giả khẳng định đã làm việc đều đặn suốt hai tháng, nhưng mô hình mà họ nói là đã dùng để tìm và sửa vấn đề thì lại được giải thích là ra mắt cách đây 12 ngày
Tôi hiểu vì sao tác giả khá tức giận, nhưng rốt cuộc tôi cho rằng mã nguồn mở không phải là thứ trao cho bạn quyền lợi nào đó, mà gần hơn với một đặc quyền được sử dụng đoạn mã đã được tạo ra sẵn. Điểm tích cực là có lẽ vẫn có, và những gì tác giả viết về macOS nhìn chung là đúng nên các nhà phát triển Emacs có thể sẽ dành thời gian xem qua. Chỉ là macOS có lẽ không phải mối quan tâm chính của họ
Có một cách giải quyết rất dễ để chứng minh chính sách này ngớ ngẩn đến mức nào. Chỉ cần mở PR diff có hỗ trợ LLM trên màn hình thứ hai, rồi trên màn hình chính tự tay viết lại toàn bộ phần sửa đổi từ đầu. Chỉ cần đổi tên biến và nội dung chú thích đi một chút
Giờ thì nó đã trở thành mã do con người viết, nên có thể được gộp