Ubuntu 16.04 : les paquets Snappy avec les paquets Debian

Le par  |  73 commentaire(s)
Ubuntu-logo

C'est une confirmation. Avec la distribution Ubuntu 16.04 (LTS), les paquets snap seront proposés aux côtés des habituels paquets .deb.

Ce point avait déjà été éclairci par Mark Shuttleworth, le fondateur d'Ubuntu et Canonical, alors que la communauté s'inquiétait d'un remplacement du système de paquets Debian au profit de la technologie maison Snappy.

Ubuntu-convergence-logoAvant la sortie d'Ubuntu 16.04 le 21 avril prochain et qui sera une mouture avec support à long terme (cinq ans), Olli Ries, le responsable du développement des produits Ubuntu Client Platform pour Canonical, confirme une nouvelle fois que le support des paquets snap se fera aux côtés des paquets .deb usuels.

L'utilisateur final pourra donc installer des applications et paquets snap mais il n'y aura pas de trait tiré pour les paquets Debian. " Les développeurs et communautés pourront publier soit des debs ou snaps pour les utilisateurs d'Ubuntu. "

Reste à savoir si les développeurs vont se saisir des outils à leur disposition pour confectionner des paquets snap. Rappelons qu'un paquet snap peut être utilisé sur ordinateur, serveur, mobile ainsi que pour l'Internet des Objets.

Avec Snappy, l'idée est de préserver la base du système Ubuntu en l'isolant des applications installées par la suite. Elles ont des répertoires distincts les uns des autres grâce à AppArmor dans le noyau Linux. " Les utilisateurs peuvent installer un snap sans s'inquiéter de savoir s'il aura un impact sur leurs autres applications ou leur système ", écrit Olli Ries.

Cette technologie doit aussi éviter le casse-tête des dépendances logicielles manquantes pour les développeurs d'applications. D'ici l'automne 2016, la plupart des applications qui fonctionnent sur d'anciennes versions d'Ubuntu seront automatiquement migrer du format .deb vers snap.

" Toutes les dizaines de milliers d'applications et paquets dans le format .deb continueront d'être pris en charge dans Ubuntu 16.04 et au-delà, et les archives deb en particulier seront toujours disponibles pour tous ", conclut le responsable de Canonical.

Complément d'information

Vos commentaires Page 1 / 8

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1890282

au profit de la technologie maison Snappy.



Ok, je situe mieux la.
Le #1890290
Mmmh, en gros ils font "à la Steam" sous *nux: le "snap" doit sûrement embarquer les libs nécessaires au fonctionnement de l'appli "snappée" et les charger au lancement de l'appli via les mécanismes LD_PRELOAD et cie.

Avantages à vue de nez:

* ça doit être possible d'avoir plusieurs versions de la même appli qui cohabitent
* on risque pas d'avoir un logiciel mal packagé écrasant des libs de la distrib pour y coller les siennes (typiquement: du logiciel proprio mal codé, mal packagé ou juste pas packagé du tout, avec tous les risques que ça comporte niveau sécu et stabilité, en prime)
* On risque pas d'avoir un logiciel qui se viande après une màj du système car il ne trouve pas "libmachin.so.6". Mais normalement, ça, c'est le boulot des devs d'assurer le suivi par rapport à upstream.

Désavantages à vue de nez:

* Espace disque: toutes ces jolies libs bouffent de la place. Sur du petit SSD ça peut vite devenir lourd
* Sécurité: si le dev' de l'appli snappée ne veut pas utiliser, au hasard, la dernière version de la libcrypto (mais vraiment au hasard, hein… ), ton appli risque donc de tourner avec une libcrypto avec un gros trou dedans.
* EDIT: un autre détail… mais ces snaps sont ils disponibles depuis des dépôts officiels (et donc signés, validés, faciles à mettre à jour en un clic ou une ligne de commande), ou est-ce qu'on va se retrouver avec la peste des 01net et cie, c'est à dire des "faux" snaps (genre vlc ou firefox) livrés déjà pourris d'adwares et de véroles par les 01net, télécharger.com ou download.com?

Mouais. À voir comment c'est géré, si les devs sont obligés de tenir leurs "snaps" à jour, etc.
Le #1890294
lidstah a écrit :

