当前位置:主页 > 九龙论坛 > 正文

Linus:“免费”不是最重要的“源代码公开”才是

日期:2021-09-11   

  【编者按】1991年8月25日,21岁的Linus Torvalds(以下简称Linus)做了一个免费的操作系统“Linux”,并在这一天向外界公布这个由“业余爱好”主导的个人项目;如今,全球超级计算机500强和超过70%的智能手机都在运行Linux,因此,8月25日也被许多Linux的爱好者视为Linux线年来,Linus一直领导着Linux内核开发,并在2005年创建Git。在Linux 30周年之际,Linus接受了Tag Consulting创始人&首席执行官采访Jeremy Andrews(以下简称Jeremy)的采访,深入谈起30年来管理如此大型开源项目的经验与思考。

  Jeremy:今天,Linux将迎来它的30周年纪念日。在这段旅程中,你是在什么时候意识到自己所做的Linux并不仅仅“只是一个爱好”的?

  最大的转折点是当我意识到真有人在使用它,并对它感兴趣时,它开始有了自己的生命。人们开始发送补丁,而且我渐渐发现这个系统能够完成的事情远比预想的要多。

  X11大概是在1992年4月被移植到Linux上的,这可以算是又一里程碑式的大动作

  因此,第一版实际上更像在说“快来看!我做了一个新东西”。我当然希望大家会觉得它很有趣,但那时它并不是一个真正严谨且可用的OS。它的存在更像是为了证明概念的可行性,是仅用几个月完成的个人项目罢了。

  Jeremy:你是否曾为自己的许可证选择后悔过?或者曾为其他人/公司从你创造的系统上赚了多少钱而后悔?

  与此同时,我100%地相信许可证是Linux(以及Git)成功的重要组成部分。我始终坚信要让大家都知道自己具有平等的权利且没有人在许可方面享有特权,这对所有人来说都是一件好事。

  我认为GPLv2能够实现“所有人都在相同规则下工作”与“要求人们回馈社区”的完美平衡,大家都受同样的规则约束,非常公平公正

  同样,你的投入也会得到相应的回报。你可以当项目的“旁观者”,但也就失去了项目的控制权;也可以只把Linux当做一个基本的操作系统;但如果你有特殊要求,那么能对项目产生真正影响的唯一方法就是参与进来。

  “任何人都可以维护自己的版本”这一点让一些人对GPLv2产生了怀疑,但我认为这是一种优势。正是这一点保护Linux逃过了分裂的结局:每个人都可以完成自己的项目分支。事实上,这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支,开发者(或公司)要想真正完成项目开发的话,则需要从中分叉出去。

  另一个问题是,大家都想拥有能够支持项目生产的工具,与此同时,心态也一定要强大。将分叉融合回来的障碍,不仅是许可证,还有“Bad Blood”的问题。如果两个分叉从根本上就非常对立的话,那么要想将它们融合是非常困难的——并不是因为许可证或技术原因,而是由于分叉过于尖锐对立。同样,我认为Linux很好地避免了这一点,主要是因为我们一直认为分叉是一件非常正常且自然的事情;当其证明了自身的成功后,自然也要合并回来。

  人们参与到一个共同的项目中来,并真正感觉到自己可以成为这个项目的全面合作伙伴。Jeremy:如今人们在GPLv2下发布源代码,通常都是因为Linux。你是如何寻找许可证的?在审查现有许可证上投入了多少时间和精力?

  但最主要途径的有两个:一是GCC。它对Linux的发展起了很大作用;二是Lars Wirzenius(昵称Lasu),他是当年我大学里另一个说瑞典语的CS同学。Lasu比我更喜欢讨论许可证之类的事情。

  Jeremy:人们通过Linux内核邮件列表进行公开的内核开发,而且流量非常大。你如何兼顾这么多邮件?有没有探索过邮件列表之外的其他合作沟通解决方案?还是说简洁的邮件列表对你的工作而言就是完美的?

  我之前订阅了列表,设置将所有没私人抄送的LKML邮件都自动归档,默认不显示。当有问题需要处理时,我也能找到所有的相关讨论。所有内容都储存在电子邮件中,但只有在需要时才会出现在收件箱。

  Jeremy:3.0内核与之前的2.6.x版发布之间隔了整整八年。自3.0版本发布以来,内核有没有发生什么更有趣的事情呢?

  几十年来,我们推出过许多不同的版本方案以及多个开发模式,但3.0版本最终确定了我们一直以来使用的模式。它真正实现了“基于时间,版本号只是数字,不依附于任何功能”的说法。在2.6版本中,就具备合并窗口的“基于时间”的概念,因此这并不稀奇,但3.0是“最后一片拼图”。

  内核开发的前二十年中,开发模式一路走来经历了很多坎坷,只是在过去十年里,发布的可预测性才大大提高了

  Jeremy:最新版本Linux 5.14即将来临。发布过程的标准化程度如何?例如,什么样的变化会进入RC1、RC2等等?你是在什么时候才会决定特定版本是否可以正式发布?如果版本有错误,在版本发布后宣布撤回的话会发生什么?这种情况的发生频率高吗?这一过程多年来是如何演变的?

  因此,我们形成了相对固定的节奏:在最终版本发布之前,有约两周的合并窗口时间,然后每周约6-8个候选版本,到现在已经有近15年了

  规则没有变过,但不一定完全严格执行:合并窗口是为假定“已经过测试和准备好”的新代码准备的,然后在接下来的约两个月里进行修改,确保所有问题都能得到妥善解决。但有时在发布之前,那些“已经准备好”的代码也会被禁用或彻底推翻,然后从头再来,所以我们大约每10周左右就有一次发布。

  发布了就一定会取得成功么?当然不是。内核一经发布,就会产生新的用户,其中不乏没有参与开发测试的人,而他们常常会发现一些我们在RC中没有发现的问题,这种情况无法避免。这也是我们需要“稳定内核树”的原因之一,它能够在发布后继续添加修复。一些稳定内核的维护时间比其他内核更长,因此也被称为LTS(Long-term support)内核。

  Jeremy:去年11月,有人说你对苹果公司在其新电脑中的ARM64芯片印象深刻。Linux是否仍在支持他们的开发工作?Linux即将到来的5.13内核是否会在苹果的MacBook上启动?ARM64有何重大意义?

  注:在2021年5月,Linux内核5.13-RC1版已实现对苹果M1的初步支持。当前仅支持启动,GPU的使用还未跟上,但也突破了最大的挑战,奠定了坚实的基础。

  最重要的问题并不是ARM64,而是它周围的所有硬件驱动程序(特别是SSD和GPU)

  但不仅仅是苹果的硬件得到了改进,ARM64的基础设施总体上也成长了很多,内核在服务器领域也更有竞争力了。不久前,Arm64的服务器还是一团糟,但亚马逊的Graviton2和Ampere的Altra处理器都是基于改进后的ARM Neoverse IP,这比几年前的产品要好得多。

  所以,这个想法已经酝酿了几十年了,但对我来说,与电脑相比,它们在价格和性能上仍不具备竞争力。希望在不久的将来,这一愿望终能实现。

  Jeremy:在内核中是否有什么不尽如人意的地方,需要彻底重写才能完全解决?内核已经有三十年了,技术、语言和硬件都发生了很大变化,如果现在从头开始重写,你会做哪些改变?

  我们真的非常擅长完全重写,所以如果有不尽如人意的地方也早就被重写了。我们也有很多“兼容”层,但一般无伤大雅。而且尚不清楚如果重写的话,那些兼容层是否会真的消失——它们是对旧二进制文件的向后兼容(通常是对旧体系结构的向后兼容性,例如在x86-64上运行32位x86应用程序)。我认为向后兼容是非常重要的,所以希望即使在重写时也要保持这种兼容性。显然,很多东西都不是“最优选”,都有改进的空间,确实有一些没人关心和清理的遗留驱动,并可能会被利用来做一些坏事,但重点是“没人关心”。所以当问题出现时,我们想要去积极主动解决根源问题——“没人关心”。因此多年来,当架构维护不再具有意义时,我们就会直接放弃整个架构支持。

  Jeremy:如果用Rust这种专门为性能和安全而设计的语言来进行部分重写可以吗?在这种情况下是否还有改进空间?其他像Rust这样的语言有没有可能在内核中取代C?

  特别是驱动程序约占实际内核代码的一半,所以空间非常大,但我不认为有人真的会用Rust全盘重写现有的驱动程序。绝大多数人都会“用Rust做新的驱动程序,在适当的地方重写几个驱动程序”。

  :个人认为是VFS(虚拟文件系统)层,尤其是路径名查找和我们的VM代码。前者是因为Linux在做基础任务时表现确实非常优秀(在操作系统中查找文件名就是操作系统中的基础核心操作)。后者主要是因为我们支持20多种架构,但仍使用基本统一的VM层,我认为这一点非常了不起。但与此同时,这很大程度上取决于“更注重内核的哪一部分”。我个人在VM和VFS领域的参与更多,因此自然也会选择这两方面的内容。

  Jeremy:我发现关于路径名查找的描述比我想象得要复杂。是什么让Linux比其他操作系统“更好”的呢?你提到的“更好”可以怎么理解?

  但要想把这件事做好其实相当复杂。确切地说,因为几乎所有的任务都在不断进行路径名查找动作,所以它对性能高低起着至关重要的作用,而且大家都希望它能在SMP环境中实现良好扩展,但锁定又非常复杂。由于不想做IO,所以缓存非常重要。因此,路径名查找的重要性不言而喻。我们有20多个不同的文件系统,不能将它留给低级别文件系统,如果让它们各自执行自己的缓存和锁定的话,后果将不堪设想。

  所以VFS层重要的原因之一,就是处理所有路径名组件的锁定和缓存,处理所有的序列化和挂载点遍历,这些都要通过无锁算法(Lock-free algorithms,RCU)来完成,但也有一些非常好用的类锁工具(Linux内核lockRef锁就是一种专为DCache缓存设计的特殊“带参考计数的自旋锁”,它有专门的锁感知参考计数,可以在某些常见情况下进行锁消除)。

  最终:底层文件系统仍然需要对未缓存的内容进行实际查找,但它们不需要担心缓存、一致性规则、以及与路径名查找相关的原子性规则。这些都由VFS来处理。而且它的性能比任何其他操作系统都要好,基本可以完美扩展到拥有数千个CPU的机器上,即使这些机器最终都会接触相同的目录。所以Linux dcache是独一无二、无可匹敌的。

  Jeremy:除了Linux,你还创建了Git并移交了这个项目的领导权至Junio Hamano(滨野纯,以下简称Junio),是什么让你这么快做出决定?以及是如何找到并选择他的?

  因为我完全看不上当时市面上大多数源代码控制系统,包括在Linux开发模型中运行得很好的BitKeeper也无法满足我的需求了。相比之下,我做Linux已经有三十多年(加上研究的时间),并且一直在对其进行维护,但我从未想过要长期维护Git。我喜欢使用Git,而且我认为它是目前市面上最好的SCM,但这不是我的热情和兴趣所在,因此,我一直希望由别人来替我维护SCM。

  是一个比较抽象的概念——“好品味”。编程依赖的也是各种细枝末节和每日的繁重工作,偶尔也会需要所谓的“灵感”,即“好品味”,它能干净、漂亮,甚至是完美地解决问题。编程是为了解决技术问题,但如何解决这些问题,以及如何思考也是非常重要的。随着时间的推移,你会清楚地认识到:有些人就是有那种“好品味”,能够做出“正确的”选择。而Junio就具备这种“好品味”。

  找到并信任具备“好品味”的人——这不仅仅是Git的故事,也是Linux的历史。与Git不同的是, Linux是一个我仍积极亲自参与维护的项目;但与Git相同的是,它也是一个有很多人参与的项目。我认为Linux的一大成功之处就在于有数百名的维护者,他们都具备难以言表的“好品味”,齐心协力共同维护内核。

  Jeremy:你有没有过把控制权交给维护者后,却发现这是一个错误决定的经历?

  因此,“谁拥有什么权利”更像是一个流动性指导,以及“这个人很活跃,而且做得很好”。整个结构体系都是流动的,可能你是一个子系统的维护者,但如果你需要另一个子系统的东西,是可以跨越边界的。一般这种情况大家都需要提前进行沟通,但重点是它确实可以实现,这绝对不等同于“你只能动这一个文件”之类的硬性规定。

  Jeremy:作为开源项目的维护者,你学到了哪些重要的经验教训,可以帮助其他人更成功地管理他们的项目?

  因为我真的不知道成功的关键是什么。虽然Linux非常成功,Git也站稳了脚跟,但我很难说二者成功的深层次原因究竟是什么。天时、地利、人和都非常重要。对于Linux和Git来说,最重要的是这两个项目恰好满足了很多人的需求,或者是因为很多人都有这样的需求,但我是唯一一个站出来创建了这样的项目,并取得了成功的人?我个人更倾向于后者,选择很重要,运气也很重要。另一方面,我觉得对于开源维护者而言,确实需要一些务实的精神和思想,这很重要。

  其次,你必须保持开放的心态。我们很喜欢建立一个内部的小圈子,私下讨论问题,只公开最终的结果。但是“开放”也代表要勇于接受别人的解决方案,遇到问题时不要轻易地下结论,思想一定要灵活。Linux成功的原因之一就在于,我并没有制定宏伟的计划,甚至对项目的发展都没有很高的期望,因此当人们向我发送补丁程序或功能请求时,我欣然接受了,因为我对Linux应有的模样没有先入为主的执念。最终结果是,所有希望参与Linux内核开发的个人(以及后来的大公司)都拥有自由发挥的空间,因为我对Linux持开放态度。

  Jeremy:除了上述你提到的有关减少编写的代码量,增加沟通和领导之外,你还需要掌握哪些特定的技能?你又是如何学习这些技能的呢?

  换句话说,这一切都不是我们的计划,也不是从课本上学习来的结果。Linux项目本身是自然发展而来的,如今我们拥有的任何结构都不是来自某种理论的组织结构图,而是人们自发地找到了“自己的位置”。

  很多人都会觉得“放权”很难。其实早年间有人给我发送补丁,但我并没有直接使用,我会阅读他们的代码,搞清楚他们想要什么,然后自己重新写代码。然而事实证明,我这样做并没有什么用,因为我很懒,所以决定在阅读并理解补丁后直接使用。因此,我眷恋权力的日子很快就过去了。信任他们,不要对他们进行过多的微管理。

  另外,沟通技巧非常重要。我出生于一个新闻记者家庭,读书和写作是每个人都喜欢的事情。虽然英语是我的第三语言,但是当我建立Linux项目的时候,已经可以熟练地使用英语交流了。总的来说,大部分时间里,我都是在一边工作一边学习。再说一次,Linux的成功不是一蹴而就。我们经过了三十年的努力,这个项目才有了如今大不同的局面。

  Jeremy:尽管开源取得了巨大的成功,但现状却是有些开发人员每周的收入甚至连买一杯咖啡都不够。你认为这个问题可以得到解决吗?开源模型是否可持续?

  Linux内核开发社区在商业利益方面也取得了一定的成功。Linux一直向商业用户开放,而且我有意避免了“反对企业”的心态。我认为GPLv2是一个非常出色的许可,但与此同时,我一直反对某些极端的“自由软件”形式。

  但是我认为,有些项目可能太过于排斥商业化而陷入了困境,即便有公司希望介入,也很难有机会。虽然和其他公司展开合作并非易事。我们有几个内核维护者一直在非常积极地教各个公司如何使用开源,这也是Linux基金会的一项重任。

  Jeremy:Linux基金会是怎样创建的?你的角色是什么?这个基金会除了让你不必为商业Linux公司工作就可以获得报酬之外,对Linux内核还有什么其他的影响?

  后来OSDL与另一个非营利性行业联盟自由标准组织合并,并成立了Linux基金会。于是,“行业合作”成为了主导力量。而我只是他们的员工,我一直专注于技术内核的开发

  Linux基金会除了支持我们这些核心开发者以外,还构建了各种各样的基础架构,比如一些技术性的架构(),他们还做了很多支持工作,比如组织会议、为行业合作伙伴设立工作组等等。而我只是一名员工,只不过我们之间的协议有点不寻常,因为我所做的一切都必须是开源的,而Linux基金会也不能干涉Linux的开发,这无论是对于我还是其他参与开发的公司都是双赢的状况,因为我不受任何公司政策限制。最快现场开奖报码室