J'ai installé la 18.04. Tout s'est bien passé sauf cette obstination à
imposer Gnome alors que je préfère KDE (question d'habitudes, sans
doute). Bref, j'ai fait ce qu'il fallait et j'ai KDE.
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De
mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils
concernent tous Gnome.
Merci pour vos lumières et bonne journée à tous,
--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que l'application est téléchargée avec son propre fs, un petit peu comme Docker. Ca ressemble fortement à l'installation d'applications Android. Ca devrait permettre d'installer n'importe quelle application sur n'importe quelle version de Linux avec du confinement (sécurité). https://doc.ubuntu-fr.org/snap#qu_est_ce_qu_un_snap
Dominique <zzz@aol.com.invalid> wrote:
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De
mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils
concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que
l'application est téléchargée avec son propre fs, un petit peu
comme Docker.
Ca ressemble fortement à l'installation d'applications Android.
Ca devrait permettre d'installer n'importe quelle application
sur n'importe quelle version de Linux avec du confinement
(sécurité).
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que l'application est téléchargée avec son propre fs, un petit peu comme Docker. Ca ressemble fortement à l'installation d'applications Android. Ca devrait permettre d'installer n'importe quelle application sur n'importe quelle version de Linux avec du confinement (sécurité). https://doc.ubuntu-fr.org/snap#qu_est_ce_qu_un_snap
Doug713705
Le 10-05-2018, Dominique nous expliquait dans fr.comp.os.linux.configuration (<pd0jud$1n51$) :
Bonjour, J'ai installé la 18.04. Tout s'est bien passé sauf cette obstination à imposer Gnome alors que je préfère KDE (question d'habitudes, sans doute). Bref, j'ai fait ce qu'il fallait et j'ai KDE. Je fais un df et j'obtiens ceci : Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur udev 4012488 0 4012488 0% /dev tmpfs 808384 1436 806948 1% /run /dev/sda5 47797996 7872724 37467520 18% / tmpfs 4041904 140508 3901396 4% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 4041904 0 4041904 0% /sys/fs/cgroup /dev/loop2 88704 88704 0 100% /snap/core/4486 /dev/loop1 2432 2432 0 100% /snap/gnome-calculator/167 /dev/loop4 3840 3840 0 100% /snap/gnome-system-monitor/39 /dev/loop3 3456 3456 0 100% /snap/gnome-system-monitor/36 /dev/loop0 1664 1664 0 100% /snap/gnome-calculator/154 /dev/loop5 21504 21504 0 100% /snap/gnome-logs/25 /dev/loop6 13312 13312 0 100% /snap/gnome-characters/86 /dev/loop7 22144 22144 0 100% /snap/gnome-logs/31 /dev/loop8 88704 88704 0 100% /snap/core/4571 /dev/loop9 143488 143488 0 100% /snap/gnome-3-26-1604/59 /dev/loop10 12544 12544 0 100% /snap/gnome-characters/69 /dev/loop11 143488 143488 0 100% /snap/gnome-3-26-1604/62 /dev/sda6 417146704 66988864 328944912 17% /home tmpfs 808380 28 808352 1% /run/user/1000 /dev/loop12 142848 142848 0 100% /snap/gnome-3-26-1604/64 Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je suppose qu'il s'agit de paquets installés via snap: https://doc.ubuntu-fr.org/snap "Le format snap vise à permettre l'installation de nouvelles versions de logiciels dans les systèmes Linux, tout en apportant aux développeurs la facilité de distribution, la fiabilité et la sécurité. " Dire que Snap apporte de la sécurité c'est tout de même osé. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 10-05-2018, Dominique nous expliquait dans
fr.comp.os.linux.configuration (<pd0jud$1n51$1@gioia.aioe.org>) :
Bonjour,
J'ai installé la 18.04. Tout s'est bien passé sauf cette obstination à
imposer Gnome alors que je préfère KDE (question d'habitudes, sans
doute). Bref, j'ai fait ce qu'il fallait et j'ai KDE.
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De
mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils
concernent tous Gnome.
Je suppose qu'il s'agit de paquets installés via snap:
https://doc.ubuntu-fr.org/snap
"Le format snap vise à permettre l'installation de nouvelles versions de
logiciels dans les systèmes Linux, tout en apportant aux développeurs la
facilité de distribution, la fiabilité et la sécurité. "
Dire que Snap apporte de la sécurité c'est tout de même osé.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 10-05-2018, Dominique nous expliquait dans fr.comp.os.linux.configuration (<pd0jud$1n51$) :
Bonjour, J'ai installé la 18.04. Tout s'est bien passé sauf cette obstination à imposer Gnome alors que je préfère KDE (question d'habitudes, sans doute). Bref, j'ai fait ce qu'il fallait et j'ai KDE. Je fais un df et j'obtiens ceci : Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur udev 4012488 0 4012488 0% /dev tmpfs 808384 1436 806948 1% /run /dev/sda5 47797996 7872724 37467520 18% / tmpfs 4041904 140508 3901396 4% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 4041904 0 4041904 0% /sys/fs/cgroup /dev/loop2 88704 88704 0 100% /snap/core/4486 /dev/loop1 2432 2432 0 100% /snap/gnome-calculator/167 /dev/loop4 3840 3840 0 100% /snap/gnome-system-monitor/39 /dev/loop3 3456 3456 0 100% /snap/gnome-system-monitor/36 /dev/loop0 1664 1664 0 100% /snap/gnome-calculator/154 /dev/loop5 21504 21504 0 100% /snap/gnome-logs/25 /dev/loop6 13312 13312 0 100% /snap/gnome-characters/86 /dev/loop7 22144 22144 0 100% /snap/gnome-logs/31 /dev/loop8 88704 88704 0 100% /snap/core/4571 /dev/loop9 143488 143488 0 100% /snap/gnome-3-26-1604/59 /dev/loop10 12544 12544 0 100% /snap/gnome-characters/69 /dev/loop11 143488 143488 0 100% /snap/gnome-3-26-1604/62 /dev/sda6 417146704 66988864 328944912 17% /home tmpfs 808380 28 808352 1% /run/user/1000 /dev/loop12 142848 142848 0 100% /snap/gnome-3-26-1604/64 Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je suppose qu'il s'agit de paquets installés via snap: https://doc.ubuntu-fr.org/snap "Le format snap vise à permettre l'installation de nouvelles versions de logiciels dans les systèmes Linux, tout en apportant aux développeurs la facilité de distribution, la fiabilité et la sécurité. " Dire que Snap apporte de la sécurité c'est tout de même osé. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Marc SCHAEFER
Doug713705 wrote:
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Doug713705 <doug.letough@free.fr> wrote:
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot,
vu que toutes les libs sont livrées avec le pseudo-fs.
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Doug713705
Le 10-05-2018, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pd13gc$l64$) :
Doug713705 wrote:
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche. Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec. Bref, dans une certaine mesure on s'approche d'un système à la Windows (plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le succès des *nix. Avec des zillions de paquets installés de cette manière il n'y a plus vraiment moyen de s'assurer de la mise à jour des versions de libs pour l'ensemble du système et des applications. De plus la multiplication des gestionnaires de paquets rend le tout encore moins compréhensible pour la plupart des utilisateurs (apt pour les paquets systèmes + snap pour les applicatifs mais pas tous car certains sont encore installés avec apt). On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point. -- A l'ombre de vos centrales je crache mon cancer Je cherche un nouveau nom pour ma métamorphose Je sais que mes enfants s'appelleront vers de terre -- H.F. Thiéfaine, Aligator 427
Le 10-05-2018, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration (<pd13gc$l64$1@shakotay.alphanet.ch>) :
Doug713705 <doug.letough@free.fr> wrote:
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot,
vu que toutes les libs sont livrées avec le pseudo-fs.
Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.
Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.
Bref, dans une certaine mesure on s'approche d'un système à la Windows
(plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le
succès des *nix.
Avec des zillions de paquets installés de cette manière il n'y a plus
vraiment moyen de s'assurer de la mise à jour des versions de libs pour
l'ensemble du système et des applications.
De plus la multiplication des gestionnaires de paquets rend le tout
encore moins compréhensible pour la plupart des utilisateurs (apt pour
les paquets systèmes + snap pour les applicatifs mais pas tous car
certains sont encore installés avec apt).
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à
jour. C'est surtout ça mon point.
--
A l'ombre de vos centrales je crache mon cancer
Je cherche un nouveau nom pour ma métamorphose
Je sais que mes enfants s'appelleront vers de terre
-- H.F. Thiéfaine, Aligator 427
Le 10-05-2018, Marc SCHAEFER nous expliquait dans fr.comp.os.linux.configuration (<pd13gc$l64$) :
Doug713705 wrote:
Dire que Snap apporte de la sécurité c'est tout de même osé.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche. Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec. Bref, dans une certaine mesure on s'approche d'un système à la Windows (plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le succès des *nix. Avec des zillions de paquets installés de cette manière il n'y a plus vraiment moyen de s'assurer de la mise à jour des versions de libs pour l'ensemble du système et des applications. De plus la multiplication des gestionnaires de paquets rend le tout encore moins compréhensible pour la plupart des utilisateurs (apt pour les paquets systèmes + snap pour les applicatifs mais pas tous car certains sont encore installés avec apt). On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point. -- A l'ombre de vos centrales je crache mon cancer Je cherche un nouveau nom pour ma métamorphose Je sais que mes enfants s'appelleront vers de terre -- H.F. Thiéfaine, Aligator 427
Eric Masson
Marc SCHAEFER writes: 'Lut,
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers. -- Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Marc SCHAEFER <schaefer@alphanet.ch> writes:
'Lut,
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot,
vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers.
--
Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web
peuvent poser des questions ? Ce forum de conseils est très bien, mais
il serait bon de pouvoir discuter de vive voix avec des conaisseurs.
-+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers. -- Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Eric Masson
Doug713705 writes: 'Lut,
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche.
Pas plus que de failles noyau permettant de compromettre globalement un système.
Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec.
Comme casser une appli parce qu'une dépendance a été mise à jour par le gestionnaire de paquets lors d'une opération sur une autre appli ? Dans certains cas, l'isolation d'applications et de leurs dépendances est une solution tout à fait valide (au pif, utilisation d'une version expérimentale d'une lib par une application donnée sans avoir à se baser sur un mécanisme de version de libs, s'il existe, ou encore couplé à des snapshots du fs, une possibilité de RAZ de l'application complète dans un état connu sans impact sur les autres applis installées).
Bref, dans une certaine mesure on s'approche d'un système à la Windows (plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le succès des *nix.
Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute juste une possibilité supplémentaire d'empaquetage des applications correspondant à un besoin particulier.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point.
C'est déjà le cas, le nombre de systèmes en production qui ne voient plus de màj pour éviter des régressions fonctionnelles est tout sauf négligeable. -- Tout neuneu que je suis en usenautique, je me permets de signaler aux décideurs qu'ils sont en infraction. J'ai entendu parler de black lists Sont-elles déclarées à la CNIL? Probablement pas. C'est un délit! -+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
Doug713705 <doug.letough@free.fr> writes:
'Lut,
Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.
Pas plus que de failles noyau permettant de compromettre globalement un
système.
Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.
Comme casser une appli parce qu'une dépendance a été mise à jour par le
gestionnaire de paquets lors d'une opération sur une autre appli ?
Dans certains cas, l'isolation d'applications et de leurs dépendances
est une solution tout à fait valide (au pif, utilisation d'une version
expérimentale d'une lib par une application donnée sans avoir à se baser
sur un mécanisme de version de libs, s'il existe, ou encore couplé à des
snapshots du fs, une possibilité de RAZ de l'application complète dans
un état connu sans impact sur les autres applis installées).
Bref, dans une certaine mesure on s'approche d'un système à la Windows
(plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le
succès des *nix.
Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute
juste une possibilité supplémentaire d'empaquetage des applications
correspondant à un besoin particulier.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis
à jour. C'est surtout ça mon point.
C'est déjà le cas, le nombre de systèmes en production qui ne voient
plus de màj pour éviter des régressions fonctionnelles est tout sauf
négligeable.
--
Tout neuneu que je suis en usenautique, je me permets de signaler aux
décideurs qu'ils sont en infraction. J'ai entendu parler de black lists
Sont-elles déclarées à la CNIL? Probablement pas. C'est un délit!
-+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche.
Pas plus que de failles noyau permettant de compromettre globalement un système.
Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec.
Comme casser une appli parce qu'une dépendance a été mise à jour par le gestionnaire de paquets lors d'une opération sur une autre appli ? Dans certains cas, l'isolation d'applications et de leurs dépendances est une solution tout à fait valide (au pif, utilisation d'une version expérimentale d'une lib par une application donnée sans avoir à se baser sur un mécanisme de version de libs, s'il existe, ou encore couplé à des snapshots du fs, une possibilité de RAZ de l'application complète dans un état connu sans impact sur les autres applis installées).
Bref, dans une certaine mesure on s'approche d'un système à la Windows (plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le succès des *nix.
Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute juste une possibilité supplémentaire d'empaquetage des applications correspondant à un besoin particulier.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point.
C'est déjà le cas, le nombre de systèmes en production qui ne voient plus de màj pour éviter des régressions fonctionnelles est tout sauf négligeable. -- Tout neuneu que je suis en usenautique, je me permets de signaler aux décideurs qu'ils sont en infraction. J'ai entendu parler de black lists Sont-elles déclarées à la CNIL? Probablement pas. C'est un délit! -+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
Marc SCHAEFER
Doug713705 wrote:
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche.
Juste; vrai pour toutes les formes de virtualisation et de confinement.
Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec.
Totalement! C'est aller dans le sens contraire des bijoux que sont les packages Debian, par exemple. Mais, en informatique, on voit souvent que les meilleures solutions sont remplacées par les solutions qui sont le plus facilement gérables avec du personnel sans compétence. Par exemple, imaginons un constructeur informatique comme HP: est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des packages snap un peu confinés ? La réponse parfaite est: "ils devraient publier leurs interfaces en open-source et laisser les développeurs Debian faire de jolis packages". Dans les faits, ils vont se ruer sur snap (?). Exemple: j'ai une fois installé un serveur HP, et ils proposaient des packages Debian pour leur outils de monitoring (leur interface, à l'époque, était différente des autres constructeurs, différente de celle supportée par Debian en natif, donc). J'ai regardé le package et j'ai vu assez vite le risque de rm -rf /$install_dir avec une variable $install_dir pouvant dans certains cas être vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu sur le site web d'HP.
Avec des zillions de paquets installés de cette manière il n'y a plus vraiment moyen de s'assurer de la mise à jour des versions de libs pour l'ensemble du système et des applications.
Clairement. Et il y a aussi un impact de gaspillage mémoire.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point.
Parfaitement d'accord.
Doug713705 <doug.letough@free.fr> wrote:
Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.
Juste; vrai pour toutes les formes de virtualisation et de confinement.
Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.
Totalement! C'est aller dans le sens contraire des bijoux que sont
les packages Debian, par exemple.
Mais, en informatique, on voit souvent que les meilleures solutions
sont remplacées par les solutions qui sont le plus facilement
gérables avec du personnel sans compétence.
Par exemple, imaginons un constructeur informatique comme HP:
est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des
packages snap un peu confinés ? La réponse parfaite est: "ils devraient
publier leurs interfaces en open-source et laisser les développeurs
Debian faire de jolis packages". Dans les faits, ils vont se
ruer sur snap (?).
Exemple: j'ai une fois installé un serveur HP, et ils proposaient
des packages Debian pour leur outils de monitoring (leur interface,
à l'époque, était différente des autres constructeurs, différente
de celle supportée par Debian en natif, donc). J'ai regardé le
package et j'ai vu assez vite le risque de rm -rf /$install_dir
avec une variable $install_dir pouvant dans certains cas être
vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu
sur le site web d'HP.
Avec des zillions de paquets installés de cette manière il n'y a plus
vraiment moyen de s'assurer de la mise à jour des versions de libs pour
l'ensemble du système et des applications.
Clairement.
Et il y a aussi un impact de gaspillage mémoire.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à
jour. C'est surtout ça mon point.
Il y probablement un confinement mais il existe aussi existera encore des failes qui permettent de sortir de ces confinements mais ce n'est pas trop le repoche que je fais à cet approche.
Juste; vrai pour toutes les formes de virtualisation et de confinement.
Pour moi ce types de paquets livrés avec leurs versions de libs va totalement à l'encontre du principe de bibliothèques partagées avec les problèmatiques qui vont avec.
Totalement! C'est aller dans le sens contraire des bijoux que sont les packages Debian, par exemple. Mais, en informatique, on voit souvent que les meilleures solutions sont remplacées par les solutions qui sont le plus facilement gérables avec du personnel sans compétence. Par exemple, imaginons un constructeur informatique comme HP: est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des packages snap un peu confinés ? La réponse parfaite est: "ils devraient publier leurs interfaces en open-source et laisser les développeurs Debian faire de jolis packages". Dans les faits, ils vont se ruer sur snap (?). Exemple: j'ai une fois installé un serveur HP, et ils proposaient des packages Debian pour leur outils de monitoring (leur interface, à l'époque, était différente des autres constructeurs, différente de celle supportée par Debian en natif, donc). J'ai regardé le package et j'ai vu assez vite le risque de rm -rf /$install_dir avec une variable $install_dir pouvant dans certains cas être vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu sur le site web d'HP.
Avec des zillions de paquets installés de cette manière il n'y a plus vraiment moyen de s'assurer de la mise à jour des versions de libs pour l'ensemble du système et des applications.
Clairement. Et il y a aussi un impact de gaspillage mémoire.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à jour. C'est surtout ça mon point.
Parfaitement d'accord.
Eric Masson
Marc SCHAEFER writes: 'Lut,
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers, un mécanisme de virtualisation légère similaire fonctionnellement aux jails FreeBSD. -- Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Marc SCHAEFER <schaefer@alphanet.ch> writes:
'Lut,
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot,
vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers, un mécanisme de
virtualisation légère similaire fonctionnellement aux jails FreeBSD.
--
Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web
peuvent poser des questions ? Ce forum de conseils est très bien, mais
il serait bon de pouvoir discuter de vive voix avec des conaisseurs.
-+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers, un mécanisme de virtualisation légère similaire fonctionnellement aux jails FreeBSD. -- Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
Marc SCHAEFER
Eric Masson wrote:
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers.
Pas très étonnant, le monde Ubuntu est plutôt lxc/lxd.
Eric Masson <emss@free.fr> wrote:
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot,
vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers.
Pas très étonnant, le monde Ubuntu est plutôt lxc/lxd.
Il n'y a pas de confinement ? Je croyais que c'était au moins un chroot, vu que toutes les libs sont livrées avec le pseudo-fs.
Il semble que cela soit basé sur les Containers.
Pas très étonnant, le monde Ubuntu est plutôt lxc/lxd.
Dominique
Le 10/05/2018 à 08:36, Marc SCHAEFER a écrit :
Dominique wrote:
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que l'application est téléchargée avec son propre fs, un petit peu comme Docker.
Snap a donc été utilisé lors de l'installation de la 18.04, car, de mon point de vue, j'ignorais qu'il pouvait exister un autre monde qu'apt-get-install...
Vu, merci pour le lien. En faisant un snap list, j'obtiens : :~$ snap list Nom Version Révision Suivi Développeur Notes core 16-2.32.6 4571 stable canonical core gnome-3-26-1604 3.26.0 64 stable/… canonical - gnome-calculator 3.28.1 167 stable/… canonical - gnome-characters 3.28.0 86 stable/… canonical - gnome-logs 3.28.0 31 stable/… canonical - gnome-system-monitor 3.26.0 39 stable/… canonical - Sachant que je n'utilise pas Gnome mais KDE, j'en déduis que je peux désinstaller ces applis. Je fais une grosse bêtise en cas, ou pas ? Je te remercie pour ton éclairage, -- Dominique Courriel : dominique point sextant ate orange en France Esto quod es
Le 10/05/2018 à 08:36, Marc SCHAEFER a écrit :
Dominique <zzz@aol.com.invalid> wrote:
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De
mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils
concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que
l'application est téléchargée avec son propre fs, un petit peu
comme Docker.
Snap a donc été utilisé lors de l'installation de la 18.04, car, de mon
point de vue, j'ignorais qu'il pouvait exister un autre monde
qu'apt-get-install...
Par pure curiosité, à quoi correspondent les quelques 12 /dev/loop ? De mémoire, je n'avais rien de semblable sous Ubuntu 16.04... et ils concernent tous Gnome.
Je me demande si ce n'est pas le "store" d'Ubuntu: l'idée est que l'application est téléchargée avec son propre fs, un petit peu comme Docker.
Snap a donc été utilisé lors de l'installation de la 18.04, car, de mon point de vue, j'ignorais qu'il pouvait exister un autre monde qu'apt-get-install...
Vu, merci pour le lien. En faisant un snap list, j'obtiens : :~$ snap list Nom Version Révision Suivi Développeur Notes core 16-2.32.6 4571 stable canonical core gnome-3-26-1604 3.26.0 64 stable/… canonical - gnome-calculator 3.28.1 167 stable/… canonical - gnome-characters 3.28.0 86 stable/… canonical - gnome-logs 3.28.0 31 stable/… canonical - gnome-system-monitor 3.26.0 39 stable/… canonical - Sachant que je n'utilise pas Gnome mais KDE, j'en déduis que je peux désinstaller ces applis. Je fais une grosse bêtise en cas, ou pas ? Je te remercie pour ton éclairage, -- Dominique Courriel : dominique point sextant ate orange en France Esto quod es
