Journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?

Posté par (page perso) . Licence CC by-sa.
31
16
oct.
2019

Salut Journal,

Ça fait longtemps, hein ? Mais dis-moi, c'est quoi ce bordel ? Je m'absente 5 ans et je retrouve les distributions Ubuntu sans dessus dessous.

M'étant lassé de MacOS notamment à cause du foutoir qu'est l'installation de logiciels, heureux d'enfin retrouver apt-get, je découvre que, en fait, les distribs Linux sont devenus un foutoir sans nom.

Alors, certes, apt-get existe encore, mais il est régulièrement inaccessible car packagekit ou inattended-upgrade ont un lock. Certains logiciels n'apparaissent pas dans apt-get mais bien dans l'appstore graphique que j'ai compris être Snap (et qui, d'après un post sur le blog de Linux Mint, est un truc ultra fermé réservé à Ubuntu).

Le Snap en question semble être un truc de goret qui rend l'output de df illisible.

Je réalise que les devs GNOME, eux, développent un truc appelé Flatpak. J'ai tenté d'en installé un (pour avoir la dernière version de Geary), sans succès.

Bref, c'est le gros bordel. J'ai même eu le témpoignage d'utilisateurs qui avaient deux voire trois versions différentes du même logiciel sans comprendre comment ni pourquoi.

Comme je suis sous Regolith-Linux (une version de Ubuntu avec i3 et quelques composants GNOME par défaut), j'aimerais tout simplement virer Snap.

Sauf que…

J'ai plein de Snap installés par défaut pour les outils GNOME, les thèmes GTk et certains trucs appelés « core ». Du coup, je ne suis pas sûr des paquets deb que je devrais réinstaller après avoir viré snap ni même si cela fonctionnera vu que les versions sont peut-être complètement différentes.

