25 年間の Linux カーネル開発経験から要約された 9 つの経験についての簡単な説明

原文: 25 年間の Linux カーネル開発から得た 9 つの教訓
著者: グレッグ・クローア・ハートマン
翻訳: ヤン・ジンハン

Linux カーネル コミュニティは 2016 年に 25 周年を祝い、プロジェクトの長寿と成功の秘密を尋ねるために多くの人が私たちを訪ねてきました。私はいつも笑いながら、25年も経ったとは本当に知らなかったと冗談めかして言います。このプロジェクトは常に意見の相違や課題に直面してきました。しかし、真面目な話、私たちがこれを実行できるかどうかは、コミュニティが反映し、変化する能力と大きく関係しています。

約 16 年前、ほとんどのカーネル開発者はお互いに会ったことがなく、電子メールでしかコミュニケーションをとっていなかったので、Ted T'so はカーネル サミットのアイデアを思いつきました。現在、カーネル開発者は毎年、技術的な問題を解決するために集まり、さらに重要なことに、過去 1 年間に何が正しかったのか、何が間違っていたのかをレビューしています。開発者は、開発者同士のコミュニケーション方法や開発プロセスがどのように機能するかについてオープンに話し合うことができます。次に、プロセスを改善し、Git などの新しいツールを開発し、コラボレーションの方法を引き続き変更します。

Linux カーネルの成功の主な理由をすべて完全に理解したわけではありませんが、それでも共有する価値のある経験がいくつかあります。

1. リリースサイクルの短縮は重要です

Linux プロジェクトの初期段階では、カーネルの各メジャー バージョンが数年ごとにリリースされていたため、ユーザーは新機能を楽しむまでに長い時間待たなければならず、ユーザーと再販業者にとっては非常にストレスでした。そして、さらに重要なことに、これほど長いサイクルは、一度に多くのコードを統合する必要があることを意味します。非常に多くのコードを 1 つのバージョンに統合するのはストレスがかかります。

サイクルを短くすれば、これらすべての問題を解決できます。新しいコードを安定版に短時間で組み込むことができます。新しいコードをほぼ安定したベースライン バージョンに統合すると、システムへの影響を最小限に抑えながら根本的な変更を導入できます。開発者は、このリリース サイクルを逃しても 2 か月後に次のリリース サイクルがあることを知っているため、コードを時期尚早にマージすることはほとんどありません。

2. プロセスの拡張には分散階層型開発モデルが必要です

昔は、すべての変更要件は Linus Torvalds に直接送られていましたが、オペレーティング システム カーネルほど複雑なプロジェクトを完全に把握できる人は誰もいなかったため、これはすぐに不適切であることが判明しました。非常に早い段階で、カーネルのさまざまな分野のメンテナが、カーネルの一部をその分野に精通した人々に割り当てるというアイデアを思いつきました。たとえば、ネットワーク、ワイヤレス、PCI や USB などのドライバー サブシステム、ext2 や vfat などのファイル システムなどです。これにより、コードのレビューと統合を担当する数百人のメンテナに拡張され、製品の品質を犠牲にすることなく、各リリースに数千の変更を含めることが可能になります。

3. ツールの重要性

カーネル開発は、ソースコード管理システムである BitKeeper が登場するまで、開発者の範囲を拡大しようとしてきましたが、コミュニティの慣行はほぼ一夜にして変わり、Git の登場により、さらなる飛躍がもたらされました。適切なツールがなければ、カーネルのようなプロジェクトは適切に機能せず、自重で崩壊してしまいます。

4.強力な世論誘導モデルは非常に重要です

一般に、上級開発者が提出された変更を拒否した場合、その変更はマージされません。開発者が、数か月前に提出したコードがメーリング リストで拒否されたことを知ると、非常にイライラします。しかし、それはカーネル開発が多数のユーザーや問題に適応できることも保証します。ユーザー コミュニティは、他のグループを犠牲にして変更を行うことはできません。当社にはマイクロシステムからスーパーコンピューターまであらゆるものをサポートできるコードベースがあり、多くのシナリオに適用できます。

5. 強力な「回帰なし」ルールも重要です

約 10 年前、カーネル開発コミュニティは、特定のカーネルが特定の環境で適切に動作すれば、後続のすべてのカーネル バージョンもその環境で適切に動作すると約束しました。コミュニティは、変更によって他の問題が発生したことを発見した場合、すぐに問題を修正します。このルールは、システムのアップグレードによって元のシステムが破壊されないことをユーザーに約束します。したがって、メンテナは新しい機能を開発しながら、このカーネルを継続することに前向きです。

6. 企業が開発プロセスに参加することは重要ですが、特定の企業がカーネル開発を独占することはできません

2014 年 12 月にカーネル バージョン番号 3.18 がリリースされて以来、約 500 社の約 5,062 人の開発者が Linux カーネルに貢献してきました。ほとんどの開発者は自分の仕事に対して報酬をもらっており、彼らが行った変更は彼らが働いている会社に貢献します。ただし、特定のニーズに応じてカーネルを改善することはどの企業でもできますが、他の企業に害を与えたり、カーネルの機能を制限したりするような開発を主導することはできません。

7. プロジェクトに内部境界があってはなりません

カーネル開発者はカーネルの特定の部分に重点を置く必要がありますが、変更が正当である限り、開発者はカーネルのどの部分にも変更を加えることができます。その結果、問題は回避されるのではなく、発生したときに解決されます。開発者はカーネル全体についてさまざまな意見を持っており、最も頑固なメンテナであっても、特定のサブシステムで必要な改善を無期限に棚上げすることはできません。

8. 重要な機能は少しずつ始まります

元のバージョン 0.01 カーネルにはコードが 10,000 行しかありませんでしたが、現在では 2 日ごとに 10,000 行以上が追加されています。開発者が現在追加している基本的な小さな機能は、将来的に重要なサブシステムに成長する可能性があります。

9. 要約すると、カーネル開発の 25 年の歴史は、継続的な協力により、単一のグループでは開発できない共通のリソースをもたらすことができることを示しています。 2005 年以来、1,300 社以上の約 14,000 人の個人開発者がカーネルに貢献してきました。したがって、Linux カーネルは、互いに激しく競争する多くの企業の努力を通じて、大規模な公共リソースに発展しました。

以上が25 年間の Linux カーネル開発経験から要約された 9 つの経験についての簡単な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。