最後の部分を忘れてるよ：「ボナペティ！」これは、人類の歴史の中で、誰かが食糞しろと言われた中で一番丁寧な言い方だね。

本にそれを含めたのは素晴らしいね。「彼らは本当にいいことをしてる」と昔のベチュアナランドで言われてたように。

systemdは時間と共に良くなったし、俺もそれに合わせて良くなったから、今は受け入れられるようになった。でも、SolarisのSMFが恋しいな。もっと良いシステムがあると思うけど、普及してないと特に企業環境では採用するのが難しい。で、家で別のものを使いたいなら2つのことを学ばなきゃいけないから、もうそれだけで俺には多すぎる…

あなたのニュースレターに登録したいな…いや、マジでそれを書くことがあったら読みたい。何か方法で連絡して、俺のGmailのユーザー名はHNのユーザー名と同じだよ。楽しい執筆を！

+1 そういう書き方はきっと受け入れられると思う。俺が見たいのは、systemdにとってのPipeWireがPulseAudioにとってのようなものだ。PulseAudioが出る前は、音をちゃんと動かすのが大変だった。PAは便利な抽象化を導入したけど、最初はバグだらけだった。時間が経つにつれて良くなった。そしてPipeWireが登場して、より少ないものでより多くのことをする。移行はすごくスムーズで、しばらくそれを動かしていたことに気づかなかった。ある日、アップデートログで見つけたんだ。今のsystemdは十分に動いているけど、蓄積されたゴミを取り除けたらいいな。

これらは細かいポイントだけど、ざっくり言うと：1. systemctl status nginx.service で十分な場合が多いよ。journalctlはもっと深く掘り下げたいときに使うもので、オプションもたくさん必要になる。もしこれが統一されてたら、「CLI引数がうるさい」って文句言ってたかもね。2. これをどう解釈すればいいのか分からない。合計の引数が多すぎるってこと（2a）？それともmanページやヘルプメッセージの順番が正しくないってこと（2b）？（2a）。サービスだけ気にするなら、すでにいくつかのサブコマンド（start, stop, enableなど）を知ってるし、それを使えばいい。他の引数は邪魔にならないよ。例えば、普段使うコマンドには安全で常識的なデフォルトオプションがあって、99%の確率で上書きする必要はない。さらに、異なるユーティリティがあって、それらの間で複雑なやり取りを解決しなきゃいけないよりは、ずっといいよ。時には、単一のことだけをするアプリケーションはうまくいかないこともあるしね。（2b）。これは主観的な意見かも？私はイランで数週間のインターネットの完全なダウンを経験したことがある。その時はmanページやオフラインのリソースを調べなきゃいけなかったけど、システムドキュメントの幅広さや深さ、整理には（非常に）満足してるよ。LLMの時代では、これが問題になることは少なくなったと思う。よく知られたユーティリティのmanページを読むのは日常的なタスクじゃないし、特別なケースの時にはmanページをgrepすることになるだろうしね。3. あなたの意見は~有効だと思う。でも、automountは一時的なリソースのために存在するよ。デフォルトでは、少なくとも何らかの予防策なしに失敗したドライブには触れないからね。だから、失敗が早くてリトライしないのは必ずしも間違いじゃないかも。もしかしたら、これは美徳のアピールかも… 私のPCでは、マウントが失敗したら何もリトライしたくないし、実際、検出されないようにブートが失敗するのを望むかもしれない。さらに、マウントのような重要なことには、他にも「スマート」な動作（ネットワークの指数バックオフ、メール、アラート、DBのフェイルオーバーなど）が必要だと思うし、これには特定のアプリケーションの知識が必要だね。だから…彼らは足元を撃つのを防ごうとしてるんだ。

「systemdハイターのハンドブックを書きたい。なんで？ systemdは本当にUnixハイターのハンドブックにぴったりだから。すべてを支配する一つのコマンド、バイナリログ、などなど。結局、GNUはUNIXではないというマントラが本当のように思える。GNU/Linuxを見てみて：pulseaudio、systemd、polkit、wayland、大きくて太いLinuxカーネル。」

不一致は、著者が「このinitのことは古くて、ばかげた回避策やハック、不一致でいっぱいだ。これを直すぞ！」と思っていることから来ている。時間が経つにつれて、「あ、待って、特別なケースのためにハックを追加しなきゃ、これも、これも、これも、実際に必要だったんだ！」と気づくことになる。正直、これは誰にでも起こりうることだし、特にキャリアの初期にはね。でも、本当の傲慢さは、物事が理由もなくそのままであると仮定することだと思う。物事が実際にどう機能しているのか、またその理由を知らないままでいることもね。私は、著者がsystemdを始めたときの現代のinitシステムに対する理解がある素人を想像する。その人は複雑な歯車のシリーズに近づいて、ペグが理由もなくそこにあると思って、使われていないように見えるから引き抜く。すると、全体がめちゃくちゃになる。これは、時刻管理やDNSなど、半端に実装されたサービスが正しく動かず、ちょっとしたことでおかしくなることにも当てはまると思う。著者が今の知識を持って、ゼロから書き直したら、もっと良くなるかもしれない。でも、どうやら「Linuxを直す！」という考えにまだこだわりがあるみたいで、実際にはこれらの修正が非常に複雑さを生み出して、ほとんど利点がないんだよね。だから、どんな書き直しもおそらく過剰に複雑な装置になるだろう。

私もsystemdが好きだよ。長い間使っていると、「なんで？」って思う瞬間も、決定の裏に少なくともそれなりの理由があることが分かってくる。

1. systemctlはコントローラー。ユニットの状態を変更したり報告したりするのが仕事だ。journalctlはクエリエンジン。クエリエンジンをsystemctlに統合すると、コントローラーが膨れ上がって複雑になるから、専用のツールがクリーンなアプローチだと思う。あと、ジャーナルを取り出して他のツールを使うこともできるから、systemctlにログを組み込むのは悪手かも。
2. systemdはサービスマネージャーだけじゃなくて、システムマネージャーでもある。古いinitシステムだけじゃなくて、マシンのコア状態を管理する他のツールの集合も置き換えたんだ。
3. サービスはプロセスを実行するけど、いろんな一時的な理由で失敗することがある。再試行するのは賢明で効果的な回復戦略だよ。マウントはカーネル内の状態を定義する。失敗した場合、ほとんどは「ハード」な理由で、すぐに再試行しても解決しない。失敗したマウントを再試行するのは、時間の無駄で、ブート中にログをスパムするだけだね。

その問題は「systemd2」みたいなラッパーで解決できるかもしれないけど、君の言いたいことはよく分かるよ。問題を解決するために必要な最小限の変更を考えるのが好きなんだ。これが役立つかも。多分、30分以内に大半をLLMで処理できると思うよ。