スタイリッシュなオープンソースUSBイメージライターツールであるMeet Etcherを読みました。AppImageのダウンロードについて説明します。
はい、Linux。Linuxパッケージは32ビットおよび64ビットディストリビューションの.appimageとして配布され、すべての主要なLinuxディストリビューションで問題なく実行されるはずです。チームは現在、ネイティブの.deb（または.rpm）インストーラーを提供する予定はありません。
AppImagesとは何ですか？スナップとはどう違うのですか？
回答:
ここでappImageプロジェクトページを引用しています。
AppImagesは、インストールまたはルート権限なしでダウンロードして実行できます。
次のようにappImageを実行可能にできます。
chmod a+x exampleName.AppImage
次のようにappImageを実行できます。
./exampleName.AppImage
appImageに関するいくつかの一般的な情報はこちらで見つけることができます。
ここでappImageプロジェクトページを引用しています。
AppImage形式の重要な考え方は、1つのアプリ= 1つのファイルです。すべてのAppImageには、アプリと、アプリで実行する必要があるすべてのファイルが含まれています。つまり、各AppImageには、ターゲットのベースオペレーティングシステムに含まれているもの以外の依存関係はありません。
ウィキペディアは追加します
AppImage（および前身のklikおよびportablelinuxapps）は、従来の意味でソフトウェアをインストールしません（つまり、システム内のあらゆる場所にファイルを配置しません）。
アプリケーションごとに1つのファイルを使用します。それぞれが自己完結型であり、アプリケーションが依存するすべてのライブラリが含まれており、それらはベースシステムの一部ではありません。この点で、「アプリケーションの仮想化」に似ています。スーパーユーザーでなくても、ライブCDを使用していても、AppImageファイルを使用できます。実際にはインストールが行われなかったため、AppImageファイルは多くの場合、アプリケーションをコンパイルしてインストールするよりも簡単です。AppImageファイルは、プログラムへのアクセスを許可するために一時的にマウントされた圧縮イメージですが、プログラムを抽出したり、基になるシステムを変更したりする必要はありません。
AppImageKitプロジェクトは、同じように多くの追加の情報を提供していますユースケース、問題空間と目標。README.md
ユーザーとして、アップストリームのダウンロードページに移動し、元の作者からアプリケーションをダウンロードし、WindowsまたはMacアプリケーションで行うのと同じようにLinuxデスクトップシステムで実行したいと思います。
テスターとして、コンパイルの必要もなく、システムを台無しにする心配をせずに、継続的なビルドサーバーから最新バージョンのアプリケーションを取得し、システムでテストできるようにしたいと考えています。
アプリケーション作成者またはISVとして、WindowsおよびOS Xの場合と同じように、Linuxデスクトップシステム用のパッケージを提供します。ディストリビューションに「組み込む」必要もなく、膨大な数のディストリビューション用にビルドする必要もありません。
シンプルに。
AppImageは、理解、作成、および管理が簡単な非常にシンプルな形式を意図しています。
バイナリ互換性を維持します。
AppImageは、バイナリソフトウェア配布用の形式です。AppImageとしてパッケージ化されたソフトウェアは、可能な限り多くのシステムで可能な限りバイナリ互換であることを意図しています。ソフトウェアの（再）コンパイルの必要性を大幅に減らす必要があります。
ディストリビューションに依存しない。
AppImageは、作成された（およびそれ以降のバージョン）すべてのベースオペレーティングシステム（ディストリビューション）で実行する必要があります。たとえば、Ubuntu 9.10、openSUSE 11.2、Fedora 13（およびそれ以降のバージョン）を同時にターゲットにできます。ターゲットシステムごとに個別のパッケージを作成および管理する必要はありません。
インストールの必要性を取り除きます。
AppImagesには、最初にインストールしなくてもアーカイブから直接実行できる形式のアプリが含まれています。これはLive CDに相当します。Live CDを使用する前に、オペレーティングシステムを使用する前に最初にインストールする必要がありました。
アプリを常に圧縮したままにします。
アプリケーションは常にパッケージ化されたままなので、ハードディスク上で圧縮解除されることはありません。コンピューターは、アクセス中にオンザフライでアプリケーションを圧縮解除します。ほとんどのシステムでは、解凍はハードディスクからの読み取りよりも高速であるため、スペースの節約に加えて速度の利点があります。また、インストールに必要な時間が完全に削除されます。
アプリをどこにでも配置できるようにします。
AppImageは「再配置可能」であるため、ユーザーは任意の場所（CD-ROM、DVD、リムーバブルディスク、USBスティックを含む）から保存および実行できます。
アプリケーションを読み取り専用にします。
AppImageは設計上読み取り専用であるため、ユーザーは操作中にアプリが自分自身を変更しないことを合理的に確信できます。
再コンパイルする必要はありません。
AppImagesは、再コンパイルする必要なく、既存のバイナリから作成できる必要があります。これにより、コンパイラを使用する必要がないため、AppImageの作成プロセスが大幅に高速化されます。これにより、サードパーティはクローズドソースアプリケーションをAppImagesとしてパッケージ化することもできます。（それにもかかわらず、アップストリームアプリケーション開発者にとっては、AppImageを生成するためにソースからビルドすることが特に有益です。）
基本オペレーティングシステムに手を触れないでください。
AppImagesは管理者によって特別に準備されていないプレーンなシステムで実行することを目的としているため、AppImagesは基本オペレーティングシステムの異常な準備を必要としない場合があります。そのため、特別なカーネルパッチ、カーネルモジュール、またはデフォルトで対象のディストリビューションに付属していないアプリケーションに依存することはできません。
ルートは必要ありません。
AppImageはエンドユーザーが実行することを目的としているため、インストールまたは使用する管理アカウント（ルート）を要求するべきではありません。ただし、必要に応じて、管理者が（たとえば、マルチユーザーシナリオで）インストールすることができます。
基本的な考え方は2つのシステム間で似ているように見えますが、スナップとAppimagesには設計上の違いがいくつかあります。
私の頭に浮かぶ「大きな」ものは次のとおりです。
閉じ込めの面でのセキュリティ。スナップパッケージはサンドボックス内で実行され、サンドボックスから脱出したり、システムのその他の部分に触れてはいけません。これは、権限システムと並行して実行される強力なセキュリティレイヤーです。最初（および後で）に対処するのは明らかにイライラしますが、システム管理の観点から考えると、これは管理者がユーザーに求めるものです。
セキュリティ。ネットの周りから取得したソフトウェアをインストールすることは、街中の棒をなめるのと同じくらい安全です。何も起こらないこともあれば、非常に大きな健康上の問題が生じることもあります。スナップパッケージには、通常の標準のUbuntuリポジトリと同様に、Canonicalによって制御される適切なリポジトリがあります。続けて.debファイルをインストールすることもできますが、これは設計上の問題ではなく選択することができます。
インストール。AppImagesは、「ポータブルWindows実行可能ファイル」に相当するものです。すべてのライブラリは自己完結型であり、ユーザーはいずれかをダウンロードして実行するだけです。一方、snapパッケージは適切なパッケージであり、適切なパッケージマネージャーを介して（としてroot、またはとともにsudo）インストールする必要があります（snap install tic-tac-toeエラーがスローされます：必要sudoです！）
除去。スナップパッケージを削除するにsnap remove ...は、適切な権限を持つパッケージマネージャーを使用する必要があります。一方、Appimagesは単に「そこ」にあります。だから、ユーザーはそのAppimageを望んでいませんか？彼/彼女はファイルを削除するだけで消えました。
Appimagesを使用する場合は注意することを強くお勧めしますが、私は個人的にそれらの一部を使用しています。
私は仕事用システムで特に便利だと思いますが、そこではrootアクセス権がありません（管理者だけが持っています）が、幸いなことに開発者がAppimage形式で提供した特定のソフトウェアの最新バージョンが必要です。
悪意のあるコードが実際に含まれているのではないかと少し心配しているため、できる限り出版社の身元を確認しました。私は、このソフトウェアが無害であることを完全に確信しているわけではありませんが、できる限りのことをしました。
snapはUbuntuのみに焦点を当てていますが、AppImageはクロスディストリビューションであり、Fedora、debian、openSUSE、CentOSなどでも実行されます。
AppImageは、Linuxディストリビューションのランタイムまたはインフラストラクチャサポートを必要としないため、あらゆる場所で実行されます。アプリケーション作成者は、WindowsやOS Xのように、Linuxユーザーにソフトウェアを直接出荷できます。Canonicalまたはソフトウェア作成者とエンドユーザーの「中間」にいる他の人はいません。
アプリケーションがAppImage形式で提供されている場合、ユーザーは元の作成者のWebサイトにアクセスしてダウンロードできます（例：https ://musescore.org/en/downloadからのMuseScore）。AppImageを（ファイルマネージャーまたはを使用してchmod a+x ./yourAppImage）実行可能にすると、ダブルクリックするだけでアプリケーションを実行できます。
AppImagesを実行するにはFUSEが必要です。ユーザー空間のファイルシステム（FUSE）は、非rootユーザーがファイルシステムをマウントできるシステムです。
多くのディストリビューションには、すぐに使用可能なFUSEセットアップがあります。ただし、動作しない場合は、FUSEを手動でインストールして構成する必要があります。
たとえば、Ubuntuの場合：
sudo apt-get install fuse
sudo modprobe fuse
sudo usermod -a -G fuse $USER
たとえば、openSUSEの場合：
sudo zypper install fuse
FUSEをインストールしたくない場合は、AppImageをマウントまたは抽出できます。
AppImageをマウントしてアプリケーションを実行するには、単に実行します
sudo mount -o loop Some.AppImage /mnt
/mnt/AppRun
それが機能しない場合は、実験的なタイプ2のAppImageがある可能性があります。これらは-o offset=...、mountコマンドに渡す必要があります。AppImageを実行して--appimage-offset、オフセットの正しい数を見つけます。
sudo usermod -a -G fuse）に続いてユーザー名を書いた後、usermod: group 'fuse' does not exist...を取得し続け ます。理由は何か？
sudo apt-get install fuse sudo modprobe fuse sudo usermod -a -G fuse $USER、Windows 10 64で行を入力しました。コメントしている答えは32/64の仕様を作っていないので、どこで指定する必要があるかわかりません。なぜ...
以下の手順に従ってください：
ターミナルの使用：
chmod u+x <appimage>詳細はこちらをご覧ください：https : //citguru.hashnode.dev/heres-how-to-install-appimage-on-linux-cjwxozb1n003o1rs17epqop6g
appimageタグは便利になると思うので、作成しました。必要ない場合や保持したくない場合は、とにかく再度焼き付けるオプションが常にあります。