限られたリソースの中では、実用性が勝ることもあるよね。ブルースには、（正当な）感情を脇に置いて、チームやコミュニティ全体のために最善を尽くしたことに拍手を送りたい。

UnixFromScratchやデスクトップでのYear of Unixを楽しみにしてるよ。LinuxがますますSystem Dという過剰なソフトウェアウイルスに売り渡されていくのが残念だね。

https://github.com/systemd/systemd/tree/main/src/core、1678のCファイルには見えないな。

runitは5474行のソースコード。ほとんどのソースファイルは100行未満だよ。すごくうまく動く。initシステムを実装してるけど、DNSやsyslog、inetdなどを置き換えるわけじゃない。systemdは、構造上Unixを置き換えるデーモンのセットなんだ。理想的な組み込みシステムのセットアップは、カーネル、systemd、そしてそれが動かすコンテナ（podmanなしでも）だよ。これは特にRed Hatのビジネスラインを考えると理にかなってるけど、Unixの設計やゼロから物事を学ぶこととはあまり関係がないね。

Linuxは文字通り62,000個のCファイルから成り立ってる。Linuxの仕組みを理解するためにかける時間は、systemdのそれを圧倒するよ。少なくともsystemdを勉強する時は、より現代的なinitシステムのアプローチを学べるから。

System Vの死は避けられないと思ってるよ。あれはLinux時代の古い遺物だし、systemd専用にするのが必ずしも良い選択とは限らない（実用的な観点からは理解できるけど）。System Vの代わりにもっと小さくてモジュール化された、より良い選択肢があるから、あの複雑なシェルスクリプトの絡み合いなしにUnixの「感覚」を得ることができる。OpenRCがSystem Vの代わりに採用されるのを見てみたいな。Upstartは死んでるみたいだけど（ChromeOS以外では）、それでも十分だったと思う。残念ながら、私はLFSのためにこれらのツールを維持する時間も知識もないし、誰かがその大変な作業を引き受けない限り、LFSはsystemd専用になってしまうだろうね。とはいえ、もちろんフルのsystemdにする必要はないよ。

私にとってLFSはシステムがどう機能するかを学ぶことだ。ちょっとだけ口を挟ませて。あなたが言っているLinuxは、実際にはLinuxプラスsystemd、最近私が呼んでいるように、Linux/systemdなんだ。Linuxは単独のオペレーティングシステムではなく、systemdコアライブラリ、systemdデーモン、完全なOSを構成する重要なsystemdコンポーネントによって機能する完全なsystemdシステムの一部に過ぎない。 -- https://mastodon.social/@fribbledom/116002799114521341

SysVInitはデーモンを起動するためにランレベルスクリプトを悪用していて、これは常にデーモン間の依存関係を解決するためのハックだった。LinuxやUnixをゼロから学ぶ際に、粗雑なハックを使うべきじゃない。

SysVinitは、post-systemdの世界では一種の神秘的な混合物として見られているけど、ちゃんと説明されると、明確で人に優しいものだと思う。新参者でも簡単に理解できるしね。この決定が残念だという意見には賛同するよ。

sysvはゴミだね。Unixの哲学が「一つのことをやって、それをうまくやる」なら、sysvはその一つのことをうまくやってない。サービスを実行することとは関係ないツールでsystemdをオーバーロードするのは好きじゃないけど、systemdは「サービスを実行する」こと（それに加えて「マウントサービスが起動する前にちゃんと動いてるか確認する」とか「死んだら再起動する」とか、サービスやユースケース特有のことを百もこなす）をすごくうまくやってる。過去20年で4つの異なる代替手段を使ったかもしれないけど。

この話には関係ないけど、anti-systemd派が「Unixの哲学に従ってないから嫌い」って言ってるのが面白いよね。でも、彼らはWaylandも嫌ってる傾向がある。Waylandはその哲学に従ってるのに、クソ重いモノリス（Xorg）から離れてるのに。

逆に、Unixの哲学には全然共感できない。結果を重視するし、ドグマには興味ない。systemdでサーバーを管理するのは、sysvinitで管理するよりずっと快適だよ。ツールがsysadminの生活をこれだけ改善してくれるなら、純粋さのルールを破っても全然気にしない。

ゼロからシステムを学びたいなら、自分で小さなinitシステムを作るのが一番だよ。そうすれば、ブートシーケンスがどう動いてるか理解できるしね。Linuxの高度な機能をどんどん使うようになると、initシステムもどんどん複雑になって、systemdに似てくるよ。sysvinitだけを学んでそこで止まっちゃうと、現代のLinuxディストリビューションがどうブートしてサービスを管理してるかの大部分を見逃しちゃうよ。

