Bonjour,
depuis mon installation 18.04 puis 18.10, j'ai remarqué une profusion de /dev/loop"n" ici n va de 0 à 28 aujourd'hui.
Je sais que cela est consécutif à la gestion de Snaps cf. la page web Le système de paquets snap.
Ce n'est pas, de ma part, une installation volontaire en mode snap.
J'ai cru remarquer que beaucoup de logiciels concernés étaient consécutifs à une installation via l'outil gnome "logiciel ubuntu"
(vous savez, celui qu'on lance avec l'icone en forme de valise orange griffée d'un "A")
Désormais, je visualise les logiciels disponibles sur cette étagère "A"
Mais je ne les installe plus que par synaptic ou avec un terminal de base et un "apt-get install" courant.
Il y a avec ces Snaps une double pollution :
  1. quand j'examine mes partitions, par gparted ou autre logiciel d'examen des partitions, 29 partitions /dev/loop"n" polluent la lecture
  2. lorsque j'effectue un "ps -ef | grep /dev/loop" je vois que les processus sont chargés pour tous ces snap
mes questions sont les suivantes :
  1. Est ce que c'est bien l'installateur "Logiciels ubuntu" qui génère cette mise en snap des paquets logiciels ou est-ce autre chose ?
  2. Est-ce que cette gestion par snap des paquets logiciels accroît l'efficacité du système ?
  3. Si ce n'est pas le cas, comment s'en débarrasser ?
  4. Est-il possible, si cette gestion par snap est performante de filtrer la gestion des partitions de toutes ces virtuelles partitions ?
Merci
ujmo
Bonjour,
Quelques réponses.
tout d'abord le Wiki concernant les snaps : snap(Wiki Ubuntu]
réponses aux questions :
  1. Il apparaît que l'installation par "Logiciels Ubuntu" génère des snaps mais ce n'est pas la seule source.
  2. après avoir supprimé par "logiciels Ubuntu" ou "suppression snap" et réinstallé par "synaptic" ou "apt-get install" le système me semble plus réactif.
  3. pour supprimer un paquet snap il suffit de lancer la commande "snap remove <logiciel>" cf. Suppression
  4. à cette question je n'ai pas de réponse
Remarques : avec 29 snaps le système plantait souvent et j'ai dû relancer dans ce cas par Alt-Syst- [R-E-I-S-U-B] successivement.
après avoir supprimé les snaps qui pouvaient s'installer avec synaptic et leur réinstallation par ce biais, les système m'a semblé être moins erratique.
Il reste les interrogations concernant :
la suppression totale de la gestion snap
le filtrage des partitions snap dans la gestion graphique des partitions
la performance ou efficacité effective de la gestion par paquets Snap
Si quelqu'un a une idée ou un avis
Merci
ujmo
Bonjour Xubu,
Tu as raison, ce post correspond à l'objet sur lequel porte ma demande.
Je reste cependant dans l'interrogation quant à l'efficacité des processus Snap.
Ce que je peux dire à l'expérience, c'est que les aborts intempestifs lors de l'utilisation de mon poste de travail ont diminué après que j'ai retiré les processus snap que j'ai pu réinstaller via synaptic ou par le gestionnaire de paquets apt.
Je ne peux que faire une supposition mais la possibilité d'une autre source de problème reste plausible.
Dans la situation actuelle, j'ai décidé de laisser les autres processus snap en place et de voir comment les choses évoluent.
le listage donne : 
~$ snap list
Name               Version    Rev   Tracking  Publisher   Notes
core               16-2.35.4  5662  stable    canonical✓  core
gnome-3-26-1604    3.26.0     74    stable/…  canonical✓  -
gnome-characters   3.29.91    124   stable/…  canonical✓  -
gnome-logs         3.30.0     45    stable/…  canonical✓  -
gtk-common-themes  0.1        701   stable/…  canonical✓  -
qownnotes          18.10.4    1138  stable    pbek        -
rtv-lbo            1.21.0     1     stable    lbo         -
vsslagent          1.18       95    stable    vssl        -
Je suis passé de 29 processus à 9 et il me semble raisonnable de conserver cet état du système.
par contre, le listage par fdisk - l donne un nombre plus élevé 
~$ sudo fdisk -l | grep Disque
Disque /dev/loop0 : 140,9 MiB, 147722240 octets, 288520 secteurs
Disque /dev/loop1 : 86,6 MiB, 90820608 octets, 177384 secteurs
Disque /dev/loop2 : 9,4 MiB, 9867264 octets, 19272 secteurs
Disque /dev/loop3 : 87,9 MiB, 92164096 octets, 180008 secteurs
Disque /dev/loop4 : 14,5 MiB, 15196160 octets, 29680 secteurs
Disque /dev/loop5 : 66,7 MiB, 69910528 octets, 136544 secteurs
Disque /dev/loop6 : 42,1 MiB, 44183552 octets, 86296 secteurs
Disque /dev/loop7 : 14,5 MiB, 15204352 octets, 29696 secteurs
Disque /dev/loop8 : 66,7 MiB, 69955584 octets, 136632 secteurs
Disque /dev/loop9 : 87,9 MiB, 92119040 octets, 179920 secteurs
Disque /dev/loop10 : 87,9 MiB, 92123136 octets, 179928 secteurs
Disque /dev/loop11 : 86,6 MiB, 90824704 octets, 177392 secteurs
Disque /dev/loop12 : 34,7 MiB, 36323328 octets, 70944 secteurs
Disque /dev/loop13 : 140,7 MiB, 147496960 octets, 288080 secteurs
Disque /dev/loop14 : 86,6 MiB, 90824704 octets, 177392 secteurs
Disque /dev/loop15 : 13 MiB, 13619200 octets, 26600 secteurs
Disque /dev/loop16 : 13 MiB, 13619200 octets, 26600 secteurs
Disque /dev/loop17 : 66,7 MiB, 69914624 octets, 136552 secteurs
Disque /dev/loop18 : 14,5 MiB, 15208448 octets, 29704 secteurs
Disque /dev/sda : 698,7 GiB, 750156374016 octets, 1465149168 secteurs
Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
pour afficher l'affectation de ces partitions aux processus snap : 
~$ df -TH |grep loop
/dev/loop0                squashfs     148M    148M     0 100% /snap/gnome-3-26-1604/70
/dev/loop2                squashfs      10M     10M     0 100% /snap/rtv-lbo/1
/dev/loop3                squashfs      93M     93M     0 100% /snap/core/5328
/dev/loop6                squashfs      45M     45M     0 100% /snap/gtk-common-themes/701
/dev/loop5                squashfs      70M     70M     0 100% /snap/vsslagent/92
/dev/loop12               squashfs      37M     37M     0 100% /snap/gtk-common-themes/319
/dev/loop4                squashfs      16M     16M     0 100% /snap/gnome-logs/37
/dev/loop9                squashfs      93M     93M     0 100% /snap/core/5548
/dev/loop7                squashfs      16M     16M     0 100% /snap/gnome-logs/43
/dev/loop10               squashfs      93M     93M     0 100% /snap/core/5662
/dev/loop11               squashfs      91M     91M     0 100% /snap/qownnotes/1138
/dev/loop15               squashfs      14M     14M     0 100% /snap/gnome-characters/103
/dev/loop16               squashfs      14M     14M     0 100% /snap/gnome-characters/124
/dev/loop17               squashfs      70M     70M     0 100% /snap/vsslagent/87
/dev/loop14               squashfs      91M     91M     0 100% /snap/qownnotes/1135
/dev/loop18               squashfs      16M     16M     0 100% /snap/gnome-logs/45
/dev/loop1                squashfs      91M     91M     0 100% /snap/qownnotes/1130
/dev/loop13               squashfs     148M    148M     0 100% /snap/gnome-3-26-1604/74
/dev/loop8                squashfs      70M     70M     0 100% /snap/vsslagent/95
en conclusion :
Il y a bien un sujet sur la question qui est traité mais tout cela reste des avis et non des constats qualitatifs ou quantitatifs.
La question de la performance ou non des processus snap reste sans réponse.
Dans tous les cas, merci de ton post qui m'a permis d'éclairer un peu plus mon interrogation.
à bientôt peut-être !
ujmo
un mois plus tard
Après avoir supprimé tous les processus snap dont les logiciels pouvaient s'installer par le gestionaire de paquets apt ou par synaptic le fonctionnement s'avère plus fiable.
Les blocages intempestifs ne subsistent plus qu'a raison de ce qui peut paraître raisonnable et uniquement lorsque la charge système est importante.
J'ai laissé les processus snap dont la liste suit : 
~ : snap list
Name               Version         Rev   Tracking  Publisher   Notes
core               16-2.35.5       5742  stable    canonical✓  core
gnome-3-26-1604    3.26.0          74    stable/…  canonical✓  -
gnome-characters   3.30.0          139   stable/…  canonical✓  -
gnome-logs         3.30.0          45    stable/…  canonical✓  -
gtk-common-themes  0.1-4-g88bc1b2  818   stable/…  canonical✓  -
qownnotes          18.11.4         1217  stable    pbek        -
rtv-lbo            1.21.0          1     stable    lbo         -
vsslagent          1.18            95    stable    vssl        -
après une période de test de près d'un mois le fonctionnement apparaît donc stable.

Les questions soulevées n'ont pas toutes obtenu de réponse mais je passe à résolu.
Super !
Merci
Bonne journée

  • [supprimé]

  • Message #8
Oui c'est un des gros défaut d'Ubuntu avec cette politique des Snaps :
Quand un débutant utilise la logithèque Ubuntu et qu'il recherche un logiciel, généralement c'est la version snap du logiciel qui est mis en avant et non la version APT alors que ça devrai être l'inverse.

Tous ceux qui connaissent bien ce problème savent qu'il ne faut pas utiliser la logithèque Ubuntu (en + elle ne référence pas tous les paquets) mais utiliser soit une alternative comme Synpatic ou même idéalement en CLI. Le problème c'est que le novices ne le savent pas et utilise la logithèque proposé par défaut et donc installe beaucoup de Snap sans le savoir.
(Bon en réalité quand on installe un paquet depuis la logithèque en Snap, c'est bien précisé mais ce n'est pas très mis en avant, il faut descendre en bas pour voir marqué "boutique de snap" et certains ne savent même pas à quoi cela correspond d'ailleurs).

On peux très bien utiliser la logithèque par défaut sans installer aucun snap mais il faut faire très attention dans les détails en bas à chaque fois si c'est un snap ou non donc pas pratique.
2 ans plus tard
bonsoir je suis débutant sur linux, j'ai télécharger le logiciel Snap pour le traitement des images satellite. je l'ai installé mais je n'arrive pas à le lancer. voila les commandes que j'ai entr dans mon terminal: Snap; Snap& mais aucune d'elles ne fonctionne. comment faire svp ?