Flathub không cho phép các bản gửi dựa trên LLM

• Trong khâu xét duyệt bản gửi lên Flathub, số lượng bản gửi chất lượng thấp dựa trên LLM tăng lên đã làm gánh nặng cho các reviewer tình nguyện lớn hơn, trở thành bối cảnh để làm rõ chính sách
• Ngoại lệ nhiều khả năng sẽ áp dụng cho các dự án có sự tham gia của cộng đồng, chu kỳ phát hành, CI, và dấu hiệu cho thấy đó không phải là sản phẩm làm vội với ít công sức trong thời gian ngắn
• Chỉ dựa vào lịch sử phát triển sẵn có và tiêu chí về mức độ lành mạnh của dự án vẫn không giúp giảm khối lượng công việc review, mà chỉ làm tăng tranh cãi quanh cách diễn giải quy tắc
• Chính sách mới không nhằm cấm toàn bộ các ứng dụng FOSS trưởng thành có dùng LLM một phần hay các ứng dụng độc quyền sẵn có, mà tập trung vào việc chặn các bản gửi ít công sức
• Một số ý kiến lo ngại sự phân mảnh phân phối của hệ sinh thái Flatpak có thể tái diễn và doanh nghiệp sẽ né tránh Flathub, đồng thời đề xuất thu phí thay vì cấm hoàn toàn

---

Thay đổi chính sách bản gửi dùng LLM của Flathub

• Việc số lượng bản gửi chất lượng thấp dựa trên LLM tăng lên trong khâu xét duyệt bản gửi lên Flathub và làm tăng gánh nặng cho các reviewer tình nguyện là bối cảnh cốt lõi của thay đổi chính sách này
• Sjoerd Stendahl cho biết danh sách PR của Flathub có nhiều bản gửi “AI-slop”, và vì quy mô của vấn đề nên động thái lần này có thể là lựa chọn tốt hơn
• Bart Piotrowski nói rằng nếu dự án có sự tham gia của cộng đồng, chu kỳ phát hành, CI, và dấu vết cho thấy không phải sản phẩm chất lượng thấp được tạo ra trong thời gian ngắn, thì nhiều khả năng sẽ được xem là ngoại lệ
• Trước đây cũng đã cố chặn các bản gửi chất lượng thấp bằng cách dựa vào lịch sử phát triển đầy đủ và mức độ lành mạnh tổng thể của dự án, nhưng kết quả là không giảm được khối lượng review mà chỉ phát sinh tranh cãi về cách diễn giải quy tắc

Ngoại lệ và tiêu chí về mức độ trưởng thành

• Nexi cho rằng vấn đề các bản gửi Flathub ít công sức là có thật, nhưng cách cấm đồng loạt toàn bộ mã do AI tạo ra hoặc AI hỗ trợ là quá mức
• Nếu ngay cả các dự án sẵn có như Firefox, VSCode, Chromium cũng có thể bị đưa vào diện xóa mà không có ngoại lệ, thì nên dùng chỉ số khách quan về mức độ trưởng thành của dự án để lọc các bản gửi chất lượng thấp sẽ phù hợp hơn
• Bart Piotrowski trả lời rằng các tiêu chí về mức độ trưởng thành trên thực tế đã tồn tại, nhưng rốt cuộc vẫn không giúp giảm gánh nặng review
• Nexi cho rằng nên phản ánh rõ tiêu chí ngoại lệ trong chính sách, đồng thời có thể thêm điều khoản rằng nếu chất lượng mã quá thấp thì có thể bị từ chối mà không cần giải thích thêm
• Sjoerd Stendahl nhận định chính sách mới có ngoại lệ cho các dự án trưởng thành và được bảo trì tốt, chứ không phải chính sách cấm toàn bộ các ứng dụng FOSS đã được kiểm chứng có dùng LLM một phần hoặc các ứng dụng độc quyền sẵn có

Tác động tới hệ sinh thái và lo ngại về đường phân phối

