Snap est-il portable sur d’autres UNIX (exemple macOS)?
J'aime l'idée derrière snap et j'ai joué avec cela sur une machine virtuelle Ubuntu.
Snapcraft Vue d'ensemble
Snapcraft est un outil de construction et d’emballage qui vous aide à emballer votre logiciel en un tournemain. Il facilite l'intégration de composants de différentes sources et la création de technologies ou de solutions. Concepts clés
Un paquet .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ée sur deb ou rpm, le plus important étant qu'un développeur puisse toujours être assuré qu'il n'y a pas de régression déclenchée par des modifications du système sous l'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 version d'Ubuntu avec des mises à jour transactionnelles - une image de serveur minimale avec les mêmes bibliothèques que celle d'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 de manière atomique et annulés si nécessaire. Les applications sont également strictement confinées et mises en sandbox pour protéger vos données et votre système.
IoT ›Construire des applications
Sur quelles technologies est basé Snap? À quoi ressemblent l'architecture et les kits d'outils? La capture dépend-elle des fonctionnalités du noyau Linux?
Je demande, parce que je me demande si à l’avenir, je serai capable d’utiliser les mêmes paquets instantanés é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 y a presque tout Open Source disponible pour macOS déjà avec Homebrew . Le développeur pourrait développer sur macOS et déployer sur Ubuntu lorsque la capture sera disponible (à l'avenir) pour macOS.
Oui, grâce à la stabilité de l'interface Linux Syscall, cela est possible.
L'un des grands engagements de Linus Torvalds vis-à-vis des utilisateurs de Linux est que l'ensemble des interfaces offertes par le noyau est stable. Beaucoup de gens n'apprécient pas la valeur de ceci, ni combien il est difficile en tant que leader d'un projet ouvert de réaliser cet engagement. Considérez par exemple à quel point les modifications imprévisibles dans les API GNOME sont en revanche! Quand vous entendez parler de Linus devenir très actif sur une liste de diffusion, c'est presque toujours parce que certains utilisateurs du noyau ont décidé de changer une telle interface "parce qu'ils avaient une meilleure idée". Linus dit que vous pouvez innover à l’intérieur du noyau, mais veuillez ne pas endommager les applications "espace utilisateur", qui dépendent des appels système existants.
En conséquence de cette stabilité, il est possible que d'autres noyaux offrent les mêmes appels système, permettant aux applications construites sous Linux de s'exécuter sur ces autres noyaux.
Le projet Joyent Triton, qui propose des appels système compatibles avec Linux dans des conteneurs sur SmartOS (un descendant de IllumOS, un descendant de Solaris), en est un exemple.
Un exemple plus connu est le nouveau sous-système Linux sous Windows .
Bien sûr, combien de syscalls sont proposés et comment ils sont compatibles bogue pour bogue, est la vraie question. Du moins pour le moment, il n’existe pas d’autre environnement où tous les appels système nécessaires sont en place, car ceux que les instantanés utilisent sont relativement nouveaux et profondément dans la façon dont le noyau envisage les choses qu’il gère.
Mais ils viendront certainement, avec le temps, et je pense que les instantanés seront ainsi utilisables dans un large éventail de contextes.
Ce qui est très cool, les correctifs bienvenus :)
Bien que je ne trouve aucune information sur macOS, cet article OMG! Ubunt contient une citation intéressante de Mark Shuttleworth:
Pour ce qui est d’exécuter des captures sur Windows 10? "C’est absolument plausible" a déclaré Shuttleworth.
"Les instantanés utilisent les fonctionnalités modernes du noyau Linux pour sécuriser la 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 mène beaucoup de [ce travail]. Il faudra un certain temps à Microsoft pour [avoir le temps de l’accrocher]. "
S'il est "plausible" de le faire fonctionner sous Windows, je dirais qu'il en va de même pour macOS, sauf que Microsoft semble coopérer avec Canonical, ce que je n'ai pas entendu dire à propos de Apple.
La documentation sur politique de sécurité Snap et sandbox et l'entrée Arch Wiki sur snapd sont informatives:
Depuis le Wiki Arch:
Notez que snap-confine est construit avec l'option --disable-confinement; Le confinement complet repose sur un noyau compatible avec AppArmor et sur un profil associé pour la capture.
De la politique:
Sous le capot, le lanceur:
- Configure diverses variables d'environnement: […]
- Lorsque du matériel est affecté au composant logiciel enfichable, configure un groupe de contrôle de périphériques avec les périphériques par défaut (par exemple,/dev/null,/dev/urandom, etc.) et tous les périphériques attribués à ce composant logiciel enfichable.
- Configure un private/tmp en utilisant un espace de noms de montage privé par commande et en montant un répertoire par commande sur/tmp
- Configure une nouvelle instance par commande
- Configure le filtre seccomp pour la commande
- Exécute la commande sous le profil AppArmor spécifique à la commande sous une valeur Nice par défaut.
Cette combinaison de profils AppArmor restrictifs (qui facilitent l’accès aux fichiers, l’exécution d’application, les fonctionnalités Linux (7), mount, ptrace, IPC, signaux, mise en réseau à grain grossier), des zones de système de fichiers spécifiques à l’application clairement définies, le filtrage des appels systématiques via SecComp, privé/tmp, les nouveaux développements d'instance et les groupes de contrôle de périphériques permettent un confinement et une isolation puissants des applications.
Bien qu'AppArmor et seccomp soient uniquement basés sur Linux, il semble que le confinement puisse être rendu facultatif. Nous pouvons donc l'ignorer. Il y a ensuite l'utilisation des devpts, des groupes de contrôle 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 assez les BSD pour dire quels sont les équivalents.
L'application snapd elle-même est écrite en Go, ce qui devrait la rendre raisonnablement multi-plateforme. En effet, certains fichiers ont cibles de construction 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.