ただ、標準は二面性がありますよね。みんなが「最も正しい」答えに同意するのには素晴らしいですが、進化を止めてしまうこともあります。あなたの標準が現代のユースケースをサポートしないとどうなるのでしょうか？例えば、現代のセキュリティプラクティスと真っ向から対立していたら？FHSは何年も変わっていません。その間に、サンドボックス、コンテナ、新しいパッケージスキームなどが登場しているのに、FHSはそれについて何と言っているのでしょうか？

うん、でもそうじゃない部分もあるよね。どのディストロも独自のファイルシステムレイアウト標準を定義してるし、確かに最初はFHS 3.0の共通の祖先から始まったけど、それ以降はいろいろな方向に分かれてる。最近の競合する標準もそれを修正しようとしてるし（主にUAPIグループね）。それに、UAPIがsystemdのアイデアを他に押し付ける手段だって言う人もいるけど、10年以上も標準を更新しないで、他の人がその作業を引き継ぐのも嫌なら、どうして自分たちの標準を作ることに文句を言えるのか、わからないな。 [1]: もっと正確には20年だけど、10年前にLinux Foundationがその所有権を引き継いだんだよね。

これは典型的なsystemdメンテナの行動だね。Poetteringの「私はあまり問題だとは思っていない」は伝説だよ： https://github.com/systemd/systemd/issues/5644

そのような却下へのリンク： https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112535#64

Devuanっていうのがあるよ。Debianだけどsystemdなしのやつ。個人的には「ネイティブ」に非systemdのディストロの方が一貫性があると思うけど、Guixで幸せを見つけたよ。

同じ記事を読んだの？ * 古い動作のオプションがあるよ。 * それはセキュリティの問題で、代わりにより良い解決策が存在する。 * FHSはメンテナンスされていない。関係者全員が、問題を修正するアプリケーションの更新を望んでいると思う。Debianは今のところ、ユーザーの信頼性を選んでいるから、彼らのミッションステートメントに合っている。Archでは、/run/lockはスーパーユーザーだけが書き込み可能で、セキュリティが向上している。ユーザーとしては、信頼性とセキュリティを重視していて、レガシーツールが使える状態であることを大切にしている（時にはデフォルトで、時にはスイッチで）。

彼らのやり方は最初からそうだったし、彼らにとってうまくいっている戦術を変える理由はないよね。systemdの中心的な問題は、彼らがあなたが自分のやり方で進めるのを許さず、彼らのルールに従わせようとすることだと思う。

この場合、上流のメンテイナーの反応は正当だと思う。--「上流のsystemdはXをする、やりたいディストロはYをしても自由だ」-- 逆のことを考えてみて。もしsystemdが書き込み可能な/run/lockを必要とするなら、安全を重視したいディストロは本当にできなくなるか、もっと侵入的なパッチを実装しなければならないだろう。外から見ると、これはDebianのsystemdパッケージメンテイナーがDebianのルールに従っていない失敗のように見える。（ただ、私はそのコミュニティの一員ではないので、知らない文化的な期待があるかもしれないことは認識している。）

