数週間前、Canonical は、モバイル、デスクトップ、サーバーベースのアプリケーションをサポートできる Snap アプリケーション配信メカニズムをクロス ディストリビューションでサポートすることを発表しました。 この発表は、他の Linux ディストリビューションが Snap をサポートしている証拠をほとんど見ていない Linux コミュニティ内のいくつかの羽目を外したものでした。 Snap の起源は、Canonical が 2014 年にモバイル プラットフォーム用に作成したソリューションである Click にあり、デスクトップやサーバーとは大きく異なるエコシステムである Ubuntu 電話およびタブレット ユーザーにアプリを配信する複雑さを処理するためでした。 さらに、モバイルでは、アプリを閉じ込めてサンドボックス化し、プラットフォーム全体を危険にさらさないようにする必要もありました。
Click により、開発者はすべての依存関係を単一のアプリ パッケージにバンドルできるため、ユーザーと開発者は競合するシステムやアプリ ライブラリを心配する必要がなくなりました。 1593>
Beyond Mobile to Servers and IoT
Click は Snap に進化し、Canonical はその可能性をサーバー、クラウド、IoT (Internet of Things) およびデスクトップ空間にまで広げました。 4 月の Ubuntu 16.04 のリリースで、Canonical は公式に Snap を Ubuntu デスクトップに導入しました。
Canonical は、大規模なクラウド コンテナ デプロイメント、IoT デバイス、その他、移行期の更新と小さなフットプリントが必要なもの向けの小さな Linux ベース オペレーティング システム、Snappy Ubuntu Core も開発しています。 Snappy Ubuntu Coreは、GoogleのChrome OSやCoreOSとほぼ同様に動作し、システムやアプリの更新をイメージベースで行い、ロールバックすることが可能です。 同時に、コンテナの世界で知られている閉じ込め機能を提供します。
Snap はその技術の魂です。
The Linux Mess of App Delivery
Linux の既存のアプリ配信モデルには多くの欠陥があります。 Linux の世界では、アプリのパッケージングはほとんど rpm と deb の 2 つの陣営に分かれています。
その結果、アプリ開発者は、ディストリビューションがまだ古いライブラリを使用している場合、最新のライブラリを利用し、ユーザーにより多くの機能を提供することができません。 人気のある、あるいは長く使われているアプリは、通常ディストリビューション開発者によってパッケージ化されます。 新しいまたは人気のないものは、サポートしたい各ディストリビューション用にアップストリームによってパッケージ化されるか、あるいはディストリビューションパッケージとしてまったく提供されないかのどちらかです。 アプリの新しいバージョンがリリースされると、これらの開発者はアプリをテストし、その後、ディストロで利用できるようにします。 このように、アプリ開発者がプラットフォーム全体 (この場合は Linux) 向けに 1 つのアプリを書くのではなく、多くの人がそのアプリをユーザーに提供します。
より複雑さが増します。Windows と MacOS では、アプリは主要な開発者によってパッケージ化されるので、最新バージョンをすぐに入手できますが、Linux ディストロではしばらく時間がかかる場合があります。 Skype、Dropbox、Chrome などの商用アプリの場合、アプリをパッケージ化し、異なるディストリビューション用のバイナリを提供する責任は、一次開発者にあります。 多くのアプリは、多くのディストリビューションの古いバージョンでは動作しません。
一言で言えば、混乱です。
Linux の生みの親である Linus Torvalds でさえ、Linux の既存のアプリ配信モデルには満足していません。 彼は、この混乱を理由に、自分のアプリケーションのバイナリを Linux プラットフォーム向けに提供していません。 Subsurface (Linus が立ち上げたプロジェクト) のメンテナである Dirk Hohndel は、「何十ものディストリビューションがあり、それぞれが異なるルールを持ち、異なるライブラリのバージョンを持ち、あるライブラリが欠けていて、それぞれが異なるパッケージングツールとパッケージング形式を持っている現状は、基本的にアプリ開発者に『あっちに行って、アプリケーションに関心があるプラットフォームに集中してくれ』と伝えています」と説明しています。アプリケーションのパッケージングは非常に重要ですが、関連するすべての部品の出所とメンテナンスも重要です」と、Red Hat Enterprise Linux の製品管理ディレクターである Gunnar Hellekson 氏は述べています。 しかし、それが採用されるかどうかはまったく別の問題です。
Hellekson は、Snap のようなツールは「Linux ディストリビューション間の相互運用性の問題を魔法のように解決するものではなく、実際には維持とセキュリティに対する責任をアプリケーション ベンダーにもっとシフトさせるものだ」と主張しました。 このように、ユーザーにとって多くの利点があるにもかかわらず、Linux での開発をさらに困難にする可能性があります」
「Snap の利点は欠点に直接関連しています…要するに、Snap は静的リンクと同等です。一方では便利ですが、他方では重複やセキュリティ (とセキュリティパッチ) に関しての課題を生じます」と、SUSE 製品およびテクノロジプログラム担当副社長の Gerald Pfeifer は言います。 CoreOS の共同創設者兼最高技術責任者である Brandon Philips 氏は、コンテナーは Linux でのアプリケーションの未来であると語っています。 しかし、Docker コンテナはどこでも使えるわけではありません。 彼らには限界がある。 1593>
別のインタビューの中で、Linux カーネル開発の第一人者である Greg Kroah-Hartman は、Android は「8 年か 9 年前からアプリケーションのために」コンテナーを使用してきたと語りました。 すべてのアプリケーションは独自のネームスペースで実行されます。 その外を見ることはできない。 それが、あなたがやらなければならない方法です。 それがLinuxの未来であり、システムの働き方です。” Snap は同じコンセプト、同じアイデアであると。
Snap Goes Cross Platform
Snap の成功は、より大きなオープンソース・コミュニティによって採用されるかどうかに大きく依存しています。 誰も使っていないアプリケーション フォーマットに何の意味があるのでしょうか。 Ubuntu 専用のテクノロジーとして、Linux Mint、KDE neon、または初級 OS のような派生製品によって公式にサポートされない可能性さえあり、Snap はそれほど成功しないキャリアに直面する可能性があります。
Canonical は Snap を発表したとき、記者会見で、Snap のサポートを追加するためにさまざまなディストリビューションと協力してきたと主張しました。
Canonical は、Snap は Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Unity および Xubuntu で自然に利用できると述べていました。 Canonical は、CentOS、Elementary、Gentoo、Mint、OpenSUSE、OpenWrt、および Red Hat Enterprise Linux での Snaps の検証にも取り組んでいます。
Canonical と SUSE は現在 Snaps のコラボレーションに関する開発に従事しておらず、実際、これはオープンなコミュニティの設計と開発によるものではないように思われます、と SUSE の Gerald Pfeifer 氏は述べています。
Canonical が他のディストリビューションと協力したという発表は、オープン ソース コミュニティの一部のメンバーから批判を浴びました。 Fedora の開発者はこの発表を快く思っておらず、2 つのプロジェクト間には何のコラボレーションもなかったと Canonical を批判しました。
私たちが Canonical の創設者 Mark Shuttleworth にこれらの告発について質問すると、彼は、「私たちは Red Hat デスクトップ チームと概要を話し合い、Snaps を可能にするためにすべての Linux ディストリビューションと協力することに常にオープンです」と答えました。「
しかし、これは、Fedora ディストリビューションを管理する Red Hat にとってはニュースでした。 私たちは、このことについてもっと議論し、Linux コミュニティ全体がどのように協力したいのかを確認することに前向きです」と、Hellekson 氏は述べました。 Pfeifer 氏は、「Canonical と SUSE は現在、Snaps のコラボレーションに関する開発に従事しておらず、実際、これはオープンなコミュニティの設計と開発の結果ではなかったように思われます」と述べています。
Canonical は完璧ではない
Canonical が受けた反発の一部は、そのビジネスのやり方の副産物であるかもしれません。 Fedora と openSUSE は、かなり独立した、コミュニティ主導のプロジェクトであり、決定はスポンサー企業ではなく、コミュニティのメンバーによって行われます。 そのため、openSUSE や Fedora とは逆に、Canonical は Ubuntu を直接コントロールすることができます。 コミュニティと企業のニーズのバランスを保つのは本当に難しく、ownCloud のような大惨事に終わることもよくあります。
プロジェクトでどのように「働く」のかという疑問が生じますが、
また、多くの人が Ubuntu には透明性が欠けていると感じています。 時には、Canonical 社が Ubuntu に関する主要な発表を非公開にし、コア メンバーにさえ隠していることに、Ubuntu の主要な貢献者の多くがフラストレーションを表明しています。 Ubuntu のメンバーは、Ubuntu for Windows や不運な Edge プロジェクトについて何も知りませんでした。
Red Hat CEO の Jim Whitehurst は、オープン ソースに対する同社のアプローチについての質問に対して、「私たちは物事をためらわない」と答えました。 私たちが物事を構築するとき、私たちはそれを隠して大々的に公開し、「ここにコードがあります」と言うようなことはしないのです。 そんなことはしない。 私たちは、初日からずっと、コミュニティで活動しています。 私たちは本当に良い参加者であろうとし、それが伝わっていると思います」
これらの違いに加えて、Canonical は、情報を公開することに関して、いくつかの誤った手順を踏むことでも知られています。 これは、Snap のクロスディストリビューション サポートを発表したときがまさにそうでした。Fedora 開発者を苛立たせた表現は、”Developers from multiple Linux distributions” でした。 はっきり言って、CanonicalはプレスリリースでFedoraと連携していると明言したことはありません。 そして、私たちが収集した情報によると、Fedora、Red Hat、SUSE などの Linux ディストリビューションとの「公式」な関わりはありませんでした。
とはいえ、どのようにプロジェクトと「連携」するかという疑問が生じます。 あるアプリに取り組んでいる開発者が、Ubuntu の開発者、Fedora の開発者、および openSUSE の開発者と協力して、それらのプラットフォームにアプリを提供する場合、開発者が複数のディストリビューションと協力してアプリを提供したと言うのは間違いでしょうか。 それとも、開発者がそのような発言をするためには、これらのディストリビューションのプロジェクト・リーダーと公式に関わる必要があるのでしょうか? 結局のところ、分散したオープン ソース コミュニティなのです。
Whither Snap?
より大きな疑問は、Snap は他のディストロによって公式に採用されるのでしょうか。 そこが少し複雑になるところです。
まず第一に、Snap はこの辺りの唯一のソリューションではありません。 Linux エコシステムのためにディストロに依存しないパッケージング エコシステムを提供しようとしたプロジェクトは数多くあります。 しかし、Linux ディストロの世界でコンセンサスを得るのは難しいかもしれません。 これらのプロジェクトは Snap よりもずっと長く存在しています。
では、なぜ Canonical は Click や Snap を開始する代わりにこれらのソリューションを採用しなかったのでしょうか。 リーフ ノード アプリケーションは、他のアプリケーションと統合する必要がないものです。 Snapは、どちらかというと、依存関係や関連するアプリケーションをパッケージ化するために設計されました。 「Snap には、インターフェイス、プラグ、スロット、および共有ファイルなど、それらの接続を記述するためのさまざまな機能があります」
それに加えて、Shuttleworth は、携帯電話に取り組むチームがセキュリティと効率性に焦点を当てたため、および Snap が新しいカーネル機能を使用するため、AppImage と比べてより高いレベルのセキュリティのために設計されている、と述べました。 私が質問したところ、Shuttleworth はそれを 1 人の開発者によって開発されているプロジェクトであると否定しました。
これで、Canonical が Snap に進んだ理由がわかりました。 Fedora の開発者はすでに Snap を使用しないことを宣言しています。 ある Fedora 開発者はメーリングリストに、「私たちは、もちろん、Fedora で Snappy を採用する予定はありませんし、実際、複数の Fedora 開発者が競合ソリューションである Flatpak に取り組んでいます」
以前 Red Hat は Upstart というシステム初期化用の Canonical プロジェクトを採用しました。 Hellekson は、「これらのパッケージングの取り組みすべてにとって、今は非常に初期の段階であり、Linux ユーザーができるだけ簡単に生活できるように、すべての関連コミュニティと協力することを楽しみにしています」と述べています。 その1つは、開発者がSnapプロジェクトに貢献する場合、CLA（Contributor License Agreement）にサインしなければならないことです。 Canonicalの開発者であるMichael Hall氏は、「CLAは、開発者がSnapプロジェクトそのものに貢献しようとする場合に必要なものだ」と述べている。 アプリケーションの Snap を作成したり配布したりするには CLA は必要ありません」
CLA によって、Canonical はプロジェクトのライセンスを変更することができます。 これは、Canonical にとって有益です。プロジェクトを再ライセンスすることで、フリーではないライセンスや互換性のないライセンスで使用できるようになるからです。
Nextcloud の Frank Karlitschek 氏は、オープンソース コミュニティ内で CLA はあまり良い評判を持たれていないと感じており、Nextcloud から CLA を終了していると話してくれました。 私たちは、ストレートでオープンなソース ライセンスが、より良い、より包括的なアプローチであると考えています」
SUSEの回答もほぼ同じでした。 Pfeifer は、「SUSE のエンジニアとスタッフは、会社の時間と私たち自身の時間の両方で、多くのオープン ソース プロジェクトに貢献し続けており、必要な場合には CLA に署名しています」と述べています。 しかし、私たちがプロジェクトを開始したり、影響を与えたりするときはいつでも、どこでも、CLAには近づかないようにしています。 私たちは一般的に、組織が非オープン ソース ライセンスを使用してオープン ソース コードを再ライセンスすることを可能にする著作権を割り当てる CLA を好みません」
他のディストロからの幅広いサポートを得るために Snap から CLA を取り除くことを検討するかどうかを Shuttleworth に尋ねたところ、彼はまず、なぜ CLA が良いのかを説明しましたが、「それが違いを生むなら、はい、それを取り除く方法を見つけます」とも述べました。”
And Then There was One?
時とともに、成熟度、人気、そして一方に対する技術的優位性から、ひとつのソリューションが残されるかもしれません。 以前、Upstart と systemd でそれを見ました。systemd は優れたテクノロジーとして出現し、3 つの主要な Linux ディストリビューションすべてでデフォルトとなりました。
いずれの場合も、両方のテクノロジーは開発の初期段階にあり、どちらのプロジェクトが成功するかはわかりません。 しかし、コンテナー中心の世界では、Linux が新しいアプリ配信メカニズムを必要としていることは明らかです。
多くの企業やコミュニティが、Snap のようなソリューションのサポートを表明しています。 Samsung と Dell はプレス コールで Canonical に参加し、このようなソリューションの必要性を述べました。 デスクトップ側では、LibreOffice や Firefox などのプロジェクトがすでに Snap のサポートを表明しています。
Snap が Ubuntu 以外で採用されるかどうかは、時間が経てばわかるでしょう。 Snap が将来どうなるにせよ、Canonical が限界を押し広げ、Linux コミュニティの他のメンバーに、私たちが慣れ親しんできた、あるいはおそらく解決するモチベーションがなかった問題の解決に最終的に焦点を当てるよう強制したことは、十分に評価されるべきことでしょう。