Mmmh, en gros ils font "à la Steam" sous *nux: le "snap" doit sûrement embarquer les libs nécessaires au fonctionnement de l'appli "snappée" et les charger au lancement de l'appli via les mécanismes LD_PRELOAD et cie.

Avantages à vue de nez:

* ça doit être possible d'avoir plusieurs versions de la même appli qui cohabitent
* on risque pas d'avoir un logiciel mal packagé écrasant des libs de la distrib pour y coller les siennes (typiquement: du logiciel proprio mal codé, mal packagé ou juste pas packagé du tout, avec tous les risques que ça comporte niveau sécu et stabilité, en prime)
* On risque pas d'avoir un logiciel qui se viande après une màj du système car il ne trouve pas "libmachin.so.6". Mais normalement, ça, c'est le boulot des devs d'assurer le suivi par rapport à upstream.

Désavantages à vue de nez:

* Espace disque: toutes ces jolies libs bouffent de la place. Sur du petit SSD ça peut vite devenir lourd
* Sécurité: si le dev' de l'appli snappée ne veut pas utiliser, au hasard, la dernière version de la libcrypto (mais vraiment au hasard, hein… ), ton appli risque donc de tourner avec une libcrypto avec un gros trou dedans.
* EDIT: un autre détail… mais ces snaps sont ils disponibles depuis des dépôts officiels (et donc signés, validés, faciles à mettre à jour en un clic ou une ligne de commande), ou est-ce qu'on va se retrouver avec la peste des 01net et cie, c'est à dire des "faux" snaps (genre vlc ou firefox) livrés déjà pourris d'adwares et de véroles par les 01net, télécharger.com ou download.com?

Mouais. À voir comment c'est géré, si les devs sont obligés de tenir leurs "snaps" à jour, etc.


"si les devs sont obligés de tenir leurs "snaps" à jour, " ... Effectivement. Et c'est bien là que le bas risque de blesser et jouer en défaveur de l'adoption de ces paquets. A suivre...

Autre source : http://korben.info/ubuntu-snap-snappy-paquet.html

Le #1890299
Tiens, si je comprends bien de quoi il s'agit, ces "snaps" pourraient être enfin un digne équivalent du système d'installeur standalone-qui-se-suffit-à-lui-même de Windows. Enfin une bonne idée chez Canonical !
Le #1890312
Je ne sais pas si c'est une bonne mauvaise idée ou une mauvaise bonne idée mais si avec ces paquets (reprenant toutes les ressources nécessaires à l'application) il y a une faille de découverte dans une bibliothèque, la mise à jour "globale" de l'OS ne sera plus efficace étant donné que la correction ne portera pas sur la bibliothèque incriminée.

On devra attendre que le développeur le fasse lui-même et, comme les développeurs du libre travaillent souvent pendant leur temps libre... Bonne chance pour que la faille soit comblée rapidement. D'où mon scepticisme.
Le #1890318
bugmenot a écrit :

Tiens, si je comprends bien de quoi il s'agit, ces "snaps" pourraient être enfin un digne équivalent du système d'installeur standalone-qui-se-suffit-à-lui-même de Windows. Enfin une bonne idée chez Canonical !


Ca existe déjà.
Tu peux déjà faire cohabiter différentes versions d'un même logiciel (tu les colles dans /opt). Mais c'est alors sale comme dans Windows, à l'arrache (pas de maintenance via un gestionnaire) avec les bouses qui restent dans la base de registres.

Ce dont il s'agit ici c'est d'avoir plusieurs versions possibles au sein du gestionnaire de paquets.

Ca fait 10 fois que je te répète la même chose mais tu continues à répandre tes âneries à chaque fois.

PS

Comme dit lidstah; pas certain que ce soit une bonne idée de multiplier des libs redondantes sur son OS et franchement quel est l'intérêt ?
Le #1890324
il est peut-être prévu dans le système de snap d’utiliser ou non des librairies partagées.
Ainsi un soft qui aurait besoin d'une version spécifique pourrait faire ce choix, et un soft plus ouvert pourrait garder des librairies système.
Le #1890334
mouarf76 a écrit :

bugmenot a écrit :

Tiens, si je comprends bien de quoi il s'agit, ces "snaps" pourraient être enfin un digne équivalent du système d'installeur standalone-qui-se-suffit-à-lui-même de Windows. Enfin une bonne idée chez Canonical !


