Renault a écrit 7161 commentaires

Ce n'est pas tout à fait vrai. J'ai en tête l'exemple du tramway qui s'est (ré)installé dans certaines villes en quelques années et qui a changé l'organisation des transports urbains. De façon encore plus rapide, la mise en place de lignes de bus (ou leur fréquence) peut également modifier l'organisation urbaine. Un autre exemple est la création de pistes cyclables.

Un tramway c'est minimum 10 ans entre le début du projet pour en définir le budget, les caractéristique et le tracé, pour ensuite avoir les appels d'offres et les travaux effectivement faits. Et globalement ça c'est quand tout se passe bien, car dans de nombreuses villes les difficultés font que ça prend plus de temps.

Et puis ensuite le tram va par sa présence modifier la ville, que ce soit dans l'affectation des logements ou les commerces et autres entreprises. Mais bien évidemment cela met quelques années encore pour que l'effet se fasse de manière globale.

On peut le voir par ailleurs dans le chantier du grand Paris qui va enfin permettre de résoudre certains gros problèmes du transport en commun parisien. On ne peut pas dire que quelques années seulement sont nécessaires.

Ce n'est donc pas ce que j'appelle une solution de court terme. D'autant que l'urbanisme ne se limite pas à la présence des transports en commun dans les quartiers du centre. Il y a le fait que de nombreuses villes (voire toutes) ont favorisé le développement de quartier résidentiel en bordure de la ville, avec des centres commerciaux ou industriels également assez éloignés et difficilement accessibles en transport en commun. Il faut là aussi pas mal de temps pour remettre en cause ce modèle urbanistique pour les rapatrier vers le centre ou développer des transports en communs efficaces.

De même pour développer des lignes ferroviaires efficaces entre deux villes où ça fait sens, dans de nombreux cas (comme en PACA) il y a de gros défis à résoudre de ce côté là.

Mais je ne nie pas l'importance du sujet, mais ce n'est pas la seule solution et celle-ci demande beaucoup de temps.

Je suis tout à fait d'accord avec ça, cependant, les transports en commun sont souvent (toujours ?) plus économe en énergie et en pollution dans un contexte urbain.

Bien sûr, je ne dis pas le contraire. Je suis pour le développement massif de transports en commun pour les aires urbaines et défavoriser au maximum l'usage de la voiture. Mais ça va demander du temps, entre la mise en place mais aussi parce qu'il y a une révolution à faire dans la mentalité des gens. Il n'est pas simple de convertir des gens qui font 400m en voiture à utiliser leurs jambes. J'en connais dans ce cas et ils sont nombreux.

Et en quoi ? C'est quoi ce jugement de valeur pourri ?

Déjà il y a Youtuber et Youtuber. Ceux qui font de la vulgarisation culturelle ou scientifique, ou qui font des reportages par exemple n'ont clairement rien à envier à un autre métier qu'on pourrait considérer comme intellectuel et plus socialement acceptable. Sur Youtube il n'y a pas que des vidéos pourries.

Ensuite il est bien plus réaliste et envisageable de devenir Youtuber que astronaute qui est un beau rêve mais assez inaccessible. Rêver pour rêver d'un futur compromis, ce n'est pas non plus très intéressant et peut être frustrant.

Je pense qu'on devrait un peu moins se préoccuper de la valeur sociale qu'on accorde à un métier pour se préoccuper plutôt du bonheur du travailleur. C'est avec ce genre de mentalités qu'on a fait des filières professionnelles et technologiques au collège / lycée comme des voies de garages où on ne fait que d'envoyer les mauvais élèves au détriment de ce qu'ils veulent vraiment faire. C'est comme ça que des parents ou profs rechignent à ce que l'enfant fasse un métier manuel plutôt qu'un métier intellectuel, même s'il serait plus épanoui dans une telle filière. Etc.

Si les gens sont plus heureux en devenant Youtuber qu'en étant astronaute ou comptable ou cheurcheur, je ne vois pas pourquoi on devrait les juger si péjorativement quant à ce choix.

C'est vrai que Zenitram insiste un peu sur ce point mais c'est difficile de lui donner tort quand même. Si la jurisprudence sur les licences libres, et en particulier autour de la GPL, sont manquants en Europe et en France, c'est en partie parce que la FSF n'a pas voulu se mouiller dans les rares cas qui se sont présentés.

Donc que la partie prenante dans l'affaire ici accuse le système judiciaire d'être inefficace ou frileux à traiter ces affaires alors que c'est juste que les parties prenantes jusqu'ici n'ont jamais voulu aller au bout de la bataille judiciaire, c'est fort le café. La justice en France a des problèmes à résoudre, mais on ne peut pas les accuser de tout et n'importe quoi.

