Wxy 发布的文章

按惯例,LCTT 每两年会做一次总结,在第一年第三年第五年第七年第九年都分别做了陈文。今年本来不必再赘述,但是,一方面今年是第十年了,这是个有意义的年份;另外一方面,今年以来,生成式 AI 的横空出世也深切影响到了翻译这件事。因此,我觉得有必要写点什么。

十年前的这一天上午,在没有经过预先安排和详细计划的情况下,我在 QQ 群内发起了 LCTT。原本的初心是翻译 Linux 上的手册页,因为现存的中文手册页实在残破不堪。由于没有协作翻译的经验,当时先建立了一个实验性项目 TranslateProject,收集了一些英文文章来翻译。果然,在这个过程中,我们发现并改正了不少流程上的不足。这些经验甚至成为了其它类似翻译活动的基础。

但是,遗憾的是,作为我们最初的目标,中文手册页项目,却由于种种原因,中道烂尾。至今叹息。

好了,作为十年总结,我应该将过去十年的成绩做个总结。

这十年间,我们总计有 547 位贡献者参与了从选题、翻译、校对到发布等多种贡献;这些贡献者翻译超过 10 篇的译者中有 117 位,超过 100 篇的有 8 位,而最大贡献者 geekpi 一个人就翻译了 2015.5 篇;所有的贡献者们总共翻译了 7929 篇文章。这些文章,仅在我们官方的官网、微信公众号、知乎等内容渠道就获得了上亿次阅读。

通过翻译这些文章,很多人第一次接触了开源,并亲自参与了贡献,学会了使用 GitHub 和 Git,有的人还在日后的学习和工作中,成为了开源贡献者、布道者。

现在回头看,这十年,LCTT 至少还是做了一些有意义的事情的。

表完了成绩之后,我谈谈对将来的看法。

可能有的同学已经在我们近期的文章中发现,有部分文章是由 AI(ChatGPT)翻译的。这件事其实给我带来了很大的触动。

之前,我们在翻译过程中,并不排斥译者们使用计算机辅助翻译(CAT)来帮助翻译,比如谷歌翻译、DeepL 等,只要译者能够尽职审阅校对就好,甚至有时候,这些平台会给出一些比手译更合适的参照译法。在这个过程中,这些平台基本上处于参照的地位,并不能有效的形成“信达雅”的译文。

在 OpenAI 的 ChatGPT 横空出世之后,一个最常见的用例就是用来翻译外文内容。我们也做了一些尝试,令我吃惊的是,在经过调校之后,ChatGPT(3.5)可以形成通顺、合理、可信的译文。并且,在经过它的再次润色后,可以更进一步提高译文的可读性。甚至,在个别情况下,它还能找出原文中存在的错误,比如误用的命令。

当然,出于负责的角度,我们会对这些文章进行专门的校对,以免出现被 AI 愚弄的情况。

那么,LCTT 还有存在的必要吗?我认为是有的,一方面,在短期看来,AI 翻译还没有足够成熟,至少在 AI 幻觉没解决之前,并不能完全依赖 AI,尤其是在专业技术领域。另外一方面,AI 确实可以极大地加速翻译过程,提升翻译质量,我们完全可以在相同的贡献者基础上,贡献更多的专业内容。

所以,之后的 LCTT 可能要从“翻译为主,校对为辅”转变为“AI 翻译为辅,专业校对为主”的贡献模式了。顺便说一句,在 Bestony 的努力下,我们已经在开发一个新的 AI 辅助翻译平台,到时候会极大地提升翻译的质量和数量。

那么,让我们期待 LCTT 的下一个十年,一个蜕变的十年吧!

(题图:MJ/2c55f5cf-6867-4e0f-beeb-9858ca51e644)

本文收录了 LCTT 自创和选用的翻译词汇。

为什么要自创翻译词汇?在翻译过程中,我们发现一些非缩写的英语术语沿袭使用了英语单词/短语,而没有得体的、公认的、正式的对应中文翻译。我们认为,中英文混杂是对原生语言的一种污染(英文缩写除外,这是为了减少冗长的语句),按照本地化的宗旨,应该对这些词汇进行翻译,并在必要时创造新的词汇。故此,我们在几年的翻译中,逐渐推敲和形成了一些新的译法,并在我们翻译的文章中使用和推广。

对这些译法,我们尽量遵循“信达雅”的原则。但鉴于水平所及,肯定会有所不足,虽然也有不断的调整和改进,但仍希望得到大家的反馈和指正。