愚痴を言う前にこれだけは言わせて：ハイパーバイザーやVM、非systemdディストロ、Kubernetesを最小限の実行ファイルで動かすために作られたTalosみたいなミニマルな不変Linuxディストロ、OCIコンテナのおかげで、Linuxスタックでもsystemdから抜け出す本当の方法があるのはありがたい。もっと多くの人が再び100% systemdフリーを目指すべきだと思う。 > 誰か教えてくれない？systemdの開発者たちが自分たちの考えを振りかざしてみんなをいじめる理由は？目標はLinuxを支配することだからだよ。だからsystemdはPID1なんだ。だからPoetteringはMicrosoftで働いてる。真の疑問は、あの超複雑なxzバックドアの試みが、なぜsystemdを持っているLinuxシステムでしか機能しなかったのかってこと。人々は「でもこれはこれで、xzがOpenSSHによって読み込まれるようにしたからで、systemdとは関係ない」と言って犬を振り回そうとするだろう。でも、すべてはsystemdに関係してる。もう一つの疑問は、今日、systemdを持つシステムでどれだけのバックドアが稼働しているのかってこと。systemdはMicrosoftレベルの肥大化で、PID1として動いていて、Linuxディストロのあちこちに触手を広げているのは間違いなく意図的だ。Poetteringは本当に耐え難いいじめっ子だね。TFAから: > じゃあ、今後どうすればいいと思う？Debianのポリシーを変更する（#1111839で求められている通り）、systemdの変更を元に戻す、Debian全体の解決策を見つける、または各パッケージメンテナが自分の解決策を実装するのを許す？私はDebianがsystemdを一度でいいから完全に捨てるべきだと思う。Debianはまだsystemdフリーにできるけど、面倒なんだよね。もう一度Debianをsystemdフリーにしてほしい。ちなみに、私はVMでsystemdなしのディストロを動かして、コンテナでsystemdに中指を立ててるよ。ProxmoxをFreeBSDのbhyveハイパーバイザーに切り替えるのが待ちきれない（時間を見つけないといけないけど）。でも何よりも、systemdなしのハイパーバイザーLinux、例えばProxmoxが出てくる日が待ち遠しい。もうすぐ来るし、「Dockerを使わずにsystemdを使え」みたいなことを書く人たちは勘違いしてる。私にとってsystemdはLinuxが象徴するものの対極だ。Debianがいつかsystemdを完全に捨てるくらい怒ってくれることを願ってる。P.S: 私のマシンの一つはこれを動かしてる： https://www.devuan.org/ で、正直言って全然問題ないよ。だから、systemdなしのディストロやBSDを使ってるみんなに力を！

この場合、彼らの「恐れ」は、特権のないユーザーが重要なtmpfsのリソース（inodeやファイルシステムスペース）を使い果たしてシステムを壊すことだと思う。後方互換性のための適切な解決策は、おそらく/run/lockを独自のマウントポイントにすることだろうけど、彼らは自分たちのシステム（Fedora）でそれを修正したから、もう彼らの問題ではなくなったんだ。彼らのソフトウェアがDebianのような奇妙なニッチなオペレーティングシステムに移植可能であることに感謝しなきゃね。/s

Linuxは34歳で、借りたUnixの要素はもっと古いものもあります。実際に厄介な部分があって、デメリットもあります。後方互換性、メンテナンス性、レガシーの問題が引き起こすさまざまな問題の相対的な優先順位は妥当です。systemdは基本的にレガシーの問題に対するフラストレーションから生まれたので、プロジェクト全体が近代化の努力として存在しています。後方互換性が低優先度と見なされるのも無理はありません。

だって、彼らはずっとそうしてきたし、それがうまくいっているから？ systemdは私には合わないけど、ほとんどのLinuxディストリビューションを支配しているから、明らかに私が理解できない何かを人々が求めているんだと思う。それはPulseAudioでも同じでした。

まあ、主要な著者が「同意」を汚い言葉だと考えてるMicrosoftで働いてるからね。

たぶん、みんながそのまま許してるからだと思う。systemdに対する批判があると、すぐに「でも、他のinitシステムで何かを書くのが難しかったから、文句言うのやめて」って反論が返ってくる。だから、最初からSystemdや開発者に対して甘い目が向けられてるんだよね。結局、強制されてるから。

反論：現代のディストロのニーズは、場合によってはFHSを超えて進化していて、みんなが少しずつだけど互換性のない形で逸脱している。現実を反映しない標準は意味がないと思う。実際の使用に合わせて標準を戻そうとするのは、価値のある試みだと思うよ。

まあ、どのソフトウェアがユーザーに重要なディレクトリを埋める権限を与えないようにするポリシーを実装するかによると思う。記事でも話されているけどね。最も一般的なディスクのユーザーはソフトウェアそのものだと思うし、FHSは特にユーザーにディスクを埋める責任とその結果を負わせるようにしているみたい。

/usrのマージは、現代のFHSが反映するかもしれない一例だね。