Bref, comment tu fais, cher journal ? Oui, je sais, tu passes à Debian. Mais vu que Regolith ne fonctionne pas encore avec Debian, j'aimerais pour le moment éviter ça. Et je pense que le dev Regolith serait pas contre le fait de virer Snap de son install par défaut si on lui explique comment.

  • # Flatpak c'est bien

    Posté par (page perso) . Évalué à 8 (+8/-1).

    Bref, c'est le gros bordel

    Ouais, mais c'est bien d'avoir une alternative pour installer un peu arbitrairement des paquets qui ne sont pas dans ta distro.

    Perso j'utilise flatpak pour quelques applis, et c'est franchement pas mal ! Mis à part le cache qu'il faut vider à la main de temps en temps (ça peut monter à quelques gigas assez vite).

    • [^] # Re: Flatpak c'est bien

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

      J’utilise Flatpak depuis que j’ai lu le journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap et j’en suis plutôt content.

    • [^] # Re: Flatpak c'est bien

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

      Idem, je n'ai pas trop compris le coup de gueule de Ploum. Pour ma part j'utilise LinuxMint, qui bien que dérivé d'Ubuntu, n'est pas centré sur Snap, du coup je pense que j'ai encore accès à apt-get pour la totalité des logiciels (utilisables sous Debian), et ça me convient bien comme ça.

      Par contre, pour certains logiciels multimédia, il n'était pas toujours évident d'avoir la dernière version, ou une version de développement à jour.

      Plutôt que de galérer (parfois), à tout compiler soi-même, quel plaisir d'avoir accès à des versions Flatpak, qui permettent d'utiliser immédiatement un logiciel fonctionnel.

      Peut-être que flatpak ne fonctionne pas bien sur ubuntu vanilla (je ne vois pas trop pourquoi), mais sur linux mint 19 je n'ai eu aucun problème sur tous les flatpak téléchargés. En général je les copie dans /opt et créé un raccourci vers le bureau. Je peux comme ça utiliser les dernières versions de LMMS, Musescore, Krita…

      • [^] # Re: Flatpak c'est bien

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

        j'ai dit une bêtise (que je ne peux pas corriger), c'est Appimage que j'ai utilisé, pas flatpak… du coup je présume que flatpak fonctionne un peu comme snap.

  • # Bien d'accord !

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

    Je trouve aussi que ça (re)devient le foutoir, tous ces "installeurs" -_-'
    Ça s'était un peu calmé ces derniers temps, encore des guerres de chapelle…

    Personnellement, je les utilise aussi peu que possible et j'essaye toujours, (dans la mesure du possible !) de passer par les dépôts de la distribution.
    Je pense que tout dépend de l'usage que l'on en a. En ce qui me concerne, fort peu de logiciels dont j'ai besoin nécessitent de passer par 'snap' ou 'flatpak', donc, comme le dit le type tombant du 50ème étage : "Pour l'instant, tout va bien…" :-)

    Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

    • [^] # Re: Bien d'accord !

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

      Je t'ai pertinenté parce que la dernière phrase m'a bien fait rire :)

      Mais plus sérieusement, avoir une gestion de paquets compartimentée, indépendante de la distro, ça a pas mal d'avantages:

      • ça peut permettre aux créateurs de logiciels de se focaliser sur un biais de distribution unique,
      • par la même occasion, à l'utilisateur d'être toujours à jour, et ce même si son OS n'est pas à jour,
      • pour le build des applications, ça permet d'avoir des applis qui utilisent des versions différentes des mêmes bibliothèques partagées,
      • il y a aussi un gros focus sur la sécurité, ça bac-à-sable tout, et c'est pas mal,
      • etc… il y a plein de très bonnes raisons d'avoir ce genre de système de distribution d'application.

      Après c'est pas magique, il y a aussi plein d'inconvénients (beaucoup sont techniques, j'imagine). Mais finalement, pour l'utilisateur final, si une solution émerge et dépasse les autres: avoir un store graphique sympa, et pouvoir installer plein de trucs sans connaître les base de l'utilisation de la ligne de commande d'APT ou autre Yum, et avoir en même temps un semblant de sécurité et l'assurance qu'un logiciel moisi ne va pas pourrir son appareil, c'est plutôt bien.

      • [^] # Re: Bien d'accord !

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

        Moi, ça me rappelle les horreurs des DLLs dans tous les sens…
        Comme je le disais précédemment, je n'utilise pas snap et pourtant, c'est déjà le foutoir dans le répertoire :

        tree -L 2 -d /snap
            /snap
            ├── bin
            ├── code
            │   ├── 17
            │   ├── 18
            │   └── current -> 18
            ├── core
            │   ├── 7713
            │   ├── 7917
            │   └── current -> 7917
            └── docker
                ├── 372
                ├── 381
                ├── 384
                └── current -> 384
        
            14 directories
            snap$ sudo du -sh  *
            4,0K    bin
            1,2G    code
            511M    core
            1,2G    docker
            4,0K    README
        

        Je ne suis pas descendu dans les sous-répertoires, mais tu retrouves toute l'arborescence système :

            cd docker/
            /snap/docker$ ls
            372  381  384  current
            cd 372/
            ls
            bin                      command-dockerd.wrapper  command-help.wrapper     config  lib      meta  share  usr
            command-compose.wrapper  command-docker.wrapper   command-machine.wrapper  etc     libexec  sbin  snap   var
            /snap/docker/372$ cd lib
            /snap/docker/372/lib$ ls
            libnvpair.so.1      libuutil.so.1      libzfs_core.so.1      libzfs.so.2      libzpool.so.2      python2.7  udev
            libnvpair.so.1.0.1  libuutil.so.1.0.1  libzfs_core.so.1.0.0  libzfs.so.2.0.0  libzpool.so.2.0.0  systemd    x86_64-linux-gnu
        
        
        etc...
        

        Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

        • [^] # Re: Bien d'accord !

          Posté par (page perso) . Évalué à 1 (+11/-11).

          Moi, ça me rappelle les horreurs des DLLs dans tous les sens…
          Comme je le disais précédemment, je n'utilise pas snap et pourtant, c'est déjà le foutoir dans le répertoire :

          Encore une fois un commentaire de quelqu'un qui rejette en bloc ce qu'il ne comprend pas, c'est une réaction de réactionnaire.

          La structure des répertoire est entièrement gérée par l'outil (flatpak ou autre) et tient compte d'un très grand nombre de contraintes (partage des fichiers similaires, gestion de quoi appartient à qui, etc…) et ne répond pas à une structure logique écrite par un humain, mais dicté par une réflexion technique et codifiée.

          Ce n'est pas parce que tu ne comprends pas ou n'est pas d'accord avec cette codification que ce n'est pas bien.

          Si ça fonctionne et que tu ne constate pas de bugs, c'est que les gens qui ont écrit les algorithmes qui déterminent cette structure ne se sont pas trompés. Que tu le comprenne ou pas, ça correspond à une logique réfléchie et structurée pour laquelle ce n'est pas ton rôle de s’inquiéter.

          • [^] # Re: Bien d'accord !

            Posté par . Évalué à 10 (+14/-1).

            Est-ce une réaction de réactionnaire de chercher a tendre vers un système que l'on est capable de dépanner, de maintenir, de modifier soi-même?

            Parce qu'une des raisons qui font que je n'ai pas encore étudié systemd en détails, justement, c'est que je le trouve complexe, alors que j'ai l'impression (est-elle justifiée? C'est pas sûr) de pouvoir faire la même chose avec des outils plus simples, dont je suis même capable de comprendre le source (j'ai encore lu le source de sv aujourd'hui, me suis d'ailleurs demandé si c'était du C K&R…) chose utile quand un comportement n'est pas ou est mal documenté (un logiciel trop documenté s'expose au problème qu'il faut lire trop de trucs pour le juste mettre en place, l'équilibre n'est pas simple).

            J'ai parlé de systemd ici, mais la même chose peut s'appliquer a bien des technologies, et il est possible que ces nouveaux systèmes de paquets y aient leur place.

            J'ai aussi parlé de tendre vers, parce que je suis conscient que ce n'est pas possible de comprendre la totalité de son système (le kernel linux m'est obscur, et même si je comprenait 100% des binaires de mon système, il resterait les firmwares, le code verilog/whatever qui programme un CPU s'il est en fait un FPGA, puis l'électronique… bref).

          • [^] # Re: Bien d'accord !

            Posté par . Évalué à 10 (+17/-8). Dernière modification le 16/10/19 à 21:49.

            quelqu'un qui rejette en bloc ce qu'il ne comprend pas […]

            Avec 20 ans de métier spécialisé sur UNIX puis Linux, je pense maîtriser un peu les archi système… Fais un peu attention à qui tu t'adresses quand tu fais ce genre de remarques…

            Je considère effectivement que c'est "pourri", si on a inventé les bibliothèques partagées, c'est justement pour éviter ces horreurs.
            Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement. Résultat, je me retrouve avec des lib en double/triple/whatever qui me "bouffe" des giga de disque.

            Ben je trouve pas que ce soit un progrès et non, je ne suis pas d'accord et j'ai le droit de le dire : TU trouves peut-être ça bien mais pas moi, n'impose pas TON point de vue aux autres, ou argumente plus sérieusement au lieu d'attaques "ad hominem".

            Je me moque que ce soit géré ou pas par l'appli, je veux savoir exactement ce qui est installé sur mon système, par mes soins, et j'ai légitimement le droit de m'inquiéter de ce qui est installé sur ma machine, on est pas chez Apple.

            Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

            • [^] # Re: Bien d'accord !

              Posté par (page perso) . Évalué à 10 (+14/-1).

              Ben je trouve pas que ce soit un progrès et non, je ne suis pas d'accord et j'ai le droit de le dire : TU trouves peut-être ça bien mais pas moi, n'impose pas TON point de vue aux autres, ou argumente plus sérieusement au lieu d'attaques "ad hominem".

              Il faut arrêter de croire que l'opinion qu'il a exprimé est personnel. Il évoque un vrai problème qui est aussi vieux que la notion de paquets sous Linux.

              Il y a deux cas d'usages qui sont assez contradictoires et qui sont légitimes.

              D'un côté le fonctionnement avec des dépôts, qui est assez élégant, cohérent et offre de nombreuses sources de mutualisation. Mais c'est peu flexible pour l'utilisateur qui veut un truc hors dépôt et nécessite beaucoup de travail pour s'assurer que la bibliothèque commune entre tous ces composants fonctionnent avec une version identique. Outre le travail de packaging en lui même qui reste une activité laborieuse et peu sexy.

              De l'autre le fonctionnement des applications qui fournissent tout le nécessaire avec ou non possibilité d'une base commune (ce que Flatpak propose pour limiter la duplication des bibliothèques de base). Mais comme ces applications sont autonomes, ils sont très flexibles pour l'utilisateur qui peut installer la version qu'il veut, voire plusieurs en parallèle et qu'il est totalement indépendant du cycle de sa distribution. Pour le développeur de l'application c'est aussi plus facile de le distribuer à tout le monde sans prise de tête.

              Bref, Flatpak / Snap / Autres répondent à de vrais besoins et ne sont pas le ressort d'opinion strictement personnelles tant ce besoin a été mainte fois exprimé depuis très longtemps. Nous avons seulement maintenant l'émergence de solutions matures pour le combler, tant mieux non ?

              Après tout, tout le monde ne va pas migrer vers cela, au pire tu fondes ta distribution traditionnelle et voilà. Cela ne retire pas cette possibilité.

              Je me moque que ce soit géré ou pas par l'appli, je veux savoir exactement ce qui est installé sur mon système, par mes soins, et j'ai légitimement le droit de m'inquiéter de ce qui est installé sur ma machine, on est pas chez Apple.

              Ce genre de remarques (car c'est assez récurrent de lire ce type de propos) me fait croire que la notion même de distribution n'est pas comprise.

              Une distribution, son rôle est justement de dire quelle application est fournie par défaut, quelle expérience utilisateur est souhaitée ou mise en avant, quelles sont les limites, des choix d'architecture ou techniques diverses, etc.

              Donc oui en installant une distribution tu acceptes les choix qu'elle a fait pour toi, pour te simplifier la vie mais aussi aussi pour simplifier sa propre maintenance. Car si à l'installation d'une distribution tu dois valider la libc de référence, le système d'init utilisé, la pile audio par défaut, le noyau (bah oui, BSD existe aussi !), le shell par défaut, etc. tu vas perdre un temps immense et il est peu probable que le résultat soit stable car c'est difficile à maintenir. Puis honnêtement, ce serait indigeste, d'autant plus que nous ne sommes pas omniscients.

              Fedora, Ubuntu, Debian, Suse, ArchLinux, Gentoo, etc. ont fait des choix à ce sujet très différents et ont donc leur raison d'être. Ubuntu et Fedora misent pour leur futur sur Flatpak et Snap pour différentes raisons. Pourquoi pas, c'est leur but de prendre ce genre de décisions. Si cela ne te plaît pas, soit tu t'adaptes (en supprimant manuellement après l'installation), soit tu prends une autre distribution qui est plus en phase avec tes envies. Les distributions ne te doivent rien de particulier, ils peuvent écouter tes remarques mais aussi ne pas en tenir compte.

            • [^] # Re: Bien d'accord !

              Posté par . Évalué à 8 (+6/-0). Dernière modification le 17/10/19 à 09:32.

              Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement.

              bah, mauvais système, changer de système hein ! Si tu es un sysadmin expérimenté, pourquoi n'utilises-tu pas plutôt Debian ? (ce n'est pas du sarcasme, juste une vraie question)

              Linux Mint n'a pas Snap par défaut, du coup je n'ai pas de /snap chez moi.
              La première fois que j'ai été confronté à Snap, c'était sur un boîtier nextcloud que j'avais commandé (disque dur + boîtier + ubuntu sur carte sd pour gérer l'ensemble), ça m'avait apparu assez opaque effectivement et compliqué en cas de plantage, et j'ai depuis réinstallé un système plus simple qui fonctionne toujours maintenant.

              Je ne connais pas flatpak, par contre AppImage est complètement différent, il faut plus voir ça comme les .dmg chez Apple, c'est juste une application avec la plupart des bibliothèques intégrées dedans. Quand j'ai installé l'AppImage de Krita, ça m'a mis tout ce dont j'avais besoin sans installer les dépendances de KDE sur mon système.

            • [^] # Re: Bien d'accord !

              Posté par . Évalué à 8 (+7/-1). Dernière modification le 17/10/19 à 10:41.

              Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement.

              Je ne suis pas sûr de comprendre cette phrase tellement ça me semble gros : tu voudrais que ceux qui produisent une distribution te demandent ton consentement avant chacune de leur décision* ???

              * Sachant qu'en principe ils publient des notes de version/mise à jour pour t'informer.

              • [^] # Re: Bien d'accord !

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

                Non, bien sûr :-)
                Ce que je voulais dire par là c'est que ça a fait partie d'une mise à jour globale de ma distribution sans que je la vois passer.
                Je suis c'est vrai, fautif sur ce point car j'aurais du consulter le changelog, ce que je n'ai pas pris le temps de faire.

                Mais je trouve dommage d'imposer des installations "par défaut" avec cet outil alors qu'il existe un outil "standard" pour le faire (apt dans mon cas). Ça me donne vraiment l'impression que les responsables de la distribution veulent s'affranchir du circuit "normal" de validation, et je pense qu'au final, on va avoir à nouveau une fragmentation de l'écosystème.

                Ce n'est pas forcément un mal, la diversité, bien au contraire, mais je trouve que c'est un manque de respect pour les mainteneurs : "
                Les mecs, vous bossez pas assez vite, là, nous on est pressé, alors on va se passer de vos services".

                Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

            • [^] # Re: Bien d'accord !

              Posté par (page perso) . Évalué à 10 (+9/-0). Dernière modification le 18/10/19 à 11:54.

              Avec 20 ans de métier spécialisé sur UNIX puis Linux, je pense maîtriser un peu les archi système… Fais un peu attention à qui tu t'adresses quand tu fais ce genre de remarques…

              Expérience et compétence sont deux choses différentes.

              Je considère effectivement que c'est "pourri", si on a inventé les bibliothèques partagées, c'est justement pour éviter ces horreurs.

              Et cela a fonctionné, jusqu'à un certain point.

              Voici un scénario typique:

              • un développeur d'applications a testé son application avec une version A de bibliothèque
              • un autre développeur d'applications a testé son application avec une version B de la même bibliothèque
              • un mainteneur de distribution veut intégrer ces deux applications. Il va donc chercher à utiliser la même version pour toutes les applications utilisant cette bibliothèque.
              • le mainteneur choisit une version unique (A, B, voire C)
              • malgré les tests du mainteneur et de l'équipe d'assurance qualité de la distribution, il y a peut être des bugs spécifiques à la version de bibliothèque utilisée

              Par conséquent, l'utilisateur est mécontent car:

              • il ne peut bénéficier de la dernière version de ses applications préférées tant qu'elles n'ont pas été packagées pour sa distribution
              • même si elle est packagée, elle ne fonctionnera peut être pas à 100% avec la version de bibliothèque choisie par le mainteneur
              • il va remonter des bugs au développeur de l'application

              De plus, les développeurs d'applications sont mécontents, car:

              • ils sont inondés de bugs remontés par les utilisateurs, mais pour lesquels ils ne peuvent rien, car dus aux choix des mainteneurs de distributions, et ce pour chaque distribution où cela pose problème.
              • ils ont fait une application qui fonctionne, mais voient leur réputation être entachée par des bugs ou incompatibilités des bibliothèques, et des choix des mainteneurs de distributions
              • on leur remonte des bugs sur des applications obsolètes car ils ont déjà sorti la version n+1 mais les distributions sont restées sur la version n.

              Enfin, le mainteneur est mécontent car:

              • packager des logiciels ça prend du temps et on duplique l'effort pour chaque distribution
              • il a des problèmes insolubles à résoudre notamment dû à l'explosion de la matrice de test qui fait que la moindre mise à jour d'une bibliothèque peut casser plein d'applications

              Flatpack et Snap ont été créées pour résoudre ces problèmes:

              • c'est un circuit court: directement du producteur (développeur) au consommateur (l'utilisateur) sans intermédiaire (distribution), par conséquent tu peux avoir la version nightly d'une application avec un Flatpack quelques minutes après qu'elle a été compilée
              • les testeurs peuvent remonter des bugs sur la dernière version facilement (au lieu de galérer à recompiler cette dernière version non fournie dans les backports de leur distribution)
              • l'application se lancera sans polluer ton système (pas de paquets expérimentaux, pas besoin de déstabiliser ton système)
              • tous les utilisateurs de l'application Flatpack/Snap feront tourner l'application dans la configuration choisie par les développeurs: plus de combinatoire de test, tout les utilisateurs ont une combinaison unique de versions.

              Alors oui, ça prend plus de place sur le disque, mais tu n'es pas obligé d'installer toutes tes applications avec des systèmes de conteneurs de ce type. Toutefois, quand tu as besoin d'un logiciel non fourni par ta distribution, ça change la vie. Si tu suis le développement de certains logiciels en particulier, tu peux utiliser la version stable de ta distribution, et par dessus un Flatpak/Snap de la poignée de ces applications dont tu veux absolument la dernière version stable (si tu veux les dernières fonctionnalités), ou nightly (si tu veux tester au fil de l'eau et remonter des bugs dès qu'il apparaissent).

              On s'oriente de plus en plus vers un système de base construit avec des packages pour ce qui est des composant système, avec au dessus des runtimes intermédiaires, et des applications contenairisées au-dessus.
              Tu peux jeter un coup d'oeil à Fedora Silverblue ou à EndlessOS pour avoir un aperçu de ce futur pas si lointain.

              Je n'ai pas demandé à avoir snap installé sur mon système, ça c'est fait sans mon consentement.

              Je doute qu'on t'ai mis le couteau sous la gorge. Tu as à un moment donné accepté le contrat de licence utilisateur à l'installation de ta distribution qui justement permet cela. Soit tu as directement installé une vesion utilisant snap, soit tu as donné ton consentement explicite autorisant les mises à jour et as migré vers une version utilisant snap.

              Résultat, je me retrouve avec des lib en double/triple/whatever qui me "bouffe" des giga de disque.

              Tout à fait. Mais l'espace disque est bon marché de nos jours, et bien que partager les ressources offre de meilleurs performances (accès cache, etc.), parfois cela est moins prioritaire qu'avoir une application qui fonctionne, ou avoir la dernière version d'application sans avoir à attendre 1 an. Tu n'es pas non plus obligé d'installer toutes tes applications de cette manière: on te donne le choix d'utiliser la version de ta distribution ou la version en conteneur.

              En effet, même si Flatpak ou Snap est sur ton système, tu n'es pas obligé de l'utiliser.

              • [^] # Re: Bien d'accord !

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

                [..] ont été créées pour résoudre ces problèmes:

                c'est aussi ce qui fait que Mageia existe et fait :-)

                • travail avec l'upstream
                • travail avec les autres distributions : dnfdragora, disponible pour Mageia et Fedora et basé sur une bibliothèque venant de SUSE (et pas que)
                • promouvoir de nouvelles versions des logiciels en stable plutôt que de patcher, lorsqu'il n'y a pas trop de dépendances (même si une montée de version de tout KDE a aussi été faite et réussie en 2 temps avec pas tant que ça de bugs pour tout le monde, quelques cas identifiés tout de même :/)
                • oui c'est plus de boulot : intégrer le bon fonctionnemment global, ce n'est pas simplement balancer une image docker, un flatpack ou snap de-ci, de-là ; il faut aussi le maintenir dans le temps et avec tout ce qui est autour :-)

                bref, spa facile :/
                La solution de facilité de l'espace disque vs une bonne séparation entre espace système / espace utilisateur est un problème topologique qui n'a pour l'instant pas de solution simple àmha.

                docker, snap, flatplak sont pour moi des solutions transitoires qui prennent le problème d'un autre côté, vivement que la solution converge :-)

      • [^] # Re: Bien d'accord !

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

        pour le build des applications, ça permet d'avoir des applis qui utilisent des versions différentes des mêmes bibliothèques partagées,

        Et de manière générale, ça répond à un vrai besoin en entreprise : gérer plein de versions d'applications sans instancier 20 VMs parce qu'il n'y a qu'une seule version de l'appli dispo dans la distro bidule.

        C'est un besoin auquel Docker répond d'ailleurs en partie.

      • [^] # pas d'accord !

        Posté par (page perso) . Évalué à 10 (+20/-4).

        Pour un administrateur, c'est une horreur : plus moyen d'avoir simplement la liste des logiciels installés, et donc une catastrophe au niveau sécurité : comment maintenir facilement à jour l'ordinateur ?

        Pour moi, c'est un retour arrière comme au temps des tar.gz !

        • [^] # Re: pas d'accord !

          Posté par (page perso) . Évalué à 6 (+4/-0).

          Je déploie beaucoup d'applications via puppet et flatpak, en quoi tu ne peux plus avoir la liste des logiciels installés?

          • [^] # Re: pas d'accord !

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

            c'est toujours possible mais c'est plus dur car tu dois vérifier ce qui est installé via apt, flatpak, snap. Et tu es toujours à la merci d'un gestionnaire de paquet que tu ne connais pas qui installerait des trucs en douce. Donc, oui, ça complique le travail d'administration pour le geek moyen comme moi qui veut savoir ce qu'il y'a sur sa machine (n'ayant pas suivi le bouzin, j'étais persuadé que snap était juste un format de repository qui installait ensuite via apt. C'est quand je me suis excité pour trouver un paquet que je savais installé sur ma machine et que j'ai fais, pour une autre raison, un df, que j'ai compris l'histoire.

          • [^] # Re: pas d'accord !

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

            Je veux une commande (rpm, apt , machintruc …) qui me remonte tous les logiciels installés avec leur version, quel que soit le mode d'installation.

        • [^] # Re: pas d'accord !

          Posté par (page perso) . Évalué à 8 (+9/-2). Dernière modification le 16/10/19 à 17:45.

          une catastrophe au niveau sécurité

          Le but est complètement inverse à ce que tu dis, au contraire ça renforce la sécurité. Et comme le dit le commentaire juste en dessous du tiens, tous ces stores permettent de lister et gérer ce qui est installé.

          Ça permet même d'avoir un système de base complètement readonly, ce qui est plutôt un gros plus pour la sécurité des postes de travail.

          Pour moi, c'est un retour arrière comme au temps des tar.gz !

          Les tar.gz tu les décompressais tous au même endroit, avec les shared libraries mélangées, un tar malencontreux qui remplaçait les fichiers d'un autre, etc… Avec des applis containerisées et des dépendances bien gérées, un outil comme flatpak permet justement d'éviter tous les pièges d'antan.

          • [^] # Re: pas d'accord !

            Posté par (page perso) . Évalué à 5 (+4/-0).

            Je pense qu'il y a un problème d'échelle : autant ces outils me semble utilisable à titre personnel, autant à titre professionnel ( je gère un parc de plusieurs centaines de machines sous linux ), ça me parait dangereux, tant qu'il n'y aura pas d'outil d'administration global.

            Par exemple, j'ai besoin que mon outil d'inventaire de parc remonte tous les logiciels installés.

        • [^] # Re: pas d'accord !

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

          Ça ressemble plutôt au nirvana pour les sysadmins.
          C'est juste super relou de devoir toujours construire des paquets custom ou des installs pourries à la main depuis les sources, sans mise à jour facile. Alors faut pas se mentir, ça permet aussi d'avoir PHP 5.x installé jusqu'à la fin des temps sur un serveur, mais ça n'est pas la faute des snaps. Parce que oui, dans la vraie vie, on peut avoir besoin de Tomcat 6 ou 7 tournant sur la JVM 8 un serveur en Debian Buster. Déjà que l'OS soit à jour et que l'appli pourrie en question puisse être isolée du vrai filesystem, c'est un gros progrès.

      • [^] # Re: Bien d'accord !

        Posté par (page perso) . Évalué à 4 (+3/-1). Dernière modification le 16/10/19 à 19:15.

        Tu veux dire que ca permet en gros de séparer les applications du système, avec les applications qui ont leurs propres bibliothèques embarquées. Ca permet aussi du coup au développeurs de logiciels de se contenter de faire qu'un paquet de son truc, et de le distribuer directement, ou via des sites de téléchargements.

        En fait, ca permet de faire un peu comme sous Windows quoi. A se demander pourquoi Microsoft est en train de développer son dépôt logiciel pour justement garder les dit logiciels à jours dans les dernières versions et éviter de devoir télécharger son appli depuis un site proposant un installeur foireux avec 50 cacas logiciels ajoutés en même temps au passage.

        Vous m'excuserez de ne pas être convaincu et de préférer conserver l'installation de mes logiciels avec les paquets maintenus par ma distribution ;)
        Dire qu'Ubuntu est censée être une distribution pour débutant facile et simple à prendre en main, et qu'à côté, Arch a la réputation d'être instable et de pouvoir se casser avec une simple mise à jour …

        Opera le fait depuis 10 ans.

        • [^] # Re: Bien d'accord !

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

          En fait, ca permet de faire un peu comme sous Windows quoi.

          tu confonds flatpak/snap et tarball.

          Les flatpaks/snaps restent des packages avec une boite à outil quu te permet de les mettre à jour facilement.

          La différence c'est qu'ils sont gérés indépendemment des distribs.

          Après pour moi ça n'a d'intérêt que si ces paquets sont bien maintenus, et pas par des inconnus complets. Je ne me verrais pas installer un flatpak qui n'a pas été préparé par le projet upstream (tout comme je n'irais pas démarrer une image de container non gérée et maintenue activement par l'upstream.

          • [^] # Re: Bien d'accord !

            Posté par . Évalué à 5 (+4/-1).

            Je pense que tu mets le doigt exactement ou est le problème: la maintenance.

            Les distros stable type debian, doivent patcher les softs pour qu'ils soient compatibles entre eux et donc mériter la réputation de stabilité. La volonté de fourguer le dernier soft tout frais, ben, c'est pas compatible.

            D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable. C'est pas possible. Il faut des compromis, et je pense que le fait de pouvoir installer un soft pour un user est pas mal. C'est ce que proposent ces formats, mais du coup, je pense qu'en effet ils repartent en arrière en ignorant totalement la notion de système. Bon, j'ai un peu peu bu, je peux pas argumenter correctement, je peux vous laisser construire sur cette notion de format compromis (dans le sens "entre deux extrêmes" pas dans le sens "troué").
            Perso, je pense qu'il serait plus efficace de recoder les outils type dpkg pour qu'ils soient utilisables sans etre root. Ca implique de retravailler l'archi systeme, de manièere autrement plus utile que merger /usr et / pour les bin & /sbin (qui en auraient pu être fusionnés avant en plus, m'enfin).

            En tout cas, a la vôtre. et pardon pour les fautes de français. Le reste des fautes, je dirais ça a tête repôsés

            • [^] # Re: Bien d'accord !

              Posté par (page perso) . Évalué à 7 (+4/-0).

              Les distros stable type debian, doivent patcher les softs pour qu'ils soient compatibles entre eux et donc mériter la réputation de stabilité.

              Notons qu'une partie du problème vient du fait que tous les logiciels partagent des composants en commun avec une version fixée. La plupart des logiciels de ton système utilisent par exemple glibc qui a une version unique. Pourtant ces logiciels ont été développés et testés probablement avec des versions différentes les uns des autres. Les distributions en général doivent donc corriger ces écarts de compatibilités évidentes et corriger les problèmes que cela implique aussi.

              C'est une des limites du modèle traditionnelle d'une distribution, qui est très gourmande aussi en travail humain pas forcément passionnant.

              D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable. C'est pas possible. Il faut des compromis, et je pense que le fait de pouvoir installer un soft pour un user est pas mal. C'est ce que proposent ces formats, mais du coup, je pense qu'en effet ils repartent en arrière en ignorant totalement la notion de système.

              Pas du tout, au contraire même.

              Une distribution classique pure dépôt à l'ancienne justement mélange tout. Firefox par exemple installé via les dépôts fait parti du système. Rien ne le différencie du reste. Mêmes répertoires d'installations, mêmes droits nécessaires pour l'installer ou le désinstaller, mêmes conséquences en cas de failles, même difficulté pour obtenir une version différente que celle proposée, etc.

              Oui bien sûr, proposer Firefox par ce biais offre des avantages aussi, je ne le nie pas. Mais le choix Flatpak / Snap n'est pas absurde et cela répond aussi à de vrais besoins. Enfin on peut utiliser par exemple une distribution comme Ubuntu 18.04 LTS mais avoir en même temps son logiciel préféré à la dernière version (GIMP, Firefox, LibreOffice ou autres) car on en a besoin pour une fonctionnalité précise sans remettre en cause le reste qu'on apprécie. C'est aussi un confort et une flexibilité immense.

              Nous avons affaire ici à des besoins qui nécessitent des solutions diverses et antagonistes sur le fond. Croire que seul un modèle (type dépôt) peut répondre à tout le monde de manière satisfaisante est une erreur. Du coup, pourquoi critiquer le fait que certains poussent pour des modèles différents ? Le modèle traditionnel ne peut pas disparaître : le code de tous ces logiciels sont libres, on pourra toujours créer une distribution à l'ancienne à la main.

              • [^] # Re: Bien d'accord !

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

                Je suis d'accord, même bien bourré…. en soit, une distro devrais pas être l'autorité absolue. Chaque user devrais pouvoir installer un soft.

                Enfin, s'il est permis par le ldap. Et quelle distro intègrre ça? Aucune. Windows le fait depuis au moins 10 ans, sorry. Je veux faire une distro pour ça, mais, c'est un bordel de fou, il me faudra au moins 2 voire 3 mois pour piger comment ça marche, les bases!

                A la base, j'avais estimé a 2 semaines, mes chevillles sont encore un peu enflées, on dirait

                • [^] # Re: Bien d'accord !

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

                  non !
                  un user ne devrait pas voir le droit d'installer un soft
                  c'est le role d'un admin (root)

                  Imagine si en entreprise tout le monde peut installer n'importe quoi …

                  • [^] # Re: Bien d'accord !

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

                    Mmh bizarre, je vois mal demander à un admin l'autorisation d'installer un logiciel quand on bosse en r&d. Je n'ai jamais travaillé dans de telles entreprises.

                  • [^] # Re: Bien d'accord !

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

                    La boîte qui ne me laisse pas admin de ma machine, elle ne va pas me voir longtemps…

                  • [^] # Re: Bien d'accord !

                    Posté par . Évalué à 1 (+0/-0). Dernière modification le 20/10/19 à 14:07.

                    les 2 sont possible mon capitaine : on peut restreindre l'installation de Flatpak à l'utilisateur root, ou pas.

                    Maintenant aujourd'hui, les admin s'occupent de plein de choses (faire marcher les applications métier entre autres), et l'ordinateur pro est aussi utilisé dans le cadre privé. Vouloir restreindre l'installation de programme à l'admin va être frustrant… Nous installons tous les PC, et rien n'est installé par l'utilisateur final mais je ne pense pas que cela rende le réseau tellement plus sûr. Tout le monde cède irréversiblement vers les WeeChat, Skype et autres. Il faut des solutions qui contiennent ces applications.

                    Certes, il y a des failles, mais elle sont bien plus difficile à mettre en oeuvre, et bien peu sont finalement exploitées. Après il y a Meltdown et Spectre, mais le code exploitant ces failles est détectable facilement statiquement ou pendant leur exécution. Malgré des millions d'application, les stores restent relativement sûr.

                    Dans un autre genre : Est-il simple aujourd'hui d'acheter un Wifi en entreprise qui n'accède qu'a internet (et pas au réseau local) ? Rien que ça, c'est déjà une gageure et c'est une porte bien grande ouverte aux problèmes de sécurité.

              • [^] # Re: Bien d'accord !

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

                Pardon, j'ai répondu qu'a une partie.

                Le reste sera pas mieux, mais, tu m'as répondu, c'est de mon devoir de faire de meme.

                Les distributions en général doivent donc corriger ces écarts de compatibilités évidentes et corriger les problèmes que cela implique aussi.

                C'est une des limites du modèle traditionnelle d'une distribution, qui est très gourmande aussi en travail humain pas forcément passionnant.

                C'est aussi ce qui fait leur robustesse.
                Il est vrai que le travail manuel est énorme, mais c'est justement a mes yeux une des raisons majeures de confiance. Que l'on est en droit d'accorder a du privé, mais je préfère croire des passionnés. En vrai, ces gens m'ont permis d'apprendre a me méfier d'eux, au point de lire le code C de presque tout.

                Pour faire ça, il faut sélectionner des logiciels simples a lire, et connaître son OS. Je sais sélectionnner, mais je maitrise encore mal mon OS, c'est pour ça que j'aime mon job: je peux galoper après des cerveaux si précis, avec un recul en plus, que, jamais je pourrais les rejoindre: soit je reste derrière, soit je les dépasserai. Si j'arrive a grimper leurs épaules.

                • [^] # Re: Bien d'accord !

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

                  c'est pour ça que j'aime mon job: je peux galoper après des cerveaux si précis, avec un recul en plus, que, jamais je pourrais les rejoindre: soit je reste derrière, soit je les dépasserai. Si j'arrive a grimper leurs épaules.

                  Génial !

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Bien d'accord !

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

              D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable.

              C’est pourtant ce que Windows offre. Mon système est à jour. Mes applis sont à jour. C’est stable. Je peux avoir plusieurs versions du même soft sans prise de tête interminable.

              La dernière fois que j’ai voulu compiler LibreOffice sur Linux, il fallait installer GCC7, et GCC7 voulait désinstaller quasiment tous les paquets de mon bureau. Génial… Il a fallu que j’installe une autre distro.
              C’est vraiment pénible ce sac de nœuds sans fin des dépendances. Sans compter les packageurs qui font n’importe quoi avec les dépendances requises par les logiciels.

              • [^] # Re: Bien d'accord !

                Posté par (page perso) . Évalué à 4 (+1/-0).

                Je peux avoir plusieurs versions du même soft sans prise de tête interminable.

                Autant le reste je suis d'accord, autant ça ce n'est pas gagné.

                • [^] # Re: Bien d'accord !

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

                  Beaucoup de logiciels existent en version portable. C’est très fréquent.
                  Et il y a aussi https://portableapps.com/.
                  À chaque fois que j’ai cherché une appli en version portable, je l’ai trouvée.
                  C’est comme ça que je fait cohabiter pas mal de versions de LibreOffice.

                  • [^] # Re: Bien d'accord !

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

                    ça ne fonctionne que sous windows, pas mac OSX, pas *BSD ni aucune distro Linux ; ça reste un peu limité :/

                    mais oui, c'est utile pour survivre en environnement hostile :-)
                    mon préféré : git-bash qui me redonne un vrai terminal utilisable :D

          • [^] # Re: Bien d'accord !

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

            Donc t'es en train de dire que Flatpak va utiliser mes bibliothèques partagées ? Qu'on pourra en installer que depuis des dépôts officiels, avec clefs de validation des paquets, comme les paquets logiciels classiques des distros et que ca ne sera pas possible de les mettre en téléchargement depuis n'importe quel site ? Qu'il sera impossible de repackager un Flatpak pour lui inclure des trucs du genre Avast pour Linux ou un popup publicitaire ?

            Opera le fait depuis 10 ans.

            • [^] # Re: Bien d'accord !

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

              Pardone la poche que je suis, mais, tel que je lis, il dit juste:

              On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.

              MAIS LE PUTAIN DE BON POINT QUI ÉCRASE TOUT MAUVAIS SYMPTOME, C'EST QUE LE TRUC EST A JOUR… j'ai mis assez de caps lock la? J'ai un doute….

              • [^] # Re: Bien d'accord !

                Posté par (page perso) . Évalué à 7 (+4/-0).

                On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.

                Tu devrais arrêter de troller en étant bourré, franchement…

                Tout d'abord Flatpak (je ne parle pas des autres) apporte une isolation du processus pour limiter les possibilités de nuisance au maximum. C'est sans doute plus sûr de se servir de Flatpak que d'utiliser un logiciel mal codé mais fourni par ta distribution.

                Ensuite, on oublie qu'il y a des technos type PPA, Copr, etc. pour installer des dépôts tiers pour installer des trucs que sa distribution ne fournie pas. Ces dépôts sont non sûrs également, pourtant il ne semble pas que leur existence soit remise en question.

                Enfin, rien n'empêche de distribuer les Flatpak au sein d'un dépôt. Ta distribution pourrait même en avoir une ! C'est d'ailleurs ce que fait Flathub, et Fedora projette de le faire aussi à terme. Ce qui permet de gérer les mises à jour, mais aussi de n'installer que les Flatpak de confiance, etc.

                • [^] # Re: Bien d'accord !

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

                  Ensuite, on oublie qu'il y a des technos type PPA, Copr, etc. pour installer des dépôts tiers pour installer des trucs que sa distribution ne fournie pas. Ces dépôts sont non sûrs également, pourtant il ne semble pas que leur existence soit remise en question.

                  Ben pour le coup, les PPA, j'ai toujours trouvé que c'était une horreur absolue : chaque PPA que tu installes, tu dois lui faire une confiance presque absolue. Le truc a le pouvoir de te remplacer des binaires dans ton système sans que tu ais un vrai contrôle. Et y'a un milliard de PPA mal maintenu, pas un mec pas bien identifié qui sont recommandés sur un demi million de forums…

                  Franchement, je pense que ce truc devrait disparaitre !

                  • [^] # Re: Bien d'accord !

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

                    C'est une question d'implémentation si c'est le cas (je ne sais pas, je n'utilise pas). Avec un peu de pinning, ça n'arrivera pas. Ils pourront toujours installer un paquet que tu n'a pas dans ta distribution, mais c'est justement ce qui leur est demandé.

                • [^] # Re: Bien d'accord !

                  Posté par (page perso) . Évalué à 1 (+1/-2). Dernière modification le 17/10/19 à 20:11.

                  Tout d'abord Flatpak (je ne parle pas des autres) apporte une isolation du processus pour limiter les possibilités de nuisance au maximum. C'est sans doute plus sûr de se servir de Flatpak que d'utiliser un logiciel mal codé mais fourni par ta distribution.

                  Il s'avère que les moyens d'isolations sont moins étanches qu'on peut le croire. Les seules isolations que je n'ai pas encore vu se faire percer sont à minima de l'ordre de la VM (coucou Qubes OS). De plus, l'isolation ne protège pas contre les ajouts de popups publicitaires par exemple, de bout de code de télémétrie, etc. En fait, l'isolation n'est pas un processus magique rendant d'un coup un logiciel saint, mais plutôt une sécurité (pouvant être percée) pour éviter que le dit logiciel n'ait accès à tout. Cependant, le dit logiciel peut toujours faire sa vie.

                  Ensuite, on oublie qu'il y a des technos type PPA, Copr, etc. pour installer des dépôts tiers pour installer des trucs que sa distribution ne fournie pas. Ces dépôts sont non sûrs également, pourtant il ne semble pas que leur existence soit remise en question.

                  Je n'ai pas entendu parler d'une telle technologie dans la quinzaine de distribution que j'utilise, ou que j'ai utilisé. Généralement lorsqu'on cherche la façon d'ajouter un dépôt, on a le droit sur le wiki de la distro (si elle est généraliste) les dangers d'ajouter un dépôt externe Mais bon, j'ai besoin de faire ce genre de chose qu'en entreprise, pour des logiciels déjà éprouvés, qui proposent des dépôts séparés pour des versions de bibliothèques (mais s'intégrant sans conflits).
                  Bon aller, je vais arrêter de faire le malin et bien accepter que tu parles d'un truc dispo que sous une seule distribution, dont régulièrement les choix technologiques sont remis en question (Mir, upstart, Unity, les PPA et d'autres). Bah justement, au cours de ces 10 dernières années, j'ai entendu pas mal de monde râler sur le fonctionnement des PPA et sur leur existence même.
                  Par contre, jamais entendu parler de Copr ou autre, ca doit être des trucs pas très répandus.

                  Enfin, rien n'empêche de distribuer les Flatpak au sein d'un dépôt. Ta distribution pourrait même en avoir une ! C'est d'ailleurs ce que fait Flathub, et Fedora projette de le faire aussi à terme. Ce qui permet de gérer les mises à jour, mais aussi de n'installer que les Flatpak de confiance, etc.

                  Mes distributions préférées n'ont pas de dépôts Flatpak. Mais bon, si chaque distribution se met à gérer et maintenir son propre dépôt Flatpak, ca revient un peu à avoir des dépôts logiciels classiques, juste qu'on pourra utiliser ceux des autres distributions plus facilement (si il n'y a pas une incompatibilité qui apparaisse, par exemple avec une nouvelle version ou avec un fork, ca ne sera pas la première fois).

                  Opera le fait depuis 10 ans.

                  • [^] # Re: Bien d'accord !

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

                    Les seules isolations que je n'ai pas encore vu se faire percer sont à minima de l'ordre de la VM (coucou Qubes OS).

                    Pourtant, ça se fait régulièrement percé, rien qu'avec meltdown. Mais aussi avec des failles spécifiques.

                    https://www.cvedetails.com/cve/CVE-2018-19966/
                    https://www.cvedetails.com/cve/CVE-2017-15597/
                    https://www.cvedetails.com/cve/CVE-2019-17346/
                    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456
                    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14821
                    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10901
                    https://www.cvedetails.com/cve/CVE-2019-5519/
                    https://www.cvedetails.com/cve/CVE-2019-5518/
                    https://www.cvedetails.com/cve/CVE-2017-4924/

                    « 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: Bien d'accord !

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

                      Awi tiens, j'avais oublié celle là.
                      Et c'est pas parce que je ne les vois pas percé que ca n'arrive pas x). La seule isolation qu'on connaisse d'à peu prêt sûr, c'est une machine physique complètement isolée des autres (et avec quelques particularités matériels spécifiques).

                      Bon sinon, pour ceux qui moinssent, j'aimerais bien continuer la discussion avec vous, je suis ouvert à vos opinions :).

                      Opera le fait depuis 10 ans.

                    • [^] # Re: Bien d'accord !

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

                      rien qu'avec meltdown

                      Ouais, enfin Metldown ça compte pas, ça touche absolument tout.

                  • [^] # Re: Bien d'accord !

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

                    Il s'avère que les moyens d'isolations sont moins étanches qu'on peut le croire. Les seules isolations que je n'ai pas encore vu se faire percer sont à minima de l'ordre de la VM (coucou Qubes OS).

                    Personne n'a dit que l'isolation des processus étaient une sécurité parfaite. Il y a des trous ou des limites, on le sait. Mais entre ne pas avoir d'isolation du tout et en avoir une qui présente des limites ou failles, le second restera toujours préférable au premier.

                    De plus, l'isolation ne protège pas contre les ajouts de popups publicitaires par exemple, de bout de code de télémétrie, etc.

                    Oui, et ? Ta distribution non plus ne te protège pas là dessus. Les mainteneurs ne sont pas des auditeurs de code ou de projets, ils peuvent passer à côté de tas de choses qu'ils jugeraient inacceptables. Et ils peuvent laisser aussi volontairement les éléments de télémétries car cela a aussi un intérêt. Genre la version de Firefox proposée par toutes les grandes distributions Linux dispose d'éléments de télémétrie. Est-ce choquant ? Non.

                    Puis si tu n'aimes pas la pub ajoutée par l'éditeur du Flatpak, soit tu trouves un autre fournisseur qui ne l'ajoute pas. Soit, parce que le code est libre, tu le fais toi même.

                    Par contre, jamais entendu parler de Copr ou autre, ca doit être des trucs pas très répandus.

                    C'est juste le PPA de Fedora, une broutille quoi. Et je précise que l'infrastructure Copr est maintenu par Fedora elle même : elle fournie de quoi créer facilement des dépôts personnels pour ajouter ou tester des paquets qui ne font pas sens dans les dépôts officiels.

                    Tu es d'assez mauvaise foi en ignorant l'usage massif de petits dépôts personnels pour contourner les limites des dépôts à l'ancienne maintenus par les distributions.

                    Mes distributions préférées n'ont pas de dépôts Flatpak.

                    Et ? je dis juste qu'une distribution peut le faire ou que quiconque peut le faire. Flathub le fait par exemple. Cela permet de résoudre la critique récurrente quant à l'absence de dépôts : ici tu as un tiers de confiance qui gère / ajoute des paquets sous certaines conditions, tu peux facilement avoir accès à tous les programmes qu'il propose et la mise à jour est automatique et centralisé. De quoi réduire l'écart entre les deux mondes.

                    Mais bon, si chaque distribution se met à gérer et maintenir son propre dépôt Flatpak, ca revient un peu à avoir des dépôts logiciels classiques

                    Le but n'est pas que chaque distribution le fasse, mais que cela est une possibilité. Qui n'est en tout cas pas plus contraignante que la situation actuelle.

                    Et cela a aussi de l'intérêt. Si un utilisateur d'Ubuntu veut la version de LibreOffice plus récente proposée par Fedora, il pourra facilement le faire. Si un utilisateur de Fedora veut une version plus stable de Firefox proposée par Debian (ESR + correctifs perso), il pourrait le faire aussi facilement. Cela découple en fait la base du système et les applications haut niveau. Cette flexibilité est très intéressante que ce soit en contexte professionnelle comme personnelle.

                    Il suffit de parcourir les forums des différentes distros pour voir que les utilisateurs cherchent toujours de contourner les dépôts officiels pour faire à la Windows. Et pour des raisons légitimes. Donc pourquoi rejeter toutes les solutions qui permettent de les satisfaire ? Leur besoin n'est pas légitime ?

                    D'autant que Flatpak ou Snap ne remet pas en question la possibilité de faire une distribution comme aujourd'hui. Le code de tous les projets restent libres, faire des paquets comme aujourd'hui sera toujours possible même si Flatpak et Snap s'imposent.

                    • [^] # Re: Bien d'accord !

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

                      Oui, et ? Ta distribution non plus ne te protège pas là dessus. Les mainteneurs ne sont pas des auditeurs de code ou de projets, ils peuvent passer à côté de tas de choses qu'ils jugeraient inacceptables. Et ils peuvent laisser aussi volontairement les éléments de télémétries car cela a aussi un intérêt. Genre la version de Firefox proposée par toutes les grandes distributions Linux dispose d'éléments de télémétrie. Est-ce choquant ? Non.

                      Rien à voir avec mon propos, je ne parle pas d'audit de l'application mais de vecteurs de distribution de logiciels.

                      Les paquets présents dans mes distributions habituels ont reçu une validation pour l'intégration aux dépôts. Ca implique donc de vérifier que le logiciel ne balance pas 50 popup à l'utilisation (sinon il dégage) ou n'installe pas d'autres logiciel en même temps (sinon il dégage). Ce qu'un Flatpak distribué par un site random n'assure pas du tout en fait.
                      Pour ce qui est de la télémétrie de Firefox, elle est désactivable. Pareil pour la télémétrie de la distribution si il y en a. Par contre, un Flatpak distribué par un site random peut avoir une partie de télémétrie ajouté par le dit site sans que l'utilisateur en soit averti ni qu'elle soit désactivable. Certes un logiciel peut le faire, alors autant ne pas multiplier les vecteurs d'ajout d'outils de télémétries.

                      Autrement dans mon propos, je ne parle pas de la fiabilité du logiciel installé, que ce soit un Flatpak ou un paquet logiciel de la distribution le problème reste le même, mais de la fiabilité du media d'installation. J'ai bien plus confiance dans un paquet logiciel fourni par les dépôts officiels de ma distribution que dans un Flatpak distribué par n'importe quel site au hasard trouvé sur le web. Tu me diras que j'ai qu'à passer par un site "sérieux" de Flatpak (j'en connais aucun, j'utilise pas ce format), mais c'est la réponse trop facile à faire, je reste un utilisateur averti. Par contre pour un utilisateur non averti qui a fait le choix de ne pas utiliser Windows ou d'utiliser Linux pour diverses raisons pas forcément techniques, il y a un risque loin d'être négligeable de tomber sur un site ayant repackagé les Flatpaks de façon malveillante. Les dépôts officiels d'une distribution servent justement entre autre à fournir des logiciels empackagés d'une façon honnête et non malveillante. Un site lié à aucune distribution fourni des Flatpaks dans le but qu'il souhaite, tout comme les sites de logiciels pour Windows le font.

                      Soit, parce que le code est libre, tu le fais toi même.

                      Ou alors parce que je suis libre de mes choix je vais voir ailleurs. À un moment faut voir ce que vous voulez aussi. Avec ce genre de remarque, faut pas s'étonner qu'on dépasse pas les 5% de parts de marchés, toutes distributions confondues, dans la partie grand publique.
                      Autrement, ca serait avec plaisir que j'accepterai tes dons pour pouvoir suivre une formation me permettant de "faire moi même". Je les attends même avec impatience.

                      C'est juste le PPA de Fedora, une broutille quoi. Et je précise que l'infrastructure Copr est maintenu par Fedora elle même : elle fournie de quoi créer facilement des dépôts personnels pour ajouter ou tester des paquets qui ne font pas sens dans les dépôts officiels.

                      J'utilise Fedora au boulot, jamais entendu parlé de Copr. C'est toujours bon à connaître pour la culture, si jamais un des utilisateurs (plutôt des devs) que j'ai aidé à passer sous Fedora me pose la question.

                      Tu es d'assez mauvaise foi en ignorant l'usage massif de petits dépôts personnels pour contourner les limites des dépôts à l'ancienne maintenus par les distributions.

                      Que ca soit sous ArchLinux (et ses dérivés), Debian (et ses dérivés), FreeBSD (et ses dérivés), Fedora, CentOS ou Gentoo (et Sabayon), je n'ai jamais eu besoin d'utiliser de petit dépôt persos en fait. Les seuls dépôts externes que j'ai ajouté sont ceux proposés par des éditeurs d'applis serveurs, pour CentOS. Et pourtant sur mon ordi perso (actuellement sur Arch c'est il est passé sous pleins d'autres distros) je joue aux JV, je fais de la photo, je joue avec mes systèmes, j'utilise du hardware exotique (lecteur de smartcard, hardware de gaming, interface neurale), bref j'ai un rapport avec mes OS assez large d'une façon générale. Mais ca vient peut-être du fait que j'ai pas hésité à changer de distribution pour aller vers celle qui me plaisait le plus et collait le plus à mes usages. Après tout, on ne va pas sur une Debian Stable si on souhaite avoir les dernières versions des logiciels.

                      Tu vas me dire que oui, je suis un utilisateur averti, je fais de mon cas une généralité, blablabla. Si tu veux on peut étendre ce propos à mon entourage composé de devs qui ne connaissent rien au fonctionnement d'un OS, mais aussi de néophytes, de gens qui l'utilisent au travail mais sans forcément volonté de leur part, de gens qui ont voulu quitter Windows par lassitude, de gens pas forcément jeune dans ce dernier cas. Bah en fait, ils n'ont pas besoin non plus d'utiliser de dépôts persos à partir du moment où la distribution de base est bien choisie.

                      Et ? je dis juste qu'une distribution peut le faire ou que quiconque peut le faire. Flathub le fait par exemple. Cela permet de résoudre la critique récurrente quant à l'absence de dépôts : ici tu as un tiers de confiance qui gère / ajoute des paquets sous certaines conditions, tu peux facilement avoir accès à tous les programmes qu'il propose et la mise à jour est automatique et centralisé. De quoi réduire l'écart entre les deux mondes.

                      Tout à fait, n'importe qui peut faire un dépôt de Flatpak, dans des buts divers et variés. Comme la distribution massive d'un logiciel en plus intégré dans tout les Flatpaks proposés, de adware, ou d'outils de télémétries. Cf plus haut dans ce commentaire.

                      Et cela a aussi de l'intérêt. Si un utilisateur d'Ubuntu veut la version de LibreOffice plus récente proposée par Fedora, il pourra facilement le faire. Si un utilisateur de Fedora veut une version plus stable de Firefox proposée par Debian (ESR + correctifs perso), il pourrait le faire aussi facilement. Cela découple en fait la base du système et les applications haut niveau. Cette flexibilité est très intéressante que ce soit en contexte professionnelle comme personnelle.

                      Quand on parle de découpler la partie système et applicative, j'ai très fortement envie de dire pour faire un peu comme sous FreeBSD quoi ;). Mais je m'en abstiendrais parce que clairement la séparation entre les deux est bien plus importante, ca serait plutôt comme ce que permet de faire Windows ou MacOS X (la dernière fois que je m'en suis servi date un peu cela dit).
                      Cette séparation est tout à fait louable, à partir du moment où l'utilisateur a un gestionnaire de Flatpak pour les garder à jour. Sinon on arrive dans une situation similaire à Windows ou MacOS, qui est un peu un des points les plus importants en sécurité informatique : la non installation des mises à jours de sécurités des applications.
                      Par contre, présenter deux gestionnaires de paquets à un utilisateur non averti est un excellent moyen de le perdre. C'est comme ca qu'on se retrouve avec, par exemple, deux versions de LibreOffice différentes installés, que l'utilisateur pense avoir installé une version plus récente avec un Flatpak mais se retrouve à ouvrir ses documents avec la version de sa distribution, et finalement se retrouve à porter un jugement négatif sur LibreOffice, sa distribution, voir l'écosystème GNU/Linux en général dans le pire des cas.
                      D'ailleurs ca me fait penser à une question un peu biscornue : est-ce qu'un programme installé en Flatpak peut se lancer directement en ligne de commande comme un programme installé par le gestionnaire de paquet, et si oui, comment ca se passe quand les deux versions sont présentes ?

                      Opera le fait depuis 10 ans.

                      • [^] # Re: Bien d'accord !

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

                        Je n'ai jamais vu de chartes des paquets d'une distribution linux. Si tu en as une sous la main, ça m'intéresse. On peut considérer la définition du logiciel libre selon Debian, mais ça me paraît assez loin de ce dont tu parle.

                        Tu amalgame une techno avec son usage. FP peut travailler sans dépôt, c'est potentiellement gênant effectivement. Ça fait perdurer des usages dangereux comme on l'a déjà aujourd'hui (en particulier via curl ... | sh). Mais il donne la possibilité de faire de la distribution logiciel hors distribution linux. Tu peux voir la fondation Apache créer le sien par exemple pareil pour gnu. Les innombrables projets qui créent leur propre dépôt debian (mongo, docker, chrome,…) peuvent faire un travail plus universel et ne pas laisser sur le carreau les utilisateurs de distributions trop exotiques. Enfin ça peut être utile pour des choses comme debian-multimédia.

                        La multitude de gestionnaire de paquets elle est d'abord du fait des distributions linux qui chacune se sent obligée de montrer qu'elle est différente. Ensuite là il y a une solution concerté qui a une chance et vocation à remplacer toutes les méthodes à l'arrache que l'on a aujourd'hui.

                        FP ne fait pas le café, il ne fait pas revenir l'être aimé, il est juste une proposition pour passer d'une situation pourrie à un peu moins mieux.

                        Et mon dieu, c'est clair qu'il n'est pas parfait…

                        • [^] # Re: Bien d'accord !

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

                          Je n'ai jamais vu de chartes des paquets d'une distribution linux. Si tu en as une sous la main, ça m'intéresse. On peut considérer la définition du logiciel libre selon Debian, mais ça me paraît assez loin de ce dont tu parle.

                          Je n'ai jamais parlé de charte, mais de paquets qui dégagent si on constate des fonctionnements clairement malveillant. Ca arrive régulièrement, suffit de suivre un peu les évolutions des dépôts.
                          En fonction de la distribution il n'y a d'ailleurs pas forcément besoin de charte, ca peut se faire mécaniquement. Par exemple pour Arch, l'installation des nouveaux programmes, non-vérifiés par les mainteneurs de paquets, passe par AUR. Dans AUR, il existe un système de vote et de commentaires de paquets.
                          Pour Debian, avant qu'un paquet se retrouve dans Stable, il doit satisfaire différents critères de stabilités. Autrement, il aura du mal à passer de Sid à Unstable, et de Unstable à Stable.
                          Pour Red Hat et ses dérivés, les dépôts sont maintenus par Red Hat qui a tout intérêt à avoir des paquets cleans si ils ne souhaitent pas perdre de PdM.

                          Tu amalgame une techno avec son usage.

                          Non, à la base je fais juste remarquer que Flatpak permet exactement les mêmes dérives que les sites d'installations de logiciels Windows. Après on me vend de la sécurité, je fais remarquer que cette dite sécurité ne pare en rien les dérives en question, ce à quoi on me fait remarquer que la sécurité n'est pas l'objet de Flatpak, que si je veux mieux j'ai qu'à faire et que je fais des amalgame. Faudrait choisir un peu, hein :)

                          La multitude de gestionnaire de paquets elle est d'abord du fait des distributions linux qui chacune se sent obligée de montrer qu'elle est différente. Ensuite là il y a une solution concerté qui a une chance et vocation à remplacer toutes les méthodes à l'arrache que l'on a aujourd'hui.

                          Non, les gestionnaires de paquets ne sont pas des solutions à l'arrache (dire ca c'est un peu insulter les devs des distributions en fait) et Flatpak n'a pas à vocation de les remplacer (en particulier pour la partie système).

                          Pour le reste, j'ai déjà donné mon opinion plus haut, flemme de me répéter.

                          Opera le fait depuis 10 ans.

                          • [^] # Re: Bien d'accord !

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

                            Non, les gestionnaires de paquets ne sont pas des solutions à l'arrache (dire ca c'est un peu insulter les devs des distributions en fait)

                            Je n'insulte personne, j'affirme qu'un gestionnaire de paquets avec gestion des dépendances ça n'a rien de triviale. On revois éternellement de nouvelles personnes arriver en expliquant que ce qu'ils font c'est plus simples alors qu'ils ont surtout réimplémenter les bugs corrigés il y a longtemps chez leurs prédécesseurs. Critiquer leur travaux ce n'est pas les insulter ou alors je pourrais te répondre que ces gens qui pensent réimplémenter des gestionnaires de paquets en quelques semaines insultent leurs prédécesseurs.

                          • [^] # Re: Bien d'accord !

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

                            Non, à la base je fais juste remarquer que Flatpak permet exactement les mêmes dérives que les sites d'installations de logiciels Windows.

                            C'est vrai. Et c'est pour ça qu'il faut faire avec flatpack comme tu ferais sous Windows : ne prendre le paquet que sur le site de l'éditeur du logiciel. Tu constateras qu'il faut faire plus ou moins la même chose avec AUR : lire attentivement le PKGBUILD et t'assurer, notamment, que la source est correcte. Car les paquets ne sont pas gérés pas l'équipe de Arch (et il y a eu des cas de paquets vérolés). Et tu passes par un outil tiers (pas par Pacman, pas par le gestionnaire de paquets de la distribution) pour installer ton logiciel.
                            Bref, sur la sécurité, flatpack n'est pas si différente de AUR… Charge à l'utilisateur de vérifier ce qu'il installe.

                            • [^] # Re: Bien d'accord !

                              Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 22/10/19 à 20:30.

                              Tu noteras que pour AUR, ce point là est très bien expliqué sur le wiki de Arch. Il est aussi largement envisageable de s'en passer.
                              A côté, un peu partout, il y a des petits messages disant également que Arch n'est pas une distro pour débutants, contrairement à Flatpak qui est vendu comme la solution miracle à tout le monde. Tu vois le problème qui se pose.

                              Pour la culture, je viens de regarder rapidos de ce que j'ai qui vient de AUR. Dedans, on y retrouve :
                              - des programmes proprios (AUR, FlatPak ou autre, le problème reste un peu le même là)
                              - des pilotes proprios d'imprimantes (idem du coup)
                              - des versions expérimentales de certains paquets disponible normalement dans les dépôts(wine-staging en fait)
                              - des outils que je pourrais avoir via le dépôt de Blackarch maintenant (du coup faudrait que je le fasse)

                              Charge à l'utilisateur de vérifier ce qu'il installe.

                              Sous Arch, quand un utilisateur râle sur un truc qu'il a cassé salement lui-même alors que ca aurait pu être évité, il avait qu'à RTFM avant : c'est un peu le principe de cette distro.
                              Par contre, quand t'auras la moitié des utilisateurs qui vont débarquer sur les forums en disant que Linux c'est de la merde parce qu'un Flatpak installé a tout cassé, et que du coup ils retournent sous Windows, faudra pas se plaindre de voir les PdM passer de 5% à 2%.

                              Encore une fois, faut voir ce que vous voulez : un OS pour tout utilisateur, et essayer de se faire une ptite place de 3eme OS d'ordi de bureau pour être un minimum supporté et pris en compte, ou être un OS élitiste utilisé que par 3 nerds dans un garage (mais dans ce cas, Flatpak n'est finalement plus vraiment nécessaire).

                              Opera le fait depuis 10 ans.

                              • [^] # Re: Bien d'accord !

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

                                Flatpak installé a tout cassé

                                Ça n'est pas possible si j'ai bien compris. Tout au plus il peut avoir quelques logiciels qui interagissent avec ce flatpak qui vont fonctionner bizarrement.

                                Encore une fois, faut voir ce que vous voulez

                                Moi perso je ne veux rien, je laisse les gens qui font faire. Je ne vois pas pourquoi avoir une ambition quelconque si c'était le cas au lieu de répondre à des commentaires sur un sites d'aigris je contribuerais. Ta question n'a pas de sens pour des gens qui ne sont pas aux commandes d'une distribution. Nous, quidam de linuxfr, nous pouvons vociférer autant que l'on veut ça n'a pas vocation à être « volonté de la communauté linux ».

                                • [^] # Re: Bien d'accord !

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

                                  Oh, en effet, tu peux imaginer que c'était une discussion au bar du coin sur un article du canard local :)

                                  Opera le fait depuis 10 ans.

                              • [^] # Re: Bien d'accord !

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

                                Par contre, quand t'auras la moitié des utilisateurs qui vont débarquer sur les forums en disant que Linux c'est de la merde parce qu'un Flatpak installé a tout cassé, et que du coup ils retournent sous Windows, faudra pas se plaindre de voir les PdM passer de 5% à 2%.

                                Alors :

                                • Ils peuvent déjà tout casser. C'est la (mauvaise) mode aux "curl | sh" mais ceux qui sont susceptibles de taper ça sont généralement des dev donc ils vérifient. Les utilisateurs lambdas vont faire comme toujours : utiliser le programme fournit par la distro. Ici c'est de ça dont parle Ploum : sa distro lui donne des paquets snap. Mais le lambda ne saura même pas si c'est deb snap ou flomp. Il clique dans l'interface, ça installe. Donc pas plus de danger qu'avant, c'est la distribution qui gère.

                                • Je ne pense pas que Linux soit déjà à 5% mais dans tous les cas, tu FUD. Je ne vois pas ce qui permet de penser que ça va faire fuire ceux qui vont se contenter de passer par l'outil fournit par la distro. Les autres savent ce qu'ils font

                                • Personnellement, je ne veux rien à part un système qui marche. Ça fait longtemps que j'ai arrêté le prosélytisme. Je n'ai jamais utilisé flatpack/snap/autres parce que je n'en ai pas besoin. Si un jour ça arrive, je saurai gérer. Je m'adapte.

                                • [^] # Re: Bien d'accord !

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

                                  J'ai la très vague sensation que cette discussion commence à prendre une tournure sacrment stérile. Ce qui suit n'est que pour le plaisir rhétorique.

                                  Ils peuvent déjà tout casser. C'est la (mauvaise) mode aux "curl | sh" mais ceux qui sont susceptibles de taper ça sont généralement des dev donc ils vérifient. Les utilisateurs lambdas vont faire comme toujours : utiliser le programme fournit par la distro. Ici c'est de ça dont parle Ploum : sa distro lui donne des paquets snap. Mais le lambda ne saura même pas si c'est deb snap ou flomp. Il clique dans l'interface, ça installe. Donc pas plus de danger qu'avant, c'est la distribution qui gère.

                                  Me semblait qu'on parlait d'utilisateurs plutôt débutants, pour qui ouvrir un term pour installer un programme c'est plus compliqué qu'un marathon. Donc des utilisateurs qui ne font pas trop ce genre de choses en fait.

                                  Je ne pense pas que Linux soit déjà à 5% mais dans tous les cas, tu FUD. Je ne vois pas ce qui permet de penser que ça va faire fuire ceux qui vont se contenter de passer par l'outil fournit par la distro. Les autres savent ce qu'ils font

                                  Non, je ne pense pas.

                                  Personnellement, je ne veux rien à part un système qui marche. Ça fait longtemps que j'ai arrêté le prosélytisme. Je n'ai jamais utilisé flatpack/snap/autres parce que je n'en ai pas besoin. Si un jour ça arrive, je saurai gérer. Je m'adapte.

                                  Un système qui marche, c’est un OS capable d'exploiter le matériel. Pour que celui-ci puisse être exploité, faut des pilotes. Pour ca, faut que les industriel aient un minimum d'intérêt pour le faire. Je te laisse comparer avec les années 2000 ou FreeBSD pour voir où je veux en venir.

                                  Opera le fait depuis 10 ans.

              • [^] # Re: Bien d'accord !

                Posté par . Évalué à 2 (+0/-0). Dernière modification le 17/10/19 à 09:27.

                Pardone la poche que je suis, mais, tel que je lis, il dit juste:

                On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.

                MAIS LE PUTAIN DE BON POINT QUI ÉCRASE TOUT MAUVAIS SYMPTOME, C'EST QUE LE TRUC EST A JOUR… j'ai mis assez de caps lock la? J'ai un doute….

                Je pense que tu aurais du aller te coucher et arrêter de boire.

                Ce n'est pas la présence de flatpak ou pas qui permet ou empêche l'utilisateur à faire de la merde. Rien n'empêche d'installer un bin sans flatpak, il n'y a que le noexec qui permet d'empêcher ça et encore ça n'a une efficacité que limité puisque ça ne peut rien contre un langage interprété déjà présent sur le système.

                Du coup il est où le problème ?

                De plus ont fait souvent tout un patacaisse sur le boulot de mainteneur. Alors oui il est important il suit et backporte des patchs pour assurer les maj de sécurité en essayant de rien casser mais combien de mainteneurs font un réel audit de sécurité de ces projets upstream avec étude en détail du code, pen testing et fuzzing ?

                • [^] # Re: Bien d'accord !

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

                  Parce que tu crois vraiment que ceux qui font les paquets snap/flatpack font mieux que les mainteneurs des distributions ?

                  Moi, j'ai un (GROS) doute.

                  • [^] # Re: Bien d'accord !

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

                    Parce que tu crois vraiment que ceux qui font les paquets snap/flatpack font mieux que les mainteneurs des distributions ?

                    Moi, j'ai un (GROS) doute.

                    Parfois oui, parfois l'upstream peut paraître moins goret en mettant à jour toute l'appli au lieu de partir d'une version plus ancienne pour lui appliquer 'n' patches de sécurités à la louche.

                    Et puis tu veux qu'on ressorte le cas openssl/debian ?

  • # Re: Snap, Flatpak, Packagekit : c'est quoi ce bordel ?

    Posté par (page perso) . Évalué à 10 (+9/-0).

    Salut Lionel,

    C'est le foutoir surtout sur Ubuntu. J'utilise Debian et flatpak pour quelques logiciels. C'est nickel. Au final, j'ai pas mal de gestionnaire de paquets:

    • APT pour le système et l'essentiel des logiciels
    • flatpak pour quelques app: des jeux, Gimp, Blender, Pitivi.

    En plus, pour le dév:

    • docker pour certains services : cache APT, résolution DNS des conteneurs, etc.
    • pip dans ~/.local/ : Ansible, etc.
    • npm dans ~/.local/ : markdownlint, etc.

    Tu te souviens de ton idée Debian + GNOME = perfect desktop. Et bien c'est redevenu le cas depuis qu'Ubuntu part en vrille avec upstart, mir, unity, snap, etc. Un conseil : passe à Debian. Tu sera agréablement surpris.

  • # PackageKit est hors sujet

    Posté par (page perso) . Évalué à 9 (+8/-0). Dernière modification le 16/10/19 à 13:22.

    Snap et Flatpak sont effectivement plus ou moins équivalent, par contre PackageKit n'a rien à voir et est là depuis des lustres. Il permet d'abstraire la gestion des paquets via une interface commune. En bref en utilisant packagekit tu peux installer des paquets sans savoir si c'est dnf, apt, pacman derrière… En général packagekit était utilisé par quelques interfaces graphiques comme GNOME PackageKit. Seul problème, il est considéré comme obsolète par son propre mainteneur en plus d'être foutrement buggé.

    vanilla, ma distribution radicalement différente : http://projects.malikania.fr/vanilla

  • # témpoignage

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

    J'espère que ce témoignage empoignant n'était pas trop agressif ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Ça aurait pu être bien

    Posté par . Évalué à 5 (+4/-1).

    Si tout le monde s'était mis d'accord sur un format entre Flatpak, Snap, AppImage (je ne connais pas assez les différences entre chaque, mettons Flatpak pour l'exemple), et si les distributions avaient gardé simplement leur gestionnaire de paquets habituels :

    • les dev n'auraient qu'à fournir les sources, un flatpak, et c'est tout ;
    • les mainteneurs des distribs fourniraient des paquets pour leur distrib (comme avant quoi) ;
    • les utilisateurs utiliseraient par défaut le gestionnaire de paquet de leur distrib, et pourraient se rabattre sur flatpak si un soft n'est pas fourni par la distrib ou pas dans la version souhaitée.
    • [^] # Re: Ça aurait pu être bien

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

      Oui bien sûr, mais apparemment ce n'est pas juste se mettre d'accord sur un format, c'est aussi se mettre d'accord sur des fonctionnalités (bac à sable, sécurité, partage ou non de librairies, etc…).

    • [^] # Re: Ça aurait pu être bien

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

      AppImage ne fournit aucune sécurité, et n'est a ma connaissance pas géré par dépôts, juste l'utilisateur télécharge le fichier d'origine, le chmod, et l'exécute.
      Les autres semblent essayer de fournir des sécurités.

      J'ai lu plusieurs fois sur linuxfr que les autres ont aussi l'avantage du téléchargement incrémental, contrairement a appimage, mais les auteurs de ces commentaires n'ont jamais du essayer d'utiliser l'appimage de redeclipse2, sinon ils sauraient que c'est faux.

      Pour le reste, je n'en sais pas pas plus, je n'ai jamais testé fapfap/snap (désolé, pas pu résister), et jamais analysé un binaire AppImage, donc…

  • # La solution

    Posté par (page perso) . Évalué à 3 (+4/-3).

    Bref, comment tu fais, cher journal ?

    Ben MacOS + homebrew, what else?

    Mais sinon tu peux utiliser homebrew sous linux.

  • # Bof

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

    Je suis resté sous GNU/Linux tout ce temps, et apparemment c’est un peu comme Facebook : c’est omniprésent mais je suis jusqu’à maintenant complètement passé à côté. Malgré tout, ma vie se déroule sans soucis majeur.

    Snap est apparu dans Ubuntu quand je l’utilisais encore. Il suffisait de le désinstaller et de continuer sa vie. Aujourd'hui, je me rends compte que des trucs liés à Gnome sont installés par défaut sur un système Live que j'ai utilisé dans une VM ce weekend. Ce serait probablement une mauvaise idée de désinstaller ça aveuglément.

    Mais entre-temps, je suis passé par Debian et openSUSE, et là, c’est du apt/dpkg et du zypper/rpm pur et tout fonctionne comme ça a toujours fonctionné. Je marche en sifflotant à côté d’un champ de bataille et je le sais mais je ne m’en rend pas vraiment compte…

    Le plus gros défaut de Snap pour moi n’est pas technique : à ma connaissance, la séparation logiciels libres / non-libre n’est pas clair, du coup, ça ne m’intéresse pas trop.

    Une solution pour distribuer un logiciel sur n’importe quel distribution GNU/Linux sans difficulté me paraît pourtant souhaitable.

    • [^] # Re: Bof

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

      Un peu pareil. En restant sur la même Gentoo ces douze dernières années, probablement grâce à la fois au système de mise à jour continue et à la liberté que me laissent les codes employés je n'ai jamais vu débouler ces technologies chez moi. Ouf, vu l'âge de ma bécane.

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # pas obligatoire

    Posté par . Évalué à 2 (+0/-0). Dernière modification le 16/10/19 à 15:34.

    Packagekit n'est qu'une couche d'abstraction, perso ça ne me gène pas.

    Pour les autres ben si tu n'en veux pas tu peux t'en passer. Perso je trouve les snaps bien utiles pour des trucs bien précis, dans mon cas kubernetes et ses outils, pour le reste je ne l'utilise pas.

    Ces outils de packaging (j'ajouterais nix à la liste) ont aussi beaucoup de sens dans une distro immutable (fedora silverblue/atomic) avec une séparation claire système/userland.

    • [^] # Re: pas obligatoire

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

      Pour le coup, nix a aussi du sens dans une distro mutable puisque le boulot de nix c'est de te faire un environnent reproductible quel que soit la distro dans laquelle tu es.

  • # ça vient de qui ?

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

    Vérifie si ça vient de Regolith-Linux : certaines dérivées de distro installent tout plein de choses via Flatpak ou Snap ou Appimage ou … parce que les petits gars ne savent pas empaqueter. Dans ton cas, une dérivée d'Ubuntu un peu minimaliste avec le paquet Regolith devrait aboutir à une intallation propro.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: ça vient de qui ?

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

      Après recherches, c'est clairement Ubuntu qui package certains outils GNOME via Snap et, allez savoir pourquoi, des libraires GNOME 3.28 (!). J'ai tout supprimé sans observer le moindre problème. On dirait qu'à chaque release d'Ubuntu, y'a un peu plus de paquets via Snap et non via apt.

      • [^] # Re: ça vient de qui ?

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

        Oui c'est la politique ubuntu depuis quelques années déjà mais ça tout le monde est au courant. Si ça te dérange je ne comprends pas bien pourquoi tu as choisis d'utiliser ubuntu ou une de ses variantes.

  • # brute

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

    Perso j’ai désinstallé snapd et supprimé le répertoire dans lequel j’avais encore des traces de ce truc, et éventuellement j’ai réinstallé la calculatrice gnome…

    J’utilise Ubuntu avec i3 (pas la version regolith par contre mais c’est "pareil" pour notre problème), et tout va très bien depuis.

  • # Découverte de flatpak

    Posté par (page perso) . Évalué à 10 (+13/-0).

    Je tente de créer un paquet flatpak pour Newton Adventure, mais:

    • il ne gère pas maven, ça commence mal ;
    • il y a un runtime pour l'openjdk, mais sans documentation ;
    • je ne comprends pas où vont les sources quand on construit un paquet, la doc dit qu'elles sont copiées, oui mais où ???

    Bref ça va être encore une énorme et gigantesque galère de créer un paquet.

    Et après on s'étonne que les jeunes développeurs tombent dans la drogue et le curl|sh.

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Découverte de flatpak

      Posté par (page perso) . Évalué à -1 (+1/-4).

      Faire un flatpak, c'est aussi simple que de faire un paquet sous ArchLinux (voir encore plus simple dans certains cas).

      je ne comprends pas où vont les sources quand on construit un paquet,

      Tu as pas du beaucoup lire la doc pour demander cela…

      • [^] # Re: Découverte de flatpak

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

        Tu as pas du beaucoup lire la doc pour demander cela…

        Pas trouvé…

        Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: Découverte de flatpak

          Posté par (page perso) . Évalué à 4 (+1/-0). Dernière modification le 17/10/19 à 11:42.

          Pour préciser mon problème, dans Docker j'ai l'instruction ADD pour ajouter des fichiers. Je ne comprends comment cela fonctionne avec flatpak, j'ai essayé une source de type "dir", mais ça semble ne rien faire. Je ne sais pas où vont mes fichiers…

          Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Découverte de flatpak

      Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 17/10/19 à 12:23.

      J'ai eut le même genre de problèmes avec Paperwork. Heureusement pour moi, Mathieu Jourdan avait fait un début de Flatpak qui réglait le problème de l'installation des paquets Python. De mon coté, j'ai pu me concentrer sur les problèmes de fichiers de données spécifiques à la langue de l'utilisateur et sur le problème de l'accès aux scanners.

      Pour Maven, je pense que tu peux t'en sortir comme Mathieu Jourdan avait fait pour Python:
      - Compiler et installer Maven comme faisant partie du build Flatpak
      - Utiliser un mini Makefile bidon pour construire les builds suivants avec Maven

      C'est effectivement difficile, mais Flatpak offre ensuite plusieurs avantages:
      - Tu as une liste quasi-exhaustive des dépendances de ton programme.
      - Tes utilisateurs peuvent tester la dernière version de ton programme quelque-soit leur distribution.
      - Tes utilisateurs peuvent te faire des rapports de bugs indépendamment des 25000 versions des dépendances disponibles dans les diverses distributions.
      - Tu peux faire de l'intégration continue en mettant à jour ton dépôt Flatpak automatiquement.

      • [^] # Re: Découverte de flatpak

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

        Je ne comprends toujours pas comment ajouter un dossier. Une source de type "dir" ne fonctionne pas du tout.

        Par contre une source de type "git" fait bien un checkout \o/

        Une de type "file" avec une url vers un tar.gz aussi \o/

        Cool je vais pouvoir télécharger mes sources, le tar.gz de Maven et compiler le tout !

        Ah zut tiens, flatpack-builder ne propage pas http_proxy donc impossible pour Maven de télécharger les dépendances.

        Bon flatpak est pas près pour les entreprises…

        Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: Découverte de flatpak

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

          flatpack-builder ne propage pas http_proxy

          Flatpak-builder bloque volontairement le réseau pendant les builds de chaque composant. L'objectif est de s'assurer que la liste des dépendances est complète et que le build reste 100% reproduisible. C'est notamment pour éviter que des dépendances soient téléchargées pendant le build.

          Par exemple, lors de l'installation d'un module Python avec pip, si une dépendances n'est pas sur le système, pip va essayer de la télécharger. Et par défaut, il va tenter de télécharger la dernière version. Or ce pourrait ne pas être la même entre 2 tentatives de build différentes. Donc il faut que les dépendances soient installées avant explicitement (y compris les dépendances des dépendances, etc).

          • [^] # Re: Découverte de flatpak

            Posté par (page perso) . Évalué à 5 (+2/-0). Dernière modification le 20/10/19 à 01:43.

            Pas terrible:

            • je n'arrive pas à construire mon projet à partir du code compilé, car impossible de copier plusieurs fichiers (source de type dir qui ne fonctionne pas).
            • je ne peux pas utiliser une source de type git puis faire compiler mon projet par flatpak, car on ne peut pas utiliser de gestionnaire de dépendances.

            La seule solution que je vois, c'est de construire un fat jar avec toutes les dépendances, voire embarquer la jvm au cas où celle flatpak ne fonctionne pas (maven se plaignait de ne pas voir un vrai jdk).

            Mais du coup quel est l'intérêt de flatpak si le seul moyen de travailler avec c'est de tout embarquer dans un énorme et gigantesque binaire?

            Incubez l'excellence sur https://linuxfr.org/board/

            • [^] # Re: Découverte de flatpak

              Posté par . Évalué à 4 (+3/-0). Dernière modification le 20/10/19 à 13:36.

              il n'y a pratiquement aucun intérêt à utiliser Flatpak pour une application Java (ni le gestionnaire de paquet de la distribution d'ailleurs), sauf à vouloir proposer d'isoler l'application, (qui est quand même l'un des gros avantage de Flatpak). Java est assez indépendant des binaires de la distribution, dispose d'une bonne stabilité binaire, et propose des gestionnaires de dépendances qui fonctionnent par application et même par dépendance (les dépendances peuvent utiliser de multiple version d'une même dépendance).

              Par contre pour les applications Python, ça permet de les isoler du système de la volatilité de pip et autres. Il est très facile de casser une distribution ou un build avec pip.

              J'aime bien Python (on est dimanche, mais bon), par contre rien que pour Qt, entre PyQt[45], PySide, PySide2, le tout en Python2 ou Python3, installé via pip, conda, ou le package de la distro, le tout global à la distro, qui n'utilise pas la même version de gcc ni de Qt que pip et conda, on est très loin de la simplicité du monde Java pour la gestion des dépendances.

  • # Tu en as oublié un gros

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

    Tu as oublié Docker dans la liste, et LXD aussi.

    Enfin la dernière fois que j'ai essayé LXD, je ne suis même pas arrivé à tourner un container de base.

    En fait c'est tellement compliqué de faire un package pour Debian (ya tjs pas de PPA :-) qui soit dans la distro, et je ne parle pas des 6 mois pour être Debian Developer.

    Je comprends que la majorité de fasse plus de paquets, mais des images Docker.

    • [^] # Re: Tu en as oublié un gros

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

      En fait c'est tellement compliqué de faire un package pour Debian (ya tjs pas de PPA :-) qui soit dans la distro, et je ne parle pas des 6 mois pour être Debian Developer.

      Je comprends que la majorité de fasse plus de paquets, mais des images Docker.

      Pas moi, si ton objectif est juste d'installer ton blob sur une bécane.

      Si tu veux être un paquet Debian officiel, il faut suivre une tétrachiée de règles, un format fixe qui garantit tout plein de truc, et… mais en fait, on s'en fout.

      Le but d'un dev, c'est de distribuer son application. Pour la distribuer sur Debian, le plus simple, c'est de filer un paquet Debian binaire, proprio-style, pas un paquet source qui permets… euh… de se prendre la tête?

      Et un paquet binaire de Debian, ça se construit hyper facilement, promis. Allez, j'explique, s'pas bien long après tout:

      Il faut lancer la commande dpkg-deb -b $TARGET, $TARGET étant une arbo constituée, de mémoire, ainsi:

      • DEBIAN/control: fichier qui permets d'avoir le nom du paquet, sa version, ses descriptions courtes/longues, la homepage, etc… dans un format que même un enfant de 10 pourrait comprendre. C'est le seul fichier obligatoire;
      • DEBIAN/md5sums contiens les somme de contrôle md5 (on peut aussi utiliser SHA512 je pense). C'est basiquement la sortie de md5sums avec quelques arguments…
      • DEBIAN/post-inst (en gros) script lancé après chaque dépaquetage
      • DEBIAN/pre-inst (en gros) script lancé avant chaque dépaquetage
      • DEBIAN/post-rm (en gros) script lancé après chaque suppréssion
      • DEBIAN/pre-rm (en gros) script lancé avant chaque suppréssion
      • une arbo qui indique la ou iront les fichiers. En fait, la partie du système concernée par le paquet

      Vraiment, pourquoi viser l'officiel? C'est le job des mainteneurs, les paquets source Debian ont des patchs justement pour ça: l'intégrer aux changements systèmes de Debian.
      Rien n'empêcherait de faire un paquet avec un binaire lié statiquement qui s'installe dans /usr/local ou /opt…

      • [^] # Re: Tu en as oublié un gros

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

        D’autres exemples :

        • [^] # Re: Tu en as oublié un gros

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

          le traité empirique est nettement plus compliqué que ce que moi je fais pour construire un deb…

          Je commence a croire que c'est le manque de doc sur le format binaire qui est le problème de debian.

          Je cite, et vous m'excuserez des fautes, je suis hors d'état de conduire, et je ne devrais pas poster sur l'autoroute de l'information… mais je compte sur votre magnanimité, donc:

          Il nous faut créer quatre fichiers :

          debian/compat
          debian/changelog
          debian/control
          debian/rules

          c'est pas une citation exacte, j'ai viré la poncutaition et divers mots de jonction.
          Bref, seul control est vital. Je connaissais même pas l'existance de compat, en vrai. On se fait une dépêche en mode coop sur comment faire un deb proprio/freestyle propre, un jour? Je pense que ça permettrait d'aider a perdre cette réput injustifiée du format deb…

          Le changelog, c'est d'un pénible a maintenir… on sent que debian est née avant les DVCS, mais, pour être honnête, je ne connais aucun outil capable de gérer C ou C++ qui sache compiler en prenanant en compte facilement le versionning a base de hash. Dur sujet, faut dire. Mais même les tags sont absents… et un admin noob comme moi a pu pondre un script (de merde, je tenterais unjour de faire mieux, et de le publier d'abord sur le temps libre, puis de l'utiliser au taf, en ayant soin dans ce cas d'utiliser GPL) qui peut récup les tag+commit hash d'un dépôt pour générer un numéro de version.
          Le changelog, en soit, c'est plus dur, y'a une notion de politique: est-ce destiné a l'utilisateur, ou a l'admin, ou au contributeur? Pas facile.

          Le dernier fichier à rédiger est debian/rules

          Je croyais que ça devait pas générer un deb source? Ce truc est useless dans le cas d'un deb binaire.
          Le ficher rules, c'est en gros un makefile de ce que j'ai compris (confirmé par la 1ère ligne, en fait).

          purée, c'est ça, la ceinture blanche? J'ai pas un tiers des connaissances requises, et pourtant, promis, je peux te générer un .deb a partir d'un binaire proprio en moins de de 15 minutes…

          Je crois que la complexité, ça s'acquiert quand on cherche a faire du propre, du bien intégré et universel.
          Ce qu'on repproche a debian, justement, c'est de vouloir faire trop universel, et le pire c'est que ça marche pas: Debian reste, malgré les efforts (qu'il faut saluer) une distro GNU/linux. Les ports BSD ou non-GNU officiels semblent a l'état de bêta-test, et je suis gentil.

          Merci d'arrêter de balancer des rocquettes dans les pattes de cette distro. A la base, c'est censé être une distro geek friendly, pas user-friendly, et il reste des traces, très claires: je peux installer un paquet avec juste du shell unix, et je peux installer un système en mode archlinux, la stabilité en plus.

          J'ai parfois l'impression que les "nouveaux geeks" se contentent de lire 1 seul tutoriel, et se proclament maîtres de la techno en question, en ignorant tout de l'histoire et du fonctionnement interne…. le pire, c'est que ces gens semblent se croire aptes a critiquer des choses que peu d'entre nous seraient capables de recreer, même avec l'exemple sous le nez! Ou alors, je suis totalement idiot…. ça me choquerais pas, d'ailleurs, en soit.

          • [^] # Re: Tu en as oublié un gros

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

            On se fait une dépêche en mode coop sur comment faire un deb proprio/freestyle propre, un jour?

            J'avais fait un journal (je partais pas d'un truc proprio mais le principe est le même)

      • [^] # Re: Tu en as oublié un gros

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

        J'utilise fpm, c'est un peu la même idée.

        Les règles de l'empaquetage debian sont l'accumulation d'expérience depuis bientôt 40 ans. L'informatique a beaucoup changé depuis. Et puis le couplage debdiff + orig n'est franchement pratique.

        Ceci dit, une fois le paquet binaire produit (et le .changes), dpkg et apt font un bon boulot.

        • [^] # Re: Tu en as oublié un gros

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

          C'est un peu le point essentiel de apt/deb : c'est un enfer à packager (il y'a quelques années, j'ai tenté de m'y mettre, j'ai vite compris que je n'avais pas les neurones pour ce genre de travail) mais, pour un utilisateur, quel bonheur ! J'arrive à me dépétrer de n'importe quelle situation même avec les paquets deb les plus pourris.

          Et, ce petit traité empirique est effectivement une horreur. Quand j'ai vu ce qu'il appelle "ceinture blanche", j'ai laissé tomber (une fois de plus).

          • [^] # Re: Tu en as oublié un gros

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

            En fait, le problème du paquet debian source, c'est qu'il correspond au besoin de la distribution c'est à dire du développeur debian. Pour le mainteneur du projet, c'est beaucoup trop lourd.

            Un développeur debian voudrat gérer des patchs, des NMU et tout un tas d'autres problématiques.

            Le mainteneur d'une application ne veut pas de source intermédiaire entre ses sources et celles amonts.

            D'où la méthode répandue pour les mainteneurs de projet amont de générer directement un paquet debian binaire, sans passer par l'étape debian/.

            En soi, tout le monde a raison, c'est juste une question de point de vue.

          • [^] # Re: Tu en as oublié un gros

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

            Le format de paquet debian source correspond aussi à l'époque où il ne suffisait pas de donner un lien github pour pointer vers les sources. C'est à la charge de la distribution de fournir les sources amont ET les patchs de la distribution, pour satisfaire les contraintes légales. C'est valable aussi pour SRPM.

  • # debootstrap est ton ami

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

    Salut.

    Si tu considères (comme moi) que l'installateur de Debian installe trop de merdes par défaut, tu peux utiliser (c)debootstrap (l'un ou l'autre, peu importe).

    Je préviens, c'est une méthode d'installation très "low level", faut connaître son système un minimum, mais bon, on est sur linuxfr ici, ça devrais donc aller.

    Pour détailler un peu plus, quand j'installe une Debian maintenant, je commence par booter le CD en mode "dépannage" ou whatever. Je réponds vite fait à la chiée de questions dont on devrait se foutre royalement dans ce mode (domaine, nom de la machine, ce genre de choses) ainsi qu'a celles utiles (config réseau, sur quelle partition me chrooter ou juste me chrooter dans le contexte de l'installateur) en prenant soin de chrooter dans le contexte de l'installateur.

    De là, je fais un p'tit fdisk, histoire de préparer mon disque dur (bon, certes, c'est chiant pour le boot UEFI vu qu'il faut bricoler l'UUID de la partoche de boot, du coup j'ai tendance a booter en mode legacy la 1ère fois, et corriger ça ensuite), que j'enchaîne avec quelques mkfs bien sentis. Étape finale: monter la future "/", y créer les dossiers qui vont bien (dans mon cas, /boot/EFI, /var, /home, et le jour ou je serais motivé pour que mon système boot en read-only, probablement le /usr) et y monter les partitions.

    Un petit debootstrap --variant=minbase buster /target plus tard, le système réellement minimal est prêt.

    for i in dev proc sys
    do
      mount --bind /$i /target/$i
    done

    fini de préparer le chroot /target, ou j'invoque l'installation des paquets qui me permettrons d'avoir un système autonome: apt-get install --no-install-recommends linux-image-amd64 syslinux syslinux-efi syslinux-common busybox vim aptitude runit-init sudo.

    L'oeil averti notera que je me permets du confort inutile avec vim, sudo et aptitude, j'aurai pu me passer du 1er puisqu'un close vi est embarqué dans busybox, les autres… bon, bref.
    Il notera également l'absence de grub, car je préfère et de très loin syslinux, malgré le fait de devoir copier manuellement (oh mon dieu, une copie manuelle!) les fichiers /initrd et /vmlinuz dans la partition de boot. Je pourrais sûrement installer un hook dans dpkg, mais je n'ai jamais cherché comment faire.
    Pour finir, le troll averti notera l'absence de systemd, remplacé par syslinux, Debian 10 mettant à disposition un paquet syslinux-init qui permets de l'utiliser comme système d'init.

    Création d'un user qui fait partie de quelques groupes (sudo ici): useradd -m -G sudo user -s /bin/bash , modification des passwords de user et root via passwd ou chpasswd (bien utile pour les scripts, le 2nd) et il me sera possible de me loguer.

    Création d'un fichier syslinux.cfg, installation du boot loader et copie des kernel/initrd:

    timeout 50
    outimeout buster
    default buster
    prompt 0
    
    ui vesamenu.c32
    menu title oOo Chargement du démarrage OoO
    append ro
    
    label buster
        menu label Buster
        linux  /buster/vmlinuz
        initrd /buster/initrd.img
        append root=LABEL=main_sys
    
    dd if=/usr/lib/syslinux/gptmbr of=/dev/$TARGET
    syslinux -i /dev/$TARGET -d /mnt/bios
    mount /dev/$TARGET /mnt
    cp -r /usr/lib/syslinux/modules/* /mnt
    cp /usr/lib/SYSLINUX.EFI/efi32/syslinux.efi /mnt/efi32/
    cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi /mnt/efi64/
    cp $SOURCE/syslinux.cfg /mnt/bios
    cp $SOURCE/syslinux.cfg /mnt/efi32
    cp $SOURCE/syslinux.cfg /mnt/efi64
    mkdir /mnt/distro
    cp /vmlinuz /initrd.img /mnt/distro

    Reste plus qu'à créer quelques fichiers systèmes: /etc/fstab et /etc/hostname et configurer le système est bootable.

    Bon, je vais être honnête:

    • je n'ai jamais utilisé l'efi32,
    • d'habitude je ne copie que les modules dont j'ai besoin,
    • l'efi64 nécessite quelques autres manipulations pour être réellement utilisable, à base d'efibootmgr, qui ne fonctionne que si le système a booté en mode efi. Pour ça, suivre les excellentes instructions du wiki d'archlinux
    • j'ai juste testé ça pour Debian, d'où le "buster" dans debootstrap,
    • il est possible de tout installer direct du debootstrap,
    • j'utilise perso un proxy apt nommé apt-cacher-ng,

    m'enfin, chez moi, ça marche. Si avec ça, t'as encore des cochonneries installées, faut vraiment penser à changer de distro.

    • [^] # Re: debootstrap est ton ami

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

      fait une distro ;-)

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: debootstrap est ton ami

        Posté par . Évalué à 3 (+1/-0). Dernière modification le 16/10/19 à 19:32.

        Ça ne serait pas un projet inintéressant (j'y pense, en vrai), mais je pense que je manque de connaissances, d'expérience en gestion système. Il y a aussi des points qui me semblent mal branlés, mais probable que je ne comprenne juste pas la raison derrière.

        Notamment:

        • pas encore assez d'expérience avec runit, comme le prouve ma tâche de ce jour: sv check $DAEMON ferme le descripteur de fichier 2 (stdout) avant d'exécuter $SVDIR/$DAEMON/check. Du coup, si le fichier check écrit quelque chose dans stdout, le script plante, ce qui fait croire que le daemon n'est pas fonctionnel… dans mon cas, c'était un tunnel ssh inversé, ce qui mène a un reset du tunnel (le daemon était un watchdog codé à la va-vite) entraînant une sur-consommation de données (parce qu'une liaison ssh, ça bouffe un max a établir, et je n'ai pas étudié IPSEC, donc les VPN, pour ça que je suis parti sur cette solution: je suis dev moi, pas admin);
        • gestion des paquets: j'adore le format des binaires debian (une archive cpio qui regroupe 1 fichier texte et 2 tarball, on pourrait en pratique réimplémenter dpkg en shell! voire, ne pas avoir besoin d'installer un paquet pour l'utiliser, si on le montais directement… ça éliminerai peut-être des race-conditions?), mais certains trucs dedans me gênent, genre les scripts pré/post inst/rm. Il y a aussi le fait d'être obligé d'être root pour utiliser apt (je veux dire, on ne peux pas installer de paquets juste pour un seul user, et, justement, j'aime pas l'idée d'utiliser plusieurs systèmes de paquets) qui me gêne, le fait que dpkg ne soit pas parallélisé… sur des points plus techno-politiques, je trouve dommage qu'un daemon soit systématiquement activé quand il est installé, et que la doc soit souvent séparée du paquet principal: quand on code (du C ou juste de simples scripts) on a du coup tendance a bloater le système pour rien, et trouver la doc est pénible;
        • je suis toujours incapable de compiler un kernel. Enfin, je sais le compiler, mais juste si j'ai une configuration fonctionnelle. Je ne saurais même pas me passer d'un initrd, alors si c'est juste pour faire une Nième distro comme les autres, je pense que le net peut se passer de bruit inutile supplémentaire;
        • j'étudie en ce moment le déploiement d'un LDAP+kerberos. C'est assez difficile de trouver des explications claires, alors que je pense que ce type d'outils devrais être bien intégrés à une distro. Si je comprend pas comment ça marche, je ne peux pas les intégrer;
        • je ne sais pas configurer d'outils de monitoring digne de ce nom. Je suis à peine capable de balancer des logs dans svlogd, mais si les logs ne sont jamais lus ou ne déclenchent pas d'alerte, alors ils ne servent pas a grand chose;
        • idem pour le backup;
        • idem pour le chiffrement;

        Bref, j'ai encore un peu de chemin a faire avant de m'attaquer à un truc aussi complet que la création d'une distro. Enfin, si je veux qu'elle apporte vraiment quelque chose.
        Parce que je pense qu'il y a de la place pour de nouvelles distro: je verrai bien une distro qui ait un coeur stable et soit relativement simple a installer, comme Debian, mais axée codeurs (que ce soit du C, du python, du java, du bash ou autre). Si on pouvait avoir du dpkg qui marche sans être root, on pourrait du coup intégrer des dépôts "contrib" pour le code "à l'arrache", pas officiellement supportés, comme ce que fait archlinux.

        Si c'est juste forker Debian pour refourguer des paquets debian mais avec juste la sélection par défaut et le fond d'écran officiel qui change, je pense sincèrement que c'est pas la peine. Il y a déjà bien assez de variantes de Mint ou d'Ubuntu comme ça.

        [edit]
        Ah, j'oubliais, je ne sais toujours pas utiliser docker, SElinux ou AppArmor, les cgroups… qui sont pourtant dans l'air du temps. Donc, vraiment, vraiment beaucoup de chemin à faire :)

        • [^] # Re: debootstrap est ton ami

          Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 17/10/19 à 12:44.

          Bien sûr, je disais ça pour rire, comme celui qui annonce la n-ième distro. Des minimalistes il y en a déjà, il vaut mieux participer. Et comme tu le sous-entend, c'est un énorme travail, presque impossible à faire seul. Tu peux faire une preuve de concept, pour réorienter une minimaliste qui ne te correspond pas tout à fait. D'ailleurs, Tiny Core est un peu conçue pour ça.

          J'ajoute un test de Tiny Core par LWN.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Mwai

    Posté par (page perso) . Évalué à -2 (+4/-8).

    Je réalise que les devs GNOME, eux, développent un truc appelé Flatpak. J'ai tenté d'en
    installé un (pour avoir la dernière version de Geary), sans succès.

    Ok, retourne sous MacOS, tu as perdu la main…

    • [^] # Re: Mwai

      Posté par . Évalué à 5 (+4/-1).

      tu as perdu la main…

      Faut reconnaître que c'est dommage de la perdre avec un système de paquet nommé fapfap flatpack.

      Je suis déjà dehors :)

  • # Quelques infos sur Snap (et Flatpak)

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

    Salut Ploum !

    Avant d'aller plus loin, sache qu'Ubuntu est toujours basée sur les repos Debian, donc tous les logiciels qui sont dispos dans ces repos sont dispos sur Ubuntu :)

    Un des buts des snap et autres flatpak, c'est de simplifier la mise à jour des logiciels sur les distributions Linux. Aujourdhui, si tu as réussi à pousser ton super logiciel foobarbuzz en version 1.0 dans les repos Debian, il va falloir attendre un paquet de temps avant qu'il soit dispo sur Debian stable ou dans Ubuntu, sans compter qu'il ne sera jamais disponible sur Fedora, RHEL, Arch Linux, etc. Si, en cours de route, tu as publié une version 1.1, voire 2.0, le processus pour publier cette mise à jour est contraignant et chronophage, et il peut s'écouler des mois avant que tes utilisateurs puissent y avoir accès, en fonction de la distribution qu'ils utilisent.

    Les PPA d'Ubuntu essaient de limiter cette attente, mais c'est galère à utiliser pour le commun des mortels, il faut quand même avoir une certaine confiance dans les gens qui créent ces PPA, et surtout on peut y mettre n'importe quoi, et potentiellement casser un système.

    Si tout cela t'intéresse, je pourrais écrire un petit article à ce sujet. (enfin, surtout à propos de snap que je connais bien mieux que flatpak)

    Certains logiciels n'apparaissent pas dans apt-get mais bien dans l'appstore graphique que j'ai compris être Snap (et qui, d'après un post sur le blog de Linux Mint, est un truc ultra fermé réservé à Ubuntu).

    Justement, non. Le but affiché de snap est de faire en sorte que les développeurs/mainteneurs n'aient à packager leur application qu'une fois, et qu'elle soit ensuite disponible sur un paquet de distributions. Je te renvoie à la documentation de Snap et notamment sa page qui liste les distributions compatibles.

    Le Snap en question semble être un truc de goret qui rend l'output de df illisible.

    Une application installée en tant que snap n'est autre qu'une mini-partition au format squashfs. Un petit alias df="df -x squashfs" bien placé, et hop ! plus de problème avec df ;)

    certains trucs appelés « core »

    Si tu parles du snap core (ou core18), il s'agit, en gros, d'une base qui est utilisée par tous les logiciels qui sont empaquetés au format snap.

    Et je pense que le dev Regolith serait pas contre le fait de virer Snap de son install par défaut si on lui explique comment.

    Il faut voir si c'est judicieux sur le long terme. Chromium est disponible au format snap, par exemple (lire l'article d'Alan Pope à ce sujet). Cela permet à l'équipe en charge du desktop Ubuntu de n'avoir à empaqueter qu'une seule version de Chromium qui est disponible sur beaucoup de versions d'Ubuntu différentes (toutes les LTS, même les plus anciennes, et toutes les versions intermédiaires encore supportées). Mine de rien, ça réduit considérablement leur travail d'empaquetage et de test.

  • # flatpak c'est nul

    Posté par (page perso) . Évalué à 5 (+2/-0). Dernière modification le 30/10/19 à 12:12.

    Après de nombreux tâtonnements en suivant la doc pas terrible et la quasi absence d'infos pour les applis Java/Maven (un scandale vu le nombre d'applis utilisant ces technos), j'ai réussi à faire mon paquet avec Flatpak.

    Je le teste sur une Ubuntu: super ça marche !

    Je le teste sur la dernière Fedora:

    The application fr.devnewton.NewtonAdventure/x86_64/master requires the runtime org.freedesktop.Platform/x86_64/18.08 which was not found

    L'argument n°1 de Flatpak était pourtant:

    Create one app and distribute it to the entire Linux desktop market.

    Incubez l'excellence sur https://linuxfr.org/board/

Envoyer un commentaire

Suivre le flux des commentaires

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