我们采用的方法是:

  • 音似:中文读音近似于英文原词
  • 意近:中文字的意思接近英文原意
  • 组词:根据上述两条组成新的词汇,以避免和原有词汇混淆

此外,需要说明的是,有些译法可能已经被其他人在别的地方更早提出,但限于我们的学识和搜索能力,并未发现和了解到,并非我们故意剽窃。

顺便说一句,2014 年对 “Shebang”(#!)一词翻译时,来自于 LCTT 早期重要贡献者 GOLinux 提出的 “释伴” 译法,是我们第一次创造新的翻译词汇,也是我们形成这样的想法的起点。

除了自创的翻译词汇外,这里还收录了一些选用的翻译词汇。有一些词汇存在多种译法,我们在翻译和使用过程中,采用了某个译法,在此列出以保持一致。

F

Fork:复刻

Fork 行为/操作广泛用于进程管理、版本管理和软件衍生方面。此词汇也长期缺乏确定的译法。

此前,提议者对 Fork 给出了 “复刻” 的译法。基本意思是,根据上游/父本复制一份,然后在此基础上进行修改,从而形成“衍生品”。

有趣的是,我们发现 GitHub 的 部分中文文档 中也采用了此译法,不知道是不是受到了我们的影响。

  • 提议者:wxy
  • 首次链接:</article-7877-1.html>

H

Here Document:现场文档

在编程领域,“here document” 是一个常见的术语,特指在脚本语言(如 Perl、Bash)中,能够直接在代码内部嵌入并处理一个数据块或文本串的技术。尽管传统上我们将它翻译为“嵌入式文档” 或不翻译,但这个译法似乎并不能完全地体现出原文的感觉和含义。

为了让这个概念变得更为直观和易理解,我们建议将 “here document” 翻译为 “现场文档”。“现场”相比于“嵌入式”,更好的传达了文档就在代码的当前位置,或代码“现场”的含义。这样的译法也与原文 “here document” 中 “here”(这里)的含义更为契合。我们希望这个译法能够在未来得到更广泛的使用和认可,让编程的世界因语言的精准而变得更美好。

PS., 该译法和解释得到了 ChatGPT 的建议和生成。

  • 提议者:wxy
  • 首次链接:</article-16298-1.html>

L

Live:立付

Live 原意多指“现场”、“实时”,在计算机环境中使用时也多引用此意。但对它的翻译就颇费神,因为无论是在 Live Patch,还是更多见的 Live USB/CD、Live Session,其实都不好翻译为“现场”、“实时”。

提议者之前曾经尝试创造了新的“临场”词汇,但是感觉有些不够达意。经过推敲,提议者再次推荐使用“立付”,在照顾发音的同时,取其“立时交付”之意。这样,Live USB/CD 可以译做 “立付 USB/CD”,Live Session 可以译做 “立付会话”。

而对于 Live Stream,提议者建议依旧翻译为“直播”、“实时流”。对于 Live Patch,还是采用 “热补丁” 这样的意译。

  • 提议者:wxy
  • 首次链接(临场):</article-12854-1.html>
  • 首次链接(立付):</article-15499-1.html>

Repo(Repository):代码仓库/软件仓库

Repository 主要用于两个场景,一个是用于版本管理的代码仓库,一个是用于分发软件/组件/制品的软件仓库。

鉴于两种场景的差异,建议在使用时,分别注明“代码仓库”或“软件仓库”,也可简称为 “代码仓”或“软件仓”。

S

Shebang [ʃɪ'bæŋ]:释伴

Shebang(也称为 Hashbang)是一个由井号和叹号构成的字符序列(#!),出现在脚本文件的第一行的前两个字符,后跟解释器路径,如:#!/bin/sh,这通常是 Linux 中 shell 脚本的标准起始行。

长期以来,Shebang 都没有正式的中文名称。提议者将其翻译为:“释伴”,即解释伴随行的简称,同时又是 Shebang 的音译。(关于这个词汇的翻译,在下面的首次链接中有其它的建议和讨论。)

  • 提议者:GoLinux
  • 首次链接:</article-3664-1.html>

Shell :交互界面

Shell 是 Unix/Linux 等系统的 shbash 等命令行的接口程序,包括 DOS/Windows 的 command.com/cmd.exe 等其实也属于此类,只是通常不这样称呼。

这个词汇也是一个一直没有翻译而径直使用的计算机词汇。我们也没有见到(找到)合适的翻译。但是我们在 LCTT 译者 CanYellow 翻译的一篇文章中见到他将其翻译为 “交互界面”,我们认为这是一种好的翻译。

  • 提议者:CanYellow
  • 首次链接:</article-15469-1.html>

说明

此文档会根据建议不断更新,其固定地址为: https://github.com/LCTT/TranslateProject/blob/master/Dict.md ,欢迎大家提交议题或拉取请求来完善它。

九年前,也是这个上午,我创建了 LCTT 及其第一个项目 TranslateProject。从最初只是有感于 Unix/Linux 上的中文手册页实在太糟糕,希望做一些事情;到最后变成了一个以翻译国外各个开源社区的技术文章和开源资讯/讨论的“流水”式项目,LCTT 已经走过了令我自己都非常吃惊的九年。

人的一生,几十年而已,能在一件事上持续投入九年时光,这是我从未想过的事情。驻足回望,LCTT 其实并没有完成我最初的想法,这是缺憾;但是 LCTT 就这样变成了另外一种并非在我计划中的样子,或许也有其必然性。现在看来,LCTT 做了一些事情,也有一些存在的意义。我试着总结一下:

LCTT 的主项目 TranslateProject,选题广泛,参与门槛低,从某种意义上,为初识开源的小伙伴提供一种成为开源贡献者的方式。一些人就是通过这个项目,迈出了成为开源贡献者的第一步,并在日后的学习和工作中,成为了开源爱好者、专业技术人员。

LCTT 持续翻译了数千篇(截至今日,已经翻译发布了 6395 篇文章),这些文章的专业程度横跨了入门到精通等不同难度,内容方向涉猎了开发、运维、使用和文化等各个方面。虽然,有些文章仅堪一读,但也有不少文章值得收藏、一再细读。我屡屡能从读者那里得到反馈,这些文章对他们提供了很大的帮助,我想这就是 LCTT 的存世价值之一吧。唯独可惜的是,这些文章,没有以很好的方式组织起来,甚憾。

LCTT 有数百成员(截至今日,成功地在仓库中进行了贡献的贡献者有 311 位),他们的年龄不等,最年轻的有初中的学生、最老的,嗯这个不需要说了;他们的职业各异,比较多的是大学生,也有很多从事技术工作的专业人员,甚至还有完全不从事技术工作的贡献者。但是,他们都有一个共同的身份就是 LCTT 贡献者,因此,他们都有很多开源兄弟姐妹。

按照惯例,每两年,我会写一篇 LCTT 总结。今年又快到这个时间了,我却有些不知道该如何下笔。恍惚间,我突然想到,LCTT 是一个贡献者组织,是大家的 LCTT,那么,为什么不让大家来为 LCTT 写两句话呢?于是,我在 LCTT 群内发起了号召,请诸位成员写写自己参与 LCTT 的经历、感受或收获,也可以是祝愿、建议。下面,是我收集到的其中一些成员的留言(以留言时的顺序列出):

  • 译者-acyanbird:Linux 中国是我的开源引路人,让我有机会从零开始参与开源社区,认识到了开源精神,见到了世界的另一个可能性。也借此机会参与不少活动,认识了很多开源人士。目前在组长的帮助下,我也开始自己建立社区,十分感谢您给我这个机会~希望我们都越来越好,有更多的人也来一起参与开源
  • 译者-mandeler:LCTT community forever!
  • 译者-Kira-Pgr:For a better open source world!
  • 译者-mengxinayan:LCTT 不仅可以用来锻炼翻译能力,同时有专人进行校对,能有效找到自身不足。此外还可以用来接触新知新方向,最重要的是可以培养自身英文阅读的习惯。Thanks LCTT!
  • 译者-aftermath0703:从 LCTT 我收获到了许多知识,有时间我就会去 GitHub 上读读新的文章,有更多时间我就会去翻译一篇。翻译过程中先自己翻译一遍,再用翻译网站翻译一遍,有偏差的地方相互比对,我觉得这对我的各项英语能力都有很大的帮助。希望 LCTT 蓬勃发展,越办越好!
  • 译者-MFGJT:虽然因为工作原因很久没有翻译了,但是还是每天在看微信公众号。感觉到大家都很努力,希望今年有机会继续参加翻译 ?
  • 译者-stevending1st:加入 LCTT 最大的惊叹是核心贡献者能够做到维护一个几百人的贡献者群体,背后是他们巨大的努力。希望能在 LCTT 不断学习,努力提升自己的能力。也祝愿 LCTT 越来越好。
  • 译者-aREversez:作为一个学翻译的学生,能参与到 LCTT 这样一个项目,了解更多关于开源与技术的知识,见识更宽阔的世界和更深远的历史,让自己能尽己所能为开源贡献一份力量,实属荣幸之至。希望咱们社区能够一直繁荣下去,传播更加丰富多彩的开源技术与思想!
  • 译者-mcfd:LCTT 翻译的许多实用的技术文章,能够简明、易懂地为广大小白答疑解惑,扫除学习、日常中遇到的坑,间接且不断地为开源社区注入生机。清风不解凌云志,明月无声照九州​。
  • 核心-lkxed:在裸辞考研失败之后,我曾一度陷入迷茫。偶然间读到老王写的《如何以翻译贡献参与开源社区》,决心加入进来。自此,我从一个连 Git 和 GitHub 都搞不大懂的小白,成长为一名熟练的译者,又成长为一名熟练的选题。踏踏实实地做好一件小事,每天如此,不正是对抗焦虑和迷茫的好办法吗?感谢开源,给了我这个成长的机会;感谢 LCTT,领着我敲开了开源的大门;感谢老王,在我困惑时指点迷津。祝愿 LCTT 越办越好,我们一路与你同行!
  • 核心-bestony:刚刚专门回到网站上看了一下,我参与 LCTT 已经 8 年了,8 年来,LCTT 见证了我从小透明到半透明,也经历了我人生的三分之一。希望在未来的时间里,我可以和 LCTT 共成长,也可以与 LCTT 共人生。
  • 核心-Locez:今天是 LCTT 的生日,也是我的生日,一种奇妙的缘分。LCTT 是我接触 LC,接触开源以后第一个比较正式贡献的项目,对我来说意义比较非凡,重要的是通过这个项目在 LC 以及 LCTT 结识到了热爱分享的大家,特别是老王,viz,bestony 等人,很感谢大家在我学生时代起,就对我的一些耐心引导与帮助。
  • 译者-robsean:科教兴国,实干兴邦
  • 译者-TravinDreek:作为一位自由软件活动者,我主要从事技术伦理相关文章的翻译。我在 LCTT 的翻译动机,不止在于增进自己对当今技术伦理问题的认识,更在于让人们有机会了解到并利用自由(和开源)软件来应对这些问题。希望 LCTT 今后能在传播 FLOSS 方面起到更大的作用。Happy hacking.
  • 译者-Wlzzzz-del:之前备考考研时,偶然接触到 LCTT。为了多了解一些 Linux 知识,同时提高自己的英语水平,因此选择加入了 LCTT,这也是我第一次参与开源项目。虽然因为很多原因,翻译的文章不多,但是 LCTT 发布的文章我都会认真阅读。在未来我希望能多抽出时间来,参与到翻译活动中来。
  • 译者-Veryzzj:今年年初在朋友的介绍下认识了 LCTT 并参与到了其中,仔细回想 LCTT 的意义于我是什么?是打破开源项目于我的神秘面纱,是从申领到翻译每一篇收获的成就感,是发布了文章感受到的正反馈,是在翻译群中和大家交流时的友好气氛。正是这些点滴,是我对抗生命无意义感的武器。我们用语言打破边界,也用语言拓宽世界。预祝 LCTT 越来越好!
  • 译者-Chao-zhi:加入 LCTT 已经六年了,我已经不记得自己是怎么加入 LCTT 了。但我一直记得我是通过 LCTT 的 wiki 学会使用 GitHub 的。也是通过 LCTT 慢慢了解开源世界的。希望能继续和 LCTT 一起成长。
  • 核心-MjSeven:但愿 LCTT 长久,千里共婵娟
  • 译者-mudongliang:LCTT 是早期我参与的开源项目,通过这个项目我学会了很多开源知识,熟练使用 Git 使用,为后期在内核项目贡献,奠定了坚实基础 ?

说实话,LCTT 和 Linux 中国能走到今天,全赖这些贡献者的支持,这让我每每感觉吃力时,都有了不能放弃的理由。

那么,你是不是也想加入 LCTT 呢?很简单,访问 LCTT 官网:https://linux.cn/lctt/ 即可了解如何成为一名 LCTT 贡献者了。

最后,感谢大家九年来的支持和信任!顺祝大家中秋节、教师节快乐!

熟悉我们的朋友都知道,Linux 中国(https://linux.cn/)的内容以旗下 LCTT 翻译组贡献的内容为主,间或有一些朋友私下投递的稿件,嗯,也有一些我们为金主写的软文。不过,近来,常有朋友问,我们是否接受投稿。

考虑之后,在与我的拖延症搏斗中,我终于设置了一个接受投稿的渠道。遵循我们的传统,投稿方式以 GitHub 协作的方式来进行:

投稿约定

投稿者递交投稿即表示 接受 以下约定:

  • 投稿者应拥有其所投稿件及稿件内图片的完整版权,如因此出现的任何版权纠纷,由投稿者承担相应责任。
  • 投稿者所投稿件采用 CC-BY-SA 协议发布。
  • 投稿者及其委托方不得对提交的投稿,及「Linux 中国」发布的投稿提起版权异议。
  • 「Linux 中国」有权在其发布平台(包括但不限于 Linux 中国的官网、微信公众号、知乎等)声明原创,并享有相应的原创权利。
  • 「Linux 中国」发布投稿不向投稿者收取任何费用,也不向投稿者和任何利益相关方支付任何费用。

投稿方式

请按照模板创造你的稿件,默认模板为:templates/article.md

  • 稿件接受 Markdown 格式
  • 投稿文件名格式:“日期 英文标题.md”,例如:20220222 How To Make Live.md
  • 投稿请发送拉取请求到 contributions 目录,标题为文件名
  • 文章内图片请自行放置于图床,并引用
  • 文章要求至少有一张符合要求的题图
  • 提交投稿后,我们会对稿件内容提出修改意见,符合标准后才会发布

内容要求

我们接受纯技术投稿,也接受非技术投稿,但是不接受广告内容。比如:

  • 包括 Linux 在内的开源技术,如编程、运维、架构、安全、DevOps、云计算、Linux 桌面、开源软件、操作系统等
  • 关于开源文化、历史、思考等
  • 与开源有关的最新新闻、事件等

如果文章内容和投稿方存在利益相关,可以在文末对相关产品、事件做简短说明。

如果是个人投稿者,可以在文末做简短介绍。

另外,我们只接受简体中文投稿,如是其它语言,请自行转换。

最后,感谢您的投稿和贡献!

就如我们之前报道的,因为对 Linux 内核提交了一些作用不明的补丁,并疑似以 Linux 内核作为其研究论文的试验场,Linux 内核社区决定撤销该大学所有近 200 个补丁贡献,并将明尼苏达大学“拉黑”。

此事件曝光并发酵之后,引来了全球技术社区的大量关注、抨击和一些反思。之后,明尼苏达大学计算机科学系表示暂停该研究项目,而陷入此事件的三位研究人员更是一时之间处于风口浪尖,招致了大量批评甚至谩骂。

此事件中的主要负责人 Kangjie Lu 助理教授昨日发表了一篇英文公开信进行澄清,我们将其翻译并点评如下,如有表达不到位或误解之处,敬请参照原文

这封信是由此事件中三位研究人员联合署名发表的:

Kangjie Lu, Qiushi Wu, and Aditya Pakki
University of Minnesota

其中 Kangjie Lu 是负责该项目的助理教授,而 Qiushi Wu 和 Aditya Pakki 都是 Lu 助理教授带的博士生,其中 Qiushi Wu 是那篇论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》的一作,而 Aditya Pakki 不是该论文的作者,但是是引发这场争议的补丁提交者。

信件开头首先对 Linux 内核社区致歉:

亲爱的社区成员:

我们为我们的研究小组对 Linux 内核社区造成的任何伤害真诚地道歉。我们的目标是找出修补过程中的问题以及解决这些问题的方法,我们非常抱歉,在“伪君子提交”论文中使用的方法是不恰当的。正如许多观察家向我们指出的那样,我们犯了一个错误,在进行这项研究之前没有找到咨询社区并获得许可的方法;我们这样做是因为我们知道我们不能向 Linux 的维护者征求许可,否则他们会对伪装者的补丁进行监视。虽然我们的目标是提高 Linux 的安全性,但我们现在明白,让社区成为我们研究的对象,并在社区不知情或未经其许可的情况下浪费其精力审查这些补丁,是对社区的伤害。

我们只想让你知道,我们绝不会故意伤害 Linux 内核社区,也绝不会引入安全漏洞。我们的工作是抱着最好的目的进行的,都是为了寻找和修复安全漏洞。

然后介绍了该研究项目的情况,并进行了澄清:

“伪君子提交”的工作是在 2020 年 8 月进行的;它的目的是提高 Linux 中修补程序的安全性。作为项目的一部分,我们研究了 Linux 打补丁过程中的潜在问题,包括问题的原因和解决这些问题的建议。

按 Lu 助理教授的解释,这个“伪君子提交”的研究已经于 2020 年 12 月结束,并且用于研究而提交的三个补丁也只是在邮件列表讨论中进行的,从未获得进入 Linux 内核的机会。而且,Linux 内核社区是知道这件事的。

  • 这项工作并没有在 Linux 代码中引入漏洞。三个不正确的补丁是在 Linux 留言板的交流中讨论和停止的,从未提交到代码中。在提交论文之前,我们向 Linux 社区报告了这项工作的发现和结论(不包括不正确的补丁),收集了他们的反馈,并将其纳入论文中。

Lu 助理教授还提到,这次事件发酵而招致 Linux 内核负责人 GKH 全部撤销的 190 个历史补丁,是和该项目无关的,是出于善意和服务提交的。但是这个事情发展到现在,按照 GKH 的说法,要对这 190 个补丁进行重新审核,不过这个工作是在 GKH 自己的仓库内进行,无论审核结果如何,目前这 190 个补丁并没有在 Linux 主线内核中发生变更。

  • 所有其他 190 个被撤销和重新评估的补丁都是作为其它项目的一部分和对社区的服务而提交的;它们与 “伪君子提交”论文无关。
  • 这 190 个补丁是对代码中真正的错误的回应,并且在我们提交时都是正确的 —— 就我们所能辨别的而言。

对于“伪君子提交”所涉及的三个研究性的补丁,正在努力进行披露:

  • 我们理解社区希望获得并检查这三个错误的补丁的愿望。这样做会暴露在留言板上对这些补丁做出反应的社区成员的身份。因此,我们正在努力在披露这些补丁之前获得他们的同意。

对于引发这次事件的几个由 Aditya Pakki 提交的补丁,是和这 190 个补丁无关,也和“伪君子提交”研究无关,是另外一个项目所产生的。

  • 我们最近在 2021 年 4 月的补丁也不属于“伪君子提交”文件的范围。我们一直在进行一个新的项目,旨在自动识别由其他补丁(不是来自我们)引入的 bug。我们的补丁是为了修复被识别的 bug 而准备和提交的,以遵循责任披露的规则,我们很高兴与 Linux 社区分享这个较新项目的细节。

只是这些补丁看起来质量不佳,按 Aditya Pakki 的说法,“它的灵敏度显然不是很高”。正是由于这些糟糕的补丁,引发了 Linux 内核社区的愤怒,并将其和之前的“伪君子提交”研究联系到一起。

在公开信中,Lu 助理教授等继续认错:

我们是一个研究小组,其成员致力于改善 Linux 内核的工作。在过去的五年里,我们一直致力于寻找和修补 Linux 的漏洞。过去对修补过程的观察促使我们也研究和解决修补过程本身的问题。目前这一事件在 Linux 社区引起了对我们、研究小组和明尼苏达大学的极大愤怒。我们为我们现在认识到的违反开源社区共同信任的行为无条件地道歉,并为我们的错误行为寻求宽恕。

并请求社区原谅:

我们寻求从谦逊的角度重建与 Linux 基金会和 Linux 社区的关系,以创建一个基础,我们希望从这个基础上,我们可以再次为我们的共同目标作出贡献,即提高 Linux 软件的质量和安全性。我们将与我们的院系合作,因为他们为寻求在开源项目、同行生产网站和其他在线社区进行研究的师生开发新的培训和支持。我们致力于遵循合作研究的最佳实践,就我们研究项目的性质与社区领导人和成员进行协商,并确保我们的工作不仅符合 IRB(学术伦理委员会) 的要求,而且符合社区在此事件后向我们阐述的期望。

虽然这个问题对我们来说也很痛苦,我们对 Linux 内核社区所承担的额外工作感到由衷的抱歉,但我们从这次事件中吸取了一些关于与开源社区研究的重要教训。我们可以而且会做得更好,我们相信我们在未来还有很多贡献,并将努力工作以重新获得你们的信任。

我的看法

这件事到此算是告一段落了,如果这封公开信披露的信息属实,而 Linux 内核社区也愿意接受的话,那不失一个还算美好的结局。

就我个人的感受,Lu 助理教授的这封道歉的公开信,算得上谦卑,或许心中有所委屈,但还是就能道歉的地方都低头道歉了。在这个事件发酵后,我们其实看到了很多对这个研究团队的、对这些研究人员个人的谩骂和指责,鲜少能看到理智而独立的看法——这还仅仅只是中文社区的一个小角落。所以,可以想象身处美国的 Lu 助理教授和他的学生们会招致什么样的压力和语言暴力。

事实上,初看到这个新闻时,我也非常愤怒,也为其中两位研究人员是华人而感觉蒙羞。但是,在我仔细梳理了内核社区的邮件列表对话、综合了各处信源之后,得出的结论和看法,是和这份公开信相似的。也许 Lu 助理教授他们在此事件中有些不当,但内核社区的负责人的处置也或许有点过激。那么,社区是否真正能做到公平公正和公开决策?作为知名领袖和多年的社区元老,个人所做的处置和反应带来的影响可能要比预想的更高,在决策前是否应该三思?

另外,从这个事件中,还反映出的一个情况是,Linux 内核社区的管理和审核,似乎还是人治为主,对于来自外部的恶意或无意的破坏,应该具有更有效的反应机制。

好了,对于这件事,你如何看呢?

更新

周六深夜,内核团队的 GKH 回复说:

谢谢你的回应。

如你所知,Linux 基金会和 Linux 基金会的技术顾问委员会在周五向贵校提交了一封信,概述了需要采取的具体行动,以便贵组和贵校能够努力重新获得 Linux 内核社区的信任。

在采取这些行动之前,我们不会就这个问题进一步讨论。

谢谢

正如我们昨天报道的,明尼苏达大学的研究人员被踢出了 Linux 贡献群体,Linux 内核社区撤销了之前他们提交的所有 Linux 内核代码,并且,以后默认拒绝所有来自该大学的内核贡献!

发生了什么?是什么让 Linux 内核社区勃然大怒?

这一切始于 2021 年 4 月 6 日对 Linux 内核的一个看似无辜的补丁。明尼苏达大学的一名博士生(Aditya Pakki)提交了一个一共只修改/增加了两行的小补丁

Signed-off-by: Aditya Pakki <[email protected]>
---
 net/rds/message.c | 1 +
 net/rds/send.c    | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rds/message.c b/net/rds/message.c
index 071a261fdaab..90ebcfe5fe3b 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm)
         rds_message_purge(rm);
 
         kfree(rm);
+        rm = NULL;
     }
 }
 EXPORT_SYMBOL_GPL(rds_message_put);
diff --git a/net/rds/send.c b/net/rds/send.c
index 985d0b7713ac..fe5264b9d4b3 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head *messages, int status)
 unlock_and_drop:
         spin_unlock_irqrestore(&rm->m_rs_lock, flags);
         rds_message_put(rm);
