他のUNIX（例macOS）間でスナップポータブルですか？

スナップの背後にあるアイデアが気に入って、Ubuntu VMで遊んだ。

Snapcraftの概要

Snapcraftは、ソフトウェアをスナップとしてパッケージ化するのに役立つビルドおよびパッケージ化ツールです。これにより、さまざまなソースからのコンポーネントを簡単に組み込み、テクノロジーやソリューションを構築できます。重要な概念

Ubuntu Coreシステムの.snapパッケージには、すべての依存関係が含まれています。これには、従来のdebまたはrpmベースの依存関係処理に比べていくつかの利点があります。最も重要なのは、開発者がアプリの下のシステムへの変更によって引き起こされるリグレッションがないことを常に保証できることです。

Snapcraftは、snapcraft.yamlファイルで「パーツ」として指定できるようにすることで、これらの依存関係を簡単にバンドルできます。スナッピー

Snappy Ubuntu Coreは、トランザクションの更新を含むUbuntuの新しいレンディションです。現在のUbuntuと同じライブラリを備えた最小限のサーバーイメージですが、アプリケーションはより単純なメカニズムで提供されます。

SnappyアプリとUbuntu Core自体はアトミックにアップグレードでき、必要に応じてロールバックできます。また、データとシステムを保護するために、アプリは厳格に制限およびサンドボックス化されています。

IoT›アプリの構築

どのテクノロジーがスナップベースですか？アーキテクチャとツールキットはどのように見えますか？スナップはLinuxカーネル機能に依存しますか？

将来、macOSでも同じスナップパッケージを使用できるかどうか疑問に思っているので、質問します。

明確化、最初のコメントの後：

macOSとUbuntuはバイナリ互換ではないことを知っています。再コンパイルが必要です。Homebrewを備えたmacOSですでに利用可能なオープンソースはほとんどありません。開発者は、macOSで開発し、スナップショットが（将来的に）macOSで利用可能になったときにUbuntuに展開できます。

はい、Linux syscallインターフェースの安定性のおかげで、これは可能です。

Linuxユーザーに対するLinus Torvaldsの大きなコミットメントの1つは、カーネルによって提供される一連のインターフェースが安定していることです。多くの人々は、これの価値や、そのコミットメントを達成するためのオープンプロジェクトのリーダーとしての困難さを理解していません。たとえば、GNOME APIの予測不可能な変更が対照的にどのようになっているのか考えてみてください。Linusがメーリングリストで激しくなっていると聞いたとき、それはほとんどの場合、カーネルのコミッターがそのようなインターフェースを「より良いアイデアを持っていたため」変更することを決めたためです。Linusはカーネル内で大胆に革新できると言いますが、既存のシステムコールに依存する「ユーザースペース」アプリを壊さないでください。

その安定性の結果として、他のカーネルが同じsyscallを提供することが可能になり、Linuxで構築されたアプリがそれらの他のカーネルで実行できるようになります。

その一例がJoyent Tritonプロジェクトで、SmartOS（Solarisの子孫であるIllumOSの子孫）上のコンテナーでLinux互換のsyscallを提供しています。

より広く知られている例は、Windowsの新しいLinuxサブシステムです。

もちろん、いくつのsyscallが提供されているか、そしてどれだけのバグとバグの互換性があるかが本当の問題です。少なくとも今のところ、必要なすべてのsyscallが配置されている別の環境はありません。スナップが使用するものは比較的新しく、カーネルが管理するものについて考える方法が深いためです。

しかし、それらは確実に間に合い、スナップは幅広いコンテキストで使用できると私は思います。

パッチは大歓迎です:)

macOSについての情報は見つかりませんが、このOMG！Ubuntuの記事には、マーク・シャトルワースからの興味深い引用があります：

Windows 10でSnapを実行するのはどうですか？「それは絶対にもっともらしい」シャトルワースは言った。

「スナップは、Linuxカーネルの最新機能を使用して、セキュリティの制限、ファイルシステムアクセスのセットアップなどを行います。これらすべてには、カーネルで最新のメカニズムを使用することが含まれます。そしてCanonicalは[この作品]の多くをリードしています。Microsoftが[フックする]にはしばらく時間がかかります。」

Windowsで実行するのが「もっともらしい」のであれば、MicrosoftがCanonicalと協力しているように見えることを除いて、macOSについても同じことを言います。

上のドキュメントのスナップセキュリティポリシーとサンドボックスとsnapd上のアーチのWikiエントリは有益です。

Arch Wikiから：

snap-confineは--disable-confinementオプションで構築されていることに注意してください。完全な制限は、AppArmor対応のカーネルとスナップの関連プロファイルに依存しています。

ポリシーから：

ボンネットの下で、ランチャー：

• さまざまな環境変数を設定します：[…]
• ハードウェアがスナップに割り当てられている場合、デフォルトのデバイス（例：/ dev / null、/ dev / urandomなど）とこのスナップに割り当てられているデバイスでデバイスcgroupをセットアップします
• コマンドごとのプライベートマウント名前空間を使用してプライベート/ tmpをセットアップし、コマンドごとのディレクトリを/ tmpにマウントする
• コマンドごとのdevpts新しいインスタンスを設定します
• コマンドのseccompフィルターをセットアップします
• デフォルトのnice値の下でコマンド固有のAppArmorプロファイルの下でコマンドを実行します

この制限のあるAppArmorプロファイルの組み合わせ（ファイルアクセス、アプリケーション実行、Linux機能（7）、マウント、ptrace、IPC、シグナル、粒度の粗いネットワーキングを仲介します）、明確に定義されたアプリケーション固有のファイルシステム領域、seccompを介したシステムリストフィルタリング、プライベート/ tmp、新しいインスタンスdevptsおよびデバイスcgroupsは、強力なアプリケーションの制限と分離を提供します。

AppArmorとseccompはLinuxのみですが、制限はオプションにすることができるため、無視できます。次に、devpts、cgroups、mount名前空間の使用法があります。何かブロッキングがあれば、それはそれらのためだと思います。相当するものを言うのに十分なほどBSDに精通していません。

snapdそれが合理的にクロスプラットフォームにする必要があり、それ自体はゴーで書かれたアプリケーション、。実際、一部のファイルには非常に興味深いビルドターゲットがあります。

osutil/group_other.go：

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build !linux,!darwin,!freebsd

osutil/group_linux.go：

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build darwin freebsd linux
// +build cgo

だから、誰かがこれに興味を持っているようです。