テクノロジーの世界には、分散を避けるために他のすべての最良のものをまとめるフォーマットを作成しようとするときはいつでも、新しいものをリストに追加するだけであるという古いジョークがあります。 その一部は、変更なしですべてのLinuxディストリビューションで実行できるパッケージ形式を作成するための努力によるものです。 今世紀のこれまでのところ、私たちはすでにXNUMX歳になっています。
Snap、Flatpak、Appimage。 従来のフォーマットとの違い
ネイティブパッケージ形式とスタンドアロンパッケージ形式の主な違いは、前者がオペレーティングシステムにインストールされている他のプログラムと依存関係を共有していることです。 言い換えると、プログラムYが依存関係1を必要とし、その依存関係がそれも必要とするプログラムXによってインストールされた場合、その依存関係は再度インストールされません。
個別の形式でパッケージ化されたプログラムには、機能するために必要なすべての依存関係が含まれています。 つまり、依存関係1は、それを必要とするプログラムがインストールされるたびにインストールされます。
XNUMXつ目の違いは、従来のパッケージ形式は各ディストリビューションの仕様に基づいて作成する必要があることです。。 そのため、UbuntuはDebianから派生したディストリビューションですが、違いは十分に重要であるため、最初のリポジトリをXNUMX番目のリポジトリで使用することはできません。
XNUMX番目の違いは 従来のパッケージへの依存関係を変更すると、それを必要とする他のすべての操作に影響を与える可能性があります。 一方、独立した形式でプログラムを変更しても、システムの他の部分には影響しません。
各ディストリビューションの特殊性に応じて、パッケージマネージャーから独立した形式でアプリケーションをインストールし、それらを担当するマネージャーで更新を自動化することができます。
Ubuntuでは、Software Centerを使用すると、Snapなどの従来の形式で両方のプログラムをインストールでき、後者が優先されます。 GNOME Software Center(Ubuntuの派生元)を許可するプラグインはありますが、このディストリビューションでは機能しません。
Ubuntu Studioの場合、Snapパッケージを使用するオプションを有効にすることができますが、KDENeonとManjaroは両方の形式で動作します。
スナップ
2014年に開発が開始されて以来、最新の独立フォーマットです。 デスクトップLinuxディストリビューションだけでなく、モノのインターネット、モバイルデバイス、サーバーでも使用することを目的としています。 に個別のアプリストアを作成することは可能ですが、現在、Canonicalが運営しているアプリストアはXNUMXつだけです。 Snapcraft。
Snapcraftには最も人気のあるオープンソースアプリの品揃えがありますが、 その強みは、プライベートソフトウェア開発者とクラウドサービスプロバイダーによって開発されたプログラムです。
フラットパック
Flatpakは2015年に正式に開始されましたが、xdg-appとして知られる別のユニバーサルフォーマットプロジェクトの継続です。 このプロジェクトは、 root権限を必要とせず、システムにセキュリティ上の脅威をもたらすことのない、安全な仮想サンドボックスでアプリケーションを実行できます。
Flatpakはデスクトップディストリビューションに焦点を当てており、アプリケーションストアの概念も使用しています フラット 最も有名な。
Flathubの長所は 通常、メインのオープンソースアプリケーションの最新バージョンがあります。
イメージ
AppImageは、2004年に最初にリリースされた、最も古いスタンドアロンパッケージ形式です。
これは、「XNUMXつのアプリケーション-XNUMXつのファイル」のパラダイムに従った最初のフォーマットでした。。 つまり、Appimageファイルをダウンロードするたびに、アプリケーションとそれが機能するために必要なすべてのものをダウンロードします。 アプリケーションを使用する場合は、実行権限を付与して、アプリケーションを識別するアイコンをダブルクリックするだけです。
Appimageはアプリストアシステムを使用していませんが、 干し草 Webページ 利用可能なすべてのタイトルのリストを見つけることができます。
Appimageを更新するには、 このツール。
アプリをインストールするときにスナップの速度が極端に遅くなることについては言及されていません。アプリごとに仮想ユニットが必要だからです。
アプリをインストールするときにスナップの速度が極端に遅くなることについては言及されていません。アプリごとに仮想ユニットが必要だからです。
ご意見ありがとうございます。 ちゃんと覚えておきますよ。
個人的には、独立したソフトウェアパッケージングの問題は、さまざまなディストリビューションによるLSBおよびFSH標準への準拠の程度に関係するはるかに深刻な競合の反映にすぎないと思います。
パッケージングの背後にある基本のXNUMXつは、標準ライブラリの実装であり、ソフトウェアの場所と場所、および構成ファイルの両方を保持します。 したがって、ライブラリの競合を回避できます。 他のオペレーティングシステムに共通すること、そして残念ながら、標準に準拠していないことにより、あるディストリビューションから別のディストリビューションへのソフトウェアの移行は言うまでもなく、ソフトウェアの保守と更新が困難になります。 実装の標準への準拠を分析せずに、ハウツーから何度も実行される手動コンパイルの悪い習慣は、システム管理者にとって大きな頭痛の種になります。 特に、以前の別の管理者によってインストールされた運用サーバーを誰かが引き継ぐ必要がある場合。
独立したパッケージングは、何らかの形で、その哲学に貢献し、独立性、特定のフォーマットまたは会社への依存以上のものを促進することになります。 プラットフォームの移行を何度もほとんど不可能な作業にします。 長期よりも短期的に考える。 15年以上の経験を持つ真面目な管理者なら誰でも目撃できる状況。 そして、私は意図的にその数字を言います。その期間に十分な配布が行われるのを見て、遅かれ早かれ、プロジェクトまたはサービスが何らかの理由でプラットフォームから移行することを余儀なくされることを理解するためです。 プロジェクトの実施中に評価プロセスに入ることがめったにない状況。 移行が最も簡単なのは、前述の標準に最もよく準拠するプラットフォームです。 これらの独立したパッケージであるため、これらの標準から最も遠いものです。
興味深い貢献、それについて考えることは私には思い浮かばなかった
AppImageファイル更新ツールは実際には役に立たない。 私が試した7つのAppImageファイル(Inkscape、Olive、KSnip、MuseScore、OpenShotなど)のうち、「検証署名が存在しません」で終わるXNUMXつだけを処理しようとしたため、更新もしていません。 つまり、それは何にも使用されていないので、参照を削除できます。 また、何ヶ月も更新されていません。
コメントありがとうございます