Ca existe déjà.
Tu peux déjà faire cohabiter différentes versions d'un même logiciel (tu les colles dans /opt). Mais c'est alors sale comme dans Windows, à l'arrache (pas de maintenance via un gestionnaire) avec les bouses qui restent dans la base de registres.

Ce dont il s'agit ici c'est d'avoir plusieurs versions possibles au sein du gestionnaire de paquets.

Ca fait 10 fois que je te répète la même chose mais tu continues à répandre tes âneries à chaque fois.

PS

Comme dit lidstah; pas certain que ce soit une bonne idée de multiplier des libs redondantes sur son OS et franchement quel est l'intérêt ?


Oui, l'install de programmes dans /opt est une solution qui date des années 80 je crois, et qui permet d'installer "à l'arrache" ce qu'on veut - ça et les mécanismes type LD_PRELOAD, LD_PREFIX (de mémoire) pour charger les librairies voulues. Mais comme tu le fais remarquer… bin là on pert l'intérêt du gestionnaire de paquets, avec tous les risques que cela comporte. Perso j'ai pas envie qu'un logiciel utilise une vieille version de bash (hein shellshock?) ou openssl, entre autres.

Après, il faut voir comment cela va être implémenté chez Canonical, mais j'ai assez peur d'un écosystème à la Docker (ie des containers tout faits, "facile" à utiliser/installer pour le développeur ou l'adminsys paresseux *mais* bourrés de failles - attention hein, Docker (tout comme lxc, vagrant, etc) c'est très intéressant, mais il faut éviter comme la peste les containers tout faits, vaut mieux se les faire (et les maintenir) soi-même)
Le #1890369
lidstah a écrit :

mouarf76 a écrit :

bugmenot a écrit :

Tiens, si je comprends bien de quoi il s'agit, ces "snaps" pourraient être enfin un digne équivalent du système d'installeur standalone-qui-se-suffit-à-lui-même de Windows. Enfin une bonne idée chez Canonical !


Ca existe déjà.
Tu peux déjà faire cohabiter différentes versions d'un même logiciel (tu les colles dans /opt). Mais c'est alors sale comme dans Windows, à l'arrache (pas de maintenance via un gestionnaire) avec les bouses qui restent dans la base de registres.

Ce dont il s'agit ici c'est d'avoir plusieurs versions possibles au sein du gestionnaire de paquets.

Ca fait 10 fois que je te répète la même chose mais tu continues à répandre tes âneries à chaque fois.

PS

Comme dit lidstah; pas certain que ce soit une bonne idée de multiplier des libs redondantes sur son OS et franchement quel est l'intérêt ?


Oui, l'install de programmes dans /opt est une solution qui date des années 80 je crois, et qui permet d'installer "à l'arrache" ce qu'on veut - ça et les mécanismes type LD_PRELOAD, LD_PREFIX (de mémoire) pour charger les librairies voulues. Mais comme tu le fais remarquer… bin là on pert l'intérêt du gestionnaire de paquets, avec tous les risques que cela comporte. Perso j'ai pas envie qu'un logiciel utilise une vieille version de bash (hein shellshock?) ou openssl, entre autres.

Après, il faut voir comment cela va être implémenté chez Canonical, mais j'ai assez peur d'un écosystème à la Docker (ie des containers tout faits, "facile" à utiliser/installer pour le développeur ou l'adminsys paresseux *mais* bourrés de failles - attention hein, Docker (tout comme lxc, vagrant, etc) c'est très intéressant, mais il faut éviter comme la peste les containers tout faits, vaut mieux se les faire (et les maintenir) soi-même)


Bin oui c'est ce que j'explique à Bugmenot pour lequel l'absence, au sein de Windows, de gestionnaire de paquets et la prolifération de différentes versions de logiciels et de leurs différentes librairies avec leurs "installateurs magiques" semble être un avantage.

Franchement quand je vois la stabilité de mon système, sa légèreté avec un ensemble extrêmement à jour, sans aucun effort,j'ai vraiment pas envie de changement ! J'attends une ou deux semaines maximum pour avoir les tous derniers packages ou au pire, si je suis pressé, je teste un binaire dans /opt.
Le #1890401
Doit on comprendre qu'Ubuntu va avoir un système d'installation de logiciel par drag and drop comme mac OS, et sans ce soucier qu'un nouveau logiciel foute la grouille dans le système ?
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]