Sans compter qu'ici la partie prenante souhaite que la justice se prononce en dehors de juger le simple droit. Il n'est pas de la responsabilité de la justice de se prononcer ou de garantir un fonctionnement d'un modèle économique ou de la communauté du LL, son objectif est de juger la conformité des actions de chacun selon le droit en vigueur et éventuellement de l'interprété ou de gérer les éventuels conflits législatifs.

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.

La solution pour le transport de demain, ne serait elle pas plutôt dans l’aménagement du territoire ?

Il est certain que l'urbanisme a un rôle à jouer, mais tu ne changes pas l'organisation d'une ville rapidement, il faut plusieurs génération pour qu'une nouvelle organisation porte ses fruits.

Or il faut prendre des mesures qui ont des effets dès maintenant, le temps que l'urbanisme apporte une réponse plus complète sur le temps long.

Ce n’est peut être pas en économisant au mieux cinquante pour cent sur du transport inutile que l’on réglera les problèmes.

Je pense qu'il est assez idiot de croire qu'il y a une solution unique qui résoudra tous nos problèmes, ou qu'on doit se contenter d'une unique solution. Je pense au contraire qu'il faut mixer les différentes solutions et ensemble l'impact sera bien plus significatif voire suffisant.

D'autant que certaines solutions peuvent être déployées massivement à court terme, d'autres pas. Il faut bien cadencer la mise en œuvre pour obtenir le rendement optimal.

pour être plus dans la réalité, je consomme plus MAIS j'arrive à aller plus loin en distance si je reste à > 20kw

Non, tu ne consommes pas plus, sinon ça n'aurait pas de sens. ;)

En fait à cause du rendement plus faible à 5 kW, tu as besoin de plus d'énergie venant de la batterie pour délivrer cette puissance par rapport à quand tu es à 20 kW.

Après cela reste étonnant qu'avec un facteur 4 de puissance plus faible tu consommes plus d'énergie quand même. Tu es sûr de comparer dans les mêmes conditions en dehors du changement de puissance ? Car il est évident que comparer la ville avec de nombreux arrêts n'a pas la même consommation qu'une conduite régulière sur nationale.

par contre cela fait 5 ans que je ne consomme plus d'essence, soit environ 100L/mois -> 6M³ d'essence non brulé, ca commence à faire … surtout niveau C02 et budget , environ 9600€ d’économisé, ça me paye la voiture.

Après la question est : est-ce que ton expérience individuelle est généralisable. Si oui, à quelles conditions ? Car c'est bien que cela fonctionne à ton échelle, mais le vrai enjeu est de passer à une solution de masse.

La voiture électrique est probablement une réponse possible de la mobilité de demain. Mais probablement pas la réponse universelle. Car il y a la question des métaux nécessaires, la question de l'approvisionnement électrique et de l'origine de cette énergie et donc des pollutions engendrées par cette production.

Or l'énergie nécessaire pour avoir le parc actuel en électrique est énorme et difficilement compatible avec les défis à relever. La solution est probablement un mix de solution comme :

• Une partie des véhicules en hybrides, une autre en électrique, une autre avec peut être une source énergétique différente encore ;
• Plus de partage de voitures communes, moins d'achats individuels ;
• Plus de transports en communs, moins de kilomètres en voiture.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Basculant entre plusieurs machines physiques, dont serveurs à multiple eths, tout le temps et tous les jours, ça ne m'a toujours pas sauté aux yeux si ce n'est le côté ennuyant et imprévisible.

Bah oui, c'est ça l'intérêt de ce renommage, il y a un lien physique entre l'interface et le matériel. Alors que sinon, au redémarrage, cela peut changer d'affectation. Ce qui est bien pénible.

La plupart des distributions y sont passés il y a longtemps sans soucis. Fedora l'a fait même pour Fedora 15, en 2011.

Oui, enfin tu oublies une part essentielle de son propos :

or you yourself must carry the burden of supporting that libc.

En gros, rien n'empêche à ce que ce composant soit compatible avec musl mais il ne va pas se charger lui même pour ton plaisir de s'en occuper.

Le libre et le développement communautaire ne signifient pas que les développeurs doivent répondre au moindre desiderata de ses utilisateurs. Si tu veux une fonctionnalité ou un support, tu as le code, envoie un correctif et maintiens le.

C'est trop facile d'exiger aux autres de faire l'effort.