UAPIグループの「独立した標準」という仮面が崩れたことがとても嬉しい。今やその行動はsystemdの利益に直接結びついているから。

作者です：それは放棄されました。元のメンテナーの一人にリンクしましたが、彼もそう言っていました。現在の取り組みは、LFに引き継いでもらうように頼んだ数人によるもので、初期の活動があった後は（今のところ）ほとんど何も進んでいません。それについては、最近書いたFHSに関する他の記事でも触れています。更新作業を始めたグループができる前は、約10年間放置されていました。それは遅れているのではなく、完全に放棄されています。

Debian PolicyはまだFHSを引用していますが、FHSは10年以上もメンテナンスされていません。 > ファイルシステムの標準にはどんな継続的なメンテナンスが必要ですか？ その手の成功した標準は、解決すべき重大な問題がない限り静的でなければなりません。定期的な変更は、そもそもその標準が対抗することを意図していたものです。2025年ですから、現代と見なされるためには（すべてがそうであるべきですが）、常に変化し続け、定期的に「改善」を提供する必要があります。>>...ただし、FHS 4.0として標準を復活させ、改訂しようとする動きは遅々として進んでおらず、まだ結果は出ていません。 > それなら、放棄されてはいないということですね。遅いプロセスは、ファイルシステム標準のメンテナンスにはちょうど良いものです。FHSの人たちはもっと動くべきです。今の時代、こんなに発展したAIアシスタントがあるのに、そのペースには言い訳がありません。最低でも四半期ごとの更新を推進し、年に一回か二回は大きな変更を行うべきです。「etc」を「config」に、「home」を「user」に、「usr」を「Program Files」に改名する必要があるのは、現代のUXトレンドに追いつくために明らかです。

より中立的な表現にすると、 > Debian PolicyはまだFHSを引用しており、FHSは10年以上も静的なままです。

ファイルシステムの標準にはどんな継続的なメンテナンスが必要ですか？ 要件の微妙な変化への適応 - 今日のセキュリティ関連の要件は非常に異なる - パフォーマンス関連の要件や特性も非常に異なる - 様々なエッジケースへのニーズも異なるし、最後に、うまくいったこととそうでないことに基づいて適応する必要があります。記事でまだ言及されていないいくつかの例を挙げると、 - /boot -- efistubブートを使うと死んでいるか、少なくとも異なる使われ方をしています - /etc/X11 -- waylandでは半分死んでいます - /etc/xml, /etc/sgml -- 死んでいます、私の意見では存在すべきではありませんでした - そもそも、なぜ/etc/{X11,xml,sgml}が標準の明示的な部分だったのか？ /etcの仕様が、例えばX11が使われている限り、すでにそれを暗示しているのに。?? - /media -- ディストリビューションによっては死んでいる/半分死んでいる、/run/media/{username}/{mount}に置き換えられています - /sbin -- 「論争の的」；もはや必要ないという頻繁に繰り返される議論があり、意図した通りには機能しませんでした。非常に古いスタイルのシンクライアントには役立ちましたが、/sbinはストレージにあり、/binはマウントされていました。今でも意味があるエッジケースもありますが、大半は「別の問題のための回避策で、適切に修正する方が良い」です。 - /tmp -- 「論争の的」、セキュリティ問題の長い歴史があり、プログラムごとの/tmpディレクトリがセキュリティ問題を解決します（例：systemdサービスのPrivateTmpオプション）が、「実行中のプロセス」ではなく「プログラム」の概念が必要です（例：systemdサービスやflatpakプログラムによって）。また、tmpfiles.dもここで役立ちます。 - /usr/libexec -- 死んでいます、良いアイデアですが、不要な複雑さを引き起こし、suidなどと組み合わせると非常に誤解を招くことがあります - /usr/sbinは/sbinを参照 - /usr/share/{color,dict,man,misc,ppd,sgml,xml} -- 標準に含まれるべきではなく、/usr/shareの定義によって暗示されています；少なくともsqml,xmlは死んでいます。dictはスペルチェック/オートコンプリート用でしたが、どちらもdictが期待するようには機能しなくなっています - /var/account -- 一部の部分的に死んだプログラムのサブセットに特有すぎて、標準に含まれるべきではありません - /var/crash -- ディストリビューション特有の混乱 - /var/games -- 基本的に死んでいる/セキュリティの混乱、99%のゲームは今日、ユーザーごとにインストールされています（例：Steam）し、パッケージ化されたものでも、可変のダウンロードデータはユーザーごとに異なり、共有すると権限/セキュリティの混乱を引き起こします - /var/lock -- すでに言及したように、今ではより良い技術的解決策があります。例えば、「ファイルの存在」ではなくflockを使用するなど。他にも、クラッシュしたプログラムが「ロックファイル」をクリーンアップしない問題を避ける傾向があります。 - /var/mailは、メールを管理する非常に古い形式を前提としており、特定のプログラムに特有です。非常にプログラム特有なので、私の意見では標準に含まれるべきではありません - 様々なレガシープログラム特有の、非「一般的」なファイルシステム要件、例えば/usr/lib/sendmailが存在し、sendmail互換プログラムへのリンクでなければならないというもの。また、欠けている部分： - /run/user/{uid} - /var/run/user/{uid} - /proc - /sys - ユーザー側のバージョン（例：XDG仕様からのもので、私の個人的な経験ではややゾンビ状態です。例：.config, .local/{bin,share}） - 軽量サンドボックスへの言及、例：プログラムごとの/tempなど - 工場出荷時リセットのためのもの（/usr/share/factory）、Linuxで販売されるデバイスとデバイス特有のディストリビューションのカスタマイズのための均一な方法を持つために必要です（例：steam deck）ので、はい、かなり古くなっています。