• Dmitry Mantis lo ngại chính sách này có thể tái tạo sự phân mảnh phân phối Linux mà Flatpak vốn muốn giải quyết
• Việc các ứng dụng độc quyền như Slack và Spotify được cung cấp trên Flathub dưới dạng sandbox là một lợi thế, và ông đặt câu hỏi liệu mã đóng có thể lại được lợi vì không ai biết chúng được viết bằng cách nào hay không
• Cũng có ý kiến phản biện rằng các ứng dụng độc quyền của nhà phát triển mới và chưa được biết đến thì ngay cả khi không có chính sách này cũng không nên được đăng ngay lên Flathub
• Xu hướng một số ứng dụng trước đây chỉ dùng AppImage nay bắt đầu hỗ trợ Flatpak chính thức là tín hiệu tích cực, nhưng có lo ngại rằng sau chính sách kiểu này, các công ty có thể tránh gia nhập Flathub
• Cũng có đề xuất rằng thay vì cấm hoàn toàn thì nên áp dụng mức phí cho các bản gửi dựa trên AI để bù chi phí review
• Điều này có thể trở thành tín hiệu rằng hãy phân phối ở nơi khác trước khi có được một lượng người dùng nhất định, và nếu các ứng dụng được bảo trì tốt có dùng LLM cho một phần kiểm thử hoặc tự động hóa tài liệu đã ổn định ở kênh phân phối khác thì động lực chuyển sang Flathub có thể giảm đi

Đánh giá trái chiều quanh công cụ LLM

• Thomas Fuchs cho rằng vấn đề của LLM gần với vấn đề con người và marketing hơn là bản thân công nghệ
• Ông chỉ ra rằng các công ty LLM bán LLM như thể phép màu hoặc nô lệ lao động cá nhân, và vấn đề là người dùng tin nguyên các tuyên bố đó
• Khi người dùng có kinh nghiệm hiểu rõ điểm mạnh và điểm yếu và dùng cho phạm vi hẹp, nó có thể là công cụ tuyệt vời, nhưng ông mô tả ngành này đang quảng bá quá mức theo kiểu “phát miễn phí cưa máy đang cháy để đi tung hứng”
• Wolkensteine không cho rằng LLM hoàn toàn vô dụng, nhưng trong đa số trường hợp chúng không hữu ích, và hiện vẫn chưa có mô hình hữu ích nào được tạo ra theo cách mà ông muốn ủng hộ về mặt đạo đức
• Ông cho rằng các mô hình on-device có thể hữu ích cho kiểm tra chính tả hoặc dự đoán từ trong tự sửa trên bàn phím điện thoại, nhưng những việc có thể làm mà không mắc lỗi thì nhìn chung con người cũng có thể dễ dàng tự làm và học được
• Ember cho rằng ngay cả những trường hợp sử dụng tiềm năng đó cũng đã có thể làm bằng các công cụ trước thời AI tạo sinh, và trong các trường hợp hiếm hoi thì ML chuyên biệt được huấn luyện trên dữ liệu cụ thể còn tốt hơn
• Kroc Camen lập luận rằng do vấn đề sao chép mã, thiên kiến nội tại và tác động môi trường, LLM không có trường hợp sử dụng hợp lệ ở bất kỳ đâu

Văn hóa cộng đồng và sự phân cực của tranh luận

• trisweb cho rằng văn hóa xoay quanh mã do LLM tạo ra và những người dùng nó thường không phù hợp với cách tiếp cận tử tế và hợp tác cần thiết để duy trì cộng đồng mã nguồn mở
• ragectl cho rằng có thể cần một triết lý kiểu thời gian chờ cho ứng dụng mới, vì trước khi có nhiều bản phát hành và có người đóng góp thứ hai là con người thì nguy cơ vẫn cao
• Sjoerd Stendahl nói rằng cần cẩn trọng với việc săn phù thủy, nhưng việc Big Tech thúc đẩy LLM một cách hung hăng đang làm gia tăng phản ứng ngược từ mọi người
• Một số nhà tuyển dụng yêu cầu dùng LLM trong công việc kèm đe dọa sa thải, cả những chức năng đơn giản như tìm kiếm cũng bị làm hỏng, và ông mô tả “Agentic future” là nhu cầu rất hẹp nhưng nhiều sản phẩm lại đang biến thành thứ giống tàn dư bắt chước lao động của con người
• razze cho rằng vấn đề dùng LLM cho tìm kiếm hay chatbot là chuyện khác với dùng cho mã nguồn, vì mã có thể được kiểm chứng và các đánh đổi rõ ràng hơn nên cần được đánh giá riêng
• Zeeshan Ali Khan chỉ ra tính công kích của phe phản đối LLM, và Bart Piotrowski đáp rằng cả phe ủng hộ lẫn phản đối LLM đều đang phân cực mạnh, còn những “vibecoders” thì khi bị chỉ trích cũng hành xử như nạn nhân

