Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Ubuntu : les paquets snap peuvent s'utiliser sur d'autres distributions

En étant un peu patients
Logiciel 3 min
Ubuntu : les paquets snap peuvent s'utiliser sur d'autres distributions

La bêta d’Ubuntu 16.04 a été l’occasion pour Canonical d’introduire les snaps, de nouveaux paquets d’installation pour les logiciels. Le gestionnaire peut désormais être installé sur d’autres distributions, mais l’infrastructure est jeune. Plusieurs problèmes sont à noter, dont la taille imposante des téléchargements.

Ubuntu 16.04 a été l'occasion pour Canonical d'officialiser un nouveau gestionnaire de paquets, qui prend place aux côtés des habituels paquets Deb, les snaps. L’idée est la même que pour les DMG d’OS X, devenu depuis peu macOS avec Sierra : dans une même image, tous les binaires sont présents, accompagnés par l’ensemble des dépendances/bibliothèques dont le logiciel pourrait avoir besoin pour fonctionner. Avec des avantages et inconvénients.

Un certain embonpoint 

Comme Phoronix l’indique, Arch Linux, Gentoo, Debian et Fedora sont désormais supportés, Snapcraft.io ayant été mis à jour. Une fois installé, il permet immédiatement de commencer à installer des snaps. Ces derniers ne sont pas nombreux, à peine sept pour l’instant, dont Ubuntu Clock, Ubuntu Calculator et LibreOffice. Une fois installés, ces logiciels fonctionnent presque comme on s’y attend, mais des points importants sont à signaler.

Le lancement des applications installées via des snaps ne peut se faire que si SELinux est désactivé. S’il ne s’agit que de faire quelques tests, la protection peut donc être désactivée temporairement. Ensuite, en cas de distribution de type non-Debian, il conviendra de s’assurer que le service snapd est bien lancé. Cela peut se faire via la commande suivante :

sudo systemctl enable –now snapd.service

Il faudra également faire attention à la taille des paquets, assez surprenante. Clock et Calc font ainsi 120 Mo chacun, un poids élevé considérant les fonctionnalités très simples proposées. Mais le plus impressionnant reste LibreOffice, dont le snap pèse pas de moins de... 1,1 Go. Eric Griffith de Phoronix note à ce sujet que cette taille est très supérieure à celles des installeurs habituels : 238 Mo pour Windows x64, 201 Mo pour OS X, 229 Mo pour le RPM Linux x64 et pour le Deb x64. En fait, même en réunissant les quatre, le snap est toujours plus lourd.

Fonctionnel, mais améliorable

Globalement, l’ensemble fonctionne. Les snaps s’installent, les raccourcis apparaissent et les logiciels deviennent disponibles dans la recherche de la distribution. Par contre, il peut exister des soucis en fonction de la distribution utilisée. Phoronix signale par exemple que LibreOffice n’affiche pas la barre de menus sur une distribution Fedora. Il est probable que les snaps soient prévus pour fonctionner sur Ubuntu au point d’être parfois « perdus » si Unity est absent.

On peut considérer globalement que les snaps sont une infrastructure jeune et qui laisse donc une bonne place pour des améliorations. On peut imaginer par exemple, quitte à garder un système d’images contenant tous les binaires, que ceux ne servant à rien une fois installés pourront être supprimés. Pour court-circuiter même les imposants téléchargements – les snaps sont tout de même censés être utilisables tels quels sur des appareils mobiles – on peut songer également à un service « intelligent » qui formerait des snaps adaptés côté serveurs. Il faut espérer en outre qu'ils pourront se lancer à terme sans devoir couper SELinux.

Les snaps offrent cependant l’avantage d’être faciles à mettre en place. Ils devraient permettre aux éditeurs de proposer directement des paquets tout-en-un s’installant facilement, quelle que soit la distribution retenue. Du moins en théorie.

157 commentaires
Avatar de Vengeur_Masqué INpactien
Avatar de Vengeur_MasquéVengeur_Masqué- 16/06/16 à 09:23:30

C'est effectivement très encourageant pour que Linux se mette au niveau de windows ou MacOSX sur ce point.

Quand je vois que spotify propose toujours des lignes de commande

Avatar de anonyme_69736061fe834a059975aa425bebeb6d INpactien

j'aime mes lignes de commande ...:transpi:

Avatar de edrin17 Abonné
Avatar de edrin17edrin17- 16/06/16 à 09:31:26

En même temps, j'ai toujours été un Ubuntuero à cause du côté user friendly, mais la ligne de commande est indispensable sous ubuntu encore maintenant, sauf à utiliser synaptic.
J'arrive toujours pas à comprendre qu'il n'y ait pas d'option "mode admin" dans nautilus. Du coup "sudo" + ligne de commande pour tout les trucs un poil plus compliqués que faire de texte avec libreoffice (genre xampp).