-        if (was_on_sock)
+        if (was_on_sock && rm)
             rds_message_put(rm);
     }
 

由于这个补丁很简单,而且似乎改善了代码的质量,它最初得到了一些成员的支持,但后来在 4 月 9 日受到了 Eric Dumazet 的质疑

而在 4 月 19 日,资深的内核贡献者 Al Viro 斥责该贡献者提交了一个“没有修复任何东西的补丁”。他指出了提交垃圾代码补丁的两种可能性:

简单地说,这个补丁要么显示出完全缺乏理解,要么显示出有人不真诚地行事。如果是后者[1],我可以建议尊敬的社会学家们滚蛋,不要再用故意喷出的排泄物来测试审核者了?

如果你觉得他用词太激烈了,这背后是有原因和历史的。

前不久,明尼苏达大学的博士生 Qiushi Wu 和助理教授 Kangjie Lu(看起来是中国人或华裔?)提交了一篇研究论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》。据之前发布在明尼苏达大学的一篇新闻稿(已被删除),该论文被 2021 年 IEEE 安全与隐私研讨会接受:

CS&E 很荣幸地与大家分享博士生 Qiushi Wu 和助理教授 Kangjie Lu 为即将举行的第 42 届 IEEE 安全与隐私研讨会所撰写的论文。IEEE S&P 是展示计算机安全和电子隐私发展的首要论坛,并将该领域的研究人员和从业人员聚集在一起。

