FluffyHamster a écrit 252 commentaires

Il me semble que ce n'est pas le rôle du gestionnaire de fichiers de faire ça.

Disons que quand tout ce qu'il faut c'est un double clique, on va confier l'intégration à qui d'autre ? Et je te parle "que" de lancer (si tu veux pas l'inclure dedans) l'utilitaire d'appimage lors du double clique, pour l'instant (vu qu'on lui refuse l'intégration, que tu réclames pourtant) il scan les appels système pour s’intercaler sur le double clique des appimages.

Comme sur mac. On installe les paquets avec le finder (drag and drop dans le répertoire application, cqfd). Si tu veux continuer dans le bonne fois tu peux tenter d'argumenter que mac n'est pas KISS. Ou qu'un seul utilitaire est moins KISS que la solution flatpak ?

besoin de la bibliothèque libcrypt

Envoie un mail à Linus, si c'est pas inclus, c'est un bug du paquet !

J'ai trouvé un paquet flatpak (pitivi) qui ne se lançait pas, par ce qu'il n'avait pas le runtime nvidia, que j'étais apparemment le premier à tester à l'époque, je suis aller leur dire ça a été fixé dans la journée (au lieu de blamer sur linuxfr :-)…

Ça fait tout de même le tiers, juste pour une bibliothèque.

300 Mo pour 10 app ça te dérange, mais quand je t'ai cité 6 Go de runtime pour 5 app d'installées, la, ça t'as pas choqué ?

J'ai d'autre exemples alors. Une appli Qt 5 widget (plus l'applis et les resources graphiques) l'AppImage fait 22 Mo. Une bien plus grosse, qui à tous les modules de Qt, un service de cartographie, des libs en veut tu en voila, player et encodeur GStreamer et ffmpeg (c'est possible qu'il y ai deux ffmpeg à vrai dire…), l'appli en fait 60 Mo.

Est ce que tu trouves franchement que c'est déconnant ? Que pour le cas d'une app concrète et 100% indépendante, on arrive à… 60 Mo ? ça reste 5* moins que les apps electrons qui fleurissent sur flathub (alors qu'elles ont des runtimes).

Pourquoi personne ne pousse ces solutions ou ne fait le travail d'intégration nécessaire ? Pourquoi globalement le rejet de Flatpak revient à renier le besoin exprimé qui a donné lieu à la naissance de Flatpak ?

Pour l'exemple d'AppImage, ils ont un utilitaire minuscule qui, lors du premier double clique sur un fichier AppImage, déplace les fichiers AppImage au même endroit, les rends exécutable et créer les raccourcis, en plus des updates et de la désinstallation. Alors pour répondre à ta question, pourquoi ce n'est pas nautilus qui le fait directement ? Ça coûte pas grand chose, c'est déjà codé, et ça rentre même pas en conflit avec flatpak, leur solution.

Mais Gnome refuse d'intégrer cette fonctionnalité. Ça passe pas par le gestionnaire de paquet : c'est non. Ils en parlent régulièrement, ils l'ont bien en travers de la gorge, qu'on leur refuse l'accès aux distributions linux. C'est un problème culturel et non technique.
De la à dire qu'on refuse aux utilisateurs de linux un moyen très simple et très efficace et universel d'installer des applications, il n'y à qu'un pas que ça ne me dérange pas de franchir.

Le Logiciel Libre ce sont des gens qui codent et qui proposent des choses

Ha bon. Personne n'influe le développement de Gnome à part les insiders. Personne n'influe le développement de Fedora à part les insiders. Les gens qui codent des sites web ne sont pas les mêmes que ceux qui code le kernel. Ceux qui codent les applications ne sont pas les mêmes que ceux qui code les environnements de bureaux. Les uns subissent les décisions des autres.
Dans le journal d'a coté on à tenté de critiquer Canonical par ce qu'il ne voulait pas mettre à la benne sa propre solution pour choisir celle de RedHat. Le logiciel libre c'est pas les bisounours "propose, code et tout ira bien". Le logiciel libre, aujourd'hui, c'est les balkans.

Si ces outils sont si extraordinaires et puissants, comment ça se fait que vous ne parvenez pas à offrir ce que Flatpak propose ?

Je code des logiciels, ils sont pas dans les dépôts des distributions que je n'utilise pas, car il n'y à que 24h de dispo dans une journée. Le problème de flatpak je ne l'ignore pas, contrairement à ce que tu sembles sous entendre, mais je me le prends en pleine face.

Je propose des AppImages pour mes applications, je continuerai. Et je suis pas seul. A la différence de flatpak, ça marche (vraiment) chez tous le monde, et j'ai eu des commentaires "ho mon dieu comment t'as fait ça", alors qu'AppImage à 15 ans). Si faire des flatpak c'était facile je le ferai aussi. C'est pas le cas.

Le fait d'accepter que flatpak fonctionne et rend peut être service à des utilisateurs (ok) et le fait de dire que c'est une solution technique pourrie qui va sacrifier l'efficacité d'une distribution sans résoudre le problème sous jacent, ça peut être dé-corrélé ?

Le problème, c'est que 10 fois Qt c'est approximativement 330 Mo (source : 10x mes propres AppImage, qui ont tous pas mal de modules de Qt pourtant). On est au tier d'une seul version d'un seul runtime flatpak.

Pas mal d'OS ne font pas ce que Linux fait sur certains points, donc Linux est mal ?

Disons que les autres OS en tout cas, ils ont des parts de marchés, des utilisateurs, et des applis faciles à installer. Pour le reste, pas besoin de me tenter un sophisme…

C'est un délire par ce que rendre une application indépendante et partager ces dépendances avec d'autres applis, c'est contradictoire, et c'est une contrainte. De plus, aucun autre OS ne le fait, ça ne les empêches pas de faire des applications facilement distribuables : au contraire, ça le rend facile.

La sandbox tu l'utilise encore comme argument ultime, si t'es pas pour la sandbox de flatpak t'es contre. Je l'ai assez dis dans ce journal, le sandboxing c'est clairement quelque chose dont on devrai prendre plus souvent avantage, mais en réfléchissant avant.

Windows et son store étaient réservés aux applications avec une API radicalement nouvelle, et peut être que ces applis étaient sandboxées. Maintenant, rétropédalage, il est ouvert aux applis win32, et à ma connaissance non, aucune garantie de sandbox. Par contre ils ont effectivement fait le "windows sandbox" maintenant. Les applis démarrent dans une VM. Littéralement. Un nouveau bureau dans une fenêtre, avec ton appli dedans. Elles n'ont donc accès, à rien, et ne partage donc, rien, avec le système. Très pratique quand tu veux utiliser une appli que tu sais malveillante. Pour les autres, inutile car inutilisable.

Firefox qui ne dialogue pas avec le système ? Il prend son thème. Il dialogue par l'intermédiaire du press papier. Il utilise internet. Il lit des fichiers quand tu veux les envoyer sur facebook, il les enregistres quand tu veux une image de chat, il empêche ton écran de veille de s'enclencher quand tu es sur youtube (ou autre). Il utilise open gl et il doit maintenant linker avec le runtime nvidia (versionné…) car impossible d'utiliser celui du système à cause de la sandbox. Il dialogue avec lui même par IPC quand tu as des onglets ouvert dans deux fenêtres. Quand on regarde les nouvelles API web, ton navigateur à maintenant accès à l’accéléromètre, le GPS, les gamepads, les devices USB, et j'en passe…
Je suis sur qu'en réfléchissant un peu plus (ou si on a un spécialiste) on va pouvoir trouver beaucoup d'autre exemples.
Et tout ça, c'est des trous dans la sandbox. Ça doit être prévu, encadré, ou contourné, ou juste accepter de s’asseoir sur certaines fonctionnalités. C'est un retour en arrière au nom de la sécurité. C'est peu être louable pour les utilisateurs mais c'est surement pas un progrès pour les applications.

Les applications Android qui ne dialoguent pas entre elles ou avec le système ? Va relire les permissions à inclure dans leur manifestes : https://developer.android.com/reference/android/Manifest.permission.html toutes sont des interactions systèmes qui ouvrent des trous.

Les deux premiers points sont valides et résolut par AppImage d'une manière élégante, une solution existante.
Le troisième est un délire de linuxien, qui n'a rien à faire dans la problématique qu'on essai de résoudre (partager facilement des logiciels) et qui pourtant va finir par définir son fonctionnement.
Le dernier point, c'est un truc qu'on essaie de nous refiler, dont l’intérêt est loin d'être absolue (au sens, tout ce qui ne l'utilise pas est à jeter) et qui n'a également rien à faire dans la problématique. Windows ne le fait pas. macOS ne le fait que partiellement. Les téléphones le font car les applis ne parlent pas entre elles, ni avec le système. Et quand elles le font c'est uniquement car le système impose une API très carré en remplacement de ce que la sandbox empêche (ce qui n'est pas le cas chez nous).
En tant que développeur, ça pose des barrières, qui sont bien souvent résolues par "je désactive la sandbox" de toute manière, et partant de la on peut berner tout aussi facilement l'utilisateur.

Comme mentionné dans le journal, c'est juste réservé aux personnes qui ont 100 balles et qui veulent faire partie du programme payant "apple developer".
Les gros logiciels libres signent leurs packages aussi. Niveau sécurité ça n'apporte pas grand chose c'est sur, juste de savoir que le développeur avait 100€.

système, tu dois aller chercher le binaire sur le site officiel plutôt que de passer par un dépôt, tu n'as pas le lanceur accessible directement depuis le menu de ton environnement

Comme je me tue à le mentionner dans le journal et dans des commentaires, c'est même pas vrai ! Les appimage gèrent ça, et si c'est ce qui t'embête vraiment, installer le fichier .desktop depuis le script qui lance l'appli en .tar.gz, c'était relativement accessible aussi.
Et quand bien même, si le problème était "j'ai pas de raccourci", la solution était elle "je vais recréer un système de gestion de paquet" ?

ça n'occupera pas plus de place

mais c'est juste pas vrai… au minimum tu aura une seule duplication de ce qui est déjà dans ton système, au pire tu aura X copies… Comme Albert j'ai fais un flatpak list, et avec seulement quelques applications, j'ai halluciné. Chacun peu vérifier chez soi, c'est utile de le faire pour se rendre compte du problème sans attendre le popup de Gnome qui t'apprendra un jour que t'as plus de place sur ton disque.

J'avais déjà plusieurs versions des runtimes et plusieurs versions du driver nvidia aussi par exemple… Partant de la, il est ou le gain d'espace, et il est ou le gain de RAM avec 3 copies de la même lib ?

Il n'y a pas si longtemps que cela je me moquais de windows et de ses drivers wifi de plus de 1 Gigas. C'est super avec flatpak on va reussir a avoir la meme chose (cf le driver Nvidia)…

Au moins on aura plus besoin d'avoir honte à conseiller Windows 10 à notre entourage. "Tu verra c'est très efficace".

Il reste la solution de fournir un binaire entier en statique, mais cela ne résout pas la question du bac à sable que propose Flatpak, ni même l'intégration. Oui quand j'installe un logiciel je veux le voir dans les menus de mon bureau ou le retrouver facilement, alors qu'avec un .tar.gz avec le binaire précompilé tu dois te démerder pour placer le fichier .desktop voire le créer toi même. Super.

Et c'est expliqué dans le journal. Comme les .app de macOS, les AppImage "seuls", sans aucun support de la distribution, se lancent en un clique.
Avec un tout petit utilitaire qui fait 2 Mo (https://github.com/TheAssassin/AppImageLauncher), lors de leur premier lancement les AppImage se copient dans un répertoire commun, que tu choisis (/home/user/Applications c'est cool aussi) et installent le raccourci et icône qui est embarquée à bord du binaire. Et les sandboxer (avec firejail, comme mentionné en commentaire ou dans la doc d'AppImage) c'est aussi possible.

Alors, était il plus facile de généraliser ça, ou de construire une usine à gaz par dessus ?

Or, nous ce qu'on veut c'est jouer ensemble et rapidement, pas perdre du temps à les installer.

Et bien nous, on jouait à tee worlds. Les linuxiens allaient télécharger le .tar.gz avec tout dedans (il fait 8 Mo, pas 8 Mo + 1 Go, désolé). Les gens sur Windows et macOS, et bien franchement ils avaient même pas besoin de se poser la question…

Tous les problèmes que tu cite peuvent être résolut de plusieurs manières.
Paquet cross distribution : .tar.gz ou appimage ?
Version de firefox ou libreoffice : mettre à jour sa distribution ? distribution en rolling release ? .tar.gz ou appimage ? blamer à la fois ça distrib ET son gestionnaire de paquet ??
Complexité de deb ou rpm : Certe ! 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.

Donc la moralité c'est supprimer toutes les protections pour qu'on utilise nos 5 sens pour assurer la protection ?

La moralité c'est peut être plutôt de brandir la sandbox comme argument principal pour flatpak ? Pourquoi on ne peut pas débattre du bien fondé d'une fonctionnalité sans que se soit tu l'aime (comme les autres) ou tu la quitte ?

Mais cela ajoute une couche de sécurité légitime et essentielle.

Bien sur, il y à des protections dans le style sandbox que nos logiciels devraient tous avoir. Chaque logiciel devrait avoir un petit espace sécurisé dans lequel il peut stocker des choses sans que les autres logiciels puissent intervenir dessus par exemple. Qu'on puisse protégé notre .ssh/ sans forcer tous les logiciels dans une sandbox ultra contraignante, ce serai un progrès majeur.

Le vrai problème c’était surtout la simplicité à installer des logiciels qui ne sont pas dans la base de paquets de la distribution.

Oui !

on se retrouvera avec un runtime Gnome 3.35 à côté d’un 3.36 et d’un 3.37 et autant de versions de Qt, chacun de ces runtime tirant sur le gigaoctet

Bien entendu ! C'est déjà le cas !

Rajoute les runtimes de drivers nvidia qui rajoute 200 Mo plusieurs fois par an et c'est partit. Mon système Arch Linux fait 10 Go, mon répertoire flatpak faisait… 6 Go. En moins d'un an et même pas 5 logiciels d'installés. J'ai tout désinstallé, sauf le paquet flatpak de ma distrib. Problème, il utilise encore 554 Mo d'espace (???).

Mais comme on me l'a dis plus haut, j'ai raté le principal problème que veut résoudre flatpak : "le gaspillage de l'espace disque et de la RAM ". Allright.

Les gens ne cliquent pas sur oui par ce qu'ils sont cons, les gens cliquent sur oui par ce que lire et analyser une page de permissions (160 différentes dans les manifestes) pour chaque application (et de toute manière à la fin il faut cliquer sur oui) et bien personne ne le fait.

Maintenant ça à changé sur Android, déjà elles sont groupées pour en réduire dramatiquement le nombre (et avoir une chance de comprendre SET_ALWAYS_FINISH sans aller lire la doc https://developer.android.com/reference/android/Manifest.permission.html), et on valide les permissions sensibles au moment ou l'application essaie de s'en servir, pas avant.

Pareil pour la sandbox de flatpak, d'où l'application peut ouvrir n'importe qu'elle fichier sans l'autorisation de l'utilisateur ? Normalement, seuls les fichiers volontairement ouvert via le file chooser sont accédés.

D'ailleurs j'y pense que maintenant mais je fais une appli qui charge toute les vidéos et photos de l'utilisateur et de ces appareils connectés dans une grille. Elle fait quoi cette appli du coup, elle arrête linux ou il y a un moyen de désactiver la sandbox ?

Oui ça mérite plus qu'un journal.
C'est vrai pour le framework android bien sur. Les applis en java utilisent le SDK et la VM qui est sur chaque téléphone. Une appli compilé avec le NDK utilise surtout la libc qui est également dans le SDK, mais peut aussi appeler directement des composants java. Comme une appli mac n'est pas forcément indépendante, elle peut quand même linker avec une lib système, qui bouge pas entre les versions de l'OS (en tout cas, qui cassent pas la compatibilité).
Mais pour toute les autres librairies externes, qui peuvent être dupliqués dans plusieurs app chez ces autres OS, on ne cherche pas à les partager à tout prix, quitte à remettre un gestionnaire de paquet par dessus un autre.

Pareil pour la sandbox de flatpak, d'où l'application peut ouvrir n'importe qu'elle fichier sans l'autorisation de l'utilisateur ? Normalement, seuls les fichiers volontairement ouvert via le file chooser sont accédés.

Et bien tu vois je ne savais pas. macOS fonctionne comme ça aussi, c'est très bien. Pour l'enregistrement ça marche pareil ?

Et sans sandbox, tu croies qu'il y aurais combien de failles ???

Plus, bien plus. J'ai juste dis que les sandbox ce n'était pas magique, qu'est ce qui t'a fait penser que je voulais les supprimer ? S'il y a bien un point positif aux flatpak c'est le sandboxing.

Et ce sont deux failles de sandbox exploitées cette année ?! Une pour le lol et une en pratique.

En googlant une minute j'ai ca pour chrome, d'avril, directement de chez google : https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html

Et cette semaine chez Android, un malware qui va injecter du code dans les app d'à coté : https://www.theverge.com/2019/7/10/20688885/agent-smith-android-malware-25-million-infections

Ha pas bête, mais je viens d'en générer (de type apple development et apple distribution) et ils expirent l'année prochaine. C'est peut être un changement récent ?

J'ai envie de dire convainc moi. Le titre du journal est une question après tout.

Oui bien sur avoir un écosystème de distributions qui explorent des solutions différentes c'est important. Il faut faire attention à ne pas faire et refaire les mêmes choses en boucle. Des distributions il y en a des tas et je suis pas sur qu'elles aient toute quelque chose à dire.

Je vais même pas essayer de répondre point par point à ton commentaire.
La seule question qu'on devrai se poser, c'est qu'est ce qu'essaie de résoudre flatpak ?

Et vu que ça va me prendre une page, que ce n'est pas exactement l'objet de ce journal, et puis bien sur qu'on est vendredi… Je vais aller écrire un journal… Ça faisait longtemps…

Oui mais là, j'ai l'impression qu'avec des moyens en moins, l'objectif soit encore plus hors de portée.

Pas forcément un problème de moyen. Les stores ont des façades très simples justement, pas si difficiles à émuler. Sur Gnome Software je vois de grosses erreurs niveau UI/UX, comme une icone rouge pour indiquer le sandboxing (c'est une fonctionnalité de sécurité, pourquoi la marquer en rouge ?). Je vois des gros encarts rouges pour les logiciels propriétaires, sympa… La moitié des applis ont une description qui tient en deux lignes et pas ou peu de captures d'écrans, c'est dommage.

Ensuite les stores, ils permettent aussi (même surtout) de monétiser des applications. La, on en est ou ?
Devenir une vrai boutique d'application par contre c'est sur qu'il va falloir y mettre des moyens…

Je souris légèrement à ces réactions excessives du côté des développeurs chez Red Hat et GNOME.

Le tout premier commentaire sur l'article de phoronix résume bien le propos et m'a fait beaucoup rire :

Any excuse to remove a feature, GNOME will be there!