La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 03 novembre 2018 à 22:46:14
-
Snap, Flatpak et AppImage : il y a concurrence pour le renouvellement de l'installation des applications sous Linux
L'objectif de Snap comme Flatpak est de fournir un environnement « bac à sable » (sandbox) sûr, isolé du reste du système, dans lequel les utilisateurs peuvent exécuter des applications non validées par les dépôts de la distribution (des versions de test, par exemple). Les applications utilisent des appels de fonctions spécifiques pour contrôler les périphériques matériels ou accéder aux fichiers de l'utilisateur, et demande à l'utilisateur sa permission avant de donner accès.
Les applications Snap et AppImage viennent avec TOUTES leurs "dépendances", "runtimes" et "bibliothèques" contenues dans le paquet, ce sont donc des applications assez lourdes, mais il est possible de faire fonctionner n'importe quel version à coté de n'importe quelle autre version et sur n'importe quel Linux.
Flatpak est un peu moins lourd que Snap, car il existe une collection de "runtimes" et de "bibliothèques" partagés entre plusieurs applications du système.
Snap et AppImage ont l'avantage sur Flatpak de pouvoir fonctionner sur un serveur (sans interface graphique) alors que Flatpak est dédié aux linux avec interface graphique.
Flatpak a l'avantage sur Snap d'être 100% open source, même si il est poussé par Red Hat et que le développeur de Flatpak est salarié de Red Hat.
Snap est créé par et sous licence Canonical qui gère le store.
AppImage est indépendant. Pas de store, pour corriger les bugs et éviter les failles de sécurité, il faudra aller chercher soi-même les nouvelles versions quand elles sortent.
Les principales différences des 3 format d’application qui veulent remplacer les .deb et les .rpm :
- Snap : l’application est sandboxée (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 sandboxée via BubbleWrap. S’appuie sur des éléments d’une session graphique pour fonctionner => inutilisable 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é. Utilisable en environnement serveur. Le logiciel ne peut utiliser que les bibliothèques incluses dans son package (comme snap). Molotov.tv est disponible sous Linux uniquement en AppImage.
Les 3 formats sont tous les 3 pris en charge par les principales distributions Linux, ce n'est donc pas un point qui va les différencier.
Canonical a publié une nouvelle infographie pour vanter son format '.snap' :
L'infographie de Canonical explique :
- Plus de 4100 snaps sont disponibles au téléchargement
- 41 distribution linux supporte les snap
(https://lafibre.info/testdebit/ubuntu/201810_snapcraft_Infographie.png)
-
Snap est très loin d'être parfait.
https://www.reddit.com/r/Ubuntu/comments/6icsmz/snap_is_currently_a_joke_and_could_actually_hurt/
-
L'article pointe des défaut de jeunesse.
-Login: Je ne comprends toujours pas pourquoi je dois avoir un compte pour installer les paquets instantanés.
Il n'est maintenant plus nécessaire d'avoir un compte pour installer des Snap gratuites
Il n’est pas non plus facile de savoir dans le centre logiciel si le package provient de snap ou du référentiel standard.
Aujourd'hui, c'est bien indiqué dans le centre logiciel : il y a une ligne "Source" qui indique "Boutique des snap" si c'esr un snap ou "ubuntu-cosmic-main" si c'est un paquet DEB.
Exemple avec Firefox au format DEB :
(https://lafibre.info/testdebit/ubuntu/201811_firefox_deb.png)
Firefox au format Snap : (je regrette au passage e fait que la description soit en Anglais)
(https://lafibre.info/testdebit/ubuntu/201811_firefox_snap.png)
(observez la taille de Firefox au format Snap, car toutes les dépendances sont embarquées)
Les problèmes indiqués (pas accès aux fichiers) sont aussi du passé : aujourd'hui de nombreuses application phares sont proposées par défaut en snap. Il reste possible de prendre la version qui n'est pas dans les snap via un apt install.
Personnellement je reproche d'autre choses :
- un temps de lancement plus long des SNAP par rapport à un paquet DEB. Certains comparatif disent qu'il n'existe plus, il faudrait que je teste de nouveau.
- impossibilité de bloquer les mises à jour automatiques (sauf si paquet installé manuellement, ce qui est compliqué, il faut récupérer un fichier .snap et un fichier .assert.
- pas de miroir local possible pour une entreprise (si les serveurs n'ont pas d’accès à Internet, il faut mettre un proxy)
- pas de source code repository (problème présent aussi bien pour Snap que Flatpak ou AppImage) : il n'est pas simple de vérifier que le binaire correspond aux source, alors que c'est possible pour les paquets .deb traditionnels.
C'est un prés les même défaut que ceux du store de Windows 10... (lui aussi demandait de se connecter à l'époque de Windows 8 pour télécharger une application gratuite)
Snap, Flatpak ou AppImage permettent d'améliorer la sécurité (exécution dans un bac a sable), demander de permissions pour les ressources utilisées (une application ne peut pas utiliser votre webcam sans votre accord), ils permettent à un éditeur d'adresser facilement toutes les distributions linux, cela permet d'avoir différentes version d'un même logiciel (pour Snap et AppImage) mais il y a des régressions que je trouve inacceptable et on s'éloigne un peu du modèle Debian ou tout binaire a son code source à coté. Est-ce nécessaire pour que Linux dépasse 2% des système exploitation PC de bureau ?
A noter que le sandboxing n'est pas obligatoire et Skype ne l'utilise pas :
(https://lafibre.info/testdebit/ubuntu/201811_skype_snap.png)
Mais d'autres logiciels propriétaire comme Spotify l'utilise :
(https://lafibre.info/testdebit/ubuntu/201811_spotify_snap.png)
-
Comparaison d'AppImage, Snap et Flatpak
(il met bien en valeur le format AppImage)
(https://lafibre.info/testdebit/ubuntu/201811_comparison_appimage_snap_flatpak.png)
Source : https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
-
(il met bien en valeur le format Appimage)
Oui, il "oublie" de mettre des croix rouges lorsqu'Appimage est moins bien (Update mechanism) ...
C'est normal que "Can run without sandboxing" soit un objectif ?
-
Un an après, je vois qu'il y a de plus en plus de paquets mis dans Snap, par Canonical.
Je pense qu'il veulent à terme supprimer les .deb (les paquets traditionnels) sur Ubuntu
Exemple LibreOffice est sur SnapCraft, mais ce n'est pas "The document fondation", l'éditeur de LibreOffice qui l'a mis, mais Canonical: https://snapcraft.io/libreoffice (sympa, permet d'avoir toujours la dernière version, la version 6.3)
Bien sur la version LibreOffice sur Snap co-existe avec la version .deb qui est toujours mis à jour (mise à jour de sécurité uniquement, les correctifs sont rétro-porte par Canonical sur les versions qui ne sont plus supportées par "The document fondation" :
LibreOffice 6.2 pour Ubuntu 19.04
LibreOffice 6.0 pour Ubuntu 18.04
LibreOffice 5.1 pour Ubuntu 16.04
Par contre Ubuntu envisage en effet de remplacer le paquet classique de Chromium par une « boite vide » qui renverrait alors vers le snap correspondant. On n'aurait donc plus le choix.
Bref, je vois bien arriver un Ubuntu sans aucune application .deb pré-installées et les applications snap qui sont les seules versions disponibles. Les paquets .deb traditionnels restant pour assurer la compatibilité avec des application qui n'existent pas dans Snap.
Il reste un problème: il faut être connecté à Internet : https://bugs.launchpad.net/snapstore/+bug/1767118
(pour les paquets traditionnels, il est facile pour une société de faire son propre miroir, cf liens sur https://ubuntu.lafibre.info/#new-mirror)
-
Exemple: Comment installer Le dernière version de LibreOffice ?
Dans "Logiciels Ubuntu", chercher LibreOffice. Faire attention de prendre la version dont la source indique "Boutique des snap" :
(https://lafibre.info/testdebit/ubuntu/201909_ubuntu_libreoffice_1.png)
L'installation ne remplace pas la version de LibreOffice dans des paquets .DEB : Toutes les applications sont en double :
(https://lafibre.info/testdebit/ubuntu/201909_ubuntu_libreoffice_2.png)
Il est possible de lancer simultanèment deux versions différentes de LibreOffice.
Exemple sous Ubuntu 18.04 avec toutes les mises à jour au 7 septembre 2019 :
- LibreOffice Writer 6.3.0.4 est la version installée par les Snap
- LibreOffice Writer 6.0.7.3 est une version "Ubuntu 18.04.9" qui intègre les derniers correctifs de sécurité, sont rétro-porte par Canonical - cette version date du 20 août 2019 et corrige une faille sur LibreLogo (rendu graphique vectoriel).
(https://lafibre.info/testdebit/ubuntu/201909_ubuntu_libreoffice_3.png)
Vous pouvez bien sur désinstaller les applications de la version LibreOffice 6.0 dans "Logiciels Ubuntu"
Edit: La version snap et flatpak de LibreOffice ont toutefois des soucis si vous souhaitez utiliser Base avec un driver SGBD écrit en Java ou si vous utilisez des extensions Java/Python.
-
La taille des mises à jour Linux me semble être problématique avec Snap / Flatpak et Appimage
Sous Windows, une mise à jour majeur de Firefox prend environ 30 Mo :
Mise à jour de Firefox 68.0.2 à 69.0 sous Windows 7 :
(https://lafibre.info/testdebit/windows7/201909_firefox_mis_a_jour_version_majeure.png)
Mais les versions intermédiaires de Firefox, qui sortent en moyenne tous les deux semaines, prennent de 2 à 10 Mo :
Mise à jour de Firefox 69.0 à 69.0.1 sous Windows 7 :
(https://lafibre.info/testdebit/windows7/201909_firefox_mis_a_jour_version_mineure.png)
Sous Linux, il faut tout télécharger à chaque mise à jour, même mineure.
Mise à jour de Firefox 69.0 à 69.0.1 avec APT :
(https://lafibre.info/testdebit/ubuntu/201909_firefox_apt.png)
Avec Snap, Flatpak et Appimage la taille explose.
Exemple avec la mise à jour de Firefox 69.0 à 69.0.1 avec Snap :
(https://lafibre.info/testdebit/ubuntu/201909_firefox_snap.png)
Télécharger des mises à jour de 2 à 10 Mo sous Windows, vs 222 Mo tous les deux semaines, cela fait une grosse différente qui n'est plus négligeable.
-
Bien sur il y a la solution de ne pas faire chaque mise à jour mineure.
Je m'étonne de deux choses :
1/ Pourquoi Linux Mint n'utilise pas la version Firefox inclut dans la base Ubuntu qu'il utilise ? Pourquoi en faire une nouvelle version ?
2/ Pourquoi Linux Mint ne propose pas la mise à jour 69.0.1 ?
(https://lafibre.info/testdebit/ubuntu/201909_firefox_mint.png)
-
Intéressant je ne connaissais pas.
Par contre on perd pour moi ce qui faisait la force d'un linux: le côté modulaire et léger!
La à chaque fois on sera forcé de tout retélécharger, d'avoir potentiellement x versions d'une même librairie installée...
Bref de la lourdeur, et un manque d'optimisation.
Après ça permet d'avoir une certaine uniformisation et donc des logiciels plus facilement portable entre les différentes distributions...
Bref mitigé
-
Mint propose bien la MAJ mineure de Firefox : https://mint.pkgs.org/19.1/mint-upstream-amd64/firefox_69.0.1+linuxmint1+tina_amd64.deb.html
Le dépôt n'était peut-être pas encore à jour ?
-
C'est probablement la raison.
J'ai reçu la mise à jour ce matin.
J'utilisais ce miroir :
(https://lafibre.info/testdebit/ubuntu/201909_linux_mint_miror_1.png)
Le choix ne se fait que par le débit avec mint :
(https://lafibre.info/testdebit/ubuntu/201909_linux_mint_miror_2.png)
Alors que sur Ubuntu, on peut regarder la fraîcheur des dépôts sur https://launchpad.net/ubuntu/+archivemirrors
(https://lafibre.info/testdebit/ubuntu/201909_ubuntu_miror_france.png)
-
Heu ...
Les vendors Linux ne sont pas en train de répliquer le DLL Hell qui existe sous Windows depuis 20 ans là, rassurez moi ? (WoW, WinSXS , et un disque dur de 300Go nécessaire pour installer un OS qui pourrait tenir sur 2Go s'il était correctement conçu) ?
Ils tombent vraiment bien bas dans mon estime tous les Canonnical etc... Wou la vache.
Heureusement que je reste sous Debian qui ne changera pas de ci-tôt son système de packaging ;D
-
C'est le but. Ne plus dépendre de la version du système (ou d'un type de distro) et pouvoir exécuter de l'ancien ou du récent même si les dépendances et le programme lui-même dans les dépôts ne sont pas dans la bonne version (ou qu'ils ont disparu).
C'est un avantage et un inconvénient à la fois...
Perso, je m'en sers de cette manière : Vu que je suis sur ubuntu LTS et que j'aime avoir les dernières avancées (pour kdenlive par exemple) j'installe le appimage et le reste du système reste à l'identique.
-
L'inconvénient est quand même assez féroce : c'est extrêmement gourmand en espace disque, et possiblement aussi en quantité mémoire (le Kernel ne pourra pas partager les segments mémoires partgeables, comme celui des libs).
En gros, ca consomme beaucoup, beaucoup beaucoup .... la planète , une fois de plus.
-
Tu y a vas un peu fort je trouve.
Ce n'est pas l’utilisation de 2 ou 3 programmes en appimage/flatpack/snap qui va faire grimper de manière exponentielle la pollution mondiale, surtout vu le nombre d'user Linux deskop...
A ce compte là, que Microsoft fasse l'effort de faire comme Linux, et là on aura un vrai impact avec plus d'un milliard de machines. Et pour le coup je dirais pas non à un système plus léger, 4 Go d'iso et plus de 10 installé, ça commence à faire beaucoup.
-
Je constate simplement, que depuis X années , on ne fait que grossir , et la planète ne fait que souffrir plus.
Au lieu de faire mieux, avec moins, on fait à peine mieux (souvent même moins bien, ou inutile tout simplement) , mais avec beaucoup plus de ressources nécessaires.
A l'echelle planétaire, je suis désolé , mais un octet en moins dans un programme / en mémoire, par ci, par là , ca représente beaucoup. Sauf qu'aujourd'hui, le maitre mot est productivité. A l'époque où j'ai commencé, c'était simplicité, et économie (la mémoire se comptait en Ko) et on utilisait un char à la place d'un int ;-)
Bref, passons le HS, j'en suis désolé :-)
-
C'est vrai qu'il y a 10 ans on se débrouillait très bien avec 2 Go de RAM voir moins (mon premier portable sous linux en 2008 avait 1 Go de RAM et un celeron bas de gamme et tournait très bien avec la 8.04, je pouvais même faire mon kéké avec compiz : le cube, les flammes 8)) et elle tenait sur un CD. Aujourd’hui si on a pas 4 Go mini, on ne fait plus rien.
Tu n'es pas le seul qui aimerais ne jamais avoir à augmenter sa quantité de RAM parce que tout est de plus en plus lourd. Et pas forcèment mieux.
-
2 Go ? J'ai encore un PC avec 64 Ko de ram...
Il faut que j'essaye de le démarrer (IBM PC avec un 8088 à 4,77 Mhz équipé d'un disque dur de 10 Mo qui prend 2 emplacements Frontal 5.25")
C'est vrai que l'interface noir et vert de PC-DOS, c'est moins sympa.
-
Ah oui... c'était vraiment le tout début d'intel :o
Perso, le plus vieux PC que j'ai utilisé c'était ça (ou un modèle hyper proche, en tout cas extérieurement c'était exactement le même boîtier avec ce gros bouton rose) : http://ru.pc-history.com/icl-ergo-pro-c433.html
Maintenant je regrette tellement de l'avoir foutu à la benne :( En plus en y repensant, je pense qu'il n'avait aucune panne hardware et qu'il suffisait de le réinstaller... mais à l'époque je n'avais aucune connaissance ni les disquettes de 3.1 et encore moins internet. C’était déjà le parcours du combattant pour installer 98 avec la disquette de boot et le CD avec la procédure notée sur un papier...
-
Petite vidéo qui présente bien Snap et Flatpak
On comprend bien avec une démonstration de création d'un paquet démo
https://www.youtube.com/watch?v=ixWuE1hhZfw
-
Comparaison de la taille : J'ai comparé la taille de l’application Riot, un concurrent OpenSource de WhatsApp.
Windows : .exe 64bits => Téléchargement d'un fichier de 76 Mo
(https://lafibre.info/testdebit/ubuntu/201909_riot_win64.png)
Linux : .deb 64bits => Téléchargement d'un fichier de 54 Mo
(https://lafibre.info/testdebit/ubuntu/201909_riot_deb.png)
Snap => Taille installée de 69 Mo
(https://lafibre.info/testdebit/ubuntu/201909_riot_snap.png)
Flatpak => Téléchargement d'un fichier de 770 Mo / Taille installée de 206 Mo
(https://lafibre.info/testdebit/ubuntu/201909_riot_flatpak.png)
770 Mo sachant que le paquet est mis à jour toutes les semaines, c'est dèmentiel !
-
Comparaison de la taille de l'application FileZilla :
Windows : .exe 64bits => Téléchargement d'un fichier de 9 Mo
Linux : .deb 64bits => Taille installée de 7 Mo
(https://lafibre.info/testdebit/ubuntu/201909_filezilla_deb.png)
Snap => Taille installée de 47 Mo
(https://lafibre.info/testdebit/ubuntu/201909_filezilla_snap.png)
Flatpak => Téléchargement d'un fichier de 834 Mo / Taille installée de 31 Mo
(https://lafibre.info/testdebit/ubuntu/201909_filezilla_flatpak.png)
-
Heu ...
Les vendors Linux ne sont pas en train de répliquer le DLL Hell qui existe sous Windows depuis 20 ans là, rassurez moi ? (WoW, WinSXS , et un disque dur de 300Go nécessaire pour installer un OS qui pourrait tenir sur 2Go s'il était correctement conçu) ?
Ils tombent vraiment bien bas dans mon estime tous les Canonnical etc... Wou la vache.
Heureusement que je reste sous Debian qui ne changera pas de ci-tôt son système de packaging ;D
Je me disais la même chose que toi en lisant la description de ce système d'images. Ce n'est pas 2 ou 3 applications, si Ubuntu remplace deb par snap. C'est bien vers l'enfer des DLLs de windows que l'on va. Chez moi, sur mon windows 10, WinSxS fait 10 Go (et ce n'est pas énorme vu d'autres installations que j'ai vues).
Linux va de plus en plus vers la complexité et l’embonpoint (comme avec systemd par exemple).
-
Et encore winSxS ne concerne que windows lui-même et pas les logiciels tiers...
Y'a aussi le système de comptage de l'explorateur qui le rend plus gros qu'il ne l'est en réalité (perso, je ne l'ai découvert que récemment) :
Le magasin de composants présente une grande taille de répertoire en raison de la manière dont le shell de l'Explorateur Windows prend les liens physiques en compte. Le shell Windows compte chaque référence à un lien physique comme une seule instance du fichier pour chaque répertoire dans lequel le fichier réside. Par exemple, si un fichier nommé advapi32.dll présente une taille de 700 Ko et est contenu dans le magasin de composants et dans le répertoire \Windows\system32, l'Explorateur Windows signale à tort que le fichier utilise 1 400 Ko d'espace disque dur.
S'ils réglaient ce soucis, on aurait enfin la vraie taille et par la même occasion on pourrait stocker plus de truc. Car là on a de l'espace gâché alors qu'il n'existe pas en réalité.
-
Maintenant pour plus de sécurité, je comprends qu'il soit nécessaire d'évoluer vers un système qui confine les application.
Maintenant, je trouve dommage de ne pas savoir quand on installe un snap si on est en mode strict ou mode classique.
La documentation : Snap confinement (https://snapcraft.io/docs/snap-confinement)
Snap propose trois niveaux de confinement instantané:
- Strict : Utilisé par la majorité des snaps. Les snaps strictement confinées s'exécutent de manière totalement isolée et ne peuvent par conséquent accéder à vos fichiers, réseau, processus ou à aucune autre ressource système sans demander un accès spécifique via une interface (voir ci-dessous).
- Classique : Permet d’accéder aux ressources de votre système de la même manière que les packages traditionnels. Pour vous protéger contre les abus, la publication d'un snap classique nécessite une approbation manuelle, et l'installation requiert l'argument de ligne de commande --classic.
- Devmode : Un mode spécial pour les créateurs de snap et les développeurs. Un devmode snap s'exécute comme un snap strictement confiné avec un accès complet aux ressources système et génère un résultat de débogage permettant d'identifier les interfaces non spécifiées. L'installation nécessite l'argument de ligne de commande --devmode. Les snaps Devmode ne peuvent pas être publiés sur le canal stable, n'apparaissent pas dans les résultats de la recherche et ne sont pas actualisés automatiquement.
Le confinement strict utilise les fonctionnalités de sécurité du noyau Linux, notamment AppArmor, seccomp et les namespaces, pour empêcher les applications et les services d'accéder au système plus vaste.
Et un comparatif sur une grosse application :
Snap => Taille installée de 441 Mo
(https://lafibre.info/testdebit/ubuntu/201909_libreoffice_snap.png)
Flatpak => Téléchargement d'un fichier de 1,1 Go / Taille installée de 682 Mo
(https://lafibre.info/testdebit/ubuntu/201909_libreoffice_flatpak.png)
-
vu les tailles que tu indique vivien, la on fait pire que windows!!!
Je veux bien que la bande passante et l'espace disque soient de moins en moins limités mais quand même...
Je ne suis vraiment pas sur que ce soit "la bonne voie"
-
Je n'avais pas fait attention à la taille, c'est assez énorme en effet...
Pour moi ça va bien si on a besoin d'une version plus récente de quelques logiciels. S'il s'avère qu'Ubuntu ne se repose plus que sur les snap à l'avenir, il est clair que j'irais voir ailleurs.
-
Ubuntu envisage en effet de remplacer le paquet classique de Chromium par une « boite vide » qui renverrait alors vers le snap correspondant. On n'aurait donc plus le choix.
Bref, je vois bien arriver un Ubuntu sans aucune application .deb pré-installées et les applications snap qui sont les seules versions disponibles. Les paquets .deb traditionnels restant pour assurer la compatibilité avec des application qui n'existent pas dans Snap.
C'est fait :
Nous avons récemment annoncé la transition du paquet deb Chromium vers Snap, dans Ubuntu 19.10. Une telle transition n'est pas anodine et a suscité de nombreuses discussions constructives. Nous résumons donc ici pourquoi nous procédons ainsi, comment et dans quel délai.
Pourquoi
Chromium est un navigateur Web très populaire, l’équivalent totalement ouvert de Google Chrome. Sous Ubuntu, Chromium n’est pas le navigateur par défaut et le paquet réside dans la section "univers" de l’archive. Univers contient des progiciels gérés par la communauté. Malgré cela, l’équipe Ubuntu Desktop s’engage à conditionner et à maintenir Chromium car un nombre important d’utilisateurs y ont recours.
La maintenance d’une version unique de Chromium représente un investissement de temps considérable pour l’équipe de bureau Ubuntu qui travaille avec l’équipe de sécurité d’Ubuntu pour mettre à jour chaque mise à jour. Les équipes prenant en charge de nombreuses versions stables d'Ubuntu, la charge de travail est complexe.
La comparaison de cette charge de travail avec d'autres distributions Linux en rolling release omet la nuance de prendre en charge plusieurs versions de support à long terme (LTS) et non-LTS.
Google publie une nouvelle version majeure de Chromium toutes les six semaines, avec généralement plusieurs versions mineures permettant de remédier aux vulnérabilités en matière de sécurité. Chaque nouvelle version stable doit être créée pour chaque version d'Ubuntu prise en charge - 16.04, 18.04, 19.04 et les prochaines versions 19.10 - et pour toutes les architectures prises en charge (amd64, i386, armhf, arm64).
En outre, il peut être difficile de s'assurer que Chromium construit (et encore moins s'exécute) sur des versions plus anciennes telles que 16.04, car le projet en amont utilise souvent de nouvelles fonctionnalités du compilateur qui ne sont pas disponibles sur les versions précédentes.
En revanche, un paquet Snap ne doit être créée qu'une fois par architecture et sera exécutée sur tous les systèmes prenant en charge snapd. Cela couvre toutes les versions prises en charge d'Ubuntu, y compris 14.04 avec maintenance de sécurité étendue (ESM), ainsi que d'autres distributions telles que Debian, Fedora, Mint et Manjaro.
Bien que ce changement d’emballage pour Chromium puisse nous permettre de concentrer les ressources des développeurs ailleurs, l’emballage en un coup d’œil présente des avantages supplèmentaires. Les canaux dans le Snap Store permettent de publier facilement plusieurs versions de Chromium sous un seul nom. Les utilisateurs peuvent basculer entre les canaux pour tester différentes versions du navigateur. Snap Store met à jour les Snap automatiquement en arrière-plan, ce qui permet aux utilisateurs de s’assurer qu’ils exécutent des logiciels à jour sans avoir à gérer manuellement leurs mises à jour. Nous pouvons également publier rapidement des correctifs spécifiques via des branches du Snap Store, ce qui permet aux utilisateurs et aux développeurs de se remettre rapidement au courant des rapports de bogues. Enfin, la capture instantanée de chrome est strictement confinée, ce qui fournit des garanties de sécurité supplèmentaires aux utilisateurs.
En résumé: il existe plusieurs facteurs qui font de Chromium un bon candidat à la transition:
- Ce navigateur n’est pas le navigateur par défaut d’Ubuntu et a donc moins d’impact en raison de la taille réduite de sa base d’utilisateurs.
- Les snaps sont explicitement conçus pour supporter une fréquence élevée de mises à jour
- Le projet en amont a trois canaux de publication (stable, beta, dev) qui correspondent parfaitement aux canaux par défaut de snapd (stable, beta, edge). Cela permet aux utilisateurs de changer facilement de version de Chromium ou même d’avoir plusieurs versions installées en parallèle.
- L'application est strictement confinée, ce qui ajoute une couche de sécurité supplèmentaire au mécanisme de sand-boxing déjà robuste du navigateur.
Comment
La première Snap de Chromium a été crée il y a deux ans et nous avons parcouru un long chemin depuis. La version snap compte actuellement plus de 200 000 utilisateurs d'Ubuntu et plus de 30 autres distributions Linux. La version actuelle présente quelques problèmes mineurs sur lesquels nous travaillons, mais nous avons pensé qu’elle était suffisamment solide et mûre pour une transition. Nous sommes convaincus qu'il est temps de commencer la transition des utilisateurs de la version de développement (19.10) d'Ubuntu. Nous sommes impatients de recueillir des commentaires sur ce qui fonctionne et ce qui ne nous attend pas avant la prochaine version du support à long terme d’Ubuntu, la 20.04.
Avec Ubuntu 19.10, le package deb du navigateur chromium (et les packages associés) ont été transformés en un package de transition qui ne contient que des scripts d'encapsulation et un fichier de bureau pour la compatibilité en amont. Lors de la mise à niveau ou de l'installation du paquet deb sous 19.10, la capture sera téléchargée à partir du Snap Store et installée.
Un soin particulier a été pris pour ne pas interrompre les flux de travail existants et pour rendre la transition aussi transparente que possible:
- Lors de la première exécution de la capture, un profil utilisateur Chromium existant dans $ HOME / .config / chromium sera importé (à condition que l'espace disque soit suffisant).
- Les exécutables chrome-browser et chromedriver de / usr / bin / sont des wrappers qui appellent les exécutables de snap respectifs.
- chromedriver a été corrigé afin que les scripts de sélénium existants continuent à fonctionner sans modifications
- Si l'utilisateur a défini Chromium comme navigateur par défaut, le wrapper du navigateur chromium se chargera de le mettre à jour dans le snap Chromium.
- De même, les entrées épinglées existantes dans les lanceurs de postes de travail seront mises à jour pour pointer vers la version instantanée (mises en œuvre pour GNOME Shell et Unity uniquement pour l'instant, les contributions sont bienvenue pour le faire dans d'autres environnements de postes de travail).
- Le apport hook a été mis à jour pour inclure des informations pertinentes sur le snap et ses dépendances.
Quand
Si vous passez a Ubuntu 19.10, vous pouvez essayer Chromium en un clin d’œil et tester la transition à partir du paquet deb dès maintenant. Toutefois, vous n’avez pas besoin d’attendre la sortie du 17 octobre pour commencer à utiliser le logiciel instantané et à partager vos commentaires. Exécutez simplement les commandes suivantes pour être opérationnel:
snap install chromium
snap run chromium
Une fois la version Ubuntu 19.10 publiée, nous envisagerons d’étendre la transition à d’autres versions stables, à partir de 19.04. Cela ne se produira que lorsque tous les problèmes connus importants auront été résolus.
Nous apprécions tous les commentaires que nous avons envoyés au cours des derniers mois lors de l’annonce de ce projet. Honnêtement, nous pensons que la fourniture d’applications snap offre des avantages considérables aux développeurs et aux utilisateurs. Nous savons qu'il peut y avoir des difficultés lorsque nous travaillons pour l'avenir et continuerons d'écouter nos utilisateurs à mesure que nous planifions ces migrations.
Source : Blog Ubuntu (https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition), traduit de l'Anglais rapidement par moi-même.
-
En image pendant la mise à jour vers Ubuntu 19.10 :
(https://lafibre.info/testdebit/ubuntu/201910_chromium_snap_1.png) (https://lafibre.info/testdebit/ubuntu/201910_chromium_snap_2.png)
Après installation :
(https://lafibre.info/testdebit/ubuntu/201910_chromium_snap_3.png)
-
Ça a du sens pour Chromium, ok, mais j'espère qu'ils se cantonneront à ce cas spécifique...
-
S'il te plaît vivien, pourrais-tu plutôt vérifier la taille à l'installation en installant vraiment les logiciels, et en vérifiant l'espace disque/la bande passante utilisée?
Les nombres que tu indiques montrent que snap est beaucoup plus léger que flatpak. En vérité, c'est plutôt l'inverse (sauf au premier flatpak installé sur le système):
- Les flatpak utilisent des runtimes partagées: si une application a besoin de la runtime KDE, il faudra télécharger tout cela! mais pas si on installe une deuxième application qui utilise la runtime KDE... En fait, c'est assez proche d'un gestionnaire de paquets traditionnel, mais avec beaucoup moins de granularité
- Les flatpaks conservent les données dans OStree (https://ostree.readthedocs.io/en/latest/manual/introduction/): il est techniquement impossible de prédire la taille exacte de téléchargement, pour les mêmes raisons que git: on ne télécharge que ce que l'on n'a pas, mais pour le savoir, il faut comparer les deux. Seule une estimation du pire cas est possible, c'est ce qui est affiché. En vérité, il est fort probable que cela prenne moins de place que les mises à jour de la distribution, pour un nombre comparable de paquets
Je dois avouer qu'il s'agit de ma solution favorite pour l'instant, et je l'utilise beaucoup pour isoler des applications un peu louches/propriétaires quand vraiment nécessaire (il faut noter que les droits des paquets flathub sont souvent un peu trop permissifs sur l'accès aux fichiers, mais c'est modifiable), ainsi que pour installer des applications sans installer trop de dépendances: calibre et python2, ou steam et tout le multilib... Je note aussi que le "bac à sable" n'est efficace qu'avec Wayland.
Je note cependant que Appimage et Snap disposent aussi de systèmes de mise à jour incrèmentales, même si elles sont utilisées beaucoup moins systématiquement. J'aime pas mal AppImage pour des applications portables à mettre su une clé USB.
Mais malgré ces avantages, je leur préfère une autre solution: le système déclaratif de Nix (https://en.wikipedia.org/wiki/Nix_package_manager) et Guix (https://en.wikipedia.org/wiki/GNU_Guix), qui sont plus des itérations sur le modèle de gestionnaire de paquet traditionnel, et quelques liens avec OStree. Cela permet d'avoir plusieurs versions concurrentes installées, avec leurs dépendances différentes, d'utiliser des environnements différents facilement, et de rétablir une configuration précédente très facilement (même depuis GRUB). Il est aussi possible de tester une configuration du système avant de l'appliquer (celle-ci peut être utilisée dans un seul des terminaux, par exemple). Il est même possible de décrire la configuration entière du système dans un seul fichier, afin de répliquer celle-ci à l'identique sur une autre machine (d'où le sobriquet de "gestionnaire de paquet déclaratif").
Je trouve que les distributions basées sur Nix et Guix gagnent de plus en plus de traction... Je vais personnellement passer de Yunohost à NixOS sur mon serveur, je pense (et bien sûr, utiliser les fonctionnalités de btrfs en prime: déduplication, COW, snapshots, btrfs-send pour les backups).
Enfin, le système a suffisamment fait couler beaucoup d'encre... Mais il faut espérer qu'une solution bien meilleure sortira de tout cela, et que la compétition sera fructueuse. Snap a déjà récupéré le système de portails (https://github.com/flatpak/flatpak/wiki/Portals) créé pour flatpak, par exemple.
-
Avec le format Appimage, l'application doit gérer elle même sa mise à jour, contrairement à Snap ou Flatpak.
Résultat, cela ne fonctionne pas toujours : (ici Molotov.TV sous Ubuntu 19.10)
(https://lafibre.info/testdebit/ubuntu/201911_appimage_maj.png)
-
La logithèque de Fedora ne prendre plus en charge les paquets Snap à partir de Fedora 31.
L’explication est à se tordre de rire avec une histoire avec Fiat, Peugeot, General Motors et BMW (je pense que c'est Canonical) avec son moteur diesel (je pense que c'est Snap).
=> https://blogs.gnome.org/hughsie/2019/07/12/gnome-software-in-fedora-will-no-longer-support-snapd/
Plus sérieusement, Canonical a décidé de ne pas installer gnome-software dans Ubuntu 20.04 LTS. gnome-software sera remplacé par "Snap Store by Canonical".
Le nouveau Snap Store ne prendra pas en charge les Flatpaks, le format concurrent développé par RedHat/Fedora.
Richard Hughes, un développeur Red Hat, explique que les développeurs de Canonical actuellement affectés à travailler sur gnome-software ont été réaffectés pour travailler sur le Snap Store, et il n'est pas sur que le code qui sera développé sera open source (sous réserve que j'ai bien compris sont mail du Heads up: No more snap plugin in gnome-software (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/).
Il rajoute : "Sans le Snap Store le support de snap est plutôt inutile, car snapd est tellement lié a l'écosystème snapcraft, et parce que vous ne pouvez pas réellement exécuter votre propre instance du Snap Store, contrairement à Flatpak". Ce point semble bien vrai et il m’inquiète moi aussi : Avoir un unique magasin pour télécharger les snap, c'est faire la même chose que Google et le Google Play Store, Apple et l'App Store ou Microsoft et le Microsoft Store.
Bref, il semblerait que la guerre des nouveaux format d’application sous Linux soit déclarés. Aujourd'hui les distributions Linux acceptent aussi bien Snap, Flatpak que Appimage, mais si j'ai bien compris Canonical va supprimer le support de Flatpak et RedHat/Fedora le support de Snap.
-
Et après on se demande pourquoi Linux ne perce pas (et ne percera jamais)...
-
Voici un exemple de mise à jour que je viens d'effectuer via flatpak sur mon système. L'interface graphique aurait affiché 2.5 Gio de mises à jour. Il a été uniquement nécessaire de télécharger 68 Mio. OStree rend les mises à jour plus efficaces que les traditionnels gestionnaires de paquets (à peu près au même niveau que les mises à jour internes à Firefox, ou les Apk android, qui utilisent bsdiff).
-
OStree rend les mises à jour plus efficaces que les traditionnels gestionnaires de paquets
dnf a une option deltarpm qui fait la même chose
apt possède également debdelta mais il me semble que ce n'es pas utilisé par debian/ubuntu
pacman vient de perdre son option de delta pour raisons de sécurité (plutôt prévenir que guérir selon les devs)
Dans l'ensemble on peut voir qu'ils ont quand même expérimenté avec le concept.
Les avis ont l'air plutôt partagés sur l'intérêt réel des deltas, ça ne m'étonne pas que Canonical n'utilise pas ce procédé pour snap vu qu'ils refusent de l'utiliser pour apt.
-
Un autre point problématique : pas moyen de forcer la mise à jour des Snap graphiquement ou de les bloquer !
Le "Gestionnaire de mise à jour" se limite aux fichiers .deb :
(https://lafibre.info/testdebit/ubuntu/201804_mis_a_jour_ubuntu_1804_02.png) (https://lafibre.info/testdebit/ubuntu/201804_mis_a_jour_ubuntu_1804_01.png)
Les mise à jour Snap sont réalisées automatiquement au démarrage et on n'a pas de possibilité de bloquer ces mises à jour (par exemple si on est en 4G), contrairement aux mises à jour .deb
Pas facile pour un non expert d'imaginer que malgré les paramètres de cette fenêtre ses applications Snap seront mises à jour :
(https://lafibre.info/testdebit/ubuntu/201911_ubuntu1910_parametres_maj.png)
-
Les mise à jour Snap sont réalisées automatiquement au démarrage et on n'a pas de possibilité de bloquer ces mises à jour (par exemple si on est en 4G), contrairement aux mises à jour .deb
selon la doc il est seulement possible de désactiver la recherche de mise à jour en connection limité : https://snapcraft.io/docs/keeping-snaps-up-to-date
Use refresh.metered to pause and re-enable the refresh process when NetworkManager detects a metered connection, such as an LTE link with a limited data plan.
On peut remarquer que ce comportement est dépendant de NetworkManager, à voir si ça fonctionne sans...
à noter aussi que le comportement par défaut est le fonctionnement des mises à jour
By default, refresh is enabled when a metered connection is detected.
Je ne comprends vraiment pas la stratégie de Canonical avec snap, aucune des décisions qu'ils prennent n'a de sens.
-
Sortir des gestionnaires de paquets avec des dépendances qui font qu'une application est disponible dans une version différente pour chaque version supporté de l'OS.
La plupart des applications exceptés certaines comme Firefox, c'est une version différente pour chaque version supporté d'Ubuntu / Debian.
Vous imaginez si c'était la même chose sous Android ?
Les applications dasn les .deb ou les .rpm, il n'y a pas de possibilité de les exécuter dans une sandbox, alors que les appli Android, iOS, MacOS et Windows (via le windows store) sandbox les applications et demandent une autorisation pour avoir accès à la webcam ou aux fichiers.
C'est ces besoins qui ont fait naitre le format AppImage. Un même fichier va marcher avec n’importe quelle distribution dans n'importe quelle version, le rêve !
AppImage a deux grandes faiblesses :
- Pas de mises à jour centralisée et souvent pas de mises à jour du tout (les paquets qui savent se mettre à jour comme Molotov sont un exception et souvent cela ne fonctionne pas bien cf Pb de MAJ Molotov TV (https://lafibre.info/testdebit/ubuntu/201911_appimage_maj.png)).
- On télécharge une application comme un .exe sur Internet : on n'est pas sur de son authenticité alors qu'on a une sécurité élevé sur la provenance avec les .deb / .rpm.
Ces deux régressions ont fait que AppImage ne s'est jamais démocratisé.
Ces pour ces raisons que Snap (Canonical), Flatpak (RedHat) ont été crée par deux des grands acteurs de Linux pour démocratiser l’utilisation de Linux auprès du grand public avec un concept qui a fait ses preuves sur les autres plateformes. Les concepts sont presque identiques, on peut penser qu'une fois la guerre terminée, un seul va survivre. Que va faire Debian à terme ?
Il est impossible de télécharger un Snap / flatpak et le stocker sur une clée usb pour l’utiliser ou le partager hors ligne.
Ce comportement est le même que sous Android / iOS / MacOS ou le store Microsoft.
Cela choque par contre dans le libre, car on n'a plus accès aux sources et il faut faire confiance à l'éditeur qui a crée le paquet Snap / flatpak.
On a les mêmes limitations que sur les autres OS qui ont un store unique.
Si vous souhaitez installer un vieux PC avec de veilles applications, c'est facile avec les paquets traditionnels, que ce soit les .exe sous Windows ou les .deb / .rpm.
Par contre avec Snap, Flatpak, c'est impossible. C'est comme quand vous testez votre vieux Smartphone avec Android version 2.x ou 3.x : vous ne pouvez plus rien télécharger / faire, il est bon pour la poubelle.
La lenteur de démarrage d'une application Snap, Flatpak vs native est aussi un problème pour les petites configuration. C'est particulièrement visible pour des petites application comme la calculatrice (avec une clean install Ubuntu, la calculatrice est un paquet Snap).
A noter que flatpak permet de configurer un store alternatif et Snap non (officiellement, c'est pas encore).
Bref, il y a des bonnes idées, mais appliquer les solutions des OS propriétaires tel que, ce n'est pas forcément la bonne solution et on voit aussi la difficulté qu'a Microsoft pour basculer les applications Win32 en "Métro" (le nouveau nom est "Applications Windows" et remplace le terme "Metro").
-
alors que les appli Android, iOS, MacOS et Windows (via le windows store) sandbox les applications et demandent une autorisation pour avoir accès à la webcam ou aux fichiers.
Snap et Flatpak n'ont conceptuellement rien a voir avec ce qui se fait sur Windows/Android/iOS/MacOS.
Snap et Flatpak sont plus proches de ce qu'on fait avec Docker et les containers en général: on embarque avec l'application tout une partie de l'OS (l'userland) qu'elle a besoin pour fonctionner et on l'exécute dans un environnement isolé.
On ne fait pas ce genre de 'sandboxing' sur Android/iOS/Mac/Windows et la notion d'autorisation d'accès aux périphériques ou autres n'a rien a voir avec ca.
Le problème de Linux c'est qu'il y a trop de distro différentes incompatibles entre elles et que les apps dépendent souvent d'autres apps via tout un graphe de dépendance qui peut être compliqué. Un créateur d'app ne peut 'cibler' une version d'OS car il n'y a pas un seul OS. Du coup il va peut-être cibler une famille comme Debian/Ubuntu/etc mais la encore il aura des soucis avec les dépendances.
Meme la lib de base, la 'libc' peut-être différente et incompatible d'un Linux a un autre.
Apres franchement ce débat est de nos jours limité aux apps pour Linux Desktop ou aux applications "anciennes". Toutes les applications modernes du moment n'ont pas besoin de ces systèmes de 'packaging' car elle produisent un binaire unique qui ne dépend que d'une version minimum du noyau (linux kernel). C'est a la compilation (génération du binaire) que les dépendances sont résolues et intégrées donc c'est le développeur qui s'occupe de ca et l'appli n'aura pas de souci si l'administrateur ne tient a jour les dépendances car il n'y en a pas.
Le problème subsiste qu'en Linux desktop a cause de la pléthore d' environnements graphiques déférents (GNOME, KDE, etc).
On peut contourner ce problème avec les containers ( https://github.com/mviereck/x11docker ) c'est bien mieux isolé que Snap/Flatpak/etc mais pour le moment moins 'user friendly' donc réservé a un public averti.
-
Mise à jour du support Flatpak sous Ubuntu : J'ai été mort de rire en lisant le changelog - les modifications ne concernent que Snap.
(https://lafibre.info/testdebit/ubuntu/201912_maj_support_flatpak_gnome.png)
-
Elle est pas mal celle là^^
-
c'est un patch de GNOME pas spécifique a FlatPak.
-
Les modifications ne concernant que Snap, pourquoi mettre à jour le paquet "gnome-software-plugin-flatpak" qui est indépendant et d'ailleurs pas installé de base sous Ubuntu (c'est moi qui l'ai installé pour rajouter des applications Flatpak)
-
Les modifications ne concernant que Snap, pourquoi mettre à jour le paquet "gnome-software-plugin-flatpak" qui est indépendant et d'ailleurs pas installé de base sous Ubuntu (c'est moi qui l'ai installé pour rajouter des applications Flatpak)
question de dépendances. si tu regarde bien le correctif vient de l'upstream (corrigé dans gnome-software -> propagé dans Debian -> propagé dans Ubuntu).
comme tu as installé Flatpak et gnome-software-plugin-flatpak, "gnome-software" doit être mis a jour et la dépendance se propage par"gnome-software-plugin-flatpak".
Ca n'a rien a voir avec Flatpak directement donc.
enfin je le comprend comme ca, c'est souvent prise de tete les arbres de dépendances des paquets. ;D
-
Il est impossible de télécharger un Snap / flatpak et le stocker sur une clée usb pour l’utiliser ou le partager hors ligne.
Ce comportement est le même que sous Android / iOS / MacOS ou le store Microsoft.
Cela choque par contre dans le libre, car on n'a plus accès aux sources et il faut faire confiance à l'éditeur qui a crée le paquet Snap / flatpak.
On a les mêmes limitations que sur les autres OS qui ont un store unique.
http://manpages.ubuntu.com/manpages/cosmic/man1/flatpak-create-usb.1.html
-
Merci, cela existe, même si une connexion est quand même nécessaire.
Autre limitation : Impossible d'installer un vieux paquet par faire des tests.
flatpak create-usb [OPTION...] MOUNT-PATH REF...
Copie les applications et / ou les exécutions REF spécifiées sur le support amovible monté sur MOUNT-PATH, ainsi que toutes les dépendances et métadonnées nécessaires à leur installation. C'est une façon de transférer des flatpaks entre des ordinateurs qui ne nécessitent pas de connexion Internet. Après avoir utilisé cette commande, la clé USB peut être connectée à un autre ordinateur et flatpak install préférera s'installer à partir de celle-ci plutôt qu'Internet, si les références sont les plus récentes disponibles. Pour que ce processus fonctionne, un ID de collection doit être configuré sur les télécommandes appropriées sur les ordinateurs source et de destination, et sur le serveur distant.
Chaque argument REF est un identifiant complet ou partiel au format ref flatpak, qui ressemble à "(app | runtime) / ID / ARCH / BRANCH". Tous les éléments, à l'exception de l'ID, sont facultatifs et peuvent être omis, y compris les barres obliques, de sorte que la plupart du temps, il vous suffit de spécifier l'ID. Toute partie laissée de côté sera comparée à ce qui est installé, et s'il y a plusieurs correspondances, un message d'erreur listera les alternatives.
Par défaut, cela recherche à la fois les applications installées et les runtimes avec la REF donnée, mais vous pouvez limiter cela en utilisant l'option --app ou --runtime.
Toutes les REF doivent être dans la même installation (utilisateur, système ou autre). Sinon, il est ambigu de savoir quelles références de métadonnées de référentiel mettre sur le lecteur USB.
Par défaut, flatpak create-usb utilise .ostree / repo comme répertoire de destination sous MOUNT-PATH mais si vous spécifiez un autre emplacement à l'aide de --destination-repo, un lien symbolique sera créé pour vous dans .ostree / repos.d. Cela garantit que dans les deux cas, le référentiel sera trouvé par flatpak (et d'autres consommateurs de libostree) pour les opérations d'installation / mise à jour.
Sauf si elle est remplacée par les options --system, --user ou --installation, cette commande recherche à la fois l'installation à l'échelle du système et celle par utilisateur pour REF et les erreurs si elles existent dans plusieurs.
-
J'ai regardé la taille des mises à jour sur Android, pour voir comment cela se passe sur d'autres plateformes.
La mises à jour de Firefox 68.4.1 vers 68.4.2 ne comporte que des correctifs mineurs qui ne sont même pas détaillés par Mozilla.
(https://lafibre.info/testdebit/android/202001_mise_a_jour_firefox_4.png)
Le Google play sotre est obligé de tout télécharger (41,3 Mo) pour faire cette petite mises à jour de 68.4.1 vers 68.4.2.
(https://lafibre.info/testdebit/android/202001_mise_a_jour_firefox_1.png) (https://lafibre.info/testdebit/android/202001_mise_a_jour_firefox_2.png) (https://lafibre.info/testdebit/android/202001_mise_a_jour_firefox_3.png)
-
Canonical dévoile les résultats d’un audit indépendant de sécurité sur Ubuntu Core, ce système d’exploitation basé uniquement sur des Snap et orienté embarqué + sécurité.
Plus d'info sur Ubuntu Core : https://ubuntu.com/core
Audit sécurité : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/202001_rule4_canonical_ubuntu_core_security.png) (https://lafibre.info/images/doc/202001_rule4_canonical_ubuntu_core_security.pdf)
-
Lister les SNAP installées sur un Ubuntu 18.10 (Gnome 3.30) mis à jour en 19.04 (Gnome 3.32) puis 19.10 (Gnome 3.34) :
$ snap list
Nom Version Révision Suivi Éditeur Notes
chromium 81.0.4044.92 1089 latest/stable canonical✓ -
core 16-2.44.1 8935 latest/stable canonical✓ core
core18 20200311 1705 latest/stable canonical✓ base
gnome-3-26-1604 3.26.0.20191114 98 latest/stable/… canonical✓ -
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable canonical✓ -
gnome-calculator 3.34.1+git4.c387feb0 704 latest/stable/… canonical✓ -
gnome-characters v3.32.1+git4.e06f0b2 495 latest/stable/… canonical✓ -
gnome-logs 3.34.0 93 latest/stable/… canonical✓ -
gnome-system-monitor 3.32.0-27-g32ed970e06 135 latest/stable/… canonical✓ -
gtk-common-themes 0.1-29-g45e78c5 1474 latest/stable/… canonical✓ -
$ snap list --all
Nom Version Révision Suivi Éditeur Notes
chromium 80.0.3987.163 1077 latest/stable canonical✓ désactivé
chromium 81.0.4044.92 1089 latest/stable canonical✓ -
core 16-2.44.1 8935 latest/stable canonical✓ core
core 16-2.43.3 8689 latest/stable canonical✓ core,désactivé
core18 20200311 1705 latest/stable canonical✓ base
core18 20200124 1668 latest/stable canonical✓ base,désactivé
gnome-3-26-1604 3.26.0.20191114 98 latest/stable/… canonical✓ -
gnome-3-26-1604 3.26.0.20191024 97 latest/stable/… canonical✓ désactivé
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable canonical✓ -
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 110 latest/stable canonical✓ désactivé
gnome-calculator 3.34.1+git4.c387feb0 704 latest/stable/… canonical✓ -
gnome-calculator 3.34.1+git1.d34dc842 544 latest/stable/… canonical✓ désactivé
gnome-characters v3.32.1+git4.e06f0b2 495 latest/stable/… canonical✓ -
gnome-characters v3.32.1+git3.b9120df 399 latest/stable/… canonical✓ désactivé
gnome-logs 3.34.0 81 latest/stable/… canonical✓ désactivé
gnome-logs 3.34.0 93 latest/stable/… canonical✓ -
gnome-system-monitor 3.32.1-3-g0ea89b4922 127 latest/stable/… canonical✓ désactivé
gnome-system-monitor 3.32.0-27-g32ed970e06 135 latest/stable/… canonical✓ -
gtk-common-themes 0.1-28-g1503258 1440 latest/stable/… canonical✓ désactivé
gtk-common-themes 0.1-29-g45e78c5 1474 latest/stable/… canonical✓ -
Je n'ai installé aucun Snap manuellement, Le snap de chromium est venu lors de la mise à jour 19.10, car j'avais chromium version Deb dans Ubuntu 19.04.
Gnome 3.28 est utilisé par Ubuntu 18.04 LTS et j’imagine certains SNAP.
Ce qui m'étonne, c'est la présence d'éléments de Gnome 3.26 (Version de Gnome utilisée par Ubuntu 17.10)
Version actuelle d'Ubuntu : lsb_release -a
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 19.10
Release: 19.10
Codename: eoan
Récupérer la version initiale utilisée pour Installer Ubuntu : cat /var/log/installer/media-info
Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
Date de l'installation initiale : ls -l /var/log/installer/media-info | awk '{print "Install date =", $6, $7, $8}'
Install date = févr. 13 2019
Mise à jour vers la version : grep "release-upgrader version" /var/log/dist-upgrade/main.log
2019-10-26 10:04:01,773 INFO release-upgrader version '19.10.12' started
Date de la mise à jour : ls -l /var/log/dist-upgrade/main.log | awk '{print "Upgrade date =", $6, $7, $8}'
Upgrade date = oct. 26 10:24
CPU : lscpu | grep modèle
Nom de modèle : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
-
Le problème c'est que certains snap sont déjà installés au départ. Ensuite dans la logithèque, certains logiciels sont en double et je ne vois pas bien la différencie entre les deux. Ce qui serait cohérent, c'est qu'il ne devrait pas y avoir de proposition de snap dans la logithèque et il faudrait passer la commande explicite snap install"paquet".
Il y a d'ailleurs une méthode pour ça. En passant la commande suivante :
sudo apt purge gnome-software-plugin-snap
Personnellement c'est ce que j'ai fais.
Je viens d'ailleurs d'aller plus loin en virant complètement snapd et tout ce qui avait été installé par snap.
stylou@lynx:~$ snap list --all
Nom Version Révision Suivi Éditeur Notes
core 16-2.43.3 8689 latest/stable canonical✓ core,désactivé
core 16-2.44.1 8935 latest/stable canonical✓ core
core18 20200311 1705 latest/stable canonical✓ base
core18 20200124 1668 latest/stable canonical✓ base,désactivé
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable/… canonical✓ -
gnome-calculator 3.34.1+git4.c387feb0 704 latest/stable/… canonical✓ -
gnome-calculator 3.34.1+git1.d34dc842 544 latest/stable/… canonical✓ désactivé
gnome-characters v3.32.1+git4.e06f0b2 495 latest/stable/… canonical✓ -
gnome-characters v3.32.1+git3.b9120df 399 latest/stable/… canonical✓ désactivé
gnome-logs 3.34.0 93 latest/stable/… canonical✓ -
gnome-logs 3.34.0 81 latest/stable/… canonical✓ désactivé
gnome-system-monitor 3.32.0-27-g32ed970e06 135 latest/stable/… canonical✓ -
gnome-system-monitor 3.32.1-3-g0ea89b4922 127 latest/stable/… canonical✓ désactivé
gtk-common-themes 0.1-28-g1503258 1440 latest/stable/… canonical✓ désactivé
gtk-common-themes 0.1-29-g45e78c5 1474 latest/stable/… canonical✓ -
Il y a juste ce qui est installé par défaut. Je passe généralement par le terminal et la commande apt install qui ne prend pas "les paquets instantanés" (enfin il me semble) .
Dans l'ordre :
J'ai viré ceux désactivés (ancienne révision)
snap list --all | awk '/désactivé/{print $1, $3}' |while read snapname revision; do echo $snapname $revision; sudo snap remove "$snapname" --revision="$revision"; done
Puis ensuite tout le reste :
sudo snap remove --purge gnome-3-28-1804 gnome-calculator gnome-characters gnome-logs gnome-system-monitor gtk-common-themes
Et enfin :
sudo rm -rf /var/cache/snapd/ && sudo apt autoremove --purge snapd && sudo rm -fr ~/snap
Dans le doute j'ai fais ensuite :
sudo apt install -f
Si besoin, ne pas oublier de ré-installer les paquets. Exemple dans mon cas :
sudo apt install gnome-calculator gnome-characters gnome-logs gnome-system-monitor
-
Et bim ! Apparemment à la sortie de Ubuntu 20.04, Snap store remplace Ubuntu software. les snap deviennent prioritaires sur les "paquets Apt" à moins de passer explicitement la commande Apt install dans un terminal. Ou alors j'ai pas tout compris ?
-
Il y a du positif et du négatif.
Positif : Il n'y a plus aucune application Snap pré-installée dans Ubuntu (pour ceux qui font une clean install, dans le cadre d'une mise à jour on garde les Snap déjà installées)
Négatif : La logithèque priorise les Snap sur les paquets des dépôts (les .deb téléchargés sur les dépôts Focal Fossa). Il faut donc faire attention de choisir le second choix quand on cherche un application (et elles sont nombreuses) à être présent au format snap et dans les dépôts classiques.
Les applications snap sont :
- Plus lente au démarrage
- Pas toujours localisées en Français contrairement à l'équivalent dans les dépôts
- Peuvent avoir des fonctionnalités avancées bloqués par le fait de se retrouver dans un snap (cas de LibreOffice dans un SNAP, mais aussi de nombreux logiciels un peu complexes qui font appels à des dépendances / extensions)
- L'interface utilisateur de l'application peut être moins bien intégrée avec Gnome que l'équivalent dans les dépôts
L'avantage des snap est par contre :
- Mise à jour vers la version majeur suivante automatique
- Facilité d’installation (j'ai eu besoin de Skype, j'ai vraiment apprécié le snap)
- Plus de problèmes liés aux PPA rajoutés, lors des mises à jour
- Plus de sécurité / insolation des applications
- Possibilité d'avoir différentes version de l’application installée : channel stable / channel candidate / channel beta / channel edge (ex: sudo snap install --channel=beta vlc)
-
J'ai fais une mise à jour Ubuntu 19.10 vers Ubuntu 20.04.
Au final peu de choses changent dans les SNAP :
Ubuntu 19.10 :
$ snap list
Nom Version Révision Suivi Éditeur Notes
chromium 81.0.4044.122 1119 latest/stable canonical✓ -
core 16-2.44.3 9066 latest/stable canonical✓ core
core18 20200311 1705 latest/stable canonical✓ base
gnome-3-26-1604 3.26.0.20191114 98 latest/stable/… canonical✓ -
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable canonical✓ -
gnome-calculator 3.34.1+git4.c387feb0 704 latest/stable/… canonical✓ -
gnome-characters v3.32.1+git4.e06f0b2 495 latest/stable/… canonical✓ -
gnome-logs 3.34.0 93 latest/stable/… canonical✓ -
gnome-system-monitor 3.32.0-27-g32ed970e06 135 latest/stable/… canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
Ubuntu 20.04 :
$ snap list
Nom Version Révision Suivi Éditeur Notes
chromium 81.0.4044.122 1119 latest/stable canonical✓ -
core 16-2.44.3 9066 latest/stable canonical✓ core
core18 20200311 1705 latest/stable canonical✓ base
gnome-3-26-1604 3.26.0.20191114 98 latest/stable/… canonical✓ -
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable canonical✓ -
gnome-3-34-1804 0+git.2c86692 27 latest/stable canonical✓ -
gnome-calculator 3.36.0+git4.51b0dc05 730 latest/stable/… canonical✓ -
gnome-characters v3.32.1+git4.e06f0b2 495 latest/stable/… canonical✓ -
gnome-logs 3.34.0 93 latest/stable/… canonical✓ -
gnome-system-monitor 3.32.0-27-g32ed970e06 135 latest/stable/… canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
snap-store 3.36.0-74-ga164ec9 433 latest/stable/… canonical✓ -
On note une mise à jour : gnome-calculator passe de la version 3.34.1 à la version 3.36
Deux nouveaux snap sont installés :
- gnome-3-34-1804 (alors que Ubuntu 20.04 utilise Gnome 3.36)
- snap-store
Un snap intégrant les bibliothèques en dépendance à quoi sert gnome-3-26 (version Gnome d'Ubuntu 17.10) / gnome-3-28 (version Gnome d'Ubuntu 18.04) / gnome-3-34-1804 (version Gnome d'Ubuntu 19.10) ?
-
Comparatif intéressant : Linuxtricks tests en parallèle deux VM Ubuntu 20.04.
- La première VM est équipée avec tous les logiciels en version Snap (le Firefox / Thunderbird / LibreOffice de base ont été désinstallé pour mettre la version deb)
- La seconde VM est équipée des mêmes logiciels mais en version deb. Si le logiciel n'était pas proposé par le store, il est récupéré sur le site de l'éditeur ou pour Chromium sur les dépôts de Debian (Chromium n'existe plus qu'en version snap). Le daemon snap a été désinstallé.
Conclusion :
RAM : un peu plus de ram consommée au lancement d'Ubuntu, probablement lié au daemon Snap. Une fois de nombreuses application lancées, on voit que Snap ne consomme pas plus de mémoire (on reste avec un écart stable de 100 à 150 Mo consommé en plus par la machine avec de nombreuses snap. Cet écart reste stable à vide ou en lançant de nombreuses applications simultanémenent).
Vitesse de lancement : Les snap sont plus lente à lancer que les deb en moyenne (cela varie selon le logiciel, certains sont aussi rapide à se lancer en snap vs deb alors que d'autres sont nettement plus lent en snap)
Regarder à partir de la 13ème minute :
https://www.youtube.com/watch?v=_xxnpvYgONQ
Tuto pour désactiver SNAP sur Ubuntu 20.04 : https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-04/
-
Finalement ça me rassure, je me sens moins seul sur l'avis que j'ai des Snap sur Ubuntu. Aucun intérêt pour la majorité des gens. Du coup, je comprends encore moins ce choix. Ceux en ayant besoin l'aurait installé sans mal tout en gardant les deb pour 85-90% des utilisateurs.
Édit : au passage beau travail pour ton topic de 2018 ;)
-
Aucun intérêt pour la majorité des gens
L’intérêt de ces formats c'est plutôt pour les développeurs et éviter les conflits de version des dépendances.
Mais Snap c'est clairement trop "propriétaire" (trop Ubuntu quoi), sans consensus dans la communauté Linux. Son adoption se fait a coup de marketing et pression de Canonical et pas par 'acceptation et intérêt' de la communauté parce que la techno est bonne.
L'objectif final pour Canonical est surtout de fournir un "store' (snapcraft) pour espérer reproduire le contrôle ,'lock-in' et centralisation comme les stores d'Android & d'iOS.
-
Snap et/ou Flatpak, c'est clairement l'avenir en terme de sécurité, gestion fine des droits d’accès, mise à jour et gestion des dépendances.
Cela permet de dissocier le système d'exploitation des applications utilisées.
Sur Andorid ou iOS toutes les applications que tu utilises sont dans un équivalent de Snap : quelques soit la version de ton système, tu as la même application, mise à jour simplement, avec possibilité de bloquer certains accès et sans problème de dépendance.
Il faut bien reconnaître qu'on n'est pas encore arrivé au même niveau de maturité.
-
Snap et/ou Flatpak, c'est clairement l'avenir en terme de sécurité, gestion fine des droits d’accès, mise à jour et gestion des dépendances.
Cela permet de dissocier le système d'exploitation des applications utilisées.
Sur Andorid ou iOS toutes les applications que tu utilises sont dans un équivalent de Snap : quelques soit la version de ton système, tu as la même application, mise à jour simplement, avec possibilité de bloquer certains accès et sans problème de dépendance.
Il faut bien reconnaître qu'on n'est pas encore arrivé au même niveau de maturité.
Apres il ne faut pas oublié la 'taille' et les moyens de Canonical:
Canonical: 500 employés, $120 millions de CA 2018
Red Hat : 13k employés, $3.4 milliards de CA 2018 et depuis racheté par IBM ($80+ milliards de CA, 350k employés)
Ubuntu a beau être 'populaire' c'est ridicule en terme de business donc de moyen financiers. Red Hat soutient Flatpak et pas Snap.
-
Personnellement je n'y vois que du bon pour le moment.
La consommation de RAM en ou le fait de se retrouver avec des doublons de dépendances pour chaque applis c'est insignifiant. On a de la RAM et du stockage à foison pour par cher.
Que ce soit les snaps ou les flatpacks qui s'imposent, peu importe, pour moi utilisateur j'ai juste la garantie d'avoir une application qui marche sans me casser la tête et ça c'est génial !
-
Le fait que cela soit plus lent (significativement pour de petits programmes comme la calculatrice) à se lancer est quand même problématique.
- Canonical à développé Snap
- Red Hat à annoncé un peu plus tard Flatpak
Flatpak est plus ouvert que Snap, mais Flatpak est plus limité (Sans oublier Appimage qui est un peu différent, mais souffre d'absence de mise à jour centralisée).
A terme il est probable qu'un seul reste. Peu de chance que Appimage l'emporte, mais entre Snap et Flatpack, c'est la guerre pour gagner les part de marché et attirer des gros contributeurs.
-
Si Ubuntu 18.04 était livré de base avec quelques application au formant snap comme la calculatrice ou le moniteur système (ce n'est plus le cas d'Ubuntu 20.04), quand on réalisai tune mise à jour vers Ubuntu 18.04 (donc depuis Ubuntu 16.04 ou Ubuntu 17.10) aucun snap n'était installé et snap list était complètement vide (même pas le snapd ou le "core")
Lors d'une mise à jour d'un Ubuntu 18.04 sans aucun snap vers Ubuntu 20.04, les snap suivants sont installés :
$ snap list
Nom Version Révision Suivi Éditeur Notes
core18 20200427 1754 latest/stable canonical✓ base
gnome-3-34-1804 0+git.3009fc7 33 latest/stable/… canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
snap-store 3.36.0-80-g208fd61 454 latest/stable/… canonical✓ -
snapd 2.44.3 7264 latest/stable canonical✓ snapd
$ snap list --all
Nom Version Révision Suivi Éditeur Notes
core18 20200427 1754 latest/stable canonical✓ base
gnome-3-34-1804 0+git.3009fc7 33 latest/stable/… canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
snap-store 3.36.0-80-g208fd61 454 latest/stable/… canonical✓ -
snapd 2.44.3 7264 latest/stable canonical✓ snapd
Quand se fait l'installation ?
A la fin de la mise à jour, quand tout est terminé et qu'il ne reste plus qu'a supprimer les paquets devenus inutiles.
La barre d'avancement revient au début et il y a la mention que les snap sont en cours d'installation (c'est particulièrement lent, j'imagine que les serveurs avaient un peu de mal car j’étais en FTTH 300 Mb/s)
(https://lafibre.info/testdebit/ubuntu/202005_snap_mise_a_jour_vers_ubuntu2004_1.png)
Ce que je n’apprécie pas, outre le fait que c'est fait discrètement sans barre d'avancement, c'est que le terminal ne marque rien.
Les installations se font, mais le terminal qui est pourtant verbeux lors de la mise à jour des paquets .deb est là compétemment silencieux.
(https://lafibre.info/testdebit/ubuntu/202005_snap_mise_a_jour_vers_ubuntu2004_2.png)
(https://lafibre.info/testdebit/ubuntu/202005_snap_mise_a_jour_vers_ubuntu2004_3.png)
-
Mint n'installera pas Snapd automatiquement avec un autre logiciel (comme Chromium, qui sera compilé par les équipes de Mint et plus récupéré d'Ubuntu comme c'est le cas jusqu'à présent).
L’équipe se montre acerbe au sujet de l’Ubuntu Store : « Les applications dans cette boutique ne peuvent pas être patchées ou épinglées. Vous ne pouvez pas les auditer, les modifier ou même faire pointer snap vers une autre boutique ».
Puis vient le coup de grâce : « Vous avez autant de pouvoir que si vous utilisiez du logiciel propriétaire, c’est-à-dire aucun. C’est en fait similaire à une solution commerciale propriétaire, mais avec deux différences majeures : elle s’exécute en root et s’installe seule sans rien vous demander ».
Source: NextINpact (https://www.nextinpact.com/brief/linux-mint-dit---non---a-l-installation-automatique-de-snapd-12610.htm), le 3 juin 2020.
-
L'article est très intéressant et effectivement ça fait réfléchir
-
Voilà, c'est exactement cela !
Je me répète mais il aurait été plus judicieux de séparer sous Bionic les snap de la logithèque et aujourd'hui, plutôt que de devoir supprimer snapd, son store, etc... de laisser le choix à l'utilisateur de l'installer par lui même.
J'avais pas un très bon avis concernant mint, mauvaise expérience passé, mais je vais peut être réfléchir à y passer ou retourner sous Debian (voir même revenir sous Mandriva, enfin son successeur).
-
A part Chromium et la logithèque Ubuntu, tous les logiciels sont disponibles en .deb dans Ubuntu 20.04.
Les Snap ou les Flatpak sont par contre indispensable pour :
- Mise à jour vers la version majeur suivante automatique (plus besoin de rajouter des PPA qui risque d’entraîner des conflits)
- Facilité d’installation de logiciels non disponible dans les dépôts (exemple: Microsoft Skype)
- Sécurité: Insolation des applications
- Possibilité d'avoir différentes version de l’application installée : channel stable / channel candidate / channel beta / channel edge
Maintenant je pense que le fait de ne pas pouvoir utiliser d'autres boutiques de snap que la boutique officielle est un vrai problème (Flatpack permet d'utiliser plusieurs boutiques).
Autre problème avec les snap : l’accès au code source et la certification des développeurs afin d'être sur du code source.
-
Je ne nie pas certains avantages (bien que discutable sur certains points) mais pas au point de remplacer tout bonnement la logithèque "des .deb". De plus, 36% des utilisateurs qui ont participé au sondage (voir le billet (https://ubuntu.com/blog/ubuntu-20-04-survey-results)sur les résultats), ont un avis positif. Ce qui est loin de représenter la majorité.
Ce qui amène à devoir virer ça pour ceux qui n'en veulent pas (voir la procédure (https://lafibre.info/tutoriels-linux/snap-flatpak/msg749367/#msg749367), toujours valable), plutôt que de laisser ceux qui en ont l'utilité ou le besoin d'installer le "snap store" en une ligne de commande, les dépendances étant installés avec.
Je pense plutôt à un clin d'oeil à certains développeurs et au passage espérer attirer des utilisateurs réfractaires ou bloqués sous windows.
-
L'isolement des SNAP, c'est sympathique pour la sécurité, mais quand je cherche à partager un document avec Skype, il me propose les fichiers du SNAP :
(https://lafibre.info/testdebit/ubuntu/202006_skype_snap.png)
Si je force via arborescence pour trouver mon document (qui n'est pas dans arborescence du SNAP), il plante :(
-
J'ai exactement le même problème... enfin en partie.
J'ai voulu installer vidcutter pour me couper les pubs d'un enregistrement TNT, et manque de bol, je n'ai accès qu'à mon home... si j'essaie d'aller sur mes autres partitions, j'ai un beau acces denied.
Après recherche, il exsite une solution de contournement qui consite à remonter la partition dans le home. Par contre ça ne fonctionne que si les droits sont ok, avec une partiton NTFS avec comme propriétaire vu comme root, ça ne marche pas...
-
Je ne connaisais pas pour découper les vidéos.
Tu as aussi avidemux, cf https://doc.ubuntu-fr.org/avidemux
J'utilise la version Appimage aucun problème si c'est l'intégration au menu qui n'est pas simple, comme tous les Appimage.
-
En fait j'ai pris le snap car il n'est pas encore compilé en deb pour la 20.04
Je suppose qu'avec la version classique tout doit bien fonctionner.
Et je n'avais pas fini avec la liste des bugs : pas de son et l'export ne se termine jamais (il indique 50% mais le fichier est bien généré)...
-
Je suis déçus de nombreux SNAP, qui comportent des bugs pour l’accès à des fichiers ou l'enregistrement de fichiers.
Exemple avec Skype, le SNAP est crée directement par l'équipe de Microsoft, mais il y a des pb pour l’accès aux fichiers :
- Interface en Anglais
- Quand on navigue pour ouvrir un fichier, cela ne marche pas
- Bugs pour l'enregistrement
(https://lafibre.info/testdebit/ubuntu/202010_skype_snap.png)
Skype en version .deb n'a pas ces problématiques :
(https://lafibre.info/testdebit/ubuntu/202010_skype_deb.png)
-
Ce soir je m'attaque à Flatpak.
J'ai rencontré sur mon PC Ubuntu 20.10 un problème de fraîcheur du catalogue flathub.
Exemple avec LibreOffice, au lieu de la version 7.1.1.2 de mars 2021, il me propose la version 6.4.3.2 d'avril 2020.
(https://lafibre.info/testdebit/ubuntu/202103_flatpak_ubuntu_2010_1.png)
(capture d'écran prise le 7 mars 2021)
Tous les logiciels sont dans de veilles versions. Le catalogue ne s'est pas mis à jour depuis mes tests il y a un bon moment.
Je vois que la version de Flatpack, installée à partir des déports d'Ubuntu 20.10 n'est pas la dernière.
Je rajoute le PPA officiel en suivant le tutoriel sur https://flatpak.org/setup/Ubuntu/
Le PPA fonctionne bien sur des PC Ubuntu 18.04 et Ubuntu 20.04 (et la dernière version de flatpak est bien installée) mais, il n'ont rien prévu pour Ubuntu 20.10 !
(https://lafibre.info/testdebit/ubuntu/202103_flatpak_ubuntu_2010_2.png)
(https://lafibre.info/testdebit/ubuntu/202103_flatpak_ubuntu_2010_3.png)
Pour avoir le catalogue flathub à jour, j'ai supprimé le cache, mais je trouve étonnant de ne pas avoir de PPA pour la dernière version d'Ubuntu.
-
Autre problème, sur les PC i386.
Il est difficile de savoir les logiciels proposés par Snap ou Flatpak sans installer le logiciel.
Je ne vois rien sur le catalogue en ligne qui indique l'architecture proposée.
Ok i386, c'est un peu vieux comme architecture, mais pour Arm, c'est le grand mystère...
Snap : Presque aucun logiciel n'est proposé à ceux qui sont sur une version 32bits de Linux
Flatpak : Il y a de nombreux logiciels (la moitié du catalogue ? je n'ai pas fait de listing), mais aucun logiciel récent !
J'ai l'impression qu'il n'y a plus de mise à jour pour Flatpak pour l'architecture i386, mais je ne vois aucune annonce.
Voici une recherche de quelques logiciels avec Flatpak sur Ubuntu 18.04 en architecture 32 bits (i386) :
(https://lafibre.info/testdebit/ubuntu/202103_flatpack_ubuntu1804_i386.png)
La même chose avec Ubuntu 20.10 en architecture 64 bits (AMD64) :
(https://lafibre.info/testdebit/ubuntu/202103_flatpack_ubuntu2010_amd64.png)
- LibreOffice : 6.3.2 en 32bits contre 7.1.1 en 64bits
- Logiciels Gnome : 3.32 en 32bits contre 3.38 en 64bits
- Filezilla : 3.44 en 32bits contre 3.52 en 64bits
- KWordQuiz (KDE) : pas de version indiqué en 32bits contre 20.12 en 64bits
- Firefox : inexistant en 32 bits contre 86.0 en 64 bits
- Chromium : inexistant en 32 bits contre 89.0 en 64 bits
- Bomber : inexistant en 32 bits contre 20.12 en 64 bits
- Granatier : inexistant en 32 bits contre 1.4.20123 en 64 bits
Bref, c'est étonnant d'avoir lancé Flatpak en i386 si c'est pour ne proposer que de vieux logiciels sans mise à jour de sécurité.
-
Bref, c'est étonnant d'avoir lancé Flatpak en i386 si c'est pour ne proposer que de vieux logiciels sans mise à jour de sécurité.[/size]
ça fait des années que j'entends parler de FlatPak, ils ont peut être abandonné i386 "seulement" en 2020 et ont proposé des logiciels en i386 dessus durant des (3 à 5) années non ?
D'ailleurs ubuntu a abandonné le i386, donc c'est logique de l'abandonner aussi non ?
-
Je ne reproche pas l'abandon du x86 32bits (et je ne pense pas que ce soit le cas, les dernière version de Snap et Flatpak sont en version 32bits), mais le problème c'est que presque plus aucun logiciel est publié en 32 bits dans leur boutique logicielle sans avoir fait d'annonce et qu'il ne soit pas possible de savoir dans quelle architecture c'est disponible ce qui est problématique pour ceux qui sont sur Arm (Raspberry Pi 4 par exemple)
Exemple avec Firefox : Comment savoir les architectures supportées ? (le x86 32 bits n'est pas supporté pour info pour Firefox Snap comme Firefox Flatpak)
- https://snapcraft.io/firefox fonctionne sur Raspberry Pi 4 ?
- https://flathub.org/apps/details/org.mozilla.firefox fonctionne sur Raspberry Pi 4 ?
Certaines distributions continue à prendre en charge le 32bits i386 : Mageia 8 sorite le 28 février 2021, Debian 11 qui va sortir dans quelques mois,...
D'autres comme Canonical / Fedora ont arrêtée le support pour les OS sortie en 2019.
Dernière versions a prendre en charge les systèmes 32 bits x86 (i386) :
- Ubuntu 18.10, sortie le 18 octobre 2018 et supporté jusqu'au 18 juillet 2019.
- Ubuntu 18.04 LTS, sorite le 26 mai 2018 et supporté jusqu'en avril 2023.
- Fedora 30, sortie le 7 mai 2019 et supporté jusqu'au 26 mai 2020.
- RHEL 7 / CentOS 7, sortie en 2014 et supporté jusqu’au 30 juin 2024 (RHEL 8 / CentOS 8 est sortie en 2019 sans le support x86).
-
Flatpak a 3 runtimes possible: Freedesktop, GNOME and KDE
Ces 3 runtimes ne supportant plus i386 dans leurs versions actuelles, les 'buildbots' de flatpak ne générèrent plus de i386 si un des 3 rutimes est référencé dans sa version actuelle (ou version a partie de la quelle i386 n'est plus supporté).
A ce jour il reste donc: x86_64, arm and aarch64
si l'app fait référence a une version de runtime supportant i386 alors les bots de flatpak produiront toujours l'image pour i386.
les versions qui font qu'i386 n'est plus dispo:
FreeDesktop SDK 19.08 has deprecated i386, thus GNOME SDK 3.24 and KDE 5.13 also doesn't have it. KDE SDK/Platform 5.12 is said to be LTS, but FDO 18.08 (which 5.12 builds upon) will be supported for one more year.
ps: i386(i686) représente 2.5% du parc actuel: https://github.com/linuxhw/Trends#arch
-
Donc, à part le cas particulier d'i386 dont les runtimes modernes sont dépréciées, les paquets sont tous compilés dans les 3 architectures x86_64, arm et aarch64 ?
L'i386 est bien mort*, mais j'avais peur que le même pb se produise avec arm ou aarch64.
* J'ai l'un dernier processeur Core qui ne gère que le 32bits dans le PC de mon fils (j'exclue les Atom qui ont mis plus de temps à passer au 64bits) et je confirme que c'est très limité, Google maps est très lent (il aime bien explorer les routes avec Street view. Seul les logiciels pédagogiques sont ok (certaines vidéos H.264 720p arrivent à passer, mais c'est limite). Je me demande quand Windows 10 va arrêter de supporter la version 32bits. Il faudrait une mise à jour automatique vers le 64bits, vu que presque tous les PC qui font tourner Windows 10 32bits sont en mesure de faire du 64bits.
-
Je ne sais pas si une maj auto de windows 10 32 bits vers 64 est souhaitable.
De mémoire la dernière fois que j'avais comparé les deux (c'était il y a quelques années) la différence de consommation de ram juste au démarrage était énorme (quasi du simple au double).
sur les petite config ça pourrait poser problème.
sans parler du fait de devoir quasi refaire intégralement le système et les risques qu'une migration comme ça se passe moyennement bien.
-
Voici les paquets snap installés par défaut avec Ubuntu 21.04 fraîchement installé sur un nouveau PC :
$ snap list
Nom Version Révision Suivi Éditeur Notes
core18 20210309 1997 latest/stable canonical✓ base
gnome-3-34-1804 0+git.3556cb3 66 latest/stable/… canonical✓ -
gtk-common-themes 0.1-50-gf7627e4 1514 latest/stable/… canonical✓ -
snap-store 3.38.0-59-g494f078 518 latest/stable/… canonical✓ -
snapd 2.49.2 11588 latest/stable canonical✓ snapd
$ snap list --all
Nom Version Révision Suivi Éditeur Notes
core18 20210309 1997 latest/stable canonical✓ base
gnome-3-34-1804 0+git.3556cb3 66 latest/stable/… canonical✓ -
gtk-common-themes 0.1-50-gf7627e4 1514 latest/stable/… canonical✓ -
snap-store 3.38.0-59-g494f078 518 latest/stable/… canonical✓ -
snapd 2.49.2 11588 latest/stable canonical✓ snapd
-
J'ai testé sur une Ubuntu 18.04 qui était resté éteinte 20 mois (depuis juillet 2019), voici ce que cela donne juste avant et juste après la mise à jour :
(https://lafibre.info/testdebit/ubuntu/202104_ubuntu1804_mise_a_jour_snap_20mois.png)
Lien entre les versions de Gnome et Ubuntu :
- GNOME 3.28 => Ubuntu 18.04 LTS
- GNOME 3.30 => Ubuntu 18.10
- GNOME 3.32 => Ubuntu 19.04
- GNOME 3.34 => Ubuntu 19.10
- GNOME 3.36 => Ubuntu 20.04 LTS
- GNOME 3.38 => Ubuntu 20.10
Ubuntu 21.04 est livré avec un mixte de GNOME 3.38 et GNOME 40 (l'interface est GNOME 3.38, mais de nombreuses applications, comme par exemple gnome-system-monitor est en version 40, qui intègre des nouveautés importantes)
La version SNAP de gnome-system-monitor n'a pas encore été mis à jour dans la version issue de Gnome 40.
-
J'ai réalisé une clean install d'Ubuntu 18.04.5. C'est une iso qui date de juillet 2020.
J'ai coché la case pour faire les mises à jour dés l'installation et la machine a toujours été connecté au réseau.
En fait les Snap qui sont installés par défaut avec Ubuntu 18.04 (Calculatrice, Moniteur Système, Journaux et Caractères) le sont après le premier reboot. Le snap list lancé immédiatement après le démarrage est vide.
Et ce qui est étonnant, c'est qu'il n'installe pas les versions disponibles par le réseau, mais les versions livrées avec l'ISO.
Dans la capture d'écran ci-dessous :
- 1er snap list : après avoir attendu quelques minutes après l'installation. Ce sont des veilles versions.
- 2ème snap list : j'ai installé Chromium Snap pour voir si cela allait lancer une mise à jour, mais non. La dernière version de Chromium est installée, sans mise à jour des autres paquets. A noter que CHromium fait télécharger Gnome 3.28, c'est étonnant qu'il se base sur une version qui commence à dater. Cela semble le cas y compris avec Ubuntu 21.04 où Chromium lance le téléchargement de paquet
Snap gnome-3-28-1804 sous Ubuntu 21.04)
- snap refresh --list est a commande pour afficher les paquets qui peuvent être mis à jour. Habituellement cela répond "Tous les paquets Snaps sont à jour.", mais là tous les paquets pré-installés au 1er démarrage d'Ubuntu 18.04 doivent être mis à jour.
- snap refresh force une mise à jour immédiatement (par défaut, c'est appelé toutes les 4h donc cela se fait très régulièrement)
(https://lafibre.info/testdebit/ubuntu/202105_snap_ubuntu18045_clean_install.png)
-
Ont sont les données des Snap ?
Lorsqu'un utilisateur installe un snap à partir du Snap Store, les événements suivants se produisent :
- Les services snapd téléchargent le snap – une archive squashFS compressée avec un suffixe .snap.
- Le snap est décompressé et monté en tant que système de fichiers en lecture seule sous /snap.
Un système de fichiers en lecture seule est insuffisant pour fournir une expérience significative et persistante entre les lancements d'applications, c'est pourquoi les snaps ont également des parties inscriptibles :
- SNAP COMMON – Reflété dans la variable d'environnement SNAP_COMMON, ce répertoire est détenu et accessible en écriture par root, et il est utilisé pour stocker des données communes à plusieurs révisions du snap (par exemple : révision 6, révision 7, etc.).
- SNAP DATA - Reflété dans la variable d'environnement SNAP_DATA, il est également utilisé pour stocker des données, principalement des informations utilisées par l'application et les services d'arrière-plan, pour la journalisation et d'autres tâches qui nécessitent une persistance entre les lancements instantanés. Ce répertoire est sauvegardé puis restauré lors de l'exécution d'une mise à jour instantanée (actualisation) ou d'une opération de restauration. En revanche, SNAP_COMMON ne l'est pas.
Données d'utilisateur
Tout comme les données système, les snaps peuvent contenir des données utilisateur. D'une manière similaire aux variables d'environnement COMMON et DATA détenues et accessibles en écriture par root, des répertoires spécifiques à l'utilisateur sont également disponibles. Cependant, les répertoires spécifiques à l'utilisateur ne seront pas créés tant que l'utilisateur spécifique n'aura pas exécuté un snap pour la première fois.
- SNAP_USER_COMMON – Ce répertoire correspond aux données utilisateur communes aux révisions d'un snap. Un chemin typique serait quelque chose comme : /home/"username"/snap/"snap name"/common. Il n'est ni sauvegardé ni restauré lors des opérations d'accrochage.
- SNAP_USER_DATA - Ce répertoire contiendra toutes les données utilisateur que le snap écrit dans sa propre "home". Cela contraste avec ce que l'utilisateur de Linux considérerait comme sa "home". Il est important de noter cette distinction, car elle peut être utile, et même importante lorsque les utilisateurs décident d'effectuer des opérations de maintenance avec leurs snaps (comme le démontage). Un chemin typique serait : /home/”username”/snap/”snap name”/”revision”. Par défaut, chaque snap utilisera un lien symbolique current , pointant vers la dernière révision disponible.
~/snap/notepad-plus-plus$ ls -la
total 20
drwxr-xr-x 5 igor igor 4096 28 avril 16:13 .
drwxr-xr-x 133 igor igor 4096 26 mai 15:29 ..
drwxr-xr-x 5 igor igor 4096 26 février 14:45 258
drwxr-xr-x 5 igor igor 4096 28 avril 16:13 260
drwxr-xr- x 6 igor igor 4096 12 janvier 14:43 commun
lrwxrwxrwx 1 igor igor 3 28 avril 16:13 courant -> 260
Détails importants concernant l'accès aux données utilisateur
Il existe plusieurs exceptions notables à l'accès aux données utilisateur qui ne ressortent pas immédiatement de l'utilisation des répertoires COMMON et DATA.
- Par défaut, les snaps sont strictement confinés. Un snap strictement confiné ne peut accéder à aucune ressource système, comme la "home", le réseau, les périphériques USB, l'appareil photo, l'audio, etc. Les éditeurs qui souhaitent accorder à leurs snaps l'accès à des ressources spécifiques doivent utiliser des interfaces , qui permettent ensuite un accès granulaire à ces ressources. L'une des ressources disponibles est le répertoire personnel de l'utilisateur.
- Un snap avec une interface d'accueil déclarée aura alors accès au répertoire d'accueil de l'utilisateur, mais uniquement aux fichiers et dossiers normaux. Veuillez noter que les fichiers cachés ne seront pas accessibles par défaut et qu'ils nécessitent des dérogations de sécurité spécifiques pour ce snap dans le Snap Store. Si vous êtes un développeur ou un éditeur, vous pouvez demander les chemins supplémentaires pour votre snap dans une demande de forum.
- L'interface home est auto-connectée sur les systèmes classiques. Il n'est pas connecté automatiquement sur Ubuntu Core.
- Les snaps sans l'interface home déclarée et/ou connectée ne peuvent pas accéder au disque. Le répertoire SNAP_USER_DATA sera toujours créé et existera dans le répertoire personnel de l'utilisateur. Cependant, il ne contiendra aucun fichier.
Que se passe-t-il lorsque vous supprimez un snap ?
Si vous décidez de supprimer un composant logiciel enfichable de votre système, les événements suivants se produisent :
- Le snap sera démonté et ne sera plus affiché sous /snap.
- Les données sous /var/snap/"snap name"/ et /home/"username"/snap/ seront supprimées. Cependant, une copie sera conservée en tant qu'instantané pendant 30 jours (sauf sur les systèmes Ubuntu Core), vous permettant de restaurer les données ou de les récupérer manuellement au cas où vous en auriez besoin. L'emplacement des instantanés se trouve sous : /var/lib/snapd/snapshots/.
Vous pouvez utiliser la fonctionnalité intégrée de gestion des instantanés (https://snapcraft.io/docs/snapshots?_ga=2.186440745.1870970967.1624262699-648315293.1620133525) snapd pour restaurer les données ou décompresser les archives et copier uniquement les données que vous jugez nécessaires. Si vous disposez des autorisations appropriées, vous pouvez également créer votre propre routine de sauvegarde, qui copie les données importantes telles que les bases de données d'application, les configurations ou le contenu similaire vers un chemin de sauvegarde.
Pour supprimer un instantané sans générer d'instantané, utilisez l'argument supplémentaire « –purge » :
$ sudo snap remove vlc --purge
vlc supprimé
Autres emplacements
Il existe plusieurs autres répertoires que vous devez connaître :
- /var/lib/snapd/cache – Cache de travail, pour minimiser la taille du téléchargement et accélérer les actualisations.
- /var/lib/snapd/snaps – Contient toutes les versions de snaps installées sur votre système.
Résumé
La gestion des données Snap est différente des conventions Linux classiques. À cette fin, les développeurs et les utilisateurs doivent faire attention aux nuances les plus fines, afin qu'ils puissent obtenir la meilleure expérience. Les développeurs doivent s'assurer qu'ils utilisent correctement les chemins nécessaires et disponibles, et créer leurs snaps afin qu'ils stockent les informations importantes dans des emplacements qui seront sauvegardés lors des opérations de maintenance. Les utilisateurs doivent noter la différence entre leur "home" Linux classique et leur "home" instantanée.
Source : Ubuntu.com (https://ubuntu.com/blog/hey-snap-wheres-my-data) le 28 mai 2021 par Igor Ljubuncic
-
Je ne sais pas quel est la cause, mais je constate que Chromium n'a pas été mis à jour version 92 sur Ubuntu 18.04, la dernière version à utiliser la version DEB de Chromium, sur les autres version d'Ubuntu, c'est la version Snap qui est utilisée (la version snap est rapidement mis à jour).
Chrome 92 est sortie le 20 juillet.
Habituellement, Ubuntu es rapidement mis à jour dés qu'un logiciel a des failles de sécurité.
(https://lafibre.info/testdebit/ubuntu/202108_chromium_ubuntu1804.png)
Ubuntu envisage en effet de remplacer le paquet classique de Chromium par une « boite vide » qui renverrait alors vers le snap correspondant. On n'aurait donc plus le choix.
Bref, je vois bien arriver un Ubuntu sans aucune application .deb pré-installées et les applications snap qui sont les seules versions disponibles. Les paquets .deb traditionnels restant pour assurer la compatibilité avec des application qui n'existent pas dans Snap.
C'est fait :
Nous avons récemment annoncé la transition du paquet deb Chromium vers Snap, dans Ubuntu 19.10. Une telle transition n'est pas anodine et a suscité de nombreuses discussions constructives. Nous résumons donc ici pourquoi nous procédons ainsi, comment et dans quel délai.
Pourquoi
Chromium est un navigateur Web très populaire, l’équivalent totalement ouvert de Google Chrome. Sous Ubuntu, Chromium n’est pas le navigateur par défaut et le paquet réside dans la section "univers" de l’archive. Univers contient des progiciels gérés par la communauté. Malgré cela, l’équipe Ubuntu Desktop s’engage à conditionner et à maintenir Chromium car un nombre important d’utilisateurs y ont recours.
La maintenance d’une version unique de Chromium représente un investissement de temps considérable pour l’équipe de bureau Ubuntu qui travaille avec l’équipe de sécurité d’Ubuntu pour mettre à jour chaque mise à jour. Les équipes prenant en charge de nombreuses versions stables d'Ubuntu, la charge de travail est complexe.
La comparaison de cette charge de travail avec d'autres distributions Linux en rolling release omet la nuance de prendre en charge plusieurs versions de support à long terme (LTS) et non-LTS.
Google publie une nouvelle version majeure de Chromium toutes les six semaines, avec généralement plusieurs versions mineures permettant de remédier aux vulnérabilités en matière de sécurité. Chaque nouvelle version stable doit être créée pour chaque version d'Ubuntu prise en charge - 16.04, 18.04, 19.04 et les prochaines versions 19.10 - et pour toutes les architectures prises en charge (amd64, i386, armhf, arm64).
En outre, il peut être difficile de s'assurer que Chromium construit (et encore moins s'exécute) sur des versions plus anciennes telles que 16.04, car le projet en amont utilise souvent de nouvelles fonctionnalités du compilateur qui ne sont pas disponibles sur les versions précédentes.
En revanche, un paquet Snap ne doit être créée qu'une fois par architecture et sera exécutée sur tous les systèmes prenant en charge snapd. Cela couvre toutes les versions prises en charge d'Ubuntu, y compris 14.04 avec maintenance de sécurité étendue (ESM), ainsi que d'autres distributions telles que Debian, Fedora, Mint et Manjaro.
Bien que ce changement d’emballage pour Chromium puisse nous permettre de concentrer les ressources des développeurs ailleurs, l’emballage en un coup d’œil présente des avantages supplèmentaires. Les canaux dans le Snap Store permettent de publier facilement plusieurs versions de Chromium sous un seul nom. Les utilisateurs peuvent basculer entre les canaux pour tester différentes versions du navigateur. Snap Store met à jour les Snap automatiquement en arrière-plan, ce qui permet aux utilisateurs de s’assurer qu’ils exécutent des logiciels à jour sans avoir à gérer manuellement leurs mises à jour. Nous pouvons également publier rapidement des correctifs spécifiques via des branches du Snap Store, ce qui permet aux utilisateurs et aux développeurs de se remettre rapidement au courant des rapports de bogues. Enfin, la capture instantanée de chrome est strictement confinée, ce qui fournit des garanties de sécurité supplèmentaires aux utilisateurs.
En résumé: il existe plusieurs facteurs qui font de Chromium un bon candidat à la transition:
- Ce navigateur n’est pas le navigateur par défaut d’Ubuntu et a donc moins d’impact en raison de la taille réduite de sa base d’utilisateurs.
- Les snaps sont explicitement conçus pour supporter une fréquence élevée de mises à jour
- Le projet en amont a trois canaux de publication (stable, beta, dev) qui correspondent parfaitement aux canaux par défaut de snapd (stable, beta, edge). Cela permet aux utilisateurs de changer facilement de version de Chromium ou même d’avoir plusieurs versions installées en parallèle.
- L'application est strictement confinée, ce qui ajoute une couche de sécurité supplèmentaire au mécanisme de sand-boxing déjà robuste du navigateur.
Comment
La première Snap de Chromium a été crée il y a deux ans et nous avons parcouru un long chemin depuis. La version snap compte actuellement plus de 200 000 utilisateurs d'Ubuntu et plus de 30 autres distributions Linux. La version actuelle présente quelques problèmes mineurs sur lesquels nous travaillons, mais nous avons pensé qu’elle était suffisamment solide et mûre pour une transition. Nous sommes convaincus qu'il est temps de commencer la transition des utilisateurs de la version de développement (19.10) d'Ubuntu. Nous sommes impatients de recueillir des commentaires sur ce qui fonctionne et ce qui ne nous attend pas avant la prochaine version du support à long terme d’Ubuntu, la 20.04.
Avec Ubuntu 19.10, le package deb du navigateur chromium (et les packages associés) ont été transformés en un package de transition qui ne contient que des scripts d'encapsulation et un fichier de bureau pour la compatibilité en amont. Lors de la mise à niveau ou de l'installation du paquet deb sous 19.10, la capture sera téléchargée à partir du Snap Store et installée.
Un soin particulier a été pris pour ne pas interrompre les flux de travail existants et pour rendre la transition aussi transparente que possible:
- Lors de la première exécution de la capture, un profil utilisateur Chromium existant dans $ HOME / .config / chromium sera importé (à condition que l'espace disque soit suffisant).
- Les exécutables chrome-browser et chromedriver de / usr / bin / sont des wrappers qui appellent les exécutables de snap respectifs.
- chromedriver a été corrigé afin que les scripts de sélénium existants continuent à fonctionner sans modifications
- Si l'utilisateur a défini Chromium comme navigateur par défaut, le wrapper du navigateur chromium se chargera de le mettre à jour dans le snap Chromium.
- De même, les entrées épinglées existantes dans les lanceurs de postes de travail seront mises à jour pour pointer vers la version instantanée (mises en œuvre pour GNOME Shell et Unity uniquement pour l'instant, les contributions sont bienvenue pour le faire dans d'autres environnements de postes de travail).
- Le apport hook a été mis à jour pour inclure des informations pertinentes sur le snap et ses dépendances.
Quand
Si vous passez a Ubuntu 19.10, vous pouvez essayer Chromium en un clin d’œil et tester la transition à partir du paquet deb dès maintenant. Toutefois, vous n’avez pas besoin d’attendre la sortie du 17 octobre pour commencer à utiliser le logiciel instantané et à partager vos commentaires. Exécutez simplement les commandes suivantes pour être opérationnel:
snap install chromium
snap run chromium
Une fois la version Ubuntu 19.10 publiée, nous envisagerons d’étendre la transition à d’autres versions stables, à partir de 19.04. Cela ne se produira que lorsque tous les problèmes connus importants auront été résolus.
Nous apprécions tous les commentaires que nous avons envoyés au cours des derniers mois lors de l’annonce de ce projet. Honnêtement, nous pensons que la fourniture d’applications snap offre des avantages considérables aux développeurs et aux utilisateurs. Nous savons qu'il peut y avoir des difficultés lorsque nous travaillons pour l'avenir et continuerons d'écouter nos utilisateurs à mesure que nous planifions ces migrations.
Source : Blog Ubuntu (https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition), traduit de l'Anglais rapidement par moi-même.
-
Je suis mauvaise langue. Chromium 92 en version DEB a juste eu beaucoup de retard sur la version SNAP.
Il est disponible depuis le 19 août (en version 32 bits et 64bits), soit un mois de retard
=> https://ubuntu.lafibre.info/ubuntu/pool/universe/c/chromium-browser/?C=M;O=D
(https://lafibre.info/testdebit/ubuntu/202108_chromium92_ubuntu1804_maj.png)
(https://lafibre.info/testdebit/ubuntu/202108_chromium92_ubuntu1804.png)
-
A noter que l'outil neofetch sait maintenant compter les paquets DEB, mais aussi Flatpak et Snap (pas les Appimage qui n'ont pas besoin d'être installées)
Cela permet d'avoir une vue d'ensemble de son système.
sudo apt install neofetch pour l'installer
(https://lafibre.info/testdebit/ubuntu/202109_neofetch_ubuntu2104.png)
A noter qu'il me semble compter un snap de trop (j'ai 8 snap installé) :
$ flatpak list
Name Application ID Version Branch Installation
Element im.riot.Riot 1.8.2 stable system
Avidemux org.avidemux.Avidemux 2.7.8 stable system
Freedesktop Platform org.freedesktop.Platform 20.08.15 20.08 system
Mesa org.freedesktop.Platform.GL.default 21.1.7 20.08 system
Intel org.freedesktop.Platform.VAAPI.Intel 20.08 system
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 system
Yaru Gtk Theme org.gtk.Gtk3theme.Yaru 3.22 system
KDE Application Platform org.kde.Platform 5.15 system
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15 system
QtSNI org.kde.PlatformTheme.QtSNI 5.15 system
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15 system
$ snap list
Nom Version Révision Suivi Éditeur Notes
chromium 93.0.4577.82 1753 latest/stable canonical✓ -
core18 20210722 2128 latest/stable canonical✓ base
gnome-3-28-1804 3.28.0-19-g98f9e67.98f9e67 161 latest/stable canonical✓ -
gnome-3-34-1804 0+git.3556cb3 72 latest/stable/… canonical✓ -
gtk-common-themes 0.1-52-gb92ac40 1515 latest/stable/… canonical✓ -
skype 8.75.0.140 183 latest/stable skype✓ -
snap-store 3.38.0-64-g23c4c77 547 latest/stable/… canonical✓ -
snapd 2.51.4 12883 latest/stable canonical✓ snapd
Si on enlève les dépendances, j'ai 2 Flatpak installés :
- Element
- Avidemux
Et 3 Snap :
- Chromium
- Skype
- snap-store
-
Déplacement dans un sujet à part de Firefox Snap
=> Ubuntu: Firefox sera au format d’application Snap dans Ubuntu 21.10 (https://lafibre.info/tutoriels-linux/ubuntu-firefox-sera-au-format-dapplication-snap/)
-
Je note que Flatpak devrait décoller pour les applications grand public, c'est le format suggéré par Valve pour la Steam Deck (flathub est activé par défaut).
On peut toujours installer des paquets Archlinux, mais ceux-ci risquent d'être supprimés lors d'une màj.