Journal Mais pourquoi flatpak ?

Posté par FluffyHamster le 12 juillet 2019 à 19:29. Licence CC By‑SA.

Étiquettes :

juil.

2019

Sommaire

La concurrence
Et chez nous alors ?
- Linux
- Le problème
- Snap
- Flatpak
Conclusion

Commençons par le problème : on veut des applications.
Quand bien même une application existe, avec son joli dépôt git hub/lab ou son site Internet, il nous faut encore un moyen de l'installer sur notre machine.

Plusieurs possibilités s’offrent à nous maintenant, mais regardons d’abord comment la concurrence résout ce problème.

La concurrence

Android

On va sur le store. On clique. C'est installé.
On peut diffuser des apk par nos propres moyens. On les signent avec une clé ce qui empêchera un autre paquet d'usurper le nôtre par la suite. Oui mais voilà, c’est maintenant caché derrière une option désactivée par défaut. L’avenir nous dira comment cette situation va évolué…

Techniquement :
- Les applis sont indépendantes les unes des autres, et en grande partie du système. Chaque appli embarque les dépendances dont elle a besoin.
- Les updates passent par un store.
- Tout est sandboxé par défaut. C’est solide… Autant que les autres systèmes de sandbox quoi…
- Chaque appli dispose d’un espace de stockage isolé pour stocker ses propres fichiers. Ensuite, si l’application veut des permissions (accéder à la caméra, à la carte mémoire…) elle doit demander explicitement la permission à l’utilisateur (avant, il suffisait de lister les permissions dans un manifeste et elles étaient inconditionnellement accepté).
- La rétro compatibilité est facile à gérer. On link avec un SDK Android "minimum" (encore aujourd'hui on peut choisir la 4.3 qui est vraiment vieille) et un SDK "visé" (en général on met le dernier, ça évite des problèmes).
- A noter que maintenant, Android privilégie les "app bundle" au lieu des "apk". C'est à peu près la même chose, mais par exemple on a un seul paquet pour toutes les architectures visées. C'est très bien pour les applis java (on économise de la place), ça oblige à faire des paquets X fois plus gros (car on multiplie tout sauf les ressources) si on fait une appli C++ (jeux vidéos, Qt, tout ça…)

macOS

Pareil… store, clique, installé.
On peut diffuser des app par nos propres moyens. Mais si on veut qu’elles s’installent, ils faut qu’elles soient signées avec une clé… à 100€ par an. Sinon, un peu comme le play store, il y a une option (bien mieux cachée) pour permettre l'exécution de chaque application non signée.
Ceci étant dit, on reste sur un système unix assez classique, il y a des binaires (ni signés ni sandboxés) plein le /usr/bin et on peut y mettre les nôtres

Techniquement :
- Les applis embarquent également toute leurs dépendances et empaquettent tout ça dans un très joli format exécutable. On drag and drop dans le bon dossier, on double clique, et quand on en veut plus on déplace le fichier dans la corbeille. Dur de faire plus facile vraiment…
- On peut sandboxer les applications. Celles distribuées sur l’app store le sont.
- Les .app peuvent se mettre à jour toute seule (avec ou sans le store).
- La rétro compatibilité est la encore facile. Comme sur Android, on spécifie une version minimum et visé du SDK mac. En général, on prend dernière version, moins 2 ou 3. Si vous voulez supporter un mac OS vieux de 5 ans, c’est possible. Mais les mises à jour de macOS sont gratuites et efficaces donc ce n’est pas vraiment un problème de viser assez haut.

Windows

On compile, on réunit les dépendances dans un dossier, on zip ou créer un installeur avec tout ça. On n’oublie pas de livrer et/ou installer les redists de Visual Studio, sinon… ça marchera moins bien.

Techniquement :
- Les vieilles applis restent compatibles avec les derniers Windows, c’est la grande force de la plateforme.
- Les nouvelles applis visent de moins en moins autres choses que Windows 10 (nouvelles APIs et limitations des anciennes suivant ce que vous faites), même si il vous est possible de garder la compatibilité Windows XP si ça vous branche.
- Une appli peut avertir l’utilisateur d’une mise à jour, télécharger et démarrer un installeur, c’est entièrement manuel donc on fait bien ce qu’on veut après tout.
- Pas de sandboxing ni rien.

iOS et le store Windows

Je connais pas assez.

Et chez nous alors ?

Linux

On se vante souvent de la supériorité technique de nos distributions et de leurs gestionnaires de paquets.
Après tout ils nous permettent d’installer des logiciels très facilement, gèrent leurs mises à jour, dépendances (et leurs mises à jour). Ils assurent la cohérence et la sécurité des systèmes.

Oui mais voilà. Quand un logiciel n’est pas dans un dépôt (ou que le dépôt contient une vieille version), et bien… c’est fini. Toi lecteur (et toi seulement) tu sortira peut être ton compilateur et ton couteau.
Mais les autres, ils vont partir sur Internet à la recherche d’un fichier à double cliquer. Seulement, ça ne marche pas comme ça.

Les logiciels de nos gestionnaires de paquets sont fortement couplés entre eux. Très fortement même. Si une nouvelle version d’un logiciel demande une nouvelle version d’une dépendance, en règle général, la distribution va attendre 6 mois et sa prochaine version avant de faire les mises à jour, plutôt que de risquer de casser quelque chose.

Ce couplage est rarement un problème car vu que l’écosystème entier est libre, et qu’on a les sources de tous les participants, et on peut compiler et recompiler à la volé pour parer aux problèmes d’ABI et patcher les problèmes d’API.
Certaines distributions comme Gentoo ou Arch font d’ailleurs tout ça en live. On n’a qu’une seule version de chacun des logiciels, et c’est la dernière. Pas de problème. Point barre.
Il y a ceux qui pensent que ça ne marche pas, que ce n’est pas stable, que c’est plus de boulot qu’une réinstallation tout les 6 mois. Et il y a ceux qui utilisent ces distributions (on est vendredi ou pas ?).

Le problème

Le problème, c’est que c’est chaque distribution pour soit alors ?
C’est pas faux. Pour diffuser un logiciel, chaque distribution doit l'empaqueter sinon ca coince (et tant qu’a faire, à la bonne version…). Et un développeur qui développe un petit logiciel n’aura pas le support des distributions et devra le faire lui même. C’est du boulot.

Donc le problème, c’est que sur linux, on ne peut pas compiler un logiciel, le packager, et le diffuser pour tout le monde alors ?
Mais justement. On peut. On prends une vieille distrib (lire, avec une vieille libc pour rester rétrocompatible) on compile ses dépendances, on met tout ça dans un zip, et c’est partit.
Si on veut distribuer un logiciel propriétaire d’ailleurs, et bien on peut faire comme ca. Un zip avec tout dedans. Et on clique sur le lancermonlogiciel.sh
Par ce qu’a vrai dire, on fait comme ça sur Windows. On met tout dans le même répertoire et on fais un raccourci.
On peut même mettre tout ça dans un installeur. Loki en avait un à l’époque (pour les portages de jeux proprios) Qt en à un maintenant (avec mise à jour et désinstallation intégré).

Alors le problème, c’est que c’est pas franchement efficace ?
Pas super efficace non, on ne réutilise rien de la distrib hôte. C’est aussi pour ça qu’on est compatible avec tout le monde. Par contre, bien souvent, vous trouverez la dernière version de Qt (ou autre) dans votre logiciel proprio, bien plus récente que celle de votre distrib. Le monde à l’envers ? Ho que oui.

Alors le problème, c’est que c’est pas franchement pratique ?
Quelques personnes se sont dis ça aussi, et ils ont créé le format AppImage. il y a loooongtemps. En 2004. On encapsule tout ce dont l’appli a besoin (binaire, dépendances, ressources) dans un seul fichier exécutable.
C’est excessivement facile d’usage. On peut en générer avec une seule commande. Pas besoin du logiciel AppImage pour lancer un AppImage, ce sont des binaires comme les autres !
On le télécharge (ou le distribus) à partir de la ou on veut, on l'exécute de la ou on veut. Il encapsule les metadatas comme la description, screenshots, icône, formats de fichiers gérés, et s’intègre donc tout seul dans le système (lire, le fichier desktop intégré se retrouve pris en compte par votre système). Certains se mettent à jours tout seul aussi. Ça vous fait penser aux applications macOS ? C’est normal.

C’est beau. Ça fait bizarre la première fois, car on ne s’y attend pas. A ce que ça marche…
Linus a testé pour son logiciel subsurface et en a chanté les louanges il y a bien longtemps. Mais qu’est ce qu’il y connait Linus à Linux ?

Mais alors, vraiment, c’est quoi le problème ?
Je sais plus.

C’est pas sécurisé.
HO MON DIEU. Pas plus que le reste. Alors arrêtons tout ?!

Le problème, il reste donc vague.
On sait que distribuer des paquets sous forme “tout compris” ça va de pas si compliqué à franchement facile. C’est comme ça que font les autres (ceux qui ont des parts de marché…) mais nous, on sait qu’on en veut pas.
On sait que la plus grande force des gestionnaires de paquets (couplage logiciels/libs et mises à jours centralisées) fait finalement leur plus grande faiblesse. Et qu’il y en a beaucoup, ce qui complexifie encore la situation.

Est ce qu’on veut que nos app soit facilement à distribuables et installables ?
Est ce qu’on veut que nos app restent compatibles entre toute les distribs (et dans les vieilles autant que celles qui ne soient pas encore sorties)
Est ce qu’on reste attaché à l’efficacité de nos systèmes, qui nous rends si fière ?

Snap

Je connais pas, je vais pas en parler non plus.

Flatpak

Mais maintenant, on a flatpak. C’est cool. C’est l’avenir. Mais on veut résoudre quoi au juste ???

- La facilité d'installation pour les utilisateurs ?
Un flatpak install XXX est il plus accessible qu'un apt-get install XXX ?
Aller ajouter des "repos" à la main avec "flatpak remote-add" est il mieux que d'aller ajouter des dépôts avec "add-apt-repository" ?
Aller cliquer dans Gnome Software est il plus facile que d’aller cliquer dans synaptic (ou celui que vous voulez) ?

Mieux qu’un double clique sur un AppImage ?

Et on ne peux toujours pas télécharger un flatpak et le stocker sur une clée usb pour l’utiliser ou le partager hors ligne. Par ce que les novices ils vont toujours avoir le reflex. Et pour cliquer sur “installer ce flatpak” et bien ils ont intéret d’avoir une distrib compatible.

C’est so 2009 de télécharger et d'exécuter son logiciel. Maintenant on à un store, comme les grands.

La facilité de packaging pour les développeurs libres ?
Un flatpak n’est pas plus simple à produire qu'un paquet lamba. Ok peut être plus simple que de produire X paquets pour X distribs. Après les outils progresseront sans doute, peut être qu’un jour on pourra faire “cmake && make && make flatpak”. En attendant, accrochez vous à la doc…
Par contre moi en plus de faire ubuntu, fedora, mint, gentoo, je dois faire un flatpak en plus. Naaan jdéconne. Je fais qu’un AppImage de toute manière.

La facilité de packaging pour les développeurs de logiciels non libres ?
Ceux qui jouent le jeu font habituellement un .deb, un .rpm et un .tar.gz. Ceux qui jouent pas le jeu vont subitement se mettre a flatpak. Merci flatpak.
Maintenant qui fait vraiment du flatpak dans les éditeurs proprio ? Sur Gnome Software j'ai trouvé Steam et Skype. Et pas mal de "wrapper" fait par la communauté. Super.

Est ce que c'est la sécurité des paquets ?
Pour la mise à jour des runtimes… on à toujours notre distribution qui fait la même chose, non ? Mieux même, car on ne duplique rien.

Est ce que c'est la sécurité des paquets logiciels non libres alors ?
Pour la mise à jour des runtimes… Ok. Soit. Si on pense que les problèmes de sécurités viennent principalement des dépendances (libres) des logiciels (propriétaires) alors il y a là un progrès.
Mais qui pensent ça ? Franchement ? 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 ?

Mais l’efficacité ?
C’est surtout la que je suis choqué. L’efficacité on peut oublier, c’était avant, maintenant on est dans le futur.
On peut aborder ce problème de pas mal de manière. Je pourrai vous dire que installer une seul application de 5Mo avec flatpak prends maintenant 5 Mo + 1 Go de runtimes. Je pourrai vous dire qu’avec 10 applications, vous avez potentiellement 10 Go de runtimes. Par ce qu’il y à plusieurs, et que votre paquet à linké avec telle version de telle runtime.
Je pourrai aussi vous dire que j’ai fais une app Qt (qui pèse 5 Mo d’ailleurs, 38 en AppImage) et qu’on m’a dit “utilise le runtime KDE”. Par ce que Qt, c’est KDE. Non ? Je pourrai vous dire que de toute manière, il manquait des dépendances dans les runtimes et qu’il est marqué “Flatpak makes it easy to bundle your own libraries as part of your app”. Que du coup j’ai vraiment pas compris. Et que maintenant mon app elle pèse 1 Go.
Et si on met à jour une lib dans le runtime… J’espère que vous avez la fibre.

Steam utilise un système similaire d’overlay. Sauf qu’il n’y en a qu’une seul version, et que si il manque une librairie, on ajoute… une librairie. Allez c’est même pas vrai, depuis 2013 ils ont ajouté une deuxième version. Ils ont donc seulement 800 Mo d’overlay, pour faire fonctionner des milliers de jeux vidéos. Depuis 2013.

Sandboxing
Ouai. C’est plutôt cool. C’est bien de limiter l’accès à quelques trucs, genre les fichiers de configs et temporaires des applis d'à coté. C’est bien de limiter l’accès à la webcam dans un éditeur de texte (vu qu’il tourne probablement sur electron dans un chrome, c’est même vraiment important).
Après si l’histoire nous à appris quelque chose avec Android (qui sandbox très bien, liste ses permissions et les demandes mêmes explicitement aux utilisateurs maintenant) c’est que… le mec va cliquer sur oui. Toi même tu sais.
Et puis le sandboxing ça s’arrête la ou les fonctionnalités commencent. Si tu fais un logiciel qui à besoin de l’accès aux fichiers (quelques logiciels font ça) ben ton sandboxing il va en prendre un coup…
Chrome est sandboxé depuis très longtemps, Android aussi. Si ça à empêcher quelques personnes de faire du mal, la littérature est maintenant abondante sur les limites de ces mécanismes. C'est pas magique. Du tout.

Si un logiciel ne mérite pas votre confiance, sandboxing ou non, il ne devrait pas tourner. N’essayons pas de résoudre un problème social avec la technologie.

Conclusion

La question est donc de savoir si l’on souhaite ou non démocratiser l’utilisation de GNU/Linux auprès du grand public.

Et si c’était le cas, on aurait pu réfléchir à rationaliser un peu ce bordel de distributions, on aurait pu réfléchir à ce qui bloque les vieux et les jeunes qui sont lâchés devant un Linux, on aurait pu s’atteler à boucher les trous béant à l’usage dans nos environnements de bureaux, on aurait pu capitaliser sur ce qui fait la force de notre plateforme et ce qui fait que se sont pourtant les autres qui sont utilisées.
Mais à la place, on a fait un nouveau gestionnaire de paquet. Bon vendredi à tous.

# Pas d'accord avec la fin

Posté par totof2000 le 12 juillet 2019 à 20:47. Évalué à 10.

Et si c’était le cas, on aurait pu réfléchir à rationaliser un peu ce bordel de distributions

Bof, pas sur que ça aurait permis à Linux de prendre. S'il n'y avait qu'une seule distribution, avec 1 seul bureau, 1 seul toolkit graphique, est-ce qu'elle aurait plu à tous les utilisateurs Linux d'aujourd'hui ? Je ne crois pas. Au final, Linux n'aurait peut-être pas percé comme aujourd'hui.

Mais à la place, on a fait un nouveau gestionnaire de paquet.

Pour moi l'intéret de ce genre de truc n'est que de pouvoir installer facilement des softs proprios. Pour le reste on pourrait s'en sortir autrement.
- [^] # Re: Pas d'accord avec la fin
  
  Posté par FluffyHamster le 12 juillet 2019 à 21:03. Évalué à 1.
  
  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.
  - [^] # Re: Pas d'accord avec la fin
    
    Posté par ekyo le 14 juillet 2019 à 15:26. Évalué à 10.
    
    Celles qui n'ont rien à dire meurent.
    De la même manière, si flatpack & co ne trouvent pas de public ciao.
    
    Pour ma part, je suis parfaitement comblé avec pacman + aur.
    Je ne suis pas le public visé.
- [^] # Re: Pas d'accord avec la fin
  
  Posté par jyes le 12 juillet 2019 à 21:30. Évalué à 9.
  
  Pour moi l'intéret de ce genre de truc n'est que de pouvoir installer facilement des softs proprios. Pour le reste on pourrait s'en sortir autrement.
  
  Je suis d’accord, sauf qu’on aurait pu penser qu’une solution à la Appimage + Firejail (ou un truc du genre) serait une bonne alternative à Flatpak. Quitte à ce que ce soit la communauté qui fournisse les wrappers pour les logiciels proprios dans des Flatpak, elle pu être mobilisée pour écrire leur « manifeste » pour un outil de sandboxing quelconque plutôt que de mettre la distribution en ligne, les dépendances, l’empaquetage et la sécurité dans le même outil.
  
  Après si la mayonnaise Flatpak prend, ce sera toujours ça de gagné mais je trouve le journal assez convainquant quant à la complexité inutile du bouzin.
- [^] # Re: Pas d'accord avec la fin
  
  Posté par Zenitram (site web personnel) le 12 juillet 2019 à 23:56. Évalué à 1.
  
  Allez, on est vendredi
  
  est-ce qu'elle aurait plu à tous les utilisateurs Linux d'aujourd'hui ? Je ne crois pas.
  
  Non, sans doute pas.
  Reste que le travail est dupliqué pour une qualité finale moindre.
  Je ne suis pas convaincu qu'avoir 10 desktops différents avec 10 personnes par desktop est mieux que laisser tomber 50 râleurs, motiver 40 à aller sur un desktop commun car finalement ils choisissaient pour dire de sans vrai argument, et avoir 1000 nouvelles personnes parce que ce desktop commun évolue plus rapidement.
  
  Au final, Linux n'aurait peut-être pas percé comme aujourd'hui.
  
  Linux a percé sur :
  - le serveur : car il y a des admins bidouilleurs
  - Android : car Google a justement fait une interface utilisateur pas admin correcte
  
  Sinon Linux s'est crashé : 1-2% de Linux sur bureau qui se battent en duel?
  
  Pour moi l'intéret de ce genre de truc n'est que de pouvoir installer facilement des softs proprios. Pour le reste on pourrait s'en sortir autrement.
  
  Ben non : il y a plein de logiciels libres pas empaqueté partout, et franchement ça gonfle d'avoir des logiciels libres mais pas utilisables car trop de travail à faire pour empaqueter partout.
  
  Dommage, Linux aurait pu marcher sur le desktop… Si les gens derrière avaient mis leur égo de côté et s'étaient mis d'accord sur des bases (genre LSB? Ha ben non, Debian veut toujours des .deb à la place de .rpm… par exemple).
  C'est un rendez-vous manqué, il n'y aura pas de nouveau Windows 8 pourri qui aurait pu faire motiver les gens à changer…
  - [^] # Re: Pas d'accord avec la fin
    
    Posté par raphj le 13 juillet 2019 à 10:18. Évalué à 7.
    
    Si mes souvenirs sont bons, deb est apparu avant rpm, je n'ai jamais trop compris pourquoi rpm a été choisi pour LSB.
    - [^] # Re: Pas d'accord avec la fin
      
      Posté par Cetera le 13 juillet 2019 à 11:22. Évalué à 9.
      
      Parce que Red Hat a forcé le choix pour caser sa propre techno comme standard ?
      - [^] # Re: Pas d'accord avec la fin
        
        Posté par Fabien PRORIOL le 15 juillet 2019 à 15:36. Évalué à 4. Dernière modification le 15 juillet 2019 à 15:36.
        
        Surtout qu'rpm n'apportait rien de nouveau par rapport au deb… Juste un format différent de plus, et la force de Red Hat pour essayer encore une fois d'imposer sa vision des choses… sans compter le "bordel" dans le monde RPM (RPM5 vs RPM4, yum vs zypper vs urpmi vs dnf…).
        
        [^] # Re: Pas d'accord avec la fin
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 15:43. Évalué à 7.
        
        De toute façon cela ne changerait pas grand chose d'avoir RPM ou DEB uniquement. Les incompatibilités entre les distributions ne sont pas dus uniquement à cette histoire de format, il y a la question du nommage des paquet, du découpage des dépendances, des versions de paquets proposées dans les dépôts et des choix dans les options de compilations et autres.
        
        Bref, même avec un standard sur la question, un logiciel serait difficilement installable partout.
  - [^] # Re: Pas d'accord avec la fin
    
    Posté par CHP le 15 juillet 2019 à 11:10. Évalué à 7.
    
    il n'y aura pas de nouveau Windows 8 pourri qui aurait pu faire motiver les gens à changer
    
    Des windows pourris, y'en a eu, y'en aura encore !
# +1000

Posté par Geppeto le 12 juillet 2019 à 21:04. Évalué à -2. Dernière modification le 12 juillet 2019 à 21:07.

Tout à fait d'accord. Concentrons nous sur debian, appimage, un environnement de bureau lourd et un léger avec customisation click bouton systématique, version lts pour les frileux et advance avec les nouveaux kernels. + Wine + steam des logiciels phares comme libre Office, firefox,… Avec des apis permettant la customisation facile (force de Linux =adaptabilité)

En faisant ça, gnulinux gagnera la population et les futures générations. Quand je vois la galère par exemple pour avoir un pad qui marche sur un portable avec libinput gesture , comment espérer séduire d'autres personnes que des geeks ??
# Si tous les gens autour de toi sont des cons ...

Posté par Colin Pitrat (site web personnel) le 12 juillet 2019 à 22:47. Évalué à 10.

Si quelque chose a du succès, est apprécié par des utilisateurs (qui en plus ne sont pas des ignares) et que tu ne comprends pas pourquoi, la solution c'est peut-être de creuser un peu plus plutôt que de te dire que tout le monde autour de toi est stupide ou atteint d'une soudaine lubie.

C'est dommage, parce que le journal commençait vraiment bien mais se détériore quand tu abordes les défauts d'AppImage (où tu rates le principal problème : le gaspillage de l'espace disque et de la RAM vu que les libs ne sont plus partagées) et part complètement en vrille quand tu atteints flatpak où visiblement tu as simplement raté sa raison d'être.
- [^] # Re: Si tous les gens autour de toi sont des cons ...
  
  Posté par YBoy360 (site web personnel) le 12 juillet 2019 à 23:04. Évalué à 4.
  
  Merci, je croyais être le seul ..
- [^] # Re: Si tous les gens autour de toi sont des cons ...
  
  Posté par FluffyHamster le 12 juillet 2019 à 23:05. Évalué à 10. Dernière modification le 12 juillet 2019 à 23:05.
  
  J'ai envie de dire convainc moi. Le titre du journal est une question après tout.
  - [^] # Re: Si tous les gens autour de toi sont des cons ...
    
    Posté par YBoy360 (site web personnel) le 13 juillet 2019 à 00:05. Évalué à 9.
    
    Le problème, c'est que je trouve ta description des différents modes de distribution d'application approximative et c'est un sujet qui nécessite du doigté. Pour te convaincre, il faudrait déjà tout mettre d'équerre…
    
    Par exemple, ton premier point technique sur Android est seulement approximativement vrai. Le SDK d'Android ressemble plus à un Framework complet qu'a la libc. Il est lui, partagé entre toutes les applications. Donc les applications ne sont pas si indépendante que ça, de plus le système d'Intent font que les applications utilise les composants d'autres applications.
    
    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.
    
    Pour Steam, on sait tous que les assets représente au bas mot 98% de l'espace nécessaire à un jeu vidéo, et que ceux-ci ne partage rien avec le monde extérieur, si ce n'est la SDL ou OpenGL. Que l’interaction entre Steam et un jeu vidéo, c'est à peu près peanuts. Qu'est-ce que Steam vient faire à propos de l'efficacité de Flatpak… ça n'a juste rien à voir!
    
    Bref, je cherche pas à te convaincre que flatpak c'est bien, juste qu'avec ton journal, on y voit vraiment pas clair.
    - [^] # Re: Si tous les gens autour de toi sont des cons ...
      
      Posté par FluffyHamster le 13 juillet 2019 à 00:54. Évalué à 4.
      
      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 ?
      - [^] # Re: Si tous les gens autour de toi sont des cons ...
        
        Posté par FluffyHamster le 13 juillet 2019 à 01:08. Évalué à 2.
        
        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 ?
        
        [^] # Re: Si tous les gens autour de toi sont des cons ...
        
        Posté par BAKfr le 17 juillet 2019 à 02:12. Évalué à 9.
        
        Il y a deux façons d'utiliser les fonctionnalités "bloquées" par la sandbox: soit en configurant les permissions, soit en passant par les portails.
        
        Les permissions de la sandbox sont configurables à deux endroits: coté dev, dans le fichier manifest (le fichier de build de Flatpak); coté utilisateur, c'est actuellement disponible uniquement en ligne de commande.
        Je ne sais pas où en est le projet, mais il me semble que la présentation et configuration de ces permissions pour l'utilisateur lambda était un des points prioritaire sur la roadmap du projet.
        
        Par exemple pour le système de fichier, on peut demander à utiliser tout le filesystem, le répertoire $HOME, ou bien un dossier avec un path précis. Le comportement par défaut étant d'avoir seulement quelques dossiers en écriture en utilisant la norme xdg-user-dirs.
        
        Les portails, c'est la fonctionnalité qui est intéressante. L'application va pouvoir demander une fonctionnalité au système en passant par des protocoles spécifiques (via dbus). Tout cela est intégré dans les principaux toolkits (Gtk, KDE) pour que ce soit transparent pour le dev. Il existe des portails pour ouvrir un fichier, afficher une notification, demander à imprimer, et ainsi de suite.
        
        Un exemple concret: un éditeur de texte dans une sandbox ne va pas définir de permissions particulières. Il va utiliser les fonctions traditionnelles de son environnement (par exemple GtkFileChooserNative avec Gtk).
        Gtk va détecter la sandbox et demander au système d'ouvrir le fichier pour lui. Le système (via flatpak ou les DE, je sais pas trop) va ouvrir une boite de sélection de fichier, qui sera hors sandbox.
        
        Ce qui est intéressant avec les portails, c'est que ça permet de découpler tout un tas de choses, même en dehors de flatpak. Récemment, Firefox a intégré un patch pour utiliser les portails pour enregistrer les fichiers. Du coup, sous KDE, on peut enfin avoir les boites de dialogues natives.
# macOS et certificat

Posté par Mathieu Schroeter (site web personnel, Mastodon) le 12 juillet 2019 à 23:00. Évalué à 4.

On peut diffuser des app par nos propres moyens. Mais si on veut qu’elles s’installent, ils faut qu’elles soient signées avec une clé… à 100€ par an.

A propos de macOS, il n'est pas nécessaire de payer 100$ par an. Il suffit la première fois de générer le certificat pour signer ses app, il a une date de validité de 5 ans. C'est ce que je fait, je paie uniquement 100$ pour 5 ans car je ne diffuse pas mes .app sur l'AppStore. Bien entendu, si on désire passer par l'AppStore, il faut payer chaque année; mais c'est une autre question.
- [^] # Re: macOS et certificat
  
  Posté par FluffyHamster le 12 juillet 2019 à 23:08. Évalué à 1.
  
  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 ?
  - [^] # Re: macOS et certificat
    
    Posté par Mathieu Schroeter (site web personnel, Mastodon) le 15 juillet 2019 à 07:09. Évalué à 0.
    
    Mon certificat est de 2017 et valable jusqu'en 2022. Donc si ca a changé c'est alors vraiment récent. Je te redirai après l'échéance en fin 2022 si c'est vraiment le cas 😳 Dommage…
- [^] # Re: macOS et certificat
  
  Posté par dinomasque le 15 juillet 2019 à 10:01. Évalué à 0.
  
  Comment diffuses-tu tes applications si ce n'est pas par l'AppStore ?
  C'est pas réservé aux entreprises ?
  
  BeOS le faisait il y a 20 ans !
  - [^] # Re: macOS et certificat
    
    Posté par FluffyHamster le 15 juillet 2019 à 10:24. Évalué à -1.
    
    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€.
  - [^] # Re: macOS et certificat
    
    Posté par groumly le 15 juillet 2019 à 14:51. Évalué à 3.
    
    Il parle du Mac App Store, pas celui d’ios.
    MacOS support 3 niveaux de sécurité: Mac AppStore only, Mac AppStore et développeurs “identifiés” (en gros appli signée par un compte enregistré chez pomme, mais distribué hors de l’appstore) et “n’importe quel binaire”.
    Je suppute qu’il parle du deuxième mode, “développeur identifiés”.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: macOS et certificat
      
      Posté par Mathieu Schroeter (site web personnel, Mastodon) le 15 juillet 2019 à 17:02. Évalué à 0.
      
      Exactement, c'est ainsi que je signe Planet Blupi (blupi.org) et donc le .app est téléchargeable (enfin le .dmg en fait) directement depuis le site.
      - [^] # Re: macOS et certificat
        
        Posté par FluffyHamster le 15 juillet 2019 à 17:12. Évalué à 0.
        
        OMG Colobot ! (avec un .AppImage en plus #keurkeurlove)
# Littérature

Posté par YBoy360 (site web personnel) le 12 juillet 2019 à 23:02. Évalué à 2.

J'aimerais avoir de la littérature sur les failles des sandbox d'Android et de Chrome, qui ne me fasse pas perdre mon temps, ne soit pas des ragots approximatif comme ce journal, qui ait moins de 5 ans, et qui n'ait pu être comblées.

Structurellement les Sandbox (hors failles cpu Intel) sont-elles bancale? ou c'est juste le besoin de s'la raconter au comptoir ?

On peut tous se logger en Root et lancer Gnome aussi…
- [^] # Re: Littérature
  
  Posté par FluffyHamster le 12 juillet 2019 à 23:13. Évalué à 3.
  
  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
  - [^] # Re: Littérature
    
    Posté par YBoy360 (site web personnel) le 12 juillet 2019 à 23:24. Évalué à -4.
    
    bidon
    
    pour 1, ce n'est que pour la version Windows, ça peut-être fixé, la surface est très faible….
    
    pour 2
    Check Point says a key vulnerability that Agent Smith relies on was patched several years ago in Android. But developers need to update their apps in order to take advantage of the added protections. Evidently, many have not.
    - [^] # Re: Littérature
      
      Posté par FluffyHamster le 12 juillet 2019 à 23:29. Évalué à 1.
      
      Et ce sont deux failles de sandbox exploitées cette année ?! Une pour le lol et une en pratique.
      - [^] # Re: Littérature
        
        Posté par YBoy360 (site web personnel) le 13 juillet 2019 à 00:10. Évalué à -4.
        
        Et sans sandbox, tu croies qu'il y aurais combien de failles ???
        
        Personne a dit que les sandbox était invulnérable, elle tendent cependant à l'être. Dès lors que ces toutes petites failles sont réparable rapidement, il n'y a pas d'argument contre les sandboxes.
        
        [^] # Re: Littérature
        
        Posté par FluffyHamster le 13 juillet 2019 à 00:32. Évalué à 4.
        
        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.
- [^] # Re: Littérature
  
  Posté par ted (site web personnel) le 14 juillet 2019 à 10:35. Évalué à 7.
  
  Techniquement, le sandboxing est une avancée. Personnellement je trouve que c'est une mauvaise idée d'exécuter un logiciel dont on n'a pas confiance sur son ordinateur, mais parfois on n'a pas le choix.
  
  Par contre, est ce qu'on peut avoir un effet inverse sur la sécurité? À trop se croire protégé, ne risque-t-on pas d'installer n'importe quoi sur son ordinateur, et quand la faille arrivera on sera bien embêté? Un peu comme pour le vrai football (américain), l'obligation de port des combinaisons et casques a eu un impact négatif sur la santé des joueurs, car les joueurs se croyant protégés le sport est devenu plus violent (attaque avec la tête…)
  
  Moi ce qui m'embête avec tous ces trucs dans le gestionnaire de logiciels, c'est qu'on installe des logiciels d'on ne sais où, compilés par on ne sait qui, de licence inconnue… À l'inverse je trouve confortable d'avoir des dépôts gérés par ma distribution en qui j'ai confiance.
  
  Un LUG en Lorraine : https://enunclic-cappel.fr
  - [^] # Re: Littérature
    
    Posté par Renault (site web personnel) le 14 juillet 2019 à 11:07. Évalué à 8.
    
    Techniquement, le sandboxing est une avancée. Personnellement je trouve que c'est une mauvaise idée d'exécuter un logiciel dont on n'a pas confiance sur son ordinateur, mais parfois on n'a pas le choix.
    
    Oui nous devons éviter d'installer des logiciels dont l'origine n'inspire pas confiance, mais comme tu le dis, nous n'avons pas forcément le choix.
    
    Mais je pense que de croire qu'il suffit d'avoir confiance en ce qu'on exécute pour être en sécurité est un mauvais raisonnement. Je pense que la sécurité doit être le plus indépendante possible de la question de la confiance.
    
    La confiance n'est pas une sécurité absolue. Une erreur peut arriver par exemple, ou une faille être inconnue.
    
    Par exemple j'ai confiance en Firefox et Mozilla, mais c'est un gros logiciel, probablement avec des failles existantes mais non identifiées en amont et pourtant déjà exploitées. Donc en limitant ses droits au maximum, j'évite qu'une exploitation de faille fasse trop de dégâts.
    
    Par contre, est ce qu'on peut avoir un effet inverse sur la sécurité? À trop se croire protégé, ne risque-t-on pas d'installer n'importe quoi sur son ordinateur, et quand la faille arrivera on sera bien embêté?
    
    Donc la moralité c'est supprimer toutes les protections pour qu'on utilise nos 5 sens pour assurer la protection ? Mouais, ça me paraît bien simpliste comme point de vue. La sécurité est un domaine complexe, croire qu'on peut s'en sortir en supprimant toutes les protections me semble ridicule pour que notre vulnérabilité nous rende méfiant par nature.
    
    Il faut trouver un bon compromis entre sécurité et utilisabilité / performance, mais aussi assurer une interface et enseigner les pratiques pour que les gens ne se sentent pas invulnérables parce qu'ils ont tel dispositif de sécurité activé. Mais cela ajoute une couche de sécurité légitime et essentielle. Car même un logiciel où tu as confiance peut avoir des failles et il est important de s'en prémunir au maximum de ses effets par défaut.
    - [^] # Re: Littérature
      
      Posté par FluffyHamster le 14 juillet 2019 à 12:07. Évalué à 2.
      
      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.
# Précisions

Posté par Okki (site web personnel, Mastodon) le 13 juillet 2019 à 02:46. Évalué à 10.

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.
- [^] # Re: Précisions
  
  Posté par saltimbanque (site web personnel) le 13 juillet 2019 à 14:41. Évalué à 1.
  
  A mes yeux c'est évident que si une calculatrice doit désormais te demander pour accéder a tes contacts et ton historique de navigation, elle va désormais hésiter a le faire, moins de gens l'installeront. Bien sur certains cliqueront sur oui mais les gens ne sont pas que cons.
  - [^] # Re: Précisions
    
    Posté par FluffyHamster le 13 juillet 2019 à 15:26. Évalué à 3. Dernière modification le 13 juillet 2019 à 15:27.
    
    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.
# Utilisation offline

Posté par Wendigo le 13 juillet 2019 à 10:46. Évalué à 5. Dernière modification le 13 juillet 2019 à 10:46.

Et on ne peux toujours pas télécharger un flatpak et le stocker sur une clée usb pour l’utiliser ou le partager hors ligne. Par ce que les novices ils vont toujours avoir le reflex. Et pour cliquer sur “installer ce flatpak” et bien ils ont intéret d’avoir une distrib compatible.

Tu as la commande 'create-usb' qui te permet de créer un dépot local dans un dossier.

Sinon tu as aussi la commande 'build-bundle' qui te permet aussi de créer un fichier .flatpak autonome ( à condition d'avoir déjà téléchargé le nécessaire ) contenant l'application, attention car il faudra aussi faire la même chose pour les dépendances liées, donc oui, aussi potentiellement 1Go, mais au moins tu l'a en local :D

Pour ma part j'ai testé et impossible de faire fonctionner, à cause de "collection-id" manquants, ahah!

Après sinon, c'est cool pour les jeux vidéos, par exemple sur Piratebay si tu cherches "flatpak", un type a empaqueté des jeux avec Wine et toute les configs nécessaires.
# Windows c'est "simple" mais c'est facile

Posté par Sylvain Colinet (site web personnel) le 13 juillet 2019 à 15:42. Évalué à 1.

En fait distribuer sous Windows c'est assez simple comparativement à tout ça.
Tu as juste à empaqueter ton binaire + tes librairies et dans ton code tu peux facilement assumer que toute tes ressources (images/fichier de config/ect…) sont relatif à l'emplacement de ton binaire. Tu peux soit faire carement un installeur ou juste fournir une archive avec tout le basard.

Sous Unix tu dois commencer à gérer des trucs genre /usr/share et autre qui va varier en fonction de tes préfix fournis à la compilation (et tu dépends donc de tout tooling the compilation). Plus si tu veux faire ça bien tu dois fournir un .deb et .rpm et j'imagine qu'un flakpack et autre c'est autant de boulot que .deb/.rpm donc aucun intérêt au final.
- [^] # Re: Windows c'est "simple" mais c'est facile
  
  Posté par totof2000 le 13 juillet 2019 à 17:07. Évalué à 8.
  
  Sous Unix tu dois commencer à gérer des trucs genre /usr/share et autre qui va varier en fonction de tes préfix fournis à la compilation
  
  Bof, su tu veux tu peux faire en sorte que ton soft s'installe sous /opt, et tu le range comme tu veux.
  - [^] # Re: Windows c'est "simple" mais c'est facile
    
    Posté par diorcety le 15 juillet 2019 à 09:00. Évalué à 1.
    
    En faite le soucis sous Linux le soucis est que c'est moins "natif" de faire des binaires "relocatables". Il y a beaucoup de framework qui supporte ça mais il faut encore jouer à coup de rpath si tu veux que ça marche, ou faire un script bootstrap qui va jouer avec les variables PATH/LD_LIBRARY_PATH et autres variables d’environnement suivant ce que tu utilises.
  - [^] # Re: Windows c'est "simple" mais c'est facile
    
    Posté par Melodie (site web personnel) le 21 juillet 2019 à 00:46. Évalué à 1.
    
    Sous systèmes GNU/Linux tu peux apprendre à connaître l'arborescence du système, grâce à quoi tu sais que tes binaires n'iront JAMAIS dans /usr/share, mais au choix sous /usr/bin ou sous /usr/local/bin (quand tu compiles pour installer à la main). Et grâce au respect des conventions, on trouve rapidement ce dont on a besoin quand on le cherche. (ex: changer la Catégorie dans un fichier .desktop issu d'un paquet prévu pour Gnome, pour qu'il s'affiche dans un menu dans un autre environnement (comme Openbox ♫♪♬) puis l'installer dans le sous-répertoire fait pour dans son /home… )
    
    Pour /opt ce n'est pas faux, mais c'est surtout utilisé pour de grosses applications installées hors gestionnaire de paquets (ex: Odoo ?)
    
    Et cela n'empêche pas de respecter une arborescence qui concordent avec les conventions.
    - [^] # Re: Windows c'est "simple" mais c'est facile
      
      Posté par totof2000 le 22 juillet 2019 à 09:58. Évalué à 2.
      
      Pour ma part, j'en ai jamais fait beaucoup, mais tout paquet que j'ai créé hors distribution ne s'est jamais installé dans /usr/bin ou dans /usr. J'ai toujours mis ça dans /usr/local (sauf pour freebsd ou j'ai parfois fait autrement), ou dans /opt, avec éventuellement un wrapper dans /usr/local/bin. La raison est simple : je ne veux pas interférer avec les distributions existantes. Je ne veux pas enbtrer en collision avec des fichiers/éléments de la distribution.
      - [^] # Re: Windows c'est "simple" mais c'est facile
        
        Posté par Melodie (site web personnel) le 22 juillet 2019 à 21:54. Évalué à 2.
        
        Si le paquet n'est pas destiné à entrer dans la boucle du gestionnaire de paquets (donc dans la distribution) ça me semble logique. (Cependant quitte à créer de nouveaux paquets, je trouve ça sympa de les retrouver un jour dans les dépôts officiels ou communautaires).
# Sans moi

Posté par David Demelier (site web personnel) le 14 juillet 2019 à 08:01. Évalué à 1. Dernière modification le 14 juillet 2019 à 08:02.
Les logiciels de nos gestionnaires de paquets sont fortement couplés entre eux. Très fortement même. Si une nouvelle version d’un logiciel demande une nouvelle version d’une dépendance, en règle général, la distribution va attendre 6 mois et sa prochaine version avant de faire les mises à jour, plutôt que de risquer de casser quelque chose.

Et parfois c'est nécessaire. GNOME et KDE fournissent tous deux des bibliothèques communes à tout leur composants. Théoriquement ça veut dire que si tu utilises GNOME Maps 3.30, tu dois avoir les bases 3.30 (en réalité ça fonctionne de mixer la plupart du temps). Linux est bien plus basé sur des bibliothèques communes que Windows. Autre exemple : Gtk et Qt. Ça me ferait bien c***** de me taper ces dépendances dans chaque paquet. En plus, en ayant une unique version partagée par le système on s'assure d'une cohérence maximale. Que se passera-t-il si un des paquets qui embarque sa propre version de Qt décide de compiler sans le support de X ou Y ? Peut-être une frustration.

Si on veut distribuer un logiciel propriétaire d’ailleurs, et bien on peut faire comme ca. Un zip avec tout dedans. Et on clique sur le lancermonlogiciel.sh

Ou les :
```
curl http://mysuperproject.io | sudo bash
```
Je reviens je vais vomir.

La question est donc de savoir si l’on souhaite ou non démocratiser l’utilisation de GNU/Linux auprès du grand public.

Moi je n'y crois pas. Je n'aime pas flatpak pour la plupart des raisons que tu as citées. Pour moi ça fonctionnait déjà très bien avant et il n'y avait rien à corriger. C'est une fausse solution à un faux problème. Le vrai problème était la simplicité à installer des paquets et depuis un moment on a des interfaces graphiques conviviales qui le permettent comme anciennement GNOME Packagekit et maintenant GNOME Software, qui vous donne même des captures d'écrans.

git is great because linus did it, mercurial is better because he didn't
- [^] # Re: Sans moi
  
  Posté par jyes le 14 juillet 2019 à 10:03. Évalué à 4. Dernière modification le 14 juillet 2019 à 10:03.
  
  our moi ça fonctionnait déjà très bien avant et il n'y avait rien à corriger. […] Le vrai problème était la simplicité à installer des paquets
  
  Le vrai problème c’était surtout la simplicité à installer des logiciels qui ne sont pas dans la base de paquets de la distribution. D’ailleurs à mon avis, il n’est pas vraiment résolu avec Flatpak, car en étant bien plus compliquée qu’elle n’en avait besoin, cette solution se heurte déjà à trop de limites pour la rendre universelle (mal adaptée aux logiciels en ligne de commande, complexité de distribution dia des dépôts, etc). Il y aura toujours besoin d’autres solutions.
  
  Ça me ferait bien c***** de me taper ces dépendances dans chaque paquet.
  
  Ce n’est pourtant pas loin de ce que propose Flatpak, et c’est à mon avis son plus gros soucis. Ses défenseurs disent que les runtimes son partagés, mais en pratique si Flatpak sert un jour à résoudre le problème des dépendances, 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. S’il était si facile de suivre l’évolution des bibliothèques, les problèmes de compatibilités entre versions et entre distributions (que F(l)atpak prétend résoudre) n’existeraient pas.
  - [^] # Re: Sans moi
    
    Posté par Renault (site web personnel) le 14 juillet 2019 à 10:58. Évalué à 8.
    
    D’ailleurs à mon avis, il n’est pas vraiment résolu avec Flatpak, car en étant bien plus compliquée qu’elle n’en avait besoin
    
    Pourtant c'est bien plus simple que de se farcir RPM et DEB et autres.
    
    Déjà car tu as moins de formats, avec leurs outils et spécificités, à gérer. Tu peux te contenter d'un format et ça ira partout.
    
    Ensuite, même en considérant que RPM et DEB sont simples (ce qui n'est pas le cas non plus), chaque distribution avec ce format a ses spécificités. Fedora n'utilise pas les mêmes noms pour les paquets que OpenSuse, ils ne partagent pas les mêmes versions de bibliothèques, ils ne partagent pas le même découpage des paquets, ils n'ont pas les mêmes options de compilations par défaut, etc.
    
    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.
    
    Pour un éditeur externe qui veut déployer son application partout, Flatpak est bien une avancée que de recourir aux solutions traditionnelles.
    
    Moi je n'y crois pas. Je n'aime pas flatpak pour la plupart des raisons que tu as citées. Pour moi ça fonctionnait déjà très bien avant et il n'y avait rien à corriger. C'est une fausse solution à un faux problème. Le vrai problème était la simplicité à installer des paquets et depuis un moment on a des interfaces graphiques conviviales qui le permettent comme anciennement GNOME Packagekit et maintenant GNOME Software, qui vous donne même des captures d'écrans.
    
    Peut être que pour toi cela convient ainsi, mais il faut arrêter de croire que son cas d'usage est universel et de penser que les gens qui se plaignent depuis longtemps du problème ne sont que des idiots ou des gens malhonnêtes.
    
    Je vais donner un cas d'usage où Flatpak m'a été très utile. Avec ma boîte nous faisons de temps en temps des LAN avec des jeux libres. Mais chaque employé a sur sa machine la distribution de son choix, on a du Debian, Ubuntu, Fedora, OpenSuse, Archlinux, etc. Et même un Windows.
    
    Globalement avec la méthode traditionnelle c'était très difficile de jouer ensemble à un jeu. Car il faut que le jeu soit à la même version pour tout le monde, et disponible dans des dépôts. À part pour les jeux qui évoluent peu, c'était mission impossible. Compiler nous même n'était pas vraiment une option car c'est long et casse gueule. Du coup on perdait du temps à chercher dans des dépôts alternatifs de chaque distribution pour trouver la version commune. Or, nous ce qu'on veut c'est jouer ensemble et rapidement, pas perdre du temps à les installer.
    
    Avec Flatpak et Flathub, ce fut réglé en 2 minutes, le temps de choisir le jeu, l'installer et plus de problèmes !
    
    Voilà, ça c'est un cas très concret d'un problème difficilement soluble avec la méthode à l'ancienne. Et c'est un bonheur.
    
    Sans oublier les gens qui potentiellement veulent la dernière version de Firefox ou de Libreoffice sans pour autant changer de distributions car le reste leur convient ou jouer avec des dépôts alternatifs dans tous les sens. Pour ce cas d'usage aussi Flatpak est une très bonne solution.
    - [^] # Re: Sans moi
      
      Posté par FluffyHamster le 14 juillet 2019 à 15:04. Évalué à 5.
      
      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.
      - [^] # Re: Sans moi
        
        Posté par Okki (site web personnel, Mastodon) le 14 juillet 2019 à 20:19. Évalué à 2.
        
        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.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 14 juillet 2019 à 20:51. Évalué à 4.
        
        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.
        
        C'est en effet en projet. L'objectif derrière est multiple :
        
        Remplacer peu à peu certains RPM par des Flatpak ;
        
        Permettre à d'autres distributions d'avoir la fraîcheur applicative de Fedora via les Flatpak, dont notamment CentOS (mais valable pour Ubuntu, Debian, etc.) ;
        
        Cela ferait sans doute un bon complément à Flathub à ce sujet en ayant un choix plus large et simple à maintenir car réutilisant une infrastructure existante.
        
        Quant à remplacer les applications graphiques RPM par des Flatpak, cela serait la continuité du projet Fedora Silverblue avec une séparation des paquets en 3 groupes distincts, utilisant un maximum Flatpak et autres Fedora Toolbox (via Podman) pour avoir le système de fichier principal en lecture seule et les applications dans un bac à sable nativement.
        
        [^] # Re: Sans moi
        
        Posté par Gabin3 le 15 juillet 2019 à 02:07. Évalué à -8.
        
        Permettre à d'autres distributions d'avoir la fraîcheur applicative de Fedora via les Flatpak, dont notamment CentOS (mais valable pour Ubuntu, Debian, etc.) ;
        
        Cette "fraîcheur" qu'avence les rolling release et autre Fedora me fait doucement rire.
        Est-ce la mort d'avoir libjpeg-1.22 au lieu de libjpeg-1.30?
        Ou c'est pour avoir l'illusion d'avancement du projet GNOME? J'ai personnellement utilisé les versions de GNOME fournis sur les stables et c'était stable au point d'en oublier cette élément et me concentrer sur mes tâches.
        
        Est-ce vraiment si bien d'avoir un noyau 5.x* en avance qui corrompt un SSD?
        Ma version ESR de firefox n'a pas été impactée par le problème de certificats des addons et le net n'est pas devenu incompatible en 2 versions.
        
        Bref, Les distros stables et LTS fournissent ce qui est important, une base stable et des mises à de sécurité et on peut toujours ajouter des repos/ppa spécifiques ou utiliser de l'AppImage.
        
        mes 2 centimes
        
        Qu'on soit clair, il est tout à fait possible d'avoir un noyau aligné sur upstream sur des distros stables.
        
        [^] # Re: Sans moi
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 03:09. É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.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 14 juillet 2019 à 18:39. Évalué à 1. Dernière modification le 14 juillet 2019 à 18:39.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Sans moi
        
        Posté par Gabin3 le 15 juillet 2019 à 02:51. Évalué à -4.
        
        Sans oublier les gens qui potentiellement veulent la dernière version de Firefox ou de Libreoffice
        
        Mauvais exemple. Mozilla et The Document Foundation fournissent des versions tar.gz (standalone) de leurs logiciels qu'il suffit de extraire.
        KDEnlive et Krita offrent des versions AppImage.
        
        En résumé, pour les gros softs, il est facile d'obtenir la version upstream voire nightly sans avoir à recourir à la compilation.
        
        Pourtant, c'est une app qui correspond totalement à la cible de flatpak.
        
        Pas vraiment, ce sont des applications qu'on souhaite surtout utiliser en version longue durée, pas le genre d'application à mettre à jour tous les 4 matins.
        Et vu que la version standlone que propose Mozilla et The document foundation fait le boulot, Flatpak paraît bien redondant ou overkill.
        
        Le point à améliorer serait du côté de Debian/Ubuntu ou autres qui devraient offrir un meta paquet qui ne serait qu'une sorte de wrapper (comme celui que tu as écrit) pour télécharger le tgz officiel et le rendre visible (path, etc…).
        
        Ma position ne concernant que l'utilisateur finale, hein. Flatpak pourrait être intéressant pour du déploiement continu d'application desktop pour des devs.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 09:12. Évalué à 1.
        
        En résumé, pour les gros softs, il est facile d'obtenir la version upstream voire nightly sans avoir à recourir à la compilation.
        
        Mais il n'y a pas le bac à sable, ni même les demandes de permissions pour que l'isolation ne soit pas trop stricte ni trop statique. Il n'y a pas d'intégration avec le 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, tu n'as pas de mutualisation possible des bibliothèques communes, etc.
        
        Oui c'est donc possible de suivre ce chemin, mais on voit qu'il manque pas mal de choses que Flatpak propose. Que ce soit appImage, firejail ou Nix, aucun ne propose entièrement ce que souhaite proposer Flatpak à terme entièrement.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 10:20. Évalué à 5.
        
        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" ?
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 10:35. Évalué à 7.
        
        Ce qui m'amuse c'est que toutes les critiques concernant Flatpak sont assez isolés sur un point fourni, jamais sur l'entièreté du concept. Du coup vous passez à côté.
        
        Ce qui est intéressant dans Flatpak n'est pas ses fonctionnalités pris isolément, où effectivement il y a des solutions pour ça, nous parlons ici d'un concept global où il n'y a aucune alternative aussi complète.
        
        Ce que Flatpak propose en pêle-mêle c'est :
        
        De quoi installer une application indépendamment de son système, en étant plus ou moins statique ;
        
        Que cette application soit installable par un utilisateur sans droit super utilisateurs, simple d'utilisation et intégré (disponible via le menu système) sans complications ;
        
        Permettre de mutualiser autant que possible les bibliothèques de base entre les applications ;
        
        Isoler l'application dans un bac à sable et permettre à l'utilisateur d'allouer au cas par cas à l'application des droits supplémentaires ou certains accès en dehors de ce bac à sable.
        
        Je suis désolé mais tout ce que vous présentez ici comme alternatives sont des solutions qui ne répondent qu'à certaines problématiques et où ajouter les autres fonctionnalités ne sont pas simples.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 10:48. Évalué à 4.
        
        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.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 11:23. Évalué à 9.
        
        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.
        
        En quoi c'est un délire ? Sérieusement. C'est au contraire très sain d'essayer au maximum ce qui peut l'être tout en permettant à l'application d'être indépendante de la distribution qui l'exécute.
        
        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.
        
        Ton argument est bien pauvre. Il est au contraire sain d'essayer d'isoler au maximum les processus, pour se prémunir un maximum des failles de sécurité et d'autres bogues.
        
        Et c'est d'autant plus important qu'on parle d'offrir à l'utilisateur d'installer des paquets ne provenant pas de sa distribution, potentiellement propriétaires mêmes. Les isoler doit être le comportement de base pour limiter les dégâts potentiels.
        
        Donc c'est justement très lié à cette problématique de distribution.
        
        Windows ne le fait pas. macOS ne le fait que partiellement.
        
        Bien sûr que si Windows isole ses processus, ceux qui viennent du marché de Windows sont bien dans des bacs à sable.
        
        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).
        
        Tu crois que Firefox dialogue avec le système ou avec les autres applications de ton ordinateur spécifiquement ? Pas vraiment. Ses interactions peuvent largement se contenter d'une API standardisée, délimitée et sécurisée au lieu de pouvoir faire tout et n'importe quoi. Comme ils font sur Android par ailleurs.
        
        On ne parle pas de mettre le shell dans un processus isolé, Flatpak ne concerne que les applications graphiques qui ont de fait peu d’interactions avec le reste du système et peuvent tirer grandement profit d'un tel changement.
        
        Mais continue à nier ce besoin et ces apports, après tout c'est plus facile que d'expliquer en quoi techniquement avant c'était mieux sur tous les points. Ce qui est impossible car la solution traditionnelle a ses défauts aussi, d'où la naissance de Flatpak et de l'hybridation des modèles pour tirer avantage du meilleur des deux mondes.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 11:58. Évalué à 1.
        
        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.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 12:39. Évalué à 10.
        
        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.
        
        Pas forcément non, car en fait le but est d'être plus souple que ce que propose une distribution tout en tentant d'être économe dans la mesure du possible. Et c'est le cas. Si beaucoup d'applications s'en servent, le gain est réel.
        
        De plus, aucun autre OS ne le fait
        
        Pas mal d'OS ne font pas ce que Linux fait sur certains points, donc Linux est mal ?
        
        Ce n'est pas un argument.
        
        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.
        
        Est-ce que tu t'es servie de telles applications en vrai ? Moi oui. Et ils peuvent lire ou écrire dans le système de fichier normal, faire des opérations sur le réseau, etc. Une application isolée ne signifie pas qu'elle ne peut rien faire à part afficher un truc à l'écran.
        
        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.
        
        À part pour le pilote nVidia (qui est liée au fait que c'est un pilote proprio soit dit en passant), Firefox peut faire le reste en étant isolée dans un bac à sable. Et Flatpak va proposer des points d'ancrage pour permettre dynamiquement de sortir du bac à sable quand c'est nécessaire grâce à l'autorisation de l'utilisateur.
        
        C'est d'ailleurs aussi tout l'objet de Wayland et de Pipewire pour permettre aux applications de faire ce qu'elles doivent faire avec le système tout en étant isolées.
        
        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.
        
        Je crois que tu n'as pas compris une chose en sécurité. Le but n'est pas de tout interdire, le but est d'autoriser uniquement ce qui est nécessaire pour l'application. Il est légitime que Firefox ait accès à Internet, cela l'est moins pour beaucoup d'applications, il est légitime que Firefox ait accès à ta caméra et à ton micro, Libreoffice pas vraiment. Etc. Le but est que seules les applications qui ont besoin d'une fonctionnalité légitime puissent s'en servir.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 12:47. Évalué à -3.
        
        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…
        
        [^] # Re: Sans moi
        
        Posté par YBoy360 (site web personnel) le 15 juillet 2019 à 16:24. Évalué à 2.
        
        Les autres OS voudrait le faire et le font en partie hein.. Puis Windows est limité par l'absence de gestion des liens symboliques pour éviter le dependency hell d'il y a quelques années..
        
        Tu reproches à Flatpak de gérer les dépendances, mais tu lui reproche la taille des chargements… Si tu veux installer 50 applications, ce n'est pas délirant de vouloir partager les librairies, c'est exactement fait pour cela, ça économise la mémoire, et tu simplifies les mises à jour de sécurité. C'est dans les guideline Unix depuis environ 40 ans. On peut reprocher la granularité des packages, mais moi je pense qu'a l'usage, leurs choix sont les bons.
        
        Si il y a une chose où Linux est sans reproches, c'est justement la gestion des packages par les distributions. Ça ne t'empêche pas de télécharger un gros binaire statique… Mais ne prétend pas que cette solution est meilleur.
        
        Pour en revenir à la critique principale de ce journal : t'as une Debian 8, ou une RH 6, et que tu veux installer la dernière version de Libre Office via le système de package, tu dois mettre à jour toute ta distribution. Tu consommeras encore plus de bande passante qu'avec Flatpak.
        
        Personnellement, une distribution basée directement sur les packages Flatpak ne serait pas une mauvaise idée.
        
        [^] # Re: Sans moi
        
        Posté par SpaceFox (site web personnel, Mastodon) le 15 juillet 2019 à 16:35. Évalué à 5.
        
        Puis Windows est limité par l'absence de gestion des liens symboliques
        
        Windows supporte les liens symboliques sans bidouille pour le grand public depuis Windows Vista, soit depuis janvier 2007, ce qui ne nous rajeunit pas. Plus exactement, c'est disponible depuis NTFS3.1, donc sous Windows XP en bidouillant un peu. Par contre il a longtemps fallu les droits d'admin pour pouvoir les créer (Wikipedia n'est pas claire sur depuis quand c'est possible avec un simple utilisateur).
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 16:39. Évalué à 1.
        
        Je te cite le cas concret de mon disque dur, ou j'ai 5 runtimes qui se marchent dessus. Comment peux tu me dire que c'est un gain d'espace ou d'utilisation RAM, puis ce que les librairies sont dans le système, puis dans 5 runtimes ?
        
        Si le runtime était fixe sur un intervalle de 5 ans, à la limite, tu pourrai argumenter que 50 applications économiseraient forcément des dépendances, mais avec le runtime gnome 3.28, 30, 32, et dans quelques mois 34… Et dans quelques années…
        
        Tu consommeras encore plus de bande passante qu'avec Flatpak.
        
        Sachant que le runtime gnome fait 1 Go et qu'il change tout les 6 mois… Pas sur…
        
        Les autres OS voudrait le faire et le font en partie hein.
        
        Alors j'aimerai en profiter, si tu as des infos concrètes la dessus.
        
        [^] # Re: Sans moi
        
        Posté par Gabin3 le 15 juillet 2019 à 19:25. Évalué à -1.
        
        On se calme les amis. :)
        
        Personne n'est vraiment anti-flatpak ici, vous faites ce que vous voulez avec vos giga :), mais il y a des cas concrets où d'autres solutions font le boulot: partage de binaires + sandboxing sans la complexité et le côté unilatéral de flatpak.
        Et malgré la bonne volonté de Renault, ça peine à convaincre.
        
        Pour ma part, je ne comprends pas que AppImage ne soit pas plus mis en avant car dés qu'il m'a été nécessaire de recourir à un paquet de ce genre, ça a marché sans problème et sans chipotage, pré-config ou autre.
        
        Enfin je dis ça, je viens de découvrir https://www.appimagehub.com (492 paquets) et avec des applications bien plus intéressantes et absentes des repos stable+non free de Debian, j'achète à priori (à voir le modèle d'assurance des paquets).
        
        Alors d'un point de vu utilisateur, je vais sur un des 2 stores, je veux télécharger Olive:
        - Appimagehub me fourni un .appimage de 58mo. Fichier téléchargé, droits executable donné et cliquage: Je suis prêt à dérusher et monter.
        
        Maintenant, flatpak:
        - Il me propose de télécharger un fichier org.olivevideoeditor.Olive.flatpakref. OK je reviens en arrière et je lis les instructions:
        install
        ** flatpak install flathub org.olivevideoeditor.Olive **
        
        error: Remote "flathub" not found
        
        Je reviens encore en arrière, j'avais zappé le :
        
        Make sure to follow the setup guide before installing
        
        J'avais préalablement installé flatpak mais pas le repo.
        
        flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
        
        (déjà, le --if-not-exists prête à sourire et rappelle certaines systemderies)
        
        Je m'execute.
        
        error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Flatpak system operation ConfigureRemote not allowed for user
        
        Ah ok, je dois installer via sudo, je m'execute encore. Ici, je n'ai pas d'output pendant de longues minutes. Retour à la ligne sans output. M'okay, ça doit être terminé.
        
        Je retente
        
        flatpak install flathub org.olivevideoeditor.Olive
        
        Toujours sans output mais pendant une minute cette fois et soudain, on me propose de télécharger le runtime "org.kde.Platform/x86_64/5.12 from flathub: 365 MB. Soit, faisons…
        
        Ce qui est intéressant, c'est que je suis actuellement à l'étranger avec une connexion 10Mbits (3G) et l'écart AppImage/Flatpak est encore plus criant.
        
        27 minutes plus tard:
        
        org.kde.Platform/x86_64/5.12 from flathub
        Receiving delta parts: 0/12 211.8 kB/s 22.2 MB/365.6 MB 27 minutes 1 seconds remaining
        org.kde.Platform/x86_64/5.12 from flathub
        12 delta parts, 139 loose fetched; 357048 KiB transferred in 1139 seconds
        error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Flatpak system operation Deploy not allowed for user
        [/tmp ]$ org.kde.Platform/x86_64/5.12 from flathub
        bash: org.kde.Platform/x86_64/5.12: No such file or directory
        
        Quoi? Faut-il être root? je retape la commande avec sudo, et il me propose de télécharger le runtime.
        
        C'est bon, je n'irai pas plus loin, chers lecteurs et chères lectrices.
        
        Vous pourriez dire que c'est peut-être ma debian 9 stable mais alors, à l'eau l'argument d'universalité, mais on peut aussi rajouter les cas de multiples runtimes évoqués par Emeric et je pense qu'on reviendra tous sur sa conclusion.
        
        Mais pourquoi pas AppImage, donc?
        Je citais la faiblesse du modèle communautaire sans pognon dans un autre journal, Flatpak est supporté par Redhat et Gnome avec des moyens financiers qu'on connait et concernant Gnome, au delà de ce qu'ils produisent d'intéressant.
        Bref, ce n'est pas pour rien que Red Hat et Canonical se tirent la bourre.
        
        Suis-je un haineux, rageux, troll? Non, tant que flatpak ne force pas façon systemd pour devienir mandatory, vous êtes libres de faire ce que vous voulez avec vos gigas.
        
        cordialement,
        gabin3
        
        ps: il n'y a pas bookworm sur appimagehub, ok, mais le premier runtime de 318MB à télécharger depuis flathub ne me tente pas plus que ça.
        
        [^] # Re: Sans moi
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 22:02. É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
        
        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)
        
        [^] # Re: Sans moi
        
        Posté par groumly le 16 juillet 2019 à 01:24. Évalué à 10.
        
        Si il y a une chose où Linux est sans reproches, c'est justement la gestion des packages par les distributions.
        
        Ouais, mais alors justement. Non, pas du tout.
        La communauté est tellement bordélique et divisée sur le moindre bout de technologie que ça a crée ce problème de toute pièce: pas possible de faire la moindre assomption sur les librairies les plus basiques, et très peu de compat binaire.
        Résultat, distribuer un binaire qui marche à quiconque est un enfer, et je parle pas de pouvoir compiler quoi que ce soit.
        On a un problème cree de toute pièces par la communauté, qui est réglé manuellement par une armée de développeur qui passent un temps absolument délirant à re-empaqueter des applis.
        
        Tout ce boulot d’empaquetâge amène 0 valeur à l’utilisateur. C’est même pire en fait, c’est une perte sèche vu que d’une part les distributions se permettent de parfois patcher à la truelle du code qui marche (coucou Debian OpenSSL), et que l’utilisateur se retrouve gros jean comme devant quand il veut utiliser une version differente de celle de la distrib (coucou continuous deployment et release often).
        
        La valeur ajoutée, elle se trouverais dans là centralisation de la distribution des applis. En gros, le modèle du store. Oui, les package managers etaient sur le créneau avant tout le monde.
        Mais au lieu de developer le concept, en laissant les dev tiers packager leur binaire une fois et l’uploader sur les stores qui veulent bien d’eux, on a divise encore plus la communauté en multipliant les package managers (et leurs frontends…), et gâché une énergie incroyable en leur faisant résoudre le mauvais problème.
        
        En gros, on a pas vraiement resolu de probleme, on gâche un temps pharaonesque en packaging alakonkiserarien, et on fait chier à la fois upstream et les utilisateurs. 👏
        J’appelle pas ça “ne rien avoir à se reprocher”.
        Les milliers de dev Debian, leur temps serait vachement mieux utilisé à developer, plutôt que patcher et re-packager le code de quelqu’un d’autre.
        
        Tu sais pourquoi Windows et macOS on fait sans package manager pendant 15 a 30 ans? Parce qu’ils en ont jamais eu besoin!!!
        Les développeurs codent pour la plateforme. Si ya un truc pas couvert par la plateforme (généralement besoin spécifique), ils fournissent la dependence.
        La plateforme garde un œil sur tout ça, et quand ils voient un pattern de besoin spécifique émerger et devenir pas si spécifique, ils l’integrent a la plateforme. Au lieu de réécrire des stacks fondamentales de 0 tous les 5 ans, ils assurent une compat binaire et font en sorte d’au moins pas trop peter l’existant.
        
        Ils ont compris que leur valeur ajoutée c’est de fournir une plate-forme aux développeur tiers, pas de leur tirer la couette en recompilant à la hache du code tiers.
        Quand Windows, macOS, iOS and android ont sorti leurs store, c’était pas des package manager. C’était une solution a la fois aux problèmes de distributions des développeurs tiers, et au problèmes de découverte et de confiance des utilisateurs. Ils ont fait leur boulot de plateforme: rendre la vie de leur eco système plus facile.
        
        Ca fait plus de 15 ans que l’industrie au sens large a compris que les cycles de releases long et/ou figés ne marchent pas. Apple a montré au monde comment concilier base systeme stable avec un eco système vivace et très actifs.
        Meme Apple a finit par lâcher leur cycle de release Big Bang à la con, et commence à mettre a jour leurs os et applis au fil de l’eau.
        Il serait peut être temps d’admettre que le fondement des distros Linux, à savoir un tout soit disant cohérent et figé pendant x mois ne marche plus. Une fois que t’as admit ça, tu comprend très vite que les packages managers sont inutiles et complètement dépassés.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Sans moi
        
        Posté par Psychofox (Mastodon) le 16 juillet 2019 à 10:30. Évalué à 10.
        
        Tu sais pourquoi Windows et macOS on fait sans package manager pendant 15 a 30 ans? Parce qu’ils en ont jamais eu besoin!!!
        
        Avec comme corollaire des millions de systèmes vulnérables car les applications n'étaient jamais mises à jour, forçant les développeurs d'applications à mettre en place une système de mise à jour dans la moindre appli (on en parle du temps gaspillé à coder ça et mettre en place l'infra qui va avec?)
        
        L'absence de package manager c'était plus une tare qu'autre chose, d'ailleurs autant chez Apple qui Microsoft ils ont finis par s'y mettre, ce n'est pas pour rien.
        
        [^] # Re: Sans moi
        
        Posté par Albert_ le 16 juillet 2019 à 11:24. Évalué à -4.
        
        Tu sais pourquoi Windows et macOS on fait sans package manager pendant 15 a 30 ans? Parce qu’ils en ont jamais eu besoin!!!
        
        C'est rigolo ce que tu dis vu le apple store… Tu viens juste de dire que Apple et Microsoft sont des gros has been sur le sujet et on mis justee 30 ans a ouvrir les yeux et le cerveau…
        
        [^] # Re: Sans moi
        
        Posté par YBoy360 (site web personnel) le 16 juillet 2019 à 14:50. Évalué à 1. Dernière modification le 16 juillet 2019 à 14:54.
        
        Sans gestionnaires de packets, ce serait encore 100 fois plus la merde.
        
        Si tu veux distribuer un binaire commun à plusieurs distributions, et contrôler la diffusion de ton logiciel, sans passer par le système de packaging, tu n'as d'autre choix, dans ce cas particulier que de faire aussi mal que Windows : refiler un binaire auto extractable, gérant sa mise à jour et statique ou un appimage, un Snap, ou un package Flatpak.
        
        La distribution de binaires, hors distribution requière une compatibilité binaire entre elles si tu veux tout faire comme Windows. Moi j'y suis favorable aussi mais pas la majorité des développeurs, donc des solutions comme Flatpak permettent de concilier tout le monde en gérant plusieurs versions de binaires simultanément.
        
        Dans le monde Open Source, on échange les sources, pas les binaires comme sous Windows. Certains usages en pâtisse, mais il y a bien plus d'avantages.
        
        [^] # Re: Sans moi
        
        Posté par groumly le 17 juillet 2019 à 01:15. Évalué à -1.
        
        Dans le monde Open Source, on échange les sources, pas les binaires comme sous Windows.
        
        Foutaises. En 1994, peut être.
        Ca fait 20 ans que ça n’est plus vrai du tout.
        
        Pour le reste, tu periphrases ce que dit mon commentaire.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Sans moi
        
        Posté par YBoy360 (site web personnel) le 17 juillet 2019 à 04:50. Évalué à 1.
        
        Normal, je suis d'accord ta diatribe modulo 1 truc : que le fautif n'est pas le gestionnaire de package qui permet de factoriser les binaires. Tu connais au moins les avantages de cette démarche ? T'en donne vraiment pas l'impression.. puis faire des packets n'est pas très compliqué pour les distributions.
        
        Ce n'est pas tant le bordel que ça, il y a des gens pas d'accord, bah rien ne les empêche de faire différemment. Tu changeras pas ça. C'est l'essence même de l'Open Source, ou la plupart des utilisateurs n'utilise pas le binaire fourni par le développeur, mais LES SOURCES recompilé par la distribution.
        
        [^] # Re: Sans moi
        
        Posté par jyes le 15 juillet 2019 à 11:37. Évalué à 7.
        
        Quand la critique c’est :
        
        qu’il existe des solutions à chaque point particulier (empaquetage des dépendances : AppImage ; sandbox : Firejail, …),
        
        que d’autres points sont critiquables (ressources partagées très théoriques avec Flatpak dès lors qu’on l’envisage pour compléter sa distribution avec seulement un ou deux logiciels en Flatpak),
        
        que la solution globale Flatpak impose un tout avec ses contraintes (difficile de redistribuer un Flatpak hors des repos) et
        
        que ce tout a des allures d’overengineering,
        
        alors, je ne suis pas sûr que
        
        Ce qui est intéressant dans Flatpak n'est pas ses fonctionnalités prises isolément, où effectivement il y a des solutions pour ça, nous parlons ici d'un concept global où il n'y a aucune alternative aussi complète
        
        soit une bonne ligne de défense pour Flatpak. Justement, un peu de KISS (ou au moins de réutilisation de l’existant) et de modularité n’aurait pas fait de mal. Dans la mesure où Nix, AppImage et Firejail résolvent soit mieux, soit de manière indépendante (donc réutilisable dans d’autres contextes) chaque problème que doit résoudre Flatpak, c’est dommage que Flatpak soit construit comme une solution from scratch plutôt que de s’appuyer sur des solutions plus légères, quitte à les améliorer pour répondre à ses besoins spécifiques.
        
        Donc je ne partage pas ton enthousiasme pour la solution Flatpak. Après, comme je l’ai déjà écrit, si cette solution qui émerge, je serai content de pouvoir installer plus facilement des logiciels. Mais j’aurais préféré qu’il existe:
        
        un bon logiciel de sandboxing fourni avec de nombreux profils qui s’appliquent quelle que soit la manière dont a été distribué le logiciel,
        
        un bon logiciel d’empaquetage avec dépendances, et
        
        un bon logiciel de gestion des installations côté utilisateur qui marche aussi pour des logiciels non sandboxés (ça éviterait la compétition inutile avec Snap),
        
        quitte à ce que Flatpak soit une glue entre tous ces logiciels pour en simplifier un cas d’usage qu’est la distribution de logiciels sandboxés avec leurs dépendances depuis un (ou des) dépôt(s) central(isés).
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 12:52. Évalué à 5.
        
        quitte à ce que Flatpak soit une glue entre tous ces logiciels pour en simplifier un cas d’usage qu’est la distribution de logiciels sandboxés avec leurs dépendances depuis un (ou des) dépôt(s) central(isés).
        
        Le soucis du système de glu est multiple. Un système qui repose sur des composants indépendants peut rendre la tâche plus complexe car la conception de ces outils n'a pas été pensé ou optimisé pour le but à atteindre en tenant compte de tous les problématiques qu'adresse Flatpak.
        
        Sans compter qu'ils vont évoluer chacun dans leur coin, notamment leur API ou leurs commandes, que de faire dialoguer plusieurs logiciels distincts est toujours plus délicat que de faire un projet cohérent et unique, etc. Je ne dis pas que c'est dénué d'intérêt que de l'envisager sous cette forme, mais c'est facile de dire comment faire, bien moins de le faire soi même.
        
        Si ces outils sont si extraordinaires et puissants, comment ça se fait que vous ne parvenez pas à offrir ce que Flatpak propose ? 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 ?
        
        Le Logiciel Libre ce sont des gens qui codent et qui proposent des choses, que les utilisateurs adoptent ou pas par la suite. Ceux qui font avancer, ce sont ceux qui proposent quelque chose, pas ceux qui trollent sur linuxfr pour dire comment ça aurait pu être mieux fait. Le code des projets que vous mettez en avant est libre, vous pouvez donc faire avancer ce sujet comme bon vous semble pour corriger le tir.
        
        Cela me fait un peu penser à tous ceux qui critiquent Wayland, systemd et autres alors qu'ils peinent à réunir des développeurs pour maintenir et faire évoluer comme il le faudrait les solutions qu'ils défendent en face.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 13:55. Évalué à 4.
        
        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é ?
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 15:21. Évalué à 7. Dernière modification le 15 juillet 2019 à 15:23.
        
        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é,
        
        Il me semble que ce n'est pas le rôle du gestionnaire de fichiers de faire ça. C'est amusant de la part de gens qui prônent l'approche KISS ou de la simplicité du concept qui exige une intégration dans le gestionnaire de fichiers pour fonctionner.
        
        L'utilitaire peut utiliser la voie normale pour associer format de fichiers à un utilitaire et avoir le comportement associé. Sans que Nautilus ait à faire quoique ce soit, et en plus cela fonctionnerait pour d'autres logiciels du même type.
        
        et ça rentre même pas en conflit avec flatpak, leur solution.
        
        Flatpak n'est pas une solution spécifique de GNOME et encore moins de Nautilus.
        
        Le logiciel libre c'est pas les bisounours "propose, code et tout ira bien". Le logiciel libre, aujourd'hui, c'est les balkans.
        
        Le Logiciel Libre c'est simple, ce n'est pas plus qu'un développeur qui code quelque chose, le propose sous une licence qui confère quelques libertés fondamentales à ses utilisateurs et basta. Le reste est du fantasme ou sont des comportements fréquents mais non obligatoires.
        
        Chacun est libre de faire ce qu'il veut, et de convaincre le reste du monde que sa solution est la meilleure, en faisant le meilleur travail possible.
        
        C'est aussi simple que cela, le LL ne garantie pas la coopération, ne garantie pas le succès, ne garantie pas que le développeur tiendra compte des remarques de ses utilisateurs, etc. Il garantie juste un accès au code source aux utilisateurs et qui peuvent à leur tour l'améliorer (localement ou pas).
        
        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.
        
        Pas de bol pour toi, j'ai testé Subsurface via AppImage à l'instant sur ma Fedora 30 et ça ne fonctionne pas directement. Et ce n'est pas un complot.
        
        En effet, pour fonctionner il a besoin de la bibliothèque libcrypt que Fedora propose via un paquet non installé par défaut maintenant. Mais AppImage en a besoin apparemment. Donc j'ai dû installer à la main le paquet libxcrypt-compat pour que cela fonctionne.
        
        AppImage suppose que cette bibliothèque est disponible partout, ce qui est manifestement une erreur, et cela n'est pas documenté sur le site web d'AppImage, alors que c'est pourtant… le programme d'exemple de référence pour eux.
        
        Donc autant dire que ton double clic et ça fonctionne est théorique, il manque clairement de l'intégration. Et donc plutôt que de faire le Caliméro en mode aucune distribution ne veut de nous, pourquoi cela n'est pas identifié, documenté et guidé ? Car Flatpak propose lui sur son site la description de comment installer Flatpak sur chaque distribution qui globalement consiste à utiliser les dépôts de la distribution concernée donc ça marche très bien.
        
        Donc pour Flatpak, personnellement, j'ai littéralement eu qu'à double cliquer pour que cela marche, pour AppImage j'ai du me débrouiller seul. Donc avant de critiquer le reste du monde, ce serait bien d'abord de faire le maximum de son côté pour que le reste du monde soit convaincu de la viabilité de la solution.
        
        EDIT :
        
        Et cela ne résout pas la question des fonctionnalités que Flatpak propose ou proposera nativement et que AppImage ne fournit pas ou laisse en exercice à l'utilisateur. Niveau simplicité et complétude on a vu mieux.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 15:42. Évalué à 1.
        
        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 :-)…
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 16:04. Évalué à 2.
        
        Disons que quand tout ce qu'il faut c'est un double clique, on va confier l'intégration à qui d'autre ?
        
        Il y a la voie usuelle de définir l'association type de fichiers - comportement ou application à lancer pour que ton navigateur de fichiers sache quoi faire. C'est comme ça que Nautilus ouvre le fichier MP3 de la bonne manière pour toi, il n'y a pas de code spécifique à Nautilus pour gérer ce cas particulier.
        
        Il n'y a aucune raison que AppImage ait un passe droit là dessus alors que Flatpak et d'autres formats de fichiers savent gérer cela depuis longtemps d'une manière générique.
        
        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 ?
        
        Je m'en fou personnellement de ces histoires de KISS ou pas KISS qui sont pour moi une chimère et des notions floues appliquées trop strictement. Mais c'est toi qui me parle de la simplicité et l'élégance de AppImage mais qui exige pour une raison non justifiée du code spécifique dans Nautilus. Ce n'est pas cohérent.
        
        Envoie un mail à Linus, si c'est pas inclus, c'est un bug du paquet !
        
        Linus ne gère plus Subsurface aux dernières nouvelles, et je croyais que cela devait être simple pour le développeur et universel ? Avec Flatpak pas de surprise, tu sais ce qu'il y a dans le runtime et tu actives ce qui manque. Ici apparemment tu dois savoir si la bibliothèque exigée est bien présente ou non dans la base du système exécutant au préalable avant de décider de l'inclure. Super.
        
        Pour information j'ai testé quelques paquets :
        
        Firefox ;
        
        Inkscape ;
        
        GIMP ;
        
        AzPainter.
        
        À part Firefox qui s'est lancé directement, le reste n'a pas fonctionné car il y avait des soucis de symboles ou de dépendances non satisfaites.
        
        Je les ai tous télécharger depuis ce lien comme indiqué par le site officiel de AppImage. Et étant donné le nom du mainteneur du dépôt qui est le développeur principal de AppImage, je présume qu'il s'en est occupé lui même de le remplir. Et pourtant ça fonctionne mal.
        
        Cette solution fait face à des difficultés que Flatpak résout via la couche de compatibilité lourde que tu décries tant.
        
        [^] # Re: Sans moi
        
        Posté par FluffyHamster le 15 juillet 2019 à 16:22. Évalué à 0.
        
        Tu dois inclure toute les dépendances dans un AppImage, point barre. Si il en manque une, c'est un bug. Personnellement j'utilise un outils pour toute les trouver de manière automatique.
        Tu n'a donc jamais eu une dépendance manquante dans un paquet fedora que tu sois obligé d'en voir la une faiblesse inhérente au AppImage et inexistante ailleurs ?
        
        [^] # Re: Sans moi
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 23:20. É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 nokomprendo (site web personnel) le 15 juillet 2019 à 20:20. Évalué à 4.
        
        Ce que Flatpak propose en pêle-mêle c'est :
        
        De quoi installer une application indépendamment de son système, en étant plus ou moins statique ;
        
        Que cette application soit installable par un utilisateur sans droit super utilisateurs, simple d'utilisation et intégré (disponible via le menu système) sans complications ;
        
        Permettre de mutualiser autant que possible les bibliothèques de base entre les applications ;
        
        Isoler l'application dans un bac à sable et permettre à l'utilisateur d'allouer au cas par cas à l'application des droits supplémentaires ou certains accès en dehors de ce bac à sable.
        
        Je suis désolé mais tout ce que vous présentez ici comme alternatives sont des solutions qui ne répondent qu'à certaines problématiques et où ajouter les autres fonctionnalités ne sont pas simples.
        
        Je suis désolé mais Nix répond aux 3 premiers points, depuis plus de 10 ans. Le 4e point n'est géré que partiellement mais devrait pouvoir être compléter assez facilement.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 21:04. Évalué à 1.
        
        Je suis désolé mais Nix répond aux 3 premiers points, depuis plus de 10 ans. Le 4e point n'est géré que partiellement mais devrait pouvoir être compléter assez facilement.
        
        Permet moi d'en douter. Non pas que ce soit impossible mais je pense que tu sous estimes la tâche, ou que tu sous estimes le but de Flatpak derrière.
        
        Car oui, isoler une application avec droits d'accès sur rien (ou à presque tout) sans gestion fine ou dynamique, c'est en effet assez simple. Et je ne doute pas que Nix puisse le faire.
        
        Ici on parle de la possibilité que l'utilisateur puisse configurer de son côté les opérations possibles par une application, avec une UI compréhensible. Et qu'en cours d'utilisation il puisse autoriser ou refuser une permission à la volée. Via une pop up par exemple quand l'application a besoin d'une autorisation temporaire. Un peu comme Firefox aujourd'hui le propose.
        
        Et ça ça va demander un certain travail qui pour moi est hors champ de Nix. D'autant que le but est de s'accoupler avec Wayland et Pipewire pour fournir justement l'isolation (ou les autorisations) nécessaires.
        
        [^] # Re: Sans moi
        
        Posté par nokomprendo (site web personnel) le 15 juillet 2019 à 21:37. Évalué à 1.
        
        Permet moi d'en douter. Non pas que ce soit impossible mais je pense que tu sous estimes la tâche, ou que tu sous estimes le but de Flatpak derrière.
        …
        
        Oui peut-être. Ou peut-être que c'est toi qui sous-estimes les possibilités de Nix. Et comme le monde Flatpak ne s'est certainement jamais vraiment intéressé à Nix et ne s'y intéressera certainement jamais vraiment, on ne saura sans doute jamais.
        
        [^] # Re: Sans moi
        
        Posté par fredoche le 16 juillet 2019 à 23:34. Évalué à -1.
        
        Tu pourrais développer et expliquer plutôt que de balancer des trucs à l'emporte pièce et te plaindre. Mais non c'est plus facile de faire bosser ton interlocuteur comme un valet.
        
        [^] # Re: Sans moi
        
        Posté par nokomprendo (site web personnel) le 17 juillet 2019 à 00:10. Évalué à 6.
        
        J'ai écrit une vingtaine d'articles à propos de Nix/Nixos/Guix sur ma page perso et plusieurs sur LinuxFR. Commence peut-être par les lire. Les développeurs de Nix bossent sur leur projet depuis au moins 2006. Les pro-flatpak débarquent et balaient tout d'une main sans visiblement rien connaitre au projet. Mais c'est moi qui devrait développer et expliquer…
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 17 juillet 2019 à 00:23. Évalué à 0.
        
        Sauf que j'ai bien lu de la documentation de Nix, sisi, et je ne vois pas en quoi le système de cloisonnement envisagé par Flatpak a un équivalent dans cet écosystème, ni en quoi ce serait simple de l'ajouter tellement cela semble assez éloigné de ce qu'ils fournissent et qu'il y a un gros travail à effectuer pour fournir quelque chose qui y ressemble où que ce soit.
        
        Et si c'était simple et conceptuellement cohérent, qu'attendent les développeurs de Nix de s'inspirer de Flatpak là dessus pour démontrer leur supériorité à toute épreuve ? Ce serait facile ensuite de démontrer que Flatpak ne sert à rien et n'a pas de valeur ajoutée si une solution concurrente propose toutes les fonctionnalités voulues avant le reste.
        
        Et pourquoi l'équipe de Nix ne fait pas beaucoup plus de travail de communication pour démontrer la supériorité de leur solution (et rappeler au monde qu'ils existent) ? C'est à eux de communiquer sur leurs travaux pour susciter de l'intérêt.
        
        J'attends donc de véritables arguments techniques car très honnêtement, il n'y a rien de trivial à ce sujet.
        
        [^] # Re: Sans moi
        
        Posté par Gabin3 le 17 juillet 2019 à 11:11. Évalué à -8.
        
        Et pourquoi l'équipe de Nix ne fait pas beaucoup plus de travail de communication pour démontrer la supériorité de leur solution (et rappeler au monde qu'ils existent) ? C'est à eux de communiquer sur leurs travaux pour susciter de l'intérêt
        
        Tout à fait d'accord.
        
        Et c'est déjà mal barre d'un point de vue image car il y a déjà un fork de Nix nommé Guix.
        
        Le forking fait parti de l'Open Source blah-blah…
        Et un gestionnaire et distro de plus, ouééé \o/
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 16 juillet 2019 à 21:28. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Sans moi
        
        Posté par rewind (Mastodon) le 15 juillet 2019 à 10:47. Évalué à 2.
        
        Debian ne fournissant que firefox-esr (60.8)
        
        Même avec une Debian stable, en activant les dépôts stable-updates, anciennement volatile, (fait automatiquement à l'installation), tu as un firefox récent. Avec Stretch (l'ancienne stable), tu avais firefox 60.6, donc pas trop daté.
        
        Donc pas besoin d'un flatpak.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 11:13. Évalué à 5.
        
        Donc pas besoin d'un flatpak.
        
        Parce que tu estimes que ce n'est pas nécessaire. Si la personne veut avoir la dernière version de Firefox (non ESR) quel qu’en soit la raison mais le reste des logiciels de Debian comme d'habitude, tu n'as pas de choix simple.
        
        Ce n'est pas un besoin aberrant de vouloir bénéficier des dernières évolutions de son navigateur Internet comme macOS ou Windows le proposent. C'est un peu facile de dire que Flatpak est inutile si on considère que le besoin qu'il tente de résoudre n'existe pas. Sauf que c'est quand même une critique récurrent de l'écosystème actuelle, à savoir que les distributions sont trop rigides sur les versions proposées, il est bien d'essayer d'en tenir compte et de le résoudre.
        
        [^] # Re: Sans moi
        
        Posté par rewind (Mastodon) le 15 juillet 2019 à 12:02. Évalué à 2.
        
        Sauf que c'est quand même une critique récurrent de l'écosystème actuelle, à savoir que les distributions sont trop rigides sur les versions proposées, il est bien d'essayer d'en tenir compte et de le résoudre.
        
        Je crois que tu n'as pas compris. Justement, stable-updates sert à répondre à cette problématique, ça sert à avoir des logiciels récents sur une base stable. Dans stable-updates, tu as quelques logiciels qui sont mis à jour au moment de leur sortie, les navigateurs en font partie.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 12:43. Évalué à 1.
        
        Sauf que Debian n'est pas la seule distribution du monde, que cela se limite aux paquets maintenus par Debian et que Debian veut ou peut proposer dans ce dépôt particulier et que si une autre distribution veut fournir la même chose elle doit le faire de son côté ce qui prend du temps et demande des mainteneurs. Or le nombre de mainteneur n'est pas infini.
        
        Et l'autre soucis, c'est que c'est distribution spécifique. Si je déploie une application, pour que l'utilisateur ait la dernière version de mon application, je dois décrire ou guider les utilisateurs à travers différentes démarches uniques. Ou le laisser se démerder.
        
        Avec Flatpak, je peux proposer mon installateur unique, et roulez jeunesse ça fonctionnera. La procédure à décrire sera unique. Le développeur peut contrôler la diffusion de son application si elle le souhaite plus facilement.
        
        [^] # Re: Sans moi
        
        Posté par jyes le 15 juillet 2019 à 14:21. Évalué à 7.
        
        je peux proposer mon installateur unique
        
        Parce-que tu supposes que Flatpak va rafler la mise et que tout le monde va l’utiliser. En attendant, on peut aussi envisager un futur où il faudra faire un Flatpak pour Gnome Logiciels, un Snap pour Ubuntu et un AppImage pour ceux qui n’ont pas les clients Flatpak et Snap d’installés (sur leur Slackware :-)). Et ça, c’est si tout marche dans ces conditions, et pour le moment les solutions Flatpak et Snap sont pleines de promesses mais encore peu matures. Par exemple, avec Flatpak, on peut utiliser la dernière version de Gimp mais elle peine à trouver ses plugins. Donc on peut sûrement ajouter à la liste que pour un fonctionnement optimal il faudra pendant longtemps encore ajouter un deb, un rpm et une recette AUR/Gentoo/etc.
        
        Tu as le droit d’être optimiste pour Flatpak (tant mieux si une solution prend) mais ta réponse consiste un peu à dire que le problème ne se poserait pas si tout le monde se mettait d’accord pour utiliser Debian. Debian stable serait ton runtime et stable-updates remplacerait Flathub. Dans ces conditions, c’est facile d’identifier une solution qui marche, il suffit que tout le monde l’utilise, mais ça ne dit rien sur la pertinence technique de la solution.
        
        [^] # Re: Sans moi
        
        Posté par Renault (site web personnel) le 15 juillet 2019 à 14:34. Évalué à 3.
        
        Parce-que tu supposes que Flatpak va rafler la mise et que tout le monde va l’utiliser.
        
        Pas du tout, relis mon commentaire et celui auquel je réponds. Il dit que Debian propose un dépôt pour avoir sur une Debian stable certains logiciels plus à jour que dans le dépôt de base. C'est bien, mais ce n'est pas une raison suffisante pour dire que Flatpak est inutile, que ce soit pour Debian comme pour le reste.
        
        En attendant, on peut aussi envisager un futur où il faudra faire un Flatpak pour Gnome Logiciels, un Snap pour Ubuntu et un AppImage pour ceux qui n’ont pas les clients Flatpak et Snap d’installés (sur leur Slackware :-)).
        
        Sauf que, à priori, toutes les distributions majeures sont compatibles Flatpak dès maintenant, c'est donc une certaine garantie pour le développeur qui l'adopte aujourd'hui. Même s'il existe des formats alternatifs.
        
        Par exemple, avec Flatpak, on peut utiliser la dernière version de Gimp mais elle peine à trouver ses plugins. Donc on peut sûrement ajouter à la liste que pour un fonctionnement optimal il faudra pendant longtemps encore ajouter un deb, un rpm et une recette AUR/Gentoo/etc.
        
        Personne n'a dit que Flatpak c'était fini, stable et sans défauts. Même pas moi. Je suis parfaitement conscient des manques actuels mais je sais que ça évolue bien et vite et qu'il y a de gros efforts pour résoudre ces problèmes. De même que le passage à Wayland et Pipewire va rendre Flatpak encore plus intéressant qu'il ne l'est aujourd'hui.
        
        Mais cela reste quand même utilisable dans de nombreux cas, et personnellement ça m'a déjà servi concrètement.
        
        Debian stable serait ton runtime et stable-updates remplacerait Flathub. Dans ces conditions, c’est facile d’identifier une solution qui marche, il suffit que tout le monde l’utilise, mais ça ne dit rien sur la pertinence technique de la solution.
        
        Sauf que une distribution n'est pas qu'une collection de logiciels et que l'existence des autres est dû à d'autres critères que Debian ne gère pas de la même façon. Donc comparer des choux et des carottes n'a pas de sens.
        
        Justement Flatpak vise à régler cette problématique de compatibilité entre les distributions de manière globale en plus d'apporter d'autres choses pour rendre le déploiement d'applicatifs sous Linux plus sûr et simple. C'est une solution transversale, ce que n'est pas Debian par nature.
    - [^] # Re: Sans moi
      
      Posté par Gabin3 le 15 juillet 2019 à 02:37. Évalué à -2.
      
      Pourtant c'est bien plus simple que de se farcir RPM et DEB et autres.
      
      Vraiment pas plus simple qu'un Appimage.
      
      Si tu es GNOME centrique, oui, tu pourras tâter de la dernière version de bijiben qui permet de rechercher dans tes notes mais à part ça, en terme de logiciels pas plus que dans les repo de ma distros.
      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.
      
      Il y aussi l'absence de repo/store de référence et plutôt vides.
      
      AppImage ne nécessite aucuns tool annexe, les paquets sont en dessous des 200mo et fonctionnent partout.
      J'ai pu, grâce à ce format, tester les dernières version de Krita, Kdenlive ou compléter un atelier de dev application mobile hybride avec appium (distribué sous forme d'AppImage). Et ce, sans installer 3 tonnes de données.
      
      Je garde les repo de ma distro stable comme source principale et j'ai recours à Appimage si je ne sais pas compiler l'application de manière raisonnable ou pour la partager. Appimage résout aussi le partage d'application propriétaire pour ceux que ça intéresse.
      
      Alors Flatpak apporte le sandboxing, pourtant firejail existait déjà. Et encore une fois, intérêt majeure pour les applis hors depôts officiels et ou proprio.
      
      Mais et surtout, il n'est en rien facile pour l'utilisateur finale.
      - [^] # Re: Sans moi
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 03:26. Évalué à 2.
        
        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.
        
        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.
        
        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.
  - [^] # Re: Sans moi
    
    Posté par FluffyHamster le 14 juillet 2019 à 11:52. Évalué à 2.
    
    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.
    - [^] # Re: Sans moi
      
      Posté par Albert_ le 16 juillet 2019 à 22:49. Évalué à 1.
      
      Il faut aussi sortir les environnement et comme cela ne suffit un petit:
      sudo rm -rf /var/lib/flatpak
      
      Ou un truc comme ca pour le chemin te permettra de recuperer la place.
      - [^] # Re: Sans moi
        
        Posté par FluffyHamster le 17 juillet 2019 à 12:12. Évalué à 4.
        
        Alors ça c'est pas banale.
        Mon propre gestionnaire de paquet (10746 paquets et 54K paquets utilisateurs, dont 1679 d'installés) à un /var/lib/pacman de 130 Mo.
        
        Aujourd'hui mon /var/lib/flatpak fait 574 Mo, 20 de plus qu'il y à quelque jour (??) (pour 600 apps en lignes et 0 d'installée). Je pense qu'explorer un peu dans Gnome Software a du causer cet embonpoint. Ça aurai été /tmp ou /var/tmp j'aurai peut être fait un RM, mais la j'aurai plus confiance dans les outils. Mais qui ou quoi s'occupe de remettre un peu de bon sens la dedans ?
- [^] # Re: Sans moi
  
  Posté par Melodie (site web personnel) le 21 juillet 2019 à 00:53. Évalué à 3.
  
  Le grand public se fiche bien des gestionnaires de paquets truc bidule ou machin, il ne veut que deux choses : que ce soit simple, et que ça marche. Donc, que ce soit un système ou un autre, s'il a une "logithèque" (quel que soit le look de l'interface graphique) et qu'on lui montre comment l'utiliser, ça lui va. De plus, le grand public a des demandes le plus souvent limitées en terme d'applications à employer (tout en appréciant de savoir qu'il existe un large choix disponible). Si je commence à dire à mon public "vous avez ça, et puis aussi ça, et puis encore ça et ça et ça pour installer un programme" il va me regarder avec des yeux ronds et s'enfuir en lâchant "c'est trop compliqué !!!". ":D
  (Cela sent-il assez le vécu ? :p )
