AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
System76 is banning AI-generated content from contributions to the COSMIC desktop. Some GNOME sub-projects also restrict AI-generated contributions, but one developer is urging them to make an exception for vulnerability reports. The COSMIC desktop project has changed its contributors' guidelines. The latest version now has a clear no-AI rule, insisting that contributors declare: "I have not included any LLM (also known as AI) generated content in this PR, including code, comments, and descriptions." In other words, you can teach yourself using AI, you can find bugs with AI, but if you want to submit your code for inclusion in COSMIC, you can't use AI to write the code, its docs or notes, or even the submission requests. This position is in keeping with some other desktop projects. For instance, the GNOME Calendar guide to contributing says: "This project does not allow contributions generated by large languages [sic] models (LLMs) and chatbots." GNOME Extensions also restricts AI-generated submissions, although it permits AI learning aids and code completion. Its review guidelines spell it out: "Extensions must not be AI-generated." COSMIC is one of the newest complete Linux desktop environments, but even so, it's been under development for years. The Register first reported on the effort nearly five years ago, meaning that it's older than ChatGPT, which debuted in late 2022 (it only feels so very much longer). COSMIC does use some GNOME components, and its default config looks not unlike GNOME, with a top panel and a dock-like launcher at the bottom. There are good reasons for that: the original System76 desktop called "COSMIC" was based on GNOME, quite heavily customized with GNOME extensions. Saying that, though, this new COSMIC is a very different beast. Its first stable release shipped with Pop!_OS 24.04 in late 2025. Although it looks similar, it's an entirely new, ground-up effort, written in Rust using the Iced toolkit. COSMIC itself is Wayland-only. GNOME is much older, larger, and more complicated. The project was announced in 1997, the year after the KDE project announcement. KDE 1.0 came out in 1998, and GNOME 1.0 in 1999. In part, GNOME was a response to KDE. KDE is built on the Qt toolkit, which was not fully open source. As such, in KDE's early days, Red Hat refused to include it in Red Hat Linux. Qt is aimed at C++ developers, so KDE was built in C++. Linux, like Unix, is built in plain old C and many Unix traditionalists scorned the much more complex C++. So GNOME was built in plain old C, using GTK, the toolkit built for the GIMP. In 1998, Red Hat Linux 5.1 included a preview of GNOME, and by Red Hat Linux 6.0 in 1999, GNOME 1.0 was the default desktop. GNOME is still the default desktop in RHEL to this day, and many GNOME developers' day jobs are at Red Hat. As we noted back in March, Red Hat management is noticeably enthusiastic about AI – although six months later, it was capping developers' AI spend. GNOME is largely written in C, which lacks automatic memory safety guarantees, although other languages feature too: GNOME Shell combines JavaScript and C, and some components are written in the GNOME-centric Vala programming language. Michael Catanzaro, GNOME developer, just published a blog post titled "The Era of Software Quality, or the Era of Ostriches?" which argues that the GNOME project must accept AI-generated bug reports. This is not a new subject for him. His post links to an earlier one from June, "Please Do Not Ban AI-Assisted Issue Reports." The following month, he announced a reduction in the disclosure deadline for issues reported to GNOME Security, from 90 days to 30, effective August 1. We recently reported on the 1,313 CVE identifiers listed in Debian's latest Linux kernel security advisory. AI is resulting in the discovery of vast numbers of bugs in the equally vast codebases of modern FOSS. GNOME is one of the biggest desktops in the Linux and BSD world, with much of its code written in memory-unsafe languages. As Catanzaro says: "No matter how much we try, GNOME developers will fail [to] write secure code when using unsafe languages like C, C++, or Vala: it's just too hard for even experienced developers to do properly." We are not arguing that Catanzaro is wrong. Given the stance toward AI of GNOME's biggest sponsor, it is entirely in keeping, and he makes a strong case. All we are noting is that this could in time prove to be the thin edge of a wedge with the weight of Red Hat behind it. First the project allows AI-generated bug reports. From there, it would not be a huge step to allowing AI-assisted triage. From there, to AI-assisted fixes. Once you're letting AI-assisted code in, then AI-assisted extensions may not seem so extreme, then core components, and in time, to the desktop itself. It would be wildly controversial, just as it already is in the KDE project. That doesn't mean it won't happen – in either project. Debian decided to allow it, and of course, the kernel itself does too. ®