Pourquoi les applications Flatpak, c’est l’avenir

Régulièrement, j’entends des utilisateurs se plaindre de ce format de paquet, qui occuperait un peu plus d’espace disque ou qui aurait encore quelques bugs de jeunesse, comme le thème de l’application qui pourrait différer de celui de l’utilisateur ou, plus ennuyeux, l’impossibilité de pouvoir jouir de certaines fonctionnalités, qui seraient pourtant disponibles dans la version standard, non exécutée dans un « bac à sable ».

Mais il faut voir sur le long terme. La version 1.0 est enfin sortie au mois d’août 2018, après plusieurs années de développement, ce qui permet de franchir un premier cap. Maintenant, il faut savoir que si elles n’ont pas été directement pensées pour ce mode de fonctionnement, certaines applications ont besoin d’être adaptées pour pouvoir fonctionner parfaitement. Mais ce n’est qu’une question de temps et ça ne doit pas éclipser pour autant les nombreux avantages déjà permis.

Tout d’abord, nous pouvons citer la sécurité. Les applications Flatpak sont exécutées dans un environnement « bac à sable » (sandbox) sûr, isolé du reste du système. Mieux encore, comme pour les applications mobiles, les développeurs doivent déclarer dans un manifeste de quelles autorisations ils souhaitent pouvoir bénéficier : accès au dossier personnel de l’utilisateur, à certains périphériques (webcam, micro…), à la géolocalisation… Droits que l’utilisateur est libre d’accorder ou révoquer à tout moment. Alors oui, pour un logiciel libre dans lequel l’utilisateur a toute confiance, ça n’a pas forcément grand intérêt, mais dans le cas de logiciels propriétaires, véritables boîtes noires dont on ne sait rien, ça peut tout de suite être plus intéressant.

Autre avantage important, la possibilité offerte aux développeurs de pouvoir atteindre directement l’ensemble de leurs utilisateurs sans attendre le bon vouloir des différentes distributions. Une nouvelle version vient de sortir, un Flatpak est proposé et tout le monde peut en bénéficier, sans avoir à se soucier du système de paquet utilisé par la distribution (DEB, RPM…) ou de la compatibilité des bibliothèques.

Non seulement les développeurs pourront proposer un paquet universel dès la publication de leur application, mais ce dernier pourra représenter la version idéale telle qu’ils l’ont souhaité.

Parce qu’il faut savoir que les paquets des différentes distributions sont souvent bien loin de correspondre à cet idéal. Par exemple, pour des raisons philosophiques ou juridiques, les distributions peuvent très bien désactiver certaines fonctionnalités au moment de la compilation. Des distributions comme Debian ou Fedora, qui font très attention aux quatre libertés du logiciel libre ainsi qu’aux brevets logiciels, préfèrent ainsi se passer de certaines fonctionnalités (par exemple, un algorithme qui serait protégé par un ou plusieurs brevets), plutôt que de se priver de l’application dans son ensemble. Sans parler des nombreux patchs que les distributions peuvent appliquer, dans le but de modifier volontairement le comportement de l’application. Que ces changements soient ou non positifs, l’utilisateur peut très bien préférer la vision des développeurs officiels.

Puis comme les paquets sont identiques pour tous et que les applications sont exécutées dans le même environnement, là encore identique, si l’application fonctionne bien chez le développeur, elle fonctionnera tout aussi bien chez les utilisateurs. Et si l’utilisateur rencontre un bug, ce dernier devrait être plus facilement reproductible par le développeur. Il sera donc bien plus simple d’offrir des garanties et de corriger certains problèmes.

C’est également un gain de temps pour les développeurs, qui n’auront plus à se soucier que d’un unique Flatpak, plutôt que de créer de nombreux paquets pour différentes distributions (quand ils ne se contentent pas, bien souvent, de ne viser qu’une ou deux distributions majeures, laissant les autres sur le carreau).

Alors bien sûr, on se dit que les différentes distributions ont leurs propres contributeurs pour empaqueter toutes ces applications (petite parenthèse pour rappeler que les distributions ne se préoccupent, en général, que de logiciel libre, et que l’éditeur d’une application propriétaire ne bénéficiera pas de toute cette main d’œuvre). Mais quand on y pense, que de temps humain gaspillé à recréer tous ces paquets, chacun dans leur coin, pour les mêmes applications… Sans parler des plus petites distributions, qui n’ont pas forcément les moyens humains de gérer tout ça. Ne serait-il pas plus intéressant de pouvoir créer un paquet universel une fois pour toute, et de pouvoir ensuite se concentrer sur des tâches plus gratifiantes ou plus utiles ?

Autre avantage auquel on ne pense pas forcément, la possibilité d’installer sans risque plusieurs versions en parallèle. Que ce soit une version stable et une version de développement à des fins de test, ou une ancienne version stable qui pourrait proposer des fonctionnalités dont on a besoin mais qui auraient malheureusement été supprimées des versions plus récentes (l’évolution des logiciels que l’on utilise ne nous convient pas toujours).

La compatibilité dans le temps devrait également être renforcée. Aujourd’hui, de souhaiter utiliser de vieilles applications abandonnées par leurs développeurs (et donc non adaptées à des systèmes modernes) peut rapidement devenir compliqué, pour ne pas dire impossible pour la plupart des gens, puisque toutes les distributions n’acceptent pas forcément le risque et la charge de travail supplémentaire que représentent de vieilles applications abandonnées ou des bibliothèques obsolètes. Et si ce n’est pas géré par la distribution ou la communauté, ça implique bien souvent de devoir mettre les mains dans le cambouis et de compiler soi-même. Tandis qu’avec un Flatpak et son runtime d’époque associé (qui contient les différentes bibliothèques nécessaires à son bon fonctionnement), la distribution n’a plus besoin de s’en préoccuper.

Donc même si ça ne vous intéresse pas et que vous ne prévoyez pas de changer vos habitudes, on ne peut honnêtement pas dire que cette technologie n’a aucun intérêt (ne serait-ce que pour tout le temps que ça fait gagner aux développeurs de logiciels libres, qui travaillent bien souvent bénévolement). Tout comme il faut arrêter de penser que les distributions de type rolling release telles que Arch Linux ou Manjaro soient le Saint Graal. La première exclut tous les néophytes et la seconde, qui désactive (à raison) le dépôt communautaire AUR par défaut, n’offre donc pas forcément le même catalogue applicatif ou les mêmes versions. Et bien évidemment, en dehors de leur capacité à proposer des versions plutôt à jour, ces distributions ne règlent aucun des différents problèmes soulevés (sécurité, reproductibilité, compatibilité, gain de temps…).

Il est donc préférable de se mettre un instant à la place de l’utilisateur néophyte qui peut enfin bénéficier, à tout instant et de façon sécurisée, des dernières versions de ses applications préférées sans avoir à se soucier de toutes les questions techniques sous-jacentes, qui ne l’intéressent pas et ne l’intéresseront jamais : le choix de la distribution et du format de paquet qui en découlera, les éventuels dépôts tiers à activer (parfois gérés de façon plutôt hasardeuse, pour ne pas dire risquée), les dépendances nécessaires, l’installation d’éventuels outils de développement pour compiler soi-même et bien faire attention à chaque installation ou mise à jour à ne surtout rien casser…

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’est le cas, Flatpak pourrait grandement nous y aider.