LFSの学術的な価値を考えると、Unix/Linuxデザインの重要な歴史的要素が置き去りにされてるのが悲しいよ。まるで研究室や博物館の一部を閉鎖して、学生にそのギャップを埋めるための資料を自分で用意しろって言ってるみたいだ。

SysVは長い間、変な盲点だったな。オフィスで使ってたOpenBSDサーバーにdaemontoolsをインストールしたのを覚えてる。使いやすかったからね。Linuxの世界がその特定の機能戦争でWindowsに負けないように切り替えると思ってたよ。

オープンソースのティーパーティーが「UNIXのやり方」がないって嘆くのは、いつも少し面白い。実際の歴史的経験を持ってる人（誤ったノスタルジーじゃなくて）が視点を提供してくれるからね。ちなみに、X11は元々良くなかったし、その理由を説明する章がUNIX-HATERSハンドブックにあるよ。

LFSは、物事の仕組みに興味がある人向けっぽいね。systemdの支持者は、マニュアル車を運転したい理由を疑問に思うような人たちで、「もちろんオートマか、もっと言えば自動運転車を選ぶべきだ」って言いそう。そういう意見がAIの使い方とどう重なるのか、ちょっと興味あるな。

ちょっと堅苦しいけど、systemdはMacOSのlaunchdからインスパイアされていて、Windowsのサービスからではない。レジストリみたいなものは全くないし、マイクロソフトもそれがWindowsで面倒だって認めてる。ああ、普通はWindowsに対していろんな理由で文句を言うけど、OSのコア機能のいくつかはしっかりしてて、Linuxの人たちもヒントを得るべきだと思う。OSレベルでのサービスの概念とか、ただのランダムなbashスクリプトでバイナリをnohupしてるわけじゃないんだよ。あ、待って、それがWindows、MacOS、Linuxとsystemdのやり方なんだけど。

こういうことがGNU Hurdにもっと勢いを与えるきっかけになるのかな。最近、64bitをちゃんとサポートするようになったってアップデートを見たし、またアクティブに開発が進んでるみたい。どうやらSysVInitを使ってるらしい。

systemdの（ひどい）モノリシックデザインの背後には、ディストロ間の標準化を強制する意図があったのかな。選択肢は技術的というより政治的だったと思う。init、DNSリゾルバ、サービスコントロールマネージャー、ボリュームマネージャーなどの異なる選択肢があれば、今のスキゾフレニックなディストロの状況に悪影響を与えることになる。systemdだと、全てか無かの取引だよね。良い面も悪い面もあるけど、全てのディストロが同じように問題を抱えてる。Windowsですらこうはならない。「systemd」に相当するものはない。そう、Windowsは単一のOSとして出荷されるし、BSDもそうだけど、すべてのコンポーネントは別々に開発されてる。もし彼らが求めていたのがサービスコントロールマネージャーだけなら、すでに存在する（もっと良い）選択肢がたくさんあったはず。

GentooのOpenRCはすごく良いよ。ゲーム用にフル最新のWayland KDE PlasmaとPipewireのセットアップがある。OpenRCは最近、セッション開始後にユーザーとして動作する「ユニット」、つまりサービスを追加した。多くの新しいGUIユーザー空間アプリケーションがいろんなことに依存してる。成長痛もあるけどね。https://bugs.gentoo.org/936123 特に上流がsystemdを強く要求してる時は。実際の理由がないのにそれがあるのはもっとイライラする。でも、進む道はあるし、systemdが常にあると思い込む前に、systemdなしで動くソフトウェアを作ることを試してみることを強く勧めるよ。

Alpine試してみた？「デスクトップ」OSとして設計されてるわけじゃないけど、ちゃんと機能するよ。全体を理解するのも簡単だし、デフォルトでOpenRCを使ってるからね。

「俺が欲しいのはinitスクリプトとX11だけなんだけど、状況が厳しくなってきてる。もうsystemdに妥協しちゃったし、好きじゃない。未来にはBSDが見える。FreedesktopはX11を潰そうとしてて、パッチを拒否したり開発者を禁止したりしてる。人気のデスクトップ環境はますますLinux専用のものに依存してる。KDEはPlasmaログインマネージャーでFreeBSDのサポートを公式に削除した（logindの依存関係のせいで）。Gnome 50はX11を完全に廃止する予定だ。シンプルで明るい未来が欲しいなら、戦ったり努力したりしなきゃならないよ。」