# Et Nix / Guix ?

Posté par nokomprendo (site web personnel) le 14 juillet 2019 à 13:22. Évalué à 10.

Beaucoup des problèmes classiques des gestionnaires de paquets sont déjà gérés par Nix : installation par l'utilisateur, installation de logiciels extérieurs à la logithèque standard, isolation, réutilisation des dépendances sans duplication, possibilité d'inclure des binaires, etc. L'outil existe depuis plus de 10 ans et est utilisable sur à peu près toutes les distribs linux et sur macos.

Le plus gros problème des outils comme Nix ou Guix, c'est qu'il faut presque un bac+5 en informatique pour arriver à s'en servir correctement. Pourquoi ne pas "juste" en développer une interface utilisateur simple et contribuer à la doc, logithèque, intégration dans les distribs, etc ?
# trop de place

Posté par Albert_ le 14 juillet 2019 à 13:57. Évalué à 3. Dernière modification le 14 juillet 2019 à 14:02.

J'ai l'impression que les trucs comme flatpack and co c'est pour que les distribs ne s'occupent plus du packaging.

J'ai tenté d'utiliser flatpak et j'en suis vite revenu. Je J'avais mis 'que' 20 gigs a ma partition root et lorsque j'ai vu que j'avais un certain nombre de gigas de pris pour 2 ou 3 logiciels qui n'auraient pris qu'une dizaine ou deux de megas par mon système de packaging, flatpak a été dégagé vite fait.