[GN⁺]

Ý kiến trên Lobste.rs

• Câu nói rằng "không cho phép các ứng dụng chứa mã, tài liệu hoặc nội dung khác do AI tạo ra hoặc có AI hỗ trợ" nghe khá cứng rắn.
  Flathub là một nơi cực kỳ phổ biến để người dùng desktop Linux tải ứng dụng, tự gọi mình là "cửa hàng ứng dụng cho Linux", và có hơn 1000 ứng dụng.
  Điều đó có thực sự nghĩa là không một ứng dụng nào trong số đó được dùng mã có AI hỗ trợ sao? Có thực tế không? Có phải đã quá muộn rồi không?

  • Nhìn vào câu "có thể cho phép ngoại lệ đối với các dự án trưởng thành và được bảo trì tốt", có vẻ ý đồ gần hơn là ngăn các dự án làm hoàn toàn bằng vibe coding rồi bỏ mặc lên đó
  • Chẳng bao giờ là quá muộn cả.
    Ngay cả các dự án đã có trên FlatHub, nếu bị lộ là được vibe coding ra, vẫn có thể bị gỡ bỏ, đồng thời cũng gửi đi một thông điệp rõ ràng
  • Có lẽ nên hiểu rằng quy định này sẽ được thực thi theo quyền xem xét.
    Một số ứng dụng lớn hiện có có thể được công nhận là ngoại lệ, và ngay cả trong trường hợp đó, hạn chế này có lẽ sẽ áp dụng nhiều hơn với phần đóng gói flatpak độc lập hơn là với chính mã của ứng dụng

• Cách tiếp cận cứng rắn này có thể không thể thực thi 100%, nhưng trong bối cảnh các công ty đang ép mạnh việc triển khai LLM, cộng đồng cần một lập trường mạnh như vậy như một mức phản kháng tối thiểu có thể làm được

• Nghĩ đến các vụ việc gần đây liên quan đến chuỗi cung ứng, đây nghe như một quyết định khá hợp lý

• Dù một dự án cấm LLM, hay cấm người tóc bạc hoặc người cao đúng 160cm, tôi ủng hộ 100% quyền được tự quyết của họ.
  Không phải là tôi muốn hạn chế quyền tự do đó, nhưng quản lý gói là kiểu công việc lặp đi lặp lại điển hình có thể hưởng lợi rất nhiều từ sự hỗ trợ của LLM.
  Tôi cũng phần nào hiểu những người xem mã của mình là sản phẩm của nghệ thuật thuần túy hay tay nghề thủ công, nhưng tại sao lại không cho phép tự động hóa những việc nhàm chán nhất?

  Tôi còn nhớ hồi Arch Linux và AUR mới bắt đầu, đã có những người bảo trì thành công hàng trăm gói.
  Chúng luôn được cập nhật và hầu như không bao giờ hỏng, nên dĩ nhiên hẳn là họ đã tự động cập nhật.
  Nếu làm cùng việc đó ngày nay với hỗ trợ LLM, gần như chắc chắn nó còn có thể vững chắc hơn

  Có khi nên cấm con người trong quy trình mới đúng.
  Ngoài các cuộc tấn công chuỗi cung ứng thì con người còn đóng góp được gì? Có lẽ một ngày nào đó tôi sẽ thử làm một bản phân phối LLM để chứng minh quan điểm của mình đúng hay sai.
  Nhưng trước hết phải hoàn thành cái ngôn ngữ lập trình này đã, buồn cười thật