Renault a écrit 7255 commentaires

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.

Snap et Flatpak ne visent pas les mêmes buts. Le but de Snap c'est de facilement installer n'importe quel composant logiciel sur un système sans se préoccuper des dépendances et autres.

Flatpak partage en partie ce but, mais son objectif c'est aussi de fournir une couche commune pour mutualiser un maximum de choses entre les Flatpak, de fournir de limiter les droits d'accès des applications par défaut en utilisant un système de permission ou de requêtes de permissions pour faire plus (comme sur les téléphone mobile) et autres. Pour plus de sécurité et d'isolation des dites applications.

Bref, la conception n'est pas la même, ils ne visent pas vraiment le même besoin. Ce n'est donc pas choquant qu'il y ait cohabitation des deux.

Systemd après Upstart, Flatpak après Snap. Il y a d'autres choses mais je n'ai plus toute la liste en tête.

Red Hat a collaboré sur upstart et l'a même adopté. L'abandon d'upstart s'est fait quand ils (Red Hat et Canonical) ont identifié les limites d'upstart qui nécessitait une profonde reconception de la chose. Quand systemd était prêt, on notera que Canonical et Ubuntu n'ont pas fait un scandale et l'ont adopté assez sobrement. Ce n'est pas aussi manichéen qu'on pourrait le croire.

Note : je ne défends en aucun cas Canonical, pour moi ça reste une entreprise qui « détruit » tout autant la simplicite et beauté de Linux que Red Hat.

Pourtant ces entreprises ont fait énormément pour l'écosystème, le libre n'a jamais signifié être gratuit et on devrait se féliciter que le libre permette à des gens d'être payé pour le faire avancer. Et ils font un gros travail.

Marseille - Nice c'est au minimum 2h30 de trajet en TER. C'est donc plus que Paris - Nice en avion et de loin. Et c'est sans compter les retards fréquents sur cette ligne.

Paris - Nice en TGV c'est 5h45 au plus rapide. Si tu dois changer à Marseille tu perds du temps dans le transfert, et comme c'est un TER qui peut être chargé en heure de pointe en particulier, niveau confort ce n'est pas forcément la joie.

Ce n'est pas un hasard si la liaison aérienne Paris - Nice est très utilisée, le gain de temps est notable, le confort est moins bon mais comme la peine dure moins longtemps ça vaut le coup.

Un TER bondé, ce n'est clairement pas confortable. Et le temps de trajet n'est pas le même non plus.

De plus, ça n'évite pas d'acheter des trains, parce que pendant que ton TGV sert de TER (et remplace un TER donc), ce TGV n'est pas disponible pour faire du TGV.

Après, peut être que si le TGV ne faisait pas ce tronçon, il serait au hangar et donc inutilisé ? Cela réduirait les frais de maintenances liés à l'usure, mais rentabiliserait moins le coût fixe du TGV en lui même, et pourrait nécessiter l'achat d'autres TER pour compenser qui seraient également sous exploités. Ce n'est donc pas forcément optimal de réserver le TGV exclusivement aux liaisons LGV.

Il faudrait évaluer si effectivement ce temps là économisé aux TGV permettrait de l'utiliser sur une liaison LGV.

C'est d'ailleurs ce que dit l'article du blog en question. Commercialement parlant il peut être plus avantageux d'utiliser le TGV sur les lignes avec des sections sans grande vitesse.

C'est d'ailleurs aussi le cas de la liaison Marseille - Nice qui est également couvert par un TGV au départ / destination de Paris via Lyon. Cette section n'étant pas pourvue encore d'une LGV.

Je présume que ces liaisons étant très fréquentées (l'axe Paris / Marseille est l'une des lignes TGV les plus remplies), laisser le train aller à Nice pour éviter aux voyageurs de se taper une correspondance avec un TER pour plusieurs heures leur permet de gagner des PdM face à l'avion. Surtout que cela passe par des grandes villes. L'avion étant en effet fréquent pour Paris - Nice ou Paris - Bretagne, cela peut doper les ventes avec une telle pratique.

Ne pas oublier qu'un TER niveau confort ce n'est clairement pas un TGV, donc quand tu te fais une journée de trains pour traverser la France, le passer en grande partie dans un TER peut être gênant pour les passagers et les inciter à privilégier autre chose. Et la correspondance implique une perte de temps non négligeable avec le risque en cas de retard de la louper et d'être en difficulté.

Je présume que la SNCF a évalué la question pour éviter de dépenser trop par rapport à l'option TGV sur LGV uniquement et TER pour compléter le trajet de ces grands axes.

Mieux, tu saisies une adresse de départ et d'arrivée et il se charge de trouver le trajet le plus adéquat, éventuellement en combinant train / bus / vélo / marche.

Le voyageur en général ne se préoccupe pas de partir et d'arriver à une gare précise, son but est de relier deux adresses précises de la manière la plus efficiente (en temps ou en nombre de correspondances). Les sites du genre devraient se focaliser de simplifier ce genre de démarches.