Le changement sera invisible pour les utilisateurs, mais implique pour Mozilla plusieurs bénéfices. C’est en effet le père de Firefox qui a approché Canonical pour lui suggérer de laisser tomber le classique fichier DEB au profit de Snap.
Pourquoi ? Plusieurs raisons sont données : le fonctionnement identique sur tous les systèmes ayant snapd, la mise à jour rapide et simplifiée et un temps moindre passé sur la maintenance. Au vu de la situation complexe de Mozilla depuis un moment, on comprend que l’éditeur veuille se simplifier un peu la vie.
Ce changement sera effectif avec Ubuntu Desktop 21.10, que ce soit en installation neuve ou en mise à jour. Les variantes ne sont pas encore concernées, la version deb de Firefox sera maintenue pendant tout le cycle de vie de la 21.10. La transition devrait être achevée d’ici la 22.04, qui sera la nouvelle LTS.
Canonical explique dans un billet avoir beaucoup appris avec le passage de Chromium en snap, notamment en résolvant les problèmes initiaux de lancement plus lent. En fait, Canonical s’attend à ce que Firefox soit plus rapide en snap grâce à une chaine d’outils plus récente, basée sur Clang et Rust. Firefox sera en outre mieux protégé grâce à la sandbox des snap.
Précision importante, les utilisateurs n’auront pas obligation à se servir du snap. Firefox distribuera toujours les versions classiques pour systèmes i386 et amd64 depuis le site officiel. Le snap sera simplement la version fournie par défaut par le système et dans le Store d’Ubuntu.
Commentaires (39)
#1
Débat sur les avantages et inconvénients des snaps : je sors mon pop-corn 🍿
#2
Encore cette usine a gaz ….
SI je dois migrer sous linux ca sera pas sous ubuntu .
Peut être manjaro …
#2.1
Ou de passer à Pop_!OS de System76.
C’est comme Ubuntu, mais en bien mieux et sans snapd.
Bon, OK, eux, ils se basent sur Flatpak, mais c’est déjà plus rapide que snapd.
#3
snap c’est bien bouzin qui met plus de 10 secondes à lancer la calculatrice, quand l’OS est installé sur un SSD ?
Ça promet pour Firefox…
#3.1
Oui, sans parler des mises à jour de sécurité des dépendences, qui requièrent de télécharger des centaines de Mo (quand elles ne sont pas simplement ignorées).
#3.2
pas sur en fait. Je viens d’essayer ca:
donc a priori pour les applis ligne de commande pas de overhead…
#3.3
La calculatrice et Firefox, ce sont des applis ligne de de commande ?
#4
Ah, l’idée vient en fait de Mozilla, pas de Canonical… Quoi qu’il en soit, on comprend bien que le but de Canonical, à terme, est de tout passer en snap et se débarrasser totalement du DEB dans Ubuntu (qui restera relégué à Debian ?). Du côté de chez Mint, Clément devrait sérieusement commencer à ne plus considérer LMDE comme la cinquième roue du carrosse, parce qu’à ce rythme, il ne restera plus qu’elle s’il continue à refuser catégoriquement les snaps dans sa distribution.
« Le changement sera invisible pour les utilisateurs » C’est ça, ouais… Et la marmotte, etc.
#5
S’il vous plait… rassurez moi… les .deb firefox existeront toujours, ce ne sera que la version “par défaut” d’Ubuntu, hein ? hein ???
#6
Sécurisé via la sandbox des snaps, OK! Mais sécurisé jusqu’au point ou l’accéleration graphique sera désactivé ? Parce qu’il me semble que la sécurité empêche de passer par un driver graphique optimisé.
#7
Rien que l’idée de devoir exporter mon profil et le réimporter à chaque mise à jour
#8
ça me rassure, je suis pas le seul à pas avoir envie de FF en snap
) d’après l’annonce, c’est déjà ça
au moins le deb sera conservé pour amd64 (et i386 mais y’en a plus beaucoup je pense
on a galéré l’autre jour au taff à pas comprendre pourquoi chez certains slack se fermait régulièrement, et chez d’autres tout allait bien : ceux chez qui slack avait été installé via snap avait l’appli qui se coupait à chaque verrouillage de la session …
du coup manip pour faire l’install via le .deb pour tout le monde et miracle plus de souci
bref, snap, c’est pas encore ça :s
#9
“sur tous les systèmes ayant snapd” - à part Ubuntu, on parle de qui côté grand public ?
“Au vu de la situation complexe de Mozilla” - qui n’est due qu’à la fondation elle-même, le torpillage d’un Firefox OS avant-gardiste, qui fonctionnait bien mieux qu’un pinephone actuel ayant largement déçu la communauté. Ce qui n’empêche pas kai os de continuer à exister et de se vendre - autre paradoxe. Sinon juste pour info : c’est toujours 20s pour ouvrir firefox sur un pinephone - et certains bugs ne sont toujours pas corrigés… Cela étant, on remarquera que ces mauvaises décisions n’ont pas baissé le juteux salaire de Mme Baker au passage. Par contre, elles ont mis à la porte les excellents ingénieurs de l’époque - dommage.
“l’éditeur veuille se simplifier un peu la vie” - comme tout le monde, certes. Mais quand je vois les problèmes du snap chromium, je ne suis clairement pas rassuré. C’est même pas maîtrisé actuellement, et ils veulent déjà mettre firefox en boîte ?
Attention : je n’ai rien contre Mozilla. On a réellement besoin d’un navigateur tiers pour ne pas laisser l’internet aux mains des GAFAM. Mais j’ai tendance à dire que plus un programme est complexe, moins il est compréhensible et sécurisé. Or un navigateur web est déjà une usine à gaz en soi, et rajouter maintenant une couche extérieure de bac à sable ne va pas baisser miraculeusement sa complexité. À mon avis, ils se font des illusions.
#10
De ce que j’en comprend, le deb survivra… jusqu’à ce que la version snap soit jugée “stable”, après, il faudra soit passer par le snap ou télécharger depuis le site de Mozilla via l’archive classique (le PPA de la “Mozilla Team” semble désormais proposer uniquement les versions ESR)
En tout cas, ça a été comme ça pour Chromium sous Ubuntu: paquet deb maintenu jusqu’à un certain temps, désormais snap obligé
Ça sera juste un sursis car si le deb fini par sauter, toutes les variantes seront affectées
#10.1
Cela veut dire qu’a terme il n’y aura plus de .deb pour firefox meme sous debian ?
J’ai arrêté la version snap de vscode qui me cassait les pieds.
#11
Si j’ai bien compris, le plan à terme est de conserver les .deb pour tout ce qui touche au système (les pilotes, les framework, les environnements de bureau, etc.), et que toutes les applications à destination des utilisateurs soient distribuées sous forme de snaps.
#12
Pour utiliser le multiposte de Free avec VLC sans qu’un core soit à 100% en permanence (seul usage où j’ai constaté le pb) avec Kubuntu 21.04 (VLC 3.0.12), j’ai due me résoudre a essayer le snap de VLC 3.0.16.
, j’ai à nouveau un VLC qui ne fait pas immédiatement monter en T° le CPU et qui poussait le ventilo à fond.
Ça résout le pb
Il semble globalement se comporter comme le VLC natif, sinon.
Mais comme je connais mal, je me méfie et l’utilise assez peu pour autre chose que le multiposte…
En tout cas, il utilise bien l’accélération matériel. Core à 25% avec, à plus de 80% sans (comme la 3.0.12 en utilisation autre que le multiposte). Mais ce pourcentage n’est sans doute pas très significatif, car même à 80%, la température ne bouge presque pas. Le bug de la 3.0.12 en multiposte fait passer le CPU de 55°C à 99°C en quelques secondes. Ici, ce doit être 80% d’une fréquence faible.
Le démarrage est effectivement plus lent. À vu de nez au lieu d’une demie seconde, ça prend 2 ou 3 secondes la 1ère fois..
Et les fichiers de conf sont ailleurs, faut s’habituer :/
J’ai aussi eu quelques plantage que je n’avait pas eu avant (écran noir, avec le son qui continue et sans doute tout le reste). serveurX et plasma à 100% de CPU (et un 3ème que j’ai oublié).
Mais aucune certitude sur l’origine du pb, snap/VLC/Plasma/Kwin/Xorg en tout cas c’est rare. Mais chiant.
Même s’il m’a bien dépanné, je m’étais dit que dés que je passe en 21.10, je me débarrasse de ce truc.
Donc la nouvelle concernant Firefox ne m’enchante pas des masses, même si pour l’instant snap m’a bien dépanné, et n’a pas (trop) eu d’inconvénient majeur (le pb d’écran noir étant très rare).
Comme Trit’, j’ai tout de même de gros doutes sur la soit-disante invisibilité pour l’utilisateur sur la durée, pour un usage un peu intensif et varié.
Mais bon! S’il y a des avantages (même si ce n’est pas pour moi) et pas trop d’inconvénient, pourquoi pas.
Si je comprends bien, Kubuntu ne serait pas concerné immédiatement.
J’avoue que ça me soulage un peu.
Mais ce sera pour une prochaine fois. Sauf si grosse mobilisation contre.
#13
#13.1
Merci(s) !
#14
Hello ! Une chose que je ne comprends pas : si les deux formats (deb et snap) sont conservés, en quoi la maintenance serait facilité avec snap par défaut sur Ubuntu ? merci
#15
J’utilise Firefox en snap depuis quelques mois, je n’ai noté aucun soucis particuliers de temps de lancement … pour moi ça fonctionne bien. Si ça peut permettre aux dev de n’avoir qu’un paquet à fournir pour tous pour moi c’est tout benef
#16
Pas ravi de cette nouvelle. Le Snap est une usine à gaz selon moi. Mais cela me conforte encore davantage dans le fait d’avoir quitté Ubuntu pour Debian depuis 2015.
#17
Bin… non. La version de Debian/whatever est empaquetée par les dev de Debian/whatever. FF est un logiciel libre; Sources –> Paquet .deb
Edit: grillé.
#18
De toute façon pour Debian c’est pas Mozilla qui fait le paquet, c’est Debian. Et c’est comme ça pour toutes les distros : je n’attends de Mozilla qu’une méthode d’installation manuelle (
make; make installou équivalent), ensuite c’est le taf des packagers de tout bien emballer. Et ils sont pas obligés d’être chez Mozilla.Si Mozilla veut fournir ses propres paquets, c’est du bonus, mais c’est pas leur taf…
#19
Le seul problème, c’est que si tu lances deux Flatpaks ou deux snaps qui emploient les mêmes dépendances, ces dernières sont donc chargées deux fois, car chaque logiciel fait appel à la sienne. Déjà, ça alourdit la consommation de RAM. Ensuite, les snaps créent leur propre point de montage (/dev/loopX, avec X allant de zéro à autant que le nombre de snaps en cours d’exécution). Comme si tu branchais une clef USB à chaque fois que tu ouvres un logiciel. Quand tu veux voir combien de place il te reste sur une partition avec
df -h, tu te retrouves avec une palanquée de « /dev/loop0, /dev/loop1, /dev/loop2… », ce qui fait bien b××délique (alors que les Flatpaks n’ont pas ce souci). Dernier souci : les paquets snap sont enregistrés dans le dossier « ~/snap », qui n’est même pas caché ; donc ça pollue le dossier de l’utilisateur, contrairement à un dossier « ~/.snap », qui aurait été invisible (si on n’affiche pas les fichiers et dossiers cachés).#20
Oui puis tu oublier les packets non mis a jours meme sous snap qui appelle snap core 20 alors que l’autre appelle snap core 19, ce qui augmente de manière exponentiel l’espace utilisé par les dépendance a chaque nouvelle version de core…
#21
Le format deb ne sera plus proposé a partir d’Ubuntu 22.04 : “la transition deb vers snap devrait être terminée en 22.04” cf https://lafibre.info/tutoriels-linux/snap-flatpak/msg893827/#msg893827
Par contre Mozilla fournit des binaires génériques pour Linux, mais ce ne sont pas des .deb mais des tar.bz2 sur la page https://www.mozilla.org/fr/firefox/all/#product-desktop-releaseg
#21.1
Merci pour vos explications. Honnêtement, j’ai testé le Flatpak, et hormis le démarrage pas instantané (mais ça reste quand même rapide, je chipote), ou encore les extensions Keepassxc incompatible à cause de la couche de sécurité inhérente à ce format, c’est pas mal du tout.
#22
Sinon, l’utilisation de Firefox en snap va permettre d’augmenter la sécurité : “Le fait que l’application soit strictement confinée est une couche de sécurité supplémentaire au-dessus du mécanisme de sandboxing déjà robuste du navigateur. Le sandbox du navigateur protège le navigateur contre le code malveillant, tandis que le confinement instantané protège l’utilisateur contre le navigateur agissant de manière malveillante. Ce sont donc vraiment deux mécanismes de sécurité complémentaires.”
#23
Merci pour toutes ces précisions :)
Pour l’argument sécu, il me semble qu’il y a quand même une exception pour \(HOME
Du coup, l'apport "deep protection" du SNAP me semble exagéré. Toutes les données auxquelles je tiens se trouve justement dans \)HOME.
#24
Erreur de post
#25
Gros changement apporté par snap : tous les téléchargements se font depuis le dépôt de Canonical : on ne peut pas avoir ses propres dépôts ni dupliquer le dépôt officiel.
#26
quel scandale ce snap avec le serveur propriétaire et complètement centralisé. Flatpak est plus ouvert et mieux conçu
#27
Sur mes serveur virtuel, j’ai que des problèmes avec snap lors des navkup. Et en plus cela prend beaucoup de place pour pas grand-chose (non partage des libs)
#28
Nooooonn, pas ça !
Très mauvaise nouvelle.
#29
Sinon, nouvel épidode de la série Mozilla veut se suicider et faire fuir les derniers utilisateurs de Firefox : « à l’instar de Brave, et si on mettait des liens sponsorisés dans les suggestions de recherche de la barre d’adresse ? ».
#30
Pas jojo en effet, mais il me semble que Brave c’était pire dans le sens où il insérait discrètement des codes affiliés même lorsqu’on tapait l’URL concernée d’un site dans la barre d’adresse.
#31
Pas vu dans le détail comment ça fonctionne côté FF, mais si des suggestions de recherches sont affichées dans une section « Sites sponsorisés » quand on tape une recherche ou une adresse, c’est bien qu’il doit y avoir quelque chose qui fera reconnaître le fait que c’est un résultat sponsorisé. Maintenant, est-ce que ça se manifeste via un suffixe spécial (un « &t=blablabla… » en fin d’URL), ou si c’est le nom de domaine qui entré plus ou moins en dur dans Firefox lui-même, je sais pas.
#32
A voir dans le détail en effet. Mais là j’ai envie de dire que si c’est affiché et assumé comme montré dans les captures d’écran, c’est pas aussi violent que Brave qui faisait ça en sous marin de ce que j’avais lu.