SystemDの謎を解き明かす

@xiepあなたのコメントにこれ以上同意することはできません。

@juanfgsを読んでいるのはあなただけのようですが、少なくとも私はあなたに拍手を送りますが、私のコメントにある非常に重要なものを読む必要があります。ここに置くかどうかは関係ありません。

»NIHどこ？ 古き良きレナートはトロールして大きくするのが好きなようです。」

彼がそれを無実の理由で書いたとは思わない。彼はそれがエイプリルフール（機嫌が悪い）の別のレナートジョークであるという事実と、/、/などおよび他のすべてを/に変換することへの情熱を知っていた。 Linux。 🙂

PS：ありがとう、でも英語を練習する必要はありません。6歳の時から英語を使っています。
aaahhそして他のすべてが真実です、それを確認してください🙂

@juanfgs、私は特にこれについてあなたの言葉にあなたを連れて行きます：

«そして現実には、ほとんどのanti-systemdはこのテストに合格しません。それでも、Debian、Fedora、Archlinux、Linuxカーネル、GNOME全体など、何らかの理由で背後にいる人々よりも多くのことを知っている少数の人々がいます。プロジェクトsystemd、SUSE、longなどについて不満を言っていないので、おそらくKDEプロジェクトもそうです。

それでも、彼が達成する唯一のことは、不和や問題などを生み出すことです。 彼らがXorg、NetworkManager、PulseAudioから脅迫されているので、彼らが最終的にBSDに切り替わるのを待つことができないのはそのためです。技術的な無知によるものなのか、それとも文句を言わないためなのかはわかりません。 「」

ですから、あなたによれば、私たちすべての反システム化は有毒で硝子体であり、私たちが達成する唯一のことは不一致や問題などです。 それが私がこの辺りで読むことができた最大の怒りだと言いましょう。 システムの構造上の問題が発生したときに、なぜプロシステムドがわざわざ悩むのかわかりません。これは明らかにある時点で影響を及ぼします。今は何も起こっていない可能性があるためですが、ある時点で問題が発生します。そして、いくつかの反システムは彼らが何度も言った言葉を思い出させ、誰も彼らを止めませんでした、そして多分他のいくつかの反システムは彼らに手を差し伸べるでしょう。

個人的に、私は systemd が好きではありませんが、init を使用しないという意味ではありません。init を使用する必要があるのは、仕事上、その init を使用してマシンに触れる必要がある場合、その処理方法の知識が必要だからです。それ。また、個人的には、私は Archlinux に来て以来、Debian や Gentoo でもそれを使用しています。したがって、systemd を使用しないことで私の視野が偏っているなどと言わないでください。私はそれを使用しており、それがどれほど不自由であるかを知っています。そして、ここフォーラムで誰かを助けなければならない場合は、 DesdeLinux IRC や Debian リスト (これは私が最も長く活動しており、今でも仕事で使用しているディストリビューションです) については、喜んでやります。なぜなら、Linux コミュニティについて私が気に入っている点があるとすれば、それはまさにそれです。たとえ違いがあっても、それは常に援助です。

BSDに切り替えることは可能ですが、systemdが非常に毒性が高く、他のオプションを使用できない場合にのみ切り替えます。その間、Linuxにとどまり、多くの狂気を含むすべての狂気を無効にします。 Cgroupsのもの。

Glibcには、誰も隠すことができないバグがあります。カーネルと何百もの実行可能ファイルに影響を与える巨大なGlibcバグがあります。 Glibcとsystemdの違いは、前者は何千ものソフトウェアプロジェクトをバイナリに変換できるベースであるのに対し、systemdはinitであり、その目的は安​​定した、実績のある、実質的に間違いのない部分になることです。 それだけでなく、Glibcは、何百もの異なるハードウェアアーキテクチャ（CPU）、CPUのさまざまな最適化フラグと固有の特性、さまざまな形式のソフトウェア最適化、systemdよりもはるかに困難で困難な作業に適応する必要があります。 XNUMXつのプロジェクトを同じ規模で比較する方法は実際にはわかりません。

同じことがGCCにも当てはまります。GCCは多くの言語（非公式の言語を含めて合計13）をサポートするコンパイラであり、Glibcと非常によく似た特性を持ち、多くのアーキテクチャ（バージョン70では4.9のアーキテクチャ）、バイナリ最適化をサポートします。フラグ、CPU最適化フラグ、およびその他の多くの機能。 現在、それらは同じレベルの難易度であり、initを備えたコンパイラです。 答えは明白です。systemdがCであり、GCCコードの多くがアセンブラーにあるか、バイナリで動作させるためにアセンブラーを使用する必要があります。これは少し「難しい」ことです。

GCCとGlibcの何が問題になっていますか？ 承知しました。 Linusでさえ彼らに攻撃を与えましたが、GCCとGlibcでは、systemdでは忘れられがちなポジティブなものがあります。つまり、バグが報告され、バグが見られ、バグが修正されています。

