Le Blog Utux

Je suis d'accord que l'article est proche du FUD, mais c'est aussi le comportement de Canonical au fil des années qui aide. Pour moi, qui ne suis pas suffisamment avancé en technique pour avoir suivi un cursus informatique académique, les snaps me font furieusement penser à ce que propose Apple depuis des années avec les fichiers DMG.

Toujours dans le monde des BSD, il y a les PBI de PC-BSD qui reprennent le principe d'une archive installable qui incluent toutes les dépendances nécessaires... Au prix d'une taille non négligeable pour certains logiciels.

Côté taille plus grande de ces "tout-en-un", prenons un exemple. Celui de Mozilla Firefox pour Linux x86_64 et pour Apple.

La version 46.0 pour Linux en x86_64 ? http://ftp.mozilla.org/pub/firefox/releases/46.0/linux-x86_64/fr/ => 50 Mo.

La version 46.0 pour Mac ? http://ftp.mozilla.org/pub/firefox/releases/46.0/mac/fr/ => 83 Mo.

Je sais que comparaison n'est pas raison, mais cela fait pas loin de 40% de plus en taille. Merci l'intégration des bibliothèques dans chaque paquet.

Il y a aussi une question qui se pose : est-ce que cette énième tentative de proposer un installateur simplifié est portable ou est-il limité à la distribution de Canonical, tout comme Mir ?

Si c'est le deuxième cas, ce sera donc un énième format de paquets qui ira rejoindre les tentatives malheureuses comme auto-package ou encore zero install.

On dit que la route de l'Enfer est pavée de bonnes intentions, après tout.

Maintenant, j'attends pour voir comment cela va se goupiller. Je n'en ai pas parlé sur mon blog, car je pense que c'est encore trop tôt. Attendons que les plâtres soient essuyés par le grand public ;)

On peut voir des similitudes avec DMG en effet, mais Snap utilise des containers pour isoler les applications et leurs librairies, ainsi elles ne polluent pas le système de base. Ils ont donc abordé le problème de manière intelligente en utilisant les outils modernes.

Quelle pollution avec les dmg ? Je ne me souviens pas quand j'étais utilisateur de MacOS-X (à l'époque de Tiger) que des dmg aient pollués le système en dehors de leur espace propre.

Si tu parles de non pollution à l'exécution, d'accord. Mais à l'installation ? Est-ce que cela ne va pas alourdir la charge mémoire en plus de la charge disque ?

D'ailleurs, je me demande si ce n'est pas aussi en quelque sorte le retour des binaires avec leurs bibliothèques intégrées en statique, sur le plan général. Un peu comme ce que propose sta.li : http://sta.li/

Simple hypothèse :)

Lorsque tu installe un logiciel sur ta machine, peu importe le format du paquet, tu n'as aucune garantie que lors de la désinstallation tout sera nettoyé. Avec les containers, si.
Et c'est valable sur tous les OS, même avec un apt-get remove --purge d'un paquet sur Debian il reste toujours des traces.
Pour la charge disque et mémoire nous le découvrirons bientôt mais il s'agit de containers pas de virtualisation donc l'impact devrait être limité.

Euh... Ayant pratiqué MacOS-X durant un an, je crois me souvenir que le logiciel était limité dans son installation à son répertoire propre. Donc, pour désinstaller un logiciel au format dmg, il suffisait de placer son icone dans la corbeille et de vider la dite corbeille.

Il ne restait plus que les données utilisateurs. À moins que cela ait changé depuis 2006 ? En tout cas, je pense que la taille des paquets snap sera quand même plus importante - ne serait-ce que par l'inclusion des bibliothèques nécessaire - qu'une version classique d'un logiciel donné. Cf l'exemple que je t'ai donné plus haut avec la version dmg de Mozilla Firefox en comparaison de la version tar.bz2 classique.

Hum, le fait est que les logiciels d'Apple tourne sur des écran Retina, ce qui gonfle fatalement la taille des archive (images & co).

Je ne comprends pas en quoi Snap révolutionne l'informatique, ni en quoi il apporte un bénéfice réel, j'ai dû rater un épisode.

Est-ce qu'on ne se retrouverait pas avec une duplication faramineuse de librairies ?
Et quid des développeurs qui ne mettent pas à jour leurs paquets Snap ?

Au final, quelle différence avec un programme compilé contre des librairies statiques et intégrées ?

En d'autres mots... Snap ou XDG-app, à quoi ça sert ?

En un mot : containers.
Il ne s'agit pas d'un zip dégueulasse qui va déposer des fichiers partout comme de la mauvaise herbe (façon Windows), tout sera isolé dans un container.
Quand a la question de la redondance des libs je ne pense pas que ce soit si grave que ça.
Pour le suivi des mises à jour, c'est un problème général à tous les logiciels, il faudra faire attention à ce qu'on installe.