systemdでどんな実際の問題に直面してるの？見かける不満は「Unixっぽくない」とか「モノリシックだ」っていう哲学的な批判が多いけど、採用されてる理由があるんだよね。ちゃんと機能するから。タイマーやソケットのアクティベーション、サンドボックス、リソーススライスを管理できるのは嬉しいことだし、スクリプトベースのinitシステムでは設定が面倒なんだ。みんな「systemdは膨れすぎだ」ってウェブサイトのコメント欄で文句言ってるけど、同時にメガバイトのJSクソを読み込むredditのページに書き込んでる。デフォルトのsystemdビルドはライブラリ込みで約1.8MBだよ。それってほんの少しだ。systemdは他のinitシステムに比べて飛躍的に進んでて、強力なツールとドキュメントが揃ってるし、誤解されがちだけど実際はかなりモジュラーで、ほとんどの機能がオプションで制御できるんだ。ディストリビューション間で一貫したインターフェースを提供して、管理者にとっても馴染みやすいツールを提供してるよ。

GNU / Red Hatプラットフォームはそんな感じだよ。Glibcを入れ替えてみて。結局「うちのものを全部使わなきゃダメ」っていう依存関係になるから。

systemdじゃなくてSystemD、なんでみんなそれを勘違いしてるのか分からない。

その甘いRedHatのお金はどこで手に入れたの？なんか取り残されてる気がする。私は幸せにsystemdを使ってるのに、RedHatBucksはどこにあるの！真面目な話、bashやシェルスクリプトのハウスオブカードに戻ることは絶対にないよ。systemdは実際の問題を解決して、ちゃんと仕事をこなす。UNIX信者の夢のようなレゴみたいなものでは達成できないレベルの一貫性がある。私のお気に入りの例は、systemd-resolveとsystemd-networkが実際に連携して、どのネットワークインターフェースでどのDNSサーバーが利用可能か、どの検索ドメインがあるかを示して、ちゃんとDNSルーティングをすることだ。systemdのすべてに満足してるわけじゃないけど、アップグレード後にネットワークが壊れる傾向があるのはちょっと困る。homedについてはまだ納得してないけど、問題を解決することが成功の理由だってことは間違いないよ。

Windows NTにちゃんとしたUNIXサブシステムがあったら、Linuxには手を出さなかったと思う。キャンパスに行かずにDG/UXターミナルを争奪する方法が必要だったから。FOSSとの戦いとは関係なかったよ。

Linuxは今や実質的にsystemd/linuxだ。これが私のsystemdに対する問題なんだ。私は選択肢が欲しくてLinuxを選んだ。哲学はユーザーに選択肢を与えることだった。systemdはそれに反していて、すべてを支配しようとしているし、ますます多くのプロジェクトがsystemdを必要としている。Flatpakもそうだ：もしプロジェクトがFlatpakだけをサポートしていたら、普通にパッケージ化するのは難しいだろう。だから、Flatpakを使わなければ、私は詰んでしまう。systemdが「動くから問題ない」と思っている人たちは、ポイントを見逃していると思う。まるで、dockerコンテナで自分のプロジェクトを誇らしげに出荷する開発者たちのようだ。彼らはパッケージメンテナに適切に提供できないからそうしている。「動くけど」、私のディストリビューション用にパッケージ化できないのは大混乱だから。開発者はすべてのディストリビューション用に自分のプロジェクトをパッケージ化する必要はない。ただ、ソースを適切に提供すればいいだけなんだ。でも、実際にはそれができないことが多くて、Flatpakやdockerを「うまく動く良い代替手段」と見なしてしまうんだ。

世界は広いし、すべての機械工学者が蒸気機関を勉強しているとは思えないし、最終的にはそれが重要だとも思わない。ほとんどの現代のプログラマーはCOBOL60やCommodore BASICを学ばないし、現代の数学者がオイラーやガウスの著作を学ぶこともめったにない。50年前の数学の本だって、現代の学生には理解するのが難しいかもしれない。教育目的で簡単なツールを使うのは有用だと思うけど、SysVinitはほとんどどこでも廃れているから、捨てるのは理にかなってるよね。LFSはドメイン標準よりも、runitやs6-initのようなもっとシンプルなinitを選ぶこともできたはず。