Pour répondre à la problématique des maj de sécurité type openSSL, la méthode recommandée pour créer des snaps est l’utilisation de Snapcraft. Il permet de crée une recette en définissant des parties d’applications, où trouver les sources et comment les construire.



Du coup dans le cadre d’un daily-build automatisé, si on précise que la source d’OpenSSL c’est le GitHub du projet, on récupère toujours la dernière version proposée par la Team et non la version distribution. Reste plus qu’à faire un coup de QA, puis de pousser la nouvelle version de son appli sur le store, et tous les appareils ayant votre applications se mettront automatiquement à jour, pratique notamment dans l’IoT, pas besoin de rebuilder une image entière. On peut se permettre de mettre à jour automatiquement les appareils, puisque les librairies étant isolées, une maj d’application ne va pas casser les autres applications.



 Les snaps ne sont pas des conteneurs, mais des FS squashFS en lecture seule, doublée d’une protection d’accès AppArmor et de l’utilisation des filtres de processus SecComp. Pas d’utilisation des namespaces du noyau.



Pour réduire la taille des snaps, on peut créer des snaps “framework” (ex: KDE). Le framework KDE va exposer des fonctionnalités via différents bus ou interfaces. Ainsi une application peut dépendre d’un ou plusieurs snaps sur laquelle elle va s’accrocher, donc pas de problème de compatibilté.



On peut aisément faire des rollback, gérer les versions présentes, à peu à l’image de ce que l’on fait lors de livraisons applicatives quand on est ingé support applicatif (middlewares/couches hautes)



Les snaps sont aussi compatibles Gentoo, ArchLinux, Fedora, Debian en y installant snapd, et puisque c’est une construction par ensembles, on peut donc construire avec :



 - Des robots

• Des objets “intelligents” ou IoT (Mycroft, des smartswitch)
  


• Des drones
  


• Des services destinés au Cloud (Les snaps fonctionnent sur OpenStack, Azure, AWS…)
  


• Des serveurs
  


• Des postes de travail
  


• Des téléphones ou tablettes
  
   
  
  Pour ceux que ça intéresse, il me semble de Didier Roche de chez Canonical sera là pour en parler à l’Open Source Summit Paris. Sinon j’en parlerai plus profondement lors de l’Ubuntu Party Paris les ¹²⁄₁₃ novembre 2016

@yelin



De nos jours, on utilise le plus souvent des builds automatisé comme le permet Jenkins par exemple. D’ailleurs il me semble qu’il existe un plugins Jenkins pour Snapcraft, ou alors c’est en cours.



Quoiqu’il en soit, puisque la recette Snapcraft ne change pas, il te suffit de créer un script que tu place sur la cron en daily qui build ton app et te prévienne au cas où une des parties du build a changé histoire que tu fasse des tests. Ainsi, si la lib OpenSSL est mise à jour, toutes tes apps qui l’utilisent se construiront en automatique, et tu recevra un mail te disant de tester les nouveaux snaps. C’est prévu pour être totalement industrialisable.



Pour rappel, le coeur de métier de Canonical c’est le Cloud donc les outils qu’ils créent sont quand même vachement orientés DevOps (donc automatisation à outrance)

@yvan, en fait ce n’est pas tant au niveau des progiciels mais du packaging le problème. 

Question progiciel, en mode serveur, on s’en sort plutôt pas trop mal.

 

Déjà, question IoT, en règle général tu mets à jour l’image pour ton objet et non une app, ce qui est particulièrement relou de toujours rebuilder des images intégralement et de faire en sorte que tes clients upgrade leur objet, du coup tu te retrouve avec un tas d’objets totalement non sécurisé. Alors dans le cadre d’un thermostat, d’une télé toussa c’est chiant question vie privée, m’enfin c’est pas la mort non plus, par contre dans le cas d’une voiture, ça devient tout de suite plus compliqué. Avec les snaps, tu as un OS de base, des frameworks, et des apps, le tout étant indépendant. On peut imaginer que le constructeur de voiture sera vigilant sur tout les composants critiques avec des maj régulières OTA, et permettent des applications tiers non critiques sur son store



Oui parce que c’est aussi un truc sympa avec les snaps, c’est que tout constructeur peut ajouter (c’est tout l’intérêt du truc) un magasin d’application, qu’il gère à sa sauce (un simple serveur web suffit). Du coup, si je propose un jouet type BB-8 de sphero, ben au lieu d’être bridé par les comportement du bidule que moi, constructeur, j’ai ajouté, je peux proposer un store pour des développeurs tiers, ce qui veut dire que j’ai la possibilité de monétisé du contenu (comme apple store, Google play, ou la logitheque ubuntu). Les devs peuvent y vendre (ou pas) leur applis sous licences FLOSS ou non libre.



Enfin, dernier atout, c’est la facilité de construire des paquets depuis n’importe quelle source. C’est pas du scripting, mais un fichier déclaratif Yaml, dans lequel on précise la source, le type d’appli (maven, python, c, java, etc) et les paramètres de build.



Du coup, beaucoup d’applis de github qui n’ont pas été packagée peuvent l’être, même si on essaie de travailler avec les projets upstream pour qu’ils crachent du snap en automatique (en écrivant pour eux la recette).



La où je te rejoins question progiciel, c’est que l’application étant packagée avec tout ce dont elle a besoin, et pouvant exposer des interfaces, tu vas non seulement pouvoir avoir des applis en stable et en bêta cohabitant ensemble, mais du coup tes plugins se connecteront automatiquement au deux, sans se poser de question. Du coup, tu peux vraiment tester que la partie du progiciel qui t’intéresse et les plugins peuvent être plus facilement mutualisables.



Alors clairement il a fallu s’affranchir de la philosophie KISS d’Unix (en plus ça repose beaucoup sur systemd pas franchement KISS), mais qui est totalement inadaptée à l’informatique ubiquitaire d’aujourd’hui. C’est fini les années 80, plus personne ne porte la coupe mulet, François s’appelle Hollande et Sophie Marceau ou Drew Barrymore sont devenues des Milf. Faut vivre avec son temps les mecs, 30 ans en terme d’informatique c’est comme parler paléolithique en Histoire. Même en politique ils sont plus évolués, les dinosaures viennent des années 90, c’est dire.



Bref, j’espère que les snaps perceront, y’a des gens vraiment brillants derrière, y’a une grande curiosité de la part de nombreux industriels, un certain engouement de leaders de communautés FLOSS, et peut-être même qu’après Bash on Windows, les snaps puissent aussi débarqués sur l’OS de Redmond ce qui en ferait une ADM