昔のDOS BBSにメールを送るために、ここ1、2年使ってるんだ。UUCPパッケージがあったやつね。CentOSとDebianの両方で、すぐに使える状態だったのには驚いたし、Postfixは今でもUUCPメール設定の例を同梱してるよ。

問題は、/var/lockがまだいろんなシステムのルートコンポーネントで使われてることなんだ。lvm2やdmraid、オーディオドライバみたいなサービスが含まれてるから、少なくとも「root」と他のユーザー用で別々の/var/lockが必要になる。だから、今はすべてのルートツールを別のロックフォルダを使うように修正するか、すごく古いツールのほんの一部を壊すかの選択になる。大体、どっちに進むかは明らかだよね；) ただ、もっと調整して、コミュニケーションを良くするべきだと思う。そして、XDF_RUNTIME_DIRのtempfsにクォータを設定したいよね、間違いなく。少なくとも、問題を起こすプログラムに対してもっと頑丈なシステムのためには。正直言うと、2000年代のスレッドモデルに関するセキュリティの懸念は無視されてきたけど、時代は（悲しいかな）変わったし、もうユーザースペースのプログラムを盲目的に信じるべきじゃない。悪意のあるプログラムを無視しても、AIが持ち込むバグのことを考えると心配だよ。デスクトップLinuxがこの変化に適応できるか不安だな。サーバーLinuxは明らかに適応してるけど、非GNUのLinuxエコシステムの方が多いし、FSF/GNUの部分は未来がないように見える。これは間違いなく残念だけど、供給チェーン攻撃やAIによるユーザースペースプログラムの異常な挙動が増える未来が見えない。PS: 同じくらいの堅牢性を持つSteam Deckが欲しいなら（つまり、ゲームが暴走してもコンソールを完全にフリーズさせるのは難しい、メニューボタンを押して閉じたり殺したりできるから）、こういう微妙な変更が必要なんだよね。他にもたくさんあるけど。

メモリファイルシステムじゃない場合、誰かがディスクを使い果たすかもしれないけど、それがどう違うのかはよくわからないな。

DebianのメーリングリストでLuca Bocassiを見るたびに、イライラするような無能な発言ばっかりなんだよね。前回は、systemd-networkdの重大なバグをパッチすることに反対してたし、「Debianでサポートされてるオプションはifupだから」って言ってた。ほんと、バカみたい。