Le snap est-il portable sur d'autres UNIX (par exemple macOS)?

J'adore l'idée derrière Snap et j'ai joué avec sur une machine virtuelle Ubuntu.

Présentation de Snapcraft

Snapcraft est un outil de construction et de packaging qui vous aide à empaqueter votre logiciel en un clin d'œil. Il facilite l'intégration de composants de différentes sources et la création de technologies ou de solutions. Concepts clés

Un package .snap pour le système Ubuntu Core contient toutes ses dépendances. Cela présente quelques avantages par rapport à la gestion traditionnelle des dépendances basées sur deb ou rpm, le plus important étant qu'un développeur peut toujours être assuré qu'aucune régression n'est déclenchée par des modifications du système sous son application.

Snapcraft facilite le regroupement de ces dépendances en vous permettant de les spécifier en tant que "parties" dans le fichier snapcraft.yaml. Snappy

Snappy Ubuntu Core est une nouvelle interprétation d'Ubuntu avec des mises à jour transactionnelles - une image de serveur minimale avec les mêmes bibliothèques que Ubuntu d'aujourd'hui, mais les applications sont fournies via un mécanisme plus simple.

Les applications Snappy et Ubuntu Core lui-même peuvent être mis à niveau atomiquement et annulés si nécessaire. Les applications sont également strictement confinées et mises en bac à sable pour protéger vos données et votre système.

IoT ›Créer des applications

Sur quelles technologies Snap est-il basé? À quoi ressemblent l'architecture et les kits d'outils? Le snap dépend-il des fonctionnalités du noyau Linux?

Je demande, parce que je me demande si à l'avenir je serai en mesure d'utiliser les mêmes packages snap également sur macOS?

Précision, après le premier commentaire:

Je sais que macOS et Ubuntu ne sont pas compatibles binaires. Une recompilation est nécessaire. Il existe presque tous les Open Source disponibles pour macOS avec Homebrew . Le développeur pourrait développer sur macOS et déployer sur Ubuntu lorsque le snap sera (à l'avenir) disponible pour macOS.

Oui, grâce à la stabilité de l'interface syscall Linux, c'est possible.

L'un des grands engagements de Linus Torvalds envers les utilisateurs de Linux est que l'ensemble des interfaces proposées par le noyau est stable. Beaucoup de gens n'apprécient pas la valeur de cela, ni combien il est difficile en tant que leader d'un projet ouvert d'atteindre cet engagement. Considérez par exemple à quel point les changements imprévisibles dans les API GNOME sont en contraste! Lorsque vous entendez que Linus s'intensifie sur une liste de diffusion, c'est presque toujours parce qu'un utilisateur du noyau a décidé de changer une telle interface «parce qu'ils avaient une meilleure idée». Linus dit que vous pouvez innover énormément À L'INTÉRIEUR du noyau, mais s'il vous plaît, ne cassez pas les applications de l'espace utilisateur qui dépendent des appels système existants.

En raison de cette stabilité, il est possible que d'autres noyaux offrent les mêmes appels système, permettant aux applications basées sur Linux de s'exécuter sur ces autres noyaux.

Un exemple en est le projet Joyent Triton, qui propose des appels système compatibles Linux dans des conteneurs sur SmartOS (un descendant d'IllumOS, un descendant de Solaris).

Un exemple plus connu est le nouveau sous-système Linux dans Windows .

Bien sûr, combien de syscalls sont offerts, et comment ils sont compatibles bogue pour bogue, est la vraie question. Au moins pour l'instant, il n'y a pas d'autre environnement où tous les appels système nécessaires sont en place, car ceux que les snaps utilisent sont relativement nouveaux et profonds dans la façon dont le noyau pense aux choses qu'il gère.

Mais ils viendront certainement, avec le temps, et je pense que les snaps seront donc utilisables dans un large éventail de contextes.

Ce qui est très cool, les patchs sont les bienvenus :)

Bien que je ne trouve aucune information sur macOS, cet OMG! L' article d' Ubuntu a une citation intéressante de Mark Shuttleworth:

Quant à l'exécution de Snaps sur Windows 10? "C'est absolument plausible", a déclaré Shuttleworth.

«Les snaps utilisent des fonctionnalités modernes du noyau Linux pour effectuer le confinement de sécurité, configurer l'accès au système de fichiers, etc., et tout cela implique l'utilisation de mécanismes modernes dans le noyau. Et Canonical a mené beaucoup de [ce travail]. Il faudra un certain temps à Microsoft pour [pouvoir s'y connecter]. »

S'il est "plausible" de le faire fonctionner sous Windows, je dirais la même chose pour macOS, sauf que Microsoft semble coopérer avec Canonical, ce qui n'est pas quelque chose que j'ai entendu parler d'Apple.

La documentation sur la politique de sécurité et le sandboxing de Snap et l'entrée Arch Wiki sur snapd sont informatives:

Du Arch Wiki:

Notez que snap-confine est construit avec l'option --disable-confinement; le confinement complet repose sur un noyau compatible AppArmor et un profil associé pour le snap.

De la politique:

Sous le capot, le lanceur:

• Configure différentes variables d'environnement: […]
• Lorsque le matériel est affecté au snap, configure un groupe de contrôle de périphériques avec des périphériques par défaut (par exemple, / dev / null, / dev / urandom, etc.) et tous les périphériques affectés à ce snap
• Configure un / tmp privé à l'aide d'un espace de noms de montage privé par commande et monte un répertoire par commande sur / tmp
• Configure une per-commande pour une nouvelle instance
• Configure le filtre seccomp pour la commande
• Exécute la commande sous le profil AppArmor spécifique à la commande sous une belle valeur par défaut

Cette combinaison de profils AppArmor restrictifs (qui assurent l'accès aux fichiers, l'exécution des applications, les capacités Linux (7), le montage, le ptrace, l'IPC, les signaux, la mise en réseau à granularité grossière), les zones de système de fichiers spécifiques à l'application clairement définies, le filtrage des appels système par liste blanche via seccomp, privé / tmp, les nouveaux devpts d'instance et les groupes de périphériques permettent un confinement et une isolation forts des applications.

Bien que AppArmor et seccomp soient uniquement Linux, il semble que le confinement puisse être rendu facultatif, nous pouvons donc l'ignorer. Ensuite, il y a l'utilisation des devpts, des cgroups et des espaces de noms de montage. S'il y a un blocage, je pense que ce serait pour ceux-là. Je ne connais pas suffisamment les BSD pour dire quels sont les équivalents.

L' snapdapplication elle-même est écrite en Go, ce qui devrait la rendre raisonnablement multiplateforme. En effet, certains fichiers ont des cibles de build très intéressantes :

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

Il semble donc que quelqu'un s'intéresse à cela.