Nouvelle solution miracle, les containers ?

Quant à déposer des bibliothèques partout, c'est un problème de conception plus qu'autre chose.

Pas grave la redondance des biblios ? Sauf si tu as un petit espace de stockage. J'ai déjà cité l'exemple d'un Firefox qui passe de 50 à 83 Mo.

Si on augmente la taille de 20 à 30% par rapport aux paquets ancienne mode, ça risque vite de tourner au carnage pour l'espace libre disponible :( Surtout que les SSDs commencent à se démocratiser, et que la taille moyenne est plus proche des 256 Go que des 2 To...

On verra bien, mais je dois le dire tout de go : je ne mettrais pas un kopek dans snappy pour le moment.

Sachant qu'une Debian avec environnement graphique ne pèse même pas 10GB, je pense que ton SSD de 256GB est large :)
N'ayant pas encore eu l'occasion de bosser avec docker je ne saurais répondre à ton interrogation sur les containers, mais c'est plutôt souple (scripting, snaphots, déplacements).
En plus ils sont portables de système en système, on peut très bien imaginer que demain Archlinux ait sa propre implémentation de Snap et soit capable d’exécuter les mêmes logiciels.

Quid des données personnelles ? Je fais quoi de mes quelques 80 Go de musique ?

À moins que tu utilises un duo SSD et disque dur classique ? Pour info, en virant les traductions inutiles, voici l'espace pris par mon installation d'archlinux (Mate, LibreOffice, VirtualBox, outils de compilation, Gimp, et plein d'autres choses) :

[fred@fredo-arch ~]$ df -h | grep /dev/sda3
/dev/sda3 19G 4,5G 14G 26% /

Pour en revenir toujours au même point : on verra dans un an si on parle de Snappy au présent ou à l'imparfait.

Comme l'a souligné Frederic, Canonical le cherche un peu parfois, mais il semblerait effectivement que ce soit devenu une habitude de lui cracher dessus à chaque changement majeur dans Ubuntu. Les news à propos de cette faille dans Xorg le montrent bien, et montrent au passage que les journalistes/blogueurs qui les relaient ne comprennent pas très bien soit l'anglais soit l'informatique.

Quant à l'éventuel risque des bibliothèques embarquées qui ne seraient pas mise à jour, il semble que la conception du format Snap limite la casse. Les dépendances aux bibliothèques sont renseignées dans un fichier, et sont récupérées et compilées à chaque build du paquet Snap. Donc à priori il n'y a pas trop à craindre de ce côté là. Cf. ce commentaire sur mon article sur la sortie de Snap : https://blog.karolak.fr/2016/04/13/snap-de-ubuntu-bonne-ou-mauvaise-nouvelle/#isso-39

Le seul léger reproche qu'on puisse faire au format Snap, c'est le gaspillage d'espace disque.

"Le seul léger reproche qu'on puisse faire au format Snap, c'est le gaspillage d'espace disque."

?? À l'exception de certains fanatiques de musiques et autres téléchargements massifs, je constate autour de moi généralement une sous-utilisation des espaces disques disponibles...
Ce pourquoi d'ailleurs ont peut souvent se permettre de redescendre à un SSD plus petit, plus cher et plus rapide (quand on a constaté qu'on utilise pas tant de disque que ça).

Non, l'impact qui sera le plus sensible c'est qu'une distrib à base de snap ne sera décidément plus adaptée aux petites configurations (mémoire s'entend).

Personnellement, faire comme certains système propriétaires qui ne marchent visiblement pas si mal (suffisamment pour être adoptés massivement), en revenant aux principes premiers de la construction de logiciel.

Et je prends le pari que dans un an... Fred mange son chapeau ;-)
Faut bien que quelqu'un fasse le pari inverse...

Je n'ai pas de chapeau. Et tu fais quoi des personnes qui font du travail sur des grosses images ou des grosses vidéos ?

"Personnellement, faire comme certains système propriétaires qui ne marchent visiblement pas si mal (suffisamment pour être adoptés massivement), en revenant aux principes premiers de la construction de logiciel. "

Dans ce cas, autant utiliser les dits systèmes, non ?

"Et je prends le pari que dans un an... Fred mange son chapeau ;-)"

Difficile, je n'ai pas de chapeau. Simplement, je pense que ce sera un soufflé qui va retomber. Comme jadis autopackage ou encore zero-install.

Si aucune distribution qu'Ubuntu ne propose de paquets snaps, je parle des grosses cylindrées comme la Fedora, la Mageia ou encore la Debian, ça sera une technologie de plus qui ira au musée de l'informatique libre.

