Canonical vient de publier la première bêta d’Ubuntu Core 16, une version spécifique de la distribution qui ne se destine pas au grand public. Core est en effet bâti comme un ensemble de modules snap et est davantage tourné vers le cloud. On se demande toutefois si l’éditeur ne sera pas tenté d’en faire une nouvelle fondation.
En avril dernier, Canonical lançait Ubuntu 16.04 et ses snaps. Il s’agissait d’un nouveau format de paquet qui permettait d’inclure dans un même lot toutes les dépendances liées à un logiciel. On pouvait en déduire un gros avantage ainsi qu’un inconvénient potentiellement important : si d’un côté l’utilisateur n’avait plus à se préoccuper de la moindre dépendance, le poids des paquets devenait parallèlement beaucoup plus important.
Un monde de snaps
Vendredi dernier, l’éditeur a publié cette fois la dernière bêta d’Ubuntu Core 16. La version Core de la distribution s’oriente vers la mise en place de serveurs et le cloud. Elle ne se destine donc pas au grand public. Cette mouture 16 se distingue toutefois sur un point important : elle est entièrement conçue sur la base des snaps.
Tous les composants du système sont ainsi encapsulés dans des paquets snap. Contrairement à la distribution de base, cela concerne également les briques du système et plus seulement les applications. Ce qui est valable aussi bien pour le kernel que pour les bases élémentaires, toutes mises à jour par le démon snapd, qui s’occupe de fait de l’intégralité des paquets.
Pour quelques plateformes pour l'instant
Conséquence, l’ensemble se veut beaucoup plus modulaire, et si la bêta fournie se destine aux PC avant tout, elle est annoncée comme compatible avec les Raspberry Pi 2 et 3. À l’heure actuelle, on ne peut cependant que récupérer les images i386, x86_64 et RP2. Devraient suivre rapidement des images pour les ordinateurs composés d'une carte Dragonboard 410c.
Notez également que cette bêta est « feature freeze », autrement dit elle contient toutes les fonctionnalités prévues pour la version finale. Comme indiqué par l’équipe de développement, « les prochaines semaines seront exclusivement consacrées à la stabilisation et au polissage ».
L'avenir d'Ubuntu ?
Difficile de ne pas imaginer Canonical se tourner davantage vers les snaps à l'avenir. Il est évident que l'éditeur n'a pas mis en place un tel système pour ne l'utiliser qu'en partie. Aussi, si Core 16 n'est clairement pas conçu pour le grand public, on peut se demander si un système entièrement basé sur les snaps ne représente pas l'avenir d'Ubuntu à plus longue échéance. Il est probable que Canonical réfléchisse à la question, mais en se laissant du temps pour la réflexion.
Rappelons que d'autres briques importantes sont déjà en cours d'approche, notamment Unity 8 et le serveur d'affichage Mir. Canonical les promet depuis longtemps, mais comme on a pu le voir récemment, ils se dessinent enfin, la dernière bêta d'Ubuntu 16.10 permettant de les utiliser dans une session de test.
Commentaires (25)
Je connaissais pas ce machin de snap, mais plus je lis, plus je trouve que ça ressemble à de l’isolation dans le noyau comme docker. Me trompé-je ?
A tester, mais ça me parait très intéressant pour les serveurs effectivement. Et peut être aussi pour l’embarqué. Pour le desktop, un peu moins, mais je demande à voir.
Si j’ai bien compris, cela y ressemble un peu, sauf que docker est plus “bas-niveau” puisqu’ils utilisent les namespaces, cgroups et autres joyeseté du kernel, et permets des filesystems différenciés. C’est donc un peu plus proche du noyau que Snaps, qui s’arrête dans l’isolation au niveau des librairies-packages.
Je me demande, c’est pas très clair sur la page marketing ce que ça fait, mais je lis ici :
“And to ensure that apps can be installed safely, they are isolated using kernel containers”
Bonjour les majs de sécurité lorsqu’il faudra patcher/rebuild 30 paquets snaps contenant une version d’OpenSSL trouée.
Difficile de ne pas imaginer Canonical se tourner davantage vers les snaps à l’avenir. Il est évident que l’éditeur n’a pas mis en place un tel système pour ne l’utiliser qu’en partie. Aussi, si Core 16 n’est clairement pas conçu pour le grand public, on peut se demander si un système entièrement basé sur les snaps ne représente pas l’avenir d’Ubuntu à plus longue échéance. Il est probable que Canonical réfléchisse à la question, mais en se laissant du temps pour la réflexion.
En fait oui c’est prévu et ça s’appellera Ubuntu Personal. et ce sera oriente vers tout ce qui est smartphone/tablette/PC la ou Ubuntu Core est oriente serveurs et IoT.
c’est ce que je me suis dit quand j’ai lu le descriptif…
après, rien ne les empêchent de faire des majs de type patch qui ne prendraient que les fichiers modifiés, et de simplement remplacer dans le container sans avoir a tout rebuild vu que c’est dans des containers…
Ca revient un peu à un setup.exe
" />
Oui, et il sera bientôt aussi compliqué de tenir à jour une ubuntu qu’un windows. C’est ça le progrès ma p’tite dame !
Je pense que c’est du coup Ubuntu Core qui se rapproche de docker, bien plus que Snap. Canonical tente d’offrir un ensemble plus homogène que Docker en liant les deux niveaux, pour le meilleur et pour le pire.
M’interesserait de savoir ce que ça donne sur un Raspberry Pi 2….
Ca va pas trop ramer?
Niveau zéro de l’argumentation… Bravo!
En faite ce truc un retour en arrière sur le plan de l’unification et de la réutilisation des composants/lib.
Il y a seulement un intérêt au niveau isolation des librairies mais ne va pas jusqu’au bout et pour quel gain ? La portabilité au détriment de l’espace disque peut-être.
Cela permet aux gens de faire des build crade dépendant de rien qui pourront ne jamais recevoir de mis à jour de sécurité, Es un progrès je ne penses pas.
Le seul usage intéressant que je vois c’est pour faire des release d’app qui s’appuie sur des lib trop récentes pour certaine distribution.(à condition qu’elles ne dépendent pas du system, intégration graphique/kernel)
Au niveau de la sécurité ça l’améliore si il y a team dev qui s’occupe du snap est plus réactive que les team secu distribution. (exemple OpenSSL résume assez bien la situation)
Moué… A voir à l’usage…
Performance revu à la baisse, paquet plus lourd, possibilité de faire des build bien crade.
Ceci est une révolution, pour les utilisateurs de windows.
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
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 12⁄13 novembre 2016
Merci pour tes précisions.
Mais du coup, lorsque tu mets à jour l’application X pour corriger une faille OpenSSL, cela ne mets pas à jour les OpenSSL buildés dans les autres paquets snap. De plus, cela nécessite que le développeur rebuild son application.
Je ne suis pas sûr que tous les développeurs le feront.
Alors qu’avec un système de paquets comme apt/dnf… Tu ne mets à jour qu’une seule application.
Niveau 0 degré kelvin de la contre-argumentation
" />
@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)
Ben pas certain, la grosse faiblesse de linux pour le progiciel est justement l’absence de snaps (ou équivalent) à pousser chez le client.
Du coup entre l’intégration continue avec docker et le démerde toi avec les packages un peu anciens qui n’ont plus de sources pour leurs dépendances il y aura les snaps. Pourquoi pas.
Ca évite d’avoir à gérer la rétrocompatibilité quand tu as validé une version de ton soft avec une version de ses dépendances tu peux livrer un snap au lieu de devoir mener du test en continu dès qu’une virgule change dans les libs.
C’est nul techniquement en terme de mutualisation des ressources mais sur des progiciels où la fiabilité prime sur cette mutualisation ou sur le fait d’avoir des composants à jour c’est un manque de linux qui se comble avec un embryon de standard qui pourrait à terme concurrencer une grande force de Windows (qui suit le chemin inverse avec Windows 10 en poussant des majs par défaut des composants système).
Je n’avais pas pensé à snap dans cette optique là perso, plutôt comme un moyen de packager des apps “à la windows” dans le cadre de gros devs à l’ancienne avec cycles en V.
" />
J’avais principalement retenu le fait qu’on pouvait faire un snap d’une stable et d’autres de versions de test mais j’étais passé à côté du fait que les snaps se mettent à jour quotidiennement, merci de tes explications
@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