その上、ケイ・シェバースがカーネルのコマンドラインを壊しただけでなく、結局のところ「ジェネリックはジェネリックである」ので、それをシャットダウンしたかったことを誰も忘れません。

あなたは間違って読んで分析したと思います（分析は重要です）、またはあなたは自分自身にそれをする機会さえ与えなかっただけです。 212つのプロセスが情報を渡すことはシステムが壊れる理由ではありませんが、ネットワーク制御、ログ、コアダンプなどの動的アクションを持つバイナリがあり、情報を直接initに渡す場合、問題が発生する可能性があり、問題が発生する可能性があります。いくつかのバイナリが壊れた場合、残りを壊す可能性ははるかに高く、それは非常に現実的です、そしてそれが起こった、カーネルコマンドラインが最近クラッシュしました、Nvidia開発者がsystemd-XNUMXのおかげで持っていたacpi問題、それはすべてです私が言うことのサンプル。

@ anonymous、LinuxでTTYの問題がどのように進化するかを知りたいだけです。 CONFIG_VTコードが出てきたら、VTをXNUMXつの明確に区別された部分（カーネルスペースとユーザースペース）に分割するために、ユーザースペースからVTを制御するためのツールが必要になります。そこで、systemd-consoledは、残りの部分を引っ張る強い依存関係で遊ぶことができます。システムが機能することを可能にするためだけに、systemdコンポーネントをインストールする必要があることへのディストリビューション。 私が言っているのは誇張ではなく、非常に大きな可能性であり、本当に心配です。 KMSConのような他のプロジェクトもありますが、ほとんどのデスクトップとディストリビューションがsystemdを支持する場合、KMSConのようなものは多くの人が考えるよりも早く死ぬ可能性があります。

@匿名の質問は、CONFIG_VTを削除することは、最終的には（私が読んだものから）合計になるものです。つまり、カーネルではプリミティブのみが残り、残りのツールはユーザースペースにあります。それどころか、悪くはありませんが、カーネルから多くの古いコードが削除され、保守が容易になり、構成がはるかに容易になります（コンソールの完全なKMS / DRMサポート）。 確かに最初は両方のシステムがありますが、長期的には（15〜20リリース）カーネルを終了する可能性があります。さらに早く、多くのツールがそのようなコードをサポートしなくなり、より新しく、より適切にサポートされるコードが採用されます。

さて、systemdがそれを行う場合、50以上はそれを行うことができないので、あなたは言います（私は50以上のアプリケーションを想像します）。 KMSCon（この意味で最も古いプロジェクト）の強い依存関係を見ると、それらはlibudev（すぐにsystemdに結合されるコードであり、サポートされず、それ自体で動作する場合はsystemdと競合します）です。 libdrm、libxkbcommon、libtsm、systemd自体がマルチシートを処理するため、これを見ると、GNU / LinuxOSが問題なく動作するために必要な多くのツールを自分たちで取り込んでいることがどのように形作られているかがわかります。

@匿名確かにあなたが言うことは他の可能性です、eudevはこの点でより大きな力を取り、異なるツールを選択するためのオプションを開いたままにします。

PS：あなたが言うように、VTがfbdevと一緒にKMS / DRMの利点をどのように利用するかを見るのは興味深いでしょう😀

@dariemは、アイデアが浮かぶかどうかを確認するための簡単な方法で説明しました。

あなたが言うことは確かにモジュラープログラムとプロセスから常に期待される振る舞いです。 モジュール性は、XNUMXつのプロセスを分離し、それらが独自のメモリスペースを占有し、何らかの手段（IPCなど）で通信するために実装されました。これにより、問題が発生した場合でも、問題は発生しません。システムは中断することなく機能し続けることができます。 その可能性と現在のコンピューティングに与えられた信頼性の計り知れないマージンのために確かに大きな支持を得た理論。 さて、これは必ずしも真実ではありません（人生は必ずしも美しいとは限りません）、そしてあなたは確かにこれらのイベントの犠牲者であったと思います（これはあなたが使用するOSに関係なくすべての人に確実に当てはまります）、そして私は与えますいくつかの例。

XNUMXつ目はXorg（systemdと同じようにモジュラープロセスです）を使用します。Xorgは、ドライバーに夢中になり、クラッシュしてグラフィックが表示されないままになりますが、システムの残りの部分は引き続き期待どおりに機能します（Blessedmoduleity😀）。 これまでのところ、モジュラープロセスがシステムを壊す必要がないという私たちの理論はうまく機能しています。 しかし（常にいくつかありますが）Xorgが狂気以上のものを提供することがあり、奇妙な理由（マウスコントロールからグラフィックスドライバーまでさまざま）でXorgがクラッシュするだけでなく、最も美しいカーネルパニックも発生します（そして、想像できるピカソのようなモニター上の落書き）、それがどんなにモジュール式であっても、プロセスが別のプロセスと情報/データを相互通信して交換し、それらのXNUMXつで何かがうまくいかない場合、そして何らかの理由で、エラーを正しく処理できず、データが間違っているか単に破損しているという単純な事実のために、問題のプロセスが影響を受ける可能性が高くなり、それが大惨事になります。

