Linux の Rust: 強力なツールですが、適切なバランスをどのように保つのでしょうか?

Linux カーネルに Rust を組み込むことについての白熱した議論は、ハッカー コミュニティでかなり長い間続いています。私たちのほとんどは、それに対する誇大宣伝と躊躇の両方を認識しています。これまでのところ、議論のほとんどは、Rust のセキュリティ上の利点や、既存の C ベースのエコシステムに統合する際の課題など、差し迫った問題に集中しています。Linus Torvalds がこのアイデアに賛同した今、Rust はすでに私たちの愛するオペレーティング システムのソース コードに取り入れられ始めています。

したがって、本当の問題は、Linux カーネルで Rust を使用するかどうかではなく、どのように使用するかです。結局のところ、Rust は単なるプログラミング言語ではなく、本格的な設計哲学でもあります。メモリ破損バグが少ない C のアップグレードではなく、厳格なルールセットを強制するコード記述システムであり、それによって多くの潜在的なミスを防ぎます。これが、Rust を Linux カーネルに組み込むときに留意する必要がある重要な側面であると私は信じています。

効率性と適応性を維持する

組織の両利き性に関する研究によると、Linux のような非常に大規模なプロジェクトは、適応性、関連性、成功を維持するために、次の 2 種類の活動に継続的に従事する必要があります。

1. 活用:効率、改良、実行。Linux では、機能の最適化、バグの修正、既存ユーザーの懸念への対処などのアクティビティを指します。
2. 探索:実験、リスクテイク、イノベーション。これらの活動により、Linux などのプロジェクトは斬新なアプローチを開発し、破壊的なテクノロジーに適応し、変化するユーザーの期待に応えることができます。

研究によると、短期志向の活用活動は長期志向の探索活動を駆逐する傾向があることもわかっています。これは、新しいスキルを習得したい、または型破りなプロジェクトに取り組みたいと思っていても、代わりに常に日常的なタスクを優先するようなものです。同じことは Linux のような大規模プロジェクトにも当てはまります。短期的な効率性を重視しすぎると、長期的には時代遅れになるリスクがあります。プロジェクトが同じままでも世界は変化し続け、その提供物は進化するユーザーのニーズにますます無関係になります。

適切なバランスをとる

一方で、Rust の採用は Linux の探索活動と見なすことができる非常に型破りな実験です。この観点から、Rust の採用は十分に根拠があります。しかしその一方で、あらゆる種類の狂気と未定義の動作を歓迎し、低レベルのハッキングの主力言語となっている C とは異なり、Rust には、特定の構造化されたコード記述方法を強制する内部官僚機構があります。ある意味で、Rust はプログラミング言語とプロセス管理システムの両方として機能し、シックス シグマなどの方法論に似ています。特定の構造化されたコード記述方法は、確かにプロセスを合理化し、セキュリティの脆弱性や信頼性の問題などの短期的な結果を改善するのに役立ちます。ただし、他のプロセス管理システムの場合と同様に、この硬直性は長期的な俊敏性と適応性にリスクをもたらします。

したがって、プロセスを合理化し、より安全にする Rust のメリットは、長期的な適応性がそれほど重要でないカーネル コンポーネントで特に発揮されます。たとえば、デバイス ドライバーは外部入力と直接やり取りするため、メモリの安全性と信頼性の点でリスクの高いコンポーネントです。したがって、Rust で記述するのは理にかなっています。また、新しいデバイスが古いデバイスを頻繁に置き換えるため、寿命が比較的短くなる傾向があります。言い換えれば、Rust の方法論によって探索が減るのではないかという懸念や、コード記述の哲学の変化により最終的に Rust から離れたいと思う可能性は、あまり関係なくなります。デバイス ドライバーを Rust で開発すると、通常、より安全で信頼性が高くなり、他のコンポーネントはこのコード上に構築されません。その結果、数十年後に特定のコードの記述方法を強制されることはなくなります。

対照的に、スケジューラなどのカーネルのコア コンポーネントは、将来の課題や新しいパラダイムに対応できるように適応性を維持する必要があります。これらの領域で Rust を使用すると、調査を妨げ、陳腐化につながる硬直性が生じる可能性があります。次のように考えてみましょう。将来のコードは、現在構築されているコンポーネントに基づいて構築する必要があり、将来的にソフトウェアの記述に関する別の哲学の方が有利であることが判明した場合、柔軟性の高い C コードは、新しいアプローチに変換されるまで段階的に変更されるのが一般的です (段階的な戦略的更新)。対照的に、Rust は独自のコード記述方法に固執するため、古いアプローチで開発を続けるか、ゼロから記述するかというジレンマが発生する可能性があります。フリー ソフトウェアでは、十分な数の資格のある定期的なボランティアと十分な量の定期的な資金を見つけることが常に困難であったことを考慮すると、コンポーネントを捨ててゼロから記述するなどの大規模なプロジェクトに着手することを決定するよりも、段階的な改善の方が常にはるかに簡単です。したがって、特定のコード記述方法を主張する言語は将来的に負担となり、Linux は古いコード記述方法を継続せざるを得なくなり、最先端の地位を失うことになります。

簡単に言うと、セキュリティが極めて重要な短期コンポーネントには Rust を多用し、長期的なコンポーネントにはハードウェアに特化しない最もアジャイルな言語である C を優先して、将来のパラダイムやアプローチに対する柔軟性を維持するというハイブリッド戦略を提案します。