私が systemd ベースの Linux ディストリビューションにこだわる理由

in tech

導入から 10 年以上が経過した今でも、systemd は一部の Linux ユーザーを激怒させることがあります。たまたま私はその一人ではありません。 systemd フリーのディストリビューションを試しても、今後も systemd ベースのディストリビューションを定期的に使用する可能性があります。その理由をいくつか紹介します。

SysVInit は廃止する必要がありました

古いものを捨て、新しいものを取り入れる

の出力 "システム制御ステータス" Arch Linux ターミナルのコマンド。

2010 年代初頭に systemd が初めて登場したとき、多くの Linux ユーザーは、なぜ Linux が使用していた init システムのこのような全面的な見直しが必要なのか疑問に思いました。

img_5cc898db4e3d3

なぜ Linux の systemd は何年も経っても意見が分かれるのか

最初に導入されてから 10 年が経った今でも、systemd は一部の激しい反対者の標的となっています。しかしなぜでしょうか?その暴挙は正当化されるのでしょうか?

古いシステムである System V Init (SysVInit) のルーツは 1980 年代にありました。 80 年代には、Unix システムは現代のマシンとは異なる方法で使用されていました。 Unix は主に大型のミニコンピューターや強力なワークステーションで使用されていました。 SysVInit はサービスを順番に起動するため、起動時間が長くなる可能性があります。当時、ラップトップは珍しかったです。 USB は存在せず、周辺機器は通常、起動の合間に追加したり削除したりするだけでした。通常、システムの構成は実行時を通じて変更されません。システムは一度起動すると、通常は長時間起動したままになるため、起動時間は問題になりませんでした。共有システムでのハードウェアの変更はめったに行われず、「一度行ったら完了」のような体験でもありました。

従来、ハードウェアを追加した場合、たとえ外付けディスク ドライブなどであっても、システムをシャットダウンして再起動する必要がありました。 SysVInit も複雑で、シェル スクリプトが「ランレベル」に対応していました。 Linux がより普及するにつれて、このアプローチは不適切になりました。最新のマシンでは、USB ドライブを接続したり、ラップトップを使用して Wi-Fi と有線ネットワークの間を移動したりすることがあります。 systemd は、そのような「ホットプラグ」ハードウェアに即座に応答できます。

これは、主要なコンポーネントを必要に応じて置き換えることができるという Unix 風のオペレーティング システムのアイデアの強さを証明しています。

systemd は今後も存続します

より良い init システムは最終的には登場するでしょうが、すぐには登場しません

systemd が最初に登場したとき、それに代わるものについてはさらに多くの議論と競争がありました。議論はあまりに白熱し、一部の Linux ディストリビューション開発者は、Linux ユーザーからの絶え間ない攻撃のストレスから辞任しました。

良くも悪くも、主流の Linux ディストリビューションを使用するということは、systemd を使用することを意味します。ドキュメントにはそのことが記載されており、サポートを求める場合、問題が発生した場合は、systemctl ユーティリティの使用が必要になる可能性があります。

systemd は最新の Linux ディストリビューションの実行方法に不可欠であるため、正当な理由がない限り、ほとんどの主要なディストリビューションがこれを置き換える可能性は低いです。

これは突飛なシナリオではないでしょう。 2000 年代に Linux を使用していた場合は、SysVInit システムが永久に存続すると考えたかもしれません。それが気に入らない場合は、BSD のいずれかを使用することもできます。

おそらく誰かが、Linux 開発者がより優れていると考える別の init システムを作成するでしょう。私のお金は、BSD 開発者が独自の老朽化した init システムを置き換えるために作ったものにすべて当てられます。最終的には、systemd にも影響を与えた macOS の launchd のようなものになるだろうと想像しています。

多くの Linux ディストリビューション開発者にとって、systemd は少なくとも「十分な」オプションであるようです。ソフトウェア エンジニアリングを含む多くの形式のエンジニアリングでは、現実世界に合わせて設計するときに、絶対的に最適なソリューションを構築しようとするのではなく、トレードオフを考慮する必要があります。

systemdは私にとってはうまくいきます

信頼性が高く直感的です

の出力 "systemctl --list-units" 指示。

私が systemd ベースのディストリビューションを使い続ける傾向がある理由の 1 つは、systemd で問題が発生したことがないことです。 Linux に関する問題に対する「自分にとってはうまくいきます」という応答はイライラすることもありますが、私自身の使い方では何の不満もありません。

私は古い方法よりも systemd を好みます。 SysVInit はシェル スクリプトとランレベルを管理する必要があるため、私は決して使い慣れていませんでした。サービスの有効化と無効化に関するドキュメントを見るたびに身がすくんでしまいました。たとえそれがデスクトップ システムではめったに行わなかったことであっても、サービスのほとんどはすぐに実行するために必要なものが設定されていたからです。

サービスを有効化、無効化、開始、または停止する必要がある場合は、簡単な systemctl コマンドを実行するだけです。必要なのはそれだけです。

systemd の肥大化が予想されるにもかかわらず、時々サービスを開始および停止するだけのユーザーとして、systemctl コマンドは理解しやすいと思います。