"Et tu fais quoi des personnes qui font du travail sur des grosses images ou des grosses vidéos ?"

Je ne comprends pas le lien [que tu fais] entre snap/"packaging" d'appli et la taille des données traitées par les applis ?
(en simplification [très, très] abusive, snap c'est un chroot-dédié, ce que tu y stocke en donnée n'a aucune importance, de ce que j'ai compris.)

Je parlais de l'espace disque dans son ensemble. Tout espace supplémentaire mangé par les applications dans ce format ne seront pas disponible pour les données.

Un espace de stockage n'est pas extensible à l'infini.

Ok.
L'espace disque n'est pas "vraiment" un problème. Chez "nous", les gens qui ont une consommation hors-norme ont des machines hors-norme. Faut pas non plus espérer des miracles.
Travailler sur une machine sous-dimensionnée aboutira nécessairement à un mur (pour une raison ou pour une autre).
Ce qui est vrai, c'est que Snap se détourne donc des petites configurations (en ram ou en disque). Mais ici encore, qui n'a jamais vu papi/mami ou kevin s'acheter une bête de course pour ... faire quoi au juste ?
Je pense que "nous" devons changer de paradigme. Pour comprendre certaines évolutions il faut sortir du folklore de la petite machine recyclée qui tourne bien avec la dernière distrib réglée aux petites oignons... Il y en aura, certainement (handylinux & cie). Mais ce n'est pas, ce n'est plus la cible des Ubuntu et autres fournisseurs mainstream. Donc, les outils "supports" ne seront plus les mêmes.
Le succès ou l'échec de Snap sera aussi politico-stratégique. Probablement. Mais le résultat ne sera pas nécessairement le reflet d'une qualité technologique intrinsèque. Un peu comme certains formats cassettes vidéo, réputés meilleurs, n'ont pourtant pas survécus (exemple classique).
Mais l'histoire est écrite par les vainqueurs... Ce sera imparable. On est d'accord.

"Comme l'a souligné Frederic, Canonical le cherche un peu parfois," : mir ? upstart ? unity ? :)

Il faut dire que sa tendance à se la jouer parfois cavalier seul irrite pas mal de monde.

"Les dépendances aux bibliothèques sont renseignées dans un fichier, et sont récupérées et compilées à chaque build du paquet Snap."

On en revient toujours au même problème : la maintenance des dits paquets. Recompilé depuis où ? Des paquets debian ? Directement plus l'amont ?

J'avoue que je ne me suis pas super-renseigné, car ce projet me laisse pantois.

Ouaip, y'a de quoi avoir des interrogations...
M'enfin, on peut aussi prendre le problème à contre-pied.
En gros, est-ce que "passer par Debian" est une nécessité absolue ? n'est pas parfois un handicap ?
La règle du circuit court (moins d'intermédiaires) ne serait pertinente en matière de packaging ? Pourquoi ?
N'y-a-t-il pas des systèmes/logiciels complexes qu'il est préférable d'aller chercher à la source ? Notamment par ce que Debian n'a pas les ressources ou compétences pour mettre la bête en paquet ?
(exemples à main levée, Plone&cie, eclipse, certainement d'autres que j'oublies/ne connais pas)
Et au fait, les jeux toujours galère à installer ?

Et s'il faut que quelqu'un se plante en explorant cette piste, autant que ce soit Ubuntu non ?? (mauvais esprit inside ;-)

« Le seul léger reproche qu'on puisse faire au format Snap, c'est le gaspillage d'espace disque. »
Et le gaspillage de mémoire vive ! L’intérêt des bibliothèques partagées c'est aussi qu'elle ne sont chargées qu'une seule fois en mémoire (partagée).

Ce qui est remis en cause ce n'est pas tant la technologie Snap, mais le discours purement marketing de canonical repris ad nauseam par les défenseurs d'Ubuntu.
Matthew Garrett ne remet pas fondamentalement en cause cette technologie. Il dit qu'il est malhonnête d'affirmer que snap apporte actuellement une sécurité aux utilisateurs (« it's disingenuous to claim that it currently gives desktop users any real security»).
Et même si dans le futur avec Wayland (ou mir) le problème inhérent à Xorg ne se pose plus, de sérieuses questions concernant la sécurité restent posés, notamment sur le mode de distribution des snaps.

Bonjour, je n'ai pas suivi la mise en place des paquets Snap, je suis encore sur la version 14.04. Mais, y a-t-il beaucoup de logiciels qui s'installe sous la forme d'un paquet Snap ?

Actuellement il y en a très peut, un peut plus d'une vingtaine.