Flatpakのアプリケーションを外部ドライブにインストールし、他のLinuxディストリビューションで使用できますか？

はい。

しかし注意する点がたくさんあります。アプリケーションがPerl、Python、またはPosix Shell Scriptなどの解釈された言語で書かれている場合は、アプリケーションが依存するすべてのモジュールもアプリケーションにバンドルされていることを確認してください。特定の基本プラットフォームを想定する構成、つまりリトルエンディアン整数を想定します。これにより、アプリケーションをインタプリタを持つすべてのプラットフォームで実行できます。アプリケーションがJavaなどの仮想マシンで実行するように設計されたバイトコードで作成およびコンパイルされている場合は、Run Anywhereが隠されたトラップなしで予約された後にJavaが作成されることを前提として解釈された言語アプリケーションと同じ制約を受け入れることができます。

一方、マシン実行可能バイナリでコンパイルされたプログラムは、正しくコンパイルするのがはるかに困難です。それでも可能ですが、知っておくべきいくつかのトラップがあり、大規模なリリースでは基本的に3つの方法があります。

すべてのターゲットが同じプロセッサフ​​ァミリーに属すると仮定すると、主な問題は、互換性のないカーネルAPI、互換性のない、または不完全なユーザー領域ABI、および新しいプロセッサオペコードの3つのカテゴリに分けられます。最初は理解しやすいです。 Linuxカーネルは頻繁にシステムコールを追加し、プログラムがそのシステムコールを持たない古いカーネルから新しいシステムコールを呼び出そうとすると、プログラムは機能しません。解決策は、任意のターゲットをデフォルトのカーネルとして選択し、アプリケーションまたは依存関係のいずれも最新のシステムコールを使用しないようにすることです。 3番目のカテゴリもわかりやすいです。プロセッサフ​​ァミリの最新のプロセッサには、以前のバージョンでは解釈できないオペコードがあります。 AVX512 SIMDベクトル演算など、これらの最新の操作はx86_64プラットフォームに表示され、実際にはいくつかの計算を高速化できますが、比較的新しい操作です。解決策は簡単です。プログラムをコンパイルするときは、具体的にターゲットにしたいプロセッサのバージョンをコンパイラに通知し、以前の汎用プロセッサのみをターゲットにしてください。

2番目のカテゴリは状況が厳しくなる部分です。これは、基本プログラムが動的に接続されているためです。これは、結果のバイナリが不完全であることを意味します。完全なプロセスイメージを生成するには情報自体が不十分であり、中間プログラムはプロセスを構築するときにリンクを本質的に完了するためにファイルを解釈する必要があります。中間プログラムは、システムCライブラリの一部である動的リンカーです。これはかなり複雑ですが、重要な問題、つまり互換性のないlibc /動的リンカーの問題につながります。 glibcに対してビルドする場合、プログラムは別のlibcを使用して実行できますが、これは保証されません。動的バイナリには、実行に依存するライブラリのリストがどこかに含まれ、開発システム（本番システムではない）でそのライブラリを見つけるためのパスに関する情報も含まれます。この問題は、3 つの方法のいずれかで解決できます。 1つ目は、各依存関係のコピーと一緒にアプリケーションをバンドルするMicrosoftプラットフォームのアプローチです。アプリケーションがシステムディレクトリではなくディレクトリに含まれている場合は、POSIXシェルスクリプトを使用して、動的リンカがシステムライブラリではなくバンドルライブラリを見つけるのに必要なパス変数を設定できます。詳細については、ld.so のマニュアルページを参照してください。 2番目の解決策は、アプリケーションを静的に接続することです。これにより、動的接続に関連する問題を心配する必要がなくなります。最後に、この問題を解決するために私が考えることができる最後の解決策は、ユーザーに独自のソリューションを構築させることです。これは完成度のために追加されただけで、実際には答えではありません。バンドルまたは静的接続オプションを維持します。どちらにも利点がありますが、前者は動的接続のポイントの1つを無効にします。つまり、メモリにライブラリのコピーを置くことで、アプリケーションが新しいライブラリのバグを修正することで利点を得ることができます。つまり、後者は異なるライセンスに基づいてコードを混在させるのに問題があるため、両方とも長所と短所があります。