Au revoir Debian, bonjour Debian avec Flatpak (mise à jour)

Rédigé par antistress le 15 avril 2020 (mis à jour le 07 juillet 2020) - 26 commentaires

Des rangées de cartons de produits plats d'un magasin Ikea

J'avais évoqué, à l'occasion de la sortie de Debian 9 Stretch, la combinaison Debian Stable + Flatpak, que je déclarais gagnante sur le papier… Il est temps de passer à la pratique !

Ce billet, initialement rédigé le 10 juin 2019, a été refondu le 15 avril 2020 pour y intégrer les récents développements logiciels (corrections de bogues, nouveaux paquets Flatpak…).

Sommaire

  1. Pourquoi Flatpak ?
  2. Comment Flatpak ?
  3. Compte-rendu de mon expérience de flatpak-isation de ma Debian Testing

Pourquoi Flatpak ?

Déjà précisons que ma machine tourne sous Debian GNU/Linux Testing avec GNOME-Wayland.

Je vois plusieurs avantages à Flatpak, que je vous présente par ordre d'intérêt décroissant :

  • Stabiliser ma Debian : ajouter un dépôt non officiel comme le dépôt deb-multimedia pour bénéficier d'Avidemux, ou ajouter les dépôts d'une autre branche de Debian comme Unstable pour bénéficier de Firefox Release plutôt que de Firefox ESR, n'est pas sans risque pour la stabilité générale du système. Or ces logiciels existent en Flatpak ;
  • Profiter de la sécurité accrue du bac à sable des Flatpak, lorsque l'application en tire partie et à condition d'être sous Wayland – ce qui est mon cas (sans parler de la gestion fine des permissions d'accès à vos périphériques type webcam, microphone, à la géolocalisation…) ;
  • Profiter des dernières versions logicielles ;
  • Profiter des logiciels en version vanille, c'est-à-dire tels qu'ils ont été conçus par leurs développeurs sans modification par la distribution.

Les deux derniers points ne concernent toutefois pleinement que ceux des Flatpak qui ont été générés par les développeurs de l'application eux-mêmes, nous y reviendrons.

J'ai eu l'occasion de me frotter à Flatpak pour la première fois lors de mes tests de la version de développement de Pitivi (logiciel de montage vidéo pour GNOME) pour lesquels la version Flatpak du logiciel est recommandée (notamment parce que, étant générée par les développeurs du logiciel eux-mêmes, elle permet à l'utilisateur de faire tourner exactement la même version que les développeurs, ce qui facilite le débogage).

Comment Flatpak ?

Vous avez le choix entre la ligne de commande ou une interface graphique.

Pour ce qui est de comprendre les bases du fonctionnement de Flatpak en ligne de commande, je vous renvoie aux premières pages de ce manuel, et aux nombreux tutos disponibles sur la Toile.

Si vous préférez une interface graphique, la logithèque de GNOME vous permettra d'installer de manière transparente aussi bien de paquets .deb que de paquets Flatpak (sous Debian, installer pour cela le paquet gnome-software-plugin-flatpak).

Pour certains paquets Flatpak installés via la Logithèque de GNOME, l'interface était restée en anglais. J'ai donc dû installer les traductions du logiciel en ligne de commande (ajouter « .Locale » à la fin de l'identifiant du logiciel pour installer ses traductions. Le problème serait réglé avec les versions 3.32 ou suivantes de la Logithèque.

Il existe un dépôt central, Flathub, qui héberge un grand nombre d'applications. C'est d'ailleurs là-bas, à la page du logiciel concerné, que je récupère l'identifiant Flatpak des logiciels qui m’intéressent (l'identifiant peut aussi être récupéré avec la commande $ flatpak search nom-de-l'application). Attention, toutes les applications qui y figurent ne sont pas libres. C'est la raison pour laquelle, sur un certain nombre de distributions, ce dépôt n'est pas configuré par défaut. Il faudra donc l'ajouter ainsi : $ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo.

Au sujet de Flathub, j'ai découvert que certains paquets Flatpak sont préparés par les développeurs de l'application (directement du producteur au consommateur, pourrait-on écrire), comme LibreOffice, GIMP, Pitivi ou encore Firefox, tandis que d'autres, comme Audacity, Avidemux, Thunderbird, Transmission ou VLC media player sont générés indépendamment de leurs développeurs. Dans tous les cas, il ne s'agit pas des développeurs de votre distribution (d'où le titre de ce billet), ce qui est un changement de paradigme dans la distribution des logiciels sous GNU/Linux.

Compte-rendu de mon expérience de flatpak-isation de ma Debian Testing

Sans plus attendre, voici les paquets deb que j'ai choisi de remplacer par leur équivalent Flatpak, et les éventuels problèmes auxquels j'ai été confronté (en gras, les plus gênants).

Les Flatpak qui sont générés par les développeurs de l'application eux-mêmes figurent en vert et sont affublés de l'étiquette « [Flatpak officiel] ».

  • Audacity (application native Wayland, basée sur wxWidgets 3) : Pas de problème.
  • Avidemux (application native Wayland, basée sur Qt) : Tout semble ok (je me retrouve avec un choix de codecs un peu plus réduit via Flathub que via le dépôt deb-multimedia.org mais bon : osef). Les deux bogues (#3 et #8) que j'avais ont été réglés depuis. À noter aussi que le runtime de KDE (KDE Application Platform) est installé dans le cas de la version Flatpak, alors que j'avais juste des dépendances à Qt via le dépôt deb-multimedia.org : c'est inévitable pour limiter les efforts de maintenance à trois runtimes : freedesktop, GNOME et KDE.
  • Calibre (application native Wayland, basée sur Qt) : Tout semble ok (mais je ne l'utilise pas, je l'ai installée au cas où).
  • Déjà Dup [Flatpak officiel] (application native Wayland, basée sur GTK+3) : Tout semble ok.
  • Evince [Flatpak officiel] (application basée sur GTK+3) : Je ne l'ai pas installé car, sur ma distribution, le paquet evince dépend du paquet gnome-core que je souhaite garder pour maintenir une cohérence à mon système, et aussi bénéficier automatiquement de tout nouveau logiciel qui pourrait être ajouté en dépendance de gnome-core au fur et à mesure des développements du bureau GNOME.
  • Extensions [Flatpak officiel] (application native Wayland, basée sur GTK+3) : La nouvelle application de GNOME 3.36 pour gérer ses extensions, et qui se charge de les mettre à jour automatiquement au démarrage du système.
  • FileZilla (application native Wayland, basée sur wxWidgets 3) : Tout semble ok, sauf la possibilité d'ouvrir des fichiers dans des applications tierces (rapport de bogue).
  • Firefox [Flatpak officiel] (application X11 par défaut, basée sur Web Components, qui peut être configurée en native Wayland en réglant la variable d'environnement comme il faut) : Version stable ou bêta, au choix – mais pas les deux – et en attendant les déclinaisons Nightly et Developer Edition. On patientera toutefois jusqu'à ce que ce bogue d'affichage des polices soit réglé pour basculer son profil.
  • Frozen Bubble (application native Wayland ?, basée sur SDL) : Tout semble ok !
  • GIMP [Flatpak officiel] (application encore en GTK+2 donc X11 exclusivement) : Pour le moment c'est la dernière version stable qui est proposée en Flatpak, mais il est prévu que la future version (tirant partie de GTK+3) puisse être testée ainsi. Pas de problème particulier semble t-il pour GIMP, à moins que vous n'utilisiez des greffons. Pour ma part, j'avais l'habitude d'installer le paquet deb gimp-plugin-registry (qui fournit notamment le greffon "Save for Web" que j'affectionne) en même temps que la version deb de ce bon vieux GIMP, mais gimp-plugin-registry n'est pas proposé sur Flathub. J'ai donc dû retourner un peu le web et j'ai appris (mieux vaut tard que jamais !) que GIMP propose un système manuel d'installation des greffons ! D'ailleurs, je me souviens maintenant que Jehan a, de longue date, un plan pour améliorer la gestion des extensions dans GIMP. En attendant le résultat de ce travail, j'ai dû compiler le greffon "Save for Web" en suivant les instructions présentes dans l'archive officielle. L'exécutable webexport est alors copié dans /home/mon_user/.config/GIMP/2.10/plug-ins/ (à noter que normalement il faudrait le déplacer manuellement dans /home/mon_user/.var/app/org.gimp.GIMP/config/GIMP/2.10/plug-ins/ pour coller à l'organisation spécifique de Flatpak, mais il y a une difficulté à régler – rapport de bogue). À noter également que je n'ai pas réussi à franciser le greffon.
  • LibreOffice [Flatpak officiel] (application native Wayland, basée sur VCL) : Tout semble ok. Petit détail : le menu Outils->Options est très long à se lancer (plus de 5 secondes à attendre) (rapport de bogue).
  • Machines (alias Boxes) [Flatpak officiel] (application native Wayland, basée sur GTK+3) : La version Flatpak ne permet pas à ce jour à vos machines virtuelles d'accéder à vos disques USB : cela demande d'ajouter préalablement à Flatpak un portail ad hoc (rapport de bogue).
  • Pitivi [Flatpak officiel] (application native Wayland, basée sur GTK+3) : Aucun problème, et vous pouvez choisir votre version : la stable ou une des deux en développement.
  • Rhythmbox (application basée sur GTK+3) : Tout semble ok, si ce n'est que, parmi tous mes xdg-user-dirs, seul mon dossier Musique apparaît (rapports de bogue ici et ) et que les CD audio n'apparaissent pas (rapport de bogue). Du coup je reste à la version .deb en attendant la correction de ce bogue.
  • Scribus (application native Wayland, basée sur Qt) : Semble fonctionner correctement à part ce bogue concernant un problème d'affichage du menu « Formes » avec le thème Adwaita qui est en passe d'être réglé (il y avait aussi cet autre bogue, qui a été réglé depuis).
  • Shotwell [Flatpak officiel] (application native Wayland, basée sur GTK+3) : Tout semble ok, si ce n'est que, parmi tous mes xdg-user-dirs, seuls mes dossiers Images et Téléchargements apparaissent (rapport de bogue, qui devrait être réglé dans la future version 0.32).
  • Thunderbird (application X11 par défaut, basée sur XUL, qui peut être configurée en native Wayland en réglant la variable d'environnement comme il faut) : Pas de soucis (sauf le glisser-déplacer de messages d'un dossier à l'autre, qui nécessite sous Wayland d'appuyer sur Majuscule – en attendant la mise à jour vers Thunderbird 78 – mais c'est un problème qui touche Wayland et non Flatpak). Par contre si vous configurez Thunderbird en version native Wayland, vous pourriez être concerné par ce bogue agaçant.
  • Transmission (application native Wayland, ici dans sa version GTK+3) : Tout semble ok !
  • Video Downloader [Flatpak officiel] (application native Wayland, basée sur GTK+3) : Tout semble ok !
  • VLC media player (application basée sur Qt, ici en mode X11 par défaut, mais vous pouvez ajouter --socket=wayland au lanceur situé dans /var/lib/flatpak/exports/share/applications/ pour la passer en native Wayland) : Tout semble ok !

Toutes ces applications peuvent êtres installées dans leur version stable en une ligne de commande : $ flatpak install flathub org.audacityteam.Audacity org.avidemux.Avidemux com.calibre_ebook.calibre org.gnome.DejaDup org.gnome.Evince org.gnome.Extensions org.filezillaproject.Filezilla org.mozilla.firefox org.frozen_bubble.frozen-bubble org.gimp.GIMP org.libreoffice.LibreOffice org.gnome.Boxes org.pitivi.Pitivi org.gnome.Rhythmbox3 net.scribus.Scribus org.gnome.Shotwell org.mozilla.Thunderbird com.transmissionbt.Transmission com.github.unrud.VideoDownloader org.videolan.VLC.

À la date du 15 avril 2020, il n'y a donc guère que Evince, Firefox et Rhythmbox que j'utilise encore dans leurs versions .deb (pour les raisons sus-mentionnées).

Par ailleurs, certains logiciels que j'utilise ne sont pas (encore ?) sur Flathub : Brasero, DevedeNG, Imagination, Liferea, MComix, GNOME Web. On me fait remarquer que Chromium n'y est pas non plus. Notez que, par contre, plein de jeux ou d'émulateurs (ScummVM…), libres ou non, y sont.

En ce qui me concerne, je ne vois que des avantages à utiliser les versions Flatpak de mes logiciels usuels. Et pour celles qui ne fonctionnent pas correctement, et bien, il suffit de rester sur la version fournie par votre distribution en attendant que le problème soit réglé !

Quelques commentaires à ce billet et qui le complètent : Laurent Pointecouteau fait remarquer qu'il y a une discussion quant au fait de mettre en avant les Flatpak « officiels », ted fait remarquer qu'il est difficile de distinguer dans la logithèque GNOME les paquets de la distro des paquets Flatpak, Dragnucs demande s'il est possible de filtrer les logiciels privateurs sur GNOME Software ou flathub.

Remarque finale : à l'occasion de la stabilisation des versions natives Wayland de Thunderbird et Firefox, j'ai tenté d'activer la fonctionnalité expérimentale « XWayland à la demande » introduite avec GNOME 3.34 puisque mes applications quotidiennes (Firefox, Thunderbird, Liferea), ainsi que la plupart des autres, n'ont plus besoin de XWayland pour fonctionner. Mais je suis confronté à ce bogue impliquant Flatpak qui m'a contraint à désactiver ladite fonctionnalité pour le moment.

26 commentaires

#1  - Ose Effe a dit :

S'il y avait MS Office en flatpak, ou la suite adobe, tu l'installerais ?

Répondre
#2  - malagasy a dit :

Et pour quelle raison ne l'installerons nous pas? Développe ton point de vue.
Je suis dans une entreprise où tout tourne sous Windows. Cependant, quelques irréductibles comme moi ont décidé d'installer du Linux sur nos ordi du boulot. Pour rester en phase avec les demandes de l'entreprise, j'ai du installer Windows sur une machine virtuelle pour faire tourner des logiciels qui n'ont pas d'équivalence, et de compatibilité avec ceux sous linux.

D'où ma question par rapport à ta remarque, en quoi c'est mal d'avoir Adobe ou MS Office version flatpak si çà existe, et si celà nous permettra de ne plus utiliser une machine virtuelle Windows!

Répondre
#3  - aeris a dit :

Bienvenue dans un monde sans sécurité du coup ^_^

Répondre
#4  - antistress a dit :

Salut aeris,
Ce propos mériterait d'être développé ;)

Répondre
#5  - x a dit :

http://flatkill.org/

Répondre
#6  - antistress a dit :

Sérieusement ?

Répondre
#7  - Le fromagé a dit :

Faire ça c'est comme enlever la croûte des fromages avant de le manger, c'est jeter tout le travail de l'affineur à la poubelle.

Répondre
#8  - skc a dit :

Un des soucis que je vois avec flatpak, c'est les interactions entre logiciels.

Par exemple avec Ubuntu 18, lorsque je clique sur un document dans LibreOffice, et que je fais "Editer dans Gimp"; gimp se lance et me dit qu'il ne trouve pas le fichier (il est dans un sous-répertoire de /tmp).

On pourrait probablement définir qu'un répertoire doit être partagé, comme le $HOME de l'utilisateur, mais dans ce cas, quel est l'intérêt de la protection ?

Répondre
#9  - jonjon a dit :

Pour moi flatpak est à éviter, pareil pour Snap. Si je devais choisir je prendrais Appimage.

Flatpak vient avec son lot de problèmes notamment de sécurité qui le disqualifie d'office.
Au delà de ses limitations, Snap est voué à disparaitre à plus ou moins court terme comme la plupart des projets par canonical pour canonical.

Appimage a l'avantage d'être supporté par défaut sur la plupart des distributions existantes, y compris en live usb ou live iso, est basé sur le modèle communautaire et n'est pas dépendant du modèle économique d'une compagnie (red hat pour flatpak et canonical pour snap).

Pour une comparaison entre les 3 je recommande la lecture de cette page: https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

Répondre
#10  - XataZ a dit :

Je suis d'accord avec toi, je préfère largement Appimage, car "natif", c'est juste un exécutable qui intègre tout, contrairement à snap et flatpak qui nécessite un daemon ou des outils en plus. Appimage est très pratique pour créer un clé USB avec des applis portable dessus, un peu à la windows pour avoir ces outils de dépannage.

Après, pour moi ça reste des outils à éviter, notamment avec le fait que ça reste une boite noir, on ne sais pas trop ce qu'il y a dedans, et si ce n'est pas régulièrement maintenu. De plus c'est assez complexe à maintenir, gérer ces propres "Images" est plus compliqué que du docker avec les dockerfiles (utilisations différentes certes).

Répondre
#11  - antistress a dit :

klik (devenu Appimage) est évoqué par le créateur de Flatpak comme source d'inspiration initiale :
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

De ce que je comprends, en termes de sécurité (comment gérer les mises à jour des bibliothèques embarquées avec chaque logiciel ?) et d'espace occupé (les mêmes bibliothèques dans chaque paquet), ça me paraît nettement moins abouti que Flatpak

Répondre
#12  - XataZ a dit :

Oui c'est moins abouti niveau gestion d'espace, c'est sur, mais comme dit, appimage c'est juste un binaire qui contient tout, point, pour être portable. C'est a dire tu exécutes ton binaire sur toutes machines, en ayant rien besoin de plus.
Flatpak nécessite un binaire pour être exécuté, snap un daemon, mais donc la transportabilité n'est plus aussi évidente, car il faut que flatpak ou snap sois packager sur le système hôte.

Ensuite, niveau mise à jour ce n'est pas dit que ce sois plus simple, car ce n'est pas parce qu'une base est mis à jour, que l'image firefox par exemple va l'utiliser.
Prenons l'exemple de pitivi, qui à été builder pour la dernière fois le 20 Aout 2018, il est basé sur le runtime org.gnome.Platform (géré par gnome), qui lui est basé sur le runtime org.freedesktop.Platform (géré par flatpak il me semble). Dans ces deux runtimes, il y a forcément des composants qui ont été patcher (bug ou faille) ou mis à jour depuis (du moins je l'espère), ba ton appli pitivi ne les intègres pas, puisqu'il n'a pas été mis à jour depuis.
Le seul moyen de vraiment être sécure, ce serais de gérer toute la chaine toi même, mais flatpak ou snap, c'est plutôt complexe, ou que ce sois vraiment la même personne qui la gère.

Pour l'instant, c'est pas trop démocratiser, mais on pourrait par exemple voir dans le futur, des images basé sur d'autre, qui serons basé sur d'autre et ainsi de suite, et là on complexifiera encore plus la chaine de construction. Et on finira comme docker, avec des images non à jour dans tout les sens, bourré de faille etc ...

appImage, même si beaucoup plus complexe à mettre en oeuvre, n'a pas se problème, car tu construis tout directement. Par contre effectivement, ça monte très vite en espace disque.

Répondre
#13  - antistress a dit :

@ XataZ : Je ne te suis pas sur deux points : les runtimes flatpak sont mis à jour régulièrement* ! Et je ne vois pas en quoi nécessiter la présence d'un exécutable pour exécuter les flatpak est un problème en pratique, cela me paraît d'avantage une position de principe ;)

*https://blogs.gnome.org/alexl/2018/08/10/the-birth-of-a-new-runtime/

Répondre
#14  - lolop a dit :

As-tu regardé l'espace disque occupé par ces différentes installations?

J'avais fait un essai avec snap… c'était (pour moi) catastrophique.

Répondre
#15  - antistress a dit :

/var/lib/flatpak c'est 4,5 Go chez moi

Répondre
#16  - flatbrain a dit :

On marche sur la tête. Mais qui a eu cette idée à la con, franchement?

Répondre
#17  - Bruno a dit :

Je suis en train de désinstaller/réinstaller mes applis afin de virer Flatpak. Le seul avantage étant d'avoir des applis à jour des dernières versions (et pas toujours), ce qui peut se faire par d'autres biais (repositories,etc..), cet avantage ne compense pas les nombreux inconvénients tels que la place disque (près de 10Go !!) et je vais pas tarder à devoir agrandir ma partition système (zut!).
Je ne suis pas assez calé pour parler des problèmes de sécurité qui semblent être présents, et pour les apprécier, mais par principe de précaution et tranquillité d'esprit, je préfère ne pas poursuivre l'expérience.
J'ajouterai que certains paramétrages semblent impossibles, par exemple, pas moyen d'avoir les greffons LADSPA dans Audacity, alors qu'il suffit d'une variable d'environnement correcte pour qu'un Audacity installé "normalement" les trouve illico. Il y a peut-être un moyen, mais j'ai autre chose à faire que de résoudre ce type de problème, si j'installe des applis c'est pour les utiliser, pas pour perdre mon temps à chercher pourquoi elles ne fonctionnent pas comme elles devraient et comme elles le font dans d'autres circonstances.
Alors bye bye Flatpak

Répondre
#18  - antistress a dit :

Lire aussi les commentaires déportés sur LinuxFr.org : https://linuxfr.org/users/antistress/liens/au-revoir-debian-bonjour-debian-avec-flatpak-mise-a-jour-libre-et-ouvert

Répondre
#19  - Eso Kerman a dit :

bonjour, il existe une version Flatpak de gnome-web, ici: https://wiki.gnome.org/Apps/Nightly

Il s'agis de la version de développement, mais c'est la façon recommander d'utiliser gnome-web d'après les devs pour des raisons de sécurité, puisque tout n'est pas à jours sur les distributions, notamment WebKitGTK.

Malheureusement, la fonctionnalité d'applications web n'est pas disponible sur la version Flatpak.

Répondre
#20  - Dragnucs a dit :

Je trouve que Flatpak est assez pratique et facilite la distribution et accès au logiciels. Mais ce que je n'aime pas c'est la présence de logiciel privateurs. On doit toujours faire attention à la licence.

Y-a-t-il moyen pour filtrer les logiciels privateurs sur GNOME Software ou flathub ?

Répondre
#21  - antistress a dit :

Ha en voilà une remarque qu'elle est bonne.
Je viens de vérifier et je n'ai pas trouvé comment faire.
Il faut en conclure que ce n'est pas la priorité de ceux qui organisent ce dépôt ou la logithèque GNOME.
D'ailleurs c'est pareil pour les extensions GNOME : va t-en trouver leur licence.
J'ai créé un rapport de bogue sur FlatHub si tu veux y souscrire : https://github.com/flathub/linux-store-frontend/issues/217

Répondre
#22  - mothsart a dit :

Moi, je t'encourage à utiliser plutôt NIx + Debian (Tous les softs cités sont supportés) : https://doc.ubuntu-fr.org/nix
C'est moins gourmand en mémoire, mieux isolé, plus configurable, plus stable, une communauté de dingue... et beaucoup plus simple de créer un paquet.

Répondre
#23  - antistress a dit :

oui, mais https://linuxfr.org/users/emeric_/journaux/mais-pourquoi-flatpak#comment-1777862 ?

Répondre
#24  - mothsart a dit :

Le commentaire indiqué va plutôt dans mon sens.
En effet, les 4 points évoqués sont tout a fait fondé pour Nix :
1. Les softs installés sont totalement indépendants et on peut sans problème faire cohabiter plusieurs versions du même soft.
2. pas besoin d'avoir de droits root avec Nix
3. mutualiser les bibliothèques : mieux ou moins bien que flatpak, il faudrait sans doute une vrai comparaison technique impartial avec des benchs à l'appui.

Pour le dernier point : l'isolation, c'est un non débat à mon sens.

Pour installer des softs graphiques en lieu et place de ceux viellissant de ta Debian, l'isolation n'apporte rien.
Je dirais que c'est tout l'inverse : une vrai isolation complexifie l'interopérabilité des softs, a un coût mémoire, CPU, IO, temps de lancement du soft.

Et puis, si on veut de l'isolation, t'as des trucs comme docker ou lxc qui font bien mieux, qui sont bien plus populaires, adoptés, documenté, clé en main.

Après, y'a l'envers du décors : le packaging.
Perso, je suis dev, je crée et je maintiens des softs "libre".
J'empaquete dans la mesure du possible mes softs en .deb et je garde à jour un PPA.

J'ai tenté de faire sous Flatpak : c'est une imondisse sans nom. (bon, y'a pire : snap)
Dès qu'on sort du "hello world" ou tout nous est présenté comme simple, c'est Bagdad. Ca pue le bricolage et l'amateurisme.
Du coup, on a du mal à s'imaginer que c'est très sécure et bien branlé quand ça s'éffrite dès qu'on touche le vernis.

Nix c'est un peu le contre-pied : élitiste dès le début (au moins, on vend pas un semblant de simplicité), après s'être cassé les dents, on comprend la logique et la cohérence.
Le langage est efficace. La communauté est grande et réactive : https://github.com/NixOS/nixpkgs, le nombre de paquets supportés est impressionnant.

Tout n'est pas parfait, loin de là. (J'écris au fur et à mesure de mes découvertes : les points bloquants, les désillusions et je pense faire un bilan une fois avoir fait le tour)
Néanmoins, y'a un vrai fil conducteur et j'ai plaisir a packager pour Nix. (autant que pour debian mais pas pour les mêmes raisons)
J'ai même commencé à packager des softs dont je ne suis pas l'auteur : drawing.

Et c'est là ou je veux en venir : si les devs/mainteneurs de paquets ne sont pas emballés, ça risque de rester une coquille vide avec juste quelques softs.
Bref, moi je ne ferais pas l'effort.

Le seul point ou Nix n'est pas vendeur c'est qu'il n'a pas de GUI pour ces paquets et la recherche sur flathub est bien mieux abouti que https://nixos.org/nixos/packages.html
Je reste lucide la dessus : c'est vraiment dommage de faire autant de taf et de saboter le point d'entrée.

Répondre
#25  - antistress a dit :

Merci pour ces explications détaillées.
Néanmoins, à côté ces explications fortes intéressantes, tu sembles confirmer le commentaire ci-dessus, à savoir que seul Flatpak propose les 4 points.

Répondre
#26  - mothsart a dit :

Ben oui.
Mais en fait, le 4ème point est un partie pris que je ne défend pas.
Flatpak se met pour objectif (qu'il tient peut-être, là n'est pas la question) d'isoler les apps dans des bacs à sable donc hermétique à l'OS.

Nix n'est pas inférieur techniquement, il n'a tout simplement pas la même feuille de route.
Nix apporte juste l'isolation nécessaire à ses objectifs soit :
1. de ne pas avoir les mêmes travers que d'autres distribs : une sélections très précises des versions des logiciels et des libs et devoir casser ça à chaque upgrade de version
2. permettre de faire du versionning avec des rollbacks
3. gérer plusieurs versions des mêmes softs

Comme dis, je privilégie ce choix car bien plus pragmatique (ce qu'est l'informatique de toute façon).

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

NB : en publiant votre commentaire, vous acceptez qu'il soit placé sous la licence CC BY-SA comme indiqué aux conditions d'utilisation du site

Quelle est la première lettre du mot xeze ?