systemd をほぼ置き換えた 4 つの Linux init システム (および失敗した理由)

Linux ユーザーが init システムについて議論になると、通常、会話は systemd に戻ります。 systemd は、1980 年代以来ほとんどの Unix 系システムを動かしてきた老朽化した SysV init システムに代わるより良い代替手段をディストリビューションが探していたとき、Linux エコシステムが多くの実験を行っていた時代に誕生しました。

SysV init は機能しましたが、そのシーケンシャルな順序と原始的な依存関係管理のため、明らかな制限がありました (このことを嫌いにしないでください)。そのため、多くのプロジェクトがブート プロセスとサービス管理モデルを最新化しようと試みました。速度を重視するものもあれば、正確性、ミニマリズム、または依存関係の処理の改善を重視するものもあります。これらのプロジェクトのうちいくつかは実際に注目を集めましたが、Linux エコシステム全体のデフォルトにはなりませんでした。

最終的には、systemd が有力なソリューションとして浮上しましたが、その過程で、いくつかの有力な候補が迫ってきました。ここでは、systemd をほぼ置き換えた 4 つの Linux init システムと、それらが最終的に勢いを失った理由を紹介します。

成り上がり者

Canonical が開発したイベント駆動型の初期化システム

クレジット: ウィキメディア

2006 年から 2015 年の間に Ubuntu を使用したことがある場合は、Upstart を使用したことになります。 Canonical によって開発された Upstart は、古い SysV モデルをイベント駆動型のアーキテクチャに置き換えました。起動スクリプトを 1 つの固定された順序で実行するのではなく、サービスはシステム内で起こっていることに反応します。

これには、ファイルシステムが利用可能になる、デバイスが検出される、ネットワークの準備が整うなどのイベントが含まれます。これにより、サービスを非同期で開始できるようになり、ブート パフォーマンスが向上し、起動プロセスがより動的になりました。当時、これは SysV init からの大きな進歩でした。

Ubuntu は早い段階で Upstart を採用し、Ubuntu は最大の Linux ディストリビューションの 1 つだったため、多くの人は Upstart が Linux の新しい標準になるだろうと思っていました。数年間、それが後継者として有力視されていましたが、後継にはならず、プロジェクトは立ち消えになりました。

関連している

Ubuntu がデスクトップにはイライラする選択肢だが、ラップトップには最適な理由

Ubuntu は悪いディストリビューションではありません。間違ったマシンで使用しているだけです。

なぜ失敗したのか

Upstart はブート プロセスを最新化しましたが、初期化とサービス管理に限定的に重点を置いたままでした。一方、systemd はその境界を超えて急速に拡大しました (それが、systemd を嫌う人がいる理由です)。これまで別のツールで処理されていたロギング、デバイス管理、タイマー、サービス監視、ユーザー セッション、その他のコンポーネントが統合されました。

大きな転換点は 2014 年に起こり、Debian が Upstart ではなく systemd をデフォルトの init システムとして選択したときでした。非常に多くのディストリビューションが Debian に依存しているか、そのパッケージを共有しているため、その 1 つの決定がエコシステム全体の勢いを変えました。

最終的には Ubuntu も切り替えられ、Ubuntu 15.04 では Upstart が systemd に置き換えられました。 Upstart は技術的には有能なソフトウェアでしたが、主要なディストリビューションが他のもので標準化すると、関連性を維持する可能性はほとんどありませんでした。

OpenRC

従来の SysV モデルの控えめな改良

クレジット: ウィキメディア

OpenRCOpenRC は、より保守的な道をたどりました。 OpenRC はブート プロセス全体を最初から再設計するのではなく、従来の SysV モデルを改良しただけです。

Gentoo は OpenRC をデフォルトとして採用しており、Alpine Linux は現在でも OpenRC を使用しています。従来の Unix 慣行との互換性を維持したシンプルなデザインを好むユーザーの間で忠実な支持を得ています。私は個人的にはこれが好きですが、Fedora に興味があるので、systemd にこだわります。