他们的论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》集中讨论了开源软件的供应链安全。

“这项工作影响深远,”Lu 教授说,“供应链安全已经成为当今的一个重要话题。我们的论文已经引起了安全界和开源社区的极大兴趣。”

Wu 和 Lu 将在 5 月的虚拟会议期间展示他们的研究。

研究人员正在测试通过伪装提交在开源软件中隐蔽引入漏洞的可行性,也就是说,以看似有益的提交实际上引入了其他关键问题。结合最近发生的一些软件供应链攻击事件,看起来这是一篇很有意义的论文,也难怪会被 IEEE 会议接受。

然而,似乎他们选择了 Linux 内核项目来进行他们的实验来完成论文。Al Viro 发现,Aditya Pakki 的“无用补丁”很可能是这项研究的一部分。

对 Aditya Pakki 提交的另外一个补丁

     }
-    gss_release_msg(gss_msg);
+    if (gss_msg)
+        gss_release_msg(gss_msg);
 }

GKH 警告称,不要浪费内核维护者的时间提交这种补丁,Greg Kroah-Hartman(GKH)是仅次于 Linus Torvalds 的内核项目负责人:

请停止提交已知无效的补丁。你的教授正在玩弄审查程序,以便用一些奇怪的、怪异的方式实现一篇论文。
这是不对的,这是在浪费我们的时间,我们将不得不再次向你的大学报告此事……

