aeris22’s avataraeris22’s Twitter Archive—№ 43,560

                          1. Je sais pas pourquoi, mais j’ai presque envie de faire un #LT à retardement de la conf’ sur les snaps ubuntu :D
                        1. …in reply to @aeris22
                          En particulier le passage sur la comparaison avec le système de paquets traditionnels. Qui est presque du FUD pur et dur…
                      1. …in reply to @aeris22
                        « Paquets difficiles à réaliser » Non, ça manque juste trop souvent de mainteneurs…
                    1. …in reply to @aeris22
                      « On doit faire des paquets adaptés à chaque distrib » #ToiAussiEnfonceDesPortesOuvertes
                  1. …in reply to @aeris22
                    « Le mainteneur va peut-être faire un paquet qui va poser un problème sur votre système » 1- #EtLesTestsAlors 2- #TestingÇaSertÀÇa […]
                1. …in reply to @aeris22
                  […] 3- #SnapNeFeraPasMieux
              1. …in reply to @aeris22
                « Les devs amonts ne maîtrisent pas le cycle de distribution » Et genre ça va être eux qui vont se faire les snap ? :D
            1. …in reply to @aeris22
              « Plusieurs paquets qui vont amener le même fichier » Euh… Si c’est ça, c’est le dev du paquet qu’il faut flinguer, pas le système de paquet
          1. …in reply to @aeris22
            « Les PPA peuvent casser votre système » Ben #PPA quoi…
        1. …in reply to @aeris22
          « Lors de l’install, le paquet a les droits root, ça peut casser tout votre système » #EtLesTestsAlors ? #RepeatMySelf
      1. …in reply to @aeris22
        À l’écoute, ça me confirme ce que je pensais déjà avoir compris avant : Snap est un mot africain qui veut dire «Je ne sais pas utiliser apt»
    1. …in reply to @aeris22
      « Vous ne pouvez avoir personne entre le fournisseur du snap et vous qui peut modifier le snap, parce que c’est en read-only. […] »
  1. …in reply to @aeris22
    « […] Un MitM est du coup impossible. » Euh… Sérieusement ? Un fichier peut être read-only et infecté. Suffit juste d’envoyer autre chose…
    1. …in reply to @aeris22
      « Il y a un facteur de compression de 3 ». Alors 1- .deb peut faire pareil le jour où on fait .deb.xz hein […]
      1. …in reply to @aeris22
        […] 2- Faire un OpenSSL 3× plus petit dans le snap mais 100× plus présent sur le système… #WTF
        1. …in reply to @aeris22
          « C’est vous qui aller livrer upstream » Vous n’avez aucune idée de la libc ou du kernel utilisé par votre utilisateur. Bon courage.
          1. …in reply to @aeris22
            On ne sait déjà pas faire un simple binaire agnostique de la cible finale… Là c’est carrément un paquet avec dépendances systèmes… ><
            1. …in reply to @aeris22
              Prendre l’exemple de @Nextclouders qui livre une box entièrement sous leur contrôle est assez risible pour le coup :P
              1. …in reply to @aeris22
                Ils n’auraient aucun problème de compat/version/upstream, même avec un « make install » :P
                1. …in reply to @aeris22
                  « Si la mise-à-jour ne leur plaît pas, ils peuvent faire un retour arrière » Et ramener autant de faille. #YOLO
                  1. …in reply to @aeris22
                    (Sachant en plus que 30s avant, mention fait du blacklistage de paquets si comportement jugé instable… #LeftPad)
                    1. …in reply to @aeris22
                      « Il faut quand même avoir un sentiment de sécurité » WAT ‽‽‽‽‽‽‽‽
                      1. …in reply to @aeris22
                        (Miam time, je poursuivrais tout à l’heure :D)