なぜ大きくならなかったのか

OpenRC は、システム管理の他の領域への拡張を意図的に避けています。その設計哲学はミニマリストにとって魅力的ですが、システムの影響力は制限されます。 systemd がほぼすべての統合プラットフォームを構築している一方で、OpenRC はブート スクリプトとサービス スクリプトに重点を置き続けました。

統一されたフレームワークを必要とするディストリビューションに対して、systemd はより完全なソリューションを提供しました。 OpenRC は完全に消滅したわけではありませんが、ほとんどが小規模なエコシステム内にとどまっています。

ルニット

非常に小型で予測可能なサービス監視システム

runit は OpenRC よりもさらにミニマリズムを進めています。このシステムは、シンプルな 3 段階のブート プロセスを中心に構築されています。サービスは軽量の監視ディレクトリを通じて管理され、各サービスはアクティブな状態を維持する独自の専用監視プロセスの下で実行されます。

全体のデザインは小さく、予測可能です。隠された動作はほとんどなく、抽象化もほとんどありません。 Void Linux はデフォルトの init システムとして runit を使用しています。これは、最新の Linux ディストリビューションが systemd なしでも完全に機能することを示しています。

なぜ大きくならなかったのか

ルニットをエレガントにしているのと同じミニマリズムにより、その範囲も制限されます。 runit はほぼ完全にサービスの監視に焦点を当てており、他のことは何もしようとしません。完全なシステムを構築するには、それに基づいていくつかの追加ツールを組み立てる必要があります。この種のモジュール設計は特殊な環境には非常に適していますが、大規模な導入の可能性は低くなります。

関連している

Void Linux とは何ですか?また、そのユニークな点は何ですか?

虚空に向かって叫ぶのはやめて、それをコンピューター上に置いてください。

s6

サービス監視に対する高度に構造化されたアプローチ

クレジット: ウィキメディア

s6 は、サービス監視をスクリプトのコレクションではなく正式なシステムとしてアプローチします。これは、プロセスの監視、依存関係の管理、および信頼性の高いサービス状態遷移のための構造化されたフレームワークを提供します。このシステムは、正確性、決定論的な動作、および慎重に定義された障害処理に重点を置いています。

多くの init システムとは異なり、s6 はプロセスが正しく監視され、サービスのライフサイクルが予測可能であることを確認することに重点を置いています。純粋に技術的な観点から見ると、多くの開発者は init エコシステム全体の中で最もクリーンな設計の 1 つであると考えていますが、クリーンなデザインが常に勝つとは限りません。

なぜまだニッチなのか

このような厳格さのマイナス面は、複雑さです。これは私たちのようなマニアには問題ありませんが、systemd の比較的単純な宣言型ユニット ファイルは、ほとんどのユーザーにとってはるかに扱いやすいものです。一般的なディストリビューションのメンテナやシステム管理者にとって、s6 はより急な学習曲線をもたらします。

その結果、s6 は、主流の Linux ディストリビューションではなく、特殊な環境、組み込みシステム、またはコンテナ インフラストラクチャに現れる傾向があります。

なぜsystemdが勝ったのか

生態系の調整が大きな役割を果たした

systemd が成功した理由はいくつかありますが、最も重要な要因はエコシステムの調整でした (Red Hat の膨大なリソースが単に他の企業が太刀打ちできないほど大きすぎたかどうかの判断はあなたにお任せします)。

2010 年代初頭までに、Linux ディストリビューションはサービスの管理方法における多くの断片化に対処していました。ブート スクリプト、ロギング システム、デバイス マネージャー、セッション マネージャーは、まったく別のプロジェクト用に開発された疎結合コンポーネントであることがよくありました。

systemd は、これらの責任の多くを 1 つのフレームワークの下にまとめました。これにより、ディストリビューションは 1 つのサービス マネージャー、1 つのログ インターフェイス、1 つの依存関係モデル、および 1 つの構成形式を標準化できます。 Fedora が systemd を採用し、2014 年に Debian がそれに続くと、Linux エコシステムの大部分はすぐにその後ろに並びました。