最近、仮想マシンに Arch をインストールしました。 Arch は他の Linux ディストリビューションよりも実践的なため、いくつかのサービスを有効にする必要がありました。必要なのは、いくつかの systemctl コマンドだけでした。

systemd が Arch Linux に十分であれば…

確証バイアス?私は気にしない

Arch Wiki システムの記事。

最終的に systemd を支持するようになったのは、Arch Linux が systemd に切り替えたことです。 Arch は、システムの構成をより詳細に制御できるようにすることで、洗練された Linux ユーザーを対象としているという評判をすでに持っています。どのパーティショニング ツールとブート ローダーを選択するか、デスクトップ環境を選択するか、デスクトップ環境自体をインストールすることさえできます。

ArchWiki Web サイト上の Arch Linux ロゴ。

Arch が私の毎日のドライバーではないのに、それでも使っている理由

ちなみに、私は Arch を実行していますが、毎日ではありません。

Arch Wiki からリンクされている、開発者の 1 人による 2012 年の古いフォーラム投稿を見つけたとき、私はその開発者が説明したケースを研究しました。開発者は、システムで何が起こっているかをすべて知る能力、ホットプラグされたデバイスを検出する能力、systemd のモジュール性、セキュリティ、サンドボックス機能、さらに systemd プロジェクトのクロスプラットフォーム開発を挙げました。

Arch Wiki によると、このディストリビューションの指針の 1 つは「実用主義」です。

Arch はイデオロギー的なディストリビューションではなく、実用的なディストリビューションです。ここでの原則は単なる有用なガイドラインです。最終的に、設計上の決定は開発者の合意に基づいてケースバイケースで行われます。重要なのは政治や世論ではなく、証拠に基づいたテクニカル分析と議論です。

Arch Linux は、テキストベースの構成とユーザーに与える制御量に焦点を当てた「Unixy」Linux ディストリビューションであると常に印象に残っています。 Arch 開発者が、想定される「肥大化」にもかかわらず systemd の利点を理解できるのであれば、systemd は真剣に検討する価値があると思いました。 systemd に対するずっと残っていた不安は消えました。権威のある言い分のように聞こえるかもしれませんが、Arch 開発チームはその成果を通じて私の信頼を得ています。

プロセス管理は私の Linux 使用量のほんの一部です

あまり実践する必要はない

init システムは Linux の重要な部分かもしれませんが、私にとってはほとんどが舞台裏です。 systemctl コマンドの外部で直接操作することはほとんどありません。

一日中プログラムを起動して閉じることがプロセス管理とみなされる可能性もありますが、ほとんどの場合、systemctl を介してプロセスを管理するために systemd と直接対話した回数は片手で数えられると思います。デスクトップ ディストリビューションでは、おそらく 1 回か 2 回でしょう。

Linux ターミナルでの systemd のjournalctl ユーティリティの出力。

どのユーザーもそうであるように、私も時々ログをチェックします。 systemd のバイナリ ログも物議を醸していますが、journalctl コマンドは使いやすいです。 Ubuntu のログの多くは /var/log ディレクトリにミラーリングされているようで、通常のテキスト エディタで調べることができます。

systemdフリーのディストリビューションはあまり印象に残らない

そして、私はたくさんのディストリビューションを試しました

systemd がバックグラウンドにあるという事実は、systemd フリーであることを宣伝するディストリビューションが私にとってあまり印象に残らない理由の 1 つです。最近、EXE GNU/Linux や Obarun など、いくつかを試してみました。ディストリビューション作成者は、自分のディストリビューションに何を入れても入れなくても自由です。

私が HTG のディストリビューションを評価するときは、systemd に賛成か反対かの強い意見を持つ Linux ハッカーではなく、一般ユーザーの立場に立つように努めています。ユーザーエクスペリエンスは、内部の内容よりも重要です。

ディストリビューションは、そのディストリビューションが持つ他のすべての要素に基づいて隆盛するか衰退する必要があります。一部のディストリビューションは、EXE GNU/Linux のレトロなデザインなど、ユニークなエクスペリエンスを提供します。


変化は良いこともある

オリジナルの System V init システムは長年にわたってうまく機能していましたが、コンピューター世界の変化により、モバイル化とオンライン化が進む世界ではついにそれが時代遅れになってしまいました。

systemd の規模や、Red Hat とその親会社である IBM による Linux 開発の優位性について懸念があるかもしれません。

世界は変化し、コンピューター ハードウェアも変化し、それに伴ってオペレーティング システム ソフトウェアも変化します。オペレーティング システムはユーザーにサービスを提供し、プログラムを実行する必要があります。ユーザーが何をするかに合わせて進化する必要があります。それらは博物館の作品にはなり得ません。

このテーマについてさらに詳しく知りたい方は以下をご覧ください

公式情報はこちら

関連記事

前の投稿
Apple Watch が watchOS 27 をサポートしないのが嬉しい 1 つの理由
次の投稿
プライムの費用をカバーするにはどのくらいの頻度で Amazon に注文する必要がありますか