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

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

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で処理できると思うよ。

UNIXでは「すべてがファイル」というのは、ネットワークやUNIX System V以降に追加された機能を使うとすぐに崩れるけど、そのミームはまだ通用しているみたいだ。本当に「すべてがファイル」を求めるなら、UNIXの作者たちがPlan 9やInfernoでそれを修正したよ。

WindowsからLinuxに移行する初心者を見てきたけど、一番の痛手はファイルの権限に慣れることと、sudoを使うのが雑になることだね。

1993年の商業Unixの問題は、2025年のLinuxとはまったく違うよ。

それは、UNIXの各文字に1を足すと意味不明なものになるけど、VMSの各文字に1を足すとWNTになるからだ。時代に即した冗談はさておき：カトラーがUnixやDECのEuniceに対して持っていた見解についての実際の証拠はない。これはアーマンド・ステットナーの逸話やウィキペディアの編集、G・パスカル・ザカリーの著作から推測されたものだ。数年前に私と他の人たちがこれについて詳しく説明したよ：https://news.ycombinator.com/item?id=22814012

覚えているのは、Showstopperという本からのことだけだな。 「[カトラー]はUnixのプロセス入出力モデルに対して低い評価を示し、『Get a byte, get a byte, get a byte byte byte』をロッシーニの『ウィリアム・テル序曲』のフィナーレのメロディに合わせて唱えた。」

mboxやpop3についてはあまり経験がないけど（maildirはずっと使ってる）、mboxファイルをパーティション分けする必要があると思う。物理的な郵便と同じことをするからね（それがプロトコルの基盤だし）。rmailはちょっと好きだな。

確かに、vi(m)の嫌いな人のためのハンドブックなんて必要ないよね。それが自然だし。

マルチスレッドがないし、GNUs/ewwの下ではI/Oロックがあって、すごく遅い。もしRMSがCommon Lispを選んでたら、こんなことにはならなかったのに…

1996年にそれに出会ったとき、すごく多くのことを学んだよ（もちろんハードコピーでね）。今では無関係なこともあるけど。新しいLispマシンを作っている人たちもいるよ。 https://opencores.org/projects/igor https://github.com/lisper/cpus-caddr https://interlisp.org/ http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/VLM.html https://github.com/dseagrav/ld http://www.aviduratas.de/lisp/lispmfpga/ https://groups.google.com/g/comp.lang.lisp/c/36_qKNErHAg https://frank-buss.de/lispcpu/ それに、MorelloにはLispマシンっぽい機能も含まれているよ。私の考えでは、新しいハードウェアアーキテクチャを設計するためには、古いものを再現するよりも、ハードウェアアーキテクチャの歴史を知ることの方がずっと重要だと思う。

同様に、shは問題のあるスクリプト言語だけど、少なくとも確実に存在している。 私も昔のこの本のハードコピーを持ってるよ。この本が私のUnix入門だったんだ。DOS/Windows/NTからSunOS、そして後にLinuxに移行する際にね。この本が（ユーモラスに）指摘している多くの問題にもかかわらず、私が引き込まれたのは、上の引用が示唆していることだよ：それはアクセスしやすく、耐久性があり、だからこそ学ぶ価値があったんだ。欠点があってもね。

LISPマシンについて読むのは本当に面白いけど、新しいのを作ってる人はいないね。過去15年か10年の間に、2つのオープンソースのLispマシンOSが作られたけど、Symbolics/LMIマシンの力の大部分はソフトウェア（アプリケーション）にあったから、今でもそれはプロプライエタリコードなんだ。Lispマシンのアプリケーションを再実装するには、かなりの労力が必要だよ。

Lispマシンのハードウェアが提供していたほとんどの利点は、現代のCPUでも一般的な形で提供されてるよ。大部分の利点は、インタープリタをマイクロコードに押し込むことで、実際のデータのためにデータバスをもっと自由に使えるようにしたことなんだ。今では、コアの外部帯域幅に関して擬似ハーバードアーキテクチャを提供する普遍的なicacheがあるし、ガーベジコレクションの一部を行う独自のマイクロコードを持つ別のコアがあったのも利点の一つだった。今では、一般的なマルチコアシステムが普及してるしね。などなど。