显然,这不是唯一引起争议的补丁请求。而 Leon Romanovsky 指出,还有 3 个这样的补丁来自同一个研究人员,并认为这些补丁增加了安全漏洞:

他们故意引入内核错误。昨天,我看了一下从 Aditya 那里接受的 4 个补丁,其中 3 个增加了各种严重的安全 “漏洞”。

面对这些公开抨击,该大学的研究人员 Aditya Pakki 认为自己是受害者,指责内核维护者的态度

敬请停止胡乱指责,这近乎诽谤。

这些补丁是作为我写的一个新的静态分析器的一部分发送的,它的灵敏度显然不是很高。我发送补丁的目的是希望得到反馈。我们不是 Linux 内核方面的专家,反复发表这些言论让人听了很反感。

显然,这一步错了,但你的先入为主的偏见是如此强烈,你提出的指控毫无根据,这种怀疑也不会带来任何好处。

这种态度不仅让人讨厌,而且对新手和非专家也是一种恐吓,我再也不会发送任何补丁了。

这激怒了 GKH,他说:

你和你的团队,已经公开承认发送了有缺陷的补丁,以了解内核社区对它们的反应,并且发表了一篇基于这项工作的论文。现在你又提交了一系列新的有明显错误的补丁,那么我应该对这样的事情怎么看?