パッケージ管理者はデフォルトで systemd ユニット ファイルの出荷を開始し、ほとんどのドキュメントでは systemd コマンドを使用することを前提としていました。それが大きな要因でした。ディストリビューションごとに異なるコマンドを覚えるよりも、いくつかの systemctl オプションを覚えておく方が簡単です。

また、サードパーティのツールとオーケストレーション フレームワークが直接統合され始めました。その時点で、ネットワーク効果は、いかなる代替手段でも克服することが非常に困難になりました。

systemd が依然として物議を醸している理由

スコープと Unix 哲学をめぐる議論

systemd はあらゆる場所で採用されているにもかかわらず、現代の Linux の歴史の中で最も物議を醸しているプロジェクトの 1 つです。批判は通常、その範囲に戻ってきます。伝統的な Unix の哲学は、それぞれが 1 つのことをうまく実行する小さなツールを奨励します。代わりに、systemd は、ロギング、ネットワーキング コンポーネント、デバイス管理、サービス監視など、さまざまな役割を 1 つの統合フレームワークに統合します。

これを支持する人々は、この種の統合により信頼性が向上し、システム管理が簡素化されると主張していますが、批評家は、単一のプロジェクトに多くの機能が集中しすぎ、システム全体がより複雑になるだけだと主張しています。 systemd がなぜこれほど多くの議論を引き起こすのかを理解する簡単な方法の 1 つは、systemd がどれほど大きいか単純に見てみることです。

次のようなコマンドを実行してみてください。

find /usr/lib/systemd/ -type f | wc -l

tree /usr/lib/systemd/ 

最新のディストリビューションのほとんどでは、結果は非常に大きくなります。このディレクトリには、より広範な systemd エコシステムを構成する何百ものユニット ファイル、ヘルパー、ジェネレーター、およびサポート コンポーネントが含まれています。支持者は、これをシステム管理を簡素化する統合プラットフォームとして見ています。批評家は、コアが急速に拡大し、多くの従来の Unix ユーティリティに取って代わると考えています。

より小規模なエコシステムには代替手段がまだ存在する

現在でも、すべての Linux ディストリビューションが systemd を使用しているわけではありません。プロジェクトによっては、設計理念に合わせて異なる init システムを意図的に選択する場合もあります。 Alpine Linux は OpenRC に依存し、Void Linux は runit を使用し、Devuan などのプロジェクトは非 systemd init システムを中心に構築された環境を維持し続けています。

この多様性にもかかわらず、より広範な Linux エコシステムは主に systemd で標準化されています。ほとんどの主要なディストリビューションにはデフォルトで同梱されており、周囲のツールやドキュメントの多くはこれが存在することを前提としています。人々がそれを評価するか批判するかに関係なく、systemd は最新の Linux で最も影響力のあるインフラストラクチャの 1 つとなり、その範囲は拡大し続けています。

• 

  価格

  799ドルから

  ブランド

  フレームワーク

  ラップトップを自分で組み立てて、まさに欲しいものを手に入れ、部品が古くなったら交換します。

  
  

• 

  ブランド

  フレームワーク

  CPU

  AMD Ryzen AI Max 300 シリーズ

  グラフィックス

  AMD Radeon統合

  メモリ

  32GB+ はんだ付け LPDDR5x

  ストレージ

  2x M.2 NVMe SSD スロット

  マザーボード

  ミニITX

  Framework Desktop は、Framework チームによってゼロから構築されたモジュール式の mini-ITX デスクトップです。 AMD Ryzen AI Max 300 シリーズ プロセッサを実行するように設計されたマザーボードには、はんだ付けメモリ、2 つの M.2 NVMe SSD スロットが搭載されており、オペレーティング システムとして Windows または Linux を選択できます。