• # Faites des paquets Debian pour vos applications

    Posté par  . Évalué à 2 (+2/-1). Dernière modification le 23/11/21 à 17:41.

    Et pas que Debian les rpm ça marche aussi.

    mais des paquets pour les dépôts des distributions.

    • [^] # Re: Faites des paquets Debian pour vos applications

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      Il est vraiment très simple de faire un paquet Debian de base, certes pas conforme 100% à la qualité Debian, mais qui marche. En gros, un tar avec les fichiers, un tar de contrôle et hop, les deux dans un ar. C'est tout. C'est bien plus simple qu'on ne le croit avant d'en faire un.

      PS : évidement pour les cas simples, soit 99% des paquets. Si vous voulez du debconf avec paramétrages… C'est un peu plus complexe.

    • [^] # Re: Faites des paquets Debian pour vos applications

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0). Dernière modification le 23/11/21 à 18:45.

      Mais dans la pratique, ce n'est pas aux développeurs de faire eux-mêmes leurs paquets pour chaque distro, si ?

      (je précise avant qu'on me pose la question : je suis plutôt fan de Flatpak et sceptique vis-à-vis de ses détracteurs, mais j'ai voulu relayer ce point de vue qui m'avait l'air technologiquement mieux motivé… à l'aune de mes maigres connaissances en la matière. Je vous prie ainsi de croire à la sincérité de ma question ci-dessus.)

      • [^] # Re: Faites des paquets Debian pour vos applications

        Posté par  (site Web personnel) . Évalué à 7 (+5/-0). Dernière modification le 23/11/21 à 19:31.

        Mais dans la pratique, ce n'est pas aux développeurs de faire eux-mêmes leurs paquets pour chaque distro, si ?

        Non. Y en a qui le font, mais c'est une minorité et en général, c'est 2 boulots séparés, parce que ça prends du temps. Parfois, tu as la même organisation qui fait le logiciel et le paquet (éditeur logiciel, logiciel propre à une distribution), mais c'est tout.

        Un point du débat que je pige pas, c'est qu'on rajoute une dichotomie la ou il n'y a pas lieu d'en avoir une.

        Personne ne force à utiliser des flatpaks, tout comme personne ne force à utiliser des rpms, sauf si personne ne fait le boulot.

        Mais si personne ne fait le boulot pour avoir le logiciel dans le format qu'on veut, c'est pas la faute des gens qui font le travail qu'on veut pas. C'est la faute des gens qui ne font rien.

        • [^] # Re: Faites des paquets Debian pour vos applications

          Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

          Surtout pour moi le principal problème dans le débat aussi c'est qu'en fait : aucune solution n'est parfaite par conception.

          On ne peut pas avoir X distro différentes, avec leur tambouille interne, avec des projets qui ne collaborent pas spécialement pour garantir une compatibilité ascendante parfaite (contrairement à ce qui est dit dans l'article : ces problèmes existent toujours en nombre) avec des dépôts qui permettent de mettre à jour une bibliothèque une fois tout en permettant d'installer la version qu'on veut de chaque application car on veut facilement installer le dernier Firefox même s'il est pas dispo dans ma distro.

          Flatpak, Snap et autres répondent à des besoins et sont complémentaires des dépôts. L'un n'est pas meilleur qu'un autre, ça dépend du contexte, et surtout aucune solution ne permet de répondre convenablement à tous les envies. Et on pourra faire les efforts qu'on veut, la flexibilité de Flatpak et Snap (au détriment des ressources par exemple) ne pourra jamais être atteinte par les dépôts. Mais l'efficience des dépôts ne sera jamais atteint pas Snap et Flatpak par essence non plus.

          • [^] # Re: Faites des paquets Debian pour vos applications

            Posté par  . Évalué à 2 (+1/-0). Dernière modification le 23/11/21 à 22:27.

            Je pense qu'en effet certaines distros iront vers une généralisation du flatpak sur ce qui est graphique. Et d'autres resteront sur le modèle actuel. Au moins ça donnera de vrais différences entre chacunes et ça simplifiera le choix parce qu'aujourd'hui pas mal de distribs sont un peu toutes les mêmes.

        • [^] # Re: Faites des paquets Debian pour vos applications

          Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

          C'est la faute des gens qui ne font rien.

          Si un logiciel n'est pas empaqueté, est-ce une raison pour accuser les autres ?

      • [^] # Re: Faites des paquets Debian pour vos applications

        Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

        IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.

        Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?

        Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…

        cf Linux Distribution Timeline

        Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?

        DEB:

        • Debian ?
        • Ubuntu ?
        • Linux Mint ?
        • ..?

        RPM:

        • RedHat ?
        • CentOS ?
        • Fedora ?
        • ..?

        Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".

        Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
        Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
        Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.

        Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:

        If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.

        Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.

        Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?

        Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).

        https://link-society.com - https://kubirds.com

        • [^] # Re: Faites des paquets Debian pour vos applications

          Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

          Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.

          Oui, et c'est complexe, ils maitrisent aussi globalement toute la chaine et peuvent contraindre les employés à cela. Bon courage pour forcer Linux, glibc, systemd, Firefox, GTK, KDE, Qt, etc de suivre la même politique à ce sujet.

          D'ailleurs parfois la compatibilité casse un peu (mais bon, pas le choix), et ils tentent de s'extirper de Win32 mais migrer cet écosystème ne se fera pas en une journée et pas mal de développeurs sont contre (parfois pour de bonnes raisons, l'API de remplacement reste limité).

          Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).

          C'est ce que veut faire Fedora Silverblue aussi. J'ai fait des articles à ce sujet. ;)

        • [^] # Re: Faites des paquets Debian pour vos applications

          Posté par  . Évalué à 3 (+0/-0).

          Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?

          Tu as oublié les versions aussi. Uniquement la Debian stable, la oldstable ? RHEL 7, 8 ? Sans compter les tests avec les différentes configuration matériel.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Faites des paquets Debian pour vos applications

            Posté par  . Évalué à 2 (+0/-0). Dernière modification le 24/11/21 à 11:55.

            Sans compter les tests avec les différentes configuration matériel.

            Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.

            Uniquement la Debian stable, la oldstable ? RHEL 7, 8 ?

            Je trouve pas ça très loyale. Oldstable ne fait que des mises à jours de sécurité. Je n'ai jamais vu de packaging snap/appimage/flatpack faire autre chose que des mise à jour de leur versions (et pas de leurs dépendances par exemple). Ça correspond donc à suivre la version principale (stable ou LTS selon les distributions ou les volontés des mainteneurs) des distributions.

            Il y a toute une partie de la simplicité de ses packagings qui ne vient pas du fait qu'ils ont corrigé des difficultés, mais qu'ils ne sont tout simplement pas adressé.

            • [^] # Re: Faites des paquets Debian pour vos applications

              Posté par  . Évalué à 3 (+0/-0).

              Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.

              Non, mais le runtime est le même sur les distributions. Tu ne dois pas faire le test avec n matériel x m distributions.

              Je trouve pas ça très loyale. Oldstable ne fait que des mises à jours de sécurité. Je n'ai jamais vu de packaging snap/appimage/flatpack faire autre chose que des mise à jour de leur versions (et pas de leurs dépendances par exemple). Ça correspond donc à suivre la version principale (stable ou LTS selon les distributions ou les volontés des mainteneurs) des distributions.

              Oui, mais si tu dois faire un paquets sur oldstable et sur stable, tu dois bien testé deux fois. Je ne vois pas ce que tu veux dire avec ces mises à jour de sécurité. Ou alors, tu veux dire que tu ne mets plus à jour sur oldstable, mais ça ne correspond pas à ce qui est fait lorsqu'un logiciel est distribué par les développeurs et pas par les distributions.

              Il y a toute une partie de la simplicité de ses packagings qui ne vient pas du fait qu'ils ont corrigé des difficultés, mais qu'ils ne sont tout simplement pas adressé.

              Je ne vois pas de quelles difficultés tu parles dans le contexte de mon post.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Faites des paquets Debian pour vos applications

                Posté par  . Évalué à 2 (+0/-0).

                Ni snap, ni flatpack, ni appimage ne virtualise le matériel du coup c'est pas un élément différenciant.

                Non, mais le runtime est le même sur les distributions. Tu ne dois pas faire le test avec n matériel x m distributions.

                Ce n matériel existe aussi sur flatpack, snap et appimage.

                Oui, mais si tu dois faire un paquets sur oldstable et sur stable, tu dois bien testé deux fois. Je ne vois pas ce que tu veux dire avec ces mises à jour de sécurité. Ou alors, tu veux dire que tu ne mets plus à jour sur oldstable, mais ça ne correspond pas à ce qui est fait lorsqu'un logiciel est distribué par les développeurs et pas par les distributions.

                Oldstable ne subit que des mises à jour de sécurité pendant un an donc si ça correspond à ce qui est fait par les distributions (du moins Debian, je ne connais pas d'autre oldstable). Être plus royaliste que le roi pour trouver des arguments c'est dommage.

                Je ne vois pas de quelles difficultés tu parles dans le contexte de mon post.

                Les snap, flatpack et appimage ne sont pas utilisé pour faire des mises à jour de sécurité. Pour les utiliser, je n'ai jamais eu de mise à jour pour mettre à jour une bibliothèque qu'ils tirent. La seule mise à jour de sécurité qu'il y a c'est les runtimes pour flatpack, mais tout n'est pas dans le runtime.

                Les distributions cherchent à minimiser le temps que tu passe à utiliser une bibliothèque ayant un problème de sécurité, ces packagings ne sont pas utilisés pour ça (ils pourraient en principe mais je ne les ai pas vu le faire) et de l'autre coté tu parle de oldstable qui ne reçoit que des mises à jour de sécurité. snap, flatpack et appimage ne sont pas prévu pour.

                • [^] # Re: Faites des paquets Debian pour vos applications

                  Posté par  . Évalué à 3 (+0/-0).

                  Ce n matériel existe aussi sur flatpack, snap et appimage.

                  Mais tu ne dois faire le test qu'une fois par matériel.

                  Oldstable ne subit que des mises à jour de sécurité pendant un an donc si ça correspond à ce qui est fait par les distributions (du moins Debian, je ne connais pas d'autre oldstable). Être plus royaliste que le roi pour trouver des arguments c'est dommage.

                  Euh, je n'invente pas un truc, beaucoup de monde qui fournit des paquets, les fournissent pour plusieurs versions des distributions: https://eid.belgium.be/en/linux-eid-software-installation https://support.google.com/chrome/a/answer/7100626?hl=en https://about.gitlab.com/install/ https://docs.microsoft.com/en-us/microsoftteams/hardware-requirements-for-the-teams-app

                  l'autre coté tu parle de oldstable qui ne reçoit que des mises à jour de sécurité

                  Pas quand les développeurs de l'application fournissent le deb directement.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Faites des paquets Debian pour vos applications

                    Posté par  . Évalué à 2 (+0/-0).

                    Ce n matériel existe aussi sur flatpack, snap et appimage.

                    Mais tu ne dois faire le test qu'une fois par matériel.

                    C'est ce que je dis depuis le début. Tu souligne que le matériel qui est la même problématique des 2 côtés et qui est beaucoup plus chiant que les distributions, mais par chance quelque soit le système de paquet tout le monde s'en fout et fais 1 à 3 binaires et ne fais pas forcément de batterie de test complet sur chacun.

                    Euh, je n'invente pas un truc, beaucoup de monde qui fournit des paquets, les fournissent pour plusieurs versions des distributions

                    Ils sont plus royaliste que le roi, oui tenter de faire plus et mieux que les distributions c'est douloureux. C'est bien pour ça que les distributions sont en peine pour le faire.

                    • [^] # Re: Faites des paquets Debian pour vos applications

                      Posté par  . Évalué à 3 (+0/-0).

                      C'est ce que je dis depuis le début. Tu souligne que le matériel qui est la même problématique des 2 côtés et qui est beaucoup plus chiant que les distributions

                      Non, je dis que le matériel est à testé sur chaque distribution (vu que chaque distribution a sa version des drivers). Donc si tu as 3 matos et 3 distributions, ça fait 9 tests à faire.

                      Ils sont plus royaliste que le roi, oui tenter de faire plus et mieux que les distributions c'est douloureux. C'est bien pour ça que les distributions sont en peine pour le faire.

                      Dites moi ce dont vous avez besoin, je vous dirais comment vous en passé. C'est un peu une demande récurrente, surtout pour les version précédentes.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: Faites des paquets Debian pour vos applications

                        Posté par  . Évalué à 2 (+0/-0).

                        Dites moi ce dont vous avez besoin, je vous dirais comment vous en passé. C'est un peu une demande récurrente, surtout pour les version précédentes.

                        Ce n'est pas ce que je dis. Que tu sois packagers pour une distribution ou pour un logiciel, que ce soit avec deb, rpm, flatpack, appimage, un sh, ou ce que tu veux, les gens ne sont pas là pour t'embêter. Avoir tout qui marche sur tout matériel supportant à la fois des versions de 20 ans age et les toutes dernières releases n'est pas triviale. Les distributions représente un compromis à ça. Tenter de faire autrement c'est nager à contre courant. Tu peux vouloir le faire, mais ça va être douloureux.

                        Appimage et autres représentent d'autres compromis : ceux sont des distributions au même titre que debian ou redhat.

              • [^] # Re: Faites des paquets Debian pour vos applications

                Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

                Tu ne dois pas faire le test avec n matériel x m distributions.

                Faire le test, c'est prendre le risque de se rendre compte que ça bugge :-)
                https://linuxfr.org/nodes/118350/comments/1788497

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Faites des paquets Debian pour vos applications

                  Posté par  . Évalué à 3 (+0/-0). Dernière modification le 24/11/21 à 14:46.

                  Je ne sais pas comment tu as testé, mais j'ai déjà remarqué que les tests sur la machine où j'avais développé le flatpak n'était pas représentatifs, parce qu'on fait pas mal de truc à la main (mais c'est aussi le cas avec les paquets deb).

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Faites des paquets Debian pour vos applications

        Posté par  . Évalué à 4 (+2/-0).

        Il y a les deux points de vue… que j'analyserai ainsi :

        Si tu fais un logiciel fermé, tu dois distribuer les paquets toi-même (toute façon y a pas de valeur ajouter pour la distribution de juste empaqueter des binaires sans pouvoir contrôler…) Dans ce cas de figure, il va de soi que tu ne peux pas couvrir tous les cas possibles (tu vas par exemple faire les paquets pour mon FreeBSD ou mon Amiga ou le Haiku à côté ?) et évidement la pleurniche qui revient souvent est qu'il y a trop de formats à supporter ; et pour résoudre cela on en créé un autre format https://xkcd.com/927/

        Si tu fais un logiciel dont le code est ouvert, alors il te faut juste indiquer clairement les prérequis de ton environnement de construction. Ce sera aux mainteneurs et mainteneuses des distributions de faire les paquets… Cela permet de garantir la cohérence de la distribution (aussi bien au niveau des emplacements des fichiers que de la gestion des dépendances et diverses considérations de sécurité dont les devs n'ont souvent pas conscience.) Dans ce cas ci, le logiciel sera distribué sur BeOS ou Plan9 pourvu qu'il y ait une personne (ou plusieurs) qui joue(nt) le rôle de maintainer pour la distribution.

        • [^] # Re: Faites des paquets Debian pour vos applications

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

          Chez Haiku (puisqu'on parle de nous, hein…), on aimerait bien que les développeurs d'applications distribuent eux-même leur travail et qu'on aie pas besoin de tout packager nous-mêmes.

          Notre approche est la suivante:
          - Une "distribution" standard du système, qui est la seule à avoir le droit d'utiliser la marque Haiku sans autres précision (d'autres distributions ont existé, par exemple Senryu, TiltOS, ou Discover Haiku)
          - Une ABI et API stable. Actuellement c'est celle de BeOS, qui n'a pas bougé depuis 20 ans. Mais on est conscients que ce n'est pas réaliste car ça imposerait de tout compiler avec gcc2 et de n'utiliser aucune des nouvelles APIs ajoutées depuis,
          - L'introduction de nouvelles APIs se fait d'abord dans des bibliothèques statiques etdans un namespace dédié. Les applications utilisant ces APIs embarquent donc une copie du code concerné, etne sont pas affectées par les mises à jour
          - Pour les APIs stables utilisables en bibliothèques partagées, diverses astuces pour se garder des moyens de faire évoluer les choses: réservation d'espace dans la vtable et les champ de tous les objets C++, surcharge systématique de certaines méthodes pour pouvoir en modifier le comportement plus tard, versionning de symboles, ajout de bouchons permettant aux applications utilisant une fonction qui n'existe plus de continuer à fonctionner, etc.
          - Fourniture d'une API qui couvre pas mal de besoins (graphique, réseau, multimédia, …) évitant ainsi la prolifération de bibliothèque faisant toutes un peu la même chose

          Ça marche plutôt bien pour les applications natives. C'est plus compliqué pour les applications portées depuis Linux ou il y a souvent plein de dépendances vers diverses bibliothèques et des problèmes de compatibilité qui surviennent très régulièrement. Pas trop d'accord avec l'auteur de l'article pour dire que c'est définitivement réglé, donc…

          • [^] # Re: Faites des paquets Debian pour vos applications

            Posté par  . Évalué à 2 (+0/-0).

            Je ne parlais pas de l'équipe core mais un niveau intermédiaire entre le système et les devs et c'est normalement ça les maintainers :-) Ces dernier savent justement comment ça marche et les API et comment faire les choses proprement, alors que si tu demandes aux devs qui n'utilisent probablement pas le système ça va être le boxon. Mais bon, ces devs qui veulent garder tout le contrôle (ou pour des systèmes où il n'y a pas de personne/équipe dédiée à l'empaquetage), il y a flatpack et snap (et ce n'est pas définitivement réglé)

            • [^] # Re: Faites des paquets Debian pour vos applications

              Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

              On a pas le luxe chez Haiku d'être assez nombreux pour clairement séparer les deux. En théorie c'est le cas, les paquets pour les logiciels tiers sont gérés par Haikuports.

              En pratique, les gens qui essaient de porter des logiciels trouvent des bugs dans le système et souvent finissent par les corriger eux-même. Et les gens qui développent l'OS veulent utiliser des logiciels ou bibliothèques qui ne sont pas encore packagées (ou pas dans la bonne version) et doivent le faire eux-même. Il y a donc une assez large intersection entre les deux équipes, et une seule association (Haiku inc) qui paie les serveurs et autres dépenses pour les deux projets.

              Pour les applications natives, il n'y a pas vraiment besoin de passer par un "maintainer". Les développeurs d'applications sont aussi des utilisateurs de l'OS (ou même des développeurs de l'OS) et connaissent assez bien le système. Ce n'est pas très compliqué de distribuer un logiciel, soit sous forme d'un paquet hpkg, soit sous forme d'un simple fichier zip à décompresser.

              Pour les applications portées, ça dépend, on a certains développeurs qui sont motivés pour faire les choses proprement, d'autres qui n'ont pas du tout envie de gérer des cas particuliers, et un peu de tout entre les deux.

              Mais surtout, ce qui est important: on compte sur les utilisateurs pour se plaindre quand un logiciel est plus gros que l'installation de base de Haiku (quelques centaines de Mo).

      • [^] # Re: Faites des paquets Debian pour vos applications

        Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

        Est-ce que Flatpak est tombé en marche depuis https://linuxfr.org/nodes/118350/comments/1788497 ? :-)

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Faites des paquets Debian pour vos applications

      Posté par  . Évalué à 3 (+2/-0). Dernière modification le 23/11/21 à 22:21.

      Oui continuons à être open-bar et à donner absolument tout les droits à ce qu'on exécute !

  • # Linus et le packaging

    Posté par  . Évalué à 5 (+3/-0).

    Ce lien n'est pas nouveau, mais c'est de circonstance

    https://youtu.be/Pzl1B7nB9Kc

  • # Mouais

    Posté par  . Évalué à 2 (+1/-0).

    On compare un système très mature comme le système de paquets mais où aucun format ni gestionnaire de paquets s'est imposé. On se retrouve donc aujourd'hui avec plusieurs formats qui sont tous un peu les mêmes en différents et pareil pour les gestionnaire de paquets. On est tous habitué au deb/rpm et apt/yum/… et ça continue par inertie.

    Et de l'autre on a un système quasi-unique (je compte pas snap qui n'est poussé et n'est pris en charge que sur ubuntu) qui est encore très récent et dont pas mal de défauts mentionnés sont des choix qui peuvent être remis en cause facilement comme l'attribution de certaines permissions par défaut où le but était de ne pas trop changer les habitudes des utilisateurs.

    Sur la sécurité c'est risible, actuellement c'est open-bar. Les applications ont tout les droits sur $HOME et même l'accés en lecture à /. Avec flatpak je retire les droits sans soucis si j'ai envie et sans bidouilles.

    • [^] # Re: Mouais

      Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

      Snap + AppImage + Flatpak, c'est pas vraiment quasi-unique. Surtout que ça ne remplace pas les autres solutions, ça ne fait qu'en rajouter encore plus.

      • [^] # Re: Mouais

        Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

        En plus, deb et rpm sont quasi aussi vieux et c'est pas pour cela que rpm a basculé sur deb… Et ils y a des défauts de jeunesse compliqué à changer.

        Dans le calcul, on utilise plutôt Spark qui est plus adapté et au final, fonctionne mieux souvent que Nix ou Guix.

        Bon, tout cela fait pas mal de diversité ;-)

  • # Super on se croirait un vendredi

    Posté par  . Évalué à 3 (+2/-0).

    Et bien en voilà un tas de point de vue

  • # Pour les jeux

    Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

    Les jeux ont une problématique spécifique:

    • des mises à jour fréquentes et obligatoires pour les jeux en ligne ;
    • le besoin d'un accès "direct mais pas trop" aux piles graphiques, audio et inputs.

    Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?

    Ce qui s'en rapproche le plus aujourd'hui:

    • le brouteur avec les API canvas/webgl/webaudio/gamepad : la sécurité est bonne, mais il est difficile de jouer hors ligne ou même de faire des jeux avec des gigots de ressources, les perfs ne sont pas au top ;
    • libretro : le hors ligne et les gros jeux sont possibles, les perfs sont top, mais il n'y a aucune sécurité.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Pour les jeux

      Posté par  (site Web personnel) . Évalué à 3 (+1/-1).

      Flatpak testé et approuvé en LAN pour des tas de jeux libres : 0ad, supertuxkart, etc.

    • [^] # Re: Pour les jeux

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      On pourrait distribuer chaque jeu sur un support de stockage bootable contentant tout le code nécessaire, permettant à l'éditeur du jeu de choisir exactement ce qu'il inclut et de ne pas avoir de conflit entre les jeux.

      Et on appellerait ça une console de jeux? ça serait simple et facile à utiliser.

      • [^] # Re: Pour les jeux

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 24/11/21 à 13:47.

        Je ne vois pas très bien de quoi tu parles, je possède une "console de jeux" à la maison, et non seulement les jeux ne sont pas tous sur un support dédié, mais en plus je dois régulièrement mettre à jour le système pour pouvoir lancer ces jeux, et le plus souvent ça prend des plombes. Tu es sûr qu'avoir "tout le code nécessaire" fait mieux fonctionner les choses ?

        (le saviez-vous ? Windows CE n'était pas installé sur les Dreamcast, malgré la présence du logo sur la console. C'étaient les disques de jeu eux-même qui incluaient WinCE. La plupart ne s'en servaient pas de toute façon)

      • [^] # Re: Pour les jeux

        Posté par  (site Web personnel) . Évalué à 4 (+1/-0). Dernière modification le 24/11/21 à 14:39.

        Les consoles sans même un BIOS, ça ne court pas les rues. Peut être la PC Engine et encore uniquement pour les jeux sur hucards?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Pour les jeux

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

          La NES et la SuperNES aussi, et la MegaDrive chez Sega. Je pense que la Nintendo 64 aussi mais je me trompe peut-être.

          Pour la Game Boy et l'Atari Lynx il y a un BIOS de quelques centaines d'octets et qui ne peut pas être appelé par les jeux (il est là juste pour vérifier que la cartouche insérée est valide, et démarrer l'exécution du code).

          Pour les consoles sans cartouches c'est effectivement plus compliqué.

          Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.

          Mais même une console qui aurait un noyau Linux et laisserait chaque jeu démarrer son propre userspace, ça marcherait peut être pas si mal que ça, et ça ressemblerait finalement assez aux Snap et Flatpak, en moins compliqué. Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…

          • [^] # Re: Pour les jeux

            Posté par  (site Web personnel) . Évalué à 4 (+1/-0). Dernière modification le 24/11/21 à 19:11.

            Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.

            C'est que font les brouteurs web :-)

            Mais c'est assez bloated. Il faudrait un brouteur jeu !

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Pour les jeux

            Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

            Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…

            Tu oublies aussi la partie où les constructeurs vérifient chaque jeu un par un et leur font passer des semaines voire des mois en QA avant d'accepter leur commercialisation. Ça a été un sacré frein lorsque les premiers magasins dématérialisés ont commencé à ouvrir leurs portes aux devs indés, à la septième génération de consoles. Même aujourd'hui je doute que ce soit une promenade de santé pour les petits créateurs (parce que bien entendu, les gros n'en ont apparemment pas à s'en soucier, n'est-ce pas CD Projekt). Mine de rien, si on veut vraiment un ordinateur qui se comporte comme une console de jeux, ça existe déjà ; ça s'appelle l'iPad.

  • # Developers: Let distros do their job

    Posté par  . Évalué à 2 (+0/-0).

    Dans le même esprit, on avait déjà ceci en septembre : https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

    Systems which invert this model, e.g. Flatpak, are completely missing the point.

    • [^] # Re: Developers: Let distros do their job

      Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

      Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Developers: Let distros do their job

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

        Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.

        Je pense que dans de très fréquents cas (notamment en dev web), les développeurs n'envisagent pas ce que signifie pour les hébergeurs de maintenir 10 ans leur application à jour.

        La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Developers: Let distros do their job

          Posté par  (site Web personnel) . Évalué à 0 (+0/-1).

          Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.

          Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.

          Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.

          https://link-society.com - https://kubirds.com

          • [^] # Re: Developers: Let distros do their job

            Posté par  . Évalué à 2 (+0/-0).

            j'ai plus confiance dans NPM

            Ah tiens, on en parle au sujet d'un autre lien

            • [^] # Re: Developers: Let distros do their job

              Posté par  (site Web personnel) . Évalué à 1 (+1/-1).

              Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.

              En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.

              Ce que je voulais dire c'est que j'ai plus confiance dans :

              $ yarn add moment
              $ pip install trio
              Que :

              $ apt install moment-js
              $ yum install python-trio

              https://link-society.com - https://kubirds.com

          • [^] # Re: Developers: Let distros do their job

            Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

            […] j'ai plus confiance dans NPM/PyPI/[…] pour empaqueter correctement une lib […]

            Je suis le mainteneur de quelques paquets sur NPM et PyPI, et je ne vois pas ce qui aurait pu m'empêcher d'y mettre n'importe quoi. Du coup, il me semble bien que faire confiance à un paquet sur NPM/PyPI revient à faire confiance au quidam qui l'a empaqueter.

            Pour ma part, les paquets que j'ai mis sur NPM/PyPI ne dépendent d'aucun autre paquet dont je ne suis pas le mainteneur. C'est d'ailleurs un argument de « vente » de mes bibliothèques, cependant plus pour des considérations de légèreté que de sécurité.

            Tiens, je viens de voir qu'il y a maintenant un bouton Report malware dans NPM…

            Toolkit Atlas : un moyen simple et rapide pour ajouter une interface graphique à vos applications… (voir 'site Web personnel").

            • [^] # Re: Developers: Let distros do their job

              Posté par  (site Web personnel) . Évalué à 2 (+1/-0). Dernière modification le 25/11/21 à 15:19.

              Je me suis peut être mal exprimé.

              La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.

              Je ne compte plus le nombre de fois ou j'ai eu des soucis avec un apt install python-prout qui s'est terminé par un virtualenv dans /opt.

              La confiance dont tu parles concerne la sécurité, et oui un dépôt officiel d'une distribution ou chaque contribution est revue par un organisme tier a plus de crédibilité qu'un dépôt communautaire (coucou AUR et archlinux?).

              Maintenant, si dans ta société tu as les moyens pour une équipe en charge de la cybersécurité, ces derniers vont te fournir :

              • un dépôt DEB/RPM/whatever contenant une liste de logiciel autorisé à installer
              • un dépôt Maven/NPM/PyPI privé contenant les librairies qui ont été auditées et autorisées

              Si tu veux être parano et ne pas faire confiance a un quidam, tu l'es jusqu'au bout et tu ne fais pas confiance à un organisme tier sur lequel tu n'as aucun contrôle. En fait tu va vraiment jusqu'au bout et tu fais pas confiance à quelque chose qui a été produit par un humain.

              https://link-society.com - https://kubirds.com

              • [^] # Re: Developers: Let distros do their job

                Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.

                Sur cet aspect, c'est possible que ce soit effectivement mieux géré. Cependant, pour des paquets qui embarquent du code natif, je me demande si passer par le gestionnaire de paquets de l'OS n'apporte pas certains avantages, sachant qu'on ne peut pas embarquer l'ensemble des codes natifs propres à chaque système d'exploitation et/ou architecture matériel ciblé avec les paquets NPM/PyPI qui l'utilisent.

                J'ai fait des paquets NPM qui installent du code natif, et ce n'est pas simple. De mémoire, soit le code compilé pour la plateforme cible est disponible quelque part sur internet, et il le récupère, soit il lance une compilation, mais sans se préoccuper de la présence du compilateur adéquat.
                Pour PyPI, je n'ai pas encore fait, mais c'est en projet, sachant qu'il existe des paquets sur PyPI qui le font et dont je compte bien m'inspirer. C'est peut-être plus facile, sachant que si Python est si populaire, c'est en grande partie grâce aux nombreuses bibliothèques tierces qui sont disponibles pour ce langage et dont les plus populaires s'appuient, pour beaucoup, sur du code natif…
                Ceci dit, je n'ai jamais crée de paquets pour une quelconque distribution Linux, donc je ne peux pas m'avancer sur les avantages/inconvénients de cette méthode par rapport à l'utilisation de NPM/PyPI…

                Toolkit Atlas : un moyen simple et rapide pour ajouter une interface graphique à vos applications… (voir 'site Web personnel").

                • [^] # Re: Developers: Let distros do their job

                  Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

                  Cependant, pour des paquets qui embarquent du code natif

                  Oof, tu piques la où ça fait mal ! C'est pas très fair play :p

                  Pour PyPI, tu as les wheels qui sont des paquets précompilés. Tu en as pour la glibc et pour Windows.
                  Attention par contre : https://pythonspeed.com/articles/alpine-docker-python/

                  Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :

                  • gcc
                  • g++
                  • rustc (pour le paquet cryptography, donc tout ce qui touche de prêt ou de loin à SSL ou la génération de nombre aléatoire)
                  • myriade de libprout-dev

                  Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).

                  Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).

                  Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.

                  Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.

                  Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.

                  Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans C:\Program Files/opt. C'est juste plus simple.

                  https://link-society.com - https://kubirds.com

                  • [^] # Re: Developers: Let distros do their job

                    Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                    Cependant, pour des paquets qui embarquent du code natif

                    Oof, tu piques la où ça fait mal ! C'est pas très fair play :p

                    J'essayais juste de trouver pour quelle raison on pouvait préférer le gestionnaire de paquets de l'OS plutôt que le dédié :-).

                    Je viens juste de comprendre le fonctionnement des wheels. En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
                    Concrètement, on a une section, dans le package.json, qui ressemble à ça :

                    "binary": {
                      "module_name": "xppqnjs",
                      "module_path": "./",
                      "remote_path": "./epeios-q37/xppq-node/releases/download/v20171225/",
                      "package_name": "{module_name}-v20171225-{platform}-{arch}.tar.gz",
                      "host": "https://github.com"
                    },

                    Ça permet à NPM de construire l'URL où récupérer le code natif pour la plateforme ciblée (noter le {platform}-{arch} pour l'entrée package_name, dont on trouve l'équivalent dans le nommage des wheels de PyPI), à charge pour l'empaqueteur d'y placer le fichier adéquat.
                    En fait, c'est node-[pre-]gyp qui s'occupe de la récupération, et on peut lui indiquer de lancer la compilation s'il ne trouve pas le fichier attendu. Ce qui, le cas échéant, ne peut évidemment fonctionner que si le compilateur adéquat et présent…

                    Ceci dit écrit, même si les binaires sont disponibles sur PyPI à travers les wheels, c'est quand même à l'empaqueteur de les générer, ou bien ?

                    Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans C:\Program Files/opt. C'est juste plus simple.

                    Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?

                    Toolkit Atlas : un moyen simple et rapide pour ajouter une interface graphique à vos applications… (voir 'site Web personnel").

                    • [^] # Re: Developers: Let distros do their job

                      Posté par  (site Web personnel) . Évalué à 1 (+0/-0). Dernière modification le 25/11/21 à 19:44.

                      En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.

                      Good to know :)

                      c'est quand même à l'empaqueteur de les générer, ou bien ?

                      T'as de l'outillage pour t'aider à les générer, mais sur le principe oui, si l'empaqueteur ne les fournis pas, personne va les fournir pour toi.

                      Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?

                      Tu as par exemple des images Docker pour te fournir une alpine/debian/ubuntu avec un JDK dans une version spécifique. Pareil pour Python, Erlang/Elixir, etc…

                      Fun fact, j'ai une application Elixir qui embarque dans son image Docker un binaire Go, dans la phase de build j'ai ceci:

                      COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
                      ENV PATH="/usr/local/go/bin:${PATH}"

                      Alors certes, j'imagine mal une image Docker "python-django" ou "node-expressjs" sur DockerHub. Cependant j'ai pas mal vu en entreprise des images Docker de base du style "java-jdk11-springboot" partagées entre les différentes teams.

                      Accessoirement, pour Windows si tu veux bosser avec la SDL, tu chope un ZIP qui te donne les headers et les DLLs.

                      https://link-society.com - https://kubirds.com

              • [^] # Re: Developers: Let distros do their job

                Posté par  . Évalué à 2 (+0/-0).

                coucou AUR et archlinux

                Avant d'installer un paquet de AUR on conseille fortement :
                * de lire les commentaires
                * de lire le fichier PKGBUILD qui te montre exactement ce qui sera téléchargé et où ça va être installé.

                C'est écrit en gros, partout. En général on est en mesure de s'assurer que la source est bien "officielle" (le dépôt Github du développeur par ex.) M'enfin oui ce n'est pas comparable avec des paquets revus par les mainteneurs d'une distro. Cela dit c'est pas la même chose avec les PPA de Ubuntu ? (vraie question, je n'ai pas utilisé depuis longtemps)

                • [^] # Re: Developers: Let distros do their job

                  Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

                  c'est pas la même chose avec les PPA de Ubuntu ?

                  C'est le même problème avec tout les dépôts communautaires sans review.

                  Avant d'installer un paquet de AUR on conseille fortement :

                  Les teams DevSecOps me chuchotent à l'oreille que ces conseils s'appliquent à toutes les dépendances externes peu importe leurs provenance (dépôt officiel ou non).

                  https://link-society.com - https://kubirds.com

        • [^] # Re: Developers: Let distros do their job

          Posté par  (site Web personnel) . Évalué à 2 (+0/-1). Dernière modification le 25/11/21 à 14:15.

          Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.

          Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.

          La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.

          La maintenance à long terme demande:

          • d'avoir des libs à jour et qui fonctionnent ;
          • un seul système de build (et pas un par distrib).

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Developers: Let distros do their job

        Posté par  (site Web personnel) . Évalué à 5 (+2/-0).

        se mettre d'accord sur un système de paquets commun

        Même si toutes les distributions utiliseraient RPM, le problème ne serait pas résolu. Ce serait un progrès mais insuffisant.
        Déjà car chaque distribution nomme ses paquets de manière différentes. Si c'est souvent le même, parfois c'est très différent. Pensons à kernel chez Red-Hat pour linux côté Debian. Ou Apache pour Debian, httpd pour Red Hat. Du coup pour les dépendances d'un paquet ça pose problème.

        Ensuite les options de compilation et le découpage des paquets (et de fait les dépendances) sont différentes. Certaines distributions peuvent faire un gros paquet Libreoffice qui fournit tout, quand d'autres vont avoir un paquet par logiciel fourni par Libreoffice. L'un est plus simple, l'autre permet d'être plus modulaire (et donc potentiellement n'installer que ce qui est vraiment nécessaire). Il n'y a pas de choix parfaits à ce sujet.

        s'assurer d'avoir des API / ABI stables

        Cela dépend moins des distributions que de la chaine de compilation et des bibliothèques employées par les logiciels fournis. Ce n'est pas de la faute de Fedora ou Debian si GNOME migre vers GTK4 qui n'est pas compatible avec GTK+3 par exemple.

        C'est l'avantage du libre, tu peux composer ce que tu veux selon tes envies et besoin, l'inconvénient c'est qu'il fragmente l'écosystème et rend la tâche plus complexe pour les personnes extérieures. Flatpak est un moyen (comme d'autres) de résoudre ce conflit, mais là encore cette solution a des inconvénients.

        À un moment il faut réaliser qu'il n'y a aucune solution technique parfaite, et que d'aller dans un sens a un impact négatif sur d'autres paramètres.

        • [^] # Re: Developers: Let distros do their job

          Posté par  (site Web personnel) . Évalué à 3 (+1/-1).

          Peut être que l'approche "empaquetage" est mauvaise alors.

          En tout cas la conséquence, c'est que tout fini dans /opt ou sur docker…

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Developers: Let distros do their job

            Posté par  (site Web personnel) . Évalué à 3 (+0/-0). Dernière modification le 25/11/21 à 14:56.

            Elle a ses avantages et ses inconvénients.

            Si tu supprimes les paquets pour la faire à la macOS ou Windows, ça va certes améliorer cet aspect significativement, mais ça va râler dans les chaumières.
            Notons que par exemple Fedora Silverblue comme d'autres tentent une approche nouvelle, qui n'est pas parfaite mais a son intérêt.

          • [^] # Re: Developers: Let distros do their job

            Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

            Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.

            Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.

            En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.

            J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
            et pénible dans ma carrière.

            https://link-society.com - https://kubirds.com

  • # Une réponse de Will Thompson (Endless OS)

    Posté par  (site Web personnel) . Évalué à 2 (+0/-0). Dernière modification le 25/11/21 à 14:58.

    Pour ceux qui l'ignorent, Endless OS est une distribution qui utilise exclusivement les flatpaks pour gérer ses paquets (sur le même principe que Fedora Silverblue si je ne m'abuse). Un des employés d'Endless, Will Thompson, a voulu calculer l'espace disque que ça lui occupait (puisque l'un des reproches faits dans le billet de Ludocode est que Flatpak prend trop de place). Un aperçu :

    On peut ne pas être d'accord sur le fait que ces chiffres soient gros ou petits, comparés aux points positifs que Flatpak apporte ou non. Mais les chiffres en eux-même sont disponibles à la consultation, tout comme une bonne partie du travail actuel ou futur pour rendre ces chiffres aussi petits/gros qu'ils le sont. Personnellement, je pense que le compromis m'est nettement favorable, ainsi qu'aux utilisateurs d'Endless OS, d'autant plus que depuis le passage au tout-Flatpak, l'installation immutable de base d'Endless OS ne fait que 4,2 GB.

Envoyer un commentaire

Suivre le flux des commentaires

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