它们显然不是由一个有智慧的静态分析工具创建的,因为它们都是完全不同的模式的结果,而且所有这些显然根本没有修复任何东西。 那么,除了你和你的团队在继续通过发送这种无稽之谈的补丁对内核社区的开发者进行试验之外,我还能想到什么?

……

任何有 C 语言知识的人,只要花几分钟就能看出你提交的文件根本没有任何作用,所以认为一个工具创造了它们,然后你认为它们是一个有效的“修复”,这完全是你的疏忽,而不是我们的疏忽。你才是有错的人,我们的工作不是成为你创造的工具的测试对象。

……

我们的社区不喜欢被实验,也不喜欢通过提交已知的补丁来“测试”,这些补丁要么是故意什么都不做,要么是故意引入错误的。 如果你想做这样的工作,我建议你找一个不同的社区来进行你的实验,这里不欢迎你。

正因为如此,我现在不得不禁止你的大学今后的所有贡献,并撕掉你以前的贡献,因为它们显然是以恶意的方式提交的,目的就是为了造成问题。

随后,GKH 撤销了明尼苏达大学提交的大量补丁,GKH 表示:

我一直想这么做,但最近的事件终于迫使我这么做了。

……

这个小组提交的所有文件都必须从内核树上撤销,并需要再次进行审查,以确定它们是否真的是一个有效的修复。 在这项工作完成之前,请删除这些变更,以确保没有问题被引入代码库。

这个补丁集包含了“简单”的修正,还有 68 个需要人工审查的修正。 其中一些不能被恢复,因为它们已经被恢复了,或者被确定其为无效的后续补丁所修复。这证明这些提交的文件几乎都是错误的。

我将和其他一些内核开发者一起工作,以确定这些还原是否真的是有效的变更,如果是的话,以后会重新正确提交。就目前而言,还是安全为上。

我将通过我的开发树进行,所以维护者们不需要担心这个问题,但他们应该意识到,未来任何从 umn.edu 地址来的人提交的文件应该被默认拒绝,除非确定它实际上是一个有效的修复(即他们提供证据,你可以验证它,但是说真的,为什么要浪费你的时间做那些额外的工作?)

对此,你怎么看?

本文参考信息: lore.kernel.org、news.itsfoss.com。