これが起こり得ないと思われる場合は、Xorg、mesa、nouveau、およびカーネルのdrm / kmsドライバーにある古いエラーのバグレポート（XNUMXつはDebianの私のもので、写真がXNUMX枚あります）を残します。 **別々に実行し、モジュール式**であるため、少なくとも状況下では、一緒に実行してもうまくいきません。

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619

次に、systemdを使用して説明するもう160つの例を示します。 私たちの古いSysvinitには、古いにもかかわらず、非常に信頼性が高く、/ etc / fstabにパーティションエントリ（システムにとって重要ではない、/ mnt / DiskXNUMXGBを理解する）があり、それができなかったという特徴がありました。何らかの理由でマウントされた場合、マウントは単にスキップされ、警告メッセージが表示され、ブートプロセスが続行されました。 さて、systemdは別の話ですが、そのモジュール性にもかかわらず、/ etc / fstabにエントリがあり、何らかの理由でsystemdがそれをマウントできないことがわかった場合、パーティションが使用可能になるのを待つだけではありません（通常のプログラムされた動作） ）アセンブリのためですが、時間が終了すると、システムが停止し、リカバリモードに入り、その行を/ etc / fstabから削除する以外に何もできなくなり、実際にはかなり失敗します。 ブートの自動マウント中にその小さな詳細はなくなり、プロセス全体が停止します。最初は（systemd-）ダンプが表示されたばかりで、再起動する必要があったため、小さな詳細は見苦しくなりました。 詳細を調べた人があなたに話します。

私が挙げることができるもうXNUMXつの例は、systemdのcoredumpdです。 coredumpdは、デフォルトですべての情報をジャーナルに渡し、ジャーナルがキャプチャした情報をディスクに書き込むようにします。これまでのところ、systemdのモジュール性を活用しています。 しかし、コアダンプが非常に大きく、数GBを占める可能性がある場合、コアダンプからジャーナルに、そしてディスクに情報を渡す過程で、Xorgが機能しなくなり、カーネルさえも機能しなくなるなどの奇妙なことが起こることがあります。パニック。 それはもちろんsystemdで発生するだけでなく、その設計方法によって障害要因が増加し、他の不快な詳細（メモリ消費の増加、ログの破損、不完全なダンプなど）が作成されます。KDEコアダンプを使用する必要がある人は誰でも、確かにこのようないくつかのエピソードを経験し、ダンプパーティションの/ etc / fstabに同期オプションを含めることの重要性を理解しているでしょう。ダンプを処理するために他のオプションを使用できないという事実は確かに嫌いです。 systemdがインストールされています。 systemd-coredumpdで起こりうることの例。

https://bugs.archlinux.org/task/41728

さて、終了するには：

それらはモジュラープログラムとプロセスであるはずではありませんか？ はい、それらはモジュール式です。 カーネルは私がここで話した唯一のモノリシックなものですが、モジュール（LKM）も受け入れるので、基本的な設計形式はそのタイプの構造で設計されていませんが、一種のハイブリッドカーネルになります。そのため、特定の状況では少し不安定になります。

そのモジュール性により、何か問題が発生した場合にプロセスとシステムがクラッシュしないようにすることはできませんか？ 確かに、モジュール性は高度な安定性と信頼性を実現するために設計された手段ですが、100％確実な手段ではありません。何かがうまくいかない場合は、どんなにモジュール化されていても、単にうまくいかないからです。現実。

カーネルに追加されたcgroupやその他のオプションの使用を可能にするために、どのsystemdがすべてを制御する必要がありますか？ 完全に誤り。 これはまったく必要ありません。systemdには、現在のサービスの数を引き継ぐことなく、システム内にあるプロセスとデーモンへのcgroupの起動と割り当てを制御するインターフェイスが残されている可能性があります。その最良の例は; OpenRCはcgroupを使用することもでき、そのためにそのタスクを実行するために侵入することはできません。

systemdについて話すとき、私は何に偏見があり、恐れていますか？ 彼がどこからそれを入手したのかはわかりません。私の答えを見ると、私はそれを恐れていません。サードパーティの意見に頼らずに、systemdについて私が嫌いな側面についてのみ話します。

最後に、「プログラマーが予期しない入出力を処理できるコードを含めないのが苦手だったとしたら、それは別のことです...」と言います。

確かに、誤ったデータ入力が原因でプログラムが壊れる可能性のあるすべての方法を処理するコードを含まないプログラマーは悪いと言っても過言ではありません。 彼がどんなに優れたプログラマーであっても、人は間違いのないフェイルセーフプログラムを設計することはできません。常に失敗があり、それは何らかの形で明らかになります。それが実現した場合、それは使用中のランダムな障害、脆弱性を悪用するハッカーまたはクラッカー、コードのレビューと監査、またはプログラマーが信頼できるその他の手段。 そのようなことを言う前に単語を測定する方が良いです。

ご挨拶。