Journal antistress adventure in Flatpak land

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
18
30
avr.
2024

Hello nal, ça faisait un bail !

Certain (il se reconnaîtra) m'a demandé de le tenir au courant lorsque j'aurai basculé sur un usage de Firefox version flatpak, ce qui est le cas. Donc voilà un journal à cet effet.

Firefox+Flatpak

Tout a commencé lorsque j'ai décidé de stabiliser ma distribution (Debian Testing) en installant certains logiciels en flatpak pour pouvoir supprimer le recours à des dépôts supplémentaires (Debian multimedia en l'occurence).

Cet épisode est relaté dans ce billet de 2019, que je maintiens à jour de mes pérégrinations : « Au revoir Debian, bonjour Debian avec Flatpak ».

Depuis j'ai pu installer de plus en plus de logiciels en flatpak au fur et à mesure que la technologie maturait et que les bogues étaient corrigés.

Il restait encore Firefox release que je souhaitais également passer en flatpak pour deux raisons : un navigateur me semble particulièrement désigné pour tourner dans un bac à sable (permettant de limiter la surface d'attaque extérieure) ; surtout, je piochais jusqu'à présent la version release de Firefox dans la branche Sid de Debian : mélanger les branches n'est pas sans risque et je voyais poindre la possibilité d'enfin cantonner ma distribution aux seuls dépôts Testing.

J'ai dû tout d'abord attendre, pour me lancer, la résolution d'un bogue qui dégradait la fluidité des vidéos lues dans le navigateur et d'un autre qui dégradait le rendu des polices.

Il me fallait ensuite prévoir un peu de temps pour effectuer la bascule car j'utilise un certain nombre de profils différents, correspondant à autant d'activités différentes en ligne, profils pour lesquels j'ai mis en place des lanceurs distincts. Bien évidemment je voulais conserver cet usage lors du passage à la version flatpak de Firefox. Je décris la procédure dans le billet « Cloisonner ses activités en ligne en jonglant avec les profils de Firefox » pour celleux que ça intéresse

Il se trouve que ça a été plus simple/rapide que prévu, et ce grâce au gestionnaire de profils très pratique de Firefox (comme je le détaille dans le billet « Passer du Firefox de votre distribution à sa version Flatpak  »).

Depuis quelques jours que j'ai remplacé la version de ma distribution par la version flatpak de Firefox, je peux témoigner que l'expérience est sans problèmes.

J'ai cependant dû abandonner l'extension Open with (qui n'est plus maintenue mais qui fonctionnait toujours sur la version Debian de Firefox, ce qui n'est pas le cas dans mon expérience avec la version flatpak, la faute probable au bac à sable inhérent à cette technologie) que j'utilisais pour passer rapidement le lien d'une page contenant une vidéo à un logiciel de téléchargement capable de la détecter et de la télécharger.

À noter que depuis la version 123, le flatpak de Firefox est configuré par défaut pour fonctionner en mode Wayland dans un environnement ad hoc).

Au final :

Ce que j'ai gagné :

  • la sécurité théorique apportée par le duo Flatpak+Wayland ;
  • une distribution plus stable (risques de conflit limités lors des mises-à-jour).

Ce que j'ai perdu :

  • l'usage de l'extension « Open With », et n'ai pas trouvé d'alternative. J'en suis donc revenu à devoir copier/coller le lien dans un autre logiciel que je lance avec une touche de raccourci.

Appendice :

