すべてを/ optに移動する必要があるのはなぜですか？
SDK、IDE、拡張機能などをインストールするためのヒントを読むたびに、/optフォルダーに展開する必要があると書かれています。なぜそうする必要があるのですか？
Ubuntuをインストールしていたときに、/ファイルシステムに10-20 GiBのみを設定し、/homeに設定された残りのスペースを設定する必要があることを読みました。ルートフォルダーのスペースを拡張するか、すべてのものを/homeのままにしておく必要がありますか？違いはありますか？
まず、明示的に別のパーティション（またはそのようなマウントポイントのサブディレクトリ）のマウントポイントではないディレクトリは、ルート（/）パーティションに格納されることを理解してください。したがって、ルート（/）と/homeがあり、他のパーティションがない場合、/optディレクトリは単にルート上のディレクトリ（/）になります。 /tmp、/sbin、およびその他すべてについても同様です。したがって、最初の質問は、ルート（/）から派生するディレクトリごとに個別のパーティションが必要であり、直接回答できないという誤った前提に基づいています。
第二に、/optはサードパーティソフトウェアに使用されます。これはUbuntuのコンテキストでは、Debianパッケージを介して配布されないプリコンパイル済みソフトウェアを意味します。 /optを参照する公式のプログラムドキュメントが表示される場合がありますが、これらのファイルを別の場所にドロップするDebianパッケージが利用可能です。そのような場合、Debianパッケージを使用するときは、公式ドキュメントを無視するか、少なくともそのファイルの場所の参照を無視する必要があります。また、tarballまたはDebianパッケージ経由でプリコンパイルされたパッケージを使用する選択がある場合、Debianパッケージを使用するのが一般的に最善です。全体として、/optの使用は最近非常にまれです。それでも/optにファイルを配置する必要があると思う場合は、このソフトウェアにDebianパッケージが利用可能かどうかを知っている人がいるかもしれないので、ソフトウェアに名前を付けるとよいでしょう。
最後に、前の2つのポイントを組み合わせて、Ubuntuのインストールが/optを別のパーティションに分割することは非常にまれです。なぜなら、そこに大量のデータが保存されることはまれだからです。ほとんどのUbuntuソフトウェアは、/usrおよびその他の場所に配置されます。 /usrを個別のパーティションに分割することはかつて一般的でしたが、今日ではその方法は非常にまれです。 /optに多くのソフトウェアをインストールする必要がある場合は、そのために別のパーティションを作成しますmightが理にかなっていますが、多くの場合、これはあまり役に立ちません。セキュリティを異なる方法で処理する必要がある場合、異なるファイルシステム機能が役立つ場合、マルチブート構成で複数のOSインストール間でデータを共有する場合、およびその他の理由で、個別のパーティションが意味を持ちます。定期的なソフトウェアのインストールは、個別のパーティションの恩恵を受ける可能性がありません。実際、/optに個別のパーティションを作成すると、そこに格納されているソフトウェアが消費するサイズが変化した場合、または最初にサイズの見積もりが間違った場合に問題が発生する可能性があります。
あなたは？
事実、それをする必要はないということです。 /optの使用は慣例です。使用することをお勧めしますが、必ずしも必要ではありません。
から Linuxファイルシステム階層：第1章Linuxファイルシステム階層 ：
1.13。/opt
このディレクトリは、デフォルトのインストールの一部ではないすべてのソフトウェアおよびアドオンパッケージ用に予約されています。たとえば、StarOffice、Kylix、Netscape Communicator、WordPerfectパッケージは通常ここにあります。 FSSTNDに準拠するには、すべてのサードパーティアプリケーションをこのディレクトリにインストールする必要があります。ここにインストールするパッケージは、静的ファイル（追加のフォント、クリップアート、データベースファイルなど）を見つける必要があります。静的ファイルは、別の/ opt/'package'または/ opt/'provider'ディレクトリツリーに配置する必要があります（方法と同様）ここで、Windowsは新しいソフトウェアを独自のディレクトリツリーC：\ Windows\Progam Files\"Program Name"）にインストールします。「package」はソフトウェアパッケージを説明する名前で、「provider」はプロバイダーのLANANA登録名です。
ほとんどのディストリビューションは、ディレクトリ/ opt/bin、/ opt/doc、/ opt/include、/ opt/info、/ opt/lib、および/ opt/manの作成を怠りますが、ローカルシステム管理者が使用するために予約されています。パッケージは、システム管理者がこれらの予約ディレクトリに（リンクまたはコピーによって）配置することを目的とした「フロントエンド」ファイルを提供する場合がありますが、これらの予約ディレクトリがない場合は正常に機能する必要があります。ユーザーが呼び出すプログラムは、ディレクトリ/ opt/'package'/binにあります。パッケージにUNIXのマニュアルページが含まれている場合、それらは/ opt/'package'/manにあり、/ usr/share/manと同じ下位構造を使用する必要があります。可変のパッケージファイルは、/ var/optにインストールする必要があります。ホスト固有の構成ファイルは/ etc/optにインストールされます。
正常に機能するためにファイルシステムツリー内の特定の場所に存在する必要があるパッケージファイルを除き、/ opt、/ var/opt、および/ etc/opt階層の外部に他のパッケージファイルが存在することはありません。たとえば、/ var/lockのデバイスロックファイルと/ devのデバイス。ディストリビューションはソフトウェアを/ optにインストールできますが、ローカルシステム管理者の同意なしにローカルシステム管理者がインストールしたソフトウェアを変更または削除してはなりません。
アドオンソフトウェアに/ optを使用することは、UNIXコミュニティで確立された慣行です。 System V Interface Definition（Third Edition）およびIntel Binary Compatibility Standard v。2（iBCS2）に基づくSystem V Application Binary Interface [AT＆T 1990]は、ここで定義したものと非常によく似た/ opt構造を提供します。
一般に、システム上のパッケージをサポートするために必要なすべてのデータは、/ etc/opt/'package'および/ var/opt/'package'にコピーされるファイルを含め、/ opt/'package'内に存在する必要があります。/optの予約ディレクトリ。/optを使用した配布には、特に一部のバイナリソフトウェアで見つかった固定パス名の場合、インストールされた配布ソフトウェアとローカルにインストールされたソフトウェアの間で競合が発生する可能性があるため、小さな制限が必要です。
/ opt/'provider'の下のディレクトリの構造はソフトウェアのパッケージャーに任されていますが、パッケージは/ opt/'provider'/'package'にインストールし、次のガイドラインと同様の構造に従うことをお勧めします。/opt/package。この構造から分岐する正当な理由は、/ opt/'provider'/libまたは/ opt/'provider'/binにインストールされているファイルがあるサポートパッケージのためです。
/optは、Linuxディストリビューションの一部とは見なされない（時には独自仕様の）外部アプリケーションに使用されます。これらのアプリケーションにはハードコーディングされたパスがあるため、/optにインストールされた場合にのみ正しく実行されますが、ハードコーディングされたパスがない場合は、任意のパスにインストールできます。 /optにインストールされるプログラムは、自己完結型であると想定されています。
/optを使用する主な理由は、インストールされたシステムの残りの部分に干渉することなく外部ソフトウェアをインストールできる共通の標準パスを提供することです。 /optは標準のコンパイラまたはリンカーパス（gcc -print-search-dirsまたは/etc/ld.so.confなど）には表示されないため、そこにインストールされたヘッダーとライブラリはメインシステムからある程度分離されており、既に干渉するべきではありません-インストールされたプログラム。
/optの使用は、 Filesystem Hierarchy Standard ： / opt で指定されます。これは、/optが元々Unixから来たことを示します。
/ opt：アドオンアプリケーションソフトウェアパッケージ
目的
/ optは、アドオンアプリケーションソフトウェアパッケージのインストール用に予約されています。
/ optにインストールするパッケージは、静的ファイルを別の/ opt/<package>または/ opt/<provider>ディレクトリツリーに配置する必要があります。ここで、<package>はソフトウェアパッケージを説明する名前で、<provider>はプロバイダーのLANANA登録名。
要件
ディレクトリ/ opt/bin、/ opt/doc、/ opt/include、/ opt/info、/ opt/lib、および/ opt/manは、ローカルシステム管理者が使用するために予約されています。パッケージは、ローカルシステム管理者がこれらの予約ディレクトリに（リンクまたはコピーにより）配置することを目的とした「フロントエンド」ファイルを提供する場合がありますが、これらの予約ディレクトリがない場合は正常に機能する必要があります。
ユーザーが呼び出すプログラムは、ディレクトリ/ opt/<package>/binまたは/ opt/<provider>階層の下に配置する必要があります。パッケージにUNIXのマニュアルページが含まれている場合、それらは/ opt/<package>/share/manまたは/ opt/<provider>階層の下にある必要があり、/ usr/share/manと同じ下位構造を使用する必要があります。
可変のパッケージファイル（通常の操作で変更）は、/ var/optにインストールする必要があります。詳細については、/ var/optのセクションを参照してください。
ホスト固有の構成ファイルは、/ etc/optにインストールする必要があります。詳細については、/ etcのセクションを参照してください。
/ opt、/ var/opt、および/ etc/opt階層の外部には、適切に機能するためにファイルシステムツリー内の特定の場所に存在する必要があるパッケージファイルを除き、他のパッケージファイルは存在できません。たとえば、デバイスロックファイルは/ var/lockに配置し、デバイスは/ devに配置する必要があります。
ディストリビューションはソフトウェアを/ optにインストールできますが、ローカルシステム管理者の同意なしにローカルシステム管理者がインストールしたソフトウェアを変更または削除してはなりません。
根拠
アドオンソフトウェアでの/ optの使用は、UNIXコミュニティで確立された慣行です。System Vアプリケーションバイナリインターフェイス[AT＆T 1990]、 System Vインターフェイス定義（第3版）に基づいて、ここで定義したものと非常によく似た/ opt構造を提供します。
Intel Binary Compatibility Standard v。2（iBCS2）も、/ optに同様の構造を提供します。
通常、システム上のパッケージをサポートするために必要なすべてのデータは、/ etc/opt/<package>および/ var/opt/<package>にコピーされるファイルを含め、/ opt/<package>内に存在する必要があります。/optの予約ディレクトリ。
/ optを使用したディストリビューションには、特に一部のバイナリソフトウェアで見つかった固定パス名の場合、ディストリビューションインストールソフトウェアとローカルインストールソフトウェアの間で競合が発生する可能性があるため、小さな制限が必要です。
/ opt/<provider>の下のディレクトリの構造はソフトウェアのパッケージャーに任されていますが、パッケージは/ opt/<provider>/<package>にインストールし、次のガイドラインと同様の構造に従うことをお勧めします。/opt/package。この構造から分岐する正当な理由は、/ opt/<provider>/libまたは/ opt/<provider>/binにファイルがインストールされている可能性があるサポートパッケージのためです。
/optについては神聖なものは何もありません。システムのすべてのユーザーがアクセスできるプリコンパイル済みソフトウェアをこのディレクトリに配置するのは一般的な方法です。あなたがシステムの唯一のユーザーである場合、あなたのホームディレクトリにそれを抽出することは全く何も悪いことはありません。システムにこのソフトウェアへのアクセスを必要とするユーザーが複数いるが、/homeパーティションのスペースを使用したい場合でも、一般にアクセス可能な/home/softwarenameディレクトリを作成し、ソフトウェアがあります（唯一の注意点は、softwarenameという名前のユーザーがいる場合、ユーザーのホームディレクトリで使用できないことです）。
詳細な回答は非常に優れていますが、（ハードコーディングされた絶対パスを含む可能性のあるソフトウェアを除いて-プログラミングのベストプラクティスではありません）、主なポイントは、非システム/非配布ソフトウェアを混在させて保存しないことです通常のシステムファイル。
物を/optまたは/usr/localに入れると、物がきれいで安全になります。
特に、ソフトウェア検索パス（$ PATH）は、実行する特定の名前のプログラムを検索するときに場所を検索する順序を決定します。通常、/optや/usr/localなどの場所は、リストの最後に向かっています。
cpという名前のプログラムを含むパッケージをインストールすると、/optなどの場所の前に格納されているディレクトリが検索されるため、ディストリビューションに付属するデフォルトの検索順序で通常の検索順序が検索されます。
それがうまくいかなかった場合、誰かがファイルをコピーしようとしていると思ったときに、何か他のことをするcpという名前のプログラムが実行された場合、セキュリティホールを壊したり開いたりする可能性があることを知っている人。
このようなことが起こった場合、誰かがtype cp（何かが間違っていることを示すのに十分ではないかもしれない）のようなコマンドを実行しようとするまでに時間がかかることがありますあなたはそう思う。その時点までは、「うまくいかないという小さなディテールを除いて、すべてがまさにその方法である」ということに固執しています。
基本的に、予期しないことが起こらないようにし、システムの更新によって「カスタム」インストール済みパッケージの一部またはすべてが削除または置換される可能性を回避します。または、逆に、一部の「カスタム」プログラムは、他の多くのプログラムまたはスクリプトが依存する可能性があるシステム提供のプログラムを上書きする場合があります。
管理の観点から、同じ場所に「システム」と「オプション」のプログラム/ファイルを混在させると、システムは「未定義」または少なくとも「あいまいな」状態になります。
システムまたはプログラムに問題があり、支援が必要な場合、最初に尋ねられる質問の1つは「何を変更しましたか？」です。 「これらの変更の一部を一時的に無効にして、他の何かの症状ではなく、実際の問題を見ていることを確認できますか。」
別々の場所を使用すると、これらの変更をすばやく特定でき、（少なくともプログラム自体に対して）行う必要があるのは、パスからディレクトリを一時的に削除することだけです。