日々、コンピューターは私たちの生活の中でますます重要な部分を占めるようになっています。コンピューターに何らかの問題が発生すると、気分やユーモアに影響します。もちろん、Windows ユーザーはパニック発作を起こしやすい傾向があります。ウイルス ( Linux 万歳! )、HDD のデフラグ、Clean Master for PC の検索とインストール( Linux でもシステムをクリーンアップする必要があります。BleachBit は推奨される代替手段の 1 つです)。最近、一部の Linux ユーザーは systemd と呼ばれる頭痛を経験しています。
さて、本題に入りますが、最近流行っているsystemdに関する興味深い記事を読みました。
Systemdは、（友人の言葉を借りれば）「すべてを統べる一つの指輪」だと考える人もいれば、単に無関心な人もいます。コンピュータが正常に動作する限り、initがXやYをやろうと、systemdが使われていようと、彼らは気にしません。私としては、まあ…initの方が好きだとだけ言っておきましょう。その方がシンプルだと思うからです。
私はここに記事を残します：
始める前に言っておきたいのは、Debian で物事を変更するという決定には非常に不満があるということですが、愛着のあるスパイラルを捨てるつもりは全くありません。私自身は systemd の支持者ではありませんが、議論するトピックについては、できる限り準備を整えて臨むようにしているだけです。systemd を分かりやすく説明するために、開発者がそれぞれの見解を共有しているウェブサイトを参考にします。このサイトは、Debian ユーザーではないものの、systemd を支持していると思われる同僚から教えてもらったものです。それでは、systemd について言われていることを分かりやすく説明していきましょう。
systemdはバイナリベースです
おそらくこれは私たちに最も衝撃を与える側面のXNUMXつです。すべてがバイナリに基づいている場合、ログを介して通常行うことをどのように監視しますか？ この神話がどのようにして生まれたのか私にはわかりませんが、それは絶対に真実ではありません。
systemdは、ほとんどの場合、プレーンテキストファイルを介して構成されます。 カーネルコマンドラインや環境変数を使用して変更できる設定もあります。 構成にはバイナリはありません（XMLもありません）。 シンプルでわかりやすく、読みやすいテキストファイルです。
それはモノリシックであり、すべてを制御します
前述のウェブサイトにたどり着く前に、私は自分でこのように考えたことを告白しますが、その開発者の言うことを読んだ後、私の意見は何かを変えました...
systemd をすべての設定オプションを有効にしてビルドすると、69 個の個別のバイナリが生成されます。これらのバイナリはそれぞれ異なるタスクを実行し、いくつかの理由から慎重に分離されています。たとえば、systemd はセキュリティを念頭に置いて設計されているため、ほとんどのデーモンは最小限の権限（たとえばカーネル機能を使用）で実行され、非常に特定のタスクのみを担当することで、セキュリティ上の脆弱性と影響を最小限に抑えています。また、systemd はこれまでのどのソリューションよりもブート処理を並列化しています。この「並列化」は、複数のプロセスを並列実行することで実現されています。このように、systemd は多くのバイナリ、ひいてはプロセスに非常にうまく分割されていることがわかります。実際、これらのバイナリの多くは非常にうまく分離されているため、systemd 以外でも非常に役立ちます。
69個のバイナリを含むパッケージを、モノリシックと呼ぶのは無理があるでしょう。しかし、従来のソリューションと異なる点は、より多くのコンポーネントを単一のtarballにまとめて配布し、統一されたリリースサイクルを持つ単一のリポジトリでそれらを連携させていることです。
それはUnixのようには見えません
それには確かにいくつかの真実があります。 systemdソースファイルには、元のUNIX行からのXNUMX行のコードは含まれていません。 ただし、インスピレーションはUNIXから派生しているため、systemdには多くのUNIXがあります。 例としては、UNIXのアイデア「すべてがファイルである」があります。これは、systemdでは、すべてのサービスが実行時にカーネルファイルシステムで公開されるというものです。 cgroupfs。 したがって、UNIXの元々の機能のXNUMXつは、組み込みの端末サポートに基づくマルチシートサポートでした。 systemdを使用して、マルチシートのサポートを再びネイティブに導入しましたが、今回は、グラフィック、マウス、オーディオ、Webカメラなどをカバーする今日のハードウェアを完全にサポートします。 実際、systemdの設計は、それぞれに個別の目的がありますが、一緒に使用すると、部分の合計以上のものになります。これは、多かれ少なかれUNIX哲学の中核です。 したがって、プロジェクトの処理方法（つまり、オペレーティングシステムカーネルのほとんどを単一のgitリポジトリに保持する）は、物事を成し遂げるためにBSDモデル（Linuxではなく真のUNIX）にはるかに近いものです（コアOSは単一のCVS / SVNリポジトリに保持されます）これはLinuxでは決して当てはまりませんでした。
結局のところ、何かがUNIXであるかどうかという問題はほとんど問題になりません。 技術的に優れているため、UNIXに固有のものとは言えません。 私たちにとって、UNIXは大きな影響力（実際には最大）ですが、他の影響力もあります。 したがって、一部の領域ではsystemdは非常にUNIXになり、他の領域では少し少なくなります。
それは非常に複雑です...
それには確かにいくつかの真実があります。 現代のコンピューターは複雑な獣であり、それらで実行されるオペレーティングシステムも明らかに複雑であるため、複雑である必要があります。 ただし、systemdは確かに、同じコンポーネントの以前の実装ほど複雑ではありません。 シンプルで冗長性が少ないです。 一方、単純なsystemdベースのオペレーティングシステムを構築するには、従来のLinuxで使用されるパッケージよりもはるかに少ないパッケージで済みます。 パッケージが少ないほど、システムの構築が容易になり、相互依存性や、関連するすべてのコンポーネントのさまざまな動作の多くが解消されます。
シェルスクリプトを使用できません
これは全くの誤りです。起動プロセスにはシェルスクリプトを使用していませんが、それは起動プロセスに最適なツールではないと考えているからです。しかし、だからといってsystemdがシェルスクリプトと互換性がないわけではありません。シェルスクリプトはsystemdサービスやデーモンとして簡単に実行できます。systemdは実行ファイルの内容を全く気にしないため、どの言語で書かれたスクリプトでもsystemdサービスとして実行できます。さらに、systemdのインストール、ビルド、テストなど、私たち自身もシェルスクリプトを幅広く活用しています。起動プロセスの初期段階にスクリプトを組み込んだり、通常のサービスに使用したり、最終シャットダウン時に実行したりと、事実上制限はありません。
ここまでで、主な考え方がいくつか明確になったのではないかと思います。私は変化の推進者ではなく、「すべてを統べる唯一の悪魔」という考え方には疑問を感じていますが、最終的には、それが全く機能しないとは誰も言わないでしょう。systemd を使うと「PC の動作が速くなる」と気づいたユーザーもいますが、それはまた別の議論のテーマです。今のところ、多くのディストリビューションが採用している init システムについて、ここで皆さんの意見を議論していただくことしかできません。もっとも、最も強い反応が見られるのは Debian コミュニティで、この件をきっかけに新たなフォークまで生まれています。好き嫌いは個人の自由ですが、私としては、最終的に Debian の次期安定版である Jessie に搭載される systemd を分かりやすく解説することに少しでも貢献できればと思っています。
私はGUTLの記事を見ました（その記事はDesdeAbreusの記事からの引用でした）。
システム電流？
私は、何かが大きな論争を巻き起こしたときにあまりニュースを読まない人間の一人なので、技術的な詳細については触れずにいたいと思っています。事は…。時々、特定のトピックが純粋に技術的な議論や議論ではなくなり、芸能界のゴシップの 1 つのようになっていると感じることがあります
まず、 systemd VS intelligenceと呼ばれる systemd についてのユーザーの公開の不満、次に Linus Torvalds がsystemd は言われているほど悪くないと言う (そして彼には一理ある)、 uselessdと呼ばれるフォーク...コメントなし...そして簡単に言うと、最後にDevuan が登場します。
彼らが言うほど悪いのか、それほど悪くないのか、それとももっと悪いのかは言いません。私にとってはシステムは問題なく動作していますが、個人的にはinitの方が好みです。ログなど様々なものを整理する方法が好きだからです。でも、systemdがレースホースと呼ばれ、initに取って代わる（つまり、あらゆることをこなす主力システムになるのでしょうか？）のであれば、まあ…変更があまり劇的でなく、ユーザーがそれほど苦労せずに適応でき、システムがより良く動作する（そう、より良く、それだけでは私には十分ではないかもしれませんが！）のであれば、歓迎します！ 😉