47 réflexions au sujet de « Pourquoi les applications Flatpak, c’est l’avenir »

  1. En gros on réinvente l’exe a la windows ou chacun ajoute ses propres lib de manière très sale. Du coup répétition sur le disque avec l’arrivé des ssd minuscule sur laptop c’est la fête.

    1. Ce sont les Snaps d’Ubuntu qui semblent dupliquer les bibliothèques dans chaque paquet. Avec les Flatpaks, il y a la notion de runtimes. T’as par exemple un runtime Freedesktop, un runtime GNOME, un autre KDE… sur lesquels les paquets Flatpaks vont ensuite s’appuyer. Il faudrait vraiment que la bibliothèque soit exotique pour qu’il y ait besoin de la fournir dans le Flatpak lui-même.

      1. Et quand bien même la bibliothèque est dupliquée entre plusieurs applis, OSTree (le système de transport/stockage sous-jacent à Flatpak) va la dédupliquer sur le disque.

        Par exemple, les runtimes viennent par paire : une Platform pour lancer les applications et un Sdk pour les compiler.

        Dans le cas du runtime Freedesktop, on a donc :

        du -sh /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/18.08/active/files/
        530M /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/18.08/active/files/
        $ du -sh /var/lib/flatpak/runtime/org.freedesktop.Sdk/x86_64/18.08/active/files/
        1.6G /var/lib/flatpak/runtime/org.freedesktop.Sdk/x86_64/18.08/active/files/

        Ça a l’air énorme !

        Mais en fait :

        $ du -sh /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/18.08/active/files/ /var/lib/flatpak/runtime/org.freedesktop.Sdk/x86_64/18.08/active/files/
        530M /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/18.08/active/files/
        1.1G /var/lib/flatpak/runtime/org.freedesktop.Sdk/x86_64/18.08/active/files/

        Comme le Sdk contient la Platform, les fichiers communs sont dédupliqués sur le disque.

  2. Réponse rapide à certains paragraphes :

    « Autre avantage important, la possibilité offerte aux développeurs de pouvoir atteindre directement l’ensemble de leurs utilisateurs sans attendre le bon vouloir des différentes distributions. Une nouvelle version vient de sortir, un Flatpak est proposé et tout le monde peut en bénéficier, sans avoir à se soucier du système de paquet utilisé par la distribution (DEB, RPM…) ou de la compatibilité des bibliothèques. »

    Simplement la mise à mort à terme d’un rôle primordial : l’empaqueteur de logiciels.

    « Non seulement les développeurs pourront proposer un paquet universel dès la publication de leur application, mais ce dernier pourra représenter la version idéale telle qu’ils l’ont souhaité. »

    Tiens, le modèle MSI / DMG… Ou comment réinventer la roue après Microsoft et Apple en rajoutant le sacro-saint bac à sable pour la sécurité ultime…

    « Sans parler des plus petites distributions, qui n’ont pas forcément les moyens humains de gérer tout ça. Ne serait-il pas plus intéressant de pouvoir créer un paquet universel une fois pour toute, et de pouvoir ensuite se concentrer sur des tâches plus gratifiantes ou plus utiles ? »

    Purification du nombre de distributions par le paquet universel ?

    « Tandis qu’avec un Flatpak et son runtime d’époque associé (qui contient les différentes bibliothèques nécessaires à son bon fonctionnement), la distribution n’a plus besoin de s’en préoccuper. »

    Sans oublier une taille démente pour certains logiciels qui doubleront, tripleront ou pire la taille classique. Après tout, l’espace disque, on s’en fout :)

    Sur le bénévolat des développeurs, il faudra dire cela à ceux qui sont employés par RedHat, IBM, Canonical et combien d’autres grosses boites…

    « Tout comme il faut arrêter de penser que les distributions de type rolling release telles que Arch Linux ou Manjaro soient le Saint Graal. La première exclut tous les néophytes et la seconde, qui désactive (à raison) le dépôt communautaire AUR par défaut, n’offre donc pas forcément le même catalogue applicatif ou les mêmes versions.  »

    L’habituelle rodomontade sur les rollings… Bref… AUR est un livre de recette à l’image des ports des BSD libres. Quand aux versions, elles sont fraiches, merci :)

    « 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’est le cas, Flatpak pourrait grandement nous y aide »

    Ainsi que l’insertion de saloperies du genre mineur de cryptomonnaies comme cela a déjà été le cas.

    Nous resterons en désaccord sur la bêtise monstreuse que sont les paquets universels. On verra dans deux ans ce qu’il en sera.

    1. « Simplement la mise à mort à terme d’un rôle primordial : l’empaqueteur de logiciels. »

      Tout comme dans la vraie vie on supprime certains métiers devenus inutiles, quand, dans le même temps, de nouveaux sont créés…

      « Tiens, le modèle MSI / DMG… Ou comment réinventer la roue après Microsoft et Apple en rajoutant le sacro-saint bac à sable pour la sécurité ultime… »

      On peut également se dire que si tout le monde y est passé (aussi bien les systèmes pour PC, que pour tablettes ou mobiles), c’est peut être que ça apporte réellement quelque chose de bénéfique ? Il ne faut pas bêtement diaboliser les concurrents sous prétexte que ce sont des entreprises, des GAFAMs ou ce que vous voulez. Ils ont également de très bons ingénieurs et autres experts en sécurité, et ne font pas que de la merde…

      « Purification du nombre de distributions par le paquet universel ? »

      Tu peux développer ? Je vois au contraire que plusieurs petites distributions ont été parmi les premières à adopter Flatpak (Deepin, Endless OS…), voir même à activer le dépôt Flathub par défaut (comme Linux Mint). À mon avis, c’est justement parce que ça leur permet de pouvoir proposer plus facilement de nombreuses applications à jour. Et si elles n’ont plus besoin d’y consacrer autant de temps, elles peuvent se concentrer sur ce qui fait justement leur différence : un environnement de bureau qui leur est peut être propre, peaufiner l’expérience utilisateur, contribuer à des projets en amont… Il y a tellement de choses plus intéressantes à faire.

      Si la seule différence entre deux distributions se limite au système de paquets utilisé, alors j’y vois zéro plus-value.

      « Sans oublier une taille démente pour certains logiciels qui doubleront, tripleront ou pire la taille classique. Après tout, l’espace disque, on s’en fout :) »

      Tu confonds avec les Snaps. C’est le runtime qui prend un peu de place. Ensuite les Flatpak ne prennent pas plus de place que les paquets traditionnels. Alors oui, d’installer plusieurs runtimes (surtout si l’on a besoin de versions différentes), ça occupera quelques gigas de plus. Maintenant, un système Linux traditionnel, ça fait quoi, 10 Go à tout péter ? Même si on doublait, ça reste encore ridicule. Surtout quand, pour moins de 50 euros, on a des SSD de 240 Go.

      De mon côté, je remarque surtout que les gens se foutent royalement de l’utilisation des ressources (RAM, disque…). Ils veulent juste que ce soit simple et que tout fonctionne bien sans avoir à s’emmerder. Alors donnes le choix à une personne qui voudrait tenter Linux avec, d’un côté une Debian stable mais avec des paquets potentiellement obsolètes (et encore, tant que ça répond à ses besoins, en général elle s’en fout), une Arch / Manjaro pour laquelle elle n’aura clairement pas le niveau. Puis t’oublies AUR, de devoir compiler et toujours faire attention à ne rier casser, ça ne sera pas pour elle. Ou une solution qui occupera peut être un peu plus de place, mais où elle aura juste à cliquer sur une jolie icône pour obtenir ce qu’elle a demandé, et tu verras ce qu’elle préfère :p

      Sincèrement, tu te prends trop la tête (et pas uniquement sur les Flatpaks, mais de façon générale), sur une légère augmentation de l’utilisation des ressources (parce que oui, même MATE consomme plus que MS-Dos ou Windows 3.11, qui est la contrepartie nécessaire pour pouvoir obtenir un environnement de bureau plus joli et plus fonctionnel, tout en étant plus simple). Alors que tout ce que recherchent les gens (PC, mobile, voiture, électroménager…), ce sont des produits toujours plus simples et qui leur font gagner du temps.

      « Sur le bénévolat des développeurs, il faudra dire cela à ceux qui sont employés par RedHat, IBM, Canonical et combien d’autres grosses boites… »

      Red Hat se base beaucoup sur les paquets créés par les bénévoles de Fedora, comme Canonical se base beaucoup sur ceux créés par les bénévoles de Debian… Ce qui leur permet ensuite de créer de la plus-value propre à leurs distributions d’entreprises. Et je maintiens que de ne pas avoir à créer un paquet pour cinquante distributions, permet de libérer du temps pour d’autres tâches. Par exemple, contribuer aux applications elles-mêmes, plutôt qu’uniquement à leur empaquetage. Et parmi ces bénévoles, qui font sans doute tout ça uniquement pour que l’application soit disponible dans leur distribution, certains parlent sans doute plusieurs langues. Ils pourraient donc très bien traduire la description des paquets à la place, pour que ces derniers puissent apparaître dans la langue de l’utilisateur dans la logithèque (pour le moment, il reste tout de même énormément d’anglais). Certaines icônes en basse résolution auraient également besoin d’être refaites (elles font tâche au milieu du reste). De nombreuses applications ne disposent pas de documentation utilisateur… Je me répète, mais il y a tellement de choses plus intéressantes à faire que d’empaqueter une même application pour un grand nombre de distributions. Et pire encore, de devoir tout refaire à chaque nouvelle version (y compris quand il s’agit d’une révision mineure).

      « Ainsi que l’insertion de saloperies du genre mineur de cryptomonnaies comme cela a déjà été le cas. »

      Je vais répéter ce que je répondais sur Mastodon, mais ce n’est pas propre à la technologie mais à la modération. Que tu laisses n’importe qui soumettre un paquet traditionnel ou un Flatpak sur le dépôt, il y aura absolument les mêmes chances d’obtenir de la merde des deux côtés. C’est déjà arrivé sur le dépôt communautaire AUR, comme ça arrivera fatalement à d’autres.

      « Nous resterons en désaccord sur la bêtise monstrueuse que sont les paquets universels. »

      C’est obligatoire sur d’autres plateformes, qui ne s’en portent pas plus mal. D’autant plus que l’image idyllique d’un Linux où tout est parfait tandis que les autres vivraient l’enfer au quotidien est complètement fausse. Déjà, Linux est bien moins sécurisé que Windows ou macOS. Rien que de continuer d’utiliser X.org, ça permet à n’importe quelle application d’enregistrer les frappes clavier dans n’importe quelle autre application, ou de faire des captures d’écran en douce. Wayland résout ces différents problèmes, comme Flatpak renforce encore un peu plus la sécurité, qui était jusque-ici complètement catastrophique.

      Puis c’est sans doute très bien quand tu es naturellement parano et que tu n’utilises que des logiciels libres sous Debian, mais dans le monde réel, les gens ont envie de pouvoir utiliser Skype, Spotify, et sûrement tout un tas d’autres merdes propriétaires dans lesquelles je n’aurai pas particulièrement confiance.

    2. J’ai même envie d’ajouter qu’il y aura fatalement toujours besoin d’empaqueteurs. Déjà, parce que ce n’est pas demain la veille que Debian ou Arch abandonneront leurs paquets traditionnels. Et même si ça devait arriver un jour, il y aura toujours des développeurs d’applications qui auront juste envie de balancer leur code sur GitHub sans avoir à se prendre la tête avec un site web ou des paquets : « j’ai fait ma part, maintenant, démerdez-vous ». C’est juste qu’au lieu d’empaqueter du DEB ou du RPM, il faudra des bénévoles pour créer des Flatpaks. Et à mon avis, ça sera infiniment plus gratifiant pour eux de créer un paquet qui tourne partout plutôt qu’uniquement pour Mageia (ah ah ah).

  3. > Simplement la mise à mort à terme d’un rôle primordial : l’empaqueteur de logiciels.

    C’est un rôle d’intermédiaire. Et supprimer des intermédiaires, c’est plutôt une bonne chose.

    Pour avoir été à la fois développeur upstream et packageur (>10 ans de packaging Fedora), je suis convaincu qu’il faut effectivement supprimer les packageurs.

    C’est un boulot ingrat, inutile et même néfaste.

    Évidemment, tant qu’on a des distros structurées telles qu’elles le sont on n’a pas vraiment le choix, et c’est pour ça que typiquement je continue de packager quand il le faut.

    Mais si on veut sérieusement offrir un logiciel libre de qualité au plus grand nombre, alors il faut qu’on revoit totalement la façon dont on distribue ce logiciel, tant au niveau de l’OS (la distro) que des applications (Flatpak).

  4. « On peut également se dire que si tout le monde y est passé (aussi bien les systèmes pour PC, que pour tablettes ou mobiles), c’est peut être que ça apporte réellement quelque chose de bénéfique ? Il ne faut pas bêtement diaboliser les concurrents sous prétexte que ce sont des entreprises, des GAFAMs ou ce que vous voulez. Ils ont également de très bons ingénieurs et autres experts en sécurité, et ne font pas que de la merde… »

    Et surtout ils ont compris que le contrôle de la bibliothèque logicielle est indispensable pour maitriser l’utilisateur final.

    De plus l’argument du « tout le monde le fait » est un peu court. On peut via un raisonnement par l’absurde utiliser une comparaison avec le saut à l’élastique…

    « Tu confonds avec les Snaps. C’est le runtime qui prend un peu de place. Ensuite les Flatpak ne prennent pas plus de place que les paquets traditionnels. Alors oui, d’installer plusieurs runtimes (surtout si l’on a besoin de versions différentes), ça occupera quelques gigas de plus. Maintenant, un système Linux traditionnel, ça fait quoi, 10 Go à tout péter ? Même si on doublait, ça reste encore ridicule. Surtout quand, pour moins de 50 euros, on a des SSD de 240 Go. »

    Et encore un détournement du problème. Tu viens juste de dire qu’on réinvente le système des bibliothèques partagées avec les flatpak et leurs runtimes.

    Il est vrai que TOUT le monde n’est pas dérangé à mettre 50€ dans du matos pour le plaisir des développeurs qui réinventent la roue.

    « Et je maintiens que de ne pas avoir à créer un paquet pour cinquante distributions, permet de libérer du temps pour d’autres tâches. Par exemple, contribuer aux applications elles-mêmes, plutôt qu’uniquement à leur empaquetage.  »

    Il est vrai que le code source récupéré par les empaqueteurs, c’est moins universel :)

    « Ils pourraient donc très bien traduire la description des paquets à la place, pour que ces derniers puissent apparaître dans la langue de l’utilisateur dans la logithèque (pour le moment, il reste tout de même énormément d’anglais). »

    Tout comme un horticulteur peut devenir serveur dans un restaurant du jour au lendemain…

     » Que tu laisses n’importe qui soumettre un paquet traditionnel ou un Flatpak sur le dépôt, il y aura absolument les mêmes chances d’obtenir de la merde des deux côtés. C’est déjà arrivé sur le dépôt communautaire AUR, comme ça arrivera fatalement à d’autres. »

    Et je te remets le lien que j’ai mis sur Mastodon : la faille a été corrigé en l’espace d’une nuit. https://lists.archlinux.org/pipermail/aur-general/2018-July/034151.html

    « C’est obligatoire sur d’autres plateformes, qui ne s’en portent pas plus mal.  »

    Ah, c’est beau cette remarque… :)

    « Déjà, Linux est bien moins sécurisé que Windows ou macOS. Rien que de continuer d’utiliser X.org, ça permet à n’importe quelle application d’enregistrer les frappes clavier dans n’importe quelle autre application, ou de faire des captures d’écran en douce.  »

    Moins sécurisé ? Tu me rappelleras le nombre de malwares linuxiens et leur dégats en dehors des attaques sur les serveurs. Merci :)

    « Wayland résout ces différents problèmes, comme Flatpak renforce encore un peu plus la sécurité, qui était jusque-ici complètement catastrophique. »

    Et pour cause, qu’elle est catastrophique. X11 a été développé au début des années 1980… Faut savoir remettre les choses dans leur contexte. L’oublierais-tu ?

    « Puis c’est sans doute très bien quand tu es naturellement parano et que tu n’utilises que des logiciels libres sous Debian, mais dans le monde réel, les gens ont envie de pouvoir utiliser Skype, Spotify, et sûrement tout un tas d’autres merdes propriétaires dans lesquelles je n’aurai pas particulièrement confiance. »

    Et une leçon de morale au passage ? J’ai des « michus » dans mes proches.

    Mon OS ? Comment dire ?

    « fred@fredo-arch-mate ~ % uname -a
    Linux fredo-arch-mate 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17 UTC 2018 x86_64 GNU/Linux »

    Voila.

    Ton dernier commentaire, je n’ai rien à répondre mis à part ceci :

    « Après Autopackage, 0Install, c’est le tour du trio AppImage, Flatpak, Snap…

    L’histoire est un éternel recommencement. »

    Les flatpak ? L’avenir de l’empaquetage de nos arrières grand parents.

    Pour finir ? L’utilisation d’un dépôt centralisé unique un peu à l’image de l’AppStore ou du PlayStore me faire dire que le monde linuxien se windowsise.

    D’ici un an ou deux, je me serai tiré sur un BSD libre, histoire d’échapper à une telle dérive qui est suicidaire sur le long terme.

    1. « Moins sécurisé ? Tu me rappelleras le nombre de malwares linuxiens et leur dégats en dehors des attaques sur les serveurs. Merci :) »

      Le fait qu’elles soient moins nombreuses (on a pas non plus les mêmes parts de marché) ne signifie pas qu’elles soient inexistantes. Et rien n’empêche leur augmentation dans le futur. Par conséquent, je préfère qu’on prenne les devants (sans oublier que les questions de sécurité n’étaient qu’un problème parmi d’autres) plutôt que d’attendre bêtement le pire. D’autant plus que ça ne se fait pas d’un simple claquement de doigts. Que ce soit Wayland ou Flatpak, ça représente de nombreuses années de travail. Sans parler du temps nécessaire ensuite à leur adoption.

      « Et pour cause, qu’elle est catastrophique. X11 a été développé au début des années 1980… Faut savoir remettre les choses dans leur contexte. L’oublierais-tu ? »

      Bien sûr que non. Mais je trouve plutôt sain de reconnaître nos lacunes et de faire en sorte de les résoudre. Il est donc normal que les technologies évoluent. L’inverse serait plutôt inquiétant.

      « Et une leçon de morale au passage ? J’ai des « michus » dans mes proches. »

      Ce n’est absolument pas un reproche. Plutôt une constatation. Je suis le premier à reconnaître que les gens sont libres d’utiliser ce qu’ils veulent. Tout comme ils sont libres de faire des conneries ou de se faire avoir par des logiciels malveillants. Il est donc du devoir des systèmes d’exploitation (quels qu’ils soient) de tout faire pour protéger leurs utilisateurs. Et encore une fois, même si de nombreuses technologies libres répondaient aux besoins ces dernières années, il n’en demeure pas moins que la sécurité n’a pas été prise en compte durant leur conception.

      Et quand je parle de sécurité, c’est de façon globale. Menaces délibérées (malwares), problèmes involontaires (comme le client Steam qui effaçait toutes les données de l’utilisateur ou une mise à jour foireuse qui cassait les systèmes Fedora…), sans parler des propres erreurs de l’utilisateur.

      Avec les Flatpak, OSTree et d’autres technologies, Fedora devrait connaître un renouveau avec son projet Silverblue, qui devrait la rendre bien plus sûre et plus fiable à bien des égards. Mais Mathieu Bridon en parlera sans doute bien mieux que moi :)

      « Après Autopackage, 0Install, c’est le tour du trio AppImage, Flatpak, Snap… L’histoire est un éternel recommencement. »

      Ça serait problématique si on répétait inlassablement les mêmes erreurs. Mais si ça évolue dans le bon sens, on appel ça le progrès :D

      « Pour finir ? L’utilisation d’un dépôt centralisé unique un peu à l’image de l’AppStore ou du PlayStore me faire dire que le monde linuxien se windowsise. »

      Ça fait des années, bien avant que Windows, macOS ou Android découvrent le principe des dépôts, que chaque distribution GNU/Linux utilise son propre dépôt centralisé. Pour l’utilisateur, même s’il existe d’autres distributions, et donc d’autres dépôts, quand il installe un paquet, ça va toujours le récupérer au même endroit. Et j’en profite pour rappeler que l’utilisation du dépôt Flathub n’est en rien obligatoire, certaines distributions ayant déjà créé leur propre dépôt Flatpak.

      « D’ici un an ou deux, je me serai tiré sur un BSD libre, histoire d’échapper à une telle dérive qui est suicidaire sur le long terme. »

      C’est marrant, j’entends le même refrain chez tous les intégristes réfractaires au changement depuis des années (c’était mieux avant systemd, Wayland, PulseAudio, Flatpak ou whatever…). Puis finalement, tout le monde reste sous Linux, qui offrira toujours le choix. Il y aura toujours des distributions qui seront elles-mêmes réfractaires au changement ou qui auront, tout simplement, une vision différente de la conception et de l’utilisation d’un système.

      1. Ce sera ma dernière réponse, étant donné que nous resterons sur nos positions respectives. Sur la plus grosse partie du commentaire, je n’ai rien à dire, je passe sur les morceaux qui m’ont fait tiqué.

        « Ça fait des années, bien avant que Windows, macOS ou Android découvrent le principe des dépôts, que chaque distribution GNU/Linux utilise son propre dépôt centralisé. Pour l’utilisateur, même s’il existe d’autres distributions, et donc d’autres dépôts, quand il installe un paquet, ça va toujours le récupérer au même endroit. Et j’en profite pour rappeler que l’utilisation du dépôt Flathub n’est en rien obligatoire, certaines distributions ayant déjà créé leur propre dépôt Flatpak. »

        Les dépots centralisés existent déjà pour les distributions… Ce sont les dépots avec les paquets officiels pour chacune d’entre elles :)

        « C’est marrant, j’entends le même refrain chez tous les intégristes réfractaires au changement depuis des années (c’était mieux avant systemd, Wayland, PulseAudio, Flatpak ou whatever…). Puis finalement, tout le monde reste sous Linux, qui offrira toujours le choix. Il y aura toujours des distributions qui seront elles-mêmes réfractaires au changement ou qui auront, tout simplement, une vision différente de la conception et de l’utilisation d’un système. »

        Rien que le « intégriste » décrédibilise ce qui suit. Je dis simplement que Flatpak est une énième réinvention de la roue qui ne servira pas la cause qu’il prétend défendre. J’ai encore essayé ce matin le flatpak de VLC sur Fedora 28 ? Résultat ? Un logiciel en anglais sur une installation en français après un téléchargement de plus d’un gigaoctet.

        Pas encore au point le système des paquets universels.

        Le « c’était mieux avant » pour dire aux personnes qui critiquent les problèmes liées à des nouveautés technologique ? Comme c’est classique :)

        Flatpak connaitra le même sort qu’autopackage et 0install. C’est mon opinion. On verra si les faits corrobore tout cela.

        Tu utilises la sécurité comme un mantra… On se croirait dans la célèbre scène du poumon du Malade Imaginaire de Molière. Un comique de répétition.

        On se donne rendez-vous dans deux ans pour faire un constat, d’accord ? :)

        1. « Les dépots centralisés existent déjà pour les distributions… Ce sont les dépots avec les paquets officiels pour chacune d’entre elles :) »

          Tu me sors que les « dépôt centralisé unique un peu à l’image de l’AppStore ou du PlayStore me faire dire que le monde linuxien se windowsise ». Je te réponds juste que les dépôts centralisés ont toujours existé sous Linux, qu’il n’y a donc rien de nouveau, et que ce n’est donc sûrement pas ça qui va nous windowsifier…

          « J’ai encore essayé ce matin le flatpak de VLC sur Fedora 28 ? Résultat ? Un logiciel en anglais sur une installation en français après un téléchargement de plus d’un gigaoctet.

          Commençons déjà par le poids. Ce n’est clairement pas VLC qui prend un Go, mais le runtime. Maintenant que ce dernier est installé, tu pourras installer des dizaines de Flatpaks qui utiliseront le même runtime, ça ne te prendra pas plus de place que les paquets traditionnels.

          Pour le problème de la langue, c’est juste que les développeurs n’ont pas correctement initialisé gettext pour qu’il puisse être appelé depuis un chemin différent de /usr. Ils doivent faire un appel à bindtextdomain() avec le bon chemin, comme indiqué dans la documentation officielle. Comme je l’ai déjà indiqué, certaines applications ont encore besoin d’être légèrement adaptées.

          « Le « c’était mieux avant » pour dire aux personnes qui critiquent les problèmes liées à des nouveautés technologique ? Comme c’est classique :) »

          En même temps, si, au lieu de se focaliser uniquement sur les quelques problèmes de jeunesse, les gens arrivaient à voir au-delà et percevoir toutes les nouvelles possibilités offertes, ou réaliser que ça ne leur apporte peut-être personnellement rien de plus, mais que ça améliore la situation pour bien d’autres personnes, on aura fait un grand pas en avant :)

          Suffit de voir à quel point PulseAudio avait été décrié à ses débuts (alors que bien souvent, ça faisait surtout ressortir des bugs dans les pilotes audio), alors que maintenant, il sait se faire oublier chez la majorité des utilisateurs, qui sont bien heureux de pouvoir bénéficier de toutes les fonctionnalités qu’il propose.

          « Tu utilises la sécurité comme un mantra… »

          Au contraire. Contrairement aux réfractaires qui ne me citent qu’un domaine en particulier, j’ai bien tenté de mettre en avant les nombreux apports. La sécurité en fait partie, mais il y a également la simplification de la distribution des applications, la simplification du développement (je vous invite d’ailleurs à relire cet article, qui en aborde certains aspects), du bêta test, la garantie d’un fonctionnement à l’identique chez tous les utilisateurs, peu importe leur distribution. Et par ricochet, la reproductibilité des bugs, qui rendra leur correction plus aisée.

          Sérieux, ça me tue qu’on ne puisse pas reconnaître tous les avantages apportés, à moins de se limiter à sa propre utilisation : « chez moi ça fonctionne très bien tel quel, les autres (développeurs, empaqueteurs, utilisateurs…) ne m’intéressent pas, et je n’ai pas envie que ça change ».

    2. Je me permets d’intervenir dans cette discussion, étant utilisateur Linux de longue date mais très peu tech. Je ne suis à la base pas très fan des solutions sandboxées. Mais sans doute pour leur relative jeunesse. Si l’on tend vers un usage / une intégration aussi aboutie que presenté par Okki, alors je valide.

      « Et surtout ils ont compris que le contrôle de la bibliothèque logicielle est indispensable pour maitriser l’utilisateur final.

      De plus l’argument du « tout le monde le fait » est un peu court. On peut via un raisonnement par l’absurde utiliser une comparaison avec le saut à l’élastique… »

      Euh, pardon … mais c’est une argumentation ça ? Je suis d’accord qu’il ne faut pas faire bêtement quelque chose parce que tout le monde fait la même, mais je rejoins Okki (que je ne connais absolument pas je précise), vu le nombre de développeurs et d’ingénieurs qui bossent sur ces systèmes, si ce genre de solution est adoptée c’est sans doute pour de bonnes raisons. On va me dire, ce sont des sociétés donc c’est la rentabilité avant tout !
      Mais le temps libre des bénévoles est tout aussi précieux !
      Leur en faire gagner n’est pas négligeable non plus.

      « Il est vrai que TOUT le monde n’est pas dérangé à mettre 50€ dans du matos pour le plaisir des développeurs qui réinventent la roue. »

      Ca me fait penser à la RAM, ou à nos vieilles disquettes 3,5 pouces.
      Il faudrait peut-être arrêter les économies faites de bouts de chandelles. Je suis loin d’etre à l’aise dans mes finances, pour autant, avoir un système de 10 ou 20Go, quelle différence ?
      Je ne comprends pas cet argument. Tout dans l’informatique est en perpétuel croissance. Alors a moins de vouloir faire tourner des vieilles machines encore 10 ans de plus, je ne vois pas en quoi la dizaine de gigas que pourrait éventuellement prendre un système pose problème …

      « Tout comme un horticulteur peut devenir serveur dans un restaurant du jour au lendemain… »

      Le plus important ne serait-ce pas de s’épanouir et de se sentir utile dans la société ? Je ne suis pas pro Macron, loin de là, je dis juste que ce serait prétentieux de croire que l’on ne pourrait pas prendre du plaisir en faisant un travail qui n’est pas le sien. Je pensais que les bénévoles étaient dans le libre avant tout pour proposer et faire avancer un système / une philosophie. Je pensais que c’était la motivation première et que les moyens pour y parvenir étaient simplement les compétences et le temps que chacun était prêt à mettre. J’ai dû me tromper …

      « Et je te remets le lien que j’ai mis sur Mastodon : la faille a été corrigé en l’espace d’une nuit. https://lists.archlinux.org/pipermail/aur-general/2018-July/034151.html »

      Cela ne peut remettre en question son existence ni même une possible réapparition sous une autre forme que celle connue d’aujourd’hui.

      « Ah, c’est beau cette remarque… :) »

      Oui, si les moyens des bénévoles sont limités, cette remarque prend tout son sens !

      « Moins sécurisé ? Tu me rappelleras le nombre de malwares linuxiens et leur dégats en dehors des attaques sur les serveurs. Merci :) »
      Je plussoie pour le coup …

      « Et pour cause, qu’elle est catastrophique. X11 a été développé au début des années 1980… Faut savoir remettre les choses dans leur contexte. L’oublierais-tu ? »

      Donc on fait quoi ? On reste avec cet outil des années 80 ?
      Un moment donné, faut être constructif ! …et évoluer !

      « Et une leçon de morale au passage ? J’ai des « michus » dans mes proches. »

      Et moi donc ! Et toute sans exceptions ne concoivent pas qu’en 2018, un système informatique ne soit pas au service de l’utilisateur.
      Que chaque logiciel désiré passe par les étapes :
      – est il compatible Linux ?
      – y a t il un équivalent ?
      – est il disponible pour ma distrib ?
      – quelle version ?
      – compiler pour la dernière version ? c’est quoi ça ? je veux juste utiliser un programme !
      Mon OS ? Comment dire ?

      « fred@fredo-arch-mate ~ % uname -a
      Linux fredo-arch-mate 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17 UTC 2018 x86_64 GNU/Linux »

      Je suis dans l’informatique mais je me heurte à cette même difficulté : les gens néophytes sont prêts à quitter mac os, windows, et consorts car ils ont compris que ces sociétés abusaient d’eux … mais ils restent utilisateurs finaux et ne veulent / ne devraient pas à avoir des connaissances en informatique pour installer un logiciel quel qu’il soit.

      « Les flatpak ? L’avenir de l’empaquetage de nos arrières grand parents. »

      Je trouve ce commentaire cinglant. Ne serait ce que pour tout le travail et les efforts fournis derrière ces projets. Que faites vous depuis des années pour donner raison à votre vision des choses ?
      A part form(at)er les utilisateurs à une distribution technique, se passer de certains outils, et mettre de côté tous ceux qui n’embrassent pas à 100% la vision du libre ?
      Je trouve cette vision trop binaire. Il n’y a pas les cons d’un côté et les volontaires de l’autre. Beaucoup de personnes se trouvent entre les deux. Elles cherchent un système et des outils respectueux, sans pour autant vouloir se former à l’usage ou contribuer au projet.
      Le savoir vivre ensemble c’est entendre aussi ces personnes aux besoins sommaires mais le plus souvent mainstream, afin que Linux ne soit pas réservé aux élites.

      « Pour finir ? L’utilisation d’un dépôt centralisé unique un peu à l’image de l’AppStore ou du PlayStore me faire dire que le monde linuxien se windowsise. »

      Oh mon dieu ! Ce serait la fin du monde !
      Je n’ose même pas imaginer : des applications multiplateformes, des madame michus de partout, des empaqueteurs qui s’ennuient de ne trouver aucune activité, … on rêve !

      « D’ici un an ou deux, je me serai tiré sur un BSD libre, histoire d’échapper à une telle dérive qui est suicidaire sur le long terme. »

      Puis je savoir ce qui vous en empêche aujourd’hui ? Je trouve ça très masochiste de rester sur un système que l’on ne cesse de critiquer.
      Je ne compte plus les coups de sang que vous alimentez partout sur la toile. J’aime beaucoup lire vos articles, mais pour autant, je ne suis pas d’accord avec votre vision personnelle de ce qu’est / de ce que doit être Linux.

      J’arrête là, je sais que vous démonterez point par point mon argumentaire, et que vous continuerez à penser que n’importe quel utilisateur loin de l’informatique, n’a qu’à suivre un tuto d’install ArchLinux pour s’épanouir.

      1. « Ca me fait penser à la RAM, ou à nos vieilles disquettes 3,5 pouces.
        Il faudrait peut-être arrêter les économies faites de bouts de chandelles. Je suis loin d’etre à l’aise dans mes finances, pour autant, avoir un système de 10 ou 20Go, quelle différence ?
        Je ne comprends pas cet argument. Tout dans l’informatique est en perpétuel croissance. Alors a moins de vouloir faire tourner des vieilles machines encore 10 ans de plus, je ne vois pas en quoi la dizaine de gigas que pourrait éventuellement prendre un système pose problème … »

        Exactement le comportement/raisonnement qui conduit à http://tonsky.me/blog/disenchantment/

        1. Mouais. Même si tout n’est pas parfait, soit il est particulièrement jeune, soit il a vraiment la mémoire courte.

          Comparer le poids et la consommation des ressources de MS-Dos / Windows 95 avec les systèmes actuels est juste stupide. Pour ceux qui n’ont pas connu cette époque, MS-Dos était un système mono-tâche (vous ne pouviez donc pas utiliser deux applications simultanément), mono-utilisateur (vive la sécurité), n’avait pas d’interface graphique, de pile TCP/IP et j’en passe et des meilleures.

          Et c’est bien évidemment la même chose pour les applications. Quand je vois les trucs de dingue qu’on arrive à faire aujourd’hui, j’hallucine complètement. Il y a peu, on faisait une sortie en famille. Ma mère ne se souvenait plus du nom d’une fleur croisée sur le chemin. Je dégaine mon smartphone, lance Pl@ntNet, prend une photo de la fleur en question, et pif paf pouf, ça me sort son nom commun et en latin, tout un tas d’infos sur la fleur…

          Pour moi, c’est juste magique.

          Alors oui, dans l’informatique, tout n’est pas forcément optimisé comme il le faudrait, il y a des bugs, des erreurs de conception. Mais putain, quand on voit les progrès effectués régulièrement, je trouve ça complètement dingue.

          On devrait l’obliger à passer un mois sous Windows 95 pour qu’il redescende un peu sur Terre. Pour ceux qui n’ont pas non plus connu, il était peut-être plus léger niveau poids (mais sur les machines d’époque, c’était cent fois plus lent qu’un système actuel sur une machine moderne… par exemple, il lui fallait plusieurs minutes pour démarrer, là où je ne mets qu’une poignée de secondes avec un SSD), mais surtout, il plantait plusieurs fois par jour. Vous étiez en train de travailler, puis pouf, écran bleu de la mort, obligé de redémarrer la machine et de perdre tout le travail non sauvegardé dans la foulée.

          À choisir, je crois que les gens préfèrent infiniment un système peut être moins optimisé, mais qui ne plante jamais. Ainsi qu’un système plaisant visuellement et qui facilite la vie. Pour reprendre l’exemple de son éditeur de texte, il y a vingt ans, il n’y avait pas d’icônes haute définition pour les écrans HiDPI, les polices ne bénéficiaient sans doute pas de l’anticrénelage, il n’y avait pas la restauration de documents, il n’y avait pas de système de fichiers virtuel pour pouvoir accéder de façon transparente à de nombreux protocoles réseau… Il y a plein de fonctionnalités qu’on ne remarque pas forcément, mais qui simplifient grandement la vie, et qui ont bien évidemment un coût en termes de ressources utilisées.

          Mais on s’égare un peu :)

  5. Dans les répétitions de lib il y a souvent boost ou chacun utilise sa version propre. En gros on dit au développeur vous savez pas travailler et au lieu de leur apprendre on leur donne un système sale. Effectivement maintenant tout le monde peut développer mais avec un nivellement par le bas permanent, je ne suis pas surpris de la mauvaise qualité global des logiciels. Ceci explique pourquoi il est difficile de recruter un développeur avec un niveau correct.

  6. Bonjour,
    J’approuve totalement le commentaire de Frederic Bezies.
    Pour faire court ce système de distribution et d’installation de logiciels c’est tout simplement la fin de la sécurité et de la stabilité des distributions GNU/Linux pour ceux qui l’utiliseront.
    Je suis assez surpris de voir sans arrêt les mêmes faux arguments repris partout pour justifier ces systèmes (flatpak, snap, appimage).
    On essaie de nous faire croire que le système de paquets est sinon mauvais au moins un gaspillage de temps et de ressources humaines.
    C’est faux. Le travail d’empaquetage est essentiel à la stabilité et à la sécurité d’une distribution. C’est grâce à cela que l’on a des logiciels sûrs, des correctifs appliqués en permanence aussi bien aux logiciels qu’aux bibliothèques dépendantes.
    On essaie de nous faire croire que c’est un système sécurisé.
    C’est faux. Le fait que l’application s’exécute dans un « bac à sable » n’est pas une sécurité : c’est un faux sentiment de sécurité. Si l’application contient du code malveillant cela n’empêchera pas la fuite de données. Si l’application embarque une bibliothèque contenant une faille de sécurité, celle-ci pourra être exploitée. Les développeurs qui distribuent ainsi leur application ne mettront certainement pas à jour leur applications à chaque alerte de sécurité sur un des nombreux composants qu’ils sont susceptibles d’utiliser, contrairement aux empaqueteurs des distributions qui intègrent des correctifs me dans des choses assez anciennes.
    On essaie de nous faire croire que cela n’a pratiquement pas d’incidence sur les ressources du système.
    C’est faux. Outre une place parfois phénoménales occupées sur le disque, cela a une incidence sur l’utilisation de la mémoire et du processeur. On peut imaginer trois applications utilisant trois versions différentes (ou embarquant la même version) de la même bibliothèque. Celle-ci sera donc chargé trois fois en mémoire…
    On essaie de nous faire croire que cela va faciliter la vie des développeurs qui pourront distribuer leurs logiciels sans avoir à créer des paquets pour chaque distribution.
    C’est faux. Ce n’est pas le travail des développeurs de fournir des paquets. Et malgré la promesse de ces technologies rien ne garanti que le logiciel fonctionnera correctement partout (J’ai au moins un exemple de logiciel qui bogue en tant que appimage et qui fonctionne parfaitement en tant que paquet deb, version identique).

    Je ne vois que des inconvénients, et même des risques majeurs, à utiliser ces technologies.
    AMHA, le seul objectif de celles-ci est de pouvoir distribuer des logiciels propriétaires ou avec une partie du code fermé.

    Au passage, je ne te félicite pas pour l’utilisation de nombreux pisteur sur cette page. En particulier le très pénible capatcha…

    1. « C’est faux. Le travail d’empaquetage est essentiel à la stabilité et à la sécurité d’une distribution. C’est grâce à cela que l’on a des logiciels sûrs, des correctifs appliqués en permanence aussi bien aux logiciels qu’aux bibliothèques dépendantes. »

      Et qu’est-ce qui empêche d’effectuer des mises à jour de Flatpak ?

      « C’est faux. Le fait que l’application s’exécute dans un « bac à sable » n’est pas une sécurité : c’est un faux sentiment de sécurité. »

      Parce qu’aujourd’hui, tout est sécurisé ? Tu ne peux pas empêcher l’intégration de code malveillant et encore moins que l’utilisateur se fasse infecter après coup. Alors oui, tu peux te limiter aux paquets de ta distribution en qui tu places toute ta confiance. Mais avec de nombreuses années d’utilisation de systèmes libres au compteur, ce que j’ai remarqué, c’est que le jour où un logiciel n’est pas dans les dépôts de la distribution ou que la version ne satisfait pas les besoins, les gens sont prêts à activer le premier dépôt / PPA venu, sans vraiment se préoccuper de savoir qui est derrière ou du niveau de qualité du travail, pour pouvoir enfin combler leurs besoins.

      Et il n’y a pas besoin de s’exciter. Certaines distributions vont totalement embrasser le principe du Flatpak (Fedora, Endless OS…), mais pour d’autres, ça ne sera qu’un complément occasionnel. La plupart des gens continueront sans doute d’utiliser une Debian stable ou une Linux Mint (basée sur les versions LTS d’Ubuntu), avec seulement quelques Flatpak pour les rares applications utilisateur qui auraient besoin d’être plus à jour.

      « Si l’application contient du code malveillant cela n’empêchera pas la fuite de données. »

      On est d’accord. Mais je ne vois pas pourquoi une vieille version d’un logiciel libre empaqueté par une distribution serait plus sûr que la dernière version de ce même logiciel empaqueté sous forme de Flatpak par les développeurs de l’application ou par les bénévoles d’un dépôt Flatpak (dépôts tiers non officiels qui ont toujours existé).

      Maintenant, même si ça ne te protège pas de tout, le fait que ce soit isolé te protégera tout de même de certaines menaces. L’application n’accèdera pas au micro ou à la webcam si tu ne l’y pas autorisé, ne prendra pas de capture d’écran en douce, ne pourra pas accéder à l’ensemble des données de ton système…

      « Si l’application embarque une bibliothèque contenant une faille de sécurité, celle-ci pourra être exploitée. Les développeurs qui distribuent ainsi leur application ne mettront certainement pas à jour leur applications à chaque alerte de sécurité sur un des nombreux composants qu’ils sont susceptibles d’utiliser, contrairement aux empaqueteurs des distributions qui intègrent des correctifs me dans des choses assez anciennes. »

      Encore une fois, les Flatpak utilisent des runtimes qui contiennent toutes les bibliothèques dont ils sont censés avoir besoin. Les runtimes sont gérés par la communauté. Donc s’il y a des failles dans ces bibliothèques, le runtime concerné sera mis à jour. Ce n’est pas au développeur de l’application de s’en occuper.

      Tu peux voir le contenu du runtime Freedesktop ici.

      « On peut imaginer trois applications utilisant trois versions différentes (ou embarquant la même version) de la même bibliothèque. Celle-ci sera donc chargé trois fois en mémoire… »

      Encore une fois, tu n’auras pas trois versions identiques d’une même bibliothèque. Par contre, tu pourras effectivement avoir plusieurs anciennes versions différentes, mais c’est déjà plus ou moins le cas avec les paquets traditionnels. Les développeurs d’applications (qui ne sont parfois plus maintenues) n’adaptant pas systématiquement leur travail aux toutes dernières versions des différentes bibliothèques utilisées, les distributions sont obligées de fournir plusieurs anciennes versions des différentes bibliothèques pour assurer la compatibilité.

      Si tu n’utilises que des applications bien maintenues, tu ne devrais pas avoir ce souci. Et si t’as besoin d’utiliser de vieilles applications (et je ne pense pas que les gens utilisent énormément de vieilles applications différentes), alors tu seras heureux d’apprendre que la compatibilité sera améliorée. Point qui devrait surtout intéresser les entreprises qui continuent d’utiliser des applications qui ont parfois plusieurs dizaines d’années.

      « C’est faux. Ce n’est pas le travail des développeurs de fournir des paquets. »

      Oui et non. Déjà, tout le monde oublie la question des applications non libres, qui ne sont généralement pas empaquetées par les distributions GNU/Linux. Par exemple, je ne vois pas de Skype ou de Spotify dans les dépôts Debian ou Fedora. Et bien évidemment, les éditeurs de ces applications ne vont pas s’embêter à les empaqueter pour cinquante distributions. Ni même pour les différents systèmes de paquets. En gros, t’auras généralement un DEB, et avec un peu de chance, peut-être un RPM. Et pour les autres, démerdez-vous.

      Ensuite, tout le monde n’utilise pas forcément une Debian / Ubuntu (qui devrait sincèrement remercier Debian pour tout le travail accompli). Sur bien des distributions (y compris Fedora, qui est pourtant considérée comme majeure), je peux te lister des dizaines, pour ne pas dire des centaines d’applications qui ne sont pas dans les dépôts officiels (ni même sur RPM Fusion). Et donc, quand ni le développeur ni la distribution ne s’en occupent, tu fais comment ? Avec les Flatpaks, il suffira qu’il y ait au moins une personne pour faire l’effort de s’en occuper pour que ça puisse profiter à tous.

      « Et malgré la promesse de ces technologies rien ne garanti que le logiciel fonctionnera correctement partout (J’ai au moins un exemple de logiciel qui bogue en tant que appimage et qui fonctionne parfaitement en tant que paquet deb, version identique). »

      Je ne connais pas le format AppImage (j’ai juste vu, de loin, que ça répondait à bien moins de problématiques). Maintenant, tout comme tu peux avoir des paquets DEB / RPM mal conçus, tu peux très bien avoir des paquets AppImage, Snap ou Flatpak qui le seraient également. Tout comme il ne faut pas oublier que pour prendre en charge correctement l’isolation, l’application a parfois besoin d’être adaptée, ce qui peut prendre du temps. Mais voilà, faut pas limiter toute la technologie à un problème rencontré par le passé sur un paquet en particulier :)

      « AMHA, le seul objectif de celles-ci est de pouvoir distribuer des logiciels propriétaires ou avec une partie du code fermé. »

      Ouais, c’est sans doute pour ça que de nombreux développeurs de logiciels libres adorent cette techno, qui leur fait gagner du temps aussi bien sur le développement en lui-même, que sur la distribution de leur application :p

      1. Comme tu le soulignes avec les « dépôts » flatpak on est presque dans le même cas qu’avec des dépôts tiers : problème de mises à jour, d’abandon du développement, de confiance (absence de code malveillant par exemple). Le dernier problème étant relativement limité quand on a accès au code source.
        Je déconseille toujours fermement aux débutants d’utiliser des sources de logiciels en dehors des dépôts officiels de leur distribution. C’est le meilleur moyen d’avoir des problèmes et les divers forums sont remplis de soucis dus à cela.
        Maintenant comme les snap/flatpak vont être, ou sont déjà, inclus dans les logithèques, les utilisateurs finaux les installerons sans aucune conscience de leur provenance ni de la licence du logiciel.

        Je n’oublie pas la question des applications non libres, mais si j’utilise un système d’exploitation libre ce n’est pas pour le pourrir avec des applications propriétaires qui sont parfois de véritables logiciels espions. Au passage il y a des paquets pour installer les logiciels que tu cites sous Debian.

        Quand aux applications non empaquetées, je doute que tu puisse m’en citer des centaines sur une distribution majeure comme Debian. Évidemment plus tu choisis une distribution exotique et moins tu auras de logiciels disponibles.

        Ton explication sur les « runtimes » montre bien à quel point ce système est stupide puisque cela revient à faire le travail de la distribution en récupérant toutes les bibliothèques et applications nécessaires en amont. Mais sans les adapter et les corriger comme le font les empaqueteurs Debian par exemple.

        On parlait de gaspillage de ressources humaines. En voilà un magnifique. On refait la même chose de manière moins sécurisée pour un résultat moins bon.

        1. « Maintenant comme les snap/flatpak vont être, ou sont déjà, inclus dans les logithèques, les utilisateurs finaux les installeront sans aucune conscience de leur provenance ni de la licence du logiciel. »

          Si un dépôt Flatpak est activé par défaut, il est évident que la distribution optera pour un dépôt de confiance. Et encore une fois, on retrouve des équivalents avec les paquets traditionnels, certaines distributions ayant des dépôts communautaires. Chez Arch / Manjaro c’est AUR, chez Ubuntu c’est universe et multiverse…

          Quant aux licences, que ce soit un paquet traditionnel ou un Flatpak, l’application doit désormais être fournie avec un fichier AppStream qui contient toutes les informations nécessaires, dont la licence, qui est ensuite affichée dans la logithèque. L’utilisateur sait donc si oui ou non l’application est libre.

          La provenance est bien évidemment également indiquée dans la logithèque et l’utilisateur a le contrôle de ses dépôts (graphiquement, ça s’active ou se désactive en deux clics).

          « Je n’oublie pas la question des applications non libres, mais si j’utilise un système d’exploitation libre ce n’est pas pour le pourrir avec des applications propriétaires qui sont parfois de véritables logiciels espions. Au passage il y a des paquets pour installer les logiciels que tu cites sous Debian. »

          C’est bien le souci des libristes, qui ne se mettent jamais à la place de monsieur tout le monde, qui a peut êtres d’autres besoins ou façons de voir les choses. Quant à mes deux exemples, j’ai pris deux applications particulièrement connues. Le problème ne sera pas forcément le même pour toutes les applications sur toutes les distributions. Par exemple, sous Ubuntu, qui possède un dépôt commercial et des accords avec certains éditeurs, ça sera beaucoup plus simple d’y trouver ce genre d’applications que sur une autre distribution plus petite ou qui accorde plus d’importance au logiciel libre.

          « Quant aux applications non empaquetées, je doute que tu puisses m’en citer des centaines sur une distribution majeure comme Debian. »

          Je suis le premier à reconnaître que Debian propose une incroyable logithèque, qui plus est avec un empaquetage de grande qualité. Mais c’est malheureusement l’exception et non la règle. Sous Fedora, on a clairement pas la même offre /o\

          « On parlait de gaspillage de ressources humaines. En voilà un magnifique. On refait la même chose de manière moins sécurisée pour un résultat moins bon. »

          Tout dépend de quel point de vu on se place. Le travail effectué par Debian ne concerne que Debian (ainsi qu’Ubuntu et ses nombreux dérivés, tu me diras :)

          Fedora, SUSE, Alpine, Arch, Mageia, Solus… ne bénéficient pas du travail de Debian. Maintenant, si on crée des runtimes et des Flatpaks utilisés par toutes ces distributions, est-ce toujours du gaspillage de ressources ?

          Et pourquoi le résultat serait moins bon ? Debian, qui se veut stable et qui doit donc rétro-porter ses correctifs dans le temps, est obligé de patcher de vieilles versions. À l’opposé, Arch, qui a fait le choix de proposer toujours les dernières versions, ne modifie quasiment jamais rien. Aucun patch, ils fournissent le travail upstream tel quel. Je ne pense pas qu’ils soient moins bons. C’est juste une approche différente pour des besoins différents.

          J’imagine que pour les runtimes, ça doit être une approche similaire. Si une version sort en amont avec des correctifs de sécurité, elle sera mise à jour dans le runtime sans qu’il y ait besoin de patcher comme Debian.

        2. Calibre est une application libre.
          Sur les dépots ubuntu elle dépasse pas la version 2.55
          (ridicule)
          Alors que la dernière version elle est en 3.31 …
          La version 2.55 ne permet de partagé qu’une bibliothèque à la fois sur le réseau, alors que la version 3, autant que l’on en a.
          Du coup comment on fait avec ta méthode sachant que si cela ne s’installe pas avec les dépot ubuntu, a priori, c’est justement parce qu’ils manquent certaine librairies.
          Sauf à installer un dépôt tiers pour un binaire.
          Quand au « source install », j’ai essayé, j’y suis jamais arrivé, c’est bien au-delà de mes compétences.
          Et que dire de FreeCad, Krita, blender pour ceux que je connais …

          Donc vive les flatpaks … et c’est un Mr Michu qui vous le dit …

          PS : Quand à Manjaro et consort aucune de mes installs n’a tenu plus d’un mois … MDR

      2. « Mais je ne vois pas pourquoi une vieille version d’un logiciel libre empaqueté par une distribution serait plus sûr que la dernière version de ce même logiciel empaqueté sous forme de Flatpak par les développeurs de l’application ou par les bénévoles d’un dépôt Flatpak (dépôts tiers non officiels qui ont toujours existé) »

        Parce que les mainteneurs des bibliothèques d’une distribution sont bien plus nombreux (openssl, kde… en gros autant que de lignes ici : https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/Release-Contents) que les quelques mainteneurs du runtime et de l’application flatpack…

        Par exemple je juste rigole de voir OpenSSL dans le runtime Freedesktop… Ça signifie 20 releases par jour du runtime *juste* pour maintenir dans un état potable la libssl qui se prend 20 failles à la journée ?
        Et le mainteneur de l’application flatpack qui va devoir tester son propre flatpack avec chaque nouvelle release du runtime ?
        On sait d’avance ce que ça va donner hein, via l’exemple de Docker, AppImage ou Windows… Des libs obsolètes parce que les mainteneurs deviennent des machins à passer leurs vies à courir derrière les releases upstream de chaque librairie embarquée (dans le runtime ou l’application) et saturent rapidement au point de ne mettre à jour les libs que sur les releases officielles de leur propre composant upstream unique.

        « Maintenant, même si ça ne te protège pas de tout, le fait que ce soit isolé te protégera tout de même de certaines menaces. L’application n’accèdera pas au micro ou à la webcam si tu ne l’y pas autorisé, ne prendra pas de capture d’écran en douce, ne pourra pas accéder à l’ensemble des données de ton système… »

        Mais tournera avec un OpenSSL 1.0.2 encore dans 10 ans…
        Chouette, pas d’accès au micro mais des RCE ou double-free partout…

        « Encore une fois, les Flatpak utilisent des runtimes qui contiennent toutes les bibliothèques dont ils sont censés avoir besoin. Les runtimes sont gérés par la communauté. Donc s’il y a des failles dans ces bibliothèques, le runtime concerné sera mis à jour. Ce n’est pas au développeur de l’application de s’en occuper. »

        En gros, tu es juste en train de dire que les runtimes miment exactement tout le boulot que font déjà les mainteneurs de distributions old-school depuis 1970 ? :D
        Et que le mainteneur du flatpack applicatif devra tester et empaqueter son paquet pour chaque runtime livré par l’équipe de maintenance de la distribution^W runtime ? ie le taff actuellement réalisé par le mainteneur d’une application qui veut s’intégrer à une distribution ?

        1. « Parce que les mainteneurs des bibliothèques d’une distribution sont bien plus nombreux (openssl, kde…) »

          Je crois qu’il y a méprise. GNOME gère son propre runtime. Les applications GNOME utiliseront le runtime GNOME (+ celui de Freedesktop). Les développeurs GNOME sont plus à même de maîtriser leur travail que les empaqueteurs de distributions X ou Y. KDE gère également son propre runtime. Pour celui de Freedesktop, chaque bibliothèque est bien évidemment gérée par chaque projet concerné. Quand le projet SDL sort une nouvelle version de sa bibliothèque avec des correctifs de sécurité, elle est mise à jour dans le runtime et puis c’est bon. En dehors des distributions de type LTS qui ont des cycles particulièrement longs et qui doivent rétro-porter les corrections de la dernière version vers l’ancienne qu’ils proposent, ici il n’y a pas grand chose de plus à faire, et c’est sans doute automatisable (ça utilise BuildStream).

          S’il y a souci, ça ne concernera sans doute que les vieilles applications qui ne seront plus maintenues mais qui continueront d’utiliser de vieux runtimes qui, passé un certain temps (sans doute quelques années), finiront par ne plus être maintenus eux non plus. Mais ça vaut aussi pour les paquets traditionnels, qui ne sont jamais maintenus ad vitam aeternam. Arrive un moment où le support n’est plus assuré. Et si jamais les Flatpaks sont un jour adoptés par les distributions entreprise du type RHEL (dont le support est généralement de plus de dix ans) et qu’ils s’occupent de la maintenance de certains runtimes en particulier (comme on trouve des noyaux Linux à support long), ça pourrait bénéficier à plein de monde.

          « Par exemple je juste rigole de voir OpenSSL dans le runtime Freedesktop… Ça signifie 20 releases par jour du runtime *juste* pour maintenir dans un état potable la libssl qui se prend 20 failles à la journée ? »

          Alors déjà, si une bibliothèque est touchée par plusieurs failles dans la même journée, en général, le développeur ne sort qu’une seule nouvelle version qui regroupe tous les correctifs. Et même s’il y avait plusieurs failles rapprochées dans plusieurs bibliothèques différentes, le runtime sera mis à jour en conséquence, mais l’utilisateur n’aura pas besoin de tout re-télécharger chaque fois, le gestionnaire de paquets étant capable de ne récupérer que la différence.

          Les gestionnaires du runtime se contentant de proposer le travail des différents projets, je ne pense pas qu’il y ait de souci particulier sur la charge de travail.

          « Et le mainteneur de l’application flatpack qui va devoir tester son propre flatpack avec chaque nouvelle release du runtime ? »

          Parce que le mainteneur d’une bibliothèque s’amuse à tester le bon fonctionnement de toutes les applications qui l’utilisent ? À partir du moment où les développeurs de bibliothèques ne cassent pas les ABI, il n’y a aucun souci à se faire. S’ils le font, c’est uniquement sur une nouvelle version majeure et les développeurs d’applications seraient de toute façon obligés d’adapter leur code.

          Je dirais même que jusqu’à présent, les développeurs d’applications Linux n’ont jamais eu la moindre garantie. Par exemple, l’utilisateur d’une Debian stable ou d’une Ubuntu LTS ne pouvait pas utiliser des applications trop récentes qui auraient utilisé des bibliothèques / versions non présentes dans ces distributions. Tandis que maintenant, un développeur peut s’appuyer sur des runtimes bien précis (par exemple, runtime Freedesktop 18.08 et runtime GNOME 3.30), qu’il suffit d’indiquer dans le manifeste de l’application. Ensuite, quand l’utilisateur voudra installer l’application, ça installera également les runtimes demandés.

          Et si dans quelques mois un développeur de bibliothèque a besoin de proposer de nouvelles API, d’en supprimer d’autres et donc de casser les ABI, il proposera une nouvelle version majeure qui aura sans doute sa place dans une future version du runtime, qui ne posera donc aucun problème aux anciennes applications qui s’appuient sur d’anciens runtimes.

          « On sait d’avance ce que ça va donner hein, via l’exemple de Docker, AppImage ou Windows… Des libs obsolètes parce que les mainteneurs deviennent des machins à passer leurs vies à courir derrière les releases upstream de chaque librairie embarquée »

          À l’heure actuelle, un développeur Windows peut prévoir son application pour Windows 10 et aura la garantie que son application tournera sur tous les Windows 10 (et bien évidemment, si l’application utilise des API propres à Windows 10, ça ne passera pas si l’utilisateur possède un vieux Windows qui n’est plus maintenu).

          Sous Linux, il fait comment ? S’il est adepte des dernières technologies, son application pourra fonctionner sur les distributions à la pointe, mais devra faire une croix sur tous les utilisateurs de distributions un peu à la traîne. À l’inverse, il peut se résigner à développer sur une Debian stable en faisant une croix sur certaines technologies qui auraient pu l’intéresser, en se disant que cette distribution est tellement désuète que toutes les autres distributions devraient disposer, depuis bien longtemps, des prérequis nécessaires pour pouvoir faire tourner son application chez tout un chacun. Tout en regrettant, encore une fois, de ne pas avoir pu utiliser certaines technologies plus récentes qui auraient été pourtant bien sympas.

          Un peu comme si les développeurs Windows s’obligeaient à développer encore sous Windows XP pour être certains de pouvoir toucher tout le monde.

          Ben voilà, Flatpak résout enfin ce dilemme. Le développeur peut s’appuyer sur les derniers runtimes s’il le souhaite, en ayant la garantie que son application pourra être utilisée par tout le monde, à l’identique. Donc non, il n’y a pas besoin de courir après je ne sais quoi. Si un runtime doit être mis à jour, ça sera uniquement pour des correctifs de sécurité. Les nouveaux runtimes contenant de nouvelles versions majeures ne sortiront qu’une fois tous les six mois (aucune idée pour KDE). Et les anciens runtimes sont bien évidemment toujours présents. Il n’y a donc plus besoin de s’inquiéter en devant faire un choix entre le passé ou le présent. Je trouve au contraire que ça simplifie grandement la vie des développeurs.

          « Mais tournera avec un OpenSSL 1.0.2 encore dans 10 ans… »

          Tant que le projet OpenSSL proposera des mises à jour correctives pour la branche 1.0.x, ça devrait également être mis à jour dans le runtime (ou alors il y a souci et la procédure a besoin d’être améliorée). Maintenant, si demain le projet OpenSSL décide de ne plus maintenir cette branche et de pousser les développeurs à basculer sur une version majeure plus récente, soit les ABI sont compatibles et ça pourra être mis à jour dans le runtime, soit ça ne l’est pas et le développeur devra de toute façon s’adapter (et donc utiliser un nouveau runtime plus à jour qui contiendrait la nouvelle version majeure).

          « En gros, tu es juste en train de dire que les runtimes miment exactement tout le boulot que font déjà les mainteneurs de distributions old-school depuis 1970 ? :D »

          Ces mêmes mainteneurs qui doivent refaire exactement le même travail chacun de leur côté ? Deux cents distributions, deux cents fois le même travail et les mêmes vérifications ? Heureusement qu’au bout d’un moment, certains se sont dit que c’était peut-être un peu con et qu’il valait mieux collaborer.

          Ça me fait d’ailleurs repenser à la création du projet AppStream. Avant ça, il n’y avait, par exemple, aucune collaboration sur la description des paquets ou leur traduction. Résultat, chacun décrivait et traduisait (ou pas) la même chose dans son coin. Et au lieu d’obtenir une super logithèque ou tout aurait été bien décrit et traduit en français, on se tape des descriptions qui ne sont souvent pas à jour et trop souvent en anglais (et ne parlons pas des autres informations, comme l’âge requis pour un jeu vidéo, histoire qu’on puisse bloquer l’accès aux jeux trop violents aux jeunes enfants). Heureusement que ça bouge enfin.

          Donc, si je dois résumer, t’es l’utilisateur égoïste, mais satisfait, d’une distribution avec plus d’un millier de bénévoles qui doivent se taper quotidiennement un travail ingrat et difficile ? J’espère que t’as une petite pensée pour eux à chaque nouvelle mise à jour :D

          1. « Je crois qu’il y a méprise. GNOME gère son propre runtime. Les applications GNOME utiliseront le runtime GNOME »
            Et donc si je veux utiliser une application GNOME qui n’a finalement besoin que de GTK, je te tape tout le runtime GNOME… GG…
            Et pour les apps agnostiques, type VLC, je me tape mes libs en dur parce que sinon je me link avec le runtime GNOME *OU* le runtime KDE, et en plus je pleure parce que certaines de mes libs nécessaires ne sont pas toutes dispos dans un seul runtime (au pif libidn pour VLC qui n’est pas dans Freedesktop qui n’embarque que la version libidn2…).

            « Quand le projet SDL sort une nouvelle version de sa bibliothèque avec des correctifs de sécurité, elle est mise à jour dans le runtime et puis c’est bon. »
            Non justement, ce n’est pas bon.
            Le projet **SDL** sort une nouvelle lib, mais c’est bien l’équipe **FreeDesktop** qui va devoir lurker en permanence pour une nouvelle SDL pour rebuild le runtime et faire les correctifs nécessaires. FreeDesktop devient mainteneur de la lib SDL… Et de l’ensemble de toutes les libs qu’ils embarquent !
            À **chaque** nouvelle version de n’importe quelle dépendance, c’est bien le numéro de version du runtime FreeDesktop qui va s’incrémenter… Et va donc exploser exponentiellement avec chaque livraison d’une dépendance…
            Alors que sauf incompatibilité binaire, la version de Firefox sous Debian (ou de n’importe quelle autre applicaiton) n’a jamais bougé quand on met à jour une dépendance système…

            « S’il y a souci, ça ne concernera sans doute que les vieilles applications qui ne seront plus maintenues mais qui continueront d’utiliser de vieux runtimes qui, passé un certain temps (sans doute quelques années), finiront par ne plus être maintenus eux non plus »
            « Des années », en terme de sécurité, c’est la préhistoire…
            Et non, ça va concerner l’ensemble des runtimes et applications qui embarquent au moins une dépendance tiers. Ils en deviennent automatiquement le mainteneur et doivent en suivre le cycle propre de release sous peine de mettre leurs utilisateurs en péril…

            « Mais ça vaut aussi pour les paquets traditionnels, qui ne sont jamais maintenus ad vitam aeternam. »
            Non. Si Firefox jette l’éponge, ça n’empêchera pas la team Debian de OpenSSL d’aller mettre à jour la libssl sans l’impacter ni nécessiter la coopération de l’ensemble de la chaîne de dépendances.
            Et c’est EXACTEMENT le problème de FlatPack justement : si l’équipe d’un runtime ou d’une application jette l’éponge, sa libssl éventuellement embarquée n’est plus maintenue alors que l’équipe OpenSSL elle continue à livrer régulièrement.

            « Alors déjà, si une bibliothèque est touchée par plusieurs failles dans la même journée, en général, le développeur ne sort qu’une seule nouvelle version qui regroupe tous les correctifs. »
            Les releases de sécu en ce moment, c’est plus ou moins tous les jours hein…
            Et non, tu n’attends pas pour les livrer, parce que tu ne sais pas si tu auras une CVE supplémentaire demain ou non.
            À titre d’exemple, Gimp c’est 69 dépendances. Je parie que c’est a minima une nouvelle version du flatpack de Gimp ou de son runtime toutes les semaines du coup, alors que Gimp lui-même n’aura rien livré de nouveau.

            « À partir du moment où les développeurs de bibliothèques ne cassent pas les ABI, il n’y a aucun souci à se faire. S’ils le font, c’est uniquement sur une nouvelle version majeure et les développeurs d’applications seraient de toute façon obligés d’adapter leur code. »
            Merci. Tu viens toi-même de défoncer FlatPack…
            Si c’est ABI compatible, un changement de lib n’impacte pas l’appli. Donc qu’on soit sous Debian ou FlatPack, c’est pareil, l’appli tourne. Sauf que FlatPack a transformé les mainteneurs applicatifs en mainteneurs de dépendances, avec plus de charge de travail.
            Si c’est ABI incompatible, alors qu’on soit sous Debian ou FlatPack, ça pète, et par sécurité, il ne faut même plus chercher à faire tourner l’ancienne version mais effectuer le portage (ça sent la faille de sécu à plein nez…).

            « Et si dans quelques mois un développeur de bibliothèque a besoin de proposer de nouvelles API, d’en supprimer d’autres et donc de casser les ABI, »
            ie s’asseoir sur 50 ans de bonnes pratiques qui veulent qu’on ne casse JAMAIS les ABI sauf si on a une bonne raison de le faire ?
            Et donc que FlatPack est la solution à un non-problème pour autoriser les gens à faire de la merde ?

            http://tonsky.me/blog/disenchantment/

            « Sous Linux, il fait comment ? S’il est adepte des dernières technologies, son application pourra fonctionner sur les distributions à la pointe, mais devra faire une croix sur tous les utilisateurs de distributions un peu à la traîne. »
            Non. Je ne connais que peu de logiciel qui soient actuellement incapables de tourner sur une Debian Stretch (voire Jessie) et sur du Buster ou du Arch.
            Au pire, tu files les 2/3 commandes pour le builder et basta.

            Sans parler que ton application fait aussi des choix de public. Développer du logiciel desktop en partant sur une Debian Stable, c’est crétin, un gens humain est plutôt généralement sur Testing. Développer du soft serveur en se basant sur du Debian Testing, c’est con, la prod va être sous Stretch.

            « Si un runtime doit être mis à jour, ça sera uniquement pour des correctifs de sécurité. »
            Tu ne sembles pas avoir compris le problème. La question n’est pas de savoir quand ou avec quelle volumétrie la maj sera faite, mais *PAR QUI*.

            Les distributions sont *DÉCENTRALISÉES*, et sous réserve de respect des ABI (généralement assuré upstream), le mainteneur de OpenSSL ne s’occupe *QUE* de OpenSSL, le mainteneur de GNOME *QUE* de GNOME et le développeur de VLC *QUE* de VLC. Pour une modif de OpenSSL, seule la team OpenSSL va bosser, et c’est son boulot officielle et assumée.

            FlatPack est *CENTRALISÉ*, puisqu’une modif de OpenSSL impose à GNOME de livrer une nouvelle version qui impose à VLC de livrer une nouvelle version. Pour *CHAQUE* modif de OpenSSL, la team GNOME doit rebuild son runtime, alors qu’OpenSSL n’est *PAS* son boulot. Et ensuite la team VLC doit rebuild son runtime, alors que GNOME n’est *PAS* son boulot.

            C’est exactement le même problème que pour Docker.
            Quand Alpine s’est prise sa RCE la semaine dernière sur son gestionnaire de paquets, c’est **TOUTES** les images basées sur Alpine qui ont du être reconstruites, par **TOUTES** les équipes utilisants Alpine (couchdb, postgresql, nginx & j’en passe), elles-mêmes déclenchant le rebuild de **TOUTES** les images basées sur une image utilisant Alpine (nextcloud, sentry…). Etc.
            Et toutes les équipes ont juste pleuré leur mère… pour une dépendance qui ne les regarde généralement même pas (un gestionnaire de paquets embarqué) !
            1 semaine après, si on a 1% du parc à l’abri, on est content…

            Debian aurait eu une faille dans DPKG, ben la team DPKG aurait release un truc, ça aurait été livré **PARTOUT** (et rétroporté) en 24h. Les équipes postgres, nginx, sentry ou nextcloud n’en auraient même jamais entendu parlé de leur vie et n’auraient strictement rien eu à faire.

            « mais satisfait, d’une distribution avec plus d’un millier de bénévoles qui doivent se taper quotidiennement un travail ingrat et difficile ? J’espère que t’as une petite pensée pour eux à chaque nouvelle mise à jour :D »

            Je suis moi-même mainteneur de plusieurs paquets, et mon travail est justement bien plus simple pour maintenir du Debian et du Arch que du Docker ou du FlatPack.
            Parce que je n’ai pas à me soucier de mes dépendances, les autres équipes les maintiennent pour moi !

          2. « Et donc si je veux utiliser une application GNOME qui n’a finalement besoin que de GTK, je te tape tout le runtime GNOME… GG… »

            Une application GNOME qui n’utiliserait que GTK+, ça n’existe pas. On appelle ça une application GTK+ et le runtime Freedesktop est suffisant.

            « Et pour les apps agnostiques, type VLC, je me tape mes libs en dur parce que sinon je me link avec le runtime GNOME *OU* le runtime KDE, et en plus je pleure parce que certaines de mes libs nécessaires ne sont pas toutes dispos dans un seul runtime (au pif libidn pour VLC qui n’est pas dans Freedesktop qui n’embarque que la version libidn2…). »

            Personne n’a dit que la situation serait parfaite d’entrée de jeu. Sous macOS ça leur a pris plusieurs années. Le souci actuel, c’est d’arriver avec une application déjà existante et de tenter de s’adapter après coup à des runtimes. Alors qu’avec le temps, les développeurs d’applications s’appuieront directement dessus et le problème sera réglé. Ou du moins, c’est comme ça que je vois les choses :D

            « Le projet **SDL** sort une nouvelle lib, mais c’est bien l’équipe **FreeDesktop** qui va devoir lurker en permanence pour une nouvelle SDL pour rebuild le runtime et faire les correctifs nécessaires. FreeDesktop devient mainteneur de la lib SDL… Et de l’ensemble de toutes les libs qu’ils embarquent ! »

            Et quelle est la différence avec une distribution ? Remplace « l’équipe Freedesktop » par Debian ou qui tu veux, et t’obtiens la même chose : « Le projet SDL sort une nouvelle lib, mais c’est bien Debian qui va devoir surveiller en permanence pour une nouvelle version pour reconstruire le runtime et faire les correctifs nécessaires. Debian devient mainteneur de la lib SDL. Et de l’ensemble de toutes les bibliothèques qu’ils embarquent ! »

            Si ça peut te rassurer, il n’y a pas qu’une personne pour maintenir un runtime. C’est toute une équipe derrière. Donc que t’aies cinq mainteneurs Debian pour cinq bibliothèques ou cinq mainteneurs pour un runtime, ça revient au même.

            « À **chaque** nouvelle version de n’importe quelle dépendance, c’est bien le numéro de version du runtime FreeDesktop qui va s’incrémenter… Et va donc exploser exponentiellement avec chaque livraison d’une dépendance… »

            Le numéro majeur qui désignera le runtime ne bougera pas. Pour GNOME, ça sera le même numéro de version que l’environnement. GNOME 3.30, donc runtime 3.30. Quant à Freedesktop, ils semblent être partis sur une numérotation de type année.mois, genre 18.08 pour un runtime sorti au mois d’août 2018. Après, pour la révision du paquet, le numéro peut être aussi grand qu’il a besoin, je ne vois pas trop où est le souci. Les utilisateurs ne le verront sans doute jamais.

            « Et non, ça va concerner l’ensemble des runtimes et applications qui embarquent au moins une dépendance tiers. Ils en deviennent automatiquement le mainteneur et doivent en suivre le cycle propre de release sous peine de mettre leurs utilisateurs en péril… »

            Ah, parce que tu crois que les distributions maintiennent leurs systèmes pour l’éternité ? Pour une Ubuntu non LTS, t’as quoi, neuf mois, ensuite c’est mort ? Debian et Fedora maintiennent juste la distribution en cours et plus ou moins la précédente. Il n’y a que pour les distributions d’entreprises, genre Ubuntu LTS ou CentOS / RHEL que c’est un peu plus long.

            Maintenant, je ne sais pas si t’en es conscient, mais la technologie Flatpak n’a pas été créée et poussée par deux guignols tout seuls dans leur coin sans rien demander à personne. Ça a été développé par Red Hat, avant de devenir un projet FreeDesktop, adopté par la plupart des distributions et environnements de bureau. Les équipes sécurité de ces mêmes distributions peuvent donc très bien collaborer à la maintenance des runtimes.

            « Non. Si Firefox jette l’éponge, ça n’empêchera pas la team Debian de OpenSSL d’aller mettre à jour la libssl sans l’impacter ni nécessiter la coopération de l’ensemble de la chaîne de dépendances. »

            Si un projet n’assure plus la maintenance, ça peut effectivement être repris « pour un temps » par les distributions. Installe une Debian 6 ou 7 et dis-nous si t’as encore droit à des correctifs sécurité, qu’on rigole un peu (même la version 8 semble avoir bénéficié de sa toute dernière mise à jour au mois de juin).

            « Et c’est EXACTEMENT le problème de FlatPack justement : si l’équipe d’un runtime ou d’une application jette l’éponge, sa libssl éventuellement embarquée n’est plus maintenue alors que l’équipe OpenSSL elle continue à livrer régulièrement. »

            Pour le moment, on ne connaît pas vraiment les durées de maintenance des différents runtimes. J’imagine que ça dépendra de l’investissement des équipes sécurité des différentes distributions / projets upstream. J’avais lu que ça serait tout de même plusieurs années.

            « À titre d’exemple, Gimp c’est 69 dépendances. Je parie que c’est a minima une nouvelle version du flatpack de Gimp ou de son runtime toutes les semaines du coup, alors que Gimp lui-même n’aura rien livré de nouveau. »

            Encore une fois, qu’il y ait 15 000 révisions du runtime, on s’en fout, ça ne télécharge que la différence (le delta). Donc s’il n’y a qu’une bibliothèque qui a changé, ça ne va bien évidemment, ni re-télécharger l’application, ni re-télécharger le runtime dans son intégralité. Ça fait des années que c’est comme ça. Les dépôts n’ont pas envie de payer des sommes astronomiques en bande passante.

            « Merci. Tu viens toi-même de défoncer FlatPack… Si c’est ABI compatible, un changement de lib n’impacte pas l’appli. Donc qu’on soit sous Debian ou FlatPack, c’est pareil, l’appli tourne. »

            Non, c’est juste toi qui limites bêtement la technologie Flatpak au seul principe de la distribution d’applications, en oubliant volontairement tout le reste (sécurité, reproductibilité…). Quant à la compatibilité des ABI, elle est descendante. Si t’as une application GNOME 3.22, elle continuera de fonctionner avec GNOME 3.30. Par contre, l’inverse n’est généralement pas possible. Donc, si je développe une application pour la dernière version de GNOME, sur ta Debian stable avec GNOME 3.22 (déjà quatre versions majeures de retard), tu ne pourras pas l’utiliser sans passer par Flatpak. En parlant des ABI, je faisais donc référence à la possibilité de pouvoir mettre à jour les bibliothèques dans certaines conditions sans que ça ne casse tout et sans qu’il y ait besoin de tout revérifier.

            « ie s’asseoir sur 50 ans de bonnes pratiques qui veulent qu’on ne casse JAMAIS les ABI sauf si on a une bonne raison de le faire ? »

            Ne va pas inverser les rôles. C’est toi qui me sors que la moindre mise à jour de bibliothèque nécessite d’absolument tout revérifier. Je rappelais justement l’existence des ABI, qui ne sont bien évidemment jamais cassées dans la même version d’un runtime. Et si ça devait arriver, ça serait fatalement dans la version suivante.

            « Non. Je ne connais que peu de logiciel qui soient actuellement incapables de tourner sur une Debian Stretch (voire Jessie) et sur du Buster ou du Arch. »

            Moi j’en connais plein. C’est juste que Tartampion 20 qui tourne sous Debian, ce n’est pas forcément la même chose que le Tartampion 25 avec des dépendances mises à jour, qui tournerait chez les autres. Donc oui, t’as bien accès à l’application Tartampion, mais la dernière version ne tournera peut-être pas.

            Et la question n’était pas de savoir si ça tournait bien sous Arch ou Debian Sid, mais sur N’IMPORTE QUELLE DISTRIBUTION DANS N’IMPORTE QUELLE VERSION. Je l’écris en majuscule pour bien que ça s’imprime bien. Les gens n’aiment pas les mises à jour système. 42% de la population mondiale utilise encore Windows 7 sortis en 2009. Tiens, amuse toi aussi à faire tourner des applications d’aujourd’hui sur un Linux de 2009 :)

            C’est aussi pour ça qu’Ubuntu LTS a autant de succès et qu’elle est autant conseillée. Cinq ans de prise en charge, donc cinq années où ils auront la paix.

            « Au pire, tu files les 2/3 commandes pour le builder et basta. »

            Mais bien sûr. Tu sors ça à un être humain normalement constitué, il te répond que ton Linux c’est sans doute très bien, mais que ce n’est pas demain la veille qu’il quittera son Windows / macOS. Ou pire encore, il fera comme les si nombreux linuxiens à avoir finalement abandonné notre système au profit d’un macOS, qui reste un système de type Unix, qui offre les mêmes possibilités, sans tous les emmerdements.

            « Tu ne sembles pas avoir compris le problème. La question n’est pas de savoir quand ou avec quelle volumétrie la maj sera faite, mais *PAR QUI*. »

            Ah, parce que tu ne t’es toujours pas renseigné par qui ? Tu critiques une technologie sans connaître ni son fonctionnement, ni les personnes qui sont derrière ? Donc le runtime GNOME est maintenu par GNOME, le runtime KDE est maintenu par KDE, quant au runtime Freedesktop, il est maintenu par le projet Freedesktop (merci Captain Obvious :)

            Maintenant, parmi les développeurs / mainteneurs GNOME, KDE ou Freedesktop, on retrouve des développeurs de toutes les distributions (Debian, Red Hat / Fedora, SUSE…). Ce sont des projets communautaires, donc tout le monde peut y contribuer. Y compris les équipes sécurité des différentes distributions, comme indiqué plus haut.

            « FlatPack est *CENTRALISÉ*, puisqu’une modif de OpenSSL impose à GNOME de livrer une nouvelle version qui impose à VLC de livrer une nouvelle version. Pour *CHAQUE* modif de OpenSSL, la team GNOME doit rebuild son runtime, alors qu’OpenSSL n’est *PAS* son boulot. Et ensuite la team VLC doit rebuild son runtime, alors que GNOME n’est *PAS* son boulot. Parce que je n’ai pas à me soucier de mes dépendances, les autres équipes les maintiennent pour moi ! »

            Tu n’as pas dû comprendre le principe de fonctionnement. Si OpenSSL corrige une faille, Debian met à jour son paquet, Freedesktop met à jour son runtime, et c’est tout. Ni GNOME, ni les applications qui l’utilisent n’ont besoin de mettre à jour quoi que ce soit.

    1. Le plus drôle, c’est que dans le même temps, des blogueurs comme Frederic Bezies ou Olivyeahh vont limite se plaindre que désormais, les distributions GNU/Linux fonctionnement incroyablement bien, au point de s’ennuyer et de regretter l’époque où il fallait sans cesse bidouiller dans le but d’obtenir un système complètement bancal, fait de bric et de broc, qui fonctionnait à peu près convenablement. Avec le risque, bien évidemment, que tout puisse s’écrouler à tout instant (j’exagère à peine) :D

      Mais qui sait – et là, je me permets d’émettre une hypothèque complètement ouf – peut-être qu’on a enfin un système stable qui juste marche, justement grâce à systemd, PulseAudio, NetworkManager, Wayland et autre Flatpak :D

      1. C’est tout à fait ça.
        Leur « fond de commerce » prend l’eau grâce à flatpak et autre techno simplifiant l’usage et la maintenance de linux.
        Bien dit.

      2. Puisque tu m’attaques, je réponds. Inutile de me balancer un « c’était mieux avant » en pleine tronche pour m’accuser d’être archaïque.

        C’est étrange le fait que tu balayes des faits qui ne collent pas à ton beau discours.

        Les runtimes des flatpak ? Le principe des bibliothèques partagées à la sauce 2018.

        Quand Wayland sera vraiment fonctionnel sur autre chose que Gnome, que des outils comme un enregistreur d’écran à la SimpleScreenRecorder sera disponible, tu me le diras aussi.

        Combien de logiciels supportent vraiment Wayland ? Côté environnement de bureau et gestionnaire de fenêtres ? Deux me viennent à l’esprit : Gnome et Sway.

        Va donc faire tourner un KDE sur Wayland. Bon courage.

        Pour l’ennui concernant les environnements de bureau, c’est qu’ils sont arrivés à maturité. Wayland et Flatpak ne sont pas encore mature…

        J’ai connu la période des plâtres frais pour PulseAudio ou systemd. J’attends que les plâtres soient sec pour Wayland.

        1. C’était gentiment ironique et je ne vous accuse de rien du tout. Ça m’amusait de voir deux personnes sortir que Linux était devenu limite chiant tellement tout fonctionnait bien (en gros), alors que dans le même temps, on entend plein de gens se plaindre depuis des années à l’apparition de chaque nouvelle technologie, sans jamais se dire que si la situation s’améliore au fil du temps, avec des distributions toujours plus simples, c’est peut-être aussi grâce à ces différents projets tant décriés.

          Alors oui, que ce soit Wayland ou Flatpak, tout n’est pas encore parfait. Mais ça tombe bien, personne n’est encore obligé de les utiliser l’un ou l’autre. Et il ne faudra pas non plus 107 ans pour que ça se stabilise enfin et que ça devienne réellement utilisable au quotidien. Par contre, de faire des critiques sans fondement (critiquer une mauvaise implémentation peut faire avancer les choses, tandis que critiquer les bugs de jeunesse quand la faute incombe plus à l’application qui ne s’est pas encore adaptée qu’à la technologie utilisée, ça n’apporte rien).

          Pour le partage d’écran, la capture d’écran ou l’enregistrement vidéo, la situation devrait grandement s’améliorer avec l’arrivée de PipeWire (qui sera logiquement présent par défaut dans Fedora 29). Par contre, il faudra ensuite que les différentes applications (TeamViewer, SimpleScreenRecorder…) tirent parti de ces nouvelles API.

  7. « Déjà, Linux est bien moins sécurisé que Windows ou macOS. Rien que de continuer d’utiliser X.org, ça permet à n’importe quelle application d’enregistrer les frappes clavier dans n’importe quelle autre application, ou de faire des captures d’écran en douce. »
    Sur windows, tu n’imagines même pas que l’on peut ouvrir des applications graphiques en douce. Obtenir des privilèges sans aucune protection à cause de fonctionnalité bidon. Enregistré toutes les touches tapés. Faire des screens en douce. Faire buger NTFS avec 0 droit. Etc.

    Linux est et restera plus sécurisé que Windows.

    1. Vu de loin, la sécurité de Windows semble pourtant s’être incroyablement améliorée ces dernières années. Et je parle bien évidemment de la dernière version, ignorant volontairement les inconscients qui continuent d’utiliser de vieilles versions d’il y a dix ou vingt ans (au mois de février, Windows 7, pourtant sorti en 2009, était encore utilisé par près de 42% d’utilisateurs).

      Maintenant, l’idée, c’est tout de même de tenter de faire mieux, puisque il y a toujours moyen de renforcer la sécurité (comme il y aura toujours de nouveaux types d’attaques et autres fourberies).

  8. Fédéric Béziers …. Le plus grand faux ami des linuxien …
    On ne convainc pas un convaincu … MDR
    Les FlatPacks et autres, perso je n’installe plus que ça quand je peux …
    Moins de souci, j’ai mes propres dépôts sur mon disque dur de SAV.
    Quand j’en ai besoin une simple copie et c’est installé …
    Pas besoin d’internet.
    Seul regret, ils ne sont pas encore umltiarchitecthure et rien encore sur arm qui pourtant à terme devrait écraser X86 … snif

  9. Je n’ai pas lu tous les commentaires, désolé donc si je répète quelque chose qui a déjà été dit.
    Personnellement, en tant que développeur, je trouve effectivement bien plus simple de créer un paquet Flatpak qu’un paquet par distribution.
    Par contre, tu fais erreur sur le compte d’Arch Linux et Manjaro : le premier n’a jamais eu pour but de s’adresser aux néophytes (il y a plein d’autres distribs qui le font déjà) et n’inclut absolument pas l’AUR par défaut (il faut installer différents paquets + un AUR helper pour que l’AUR soit réellement intégré). Et Manjaro n’est pas mis à disposition sous la forme d’une rolling release.

    1. Au contraire, je sais bien qu’Arch ne s’adresse absolument pas aux néophytes (désolé si je me suis mal exprimé). Mais j’ai déjà lu, ici ou sur Mastodon, que les Flatpaks n’avaient strictement aucun intérêt sur les distributions de type rolling release comme Arch Linux ou Manjaro (et comme dit, faut avoir confiance dans AUR).

      Donc, au-delà du fait que ce n’est effectivement pas le même public, je ne suis pas d’accord avec l’argument avancé, puisque ça limiterait l’intérêt des Flatpaks à la simple distribution d’applications stables, alors que ça pourrait tout aussi bien servir à des utilisateurs qui souhaiteraient tester des versions de développement pour contribuer au bêta test et ainsi améliorer la qualité des versions finales. Ou pour les développeurs eux-mêmes, qui peuvent disposer d’un environnement de développement avec des bibliothèques elles-mêmes en cours de développement, sans perturber pour autant la stabilité du reste de leur système. Ou encore la possibilité d’utiliser facilement de vieilles versions stables, en parallèle de la dernière version généralement proposée par Arch / Manjaro.

      Mais c’est cool de voir des développeurs manifester leur intérêt :)

  10. Le flatpak , pourquoi pas , parce bon , joué les DJ quand on installe une Débian 9.5 complète , c ‘est au bas mot : un cauchemar . Pour la sécurité . GNU /Linux est un OS de travail , donc pour les stations de travail et les serveurs , pas pour le grand public . GNU/Linux , n ‘est PAS pour tout le monde , le commun à MacOs X point .

  11. Salut,

    Perso j’aime bien ce genre de technologie, mais pour des utilisations spécifique, comme pour des tests d’applications, ou alors du déploiement. Personnellement j’adore docker, qui est un peu dans le même genre, mais plus orienté serveur.

    Le problème de ces technologies, c’est les dépendances qui ne sont plus géré comme sur une distribution.

    Tu prends VLC par exemple, il utilise le runtime org.kde.Sdk 5.11 (avec plusieurs extension), installe une bonne 100ène de librairie (pour la plupart en provenance de debian). Sachant en plus que le runtime org.kde.Sdk est basé sur le SDK org.freedesktop.Platform 1.6 (sachant qu’on est à la 1.8).

    Donc le mec qui maintiens le flatpak VLC, est dépendant du runtime org.kde.Sdk qui lui même est dépendant org.freedesktop.Platform. C’est là qu’on voit bien la différence entre les dévs, les intégrateurs et les mainteneurs. Le mieux pour ce genre de chose, est de pouvoir maitriser toute la chaine, et pas seulement le dernier maillon.

    Comme pour docker, je pense qu’on trouvera bientôt de tout et n’importe quoi (surtout n’importe quoi), sur les hubs.

    Pour conclure, je pense que peux importe la distribution utilisé, 95% des besoins sont gérer par celle-ci et leur communauté, pour les 5% restant, je ne pense pas que ce soit Mme Michu, mais il y a effectivement les sources, voir les flatpak & co.

  12. « Une application GNOME qui n’utiliserait que GTK+, ça n’existe pas. On appelle ça une application GTK+ et le runtime Freedestop est suffisant. »

    Ou pas. Toujours pas de libidn dedans, et tu aurais le problème pour Qt (il faudrait un runtime QT non KDE, ie 1 runtime = 1 lib ?)

    « Remplace « l’équipe Freedesktop » par Debian ou qui tu veux, et t’obtiens la même chose : « Le projet SDL sort une nouvelle lib, mais c’est bien Debian qui va devoir surveiller en permanence pour une nouvelle version pour reconstruire le runtime et faire les correctifs nécessaires. Debian devient mainteneur de la lib SDL. Et de l’ensemble de toutes les bibliothèques qu’ils embarquent ! »

    Sauf que Debian est prévu pour être décentralisé, et sinon les freeze tous les X mois histoire de timestamper un peu les choses, un changement dans une lib Debian n’implique pas de changement de version de Debian, alors qu’un changement dans une lib FreeDesktop implique un changement de version du runtime FreeDesktop.
    Idem en terme de livrable, la team OpenSSL n’a accès qu’à ses propres paquets, et ne peut pas aller modifier ceux des autres, alors qu’un membre de FreeDesktop en charge de OpenSSL peut (et doit) aller y modifier n’importe quoi (dont le n° de version).

    « Le numéro majeur qui désignera le runtime ne bougera pas. Pour GNOME, ça sera le même numéro de version que l’environnement. GNOME 3.30, donc runtime 3.30. Quant à Freedesktop, ils semblent être partis sur une numérotation de type année.mois, genre 18.08 pour un runtime sorti au mois d’août 2018. Après, pour la révision du paquet, le numéro peut être aussi grand qu’il a besoin, je ne vois pas trop où est le souci. Les utilisateurs ne le verront sans doute jamais. »

    Sauf qu’avoir un numéro mineur qui augmente de 100 à la semaine, ça va vite devenir le bordel, sans parler du souci avec les dépendances, qui vont du coup se mettre à binder uniquement sur le majeur… Et donc perdre l’argument de stabilité (la diff entre 3.30.0 et 3.30.100 sera énorme avec 100 versions de bibliothèques d’écart entre les 2).

    « Ah, parce que tu crois que les distributions maintiennent leurs systèmes pour l’éternité ? »

    Ok, donc tu discrédites aussi toi-même ton argument de stabilité en fait.
    Oui effectivement, ton runtime va être déprécié avec le temps et ne devrait plus être utilisé passé un certain délai. Ta garantie de pérénité des applications vient donc de sauter.

    Et tout comme il est toujours possible de faire tourner du PHP 5.3 sur une Debian Etch en prod, c’est tout sauf conseillé et on devrait plutôt shooter de telles apps merdiques plutôt que de mettre en place un système autorisant de telles horreurs.

    « Ça a été développé par Red Hat, avant de devenir un projet FreeDesktop, adopté par la plupart des distributions et environnements de bureau. »

    Argument d’autorité. Ce n’est pas parce que c’est poussé par Red Hat que c’est une bonne idée. Tout comme Docker en prod est une pure hérésie, pourtant encensée par tout le monde ou presque.

    « Si un projet n’assure plus la maintenance, ça peut effectivement être repris « pour un temps » par les distributions. Installe une Debian 6 ou 7 et dis-nous si t’as encore droit à des correctifs sécurité, qu’on rigole un peu (même la version 8 semble avoir bénéficié de sa toute dernière mise à jour au mois de juin). »

    Je n’ai jamais dis que Debian 6 était maintenu. Justement, je dis qu’il en sera de même avec les runtimes tout péraves qui vont trainer partout et qu’on arrivera jamais à shooter « parce qu’on a encore trop d’applications qui en dépendent et qu’on a créé un monstre qui incite encore moins à porter ses applications sur un environnement décent »

    « Encore une fois, qu’il y ait 15 000 révisions du runtime, on s’en fout, ça ne télécharge que la différence (le delta). Donc s’il n’y a qu’une bibliothèque qui a changé, ça ne va bien évidemment, ni re-télécharger l’application, ni re-télécharger le runtime dans son intégralité. Ça fait des années que c’est comme ça. Les dépôts n’ont pas envie de payer des sommes astronomiques en bande passante. »

    Et encore une fois, le problème n’est pas la bande passante et le stockage, ça je m’en fout. Le problème est que tu vas avoir 40.000 versions d’un runtime à maintenir, parce que tu vas avoir 40.000 applications différentes à s’en servir.
    Et que soit à chaque version de runtime tu portes **TOUTES** les apps dépendants de la version précédente (hint : ça n’a jamais fonctionner sous Docker, cf RCE Alpine), soit tu te tapes une longue traîne d’applications totalement pas sécurisées pendant des plombes.
    Et alors que Debian permet de pinner sur une majeur d’une lib, si tu fais la même chose avec FlatPack tu casses ta belle garantie de pérénité.

    « Ne va pas inverser les rôles. C’est toi qui me sors que la moindre mise à jour de bibliothèque nécessite d’absolument tout revérifier. »

    Justement non. Debian ne demande justement pas de revoir toutes les applications utilisant OpenSSL pour fixer **GLOBALEMENT** un problème de sécu.
    Parce que toutes les applications du système bénéficieront automatiquement du fix de sécurité. Le fix est implicite pour les applications.
    Alors que FlatPack imposera à chaque mainteneur d’applications de corriger leur dépendances au runtime pour profiter du fix. Le fix est explicite et demande une action manuelle de la part de **TOUS** les mainteneurs dépendants.

    « Les gens n’aiment pas les mises à jour système. 42% de la population mondiale utilise encore Windows 7 sortis en 2009. »

    C’est même pour ça que je me retrouve avec mes serveurs saisis, 1 an de galère juridiques et 2.000€ de frais de justice parce qu’un connard n’a pas su mettre à jour son Microsoft Office et son Windows.
    Et toi tu veux faire la même chose à des niveaux industriels. Graver dans le marbre que les maj systèmes c’est le mal et qu’il ne faut pas les faire parce que YOLO. GG.

    « Tiens, amuse toi aussi à faire tourner des applications d’aujourd’hui sur un Linux de 2009 »

    « Tu n’as pas dû comprendre le principe de fonctionnement. Si OpenSSL corrige une faille, Debian met à jour son paquet, Freedesktop met à jour son runtime, et c’est tout. Ni GNOME, ni les applications qui l’utilisent n’ont besoin de mettre à jour quoi que ce soit. »

    Pas Debian. La team OpenSSL uniquement. Qui n’a en charge *QUE* cette librairie. Le paquet FreeDesktop n’aurait pas de travail à faire.
    Alors que oui, FreeDesktop va devoir mettre la main au runtime à chaque modif de OpenSSL…

    Et si, Freedesktop va devoir mettre à jour son runtime pour pointer sur le runtime OpenSSL nouvelle version. Et Gnome son runtime pour pointer sur le bon runtime Freedesktop. Etc.

  13. Pour moi Flatpak correspond à ré-inventer la roue une autre fois… Il existe des dizaines de gestionnaire paquets mais comme aucun ne convient hop un nouveau… Et pour pas faire chier les autre les paquets ne s’installent pas au même endroit.

    Les runtime ne sont que des groupes de paquets ni plus ni moins. Cela n’a donc aucun intérêt à part télécharger plus de dépendances inutiles.

    De plus le principe d’une distribution c’est d’avoir un ensemble de paquets cohérent entre eux. Si on veut vraiment utiliser flatpak une distribution flatpak peut être une solution. C’est d’ailleurs le but de Red Hat il me semble. Comme Ubuntu avec Snap.
    Mais l’utilisation de plusieurs gestionnaires de paquets en même temps posent problème. Il suffit de vu le nombre de problème que pose pip ou tout autre gestionnaire de paquet spécifique à un langage.

    PS : Pour un blog libre utiliser le captcha de Google… Pour info j’ai du désactiver Privacy Badger pour poster le message…

    1. Il ne te reste plus qu’à demander aux développeurs des gestionnaires de paquets DEB et RPM pourquoi ils n’ont pas permis l’isolation des applications, l’installation d’un même paquet sur l’ensemble des distributions (sans avoir à se préoccuper des dépendances), garanti un fonctionnement de l’application à l’identique, permis la reproductibilité…

      Et j’imagine qu’ils te répondront que ce n’était pas possible sans tout reprendre depuis zéro. En gros, créer un tout nouveau système. Oh, wait… :D

  14. C’est con hein, mais Flatpack me parait être un excellent exemple d’application de ce que raconte Tris dans [son billet](https://www.zdnet.fr/blogs/zapping-decrypte/vous-ne-savez-toujours-pas-vous-servir-de-l-informatique-39873329.htm).

    90 % des utilisateur⋅ices (à la louche) ne savent pas se servir d’un ordinateur. Il me semblait que les initier à Linux, c’était justement les initier à l’informatique. Donc remplacer un écosystème qui juste marche par un autre qui lui aussi juste marche, sans en comprendre le fonctionnement basique, je doute que ça aide la population à dompter l’outil informatique.

    Alors oui, quitter une merde propriétaire pour une merde à base libre (et encore, si c’est pour utiliser les flatpacks Skype et consort… :-°), ça part d’une bonne intention. Mais clairement je trouve ça con parce qu’au passage on oublie toute la partie qui vaut la peine d’être expliquée aux voisin⋅es.

    Et puis y’a plein de raisonnements dangereux. Typiquement, l’utilisation des sandbox. Whoua, un soft peut pas utiliser la webcam et le micro si je l’autorise pas. Super, je garde le contrôle de ma vie privée. J’installe le flatpack Skype. Tu sens venir la quenelle ? Un faux sentiment de sécurité est ce qu’il y a de pire en terme de sécu.

    À trop vouloir aseptiser l’utilisation d’un PC, on fini par créer une séparation de plus en plus marquée : ceux qui utilisent des trucs qui juste marchent, et ceux qui savent bidouiller leur système. Alors que l’initiation aux systèmes Gnunux avait pour objectif de réduire ces différences, les premiers finissent dépendants des seconds…

    1. Donc, si on résume, si l’utilisateur est capable de se rendre dans sa logithèque et qu’il installe un paquet issu de sa distribution, il maîtrise l’outil informatique. Mais s’il installe un Flatpak, c’est un gros noob. S’il compile manuellement les sources d’une application en cours de développement pour contribuer au bêta test (après avoir bêtement copié-collé des commandes trouvées sur le net), là encore, il maîtrise l’outil informatique. Mais s’il installe directement le Flatpak pour gagner du temps à contribuer à ce même bêta test, c’est encore une fois un gros noob (doublé d’une grosse feignasse, qui aurait dû en chier à chacune de ses actions).

      Et le meilleur pour la fin, s’il utilise une certaine distribution, qu’il passe par les paquets de cette dernière, qu’il rencontre un bug dans une application, qu’il se décide à faire un rapport de bug… mais qu’en face, le développeur n’arrive pas à reproduire le bug, il maîtrise tout de même l’outil informatique. Mais si un utilisateur utilise le Flatpak, qui garanti un fonctionnement à l’identique chez le développeur et qu’il leur est donc plus simple de reproduire le bug puis de le corriger, là encore, mon dieu, ça aura vraiment été un gros noob :)

      Ça se trouve, l’utilisateur de Flatpak sera bien plus maître de son outil et ses contributions bien plus utiles :)

      Quant à Skype, qui sait, peut être que l’utilisateur ne se sert que des discussions textuelles. Ou uniquement des appels vocaux, sans avoir besoin de la webcam. Maintenant, ça reste une application propriétaire. On lui accorde la confiance qu’on veut bien lui accorder. Mais même si tout n’est pas parfait, je continue de penser que oui, on garde bien plus de contrôle qu’avec le paquet traditionnel où on lui donne accès à tout sans pouvoir choisir.

      Le fait d’utiliser des Flatpaks n’empêche en rien de s’intéresser au fonctionnement de son système ou de chercher à maîtriser son outil (j’irai même jusqu’à dire que plusieurs intervenants durant cette discussion n’ont sans doute jamais cherché à s’intéresser à cette technologie : comment ça a été architecturé, quelles sont les possibilités offertes, ses limites, les plans à venir… tout en ayant tout de même un avis sur la question).

      1. «  Mais si un utilisateur utilise le Flatpak, qui garanti un fonctionnement à l’identique chez le développeur et qu’il leur est donc plus simple de reproduire le bug puis de le corriger »

        Docker disait pareil. « Si ça marche en dev, ça va marcher en prod ». On a vu ce que ça a donné.
        AppImage disait pareil… Et puis https://forum.cozy.io/t/erreur-suite-a-la-mise-a-jour/5234/3?u=aeris.

        Parce que tu as TOUJOURS un truc différent chez tes utilisateurs.
        Ne serait-ce que le kernel ou la libc. Qui nécessite de toute façon d’avoir à maintenir X runtimes différents (et donc X comportements différents) fonction de la distrib d’accueil…

  15. Je n’ai pas réellement d’argument contre, ni même pour.
    Mais… Flatpak me semble très mauvais sur pleins de points…

    J’ai vu plusieurs fois l’argument de l’espace disque ressortir, et je voudrais donner mon point de vue suer le sujet:
    > Un système Linux ne prend pas 10 Go, si c’est le cas il est mauvais et beaucoup trop lourd, le système ne doit avoir besoin que de 2 à 8 Go pour fonctionner.
    > Je n’ai pas 50€ à mettre dans un disque dur, quand bien même mon ordinateur le supporterait
    > « Les vieux ordinateurs ne servent plus à rien » Ce n’est pas vraiment dans l’esprit de Linux ça, Linux est fait pour rester compatible avec le maximum de machines, si une distribution ne tourne pas sur ma machine, je la supprime de la liste des distributions disponibles pour mon utilisation. Un linux doit pouvoir fonctionner sur un système minimal avec 8Go de disque et moins d’un demi-giga de ram.

    J’ai vu aussi l’argument de la portabilité, et là encore il joue contre, de mon point de vue.
    > Un flatpak 64 bits peut-il tourner sur du 32 bits? et inversement?
    > N’avoir à créer qu’un paquet ne donnerait-il pas envie aux développeurs de ne plus partager leur code?
    > Un paquet n’est pas portable si il à été prévu ou adapté pour une autre distribution que la mienne, si ton paquet à besoin de systemd, moi je suis avec openrc et je ne veux pas de sytemd, openrc fournit les alternatives et les remplacements nécessaires, je ne veux pas avoir à installer systemd, même dans un bac à sable.

    L’argument du bac à sable qui sécurise, est faux pour moi.
    > Si un flatpak demande accès à mes fichiers, je le lui donne et il me chiffre tout… Il à eu accès à mon home, il l’a demandé, et je lui ai donné comme le ferait tout utilisateur standard et non-méfiant, bravo la sécurité! C’est ça? C’est un scénario probable et même je n’ai aucuns doute sur le fait que je puisse le faire en moins d’une heure…
    > Mettre dans un bac à sable c’est bien beau mais… si je demande un droit root, je l’ai? et si je demande un accès en chmod rwx à tous les fichiers de /dev je l’ai aussi?

    Effectivement ça simplifie la vie aux devs, je ne nie pas cela, c’est même d’une simplicité génialissime, mais si je veux garder le contact avec les distributions qui n’ont pas flatpak? je fait comment, je fait d’autres paquets?

    On l’a déjà vu avec d’autres systèmes et d’autres moyens de ce simplifier la vie comme ça, ça ne marche pas, c’est tout.
    Si tel distro à son gestionnaire de paquet elle ne peux pas fonctionner avec un autre gestionnaire de paquet, et même si les paquets ne s’installent pas aux mêmes endroits… Pourquoi j’installerais gcc deux fois? et pourquoi j’aurais besoin de tripler le poids de mon système car tel flatpak demande plus de librairies?

    Non, si flatpak débarque sur Archlinux je le désinstalle et le vire des dépendances, Flatpak est une merde sans nom, immonde…

    Certe l’idée est géniale, mais elle n’est pas compatible avec le fonctionnement actuel des distributions Linux

    PS: Virez-moi ce Captcha de merde! Je ne peux même pas poster sans désactiver les protections de firefox.

    1. « Les vieux ordinateurs ne servent plus à rien. Ce n’est pas vraiment dans l’esprit de Linux ça, Linux est fait pour rester compatible avec le maximum de machines »

      Non, ça c’est juste l’avis de certains linuxiens (qui en font malheureusement une généralité). Tout le monde n’utilise par Linux dans l’unique but de pouvoir recycler de vieilles brouettes. Personnellement, j’ai un i7 avec 16 Go de RAM. Tant que mon environnement est fluide et que je ne ressents pas le moindre désagrément, l’utilisation des ressources m’importe peu. Après, bien évidemment, plus c’est optimisé et léger, mieux c’est. Ça permet à un plus grand nombre de personnes de pouvoir en profiter dans de bonnes conditions. Mais ce n’est clairement pas sur ça que je vais me focaliser.

      « Si un flatpak demande accès à mes fichiers, je le lui donne et il me chiffre tout… Il à eu accès à mon home, il l’a demandé, et je lui ai donné comme le ferait tout utilisateur standard et non-méfiant, bravo la sécurité! »

      Tu peux avoir exactement le même souci avec un paquet traditionnel qui incluerai un malware et qui serait uploadé sur un dépôt communautaire (ou sur un dépôt principal après qu’un développeur se soit fait pirater son compte personnel et ses clés, ce qui est déjà arrivé). Encore une fois, le problème est humain et ne concerne pas la technologie utilisée. À savoir, comment et par qui est géré le dépôt. Est-ce que les paquets subissent ou non un contrôle avant d’être mis à la disposition du public ?…

      « Certe l’idée est géniale, mais elle n’est pas compatible avec le fonctionnement actuel des distributions Linux »

      Et ça tombe bien, non seulement personne ne t’oblige à utiliser systemd, NetworkManager, PulseAudio, Wayland, Flatpak… mais t’as raison, on pouvait aller plus loin en repensant la conception même des distributions. Ce que fait d’ailleurs Fedora avec le projet Silverblue, qui consiste majoritairement à utiliser Flatpak et rpm-os-tree pour gérer les paquets permettant une meilleure isolation des composants et une plus grande fiabilité du système (merci Renault :p)

      Certains trouveront ça génial, quand d’autres détesteront. Mais c’est ça le libre. Le choix de pouvoir créer ou d’utiliser ce que l’on veut, comme on l’entend.

  16. Pourquoi les gens qui acceptent que Crandy Dush ai accès à trouzemille paramètres sur leur smartphone (pour que l’app juste marche) se diraient « tiens, je vais refuser la caméra pour Skype » ? Alors qu’on peut tout simplement leur dire que des alternatives fonctionnelles existent ?

    Le principe, c’est d’expliquer à l’utilisateur que les systèmes fermés c’est pas tip-top concernant les libertés, la vie privée, etc., et que du coup c’est peut être bien de se réapproprier les outils. TOUS les outils. Pas juste la distro sur laquelle on va faire tourner le client Netflix, Skype, Discord, Chrome, la suite Google, et j’en passe.

    Of course, ça va pas se faire du jour au lendemain, mais quand t’as besoin d’installer un soft qui n’est pas dans les dépôts officiels (ie pas dans le store GUI), on t’explique qu’il va falloir regarder de plus près comment ça fonctionne. Et tu apprends. Tu apprends à faire ta tambouille, à aller bidouiller, peut-être même à aller casser puis réparer ta distro. C’est comme ça que t’apprends à faire un rapport de bug, etc. Y’a 5 ans, j’avais jamais touché à autre chose que Windows. Aujourd’hui je suis capable de monter une install d’Arch en 30 minutes. Si tout était allé sur des roulettes depuis ma première install de Mint, je ne saurais pas le quart de ce que je sais faire actuellement.

    Remarques en vrac :
    – La diversité de l’écosystème Gnunux fait sa force. Peut-être aussi sa faiblesse, mais y’a clairement plus d’avantages que d’inconvénients.
    – Faire ses màjs une fois tous les 36 du mois, sous prétexte que c’est chiant, ça aide pas l’utilisateur à avoir une hygiène numérique propre.
    – Les apps qui réinstallent la roue à chaque installation, ça me gonfle (coucou Electron). Flatpack a l’air un chouille mieux. Pas de beaucoup.
    – Mélanger les gestionnaires de paquet, ça a toujours foutu la merde (coucou pip, etc.). Ce qui m’amène à :
    – Dalan a pas tort. Si tu veux du flatpack, tu fais une distro 100 % flatpack. Et tu gères tes merdes de ton coté (coucou les CVE à corriger sur les x runtimes, dont y seront plus maintenus activement).
    – Je comprends pas comment tu peux avoir des sandbox cloisonnées si tu dupliques pas les binaires de bibliothèques dans la RAM.

    « Quand je vois les trucs de dingue qu’on arrive à faire aujourd’hui, j’hallucine complètement. »
    Yep, j’hallucine quand je vois que mon CPU est trouzemille fois plus rapide que celui d’il y a 20 ans, mais que ça rame toujours autant.
    http://www.commitstrip.com/fr/2015/08/28/murphys-take-on-moores-law/

    « Deux cents distributions, deux cents fois le même travail et les mêmes vérifications ? »
    C’est peut-être ce qui fait que y’a deux-cent fois moins de chances de laisser passer une merde ?

    « Sans parler des nombreux patchs que les distributions peuvent appliquer, dans le but de modifier volontairement le comportement de l’application »
    « Et j’en profite pour rappeler que l’utilisation du dépôt Flathub n’est en rien obligatoire, certaines distributions ayant déjà créé leur propre dépôt Flatpak. »
    Quand le raisonnement se casse la gueule tout seul ;)

    « j’irai même jusqu’à dire que plusieurs intervenants durant cette discussion n’ont sans doute jamais cherché à s’intéresser à cette technologie »
    En effet, je ne fais que réagir à la manière dont tu présentes la chose.

    Il se fait tard, je développerai plus demain

  17. Le souci c’est que flatpak est sympa pour tester une application mais si on multiplie les runtime c’est vite consommateur de données. Si l’application utilise un vieux runtime ce vieux runtime sera-t-il maintenu (fix de sécurité)? Saurais-je que mon application utilise un runtime non sur? S’il faut toujours avoir la dernière version du runtime cela n’avancera a rien car l’application devra se mettre à jour a chaque nouvelle version du runtime. Android avec les apk utilisent exactement les même fonctionnement d’isolation et de demande de permission et pourtant on voit que Android est le système le plus troué de la planète et le moins maintenu à jour. Il y a même des gens qui change leur téléphone juste parce qu’ils ne peuvent plus installer d’applications (un smartphone classique entrée de gamme c’est 8go de stockage) et ne savent pas réinitialiser leur appareil.
    Tout comme beaucoup de gens on vu dans docker l’outil miracle qui isole les processus et évite les failles, simplifie les mise a jours… Ben actuellement on commence à voir beaucoup de services qui font marche arrière. Ça supprime des soucis mais en créer d’autre ce n’est pas magique. La sécurité ok mais quid des flatpak non maintenu a jour? Comment expliquer la différence entre un flatpak sur et un pas sur? Surtout si on rabâche que flatpak évite les soucis de sécurité. LE pire ennemi de la sécurité c’est la confiance au système. Il existe des mondes ou la sécurité est primordial et même dans ces univers c’est la misère. Oui chaque version doit prouver qu’elle n’introduit pas de faille mais faire ça prend du temps du coup si une faille arrive sur un système déjà existant le mettre à jour est extrêmement lent puisque les nouveaux correctifs doivent être validé (je parle de soft ou un crash/bug peu tuer une personne).
    De plus l’espace de stockage est pas si illimité que ça 250Go c’est rien pour stocker des photos a moins de ne jamais rien faire sur son pc. Une Fedora 28 avec quelques applications c’est 25Go à peu près, il fait une partition de 50go pour le système ça veut dire uniquement 200Go de stockage autant dire que c’est rapide a remplir en photo et vidéo (un pc ne sert pas que a faire tourner des applis il stocke des données aussi). LE modèle le plus vendu cet été et début rentré sur Amazon c’est ça https://www.amazon.fr/Acer-Chromebook-CB3-431-C64E-Celeron-Graphics/dp/B01HT9ITY8/ref=as_li_ss_tl?_encoding=UTF8&psc=1&refRID=9VTK2RRNSADVE4M2XPA5&linkCode=sl1&tag=cnefra-21&linkId=f40a330e1737d3e5edca66ca7a5f77f2&language=fr_FR le truc il possède 32Go au total.
    Redhat est un bon sponsor pour le produit mais pas forcément pour les utilisateurs ils ont la mauvaise réputation de ne pas prendre en compte les besoins des autres et d’imposer leur point de vue coté usage informatique.
    Donc c’est pratique, mais il ne faut pas en abuser et le considérer comme révolutionnaire. Tout comme il faut pas négliger ses qualités il ne faut pas cacher non plus ses défauts sinon on verra le même phénomène que docker et finir avec ça https://www.youtube.com/watch?v=8oDjCvFrwgU. Comme dit l’adage quand on a un bon marteau tous les problèmes sont des clous donc ne tombons pas dans le panneau et gardons nos tournevis de côté ils nous serviront plus tard.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *