Je n'ai jamais utilisé Nix, mais par rapport à tes exemples qui utilisent tous la ligne de commande, Flatpak s'intègre bien avec les logithèques graphiques des différents environnements de bureau (c'est le cas pour GNOME, KDE, Cinnamon, Pantheon…). On peut donc facilement ajouter un dépôt comme Flathub en deux clics de souris et ensuite rechercher et installer une application tout aussi facilement.
Pour des applications réellement isolées, d'avoir une gestion des permissions au sein de l'environnement de bureau permettant à l'utilisateur d'avoir un retour graphique et de pouvoir facilement faire son choix (l'application que vous venez d'installer souhaite pouvoir accéder à la webcam, souhaitez-vous l'autoriser…) est très important. L'utilisateur doit pouvoir facilement accorder ou révoquer des droits à tout moment.
Le développement de Flatpak est actif. La version 1.6.0 est sortie la semaine dernière et apporte, entre autre, la prise en charge des contenus protégés, ce qui devrait permettre, à terme, de pouvoir acheter des contenus (applications commerciales). Tous les utilisateurs ne sont pas forcément des libristes convaincus et certains voudront pouvoir acheter le dernier jeu à la mode ou une application propriétaire qui répondrait mieux à leurs besoins que son équivalent libre.
À mon avis, si Flatpak risque de remporter le match, c'est qu'il est massivement adopté (projet Freedesktop, donc plus ou moins un standard dans le Libre) et qu'il s'intègre bien dans les écosystèmes (bonne documentation, intégration dans les environnements de bureau, que ce soit pour l'installation/désinstallation des paquets ou la gestion des droits, la prise en compte des besoins des différentes parties, développeurs / éditeurs et utilisateurs finaux…)
Nix était peut être là dix ans plus tôt, mais est-ce qu'ils ont cherché à s'intégrer aux environnements de bureau, à prendre en compte les besoins des différentes distributions, des éditeurs commerciaux… ou est-ce qu'ils n'ont pas cherché à voir plus loin que leur propre communauté ?
Je ne sais pas si ça a été ajouté depuis, mais la vieille version est bien présente dans les dépôts de Fedora, mais n'apparaît pas dans la logithèque GNOME (il en va sans doute de même pour les autres environnements). Il faudrait donc fournir des métadonnées AppData pour que les utilisateurs puissent plus facilement trouver l'application et qu'elle soit bien présentée (description (potentiellement dans la langue de l'utilisateur), captures d'écran…)
Puis comme le changelog de la version 0.13 semble indiquer qu'on peut désormais construire un Flatpak à partir des sources, ça ne serait pas plus mal d'envoyer une version officielle sur Flathub.
Ça reste tout de même un énorme gaspillage de ressources, quand on sait qu'il suffisait de deux extensions (Dash to Dock ou Dash to Panel + Arc Menu) pour retrouver cette fameuse métaphore de bureau traditionnelle sous GNOME, évitant ainsi de devoir redévelopper un nouvel environnement.
C'est pourtant indiqué sur la page que j'ai donné (« Based on Ubuntu 18.04.2 LTS with Hardware Enablement (HWE) stack ») ainsi que sur la page d'accueil de la distribution (« Built on an Ubuntu Linux foundation »).
Chez Linux Mint, aucune référence sur la page d'accueil, il faut aller sur la page About Linux Mint. Mais on retrouve bien la référence dans la page des nouveautés de la dernière version (« Linux Mint 19.2 features Cinnamon 4.2, a Linux kernel 4.15 and an Ubuntu 18.04 package base. »)
C'est kif kif et je trouve qu'il faut vraiment être de mauvaise foi pour dire qu'il faut fouiller pour y trouver une référence.
Les mêmes paradigmes que l'on peut obtenir sur n'importe quel environnement de bureau, y compris GNOME avec Arc Menu et Dash to Panel…
Et pour tout ceux qui n'aiment pas bidouiller et préfèrent un environnement prêt par défaut, il existe des distributions telles que Zorin OS qui proposent tout ça clé en main.
J'imagine qu'il y a moyen de faire en sorte que les applications ne puissent plus aller espionner le presse-papier à leur guise comme elles peuvent le faire actuellement, tout en laissant la possibilité à l'utilisateur de faire des copier-coller entre applications. De façon transparente, comme aujourd'hui, mais uniquement quand il s'agira d'une action de l'utilisateur.
Pour toute la partie concernant l'installation de Flatpak et du dépôt, ça pourrait être grandement facilité par la distribution. Certaines (Fedora, Linux Mint…) intègrent déjà Flatpak par défaut. Maintenant, à moins que le wiki officiel de Debian ne soit pas à jour, malgré la sortie récente de Debian 10, il semblerait qu'ils ne fournissent toujours pas Flatpak et le greffon associé de la logithèque GNOME par défaut, ce que je trouve être une occasion manquée.
En ce qui concerne le dépôt, sans aller jusqu'à le configurer par défaut comme le fait Linux Mint, si l'étape précédente avait été faite, tout comme pour Fedora, il n'aurait suffi que d'un clic sur un gros bouton bleu pour lancer la logithèque et permettre la configuration du dépôt.
Je ne vais pas revenir sur toutes les commandes tapées dans un terminal et la nécessité d'en lancer certaines avec sudo, ça serait conforter certaines personnes dans leur croyance qu'encore aujourd'hui, sous Linux, il faut tout faire en ligne de commande /o\ De mon côté, je passe uniquement par la logithèque GNOME et peux donc tout faire à la souris. Puis quand il y a besoin de m'authentifier pour prouver que j'ai bien le droit d'installer quelque chose, ça s'en souvient et ne me repose pas la question sans arrêt (merci Polkit). Y a pas à dire, c'est beau le progrès :D
Vous pourriez dire que c'est peut-être ma debian 9 stable mais alors, à l'eau l'argument d'universalité
Il ne faut pas oublier que Flatpak est encore jeune et qu'au moment de la sortie de Debian 9, cette dernière ne proposait qu'un Flatpak 0.8.9 encore en plein développement. Il y aura sans doute bien moins de problèmes avec la nouvelle Debian 10 et son Flatpak 1.2.4 (et tant pis si la version 1.4 est sortie entre temps, incluant tout plein d'améliorations).
Et pour conclure sur l'espace disque occupé et la bande passante utilisée, je ne sais pas trop. Si l'utilisation d'AppImage est exceptionnelle et que tu n'en a qu'un petit nombre, alors oui, ça occupe bien moins de place et préserve donc la bande passante.
Maintenant, sur le nombre, je me pose des questions. Exemple tout con. T'as une dizaine de paquets AppImage qui font en moyenne 60 Mo et qui incluent tous Qt. Tes dix installations totalisent en gros 600 Mo. On se dit que ça reste inférieur aux runtimes KDE et Freedesktop qui seraient sans doute nécessaires côté Flatpak.
Sauf que voilà. AppImage n'ayant pas un système similaire aux dépôts Flatpak qui se basent sur une technologie ressemblant à celle de git où chaque révision est archivée est disponible indépendamment, si demain on découvre une faille dans Qt, il faudra re-télécharger la nouvelle version de tous les paquets AppImage (à moins que leurs mainteneurs respectifs n'aient que faire de la sécurité). T'es donc reparti pour télécharger 600 Mo (ce qui nous fait donc 1.2 Go depuis le début). Alors qu'avec Flatpak, ça ne mettra à jour Qt qu'une seule fois, sans avoir besoin de re-télécharger le runtime dans son ensemble. Ça ne sera donc l'histoire que de quelques Mo à tout casser.
Et l'histoire se répétera à chaque nouvelle faille qui entraînera une potentielle nouvelle version des paquets AppImage. 600 Mo + 600 Mo + 600 Mo…
Donc oui, les premières installations de Flatpak qui impliquent de télécharger de gros runtimes sont sans doute plus emmerdantes, mais sur la durée, je ne suis pas certain que ce soit si terrible que ça (tout en gardant à l'idée que la sécurité est bien meilleure et que la logithèque GNOME, contrairement à AppImage, peut être configurée pour ne pas récupérer les mises à jour quand on utilise une connexion mobile :p)
Je savais pas que tu pouvais bloquer une permission particulière à un logiciel qui le demande dans gnome software. Encore faut il que se soit fait comme il faut.
Cette partie n'est clairement pas terminée. La gestion des ressources et permissions des applications n'est arrivée que dans le dernier GNOME 3.32.
Tous les portails n'ont pas non plus été implémentés (par exemple, il manque le partage de contenu d'une application, pouvoir créer une alarme, accéder à l'agenda et aux contacts, prendre une photo depuis la webcam…). Et je sais encore moins où en sont les autres environnements. Donc pour le moment, histoire que les applications soient tout de même utilisables, j'ai cru comprendre que les développeurs Flatpak / mainteneurs Flathub étaient plutôt cool sur la questions de l'isolation et des droits accordés.
Dans le cas de Skype, il y a un accès complet à /dev, au réseau et au dossier personnel en lecture seule. Et pour le moment, on ne peut rien modifier.
Mais depuis le départ, l'idée, c'est tout de même qu'à terme, l'utilisateur puisse contrôler tout ça finement. Maintenant pour y arriver, il aura fallu créer ou modifier un certain nombre de projets (Flatpak, Wayland, PipeWire, les différents toolkits et environnements de bureau…). Parce qu'isoler une application, c'est simple, mais pouvoir lui accorder certains droits (quand l'utilisateur le décide) et interagir avec l'extérieur de la sandbox (le système, les périphériques, les autres applications…), si l'on veut que ce soit bien fait, c'est tout de suite plus compliqué.
Aujourd'hui, tout n'est pas encore en place, ce qui explique pourquoi certaines applications installées sous forme de Flatpak ne fonctionnent pas aussi bien qu'avec un paquet traditionnel non isolé. Mais à terme, ça devrait être transparent pour l'utilisateur (Apple y est bien arrivé avec toutes les applications macOS de l'AppStore) :D
Et pour finir sur le Flatpak de Microsoft, au moins je sais qu'ils n'auront pas modifié le code des dépendances pour y ajouter on ne sait trop quoi. Ça ne sera pas eux non plus qui géreront la maintenance de ces dernières. Reste l'application elle-même. Si elle est isolée et que tu lui accorde uniquement les droits que tu estimes nécessaires, ça sera toujours mieux que de lui laisser accéder à toutes tes données, avec tous les droits.
On peut prendre le cas de Spotify. C'est une application propriétaire pour accéder à un service propriétaire de streaming musical. Tu peux lui laisser accéder au réseau et avoir un service fonctionnel, tout en bloquant tout le reste (localisation, webcam, microphone, dossiers personnels…), dont elle n'est pas censée avoir besoin pour fonctionner.
Dis-moi si je me trompe, mais avec AppImage, tu n'as aucune granularité. C'est tout ou rien.
Je ne disais pas ça par manque de respect. Juste qu'il faut être réaliste. S'il lui arrive une merde ou qu'il abandonne tout simplement son projet, l'utilisateur n'en sais rien.
Tant que l'application répond à ses besoins, il va continuer de l'utiliser sans se préoccuper du reste. Et ce, même si l'application ou ses dépendances contiennent des failles exploitables.
Tandis qu'avec Flatpak, la gestion des dépendances est confiée à une équipe dont c'est le rôle. Quant à l'application elle-même, étant isolée, ça réduit fortement les risques, même si ces derniers existeront toujours, on est d'accord.
Distrowatch ne mesure que le nombre de recherches sur le site Distrowatch et non pas leur utilisation réelle.
Dans le Steam Survey du mois de juin, Manjaro est à 8.62% (-0.29% par rapport au mois de mai). Et encore, les gamers linuxiens doivent être suffisamment débrouillards pour préférer ce type de distribution. Sur une utilisation pro ou familiale, je suis prêt à parier que les distributions comme Ubuntu écrasent tout le reste.
T'imagine vraiment des entreprises ou des particuliers néophytes opter pour des distributions de type rolling release ? C'est sans doute très bien pour des passionnés, mais je n'imagine pas un instant leur utilisation en milieu pro ou par des gens qui n'ont absolument pas envie de se prendre la tête avec l'outil informatique, préférant de loin que ce dernier s'efface le plus possible.
Triste époque, mais qu'est ce que tu veux que je te dise ?!
Rien, puisque à aucun moment, personne n'a parlé de sécurité absolue et inviolable.
Par contre, il y a une grosse différence entre aucune sécurité et zéro confiance (tous ceux qui proposent des paquets AppImage) et une sécurité qui ne sera sans doute jamais infaillible (Flatpak), on est d'accord, mais qui reste bien meilleure que la solution existante (les distributions dans leur forme actuelle, puisque même si elles sont réactives sur leurs propres paquets, elles ne peuvent proposer aucune garantie sur tout ce qui provient de sources tierces et encore moins sur toutes les applications propriétaires).
Pire encore, non seulement on ne peut avoir aucune confiance dans un paquet AppImage, mais surtout, puisque tout repose sur l'éditeur qui propose le paquet, à moins que ce soit géré par une grosse entreprise dont on peut relativement prédire qu'ils prennent les questions de sécurité au sérieux et qu'ils seront sans doute encore là demain, pour tous les autres, c'est prendre un risque inconsidéré sur la durée.
Prenons le paquet AppImage d'une petite application libre gérée par un unique développeur. Pas un gros projet à la Firefox ou LibreOffice. Le genre de petit projet qu'on trouve à foison sur GitHub, qui sont loin d'être toujours empaquetés dans les distributions et pour qui ce genre de paquet universel est une très bonne chose (ou en tout cas, devrait l'être).
Maintenant, admettons que ce petit projet nous propose un paquet AppImage. On le récupère, on l'installe (en espérant qu'ils n'aient pas oublié de dépendances, puisque apparemment ça semble être possible :p), tout fonctionne bien, on est content. Demain, il arrive une merde au développeur ou il abandonne tout simplement son projet. Si des failles sont découvertes dans la foulée dans les différentes dépendances, elles ne seront jamais corrigées dans le paquet.
Et c'est bien là tout le souci. Vouloir confier la gestion de la sécurité, non pas uniquement de leur application, comme le propose Flatpak, mais également de l'ensemble des dépendances de l'application, à des développeurs dont ça ne sera pas forcément le métier et qui n'auront pas forcément le temps ou l'envie de s'en occuper.
Et encore une fois, non, on ne peut pas garantir qu'un développeur n'inclura pas volontairement ou non des merdes dans son paquet Flatpak. Mais ça sera la même chose pour un paquet AppImage, qui aura potentiellement en plus tout plein de failles dans ses dépendances.
Ton raisonnement revient donc à dire que puisque la sécurité absolue est un rêve impossible, alors ce n'est même pas la peine d'essayer de l'atteindre et qu'il vaut mieux se contenter d'une solution bien moins efficace, mais qui occupera potentiellement un peu moins de place sur le disque…
Oui, il se peut qu'avec une petite dizaine d'AppImage installés, ce dernier l'emporte haut la main sur l'économie de place. Maintenant, dans quelques années, quand j'aurai une soixantaine de Flatpak installés (qui, à mon avis, ne dépendront que d'un petit nombre de runtimes), est-ce que ça sera encore le cas, je ne saurai dire. Peut-être que ça sera pire encore. Ou pas :)
Mais ce que je vois surtout, c'est que comme beaucoup, tu ne te focalises que sur l'espace disque occupé. Mais est-ce réellement important, quand les SSD et les disques traditionnels sont toujours plus gros ? Surtout par rapport aux questions de sécurité auxquelles tu n'as pas répondu. Toi-même, puisque tu sembles développeur et proposer des AppImage de tes applications, est-ce que tu te considères comme étant particulièrement attentif et réactif concernant les questions de sécurité des dépendances que tu fournis dans ton AppImage ? Et est-ce que tu peux garantir que tous les autres éditeurs qui proposent des AppImage le seront également ?
Je ne sais pas toi, mais je fais tout d'abord confiance à ma distribution, que je sais réactive sur les questions de sécurité (et sur ce point, toutes les distributions sont loin de se valoir). Ensuite à l'équipe en charge de la maintenance et de la sécurité des runtimes Flatpak. D'autant plus que c'est un projet libre et ouvert et qu'on peut voir tous leurs commits.
Par contre, en tout dernier, bien loin derrière, je mettrais toutes les applications propriétaires proposées par les éditeurs eux-mêmes, ainsi que les AppImage, que je compare à un binaire sorti d'on ne sait où. Par exemple, Molotov propose un AppImage de son application propriétaire. Si demain on découvre une faille dans une bibliothèque qu'ils utilisent. Je n'ai aucun doute que les développeurs upstream ainsi que ma distribution et l'équipe derrière les runtimes Flatpak seront réactifs à corriger le problème, mais Molotov ? Est-ce qu'ils sortent bien un nouvel AppImage incluant les correctifs à chaque fois qu'une faille est corrigée dans une dépendance ou est-ce qu'ils ne vont pas plutôt attendre la prochaine version de leur application pour mettre à jour les bibliothèques dans la foulée ?
En tant qu'utilisateur, comment être certain que la sécurité est bien gérée sur l'ensemble des AppImage installés ? T'en sais rien et tu te contentes de faire bêtement confiance à autant d'acteurs que t'as installé de paquets AppImage ?
À l'inverse, les Flatpak pouvant être utilisés par l'ensemble des distributions, si ce n'est pas déjà le cas, on peut espérer qu'en plus de GNOME, KDE et Freedesktop, les équipes sécurité des principales distributions allouent des ressources à la maintenance des runtimes Flatpak.
Ça fait tout de même le tiers, juste pour une bibliothèque. Et toutes les applications ne seront pas forcément pures Qt ou Gtk+. Certaines peuvent très bien avoir des dizaines de dépendances, ce qui risque de vite chiffrer. T'imagine une application GNOME ou KDE qui devrait inclure tout le nécessaire dans son AppImage ?
D'autant plus qu'un certain nombre de distributions (Ubuntu, Fedora…) se dirigent de plus en plus vers une solution où l'ensemble des applications seront fournies sous forme de Snap ou de Flatpak avec des dépôts qui ne proposeront également que ça.
Il ne faut donc pas voir la situation actuelle où d'installer ses deux ou trois premières applications Flatpak peut paraître disproportionné au regard du poids des runtimes qui les accompagneront, mais plutôt se dire que dans le futur, les systèmes Linux occuperont effectivement quelques gigas de plus qu'actuellement, mais qu'en contrepartie, on aura réglé le problème de la distribution des applications ainsi que celui de la compatibilité ascendante et descendante qui, contrairement à Windows, n'a jamais été le fort de Linux.
Cela prendra forcement toujours plus de place par rapport a installer un package liés dynamiquement aux libs de l'OS installé. Surtout que si je veux installer un truc Gnom 3.12 puis un autre Gnome 4.0 puis un autre KDE etc les runtimes vont etre multiplié.
Si tu utilises une distribution particulièrement à jour, sans doute. Mais par exemple, sur une CentOS que les utilisateurs garderont potentiellement entre cinq et dix ans, tu lies facilement et dynamiquement une application récente qui utilise les toutes dernières technologies à la mode avec les bibliothèques de ton vieux système ?
Et quand je vois la taille d'un paquet appImage avec celui de flatpak ca fait un peu mal au c..
AppImage, c'est bien le système de paquets qui n'utilise pas de runtimes et qui fournit donc toutes les bibliothèques nécessaires dans chaque paquet ? Donc si t'installes dix applications utilisant Qt, ça t'installe dix fois Qt ? Génial. Et puisque les bibliothèques sont fournies par l'éditeur de l'application dans le paquet AppImage, ça signifie donc que c'est ce même éditeur qui est en charge de la maintenance de toutes ses dépendances ? Génial.
Alors oui, un runtime Flatpak installera potentiellement bien plus de dépendances que ton application a besoin, puisque ça couvre un ensemble de besoins. Mais je trouve cette solution bien plus saine et plus sûre, puisque la maintenance est gérée par une équipe dédiée (ce qui est comparable à la sécurité des distributions) et non pas à la charge de chaque éditeur, dont certains seront sans doute sérieux et se préoccuperont des problématiques de sécurité, quand plein d'autres n'en auront que faire ou traîneront des pattes avant de corriger un problème.
Si encore, t'avais les trucs un peu "rares" comme bookworm ou autres projet sur github qui ne sont pas nécessairement accèssible sur une Debian stable/Ubuntu LTS ou galère à compiler mais ce n'est pas le cas.
Maintenant, il faut aussi laisser le temps de voir la techno adoptée plus largement. Et de soutenir Flatpak et de demander aux développeurs de proposer une version Flatpak de leur application sera sans doute bien plus utile pour le projet. Plus il y aura de paquets (à jour), plus ça rendra cette techno incontournable, à mon avis.
Il y aussi l'absence de repo/store de référence et plutôt vides.
La référence, c'est Flathub. Qui vient d'ailleurs de franchir la barre des 600 applications. Alors bien sûr, on aimerai tous qu'il y en ai déjà plusieurs milliers et que tous les petits projets disponibles uniquement sous force de code source sur GitHub aient déjà droit à un Flatpak, mais encore une fois, ce n'est qu'une question de temps et de coup de main qu'on pourrait filer pour accélérer les choses.
Mais et surtout, il n'est en rien facile pour l'utilisateur finale.
Le dépôt Flathub peut facilement être ajouté à la logithèque de ta distribution (il me semble que Linux Mint le propose par défaut). Dans tous les cas, ça s'ajoute en deux clics, et les applications du dépôt s'installent ensuite aussi facilement que n'importe quel autre paquet de la distribution : une simple recherche puis cliquer sur Installer. On peut difficilement faire plus simple.
Flatpak est justement particulièrement intéressant pour les distributions type Debian stable, Ubuntu LTS ou CentOS, où l'on a une base robuste avec un noyau qui ne change pas toutes les semaines. Et dans le même temps, la possibilité d'installer des applications récentes.
Et personne ne dit que ça doit concerner toutes les applications. Celles fournies avec la distribution, même si elles sont dépassées, peuvent très bien répondre parfaitement à tes besoins. Mais il se peut aussi qu'un jour t'aies besoin de fonctionnalités qui ne seront disponibles que dans une version plus récente. Ou tout simplement d'une application non présente dans ta distribution.
Je suis personnellement remonté par flatpak par ce que c'est plus compliqué que les deux autres réunis, en plus d'être affreusement inefficace.
Renault pourra sans doute apporter plus d'informations à ce sujet, mais j'ai récemment lu que Fedora travaillait à améliorer l'infrastructure pour construire des Flatpaks à partir de RPMS et automatiser ce qui pouvait l'être. Avec pour objectif de pouvoir proposer certaines applications sous forme de Flatpak dans une prochaine Fedora et sans doute à terme, y proposer toutes les applications sous cette forme.
J'imagine donc que dans le futur, de construire un RPM proposera également simultanément un Flatpak en sortie. On ne pourra donc plus dire que c'est compliqué :D
Puis bon, faut se dire que la technologie est encore récente. Que ce soit l'outil Flatpak en lui-même ou sa documentation, il doit encore y avoir moyen de grandement améliorer et simplifier les choses.
C'est con, parce qu'une fois que t'as installé les runtimes, que t'installes un ou cinquante logiciels, ça n'occupera pas plus de place :D C'est vraiment pour les 2-3 premiers logiciels installés, que ça peut paraître disproportionné.
Vous allez maintenant faire confiance à Skype par ce que sa version de curl est à jour ??? Qui a pensé que la communauté allait régler le problème des gens et sociétés qui refusent de mettre à jour leur applis ?
curl, comme un bon paquet d'autres projets, fait parti du runtime / sdk Freedesktop. Ce dernier est maintenu par toute une équipe (et comme pour n'importe quel projet libre, tout le monde peut y contribuer).
Que du coup j’ai vraiment pas compris. Et que maintenant mon app elle pèse 1 Go.
Bah non. Ton application ne pèse toujours que 5 Mo. C'est la même chose avec le système de paquets de la distribution de ton utilisateur, si ce dernier n'a pas encore toutes les dépendances demandées par ton application. Peut être qu'il ne lui manque que Qt, mais peut être qu'il lui manque un bon paquet de dépendances. Ben là c'est pareil. Peut être que ton utilisateur avait déjà installé le runtime qui lui avait été demandé par une autre application, et qu'au final il n'aura donc eu besoin de télécharger que les 5 Mo de ton application.
Et si on met à jour une lib dans le runtime… J’espère que vous avez la fibre.
Les dépôts Flatpak sont similaires aux dépôts Git. Toutes les modifications sont archivées, ce qui permet de ne récupérer que la différence entre deux versions. Lors d'une mise à jour du runtime, tu ne récupère donc que les changements depuis ta précédente mise à jour, ce qui est bien plus rapide et efficace.
Après si l’histoire nous à appris quelque chose avec Android c’est que… le mec va cliquer sur oui. Toi même tu sais.
Même si l'on trouvera toujours des gens pour s'en foutre, on ne peut pas non plus généraliser. D'autant plus que les applications / extensions de navigateur qui demandent bien plus de droits qu'elles n'en ont réellement besoin sont de plus en plus mal vues, je trouve. Faut pas croire, de plus en plus de gens commencent à s'inquiéter de leur vie privée (même si c'est paradoxal de les retrouver en masse sur Facebook, mais c'est une autre histoire).
En attendant, je trouve ça bien que l'on propose enfin une gestion bien plus fine des droits par application pour ceux que cela intéresse.
# Grand public
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Flatpak et Nix. Évalué à 7.
Je n'ai jamais utilisé Nix, mais par rapport à tes exemples qui utilisent tous la ligne de commande, Flatpak s'intègre bien avec les logithèques graphiques des différents environnements de bureau (c'est le cas pour GNOME, KDE, Cinnamon, Pantheon…). On peut donc facilement ajouter un dépôt comme Flathub en deux clics de souris et ensuite rechercher et installer une application tout aussi facilement.
Pour des applications réellement isolées, d'avoir une gestion des permissions au sein de l'environnement de bureau permettant à l'utilisateur d'avoir un retour graphique et de pouvoir facilement faire son choix (l'application que vous venez d'installer souhaite pouvoir accéder à la webcam, souhaitez-vous l'autoriser…) est très important. L'utilisateur doit pouvoir facilement accorder ou révoquer des droits à tout moment.
Le développement de Flatpak est actif. La version 1.6.0 est sortie la semaine dernière et apporte, entre autre, la prise en charge des contenus protégés, ce qui devrait permettre, à terme, de pouvoir acheter des contenus (applications commerciales). Tous les utilisateurs ne sont pas forcément des libristes convaincus et certains voudront pouvoir acheter le dernier jeu à la mode ou une application propriétaire qui répondrait mieux à leurs besoins que son équivalent libre.
À mon avis, si Flatpak risque de remporter le match, c'est qu'il est massivement adopté (projet Freedesktop, donc plus ou moins un standard dans le Libre) et qu'il s'intègre bien dans les écosystèmes (bonne documentation, intégration dans les environnements de bureau, que ce soit pour l'installation/désinstallation des paquets ou la gestion des droits, la prise en compte des besoins des différentes parties, développeurs / éditeurs et utilisateurs finaux…)
Nix était peut être là dix ans plus tôt, mais est-ce qu'ils ont cherché à s'intégrer aux environnements de bureau, à prendre en compte les besoins des différentes distributions, des éditeurs commerciaux… ou est-ce qu'ils n'ont pas cherché à voir plus loin que leur propre communauté ?
# AppStream et Flathub
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche Wavbreaker 0.12 est sorti : suites d’un journal ;-). Évalué à 5.
Je ne sais pas si ça a été ajouté depuis, mais la vieille version est bien présente dans les dépôts de Fedora, mais n'apparaît pas dans la logithèque GNOME (il en va sans doute de même pour les autres environnements). Il faudrait donc fournir des métadonnées AppData pour que les utilisateurs puissent plus facilement trouver l'application et qu'elle soit bien présentée (description (potentiellement dans la langue de l'utilisateur), captures d'écran…)
Puis comme le changelog de la version 0.13 semble indiquer qu'on peut désormais construire un Flatpak à partir des sources, ça ne serait pas plus mal d'envoyer une version officielle sur Flathub.
[^] # Re: Fedora spin et KDE
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche Fedora 31 est sortie !. Évalué à 4.
Sur Fedora Packages on trouve plasma-desktop 5.16.5 pour la Fedora 31.
[^] # Re: aficionadios
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.34. Évalué à -3.
Ça reste tout de même un énorme gaspillage de ressources, quand on sait qu'il suffisait de deux extensions (Dash to Dock ou Dash to Panel + Arc Menu) pour retrouver cette fameuse métaphore de bureau traditionnelle sous GNOME, évitant ainsi de devoir redévelopper un nouvel environnement.
[^] # Re: Windows
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche Sortie du bureau léger Xfce 4.14. Évalué à 1.
C'est pourtant indiqué sur la page que j'ai donné (« Based on Ubuntu 18.04.2 LTS with Hardware Enablement (HWE) stack ») ainsi que sur la page d'accueil de la distribution (« Built on an Ubuntu Linux foundation »).
Chez Linux Mint, aucune référence sur la page d'accueil, il faut aller sur la page About Linux Mint. Mais on retrouve bien la référence dans la page des nouveautés de la dernière version (« Linux Mint 19.2 features Cinnamon 4.2, a Linux kernel 4.15 and an Ubuntu 18.04 package base. »)
C'est kif kif et je trouve qu'il faut vraiment être de mauvaise foi pour dire qu'il faut fouiller pour y trouver une référence.
[^] # Re: Windows
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche Sortie du bureau léger Xfce 4.14. Évalué à 2.
Les mêmes paradigmes que l'on peut obtenir sur n'importe quel environnement de bureau, y compris GNOME avec Arc Menu et Dash to Panel…
Et pour tout ceux qui n'aiment pas bidouiller et préfèrent un environnement prêt par défaut, il existe des distributions telles que Zorin OS qui proposent tout ça clé en main.
[^] # Re: Flatpak vers le cloisonnement du bureau
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 1.
Si tu fais référence à Microsoft et Apple, le second semble suivre le même chemin que nous : Sécurité : macOS Catalina restreint encore les permissions des apps.
[^] # Re: Flatpak vers le cloisonnement du bureau
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
J'imagine qu'il y a moyen de faire en sorte que les applications ne puissent plus aller espionner le presse-papier à leur guise comme elles peuvent le faire actuellement, tout en laissant la possibilité à l'utilisateur de faire des copier-coller entre applications. De façon transparente, comme aujourd'hui, mais uniquement quand il s'agira d'une action de l'utilisateur.
[^] # Re: Séparation app / système
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Par défaut (c'est configurable), la logithèque GNOME met automatiquement à jour les Flatpak.
[^] # Re: Sans moi
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Il faudra également envoyer un mail au mainteneur du paquet Mumble :
./Mumble-41b2655-x86_64.AppImage: error while loading shared libraries: libjack.so.0: cannot open shared object file: No such file or directory
Je serais d'ailleurs curieux de connaître le pourcentage de paquets AppImage dysfonctionnels :D
[^] # Re: Sans moi
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Pour toute la partie concernant l'installation de Flatpak et du dépôt, ça pourrait être grandement facilité par la distribution. Certaines (Fedora, Linux Mint…) intègrent déjà Flatpak par défaut. Maintenant, à moins que le wiki officiel de Debian ne soit pas à jour, malgré la sortie récente de Debian 10, il semblerait qu'ils ne fournissent toujours pas Flatpak et le greffon associé de la logithèque GNOME par défaut, ce que je trouve être une occasion manquée.
En ce qui concerne le dépôt, sans aller jusqu'à le configurer par défaut comme le fait Linux Mint, si l'étape précédente avait été faite, tout comme pour Fedora, il n'aurait suffi que d'un clic sur un gros bouton bleu pour lancer la logithèque et permettre la configuration du dépôt.
Je ne vais pas revenir sur toutes les commandes tapées dans un terminal et la nécessité d'en lancer certaines avec sudo, ça serait conforter certaines personnes dans leur croyance qu'encore aujourd'hui, sous Linux, il faut tout faire en ligne de commande /o\ De mon côté, je passe uniquement par la logithèque GNOME et peux donc tout faire à la souris. Puis quand il y a besoin de m'authentifier pour prouver que j'ai bien le droit d'installer quelque chose, ça s'en souvient et ne me repose pas la question sans arrêt (merci Polkit). Y a pas à dire, c'est beau le progrès :D
Il ne faut pas oublier que Flatpak est encore jeune et qu'au moment de la sortie de Debian 9, cette dernière ne proposait qu'un Flatpak 0.8.9 encore en plein développement. Il y aura sans doute bien moins de problèmes avec la nouvelle Debian 10 et son Flatpak 1.2.4 (et tant pis si la version 1.4 est sortie entre temps, incluant tout plein d'améliorations).
Et pour conclure sur l'espace disque occupé et la bande passante utilisée, je ne sais pas trop. Si l'utilisation d'AppImage est exceptionnelle et que tu n'en a qu'un petit nombre, alors oui, ça occupe bien moins de place et préserve donc la bande passante.
Maintenant, sur le nombre, je me pose des questions. Exemple tout con. T'as une dizaine de paquets AppImage qui font en moyenne 60 Mo et qui incluent tous Qt. Tes dix installations totalisent en gros 600 Mo. On se dit que ça reste inférieur aux runtimes KDE et Freedesktop qui seraient sans doute nécessaires côté Flatpak.
Sauf que voilà. AppImage n'ayant pas un système similaire aux dépôts Flatpak qui se basent sur une technologie ressemblant à celle de git où chaque révision est archivée est disponible indépendamment, si demain on découvre une faille dans Qt, il faudra re-télécharger la nouvelle version de tous les paquets AppImage (à moins que leurs mainteneurs respectifs n'aient que faire de la sécurité). T'es donc reparti pour télécharger 600 Mo (ce qui nous fait donc 1.2 Go depuis le début). Alors qu'avec Flatpak, ça ne mettra à jour Qt qu'une seule fois, sans avoir besoin de re-télécharger le runtime dans son ensemble. Ça ne sera donc l'histoire que de quelques Mo à tout casser.
Et l'histoire se répétera à chaque nouvelle faille qui entraînera une potentielle nouvelle version des paquets AppImage. 600 Mo + 600 Mo + 600 Mo…
Donc oui, les premières installations de Flatpak qui impliquent de télécharger de gros runtimes sont sans doute plus emmerdantes, mais sur la durée, je ne suis pas certain que ce soit si terrible que ça (tout en gardant à l'idée que la sécurité est bien meilleure et que la logithèque GNOME, contrairement à AppImage, peut être configurée pour ne pas récupérer les mises à jour quand on utilise une connexion mobile :p)
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 5.
Cette partie n'est clairement pas terminée. La gestion des ressources et permissions des applications n'est arrivée que dans le dernier GNOME 3.32.
Tous les portails n'ont pas non plus été implémentés (par exemple, il manque le partage de contenu d'une application, pouvoir créer une alarme, accéder à l'agenda et aux contacts, prendre une photo depuis la webcam…). Et je sais encore moins où en sont les autres environnements. Donc pour le moment, histoire que les applications soient tout de même utilisables, j'ai cru comprendre que les développeurs Flatpak / mainteneurs Flathub étaient plutôt cool sur la questions de l'isolation et des droits accordés.
Dans le cas de Skype, il y a un accès complet à /dev, au réseau et au dossier personnel en lecture seule. Et pour le moment, on ne peut rien modifier.
Mais depuis le départ, l'idée, c'est tout de même qu'à terme, l'utilisateur puisse contrôler tout ça finement. Maintenant pour y arriver, il aura fallu créer ou modifier un certain nombre de projets (Flatpak, Wayland, PipeWire, les différents toolkits et environnements de bureau…). Parce qu'isoler une application, c'est simple, mais pouvoir lui accorder certains droits (quand l'utilisateur le décide) et interagir avec l'extérieur de la sandbox (le système, les périphériques, les autres applications…), si l'on veut que ce soit bien fait, c'est tout de suite plus compliqué.
Aujourd'hui, tout n'est pas encore en place, ce qui explique pourquoi certaines applications installées sous forme de Flatpak ne fonctionnent pas aussi bien qu'avec un paquet traditionnel non isolé. Mais à terme, ça devrait être transparent pour l'utilisateur (Apple y est bien arrivé avec toutes les applications macOS de l'AppStore) :D
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 3.
Et pour finir sur le Flatpak de Microsoft, au moins je sais qu'ils n'auront pas modifié le code des dépendances pour y ajouter on ne sait trop quoi. Ça ne sera pas eux non plus qui géreront la maintenance de ces dernières. Reste l'application elle-même. Si elle est isolée et que tu lui accorde uniquement les droits que tu estimes nécessaires, ça sera toujours mieux que de lui laisser accéder à toutes tes données, avec tous les droits.
On peut prendre le cas de Spotify. C'est une application propriétaire pour accéder à un service propriétaire de streaming musical. Tu peux lui laisser accéder au réseau et avoir un service fonctionnel, tout en bloquant tout le reste (localisation, webcam, microphone, dossiers personnels…), dont elle n'est pas censée avoir besoin pour fonctionner.
Dis-moi si je me trompe, mais avec AppImage, tu n'as aucune granularité. C'est tout ou rien.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 3.
Je ne disais pas ça par manque de respect. Juste qu'il faut être réaliste. S'il lui arrive une merde ou qu'il abandonne tout simplement son projet, l'utilisateur n'en sais rien.
Tant que l'application répond à ses besoins, il va continuer de l'utiliser sans se préoccuper du reste. Et ce, même si l'application ou ses dépendances contiennent des failles exploitables.
Tandis qu'avec Flatpak, la gestion des dépendances est confiée à une équipe dont c'est le rôle. Quant à l'application elle-même, étant isolée, ça réduit fortement les risques, même si ces derniers existeront toujours, on est d'accord.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Distrowatch ne mesure que le nombre de recherches sur le site Distrowatch et non pas leur utilisation réelle.
Dans le Steam Survey du mois de juin, Manjaro est à 8.62% (-0.29% par rapport au mois de mai). Et encore, les gamers linuxiens doivent être suffisamment débrouillards pour préférer ce type de distribution. Sur une utilisation pro ou familiale, je suis prêt à parier que les distributions comme Ubuntu écrasent tout le reste.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 1.
T'imagine vraiment des entreprises ou des particuliers néophytes opter pour des distributions de type rolling release ? C'est sans doute très bien pour des passionnés, mais je n'imagine pas un instant leur utilisation en milieu pro ou par des gens qui n'ont absolument pas envie de se prendre la tête avec l'outil informatique, préférant de loin que ce dernier s'efface le plus possible.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 0.
Rien, puisque à aucun moment, personne n'a parlé de sécurité absolue et inviolable.
Par contre, il y a une grosse différence entre aucune sécurité et zéro confiance (tous ceux qui proposent des paquets AppImage) et une sécurité qui ne sera sans doute jamais infaillible (Flatpak), on est d'accord, mais qui reste bien meilleure que la solution existante (les distributions dans leur forme actuelle, puisque même si elles sont réactives sur leurs propres paquets, elles ne peuvent proposer aucune garantie sur tout ce qui provient de sources tierces et encore moins sur toutes les applications propriétaires).
Pire encore, non seulement on ne peut avoir aucune confiance dans un paquet AppImage, mais surtout, puisque tout repose sur l'éditeur qui propose le paquet, à moins que ce soit géré par une grosse entreprise dont on peut relativement prédire qu'ils prennent les questions de sécurité au sérieux et qu'ils seront sans doute encore là demain, pour tous les autres, c'est prendre un risque inconsidéré sur la durée.
Prenons le paquet AppImage d'une petite application libre gérée par un unique développeur. Pas un gros projet à la Firefox ou LibreOffice. Le genre de petit projet qu'on trouve à foison sur GitHub, qui sont loin d'être toujours empaquetés dans les distributions et pour qui ce genre de paquet universel est une très bonne chose (ou en tout cas, devrait l'être).
Maintenant, admettons que ce petit projet nous propose un paquet AppImage. On le récupère, on l'installe (en espérant qu'ils n'aient pas oublié de dépendances, puisque apparemment ça semble être possible :p), tout fonctionne bien, on est content. Demain, il arrive une merde au développeur ou il abandonne tout simplement son projet. Si des failles sont découvertes dans la foulée dans les différentes dépendances, elles ne seront jamais corrigées dans le paquet.
Et c'est bien là tout le souci. Vouloir confier la gestion de la sécurité, non pas uniquement de leur application, comme le propose Flatpak, mais également de l'ensemble des dépendances de l'application, à des développeurs dont ça ne sera pas forcément le métier et qui n'auront pas forcément le temps ou l'envie de s'en occuper.
Et encore une fois, non, on ne peut pas garantir qu'un développeur n'inclura pas volontairement ou non des merdes dans son paquet Flatpak. Mais ça sera la même chose pour un paquet AppImage, qui aura potentiellement en plus tout plein de failles dans ses dépendances.
Ton raisonnement revient donc à dire que puisque la sécurité absolue est un rêve impossible, alors ce n'est même pas la peine d'essayer de l'atteindre et qu'il vaut mieux se contenter d'une solution bien moins efficace, mais qui occupera potentiellement un peu moins de place sur le disque…
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 3.
Oui, il se peut qu'avec une petite dizaine d'AppImage installés, ce dernier l'emporte haut la main sur l'économie de place. Maintenant, dans quelques années, quand j'aurai une soixantaine de Flatpak installés (qui, à mon avis, ne dépendront que d'un petit nombre de runtimes), est-ce que ça sera encore le cas, je ne saurai dire. Peut-être que ça sera pire encore. Ou pas :)
Mais ce que je vois surtout, c'est que comme beaucoup, tu ne te focalises que sur l'espace disque occupé. Mais est-ce réellement important, quand les SSD et les disques traditionnels sont toujours plus gros ? Surtout par rapport aux questions de sécurité auxquelles tu n'as pas répondu. Toi-même, puisque tu sembles développeur et proposer des AppImage de tes applications, est-ce que tu te considères comme étant particulièrement attentif et réactif concernant les questions de sécurité des dépendances que tu fournis dans ton AppImage ? Et est-ce que tu peux garantir que tous les autres éditeurs qui proposent des AppImage le seront également ?
Je ne sais pas toi, mais je fais tout d'abord confiance à ma distribution, que je sais réactive sur les questions de sécurité (et sur ce point, toutes les distributions sont loin de se valoir). Ensuite à l'équipe en charge de la maintenance et de la sécurité des runtimes Flatpak. D'autant plus que c'est un projet libre et ouvert et qu'on peut voir tous leurs commits.
Par contre, en tout dernier, bien loin derrière, je mettrais toutes les applications propriétaires proposées par les éditeurs eux-mêmes, ainsi que les AppImage, que je compare à un binaire sorti d'on ne sait où. Par exemple, Molotov propose un AppImage de son application propriétaire. Si demain on découvre une faille dans une bibliothèque qu'ils utilisent. Je n'ai aucun doute que les développeurs upstream ainsi que ma distribution et l'équipe derrière les runtimes Flatpak seront réactifs à corriger le problème, mais Molotov ? Est-ce qu'ils sortent bien un nouvel AppImage incluant les correctifs à chaque fois qu'une faille est corrigée dans une dépendance ou est-ce qu'ils ne vont pas plutôt attendre la prochaine version de leur application pour mettre à jour les bibliothèques dans la foulée ?
En tant qu'utilisateur, comment être certain que la sécurité est bien gérée sur l'ensemble des AppImage installés ? T'en sais rien et tu te contentes de faire bêtement confiance à autant d'acteurs que t'as installé de paquets AppImage ?
À l'inverse, les Flatpak pouvant être utilisés par l'ensemble des distributions, si ce n'est pas déjà le cas, on peut espérer qu'en plus de GNOME, KDE et Freedesktop, les équipes sécurité des principales distributions allouent des ressources à la maintenance des runtimes Flatpak.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
Ça fait tout de même le tiers, juste pour une bibliothèque. Et toutes les applications ne seront pas forcément pures Qt ou Gtk+. Certaines peuvent très bien avoir des dizaines de dépendances, ce qui risque de vite chiffrer. T'imagine une application GNOME ou KDE qui devrait inclure tout le nécessaire dans son AppImage ?
D'autant plus qu'un certain nombre de distributions (Ubuntu, Fedora…) se dirigent de plus en plus vers une solution où l'ensemble des applications seront fournies sous forme de Snap ou de Flatpak avec des dépôts qui ne proposeront également que ça.
Il ne faut donc pas voir la situation actuelle où d'installer ses deux ou trois premières applications Flatpak peut paraître disproportionné au regard du poids des runtimes qui les accompagneront, mais plutôt se dire que dans le futur, les systèmes Linux occuperont effectivement quelques gigas de plus qu'actuellement, mais qu'en contrepartie, on aura réglé le problème de la distribution des applications ainsi que celui de la compatibilité ascendante et descendante qui, contrairement à Windows, n'a jamais été le fort de Linux.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
Si tu utilises une distribution particulièrement à jour, sans doute. Mais par exemple, sur une CentOS que les utilisateurs garderont potentiellement entre cinq et dix ans, tu lies facilement et dynamiquement une application récente qui utilise les toutes dernières technologies à la mode avec les bibliothèques de ton vieux système ?
AppImage, c'est bien le système de paquets qui n'utilise pas de runtimes et qui fournit donc toutes les bibliothèques nécessaires dans chaque paquet ? Donc si t'installes dix applications utilisant Qt, ça t'installe dix fois Qt ? Génial. Et puisque les bibliothèques sont fournies par l'éditeur de l'application dans le paquet AppImage, ça signifie donc que c'est ce même éditeur qui est en charge de la maintenance de toutes ses dépendances ? Génial.
Alors oui, un runtime Flatpak installera potentiellement bien plus de dépendances que ton application a besoin, puisque ça couvre un ensemble de besoins. Mais je trouve cette solution bien plus saine et plus sûre, puisque la maintenance est gérée par une équipe dédiée (ce qui est comparable à la sécurité des distributions) et non pas à la charge de chaque éditeur, dont certains seront sans doute sérieux et se préoccuperont des problématiques de sécurité, quand plein d'autres n'en auront que faire ou traîneront des pattes avant de corriger un problème.
[^] # Re: Sans moi
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Bookworm est disponible sur Flathub.
Maintenant, il faut aussi laisser le temps de voir la techno adoptée plus largement. Et de soutenir Flatpak et de demander aux développeurs de proposer une version Flatpak de leur application sera sans doute bien plus utile pour le projet. Plus il y aura de paquets (à jour), plus ça rendra cette techno incontournable, à mon avis.
La référence, c'est Flathub. Qui vient d'ailleurs de franchir la barre des 600 applications. Alors bien sûr, on aimerai tous qu'il y en ai déjà plusieurs milliers et que tous les petits projets disponibles uniquement sous force de code source sur GitHub aient déjà droit à un Flatpak, mais encore une fois, ce n'est qu'une question de temps et de coup de main qu'on pourrait filer pour accélérer les choses.
Le dépôt Flathub peut facilement être ajouté à la logithèque de ta distribution (il me semble que Linux Mint le propose par défaut). Dans tous les cas, ça s'ajoute en deux clics, et les applications du dépôt s'installent ensuite aussi facilement que n'importe quel autre paquet de la distribution : une simple recherche puis cliquer sur Installer. On peut difficilement faire plus simple.
[^] # Re: Sans moi
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 3.
Flatpak est justement particulièrement intéressant pour les distributions type Debian stable, Ubuntu LTS ou CentOS, où l'on a une base robuste avec un noyau qui ne change pas toutes les semaines. Et dans le même temps, la possibilité d'installer des applications récentes.
Et personne ne dit que ça doit concerner toutes les applications. Celles fournies avec la distribution, même si elles sont dépassées, peuvent très bien répondre parfaitement à tes besoins. Mais il se peut aussi qu'un jour t'aies besoin de fonctionnalités qui ne seront disponibles que dans une version plus récente. Ou tout simplement d'une application non présente dans ta distribution.
[^] # Re: Sans moi
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 2.
Renault pourra sans doute apporter plus d'informations à ce sujet, mais j'ai récemment lu que Fedora travaillait à améliorer l'infrastructure pour construire des Flatpaks à partir de RPMS et automatiser ce qui pouvait l'être. Avec pour objectif de pouvoir proposer certaines applications sous forme de Flatpak dans une prochaine Fedora et sans doute à terme, y proposer toutes les applications sous cette forme.
J'imagine donc que dans le futur, de construire un RPM proposera également simultanément un Flatpak en sortie. On ne pourra donc plus dire que c'est compliqué :D
Puis bon, faut se dire que la technologie est encore récente. Que ce soit l'outil Flatpak en lui-même ou sa documentation, il doit encore y avoir moyen de grandement améliorer et simplifier les choses.
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 3.
C'est con, parce qu'une fois que t'as installé les runtimes, que t'installes un ou cinquante logiciels, ça n'occupera pas plus de place :D C'est vraiment pour les 2-3 premiers logiciels installés, que ça peut paraître disproportionné.
# Précisions
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 10.
curl, comme un bon paquet d'autres projets, fait parti du runtime / sdk Freedesktop. Ce dernier est maintenu par toute une équipe (et comme pour n'importe quel projet libre, tout le monde peut y contribuer).
Bah non. Ton application ne pèse toujours que 5 Mo. C'est la même chose avec le système de paquets de la distribution de ton utilisateur, si ce dernier n'a pas encore toutes les dépendances demandées par ton application. Peut être qu'il ne lui manque que Qt, mais peut être qu'il lui manque un bon paquet de dépendances. Ben là c'est pareil. Peut être que ton utilisateur avait déjà installé le runtime qui lui avait été demandé par une autre application, et qu'au final il n'aura donc eu besoin de télécharger que les 5 Mo de ton application.
Les dépôts Flatpak sont similaires aux dépôts Git. Toutes les modifications sont archivées, ce qui permet de ne récupérer que la différence entre deux versions. Lors d'une mise à jour du runtime, tu ne récupère donc que les changements depuis ta précédente mise à jour, ce qui est bien plus rapide et efficace.
Même si l'on trouvera toujours des gens pour s'en foutre, on ne peut pas non plus généraliser. D'autant plus que les applications / extensions de navigateur qui demandent bien plus de droits qu'elles n'en ont réellement besoin sont de plus en plus mal vues, je trouve. Faut pas croire, de plus en plus de gens commencent à s'inquiéter de leur vie privée (même si c'est paradoxal de les retrouver en masse sur Facebook, mais c'est une autre histoire).
En attendant, je trouve ça bien que l'on propose enfin une gestion bien plus fine des droits par application pour ceux que cela intéresse.