Mon avis sur les SNAPS de Canonical
Bonjour à tous,
je n'écris pas souvent. Cependant, j'aimerais de manière écrite faire un récap de ma pensée sur les SNAP de Canonical.
je vous préviens, ça va être long, mais je vous fais une analyse détaillée de ma pensée !
Je n'aborderai pas de comparatifs poussés avec Flatpak et Appimage, mais uniquement les SNAPS par rapport aux Deb (ici je parlerai d'Ubuntu, seule distribution où j'ai pu tester les SNAPS de manière autonome).
Je fais juste un petit rappel sur les formats dits universels qui existent actuellement :
Snap : l’application est en mode bac à sable (isolée du kernel) via AppArmor. Utilisable en environnement serveur et internet des objets. Le logiciel ne peut utiliser que les bibliothèques incluses dans son package.
Flatpak : l’application est en mode bac à sable. Il utilise des éléments d’une session graphique pour fonctionner (donc pas sur un serveur). Les Flatpaks peuvent tous deux utiliser des bibliothèques incluses dans le package et des bibliothèques partagées provenant d’un autre Flatpak.
Appimage : Les programmes AppImage ne sont pas en mode bac à sable et ne nécessitent pas de droits root pour s'exécuter. Appimage offre donc moins de sécurité. Le logiciel ne peut utiliser que les bibliothèques incluses dans son package.
Le site https://snapcraft.io/store centralise les SNAPS.
D'abord, côté poids.
Je vais simplifier l'exemple :
Avec les DEB, on a par exemple Firefox = 50Mo, Thunderbird = 50Mo, les bibliothèques communes aux deux (GTK, etc etc) 100Mo.
Quand Firefox dispose d'un fix de sécurité, une nouvelle version de Firefox est publiée, on télécharge 50Mo.
Avec les SNAPS, vous l'avez compris, dans le SNAP, on a l'application et les libs. Donc Firefox = 150Mo, Thunderbird 150Mo.
Quand Firefox dispose d'un fix de sécurité, une nouvelle version de Firefox est publiée, on télécharge 150Mo. (3 fois plus).
Pour les petites connexions ADSL, ça peut être plus long, évidemment.
Sur la place sur le disque :
Je reprends mon exemple Firefox, Thunderbird, Libs du dessus.
DEB = 50+50+100 = 200
SNAP = 150+150 = 300
Ça prend plus de place.
Après, les HDD de 1To c'est monnaie courante, et les SSD 500Go ne sont plus très cher (ça dépend vos ressources mais SSD Crucial BX500 480 Go = 84€, compte 56€ pour le 240Go). Ça peut juste être problématique sur des mini PC avec de la mémoire eMMC).
Avec 45 applications installées (voir vidéo en dessous) on a pour les SNAPS 9.5Go pris sur le disque. Avec les DEB, 8.3 Go. Cela ne représente que (ou cela représente quand même !!!!) 1.2Go de différence.
Concernant la mémoire :
Toujours sur le comparatif avec les 45 SNAPS / 45 DEBS :
Sur la machine avec les 45 SNAPS on a 880Mo de RAM.
Sur la machine avec les 45 DEBS on a 720Mo de RAM.
Il semble donc que les SNAPS soient impactant sur la RAM (pas de beaucoup). Cela peut se traduire notamment par le démon snapd démarré en plus.
Concluez ce que vous voulez, je n'ai pas trop d'avis sur les 150Mo. Surtout qu'après avoir lancé sur les 2 machines les mêmes applications, puis refermées, on consomme plus des 2 côtés, mais toujours avec cet écart de 150Mo. (avec des PC actuellement de 4Go au moins, ça va)
Concernant les /dev/loop :
Chaque SNAP installé vient «pourrir» la commande df d'un média /dev/loop qui pointe sur /snap/nomdusnap/numero.
C'est déroutant, car cela pollue l'affichage d'une commande système traditionnelle.
Après, cela semble «logique» puisque les SNAPS sont dans un système de fichiers en lecture seule (comme quand vous montez avec «mount» une ISO dans un dossier de votre arborescence locale.
Concernant le temps de démarrage :
Par rapport aux DEB, tous les logiciels sont 1 à 5 secondes plus lents à lancer (effet Sandbox, effet conteneur, effet AppArmor?). A l'exception d'Audacity sur les logiciels testés.
Ce n'est pas un drame mais la lenteur peut paraître déroutante quand on a l'habitude du clic et paf c'est lancé.
Concernant les thèmes :
Même si on entend que le thème système est mieux géré avec Flatpak, sur Ubuntu et SNAP, c'est assez différent :
J'ai activé le thème Dark sur la Ubuntu (vous verrez dans la vidéo), et lancé divers logiciels. les résultats sont différents :
- Firefox, en GTK3 => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
- VLC, en Qt5 => Ne prend pas le thème de Ubuntu en SNAP / Ne prend pas le thème de Ubuntu en DEB
- SweetHome3D, en Java => Prend le thème traditionnel Java (bleuté dégradé) en SNAP / Essaie d'avoir le thème Ubuntu en DEB mais souffre de bugs d'affichages (inutilisable)
- KdenLive, en Qt5 => Prend le thème natif Breeze de KDE en SNAP / Prend le thème moche Qt d'Ubuntu en DEB (Breeze semble pas installé par dépendances).
- Filezilla, en wxwidgets => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
- LibreOffice, en GTK3 => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
On constate donc qu'avec les SNAPS, les apps GTK3 prennent le thème du système. Avec un thème inexistant (Breeze, Java), les applications ont un thème et une apparence fonctionnelle. Avantage au SNAP pour ce coup. Certes, ce n'est pas cohérent, mais c'est fonctionnel dans tous les cas !
Là où KdenLive est un peu dégueulasse en DEB si on ne va pas installer le thème breeze en plus à la main, et où SweetHome3D est inutilisable...
Côté traduction :
Et bien je reprends les mêmes applications que le test du thème, mais je vais me focaliser sur les traductions !
- Firefox => Français en SNAP / Français en DEB
- VLC=> Français en SNAP / Français en DEB
- SweetHome3D => Français en SNAP / Français en DEB
- KdenLive => Français en SNAP / Français en DEB
- Filezilla => Français en SNAP / Français en DEB
- LibreOffice => Français en SNAP / Français en DEB
J'ai testé en plus (avant le changement de thème) du précédent paragraphe :
- Clémentine : Français en SNAP / Français en DEB
- Audacity : Anglais en SNAP / Français en DEB
Sur les applications testées, il y a juste un loupé sur Audacity niveau traduction, du coup, le SNAP détecte bien la langue du système de manière globale.
Concernant la "sandbox" et les permissions :
J'ai testé sur Chromium (à 18:25 de la vidéo) le réglage des permissions sur un SNAP.
J'ai effectué les choses en graphique (sans doute possible en ligne de commande, mais je ne suis pas un expert SNAP).
Pour Chromium, il est possible de régler les permissions d'accès au micro, au son, à la camera, à l'impression, au dossier utilisateur et bien plus (liste affichée à 19:08).
J'ai testé, ça fonctionne bien.
Personnellement, je n'en vois pas l'intérêt sur un PC qu'on utilise tous les jours mais la fonction est là et semble répondre aux attentes. Je pense que l'utilité est plus là pour l'IoT ou pourquoi pas les serveurs. (Un peu similaire aux booléens SELinux ?)
Et enfin Snap sur serveur
Comparé aux Flatpaks, SNAP permet d'installer des applis non graphiques. J'ai testé avec postgresql10 sur Ubuntu 20.04 LTS, ça marche.
Pour le coup, comme indiqué dans la vidéo, je ne vois pas l'intérêt du SNAP ici pour les permissions, mais pour autre chose : La possibilité d'installer une version spécifique d'un composant serveur (base de données, etc etc). C'est une manière de reproduire ce que Fedora propose (Et RHEL8 / CentOS8) avec les modules de dnf. Installer la version de son choix d'un moteur de base de données.
Avantage du snap sur une Ubuntu graphique alors ?
Je pense que le SNAP peut être intéressant dans certains cas.
Ubuntu LTS, comme son nom l'indique, est Long Term Support. Donc prochaine LTS 2022.
Si on fait une comparaison avec Ubuntu 18.04 qui date d'il y a 2 ans :
- Ubuntu 18.04 à la sortie : LibreOffice 6.0.3
- Ubuntu 18.04.4 aujourd'hui : LibreOffice 6.0.7
- Ubuntu 20.04 aujourd’hui : LibreOffice 6.4.2
Cependant :
- Ubuntu 18.04 à la sortie : Firefox 59
- Ubuntu 18.04.4 aujourd'hui : Firefox 75
- Ubuntu 20.04 aujourd’hui : Firefox 75
On conclus que :
- Sur une LTS Ubuntu, les logiciels stratégiques exposés (Firefox, OpenSSH, Kernel) disposent soit de nouvelles versions, soit de patchs de sécurité rétroportés.
- Sur une LTS Ubuntu, les logiciels d'utilisation ne sont pas mis à jour et ne disposent donc pas de nouvelles fonctionnalités (LibreOffice reste en branche 6.0)
Le SNAP pour le coup, va permettre de garder une base système "deb" stable, et de disposer d'applications d'utilisation plus récentes pour bénéficier de nouvelles fonctionalités.
Ça va éviter d'ajouter un "PPA" (dépôt additionnel) qui risque de poser des problèmes lors de mises à jour/mises à niveau, car les PPA contiennent des DEB, et utilisent les dépendances du système. Là en cas de mise à jour, le SNAP se cassera tout seul au pire, et n'aura pas d'impact sur la stabilité du système.
Si je reviens vite fait sur une éventuelle Ubuntu Server (y a des gens qui utilisent Ubuntu Server ?) le problème de logiciel récent n'est pas intéressant car :
- On ne va s'intéresser qu'aux fix de sécurité
- On va préférer garder une même version d'un moteur de base de données, d'un langage de programmation, afin de ne pas requalifier l'applicatif à cause d'une mise à jour.
Et en conclusion ?
En conclusion, les SNAPS ne sont pas une mauvaise chose.
Ce que je reproche, c'est l'imposition du format aux traditionnels DEB. (Ou pire Chromium Browser qui est un deb vide virtuel qui force l'install du snap)
Il aurait été préférable de garder le DEB et en cas d'appli non dispo ou d'une volonté de l'utilisateur à avoir une version plus récente d'un logiciel, d'aller faire la démarche manuellement.
Sur le serveur, je n'utilise que CentOS pour le travail, le SNAP permet en gros (à voir sur l'utilisation) de reproduire les modules de RHEL8/CentOS8 et les SCL de RHEL7/RHEL6. Cela peut être utile, à voir.
Concernant la mémoire et le disque, mon PC dispose de 16Go de RAM et 512Go SSD, et j'ai la fibre, donc au pire je m'en fiche mais.... Ceux qui ont de l'ADSL c'est plus long. Un PC standard aujourd'hui, c'est 4Go mini, 256SSD ou un HDD de 500Go donc ça passe. Sur des configs plus basses, les gens n'iront pas vers Ubuntu mais vers des Debian Xfce, qui seront plus légères et qui n'ont pas de SNAP (A voir avec Xubuntu).
Concernant pour terminer le lancement des SNAPS, c'est un peu plus long que les DEB (de quelques secondes), sauf pour Audacity. mais comme disait un certain Sipo sur Twitter, ça ne fait pas refroidir le café ! Mais personnellement, j'aime bien que le système soit réactif, je clic, ça s'ouvre.
Globalement, ça marche et bien.
Et vous, que pensez-vous des SNAPS ?
La vidéo du comparatif DEB/SNAPS (aller à 13 minutes) :
je n'écris pas souvent. Cependant, j'aimerais de manière écrite faire un récap de ma pensée sur les SNAP de Canonical.
je vous préviens, ça va être long, mais je vous fais une analyse détaillée de ma pensée !
Je n'aborderai pas de comparatifs poussés avec Flatpak et Appimage, mais uniquement les SNAPS par rapport aux Deb (ici je parlerai d'Ubuntu, seule distribution où j'ai pu tester les SNAPS de manière autonome).
Je fais juste un petit rappel sur les formats dits universels qui existent actuellement :
Snap : l’application est en mode bac à sable (isolée du kernel) via AppArmor. Utilisable en environnement serveur et internet des objets. Le logiciel ne peut utiliser que les bibliothèques incluses dans son package.
Flatpak : l’application est en mode bac à sable. Il utilise des éléments d’une session graphique pour fonctionner (donc pas sur un serveur). Les Flatpaks peuvent tous deux utiliser des bibliothèques incluses dans le package et des bibliothèques partagées provenant d’un autre Flatpak.
Appimage : Les programmes AppImage ne sont pas en mode bac à sable et ne nécessitent pas de droits root pour s'exécuter. Appimage offre donc moins de sécurité. Le logiciel ne peut utiliser que les bibliothèques incluses dans son package.
Le site https://snapcraft.io/store centralise les SNAPS.
D'abord, côté poids.
Je vais simplifier l'exemple :
Avec les DEB, on a par exemple Firefox = 50Mo, Thunderbird = 50Mo, les bibliothèques communes aux deux (GTK, etc etc) 100Mo.
Quand Firefox dispose d'un fix de sécurité, une nouvelle version de Firefox est publiée, on télécharge 50Mo.
Avec les SNAPS, vous l'avez compris, dans le SNAP, on a l'application et les libs. Donc Firefox = 150Mo, Thunderbird 150Mo.
Quand Firefox dispose d'un fix de sécurité, une nouvelle version de Firefox est publiée, on télécharge 150Mo. (3 fois plus).
Pour les petites connexions ADSL, ça peut être plus long, évidemment.
Sur la place sur le disque :
Je reprends mon exemple Firefox, Thunderbird, Libs du dessus.
DEB = 50+50+100 = 200
SNAP = 150+150 = 300
Ça prend plus de place.
Après, les HDD de 1To c'est monnaie courante, et les SSD 500Go ne sont plus très cher (ça dépend vos ressources mais SSD Crucial BX500 480 Go = 84€, compte 56€ pour le 240Go). Ça peut juste être problématique sur des mini PC avec de la mémoire eMMC).
Avec 45 applications installées (voir vidéo en dessous) on a pour les SNAPS 9.5Go pris sur le disque. Avec les DEB, 8.3 Go. Cela ne représente que (ou cela représente quand même !!!!) 1.2Go de différence.
Concernant la mémoire :
Toujours sur le comparatif avec les 45 SNAPS / 45 DEBS :
Sur la machine avec les 45 SNAPS on a 880Mo de RAM.
Sur la machine avec les 45 DEBS on a 720Mo de RAM.
Il semble donc que les SNAPS soient impactant sur la RAM (pas de beaucoup). Cela peut se traduire notamment par le démon snapd démarré en plus.
Concluez ce que vous voulez, je n'ai pas trop d'avis sur les 150Mo. Surtout qu'après avoir lancé sur les 2 machines les mêmes applications, puis refermées, on consomme plus des 2 côtés, mais toujours avec cet écart de 150Mo. (avec des PC actuellement de 4Go au moins, ça va)
Concernant les /dev/loop :
Chaque SNAP installé vient «pourrir» la commande df d'un média /dev/loop qui pointe sur /snap/nomdusnap/numero.
C'est déroutant, car cela pollue l'affichage d'une commande système traditionnelle.
Après, cela semble «logique» puisque les SNAPS sont dans un système de fichiers en lecture seule (comme quand vous montez avec «mount» une ISO dans un dossier de votre arborescence locale.
Concernant le temps de démarrage :
Par rapport aux DEB, tous les logiciels sont 1 à 5 secondes plus lents à lancer (effet Sandbox, effet conteneur, effet AppArmor?). A l'exception d'Audacity sur les logiciels testés.
Ce n'est pas un drame mais la lenteur peut paraître déroutante quand on a l'habitude du clic et paf c'est lancé.
Concernant les thèmes :
Même si on entend que le thème système est mieux géré avec Flatpak, sur Ubuntu et SNAP, c'est assez différent :
J'ai activé le thème Dark sur la Ubuntu (vous verrez dans la vidéo), et lancé divers logiciels. les résultats sont différents :
- Firefox, en GTK3 => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
- VLC, en Qt5 => Ne prend pas le thème de Ubuntu en SNAP / Ne prend pas le thème de Ubuntu en DEB
- SweetHome3D, en Java => Prend le thème traditionnel Java (bleuté dégradé) en SNAP / Essaie d'avoir le thème Ubuntu en DEB mais souffre de bugs d'affichages (inutilisable)
- KdenLive, en Qt5 => Prend le thème natif Breeze de KDE en SNAP / Prend le thème moche Qt d'Ubuntu en DEB (Breeze semble pas installé par dépendances).
- Filezilla, en wxwidgets => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
- LibreOffice, en GTK3 => Prend le thème de Ubuntu en SNAP / Prend le thème Ubuntu en DEB
On constate donc qu'avec les SNAPS, les apps GTK3 prennent le thème du système. Avec un thème inexistant (Breeze, Java), les applications ont un thème et une apparence fonctionnelle. Avantage au SNAP pour ce coup. Certes, ce n'est pas cohérent, mais c'est fonctionnel dans tous les cas !
Là où KdenLive est un peu dégueulasse en DEB si on ne va pas installer le thème breeze en plus à la main, et où SweetHome3D est inutilisable...
Côté traduction :
Et bien je reprends les mêmes applications que le test du thème, mais je vais me focaliser sur les traductions !
- Firefox => Français en SNAP / Français en DEB
- VLC=> Français en SNAP / Français en DEB
- SweetHome3D => Français en SNAP / Français en DEB
- KdenLive => Français en SNAP / Français en DEB
- Filezilla => Français en SNAP / Français en DEB
- LibreOffice => Français en SNAP / Français en DEB
J'ai testé en plus (avant le changement de thème) du précédent paragraphe :
- Clémentine : Français en SNAP / Français en DEB
- Audacity : Anglais en SNAP / Français en DEB
Sur les applications testées, il y a juste un loupé sur Audacity niveau traduction, du coup, le SNAP détecte bien la langue du système de manière globale.
Concernant la "sandbox" et les permissions :
J'ai testé sur Chromium (à 18:25 de la vidéo) le réglage des permissions sur un SNAP.
J'ai effectué les choses en graphique (sans doute possible en ligne de commande, mais je ne suis pas un expert SNAP).
Pour Chromium, il est possible de régler les permissions d'accès au micro, au son, à la camera, à l'impression, au dossier utilisateur et bien plus (liste affichée à 19:08).
J'ai testé, ça fonctionne bien.
Personnellement, je n'en vois pas l'intérêt sur un PC qu'on utilise tous les jours mais la fonction est là et semble répondre aux attentes. Je pense que l'utilité est plus là pour l'IoT ou pourquoi pas les serveurs. (Un peu similaire aux booléens SELinux ?)
Et enfin Snap sur serveur
Comparé aux Flatpaks, SNAP permet d'installer des applis non graphiques. J'ai testé avec postgresql10 sur Ubuntu 20.04 LTS, ça marche.
Pour le coup, comme indiqué dans la vidéo, je ne vois pas l'intérêt du SNAP ici pour les permissions, mais pour autre chose : La possibilité d'installer une version spécifique d'un composant serveur (base de données, etc etc). C'est une manière de reproduire ce que Fedora propose (Et RHEL8 / CentOS8) avec les modules de dnf. Installer la version de son choix d'un moteur de base de données.
Avantage du snap sur une Ubuntu graphique alors ?
Je pense que le SNAP peut être intéressant dans certains cas.
Ubuntu LTS, comme son nom l'indique, est Long Term Support. Donc prochaine LTS 2022.
Si on fait une comparaison avec Ubuntu 18.04 qui date d'il y a 2 ans :
- Ubuntu 18.04 à la sortie : LibreOffice 6.0.3
- Ubuntu 18.04.4 aujourd'hui : LibreOffice 6.0.7
- Ubuntu 20.04 aujourd’hui : LibreOffice 6.4.2
Cependant :
- Ubuntu 18.04 à la sortie : Firefox 59
- Ubuntu 18.04.4 aujourd'hui : Firefox 75
- Ubuntu 20.04 aujourd’hui : Firefox 75
On conclus que :
- Sur une LTS Ubuntu, les logiciels stratégiques exposés (Firefox, OpenSSH, Kernel) disposent soit de nouvelles versions, soit de patchs de sécurité rétroportés.
- Sur une LTS Ubuntu, les logiciels d'utilisation ne sont pas mis à jour et ne disposent donc pas de nouvelles fonctionnalités (LibreOffice reste en branche 6.0)
Le SNAP pour le coup, va permettre de garder une base système "deb" stable, et de disposer d'applications d'utilisation plus récentes pour bénéficier de nouvelles fonctionalités.
Ça va éviter d'ajouter un "PPA" (dépôt additionnel) qui risque de poser des problèmes lors de mises à jour/mises à niveau, car les PPA contiennent des DEB, et utilisent les dépendances du système. Là en cas de mise à jour, le SNAP se cassera tout seul au pire, et n'aura pas d'impact sur la stabilité du système.
Si je reviens vite fait sur une éventuelle Ubuntu Server (y a des gens qui utilisent Ubuntu Server ?) le problème de logiciel récent n'est pas intéressant car :
- On ne va s'intéresser qu'aux fix de sécurité
- On va préférer garder une même version d'un moteur de base de données, d'un langage de programmation, afin de ne pas requalifier l'applicatif à cause d'une mise à jour.
Et en conclusion ?
En conclusion, les SNAPS ne sont pas une mauvaise chose.
Ce que je reproche, c'est l'imposition du format aux traditionnels DEB. (Ou pire Chromium Browser qui est un deb vide virtuel qui force l'install du snap)
Il aurait été préférable de garder le DEB et en cas d'appli non dispo ou d'une volonté de l'utilisateur à avoir une version plus récente d'un logiciel, d'aller faire la démarche manuellement.
Sur le serveur, je n'utilise que CentOS pour le travail, le SNAP permet en gros (à voir sur l'utilisation) de reproduire les modules de RHEL8/CentOS8 et les SCL de RHEL7/RHEL6. Cela peut être utile, à voir.
Concernant la mémoire et le disque, mon PC dispose de 16Go de RAM et 512Go SSD, et j'ai la fibre, donc au pire je m'en fiche mais.... Ceux qui ont de l'ADSL c'est plus long. Un PC standard aujourd'hui, c'est 4Go mini, 256SSD ou un HDD de 500Go donc ça passe. Sur des configs plus basses, les gens n'iront pas vers Ubuntu mais vers des Debian Xfce, qui seront plus légères et qui n'ont pas de SNAP (A voir avec Xubuntu).
Concernant pour terminer le lancement des SNAPS, c'est un peu plus long que les DEB (de quelques secondes), sauf pour Audacity. mais comme disait un certain Sipo sur Twitter, ça ne fait pas refroidir le café ! Mais personnellement, j'aime bien que le système soit réactif, je clic, ça s'ouvre.
Globalement, ça marche et bien.
Et vous, que pensez-vous des SNAPS ?
La vidéo du comparatif DEB/SNAPS (aller à 13 minutes) :
N'hésitez pas à sélectionner la qualité HD en 720p ou 1080p !
