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

      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)