Bon, on peut pas dire que le TTS (Text To Speech) soit la joie sous Linux.
Si ce n'est pas déjà fait, n'oubliez pas d'aller contribuer sur Common Voice, projet Mozilla ayant pour but de concevoir un système de reconnaissance vocale libre, ainsi qu'une synthèse vocale de qualité.
Et comme ça manque cruellement de voix féminines, n'hésitez pas non plus à parler du projet aux femmes de votre entourage.
Non ; je parle de la liste des applications par défaut. Si tu veux ouvrir tel fichier dans une autre appli que celle définie dans la fenêtre de ta capture (ce qui arrive très souvent) alors tu vas devoir faire "ouvrir avec/autres applications", ça va ouvrir une fenêtre où tu vas avoir la liste des applis installées par ordre alphabétique (wtf) et ce à chaque fois. Jamais il mettra cette appli dans le menu, et non, même pas (? wtf, vmt) il la mettra en haut de ladite liste. Poubelle.
Quand je souhaite ouvrir une image avec GIMP plutôt qu'avec le visionneur d'images, je fais un clic droit, Ouvrir avec une autre application, et là, ça me propose la liste des applications susceptibles de répondre au besoin.
Ça fait bien longtemps qu'il n'y a plus une longue liste d'applications en vrac.
Pour rappel, Matrix permet de participer à des discussions de groupe, d'échanger des messages privés, de partager des fichiers, de passer des appels audio, de faire de la vidéoconférence, tout en proposant du chiffrement de bout en bout. Il existe également de nombreuses passerelles vers IRC, Slack, Telegram… Et ça peut également s'interfacer avec le système de gestion des identités et des accès de l'entreprise.
En solution clé en main avec une interface conviviale (il existe des clients pour toutes les plateformes), on peut citer Riot (gratuit) ou Modular (version commerciale de Riot, avec serveur dédié pour une meilleure qualité de service, assistance et autres garanties chères aux entreprises).
Pour les écolos, on peut également citer Ungleich, qui propose une offre commerciale zéro-carbone hébergée en Suisse.
Hello Matrix liste également un certain nombre d'instances publiques.
Pour se connecter à tout ça, on trouve une multitude de clients. Web, mobile (pour Android, il vaut peut être mieux tester directement RiotX, qui est une réécriture complète du client, toujours en bêta, mais que je trouve d'ores et déjà plus fonctionnel que la version stable), clients lourds pour différentes plateformes, tel que Fractal, qui est un client pour l'environnement GNOME…
Que ce soit flatpak ou apt / dnf, ce ne sont que des outils pour installer des paquets. Et comme ça t'a été répondu, il fallait soit indiquer à tes utilisateurs la commande pour installer le runtime manuellement, soit leur proposer d'activer le dépôt Flathub pour que la commande flatpak puisse trouver les dépendances nécessaires au bon fonctionnement de ton jeu (sur Fedora, ça se fait d'un simple clic de souris).
Tout comme ça n'aurait pas été plus mal de proposer ton jeu sur Flathub, ce qui lui aurait fourni une meilleure exposition (que ce soit sur ce site vitrine ou dans les logithèques de certaines distributions) qu'uniquement ton site officiel, qui implique de déjà en avoir entendu parler.
Pour la doc, ils sont conscients du problème. Après, comme d'hab avec le libre, il faut trouver des bénévoles motivés pour s'en occuper.
En attendant, si t'as des questions, tu dois pouvoir contacter Mat Booth (le mainteneur des extensions OpenJDKs pour Flatpak).
Non, parce que le libre c'est quand même l'entraide, la contribution, l'écriture de billets de blog explicatifs quand on a résolu un problème pour aider ceux qui pourraient le rencontrer à l'avenir… Ce qui est tout de même plus productif que de juste dire (encore et encore) à quel point on trouve ça nul :)
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.
# Common Voice
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Lancement de Gspeech 0.8. Évalué à 8.
Si ce n'est pas déjà fait, n'oubliez pas d'aller contribuer sur Common Voice, projet Mozilla ayant pour but de concevoir un système de reconnaissance vocale libre, ainsi qu'une synthèse vocale de qualité.
Et comme ça manque cruellement de voix féminines, n'hésitez pas non plus à parler du projet aux femmes de votre entourage.
[^] # Re: Anti humain
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.36 à la cool. Évalué à 8.
Quand je souhaite ouvrir une image avec GIMP plutôt qu'avec le visionneur d'images, je fais un clic droit, Ouvrir avec une autre application, et là, ça me propose la liste des applications susceptibles de répondre au besoin.
Ça fait bien longtemps qu'il n'y a plus une longue liste d'applications en vrac.
[^] # Re: Matrix.org et xmpp
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche Vie dématérialisée. Évalué à 2.
Pour rappel, Matrix permet de participer à des discussions de groupe, d'échanger des messages privés, de partager des fichiers, de passer des appels audio, de faire de la vidéoconférence, tout en proposant du chiffrement de bout en bout. Il existe également de nombreuses passerelles vers IRC, Slack, Telegram… Et ça peut également s'interfacer avec le système de gestion des identités et des accès de l'entreprise.
En solution clé en main avec une interface conviviale (il existe des clients pour toutes les plateformes), on peut citer Riot (gratuit) ou Modular (version commerciale de Riot, avec serveur dédié pour une meilleure qualité de service, assistance et autres garanties chères aux entreprises).
C'est d'ailleurs ce qu'a récemment choisi Mozilla, après 22 ans d'IRC. Pour ceux qui parlent anglais et que le sujet intéresse, ils ont expliqué leur choix dans une série de billets de blog : Synchronous Text, Forward Motion, Synchronous Messaging: We’re Live.
Pour les écolos, on peut également citer Ungleich, qui propose une offre commerciale zéro-carbone hébergée en Suisse.
Hello Matrix liste également un certain nombre d'instances publiques.
Pour se connecter à tout ça, on trouve une multitude de clients. Web, mobile (pour Android, il vaut peut être mieux tester directement RiotX, qui est une réécriture complète du client, toujours en bêta, mais que je trouve d'ores et déjà plus fonctionnel que la version stable), clients lourds pour différentes plateformes, tel que Fractal, qui est un client pour l'environnement GNOME…
[^] # Re: flatpak c'est nul
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Flatpak et Nix. Évalué à 2. Dernière modification le 26 décembre 2019 à 19:14.
Que ce soit flatpak ou apt / dnf, ce ne sont que des outils pour installer des paquets. Et comme ça t'a été répondu, il fallait soit indiquer à tes utilisateurs la commande pour installer le runtime manuellement, soit leur proposer d'activer le dépôt Flathub pour que la commande flatpak puisse trouver les dépendances nécessaires au bon fonctionnement de ton jeu (sur Fedora, ça se fait d'un simple clic de souris).
Tout comme ça n'aurait pas été plus mal de proposer ton jeu sur Flathub, ce qui lui aurait fourni une meilleure exposition (que ce soit sur ce site vitrine ou dans les logithèques de certaines distributions) qu'uniquement ton site officiel, qui implique de déjà en avoir entendu parler.
[^] # Re: flatpak c'est nul
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Flatpak et Nix. Évalué à 8.
Pour la doc, ils sont conscients du problème. Après, comme d'hab avec le libre, il faut trouver des bénévoles motivés pour s'en occuper.
En attendant, si t'as des questions, tu dois pouvoir contacter Mat Booth (le mainteneur des extensions OpenJDKs pour Flatpak).
Non, parce que le libre c'est quand même l'entraide, la contribution, l'écriture de billets de blog explicatifs quand on a résolu un problème pour aider ceux qui pourraient le rencontrer à l'avenir… Ce qui est tout de même plus productif que de juste dire (encore et encore) à quel point on trouve ça nul :)
[^] # Re: Interface CSS
Posté par Okki (site web personnel, Mastodon) . En réponse à la dépêche darktable 3.0 : une version plus que majeure !. Évalué à 3.
GTK+ prend en charge les CSS : GTK+ CSS Overview.
# 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.