25年Linux内核开发经历总结出来的九条经验

原文: 9 lessons from 25 years of Linux kernel development

作者:Greg Kroah-Hartman

翻译:雁惊寒

Linux内核社区在2016年庆祝了成立二十五周年纪念,许多人来问我们这个项目经久不衰和成功的秘诀。我一般会先笑笑,然后开玩笑地说,我真的不知道已经经历了25年。这个项目一直都面临着分歧和挑战。但是,严肃地说,我们能够做到这一点与社区在反思和改变上的能力有着很大的关系。

大约16年前,大多数内核开发人员互相之间从来没有见过面,我们只是通过电子邮件进行联系,所以Ted T’so提出了内核峰会的想法。现在,内核开发人员每年都会聚在一起解决技术问题,更重要的是,回顾一下在过去的一年里我们做了哪些对的事情,又犯了哪些错误。开发人员可以开诚布公地讨论相互之间如何进行交流以及开发流程如何运作。然后,我们会改进流程,我们会开发像Git这样的新的工具,不断地改变我们的合作方式。

虽然我们现在尚未完全认识清楚Linux内核成功的所有关键原因,但目前还是有一些经验值得拿出来分享的。

1. 更短的发布周期很重要

在Linux项目的早期阶段,内核的每个主版本需要好几年发布一次,这意味着用户需要等待很长时间才能享受到新功能,这对于用户和经销商来说是相当令人沮丧的。而且,更重要的是,这么长的周期意味着需要一下子集成大量的代码。把这么多代码合入一个版本里,压力也是很大的。

更短的周期可以解决所有这些问题。新代码能够在更短时间内合入到稳定版中。将新代码集成到几乎稳定不变的基线版本上,使得能够在对系统产生极小影响的情况下引入根本性的变化。开发人员知道,如果他们错过了这个发布周期,两个月内还会有另外一个,所以他们很少会过早地合入代码。

2. 流程的扩展需要一个分布式的分层开发模型

很久以前,所有的变更需求都会直接转到Linus Torvalds手中,但这很快就被证明是不合适的,因为没有哪个人可以全面掌握像操作系统内核这么复杂的项目。很早的时候,内核不同领域的维护者们就提出了一个想法,就是把内核的其中一部分分配给熟悉该领域的人。例如,网络、无线、像PCI或USB这样的驱动程序子系统、或者像ext2或vfat这样的文件系统。然后再扩展到由数百名维护人员负责代码审查和整合,从而使得能够在不牺牲产品质量的情况下,在每个发布的版本中都包含成千上万的变更。

3. 工具的重要性

内核开发一直在试图扩大开发人员的范围,直到BitKeeper这款源代码管理系统出现,几乎在一夜之间社区的做法发生了改变,而Git的出现带来了又一次的飞跃。如果没有合适的工具,像内核这样的项目将无法正常运转,从而会被自身的重量压垮。

4. 强大的舆论导向模式很重要

一般来说,如果一个开发大咖拒绝了某个提交上来的变更,那么这个变更将不会被合并进去。如果开发人员发现自己在几个月前提交的代码在邮件列表中被拒绝了,那是非常令人沮丧的。但这也保证了内核开发可以适应大量的用户和问题。没有哪个用户社区能够以牺牲其他群组为代价而进行变更。我们有一个可以支持从微型系统到超级计算机的代码库,它可以应用在很多场景上。

5. 强大的“无回归”规则也很重要

大约在十多年前,内核开发社区承诺,如果给定的内核在特定的环境中能正常运行,那么所有后续的内核版本也能在这个环境中正常运行。如果社区发现某个变更导致了其他问题的出现,他们会很快地解决这个问题。该规则承诺用户:系统升级不会破坏他们原来的系统。 因而,维护者很愿意在开发新功能的时候延续这个内核。

6. 公司参与到开发流程中来是至关重要的,但没有哪家公司能够主导内核开发