Toute application n'est pas faite pour être utilisée dans sa version flatpak en l'état actuel de cette technologie. Ainsi j'avais testé en flatpak à sa sortie Loupe, la nouvelle visionneuse d'image du bureau GNOME : autant sur LibreOffice, Thunderbird, Liferea ou Firefox, un petit temps supplémentaire au lancement ne se ressent absolument pas, autant attendre l'ouverture de l'application à chaque fois que l'on clique sur une image pour l'afficher m'a paru incompatible avec mon usage et mes attentes.

  • # L'usage de fichiers locaux est problématique

    Posté par  (site web personnel, Mastodon) . Évalué à 10 (+23/-0).

    Coucou,

    J'utilise le flatpak de Firefox depuis pas mal de temps pour ma part. La partie qui m'horripile le plus est l'usage de fichiers locaux. En vrac:

    • Je ne peux plus charger un fichier en le glissant-déposant (e.g. si je veux visionner un SVG dans Firefox plutôt que dans le lecteur d'image par défaut). Typiquement toutes les adresses en file:// sont lettres mortes, ce qui soit-dit en passant est normal dans un contexte "bac à sable", excepté lors de requêtes explicites. Par exemple, je peux ouvrir le même fichier avec ctrl-o (Fichier > Ouvrir) puis en cherchant dans l'arborescence. Voire souvent ce que je fais, c'est: ctrl-o puis, je glisse-dépose dans la boîte de dialogue de recherche de fichier (là ça marche), pour ne pas avoir à chercher dans l'arborescence dossier après dossier, puis "OK". Enfin bon, quoi qu'il en soit, c'est inconfortable. Et surtout, un glisser-déposer devrait compter comme "requête explicite de l'utilisateur".
    • Lié, mais pire car quasi-inutilisable, c'est le développement web. Je co-gère divers sites web, et lorsqu'ils sont statiques, j'appréciais de pouvoir les voir localement en file://. Je peux bien sûr utiliser encore le portail (ctrl-o) sauf que cela ne permet d'ouvrir qu'un seul fichier. En particulier, cela n'ouvre pas un contexte arborescent entier (il y une demande de fonctionnalité ouverte pour la création d'un tel portail). Typiquement je veux voir un fichier HTML, mais celui-ci veut aussi pouvoir charger une CSS, des images en local, et les liens doivent ouvrir d'autres pages HTML locales si les liens sont relatifs. Mais rien de tout cela ne peut marcher pour l'instant. Firefox ne peut charger que la page HTML et c'est tout. Heureusement que de plus en plus de systèmes de génération HTML statique ont aussi un serveur web incorporé pour tester (voire on peut utiliser python3 -m http.server), mais quand même, c'est triste.
    • Le portail ne se souvient pas du dernier chemin d'ouverture ou de sauvegarde. Et ça c'est exaspérant. Il m'arrive très souvent de vouloir sauvegarder plusieurs fichiers à la fois dans un même répertoire. Typiquement, je suis sur une page où j'ai 10 PDF à télécharger; j'aimerais cliquer une fois, choisir le chemin d'accès, puis pour les 9 autres téléchargements, juste cliquer, OK, cliquer, OK… Ben à chaque fois, le chemin de départ n'est pas le dernier chemin dans lequel j'ai sauvé le fichier précédent (comme c'était le cas avec la version non-sandboxée)! Donc je dois laborieusement retrouver le chemin à chaque fois. Maintenant j'ai pris le pli, et ce que je fais, c'est de copier le chemin complet du répertoire cible, puis dans la boîte de dialogue de sauvegarde, je ctrl-l puis ctrl-v, puis Entrée. Enfin bon, c'est un énorme pas en arrière en utilisabilité.
    • Dernier point qui me titille: le portail d'ouverture/sauvegarde de fichier ne prend jamais le focus. Il est bien devant la fenêtre de Firefox, mais Firefox garde le focus. Alors je comprends évidemment que c'est parce que c'est un processus différent (le portail) et qu'il y a tout ce truc autour de la peur de vol de focus (si non remarqué, une application pourrait voler un focus au moment où vous allez taper votre mot de passe!), sauf que là c'est l'application qui a appelé ce portail et c'est d'ailleurs pour cela qu'il est devant Firefox. Pourquoi ne prend-il pas le focus par défaut? Pourquoi dois-je aller cliquer quelque part dans la fenêtre ou jouer du Alt-tab à chaque fois?

    Enfin bon, ce sont des détails successifs qui — je l'espère — seront réglés à terme, mais c'est vraiment embêtant, voire exaspérant.

    Voilà, c'était ma minute "grognon". Il n'empêche que je continue d'utiliser Firefox en flatpak, mais c'est vrai que des fois, je pense à repasser au Firefox en paquet natif.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: L'usage de fichiers locaux est problématique

      Posté par  . Évalué à 9 (+8/-1).

      Lié, mais pire car quasi-inutilisable, c'est le développement web. Je co-gère divers sites web, et lorsqu'ils sont statiques, j'appréciais de pouvoir les voir localement en file://

      Ça ne va pas résoudre ton problème, mais pour ça j’utilise python -m http.server dans le dossier où est enregistré le site statique. Ça pourra te faire gagner du temps plutôt que de charger toutes les pages une par une via le sélecteur de fichier.

    • [^] # Re: L'usage de fichiers locaux est problématique

      Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

      Pour la mémorisation du dernier chemin d'ouverture ou de sauvegarde, c'est Firefox / Thunderbird qui font mal les choses, puisque le dernier chemin utilisé est bien mémorisé dans d'autres applications Flatpak (typiquement celles de GNOME). Georges Basil Stavracas Neto, développeur sur différents portails, leur a pourtant signalé il y a plus d'un an.

      • [^] # Re: L'usage de fichiers locaux est problématique

        Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

        Même chose pour le focus. Je viens de tester avec GNOME Web, les boîtes d'ouverture ou de sauvegarde ont bien le focus.

        Il faudrait vraiment qu'un développeur qui connaît bien Flatpak résolve tous ces petits problèmes, pourtant facilement corrigeables.

        On peut également citer les droits par défaut. L'accès aux périphériques (webcam, microphones, contrôleurs de jeu…) ne devraient pas être accordés par défaut, puisque il existe un portail pour demander l'autorisation de l'utilisateur.

    • [^] # Re: L'usage de fichiers locaux est problématique

      Posté par  (site web personnel) . Évalué à 3 (+3/-2). Dernière modification le 01 mai 2024 à 07:40.

      J'utilise le flatpak de Firefox depuis pas mal de temps pour ma part. La partie qui m'horripile le plus est l'usage de fichiers locaux. En vrac:

      https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions

      C'est du masochisme, de pas vouloir utiliser un paquet intégré au système, ou juste parce qu'on aime bien se plaindre sur linuxfr ?

      Même le côté sécurité (discutable, d'ailleurs) n'est pas justifié, il existe des options bien intégrées, comme firejail pour limiter l'accès au système.

      • [^] # Re: L'usage de fichiers locaux est problématique

        Posté par  . Évalué à 6 (+4/-0).

        Jette un œil à Bubblewrap, évoqué ici entre autres.

        • [^] # Re: L'usage de fichiers locaux est problématique

          Posté par  . Évalué à 3 (+3/-0).

          Perso, c'est la solution que j'ai choisi niveau sécurité : Firefox dans un jail bwrap. Si ça intéresse du monde, voici le profil que j'utilise :

          /usr/bin/bwrap --setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin --as-pid-1 --cap-drop all --unshare-all --share-net --dev /dev --bind-try /dev/dri /dev/dri --proc /proc --ro-bind /sys /sys --bind /run /run --ro-bind /usr /usr --ro-bind /var /var --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /etc /etc --bind /tmp /tmp --bind-try $HOME/Bureau $HOME/Bureau --bind $HOME/.mozilla $HOME/.mozilla --bind-try $HOME/.Xauthority $HOME/.Xauthority --bind-try $HOME/.config $HOME/.config --bind-try $HOME/.local $HOME/.local --bind-try $HOME/.icons $HOME/.icons --symlink usr/sbin /sbin --symlink $HOME/Bureau $HOME/Desktop /usr/lib/firefox-esr/firefox-esr

          Ce n'est peut-être pas parfait, mais cela convient à mon usage

      • [^] # Re: L'usage de fichiers locaux est problématique

        Posté par  . Évalué à 2 (+3/-3).

        Par bien intégré, tu veux dire en fait pas du tout ?

      • [^] # Re: L'usage de fichiers locaux est problématique

        Posté par  . Évalué à 2 (+2/-0).

        firejail est un très mauvais choix en terme de sécurité. Le programme est root SUID. Lui préférer bubblewrap comme dit dans un autre post. Ce dernier ne requiert pas de droit root.

  • # "Open with..." Junction ?

    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 30 avril 2024 à 20:27.

    Pour l'avenir, tu seras peut-être intéressé par la résolution de ce ticket : Domain Specific Applications Possible?

  • # Performances ?

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Il y a quelques années, je suis passé d'Ubuntu à Debian parce que (entre autres) lancer la version Snap de Firefox prenait au moins 6 secondes, ce qui est long quand on attend devant son écran en se demandant si on a bien cliqué sur l'icône.
    Avec la version packagée de Debian, c'est moins d'une seconde.

    Certes Flatpak n'est pas Snap, mais ne ressents-tu pas également une lenteur au démarage ? Et à l'utilisation ?

    • [^] # Re: Performances ?

      Posté par  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 01 mai 2024 à 16:32.

      A part avec Loupe, je n'ai pas ressenti de lag avec aucune de ces applis installées flatpak que j'utilise souvent :

      Téléchargeur de vidéos com.github.unrud.VideoDownloader 0.12.12 stable system
      Lars Windolf net.sourceforge.liferea 1.14.6 stable system
      Audacity org.audacityteam.Audacity 3.5.1 stable system
      Avidemux Team org.avidemux.Avidemux 2.8.1 stable system
      FileZilla org.filezillaproject.Filezilla 3.66.1 stable system
      Éditeur d’image GIMP org.gimp.GIMP 2.10.36 stable system
      The GNOME Project org.gnome.Brasero 3.12.3 stable system
      The Document Foundation org.libreoffice.LibreOffice 24.2.2.2 stable system
      Thunderbird org.mozilla.Thunderbird 115.10.1 stable system
      Firefox org.mozilla.firefox 125.0.3 stable system
      VLC org.videolan.VLC 3.0.20 stable system

    • [^] # Re: Performances ?

      Posté par  . Évalué à 2 (+0/-0).

      J'utilise du flatpack et non pas du tout. D'ailleurs j'utilise aussi du docker qui s'appuie en bonne partie sur les mêmes mécanismes et pas du tout (mis à part quand je limite les ressources du conteneur évidement)

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.