Il y a quelques semaines, Canonical a annoncé la prise en charge par plusieurs distributions du mécanisme de livraison d’applications Snap, un mécanisme qui pourrait prendre en charge les applications mobiles, de bureau et de serveur. L’annonce a ébouriffé certaines plumes au sein de la communauté Linux, qui a vu peu de preuves de la prise en charge de Snaps par une autre distro Linux.
Snap est la tentative de Canonical d’affiner le mécanisme de packaging et de livraison d’applications sur la plateforme Linux. L’origine de Snap trouve ses racines dans Click, une solution que Canonical a créée pour sa plateforme mobile en 2014, afin de gérer la complexité de la livraison d’apps aux utilisateurs de téléphones et de tablettes Ubuntu, un écosystème bien différent des ordinateurs de bureau et des serveurs. En outre, le mobile avait également besoin de confiner les apps et de les mettre en sandbox, afin qu’elles ne compromettent pas l’ensemble de la plateforme.
Click a permis aux développeurs de regrouper toutes les dépendances dans un seul paquet d’apps, afin que les utilisateurs et les développeurs n’aient pas à s’inquiéter des conflits entre les systèmes et les bibliothèques d’apps. Il a permis aux développeurs d’utiliser les dernières bibliothèques dans leurs apps, pour offrir de nouvelles fonctionnalités car elles étaient découplées des bibliothèques installées sur le système.
Beyond Mobile to Servers and IoT
Click a évolué en Snap et Canonical a étendu son utilisation potentielle aux espaces serveur, cloud, Internet des objets (IoT) et bureau. Avec la sortie d’Ubuntu 16.04 en avril, Canonical a officiellement apporté Snap au bureau Ubuntu.
Canonical développe également Snappy Ubuntu Core, un minuscule système d’exploitation basé sur Linux pour les déploiements de conteneurs de cloud à grande échelle, les appareils IoT et bien plus encore, et tout ce qui nécessite des mises à jour transitoires et une empreinte minuscule. Snappy Ubuntu Core fonctionne plus ou moins comme Chrome OS et CoreOS de Google, où il propose des mises à jour transitoires basées sur des images pour le système et les applications, qui peuvent être annulées. Simultanément, il offre le confinement qui est connu dans le monde des conteneurs.
Snap est l’âme de cette technologie.
Le désordre Linux de la livraison d’applications
Le modèle de livraison d’applications existant sur Linux a de nombreux défauts. Le monde Linux est principalement divisé en deux camps de packaging d’apps : rpm et deb. De plus, il existe différentes versions des mêmes distributions qui utilisent différentes bibliothèques, il devient donc assez difficile pour les développeurs d’apps d’empaqueter des apps pour Linux.
En conséquence, les développeurs d’apps ne peuvent pas profiter des dernières bibliothèques et offrir plus de fonctionnalités à leurs utilisateurs si la distribution utilise encore des bibliothèques plus anciennes.
Dans la plupart des cas, les développeurs d’apps open source n’empaquettent pas leurs apps pour les distributions. Les apps populaires ou établies depuis longtemps sont généralement empaquetées par les développeurs de la distro. Les plus récentes ou moins populaires sont soit empaquetées par l’amont pour chaque distro qu’ils veulent supporter, soit pas du tout offertes comme paquet de distro. Lorsqu’une nouvelle version d’une application est publiée, ces développeurs testent l’application et la rendent disponible pour la distro. Comme vous pouvez le voir, au lieu que le développeur d’apps n’écrive qu’une seule app pour toute la plateforme, qui dans ce cas est Linux, il y a plusieurs personnes qui apportent cette app aux utilisateurs.
Cela ajoute plus de complexité.
Il y a des cas où Windows et MacOS obtiennent les dernières versions immédiatement, car les apps sont empaquetées par les développeurs primaires, alors que les distros Linux peuvent prendre un certain temps. Ce n’est pas tout ; certaines distros les obtiennent rapidement, et d’autres doivent attendre des semaines ou des mois.
Dans le cas d’apps commerciales comme Skype, Dropbox, Chrome, c’est au développeur primaire qu’il incombe de packager les apps et de proposer des binaires pour différentes distributions. De nombreuses apps ne fonctionnent pas sur les anciennes versions, pourtant prises en charge, de nombreuses distributions.
En un mot, c’est le bazar.
Même le créateur de Linux, Linus Torvalds, n’est pas satisfait du modèle de livraison d’apps existant sur Linux. Il ne propose pas de binaires de ses apps pour la plateforme Linux en citant ce désordre. Dirk Hohndel, le mainteneur de Subsurface (un projet lancé par Linus), explique : » La situation actuelle avec des dizaines de distributions, chacune avec des règles différentes, chacune avec des versions différentes de différentes bibliothèques, certaines avec certaines bibliothèques manquantes, chacune avec des outils d’empaquetage et des formats d’empaquetage différents… cela dit en gros aux développeurs d’apps ‘partez, concentrez-vous sur les plateformes qui se soucient des applications’.
« Le packaging des applications est extrêmement important, mais la provenance et la maintenance de toutes les pièces impliquées le sont aussi », a convenu Gunnar Hellekson, directeur de la gestion des produits pour Red Hat Enterprise Linux.
Snap a été conçu pour mettre un peu d’ordre dans cet état de fait. Mais savoir s’il sera adopté est une toute autre question.
Hellekson a fait valoir que les outils comme Snap ne « résolvent pas magiquement les problèmes d’interopérabilité entre les distributions Linux, et transfèrent en fait plus de responsabilités pour l’entretien et la sécurité aux vendeurs d’applications ». De cette façon, ils pourraient rendre le développement sur Linux encore plus difficile malgré les nombreux avantages pour les utilisateurs. »
« Les avantages de Snap sont directement liés à ses inconvénients… en substance, Snap est l’équivalent d’une liaison statique – il est pratique d’une part, crée une duplication et des défis en matière de sécurité (et de correctifs de sécurité) d’autre part », a déclaré Gerald Pfeifer, vice-président des produits et des programmes technologiques de SUSE.
Cependant, tout le monde n’est pas du même avis. Brandon Philips, cofondateur et directeur de la technologie de CoreOS, nous a dit que les conteneurs sont l’avenir des applications sur Linux. Mais les conteneurs Docker ne peuvent pas être utilisés partout. Ils ont leurs limites. Ce dont nous avons besoin, c’est d’une solution de type conteneur, quelque chose comme Snap.
Lors d’une autre interview, le principal développeur du noyau Linux Greg Kroah-Hartman nous a dit qu’Android faisait des conteneurs « pour vos applications depuis huit ou neuf ans maintenant. Chaque application fonctionne dans son propre espace de noms. Elle ne peut pas voir en dehors de celui-ci. C’est ainsi qu’il faut procéder. C’est l’avenir de Linux et de la façon dont les systèmes fonctionnent ». Il a dit que Snap est le même concept, la même idée.
Snap Goes Cross Platform
Le succès de Snap dépend beaucoup de son adoption par la plus grande communauté open source. À quoi sert un format d’application si personne ne l’utilise ? En tant que technologie réservée à Ubuntu, qui pourrait même ne pas être officiellement soutenue par ses dérivés comme Linux Mint, KDE neon ou elementary OS, Snap pourrait faire face à une carrière pas très réussie.
Lorsque Canonical a annoncé Snap, il a affirmé lors d’une conférence de presse qu’il travaillait avec diverses distributions pour ajouter le support de Snap.
Canonical a déclaré que les Snaps sont nativement disponibles pour Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity et Xubuntu. Canonical travaille également à la validation de Snaps sur CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt et Red Hat Enterprise Linux.
Canonical et SUSE ne sont actuellement pas engagés dans le développement autour de la collaboration sur Snaps, et en fait, il semble que cela ne soit pas le résultat d’une conception et d’un développement ouvert de la communauté « , Gerald Pfeifer, SUSE.
L’annonce de Canonical qu’ils ont travaillé avec d’autres distributions a attiré quelques critiques de certains membres de la communauté open source. Les développeurs de Fedora n’ont pas apprécié cette annonce et ont critiqué Canonical en déclarant qu’il n’y avait aucune collaboration quelle qu’elle soit entre les deux projets.
Lorsque nous avons fait un suivi avec le fondateur de Canonical, Mark Shuttleworth, pour le questionner sur ces accusations, il a répondu : » Nous avons fait un briefing avec l’équipe de bureau de Red Hat et nous sommes toujours ouverts à travailler avec toutes les distributions Linux pour activer Snaps. »
Ceci s’est avéré être une nouvelle pour Red Hat, cependant, qui abrite la distribution Fedora.
« Alors que nous travaillons avec Canonical dans plusieurs communautés, nous avons été aussi surpris que tout le monde quand ils ont annoncé notre implication sur cette initiative particulière. Nous sommes ouverts à plus de discussions à ce sujet, et à voir comment la communauté Linux dans son ensemble veut travailler ensemble », a déclaré Hellekson.
Les responsables de SUSE ont également minimisé toute collaboration. « Canonical et SUSE ne sont actuellement pas engagés dans le développement autour de la collaboration sur Snaps, et en fait, il semble que ce n’était pas le résultat de la conception et du développement de la communauté ouverte », a déclaré Pfeifer.
Ce qui semble s’être passé, c’est que Canonical a travaillé avec certains développeurs, peut-être seulement une poignée, d’autres projets et ils ont aidé à empaqueter Snaps pour d’autres distributions.
Canonical n’est pas parfait
Une partie du repoussoir que Canonical a pu recevoir peut être un sous-produit de la façon dont il fait des affaires.
Par exemple, d’autres sociétés Linux, comme Red Hat et SUSE, maintiennent une séparation très claire des pouvoirs quand il s’agit de Fedora et d’openSUSE. Fedora et openSUSE sont des projets assez indépendants, dirigés par la communauté, où les décisions sont prises par les membres de la communauté et non par les entreprises commanditaires.
En revanche, Ubuntu est un produit Canonical qui se trouve également être un projet communautaire. En raison de cela, contrairement à openSUSE et Fedora, Canonical a un contrôle direct sur Ubuntu. Nous avons déjà appris dans le cas de ownCloud ; il est vraiment difficile de maintenir un équilibre entre les besoins de la communauté et de l’entreprise ; cela se termine souvent par un désastre comme ownCloud.
La question se pose de savoir comment on » travaille » avec un projet ?
De plus, beaucoup pensent qu’il y a un manque de transparence avec Ubuntu. À certains moments, de nombreux contributeurs importants d’Ubuntu ont exprimé leur frustration car Canonical gardait les annonces majeures autour d’Ubuntu sous le manteau, cachées même aux membres principaux. Les membres d’Ubuntu n’avaient aucune idée d’Ubuntu pour Windows ou du projet malheureux Edge.
« Nous ne retenons pas les choses », a répondu le PDG de Red Hat, Jim Whitehurst, à une question sur l’approche de cette entreprise en matière d’open source. « Lorsque nous construisons des choses, nous ne les cachons pas aux gens pour faire une grande révélation et dire ‘voici le code’. Nous ne le faisons pas. Nous travaillons en communauté dès le premier jour, tout le temps. Je pense vraiment que nous essayons d’être de très bons participants, et je pense que cela se voit. »
En plus de ces différences, Canonical est également connu pour faire quelques faux pas lorsqu’il s’agit de publier des informations. Cela semble certainement être le cas pour l’annonce de la prise en charge de Snap par plusieurs distributions ; la formulation qui a irrité les développeurs de Fedora était « Développeurs de plusieurs distributions Linux. » Pour être clair, Canonical n’a jamais déclaré explicitement dans son communiqué de presse qu’il travaillait avec Fedora. Et d’après les informations que nous avons recueillies, il n’y a pas eu d’engagement » officiel » avec les distros Linux telles que Fedora, Red Hat, SUSE ou autres.
Cela dit, la question se pose de savoir comment on » travaille » avec un projet ? Si un développeur travaillant sur une application collabore avec un développeur Ubuntu, un développeur Fedora et un développeur openSUSE pour apporter cette application à ces plateformes, serait-il faux de dire que le développeur a travaillé avec plusieurs distributions pour leur apporter l’application ? Ou bien le développeur doit-il s’engager officiellement avec les chefs de projet de ces distributions pour pouvoir faire une telle déclaration ? C’est une communauté distribuée et open source, après tout.
Whither Snap?
La plus grande question est de savoir si Snap sera officiellement adopté par d’autres distros. C’est là que les choses se compliquent un peu. Cela devient une question technologique et politique.
Tout d’abord, Snap n’est pas la seule solution qui existe. Il y a beaucoup de projets qui ont essayé d’offrir des écosystèmes de packaging agnostiques aux distros pour les écosystèmes Linux. Mais il peut être difficile de trouver un consensus au sein du monde des distros Linux. Il y a AppImage et Flatpak, qui offrent des alternatives appropriées à Snap ; ces projets existent depuis bien plus longtemps que Snap.
Alors pourquoi Canonical n’a pas adopté ces solutions au lieu de lancer Click ou Snap ?
« Nous l’avons examiné, et nous avons constaté qu’AppImage fonctionne parfaitement pour les applications de bureau ‘leaf-node' », a déclaré Shuttleworth. Une application leaf-node est une application qui n’a pas besoin de s’intégrer à une autre application. Snap a été conçu plutôt pour regrouper des applications avec des dépendances et des applications connexes. « Snaps a une gamme de capacités pour décrire ces connexions – interfaces, prises et fentes, ainsi que des fichiers partagés et ainsi de suite. »
En plus de cela, Shuttleworth nous a dit que Snap a été conçu pour des niveaux de sécurité plus élevés par rapport à AppImage, en partie parce que l’équipe travaillant sur le téléphone mobile était axée sur la sécurité et l’efficacité, et en partie parce que Snap utilise des capacités de noyau plus récentes.
Flatpak a soi-disant été victime de la rivalité entre Canonical et Red Hat alors qu’il était développé par des personnes de Fedora. Lorsque j’ai demandé, Shuttleworth l’a rejeté comme un projet développé par un seul développeur.
Cela explique pourquoi Canonical est allé de l’avant avec Snap.
Maintenant, est-ce que d’autres distros vont l’adopter ? Les développeurs de Fedora ont déjà déclaré qu’ils n’utiliseront pas Snap. Un développeur Fedora a écrit sur la liste de diffusion, « Nous, bien sûr, n’avons aucun plan pour adopter Snappy dans Fedora, et en fait, plusieurs développeurs Fedora travaillent sur une solution concurrente, Flatpak. »
Red Hat a précédemment adopté un projet Canonical pour l’initialisation du système appelé Upstart. Hellekson a déclaré : » Ce sont des jours très précoces pour tous ces efforts d’empaquetage, et nous avons hâte de travailler avec toutes les communautés connexes pour rendre la vie aussi facile que possible pour les utilisateurs de Linux. «
Au delà de la rivalité entre Red Hat et Canonical, il y a certains problèmes techniques qui peuvent décourager d’autres projets de collaborer sur Snap. L’une de ces raisons est que les développeurs doivent signer un CLA (Contributor License Agreement) s’ils contribuent au projet Snap. Michael Hall, un développeur Canonical, a déclaré qu’une « CLA est nécessaire lorsqu’un développeur veut contribuer au projet Snap lui-même. Il n’y a pas de CLA nécessaire pour créer ou distribuer des Snaps d’applications. »
Les CLA permettent à Canonical de modifier la licence du projet. C’est bénéfique pour Canonical, car ils peuvent redonner une licence à un projet, lui permettant d’être utilisé avec des licences non libres ou incompatibles. Les développeurs n’aiment généralement pas les CLA.
Frank Karlitschek, de Nextcloud, nous a dit qu’il mettait fin aux CLA de Nextcloud, car il estime que les CLA n’ont pas une très bonne réputation au sein de la communauté open source.
Lorsque nous avons demandé à Red Hat si les CLA allaient freiner la collaboration autour de Snap, Hellekson a répondu : « Les accords de licence de contributeur rendent effectivement difficile notre participation. Nous pensons que les licences open source directes constituent une meilleure approche, plus inclusive. »
La réponse de SUSE était à peu près la même. Pfeifer a déclaré : « Les ingénieurs et le personnel de SUSE continuent de contribuer à une pléthore de projets open source, à la fois sur le temps de l’entreprise et le nôtre, et lorsque cela est nécessaire, nous avons signé des CLA. Cependant, où et quand nous lançons ou influençons des projets, nous essayons de rester à l’écart des CLA. Nous n’aimons généralement pas les CLA qui attribuent un copyright permettant aux organisations de re-licencier le code open source en utilisant une licence non-open source. »
Lorsque nous avons demandé à Shuttleworth s’il envisagerait de laisser tomber les CLA de Snap pour obtenir un soutien plus large de la part des autres distros, il a commencé par expliquer pourquoi les CLA sont bonnes, mais il a également dit que « si cela faisait une différence, alors oui, nous trouverions un moyen de les laisser tomber. »
And Then There was One?
Avec le temps, la maturité, la popularité et la supériorité technique de l’un sur l’autre peuvent nous laisser avec une seule solution. Nous avons déjà vu cela avec Upstart et systemd, où systemd a émergé comme une technologie supérieure et est devenu le défaut sur les trois principales distros Linux : Ubuntu, RHEL et SUSE.
Dans tous les cas, les deux technologies sont à des stades très précoces de développement, et il est difficile de dire quel projet réussira. Cependant, il est assez clair que dans le monde centré sur les conteneurs, Linux a besoin d’un nouveau mécanisme de livraison d’applications.
De nombreuses entreprises et communautés ont exprimé leur soutien à des solutions comme Snap. Samsung et Dell ont rejoint Canonical lors de la conférence de presse et ont déclaré la nécessité d’une telle solution. Du côté du bureau, des projets comme LibreOffice et Firefox ont déjà exprimé leur soutien à Snap.
Le temps nous dira si Snap sera adopté en dehors d’Ubuntu ou non. Quel que soit l’avenir de Snap, nous devrions donner à Canonical le crédit nécessaire pour avoir poussé l’enveloppe, forçant le reste de la communauté Linux à se concentrer enfin sur la résolution d’un problème avec lequel nous étions devenus si confortables ou, peut-être, n’avions jamais eu la motivation de le résoudre.
CoreOS et Red Hat sont des sponsors de The New Stack.