Linuxの素晴らしさの一つは、一般的なソフトウェアの検索とインストールが非常に速くて簡単なことです。GNOMEのソフトウェアのようなグラフィカルツールを使えば、数回のクリックでアプリをダウンロードしてインストールできます。コマンドラインに慣れている人なら、比較的短いコンソールコマンドを1つか2つ使うだけでアプリケーションをインストールできます。
これはすべてパッケージマネージャーのおかげです。長年Linuxディストリビューションの中心的存在として機能してきた頼もしいパッケージマネージャーですが、深刻な欠点もいくつかあります。
パッケージマネージャーの問題点
パッケージマネージャーはデスクトップLinuxユーザーの生活を楽にしてくれますが、それがうまくいかないこともあります。ライブラリの競合によって他のパッケージとの互換性が損なわれることもあります。Linux初心者にとって、システムアップグレードを試みた際にコンソール画面にエラーが表示されることほど、やる気をなくさせるものはありません。上級ユーザーでさえ、これは大きな痛手となるでしょう。
さらに、パッケージマネージャーは一つだけではありません。パッケージマネージャーはディストリビューションごとに異なるため、Fedora 向けの手順を Ubuntu にそのまま適用できるわけではありません。ディストリビューションを切り替えるということは、新しいパッケージマネージャーを習得することを意味します。また、あるシステムで動作するものが、別のシステムでは同じように動作しない可能性もあります。
初心者にとって全てを完璧にこなすのは難しいだけでなく、ソフトウェアベンダーにとってもプログラムを配布するのは大変な作業です。考えてみてください。プログラムを配布するには、ソースコードをtarball (tar.gz) で提供するだけでなく、RPM (Fedora)、Deb (UbuntuとDebian)、tar.xz (ArchとManjaro) として再パッケージ化する必要があるかもしれません。
多くのソフトウェアベンダーは、単に1つのディストリビューションを選び、残りはパッケージメンテナーに任せきりです。その結果、選択したLinuxディストリビューション向けにソフトウェアを再パッケージ化することに多大な労力を費やすボランティア集団が生まれます。これは膨大な作業とテストを伴います。WindowsやMacで広く利用できるプロプライエタリアプリが、必ずしもLinuxで利用できるわけではないのも不思議ではありません。
配布の簡素化
Linux向けソフトウェアのパッケージ化が悪夢であることに気づいた賢明な人たちがいました。この問題を解決するため、過去1年間でいくつかの新しいフォーマットが開発され、簡素化が図られてきました。
ポータブルLinuxアプリケーションは、全く新しいものではありません。Dockerのようなコンテナシステムは、エンタープライズアプリ開発者やサーバー管理者の間で人気がありますが、私たちのようなデスクトップユーザー向けには設計されていません。ポータブルデスクトップシステムは、アプリケーションの実行に必要なすべてのもの（ライブラリ、ランタイムなど）をパッケージ化します。そして、ポータブルアプリは単一ファイルのダウンロードとして提供され、長い解凍やインストールのプロセスを経ることなく実行できます。
この配布方法は、各アプリケーションをシステムの他の部分から比較的隔離された状態で実行できるため、セキュリティの強化も期待できます。つまり、不正なメールや悪意のあるウェブスクリプトが、アプリの環境、つまりサンドボックスの外側にあるシステム上のデータにアクセスするのは困難です。場合によっては、アプリケーションが正常に動作するために特定の権限を付与する必要があります。Androidアプリでスマートフォンのカメラやストレージへの権限を求められたことがあれば、その考え方はよく似ています。
候補者
Linuxのあらゆる問題と同様に、解決策は一つだけではありません。複数の人が同様の解決策を考案し、開発に取り組んできたため、競合するフォーマットが新たに登場しています。この問題に対処しようとしているフォーマットは、AppImage、Flatpak、Snapの3つです。
AppImageは最も初期のソリューションの一つであり、2004年にklikというプロジェクトとして開発が始まりました。AppImageを使用すると、ユーザーは単一のファイルをダウンロードし、実行可能ファイルとして設定するだけで、インストールなしで実行できます。JFrog BintrayにはAppImageアプリのライブラリが存在しますが、一部のアプリケーションは少し古くなっています。例えば、Chromiumアプリケーションは2016年8月のビルドです。
Canonicalは2016年にUbuntu 16.04でSnapsを導入し、ポータブルアプリケーションの分野にいち早く参入しました。Snapsは、より安全でインストールが簡単であると謳われています。Snapsを使用するには、システムにsnapdデーモンをインストールする必要があります（Ubuntu 16.04以降を使用している場合は、既に基本インストールにsnapdが組み込まれています）。Snapdはほとんどの主要なディストリビューションで利用できるため、UbuntuやMintユーザーでなくても利用できます。Ubuntu App Explorerのウェブサイトにも、豊富なSnapsが用意されています。CanonicalのSnappyエコシステムでは、サーバーアプリケーションとデスクトップアプリケーションが混在しており、Dockerなどのソリューションと若干重複する点に注目すべきです。
最後に、flatpakがあります。flatpakはRed Hatが開発したデスクトップアプリケーション向けのフォーマットで、サーバー向けではありません。flatpakは2016年11月下旬にFedora 25がWebに登場したのと同時期に「リリース」されたため、Canonicalのsnapsのようにアプリライブラリを蓄積する時間はまだありませんでした。flatpakとして利用できるアプリケーションは少ないですが、コレクションは拡大しています。
進行中の作業
Linux アプリケーションを移植可能にするのは、少し新しいプロセスであるため、まだすべてが完璧に動作するわけではありません。
CanonicalのSnapは、FedoraのSELinuxをサポートしていません。さらに、flatpakとSnapはどちらも、WaylandとMirディスプレイサーバーが提供する追加のセキュリティに依存しています（ディスプレイサーバーは、デスクトップが描画されるキャンバスを作成するものです）。残念ながら、ほとんどのLinuxシステムは依然として旧式のX11（またはX.org）サーバーに依存しています。Fedora 25は11月にシステムのデフォルトサーバーとしてWaylandを搭載してリリースされましたが、4月にリリースされたUbuntu 16.04では依然としてX11が使用されていました（ただし、Unity 8/Mirのプレビュー版をインストールすることも可能です）。
AppImageにはサンドボックスやセキュリティ機能が一切組み込まれていません。そのため、ユーザーはFirejailアプリケーションを使用してAppImageを手動でサンドボックス化する必要があります。
もう一つの調整が必要なのは、これらの形式のユーザーインターフェースです。AppImageファイルは手動で実行可能ファイルとして設定する必要があります。これは難しくありませんが、ユーザーがビットを設定する必要があることを知らなかったり、単に忘れてしまったりすると、問題になりやすいです。
この小さな青い盾は、このバージョンの Gedit が flatpak 版であるという唯一のヒントです。
Fedora 25 を実行しているか、flatpak がインストールされている場合、GNOME Software でアプリケーションの Flatpak バージョンを利用できます。ただし、GNOME Software では、アプリケーションが Flatpak であることを示す唯一のヒントは、アプリケーションがサンドボックス化されていることを示す小さな青いアイコンです。
結論
これら3つのソリューションは、それぞれ独自の方法でLinuxアプリケーション配信の統合という課題に取り組んでいます。それぞれに長所と短所があります。今年、最終的にどれがユーザーの心を掴むのかは興味深いところですが、これらのプロジェクトが実現するであろう、よりユーザーフレンドリーなデスクトップLinuxエコシステムにも期待しています。
