FHSの代替案は何ですか？

まず、利益相反の声明を事前に明記する必要があります。私は長い間GoboLinux開発者でした。

第二に、ドメインの専門知識に関する事前の声明です。私は長い間GoboLinux開発者でした。

現在、様々な構造が使用されている。ゴボリナックス一つあり、こんな道具もありますよGNUストー、自分で作ったなど、非常に似たものを使用します（主にユーザープログラムの場合）。ニックOSまた、プログラミングやライフ哲学には非標準階層を使用します。これも非常に一般的なLFS実験です。

私はこれらすべてを説明し、それが実際にどれだけうまく機能するか（「妥当性」）経験的にコメントします。短い答えははい、可能です。しかし、本当に欲しいはずです。。

ゴボリナックス

GoboLinuxの構造は、あなたが説明するものと非常に似ています。ソフトウェアは次の場所にインストールされます/Programs。/Programs/ZSH/5.0.8一般的なbin/ lib/...ディレクトリにあるZSH 5.0.8に属するすべてのファイルが含まれています。システムツールは、1に/System/Linksマップされた階層の下にこれらのファイルへのシンボリックリンクを作成します/usr。このPATH変数には単一の統合実行可能ディレクトリのみが含まれ、使用されませLD_LIBRARY_PATHん。複数のバージョンのソフトウェアが同時に共存できますが、bin/zsh指定された名前（）を持つ1つのファイルのみが一度にアクティブにリンクされます。フルパスを介して他の人にアクセスできます。

統合実行可能ディレクトリなどの互換性シンボリックリンクと/binマッピングセットもあります。/usr/binこれにより、実行時にソフトウェアの操作が簡単になります。カーネルパッチGoboHideを使用すると、これらの互換性シンボリックリンクをファイルリストから非表示にできます（ただし、まだナビゲーション可能）。

他の答えを賛成したら欲しくないカーネルコードの変更が必要：GoboHideは純粋に装飾用であり、カーネルは通常ユーザースペースパス²に依存しません。 GoboLinuxにはカスタム初期化システムがありますが、これを行うために必ずしも必要ではありません。

スローガンは常に「ファイルシステムはパッケージマネージャ」でしたが、システムにはかなり一般的なパッケージ管理ツールもあります。ただしcp、rmおよびを使用してすべての操作を完了できますln。

GoboLinuxを使いたいなら大歓迎です。しかし、このチームは小規模開発チームであることを指摘したいと思います。以前に必要なソフトウェアの一部を使用したい人がいない場合は、そのソフトウェアがパッケージ化されていない可能性があります。良いニュースは、システム用のプログラムを構築するのが一般的に非常に簡単です（標準の「レシピ」は約3行です）。悪いニュースは、時には非常に複雑になる可能性があるということです。これについては以下で詳しく説明します。

出版

「出版物」があります。私はスピーチをしましたlinux.conf.au 2010システム全体はすべてをカバーし、ビデオで見ることができます。オゴフ mp4（また、あなたのローカルLinux Australiaミラーにもあります）。私が書いたメモ散文になります。有名な」を含む古い文書もあります。私は知らない「、存在するゴボLinuxのウェブサイト、これはさまざまな反対意見や問題を解決します。今では、私たち全員があまり情熱的ではないと考えており、今後のリリースではデフォルトの場所を/usrシンボリックリンクとして採用する予定です。

ニックOS

ニックOSインストールされている各プログラムを一意のディレクトリに配置します/nix/store。これらのディレクトリの名前は次のとおりです/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/。プログラムにつながる完全な依存関係と構成セットを表す暗号化ハッシュがあります。このディレクトリには、ローカルの場所がある程度一般的な場所にあるすべての関連ファイルが含まれています。

また、同時に複数のバージョンを持ち、そのうちの1つを使用できます。 NixOSは、反復可能な構成に関連する全体的な哲学を持っています。つまり、基本的に最初から構成管理システムが組み込まれています。インストールされたプログラムの正しい世界をユーザーに提供するために、いくつかの環境タスクに依存しています。

リニアFS

とても簡単です。最初からLinuxそして、必要な階層を正確に設定してください。ディレクトリを作成し、すべてが正しい場所にインストールされるように設定します。私はGoboLinuxを構築する実験でこれを数回実行しましたが、通常のLFSよりそれほど難しくありません。この場合、互換性シンボリックリンクを作成する必要があります。それ以外の場合は難しくなりますが、本当に必要な場合は、連合の設置を慎重に使用することでこれを回避できます。

花ごろはありそうな感じLFSのヒント以前はそんな言葉がありましたが、今は見つけることができないようです。

妥当性について

FHSの特徴は、標準で非常に一般的であり、作成時の既存の使用法を広く反映していることです。ほとんどのユーザーは本質的にこのレイアウトに従わないシステムを使用しません。その結果、多くのソフトウェアは誰も気付かず、しばしばまったく意図しない潜在的な依存関係を持ちます。

これらすべてのスクリプトには#!/bin/bash？ Bashがなければ悪いです。これがGoboLinuxがこれらすべての互換性シンボリックリンクを持っている理由です。多くのソフトウェアがビルド時または非標準のレイアウトで実行されていると実行に失敗し、修正にパッチが必要で、これはしばしば非常に侵害的です。

デフォルトのAutoconfプログラムは通常、ユーザーが指示する場所にインストールされ、正しいプログラムを自動的に渡すのは簡単です--prefix。 - ポータブル構成。 CMakeは後者のカテゴリーの主な犯罪者です。つまり、この世に住みたいのなら、他人のビルドシステムであらかじめ数多くの退屈な作業を行う準備ができていなければならないという意味です。コンパイル中に生成されたファイルを動的にパッチするのは本当に面倒です。

ランタイムは別の話です。多くのプログラムは、自分のファイルや他の人のファイルが自分自身に関連して、または絶対に見つかる場所を想定しています。一貫したビューを提供するためにシンボリックリンクを使用し始めると、多くのプログラムがシンボリックリンクを誤って処理します（または時には役に立たない正しく機能すると仮定します）。たとえば、ツールはそのシンボリックリンクをfoobar読み取るかどうかによって2つの場所が異なる可能性があり、どちらかが正しくない可能性があります。baz../sbin

包括的な問題は/usr/share目次です。もちろん、共有ファイル用ですが、各プログラムを一意のプレフィックスに入れると、実際には共有されなくなります。これにより、プログラムが標準アイコンなどを見つけることができなくなります。 GoboLinuxはかなり醜い方法でこの問題を処理します。ビルド時を$prefix/share指すシンボリックリンクがあり$prefix/Shared、ビルド後にリンクはグローバルディレクトリをshare指します。これで、コンパイル時にサンドボックスとファイルの移動share（および他のディレクトリ）を使用して処理されますが、リンクを読み取るランタイムエラーは依然として問題になる可能性があります。

いくつかのプログラムのコレクションは別の問題です。 GoboLinuxはGNOMEを完全に機能させず、NixOSもそうしたと信じていません。なぜなら、レイアウトの相互依存性が根付いているので、すべて修正するのは難しいからです。

だから、はい可能です。、しかし：

• 仕事を処理するだけでも多くのことが起こります。
• 一部のソフトウェアは動作しない場合があります。
• 人々はあなたを楽しく見ます。

これらすべてがあなたにとって問題になるかもしれません。

バージョン14.01では、/System/Indexに直接マップされているものを使用しています/usr。今後のバージョンでは、リンク/インデックス階層を削除して/usr全体的に使用できると考えられます。

/bin/sh²基本的に存在する必要があります。