Donc les paquets Snap à 120mo l'horloge ... :)
 

Avatar de GierrePattaz INpactien
Avatar de GierrePattazGierrePattaz- 16/06/16 à 09:32:36

Je ne comprend pas vraiment la valeur ajoutée et comment fonctionne la gestion des dépendances.
Les snap ne partagent plus les lib ?

Avatar de brazomyna INpactien
Avatar de brazomynabrazomyna- 16/06/16 à 09:38:05

GierrePattaz a écrit :

Je ne comprend pas vraiment la valeur ajoutée et comment fonctionne la gestion des dépendances.
Les snap ne partagent plus les lib ?

C'est un peu la même histoire que les compilations d'applications avec des librairies en 'tout statique' vs dynamique:
 

  • le statique permet d'avoir un "tout" avec l'ensemble des dépendances, ce qui amoindri les problèmes potentiels de dépendance manquante ; c'est donc plus simple à installer pour l'utilisateur final: le package contient tout ce dont l'application a besoin, elle peut vivre sa petite vie en vase clos.
     

  • mais ça pose de gros souci d'embonpoint, de conso de RAM (x fois la même lib chargée en RAM), et (surtout) de besoin de repackaging complet à chaque nouvelle version d'une lib tierce (et donc de potentiels risques de sécurités si les 'packageurs' ne sont pas réactif à chaque faille + patch qui sort dans telle ou telle lib).
     

     

Édité par brazomyna le 16/06/2016 à 09:39
Avatar de Exosta INpactien
Avatar de ExostaExosta- 16/06/16 à 09:38:50

En quoi la taille des paquets est surprenante ? C'est le principe de ce gestionnaire : embarquer toutes les lib' pour éviter d'avoir à se soucier des différentes distributions, architectures, etc. Ca vient avec son lot d'inconvénients.
Concernant l'installeur Windows, j'imagine qu'il n'embarque pas Java.

Avatar de KP2 Abonné
Avatar de KP2KP2- 16/06/16 à 09:38:54

GierrePattaz a écrit :

Je ne comprend pas vraiment la valeur ajoutée et comment fonctionne la gestion des dépendances.
Les snap ne partagent plus les lib ?

Ben l'idee est justement de completement zapper la gestion des dependances traditionnelle de linux. Ou du moins, d'integrer toutes les dependances dans le package.
Mais quand on utilise des conteneurs, il faut aussi une image d'OS et ça, ça rajoute une foutue masse a l'ensemble...
Après, je pense qu'ils vont reussir a affiner l'ensemble mais quand même.

Personnellement, je suis dubitatif. Chaque solution a ses avantages et ses inconvenients et je vois pas d'amelioration globalement en fait...

Avatar de gehasia INpactien
Avatar de gehasiagehasia- 16/06/16 à 09:39:09

GierrePattaz a écrit :

Je ne comprend pas vraiment la valeur ajoutée et comment fonctionne la gestion des dépendances.
Les snap ne partagent plus les lib ?

Exactement, aucun partage de lib, c'est une espèce de sous docker merdique qui n'apporte rien sauf à faire une copie des mauvaises habitudes de systèmes concurrents.

Avatar de Commentaire_supprime Abonné
Avatar de Commentaire_supprimeCommentaire_supprime- 16/06/16 à 09:40:13

Intéressant si le côté bloatware de cette première version du concept est corrigé. Par exemple, un snap avec Texlive et tous ses paquets au complet m'aurait évité de me retrouver avec une version dépourvue de certains paquets indispensables quand j'ai essayé d'utiliser l'engin sous Mageia...

J'attends de voir la suite.

Avatar de Rozgann Abonné
Avatar de RozgannRozgann- 16/06/16 à 09:42:41

L'idée est bonne : permettre à un développeur de distribuer un unique fichier d'installation pour n'importe quelle distribution Linux, pouvoir mettre à jour son logiciel et ses dépendances indépendamment de la version des bibliothèques disponibles sur le système. Pour des applications graphiques, c'est clairement la bonne direction, parce que la situation actuelle est loin d'être optimale.

Par contre, GNOME a développé un système équivalent, Flatpack (anciennement XDG-Apps). KDE supporte également cette solution. Comme les Snaps, ça marche mais il y a certaines limitations. La plus visible est que les applications Flatpack ne suivent pas le thème défini par l'utilisateur, du fait du sandboxing. LibreOffice est dispo uniquement dans sa version qui ne dépend pas de Java, mais je pense que c'est pareil pour la version Snap.

Je sais pas si il y a des différences majeures entre Flatpack et Snappy. Après le schisme deb/rpm, est-ce qu'on aura également un schisme Flatpack/Snappy ?

Il n'est plus possible de commenter cette actualité.
Page 1 / 16