自2014年12月版本号为3.18的内核发布以来,有将近500家公司的大约5062名个人开发者为Linux内核做出了贡献。大多数开发人员因为他们的工作而得到了报酬,而他们所做的变更是为他们所在的公司服务的。但是,尽管任何一家公司都可以根据具体需求改进内核,但是没有哪家公司可以主导开发去做伤害别人或者限制内核功能的事情。

7. 项目中不应有内部界限

内核开发人员必须专注于内核的特定部分,但只要修改是合理的,那么任何开发人员都可以对内核的任何部分进行修改。从而,问题在产生的时候就会被解决掉,而不是规避掉。开发人员对整个内核有很多各种各样的看法,即便是最顽固的维护者也不能无限期地搁置任何指定子系统中所必需的改进。

8. 重要的功能是从一点一滴开始的

原来的0.01版内核只有10000行代码; 而现在每两天增加10000多行。开发人员现在添加的一些基本的、微小的功能未来可能会发展成为重要的子系统。

9. 综上所述,25年的内核发展历史表明,持续地合作可以带来共同的资源,这不是单单某个小组能够开发出来的

自2005年以来,来自1300多家公司的约14000名个人开发人员对内核做出了贡献。因此,Linux内核在很多互相之间有激烈竞争关系的公司的努力下,发展成为一个规模庞大的公共资源。

作者:程序师 来源:http://www.techug.com/post/9-lessons-from-25-years-of-linux-kernel-development.html

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2017-06-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏漫漫全栈路

R.I.P. :传统整体式架构 VS 微服务

我咨询了十几个微服务项目。有些人表示,微服务真棒(这是未来!),而有些人很沮丧(谁发明了这个废物?)

1412
来自专栏成猿之路

掌握3个搜索技巧,在 GitHub快速上找到实用软件资源

原文:https://www.toutiao.com/i6589788915316556296/

883
来自专栏美团技术团队

初探下一代网络隔离与访问控制

概述 安全域隔离是企业安全里最常见而且最基础的话题之一,目前主要的实现方式是网络隔离(特别重要的也会在物理上实现隔离)。对于很小的公司而言,云上开个VPC就实...

5037
来自专栏熊二哥

《大型网站技术架构》学习笔记-01概述

李智慧老师的大型网站架构已经买了两年了,之前大体看过一次,不过还未内化为自己的本领,最近项目空闲,决定尽力掌握这部分的知识,以跟上大师的节奏。今天是儿童节,祝自...

2755
来自专栏安恒信息

邮箱安全第7期 | 邮箱大数据分析平台与异常预警模型

上一期我们谈到通过WEB应用防火墙技术来防护邮箱系统自身的安全问题,由此解决了应用层防护不当导致的邮箱系统被黑客技术入侵的问题,本期我们介绍针对邮箱系统整体大数...

41910
来自专栏java一日一条

并发用户数与TPS之间的关系

在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因...

1821
来自专栏Java后端技术栈

“杀”一个程序员不需要用枪,改三次需求就可以了!

在很多软件公司,特别是一些创业型的团队中,对于这样的情景可能大家都很熟悉:项目经理或者产品经理(产品狗)口头或者简单记录一下软件产品的大致要做的功能,直接就让研...

1131
来自专栏大数据文摘

超贴心 :一份简单明了的营销分析软件包测评

2095
来自专栏IT大咖说

从业务变迁到研发犯难,微服务在Spring Cloud的实践之路

摘要 本次演讲是由链家网基础架构部高级研发工程师刘思贤带来基于Spring Cloud的微服务实践经验分享。 ? 回到2015年 在2015年,我受朋友的邀请加...

35310
来自专栏IT大咖说

微信支付大规模前端开发背后,如何用外包解决困境

摘要 业务高速发展离不开各种配套运营系统的高效建设,微信支付也不例外。在前端人力极其匮乏的条件下我们另辟蹊径,大规模引入外包团队协同作业,并且在如何保证效率和质...

4426

扫码关注云+社区

领取腾讯云代金券