Le seul 'interet' est pour avoir une version récente d'un logiciel mais j'utilise arch donc cela ne me concerne pas trop.
- [^] # Re: trop de place
  
  Posté par Okki (site web personnel, Mastodon) le 14 juillet 2019 à 20:11. É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é.
  - [^] # Re: trop de place
    
    Posté par Albert_ le 15 juillet 2019 à 08:59. Évalué à 5.
    
    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é.
    
    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)…
    
    Et quand je vois la taille d'un paquet appImage avec celui de flatpak ca fait un peu mal au c.. juste pour avoir un bac a sable et la je me dit que pourquoi ne pas aller directement sur du Docker du coup… cela sera a peine plus gros et au minimum aussi bien sécurisé…
    - [^] # Re: trop de place
      
      Posté par FluffyHamster le 15 juillet 2019 à 10:11. Évalué à 4.
      
      ç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".
      - [^] # Re: trop de place
        
        Posté par Renault (site web personnel) le 16 juillet 2019 à 11:27. Évalué à 3. Dernière modification le 16 juillet 2019 à 11:29.
        
        Pour information Flatpak conserve les runtimes même quand ils ne sont plus nécessaires par tes applications. Tu peux nettoyer ton disque dur en faisant :
        
        $ flatpak uninstall --unused
        
        Sans doute que l'UI ou le comportement par défaut devrait proposer d'effectuer ce nettoyage lors de certaines opérations comme une mise à jour.
        
        De plus Flatpak supporte aussi la mise à jour par delta pour économiser de la bande passante et de l'espace disque lors d'une mise à jour.
    - [^] # Re: trop de place
      
      Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 13:43. Évalué à 4.
      
      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.
      - [^] # Re: trop de place
        
        Posté par FluffyHamster le 15 juillet 2019 à 13:47. Évalué à 5.
        
        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.
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 14:15. É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 FluffyHamster le 15 juillet 2019 à 14:50. Évalué à 2.
        
        Ç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).
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 15:40. É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 Yala le 15 juillet 2019 à 16:41. Évalué à 4.
        
        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 ?
        
        Pour ma part, l'argument anti-flatpak à propos du poids, c'est surtout une question de bande passante. Télécharger 1 Go de données (et y passer quelques heures ou exploser mon forfait, j'utilise régulièrement des connexions pourrites ou de la 3g) pour un truc qui pourrait peser 20 ou 30 Mo, non merci.
        
        [^] # Re: trop de place
        
        Posté par FluffyHamster le 15 juillet 2019 à 16:48. Évalué à 3.
        
        60 * 35 Mo, on sera toujours en positif vis à vis de flatpak :-/
        
        attentif et réactif concernant les questions de sécurité des dépendances
        
        Mes AppImages sont en générés en intégration continue, et ils utilisent toujours la dernière version des libs disponibles sur la distrib hote. Donc… je suis aussi réactif qu'humainement et technologiquement possible. Si j'ai un doute je peux régénérer un commit en un clique.
        
        Et est-ce que tu peux garantir que tous les autres éditeurs qui proposent des AppImage le seront également
        
        Ha carrément ?! C'est à moi de garantir la sécurité des paquets des autres maintenant ??? Donc, pour te répondre, pas plus que je ne peux garantir la sécurité des flatpak qui ne sont pas fait par moi.
        
        Quelqu'un vérifie la sécurité des flatpaks qui sont uploadés sur flathub ? Quelqu'un vérifie que l'utilisateur est la dernière version du noyau pour garantir que la sandbox (cgroups…) est "invulnérable" ou juste à jour ? Quelqu'un peut garantir qu'il n'y à pas de mineur bitcoin ou de relais tor pédoporno dans ton flatpak sandboxé ??? Debian c'est pas trimbalé 10 ans avec une faille monstrueuse dans la génération de clé ? Tu leur fais toujours confiance ? Qui te garantie quoi que se soit dans un logiciel libre ? Ça fais même partie de la licence, paragraphe 0 : "there is no warranty for the work" ou dans les headers "WITHOUT ANY WARRANTY".
        
        Molotov, pour chaque vulnérabilité dans une dépendance j'ai aucun doute qu'il y en à 100 dans Molotov en lui même. Donc dépendance à jour ou pas, je n'aurai jamais confiance en Molotov. Ce qui m'empêchera pas de le lancer si j'en ai besoin.
        Je n'utilise pas beaucoup de logiciels propriétaires, mais j'utilise une blinde de jeux vidéo par exemple. Steam me garantit kedal niveau sécurité.
        Pose la même question à n'importe quel Windowsien qui installe n'importe quel logiciel, depuis 30 ans. Tu va tenter de le convaincre de tout désinstaller lui ? Par ce qu'un binaire, c'est maal ? Pourquoi est ce que ça devrai devenir aujourd'hui un point central à virer tout le reste ?
        
        En tant qu'utilisateur, je ne me voile pas la face. En RIEN je ne peux garantir la sécurité de mon système. Quiconque me garantie la sécurité d'un système informatique, j’appelle ça un menteur.
        J'ai une Arch Linux toujours à jour, il n'y à pas plus récent, les vulnérabilités publiées dans n'importe quel logiciel sont corrigées dans la journée, souvent bien avant que je lise les articles polémiques qui arrivent régulièrement. Au delà, je n'ai absolument AUCUN doute qu'un hacker compétant parviendra sans AUCUN problème à pirater mon système.
        J'utilise un navigateur Internet tout les jours, il a je sais pas combien de sandbox, et pourtant je suis conscient que je peux me faire poutrer à distance au moindre instant. Prétendre l'inverse c'est ignorer l'histoire et la réalité. Prétendre qu'une dépendance à jour ou une sandbox c'est la sécurité…
        
        Triste époque, mais qu'est ce que tu veux que je te dise ?!
        
        T'es pas obligé de me croire, à vrai dire tu n'a aucune raison de le faire, tu peux écouter un expert de renommée mondiale te parler du concept de sécurité et du concept de confiance : https://www.ted.com/talks/bruce_schneier/transcript.
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 18:32. Évalué à 0.
        
        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…
        
        [^] # Re: trop de place
        
        Posté par FluffyHamster le 15 juillet 2019 à 18:42. Évalué à 1.
        
        Sans dec, si un développeur meurt, tu penses à la mise à jour des dépendances de son projet ?
        
        Tu fais plus confiance à un AppImage que j'ai fais moi, ou à un flatpak de Microsoft ?
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 19:12. É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) le 15 juillet 2019 à 19:20. É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 FluffyHamster le 15 juillet 2019 à 19:37. Évalué à 1.
        
        Tout ou rien je confirme. Après tu peux le faire toi même de sandboxé une app, rien ne t'empêche, mais j'ai jamais testé le fameux firejail.
        
        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. Sur Android, si tu bloques une fonctionnalité quand il te le demande, globalement, l'application arrête de fonctionner. Surtout celles qui sont malveillantes justement. Comme les sites web qui te demandent "le tracking ou retourne sur google".
        
        A l'époque de Cyanogen ils avaient été plus malin. Le système répondait "oui" à la demande de permission de l'application, comme ça l'appli ne pouvait pas bloquer l'app sans raison, mais retournait par exemple un carnet d'adresse vide ou une image noir pour la webcam. "Étonnement" Google n'a jamais retenu la feature…
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 20:48. Évalué à 5.
        
        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
        
        [^] # Re: trop de place
        
        Posté par FluffyHamster le 16 juillet 2019 à 10:36. Évalué à 0.
        
        Ha oui j'avais déjà vu cette interface pour les applications au détours d'un menu. En effet on peut pas changer grand chose mais c'est un début. Je vois que des AppImages apparaissent dans la liste, et il me propose d'aller consulter leur page sur gnome software :)
        
        Apple y est bien arrivé avec toutes les applications macOS de l'AppStore
        
        Oui Apple impose la sandbox pour le store. Les grands éditeurs par contre, vu qu'ils n'ont pas besoin du store pour être connus, peuvent le contourner pour éviter les 30% d'Apple, mais aussi la sandbox (si tu as une clé de chiffrement du store, tu peux activer la sandbox quand même, mais bon), car la sandbox, elle à cette réputation "moins rapide, moins de fonctionnalité".
        Car même Apple te permet de diffuser tes logiciels comme tu veux grâce à leur format d'application.
        
        [^] # Re: trop de place
        
        Posté par FluffyHamster le 15 juillet 2019 à 19:27. Évalué à 1.
        
        Rassure toi je ne sous entendais pas un manque de respect. Pour moi un logiciel abandonné, c'est une raison valable d’arrêter de l'utiliser. A court terme il y à de forte chance qu'une dépendance casse tout court, en plus de sa sécurité.
        
        [^] # Re: trop de place
        
        Posté par Albert_ le 15 juillet 2019 à 16:50. Évalué à 1.
        
        Tellement de conditionnel pour un truc soit disant mature…
        
        Parceque tout ce que tu dis c'etait déjà la pub de flatpak (et ce pourquoi j'ai tenté ) mais bon quelques années plus tard la situation n'a toujours pas évolué et même si les coûts des disques ont diminué je ne trouve toujours pas que le jeu en vaut la chandelle comparer à passer sur une distrib comme arch.
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 18:38. É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 FluffyHamster le 15 juillet 2019 à 18:44. Évalué à -1.
        
        D'après distrowatch, la première distribution sur l'année dernière c'est Manjaro, qui est une Arch Linux avec un installeur graphique. Donc pourquoi pas après tout ?
        
        [^] # Re: trop de place
        
        Posté par Okki (site web personnel, Mastodon) le 15 juillet 2019 à 19:05. É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 FluffyHamster le 15 juillet 2019 à 19:17. Évalué à 0. Dernière modification le 15 juillet 2019 à 19:19.
        
        Oui bien sur distrowatch mesure plus l’intérêt qu'autre chose, compter les installs c'est dur. Effectivement sur steam "Arch based" est 2e (woohoo) derrière "Ubuntu based".
        
        [^] # Re: trop de place
        
        Posté par Gabin3 le 16 juillet 2019 à 13:42. Évalué à -6.
        
        Effectivement sur steam "Arch based" est 2e (woohoo) derrière "Ubuntu based".
        
        Rien d'étonnant, les autres bossent.
        
        [^] # Re: trop de place
        
        Posté par FluffyHamster le 16 juillet 2019 à 14:22. Évalué à 0.
        
        anéfé :)
        
        [^] # Re: trop de place
        
        Posté par Albert_ le 15 juillet 2019 à 22:54. Évalué à 0.
        
        Et elles vont installer un centos et autoriser les flatpak peut être…
        
        Soyons sérieux 2 secs
        
        Quitte a utiliser un truc bien bloatware je pense que docker est nettement plus top car en plus tu a un coté multiplateforme…
        
        Quitte a faire sale ne faisons pas a moitié 😃
