SDK、IDE、拡張機能などをインストールするためのヒントを読むたびに、/optフォルダーに展開する必要があると書かれています。なぜそうする必要があるのですか？
Ubuntuをインストールしていたときに、/ファイルシステムに10〜20 GiBのみを設定し、残りのスペースをに設定する必要があることを読みました/home。だから、ルートフォルダのスペースを拡張するか、すべてのものを残すべき/homeですか？違いはありますか？
回答:
まず、明示的に別のパーティション（またはそのようなマウントポイントのサブディレクトリ）のマウントポイントではないディレクトリは、ルート（/）パーティションに保存されることを理解してください。したがって、ルート（/）および/homeがあり、他のパーティションがない場合、/optディレクトリは単にルート（/）上のディレクトリになります。同様のため/tmp、/sbinと何か。したがって、最初の質問は、ルート（/）から派生するすべてのディレクトリに個別のパーティションが必要であり、直接回答できないという誤った前提に基づいています。
第二に、/optUbuntuのコンテキストでは、Debianパッケージを介して配布されないプリコンパイル済みソフトウェアを意味するサードパーティソフトウェアに使用されます。を参照する公式のプログラムドキュメントが表示さ/optれる場合がありますが、これらのファイルを別の場所にドロップするDebianパッケージが利用可能です。そのような場合、Debianパッケージを使用するときは、公式ドキュメントを無視するか、少なくともそのファイルの場所の参照を無視する必要があります。また、tarballまたはDebianパッケージ経由でプリコンパイル済みパッケージを使用する選択がある場合、一般的にDebianパッケージを使用するのが最善です。全体として、/opt最近では使用が非常にまれです。それでもファイルをに入れる必要があると思われる場合は/opt、ソフトウェアに名前を付けることをお勧めします。このソフトウェアのDebianパッケージが入手可能かどうかを知っている人がいるからです。
最後に、前の2つのポイントを組み合わせて、Ubuntuのインストールが/opt別のパーティションに分割されることは非常にまれです。なぜなら、そこに大量のデータが保存されることはまれだからです。ほとんどのUbuntuソフトウェアは/usr他の場所に移動します。かつて/usrは別のパーティションに分割するのが一般的でしたが、今日ではその方法は非常にまれです。あなたがソフトウェアの多くをインストールする必要が起こるならば/opt、それのために別のパーティションを作成する、かもしれません理にかなっていますが、多くの場合、これはあまり役に立ちません。セキュリティを異なる方法で処理する必要がある場合、異なるファイルシステム機能が役立つ場合、マルチブート構成で複数の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は、しばしば別のドライブでした。専用のソフトウェアをインストールするために使用され、必要なすべてのライブラリと他のリソースがバンドルされているため、多くの場合、非常に大きなディスクスペースが必要になります。現代では、ドライブは非常に大きいため、単一のドライブで単一のルートを使用するだけで実行可能で簡単です。
/optLinuxディストリビューションの一部とは見なされない（場合によっては独自仕様の）外部アプリケーションに使用されます。これらのアプリケーションにはパスがハードコーディングされている可能性があるため、インストール時にのみ正しく実行/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インターフェイス定義（第3版）に基づくSystem Vアプリケーションバイナリインターフェイス[AT＆T 1990]は、ここで定義したものと非常によく似た/ 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つは「何を変更しましたか？」です。「これらの変更の一部を一時的に無効にして、他の何かの症状ではなく、実際の問題を見ていることを確認できますか。」
別々の場所を使用すると、これらの変更をすばやく特定でき、（少なくともプログラム自体に対して）行う必要があるのは、パスからディレクトリを一時的に削除することだけです。