# Séparation app / système

Posté par Athel le 15 juillet 2019 à 10:10. Évalué à 3.

Un argument en faveur de ce genre de sytème par rapport au packaging des distributions c'est la séparation que cela permet entre le système et les app utilisateurs.

Flatpak et consort une fois installés ne nécessitent pas de droits particulier pour ajouter de nouvelles applications.

Point de vu administration système il est du coup plus facile de fournir un système de "base" et de laisser l'utilisateur choisir les app qu'il veut utiliser.
- [^] # Re: Séparation app / système
  
  Posté par Albert_ le 15 juillet 2019 à 22:56. Évalué à 0.
  
  Donc c'est plus sécurisé mais on laisse n'importe quel utilisateurs mettre ce qu'il veut… j'ai comme un doute sur le sujet surtout en environnement multiutilisateurs…
  - [^] # Re: Séparation app / système
    
    Posté par YBoy360 (site web personnel) le 16 juillet 2019 à 15:08. Évalué à 2. Dernière modification le 16 juillet 2019 à 15:09.
    
    Tu peux restreindre les droits à l'utilisateur root comme pour RPM ou deb.
    
    Question sécurité, toutes les nouvelles plateformes proposent maintenant des sandbox. Que ce soit Chrome, Windows ou Apple. Par contre, ce n'est pas transparent.
    
    Si tu utilises libreoffice de Flatpak et que tu ouvres un csv, tu n'as pas les options dans le file chooser, puisque c'est celui par défaut de ton desktop.
    - [^] # Re: Séparation app / système
      
      Posté par Albert_ le 16 juillet 2019 à 18:36. Évalué à 1.
      
      C'est tellement top les sandbox … pour les marchand de ssd !
      Sous Android, par exemple, si deux utilisateurs ca veut dire deux installe du logiciel. C'est beau non?
  - [^] # Re: Séparation app / système
    
    Posté par eric gerbier (site web personnel) le 17 juillet 2019 à 13:06. Évalué à 1.
    
    La sécurité, c'est aussi faire les mises à jour des logiciels installés. Est-ce que c'est le travail de l'utilisateur ?
    - [^] # Re: Séparation app / système
      
      Posté par Okki (site web personnel, Mastodon) le 17 juillet 2019 à 14:57. Évalué à 2.
      
      Par défaut (c'est configurable), la logithèque GNOME met automatiquement à jour les Flatpak.
- [^] # Re: Séparation app / système
  
  Posté par Albert_ le 15 juillet 2019 à 23:04. Évalué à 0. Dernière modification le 15 juillet 2019 à 23:05.
  
  Oups erreur doublon
# Snap Vs Flapak ?

Posté par freejeff le 16 juillet 2019 à 09:16. Évalué à 3. Dernière modification le 16 juillet 2019 à 09:16.

Je n'ai pas vraiment compris la différence entre les deux logiciels.

Quelles sont les choses que l'on peut faire avec l'un et pas avec l'autre et réciproquement ?
- [^] # Re: Snap Vs Flapak ?
  
  Posté par Albert_ le 16 juillet 2019 à 11:26. Évalué à -3.
  
  Ubuntu versus RedHat
- [^] # Re: Snap Vs Flapak ?
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 16 juillet 2019 à 18:55. Évalué à 6.
  
  De ce que j'ai vu:
  
  Snap permet d'installer tout type de logiciel alors que Flatpak se limite aux applications pour Desktop. Snap peut donc être utilisé sur des serveurs comme alternative à Docker par exemple.
  
  Snap n'a qu'un seul dépôt centralisé: celui fournit par Canonical et le client ne fonctionne qu'avec lui. Flatpak est capable d'utiliser plusieurs dépôts et il est possible de créer son propre dépôt.
  
  Flatpak utilise OSTree comme gestionnaire de version des runtime. Je ne sais pas si Snap sait aussi faire du téléchargement différentiel.
  
  Ubuntu souhaitait, avant de détruire son développement pour tablettes, proposer un système d'exploitation en lecture seul Ubuntu Core avec le minimum d'outils. Tout le reste devait provenir des Snaps.
  
  Fedora a une même idée avec Silverblue comme OS et Flatpak pour les applications.
  - [^] # Re: Snap Vs Flapak ?
    
    Posté par ord le 17 juillet 2019 à 09:22. Évalué à 1. Dernière modification le 17 juillet 2019 à 09:24.
    
    Snap n'a qu'un seul dépôt centralisé: celui fournit par Canonical et le client ne fonctionne qu'avec lui. Flatpak est capable d'utiliser plusieurs dépôts et il est possible de créer son propre dépôt.
    
    J'ai lus ca plusieurs fois dans les commentaires, mais il semble que c'est completement faux: lire par example ca de 2016: http://blog.dustinkirkland.com/2016/06/howto-host-your-own-snap-store.html
    
    Edit: il semblerait que ca ne marche plus: https://github.com/noise/snapstore/
    - [^] # Re: Snap Vs Flapak ?
      
      Posté par ord le 17 juillet 2019 à 09:38. Évalué à 1.
      
      Je confirme. Il semble que il etait possible en 2016 de faire son propre depot snap et que Connical a retire volontairement cette possibilite: https://forum.snapcraft.io/t/external-repositories/1760/176
      - [^] # Re: Snap Vs Flapak ?
        
        Posté par Albert_ le 18 juillet 2019 à 18:58. Évalué à 2.
        
        Ce n'est absolument pas ce que dis le message que tu mentionnes qui ne parle que possibilité de build de packages pour une architecture special.
      - [^] # Re: Snap Vs Flapak ?
        
        Posté par Albert_ le 18 juillet 2019 à 19:08. Évalué à 2.
        
        https://uappexplorer.com/faq
        
        Uh snap store non canonical semble pourtant exister.
    - [^] # Re: Snap Vs Flapak ?
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 juillet 2019 à 20:16. Évalué à 2. Dernière modification le 17 juillet 2019 à 20:16.
      
      Cette remarque me vient de Richard Hugues qui maintient GNOME Software: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/
      
      Dans ce mail, il explique pourquoi également il souhaite retirer le support de Snap dans GNOME Software.
      - [^] # Re: Snap Vs Flapak ?
        
        Posté par Albert_ le 18 juillet 2019 à 18:53. Évalué à 2.
        
        Il explique surtout que fedora a décider de sortir de gnome software tout ce qui concerne snap.
        
        [^] # Re: Snap Vs Flapak ?
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 18 juillet 2019 à 20:55. Évalué à 4.
        
        As you might know, enabling the snap plugin also enables the "Snap
        Store" which seemingly violates the same rules which prevent us
        installing Flathub by default (enabling access to nonfree software,
        and software with patent restrictions). Without the Snap Store the
        snap support is pretty useless, as snapd is so tied to the snapcraft
        ecosystem, and because you can't actually run your own instance of the
        snap store, unlike Flatpak.
        
        L'emphase est de moi et ça me paraissait assez claire: snap est bien trop lié à snapcraft (le store d'Ubuntu si j'ai bien compris) et du coup, ce n'est pas utilisable avec un autre store.
        
        Richard Hugues est bien un des auteurs de Gnome Software et, vu les arguments qu'il donne pour le retrait de Snap dans le Gnome Software de Fedora, j'imagine que ce sera pour actif ensuite pour Gnome Software directement (l'emphase est de moi à nouveau):
        
        The existing snap plugin is not very well tested and I don't want to
        be the one responsible when it breaks. At the moment enabling the snap
        plugin causes the general UX of gnome-software to degrade, as all
        search queries are also routed through snapd rather than being handled
        in the same process. The design of snapd also means that packages just
        get updated behind gnome-software's back, and so it's very hard to do
        anything useful in the UI, or to make things like metered data work
        correctly.
        
        Il dit clairement que Gnome Software ne sert pas à grand chose quand Snap est utilisé, que c'est mal testé et qu'il ne veut pas être responsable le jour où ça sera cassé (dû au choix d'Ubuntu de faire son propre application pour accéder au Snap Store).
# Flatpak vers le cloisonnement du bureau

Posté par lle-bout le 18 juillet 2019 à 03:09. Évalué à 3.

Bonjour,

Je pense qu'il faut habituer les developpeurs d'application bureau Linux ou plus generalement Unix a un environnement cloisonne, et le point fort de Flatpak c'est qu'on peut forcer toutes les applications dans cet environnement au niveau de la distribution.

Pour l'instant Flatpak fait ce qu'il peut, sa capacite a cloisonner est limitee par le fait que la majorite des applications bureau tournent avec X11 qui lui autorise le partage du presse papier entre applications sans controle de la part de l'utilisateur, on peut aussi suivre le curseur lorsque qu'il est sur d'autres applications, simuler des touches clavier et des interactions avec la souris pour au final, prendre le controle du bureau entier.

Je pense que Flatpak est une premiere etape dans cette transition, a la maniere de Android, qui, toujours, est dans une bataille contre les abus des developpeurs d'applications, neanmoins, pour Android, le probleme est plus gros car ces applications sont aussi proprietaires avec un but pas toujours aligne dans l'interet de l'utilisateur.

L'organisation Freedesktop essaye de developper un principe de "portails", l'idee etant d'avoir une interface pour demander l'ouverture d'une fenetre utilisateur pour par exemple ouvrir un fichier. Cette fenetre n'est pas controlee par l'application mais par le systeme ou la "runtime", en l'occurence, potentiellement via Flatpak, cette fenetre est consideree de confiance, etant dans la "Trusted Computing Base" qui va interagir avec le reste sans pour autant avoir confiance. Cette fenetre va donc permettre a un utilisateur d'explorer l'arborescence des fichiers pour en choisir un et ensuite l'application demandeuse recoit un descripteur sur ce fichier et peut le manipuler, mais l'application n'a pas connaissance du reste, elle ne connait pas le nom du fichier, l'arborescence du systeme de fichier, etc.

Personnellement, j'ai envie de pouvoir lancer des applications sur mon systeme sans pour autant craindre que celle ci viole son integrite. J'ai envie de pouvoir lancer des logiciels malveillants sans pour autant risquer quelque chose, a moins que, bien evidemment, je donne des acces suplementaires a ce logiciel malveillant si il le demande, ce que je ne vais pas faire, ou alors faire en mentant, en donnant des acces fictifs a des ressources fabriques pour permettre le fonctionnement du logiciel malveillant sans qu'il puisse savoir qu'il a seulement acces a des donnees fabriques.

Pour moi, Flatpak, sous sa forme actuelle, ou dans une autre forme plus adequate, c'est le debut du futur du bureau sous Linux. Evidemment, cela va etre la porte au logiciel proprietaire, mais au depend des convictions de chacun, ce qui me derange dans le logiciel proprietaire c'est qu'il a du pouvoir, tant que je peux decider de son pouvoir et le cloisonner, j'en suis personnellement satisfait. Je prefere evidemment les alternatives libres, mais quand elles n'existent pas, je prefere pouvoir le cloisonner que de lui donner acces a tout mon systeme ou devoir souffrir la reduction de performance avec une machine virtuelle, par exemple, avec Qubes OS, qui lui, pour palier au probleme, va lancer un serveur X11 par domaine de securite, chacun dans une machine virtuelle dediee, ce qui est efficace et compatible avec les logiciels actuels mais tres lourd pour un ordinateur portable de nos jours.

En esperant avoir ete clair,

Leo
- [^] # Re: Flatpak vers le cloisonnement du bureau
  
  Posté par Tonton Th (Mastodon) le 18 juillet 2019 à 12:11. Évalué à 3.
  
  mais l'application n'a pas connaissance du reste, elle ne connait pas le nom du fichier
  
  Ça me semble quand même un gros problème, de ne pas savoir sur quels fichiers on travaille…
- [^] # Re: Flatpak vers le cloisonnement du bureau
  
  Posté par Albert_ le 18 juillet 2019 à 18:52. Évalué à 3.
  
  Ca va etre un beau cauchemars ce que tu décris. Le presse papier c'est super utile pour copier entre deux documents des choses sans devoir tout retaper. La sécurité c'est bien beau mais quand cela interfère avec inutilisation je te garantie que des moyens de contournement seront trouvé pour ne pas être emmerdé a tout bout de champs. Moyen beaucoup beaucoup plus problématique qu'un presse papier…
  - [^] # Re: Flatpak vers le cloisonnement du bureau
    
    Posté par Okki (site web personnel, Mastodon) le 18 juillet 2019 à 19:04. É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: Flatpak vers le cloisonnement du bureau
      
      Posté par FluffyHamster le 18 juillet 2019 à 21:13. Évalué à 1.
      
      J'imagine qu'il y a moyen
      
      Me voila rassuré. Les portals et les permissions c'est bien, mais à un moment, ou tu les désactives ou tu sacrifie des fonctionnalités.
      Et la différence entre la bonne application sandboxé et la mauvaise application sandboxé, ça devient une ligne dans le manifeste. Et qui lit le manifeste ?
      
      uniquement quand il s'agira d'une action de l'utilisateur
      
      J'en reviens aux fichiers. Donner une permission explicitement sur un filechooser, c'est super élégant ! Sauf quand tu écris un explorateur de fichier… Alors encore une fois, on donne accès à tous les fichiers (pas franchement le choix !). Donc une appli malveillante, du moment que la possibilité existe, elle fera exactement pareil…
      
      Un autre exemple (et on peut en trouver un paquet des comme ça) :
      Avec wayland on peut configurer l'accès aux framebuffers des applis d'à coté il me semble (pour pas qu'une appli malveillante ne puisse aller enregistrer ton navigateur quand tu rentre ton code de CB). Ce qui n'avait jamais été considéré/possible avec X11.
      
      Mais si tu ferme cette possibilité, plus d'applis de screengrab ou de screenshot ! Ou de color picker ! Leur raison d'être c'est précisément d'aller enregistrer les fenêtres d'as coté ! Et quand bien même, Gimp c'est pas ça raison d'être mais il à aussi besoin d'aller voir les fenêtres d'à coté du coup (et Gimp il à des plugins utilisateurs qui tournent, tu vois ou je veux en venir ?).
      Alors tu peux imaginer wirepipe pour partager le framebuffer + une API qui dit "je ne suis pas un contenu sensible, je partage mon framebuffer" (et le navigateur web maintenant il doit demander aux sites si la page courante est sensible ? Donc on demande aussi à nos banques de supporter cette API ?).
      
      Toutes ces APIs elles seront automatiquement prises en charge par qui… ou quoi… ton framework graphique ? (si tu en utilise un, et si il est assez high profile pour que des gens se soit cassé le c*l à supporter ces portails). De manière automatique quand c'est possible, ou manuel avec le risque de créer des applis "linux only" ce qui est très, mais alors très loin d'être un progrès.
      - [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Renault (site web personnel) le 18 juillet 2019 à 21:41. Évalué à 5.
        
        J'en reviens aux fichiers. Donner une permission explicitement sur un filechooser, c'est super élégant ! Sauf quand tu écris un explorateur de fichier… Alors encore une fois, on donne accès à tous les fichiers (pas franchement le choix !). Donc une appli malveillante, du moment que la possibilité existe, elle fera exactement pareil…
        
        Sauf que le navigateur de fichiers a des permissions que les autres applications n'auront pas, pas sans l'aval de l'utilisateur. Cela évite qu'une application fasse on ne sait quoi on ne sait où à l'insu de l'utilisateur.
        
        Ce n'est pas une protection parfaite (après tout l'utilisateur pourrait accorder des droits aberrants si ça lui chante comme sur Android / iOS) mais ça reste bien mieux que de ne rien faire du tout et continuer comme aujourd'hui.
        
        C'est une question de curseur.
        
        Mais si tu ferme cette possibilité, plus d'applis de screengrab ou de screenshot ! Ou de color picker ! Leur raison d'être c'est précisément d'aller enregistrer les fenêtres d'as coté ! Et quand bien même, Gimp c'est pas ça raison d'être mais il à aussi besoin d'aller voir les fenêtres d'à coté du coup (et Gimp il à des plugins utilisateurs qui tournent, tu vois ou je veux en venir ?).
        
        Il y a un truc qui me surprend vraiment, c'est que tu crois être le seul à identifier ce genre de choses. Comme si les développeurs de Wayland (et autres) ne savaient pas qu'on fait aussi des captures d'écran de manière légitime. Comme si c'était des ignorants qui ne savaient pas ce qu'ils faisaient. Heureusement que sur linuxfr on a l'élite de la conception prête à souligner les défauts de l'architecture qui a nécessité des années de travail. Bizarrement pas grand monde pour contribuer directement dans ces projets.
        
        Et ce n'est pas comme si on n'avait pas arrêté de t'expliquer depuis plusieurs jours que le but est que les applications peuvent accéder à des zones en dehors du bac à sable mais que cela demanderait des interactions spécifiques pour que l'utilisateur approuve. Comme sur d'autres OS quoi.
        
        Pour revenir à ton exemple, par défaut dans Wayland en effet seule l'application de capture d'écran de GNOME a le droit (sous une session GNOME) de prendre une capture d'écran complète par défaut. Cela sera élargie via les portails plus tard aux applications qui le souhaitent. De même d'ailleurs pour la fonctionnalité redshift qui est géré par GNOME uniquement.
        
        Mais donc, rien d'impossible techniquement contrairement à ce que tu sous entends.
        
        Et oui, ce n'est pas la fonction principale de GIMP de faire des captures d'écran, il est donc bien que l'utilisateur puisse interdire à GIMP de se servir de cette fonctionnalité pour des raisons de sécurité si cela ne lui sert pas. C'est un progrès contrairement à ce que tu insinues.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par FluffyHamster le 18 juillet 2019 à 21:59. Évalué à 1.
        
        c'est que tu crois être le seul à identifier ce genre de choses
        
        je l'ai lu il y a bien des années sur une maillist wayland ou les mecs s'entredéchiraient sur la question, comme ici
        
        Et oui, ce n'est pas la fonction principale de GIMP de faire des captures d'écran
        
        je pensais au color picker de gimp, il peut lire n'importe quel pixel de l'écran
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par mahikeulbody le 19 juillet 2019 à 10:15. Évalué à 2. Dernière modification le 19 juillet 2019 à 10:16.
        
        je pensais au color picker de gimp, il peut lire n'importe quel pixel de l'écran.
        
        Beaucoup n'ont besoin de cette fonctionnalité qu'à l'intérieur de l'image qu'ils sont en train de traiter. Ceux qui veulent plus donneront le droit ad'hoc à l'application… s'ils lui font confiance.
        
        Si une application Android de type "lampe de poche" me demande un accès au système de fichiers, cela me force à m'interroger : est-ce pertinent ? si ça l'est, est-ce que la source de l'application m'inspire confiance ?
        
        C'est quand même mieux que rien du tout.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Albert_ le 19 juillet 2019 à 15:35. Évalué à 1.
        
        Je prend les paris que ce genre de "features" va pousser pas mal de monde soit a ne pas utiliser wayland (ce qui va devenir de plus en plus difficile), soit a repasser vers des systemes utilisables et fait pour le commun des mortels meme si ils sont closed source… ou ils accepteront les demandes d'autorisation comme on fait pour les licences de logiciels … sans les lires car cela casse les c…
        
        Enfin bon qui vivra verra comme on dit!
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par mahikeulbody le 19 juillet 2019 à 20:09. Évalué à 1.
        
        ou ils accepteront les demandes d'autorisation comme on fait pour les licences de logiciels … sans les lire car cela casse les c…
        
        Pour rester dans l'exemple de Android (bien qu'il ne concerne qu'un petit milliard d'utilisateurs), la demande pour une autorisation donnée s'effectue la première fois que l'appli l'invoque. Cela prend la forme d'une popup du genre "Voulez vous donner accès à la caméra ?" ou "Voulez-vous donner l'accès à la carte SD ?".
        
        Comparer ça à la lecture d'une licence de logiciel relève un peu de la mauvaise foi.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Albert_ le 19 juillet 2019 à 21:22. Évalué à 1.
        
        Perso, je ne fait pas exactement la meme chose sur mon telephone que sur mon ordinateur… comme quand j'utilise un velo ce n'est pas exactement la meme chose que lorsque j'utilise une voiture. N'etant pas cycliste pro je prefere faire mes 600 kms avec ma famille dans une voiture plutot que de les mettre dans une cariole et les tirer avec le velo…
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par mahikeulbody le 19 juillet 2019 à 21:55. Évalué à 1. Dernière modification le 19 juillet 2019 à 21:56.
        
        Mon "bien qu'il ne concerne qu'un petit milliard d'utilisateurs" était franchement inutile et explique certainement le ton de ta réponse ; je m'en excuse.
        
        Ceci dit, l'exemple Android est tout à fait réplicable sur Linux (via Flatpak ou tout autre solution visant le même objectif) et ta comparaison avec la lecture d'une licence logicielle reste très exagérée quelle que soit la plateforme.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Albert_ le 19 juillet 2019 à 23:17. Évalué à 2.
        
        Je prenais cet exemple pour dire que personne ne les lis comme pour les demandes d'autorisation des logiciels sur Android. Demande autour de toi ce que les non geeks font, tu seras surpris.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par mahikeulbody le 20 juillet 2019 à 09:40. Évalué à 2.
        
        C'était le cas avant quand l'installation d'une application donnait toutes les autorisations demandés par défaut. Il y avait bien la liste de ces autorisations dans la description de l'application sur le Play Store mais effectivement la majorité des gens ne la lisait pas.
        
        Maintenant, c'est un peu différent : une popup s'affiche avec un texte court que tu es obligé de lire puisque l'application est bloquée jusqu'à la réponse de l'utilisateur. Il y a une différence entre la suggestion de lire quelque chose (licence, manuel d'utilisation, liste d'autorisations) et l'obligation de répondre à une demande.
        
        Alors, certes, beaucoup de gens continuent à ne pas y réfléchir à deux fois avant d'autoriser mais pourquoi refuser aux autres un moyen qui ne demande pas d'effort supplémentaire pour se protéger ?
        
        Ceci dit, je n'ai aucune idée si Flatpak est le bon moyen d'y arriver dans l'univers Linux, ce n'était pas mon propos.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Albert_ le 20 juillet 2019 à 22:48. Évalué à 1.
        
        Il me faudra pas trop se plaindre quand nous serons oblige de n'utiliser que tel ou tel application en ligne pour pouvoir communiquer.
        Le copié / collé n'etant plus autorisé entre application. Par 'sécurité' on aura des drm pour tout et surtout n'importe quoi et le pire c'est que nous le faisons volontairement.
        Comme je demandais a un américain possédant plein d'arme 'pour se proteger' mais pas de porte digne de ce nom combien de personne il connaît a eu a se défendre avec une arme… réponse zéro mais 'au cas ou'…
        Tout cela n'enlevera jamais le problème numéro 1 de la sécurité: l'interface chaise clavier.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Renault (site web personnel) le 20 juillet 2019 à 23:27. Évalué à 8.
        
        Le copié / collé n'etant plus autorisé entre application. Par 'sécurité' on aura des drm pour tout et surtout n'importe quoi et le pire c'est que nous le faisons volontairement.
        
        Arrête ton char, le but n'est plus d'interdire le copier / coller mais rendre le presse papier sûr. Sous X11, n'importe quelle application peut lire ou écrire dans le presse papier comme bon lui semble sans que l'utilisateur ne s'en rende compte.
        
        Ce n'est pas normal, le presse papier peut contenir des mots des passes ou des données personnelles, une application doit montrer patte blanche pour y accéder.
        
        Cela pourrait simplement nécessiter une action volontaire de l'utilisateur (comme le raccourcis clavier) pour que l'accès soit permis. Au lieu de rien du tout comme aujourd'hui. Pour l'utilisateur cela ne changerait pas grand chose d'un point de vue utilisabilité.
        
        Tout cela n'enlevera jamais le problème numéro 1 de la sécurité: l'interface chaise clavier.
        
        Ton raisonnement depuis le début sur le sujet de la sécurité est contradictoire. Toute sécurité implique plus ou moins une contrainte pour l'utilisateur. Par exemple les mots de passe.
        
        Avec ton raisonnement, on pourrait affirmer que les mots de passe ne servent à rien, ou que les permissions UNIX sont une contrainte inacceptable et inutile aussi. Je suppose que par cohérence personnelle tu n'as qu'un compte superutilisateur sur ta machine et que tu n'as aucun mot de passe nul part.
        
        Pourtant la sécurité de ces dispositifs est tributaire aussi de la bonne volonté de l'utilisateur. Si l'utilisateur utilise son prénom comme mot de passe, et le même mot de passe partout, ou entre le mot de passe administrateur dès qu'on lui demande sans réfléchir, en effet la sécurité est limitée. Et pourtant ces dispositifs de sécurité de base sont partout et rendent bien des services que ce soit au novice ou à l'utilisateur expérimenté.
        
        Les portails de Flatpak, c'est pareil. Le but est d'ajouter une contrainte supplémentaire mais assez acceptable lors de l'utilisation d'une application. Au lieu d'avoir accès à tout (ou presque) par défaut, maintenant l'utilisateur aura le contrôle sur ce que l'application pourra réellement faire. Et ça a plusieurs intérêts même pour un utilisateur incompétent.
        
        Déjà l'utilisateur aura conscience de ce que fait l'application. Si l'application veut faire une opération sensible il le saura. Il pourra évaluer éventuellement si c'est légitime ou pas. Avoir cette information c'est quand même mieux que de devoir lire le code source (quand il est accessible) pour s'assurer qu'il ne fait aucune opération qu'il ne devrait pas faire.
        
        Ensuite, même si l'application est de confiance, un bogue ou une faille ça existe. Et dans ce cas là, les dégâts possibles seront bien plus limités car l'application n'aura pas un accès total au système comme aujourd'hui. C'est d'ailleurs pour une raison similaire qu'il y a des permissions UNIX ou SELinux pour qu'un processus ne puisse pas faire tout et n'importe quoi même si c'est plus rudimentaire que ce que Flatpak proposera.
        
        Donc oui, c'est un progrès. Cela n'empêchera pas l'utilisateur novice de mal s'en servir, tout comme certains aujourd'hui sont en root en permanence (sisi j'en connais), mais cela a un bénéfice pour pas mal de monde dont l'utilisateur expérimenté car il aura bien plus de contrôle et d'informations sur ce qui se passe. Et le tout pour un désagrément très mineur, de temps en temps il faut accepter une autorisation à al volée, on ne peut pas dire que sous iOS ou Android ce principe empêche de vendre des milliards de périphériques dans le monde entier. macOS et Windows s'y mettent aussi par ailleurs.
        
        Le compromis trouvé est correct. Et étant donnée la quantité de failles que l'on a découvert ces dernières années, et l'importance des données personnelles ou de la capacité de nuisance des personnes malveillantes, il est indispensable d'améliorer la sécurité globale de nos systèmes qui était adapté pour les besoins d'une époque assez reculée aujourd'hui.
        
        [^] # Re: Flatpak vers le cloisonnement du bureau
        
        Posté par Okki (site web personnel, Mastodon) le 20 juillet 2019 à 00:12. Évalué à 1.
        
        soit a repasser vers des systemes utilisables et fait pour le commun des mortels meme si ils sont closed source…
        
        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 flan (site web personnel) le 20 juillet 2019 à 11:36. Évalué à 3.
        
        C'est même plutôt un prédécesseur sur le sujets : les applications ne peuvent pas accéder à toutes les API (y compris le système de fichiers) par défaut. Avec la version actuelle (Mojave), il est nécessaire d'explicitement autoriser un terminal à accéder à l'ensemble du système de fichiers (sachant que les restrictions UNIX classiques s'appliquent toujours, bien sûr).
        
        L'accès à la géolocalisation ou au carnet d'adresse est limité depuis plusieurs années, également.

Suivre le flux des commentaires

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