Fichier snap?

Le
llgg
Bonjour,

Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Je n'ai pas encore ça sur ma distribution principale.

J'aurai aimé savoir ce que vous en pensez dans ce forum?

--
Leger
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #26516074
llgg , dans le message
Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?

Non, c'est le passé qui essaie de se prétendre l'avenir.
llgg
Le #26516078
Le Mon, 06 May 2019 19:46:39 +0000, Nicolas George a écrit :
llgg , dans le message
Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?

Non, c'est le passé qui essaie de se prétendre l'avenir.

Ah.
Du coup ça ne plaît pas à tous le monde en fin de compte?
C'est vrai qu'on avait déjà un système qui fonctionne pas trop mal.
Bon ben on verra bien ce que ça va donner.
Ca se trouve on va en arriver à pouvoir télécharger un programme à partir
d'un site quelconque en y faisant une confiance aveugle. (des sites comme
telecharger.com par exemple)
--
Leger.txt
llgg
Le #26516183
Le Tue, 07 May 2019 15:25:27 +0200, zeLittle a écrit :
Je me suis un peux mal exprimé: AppImageKit permet de créer un seul
fichier-paquet-auto-exécutable. On double-clic dessus et l'application
se lance (y'a pas de copier-coller de fichiers çà et là dans le
filesystem; c'est plus qu'un simple installateur). Pour caricaturer,
tout se passe comme si les fichiers étaient dépaquetés en mémoire-RAM.

Merci pour ces explications.
Personnellement je n'aime pas cette tournure des événements.
Je ne suis pas trop d'accord avec snap et compagnie.
Mais bon, je vais attendre de voir ce que ça donne.
--
Leger
JKB
Le #26516198
Le Wed, 8 May 2019 10:23:46 +0200,
zeLittle
"llgg" a écrit dans le message de groupe de discussion :
qasu0l$1kvv$
Je ne suis pas trop d'accord avec snap et compagnie.
Mais bon, je vais attendre de voir ce que ça donne.

Je vais radoter, mais suis personnellement pro-snap (mais j'attends aussi:
trop récent pour voir ce que ça donnera; en attendant, mettre les mains dans
la "cambouis" avec imageApp n'est pas contradictoire), car j'adhère à la
raison qui a fait que plusieurs leaders de format de paquets (*.deb zé
*.rpm) se soient entendus, avec Canonical comme fer de lance: la vraie
raison de ce format d'installation naissant, c'est le marché Linux desktop.
La création d'une norme d'installation universelle d'applications, la
définition d'un seul format qui permette de créer une seule et même
installation à destination de toute l'idiosyncrasie de chaque installation
spécifique aux us et coutumes de l'utilisation du filesystem selon chaque
distribution LinuxPOSIX-***desktop*** répond à ce fait: sur le desktop,
"Mr et Mme Michut" n'utilisent pas Linux. Ils utilisent Windows. Et ils n'y
iront pas tant qu'ils s'entendront dire qu'ils doivent apprendre à taper des
lignes de commandes. Le seul fait d'apprendre qu'ils doivent à minima
retenir s'ils seront sur une distro. pro-*.deb ou pro-*.rpm les effraient...
Snap cache l'idiosyncrasie du desktop Linux. Pour l'utilisateur final d'un
Linux-desktop, Linux apparaitra alors comme un tout homogène, en face de
Windows.
Le truc que je surveillerai d'un œil, c'est que si snap décolle (il peut
être un catalyseur de l'adoption d'un Linux-desktop par "Mr et Mme Michut"
qui n'auront plus qu'à trancher selon leur mixture de fonction
d'utilitébeauté d'un bureau), alors fatalement ce sera parce que des
scripts-shell ou que sais-je encore, bref du code-adaptateur
multi-distros-desktop sera factuellement sérialisé, et disponible par et
pour la communauté snap. Là, je basculerai vers ce format.

C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque. Si je me
souviens bien, c'était même l'argument ultime il y a quelques années
pour éviter les problèmes de DLL sous windows. Quant à l'empreinte
mémoire du truc, j'en rigole d'avance. On se demandera pourquoi il
faudra 16 Go de mémoire pour lancer la moindre distribution Linux
d'ici quelques années.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
zeLittle
Le #26516207
"JKB" a écrit dans le message de groupe de discussion :

C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.


Ce n'est pas l'avis de Linus Torvalds ***quant à Linux-desktop***.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.


Oui: on parlait de l'enfer des dlls, parce que chaque application y allait
de l'installation de sa dll supposée "shared" par dessus celle installée
pour que son appli. fonctionne... quitte à casser le fonctionnement des
autres. Et Linux est tombé dans les mêmes erreurs: le loader d'ELF de Linux
regarde dans les chemins "génériques" (un peu partout de fait de
l'idiosyncrasie des distro. Linux-desktop. Ensuite, il regarde les
registrations des librairies.
==> le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait
aussi pratique que Windows du point de vue des développements desktop, à
savoir regarder en priorité d'abord dans le même répertoire que
l'application chargée, si la librairie "NEEDED" ne s'y trouverait pas, par
le meilleur des hasards (avant d'aller voir dans )!!! La majorité des
applis-desktop Windows installent leurs dll juste à côté de l'exécutable
maintenant: ça n'est pas pour rien. Du coup, Linux-desktop a du retard quant
à la compréhension de l'utilisation simplifiée des librairies.
Le problème, c'est que si "monsieur Michut" achète un desktop-Linux, il se
fout complètement de l'administration zé des administrateurs: c'est *son*
ordinateur. Il veut pouvoir y installer facilement des logiciel pour éditer
des fichiers, écouter de la musique, voir des vidéos, et naviguer sur
internet. system.d, il s'en fout comme de l'an 40 (vu qu'on est le 8 mai)
==> il veut installer un logiciel pour Linux-desktop. Point barre.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.


Les programmeurs chargent et déchargent les dll, créent et détruisent les
objets, selon les besoins contextuels des fonctionnalité demandé par
l'utilisateur. Toutes les fonctionnalités ne sont jamais chargées en même
temps en mémoire.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).


L'empaquetage Debian ou Red-hat continuera; Mais là, ça deviendra un
empaquetage pour l'installation de l'OS-même, ou pour des paquets très
orientés shell. Bref, des paquets d'administration que "monsieur Michut"
voit défiler quand il accepte de mettre à jour son desktop-Linux.
Concernant Snap, les dépendances sont également correctement gérées. Mais
elles restent à 90% dans le
/home/.MrMichut/tous-les-fichiers-nécessaires-à-l-appli.
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.


Des machines *nix-desktop? Ouah!!? Vous travaillez sous quelles
distro.-desktop dans votre entreprise? Quand tu veux installer une
application pour retoucher une image, tu peux le faire sans attendre 3 jours
que ton administrateur ait terminé l'écriture de son script d'admin., ou sa
migration du serveur de BDD de l'entreprise, ou...?
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !


De telles applis existent déjà, sont téléchargeables depuis le logithèque
d'Ubuntu d'ailleurs (je viens de vérifier: Canonical a intégré son
snap-store dans la logithèque; c'est transparent sur cette distro.) ==> Gimp
n'a pas besoin de 32 Go de mémoire. Et "Mr Michut" n'installe pas une
serveur de BDD sur son poste. S'il le fait, alors il est conscient ou on lui
fera vite comprendre qu'il va devoir acquérir des compétences de DBA pour
PostgreSQL, MS-SQL (qui est maintenant disponible sous Linux), ou Firebird.
Mais dans ce cas, ça veut dire qu'il a décidé de s'intéresser à
l'informatique côté "cambouis", et non plus de rester dans la catégorie
simple consommateur multi-média.
JKB
Le #26516209
Le Wed, 8 May 2019 12:13:20 +0200,
zeLittle
"JKB" a écrit dans le message de groupe de discussion :

C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.

Ce n'est pas l'avis de Linus Torvalds ***quant à Linux-desktop***.

Personnellement, je me cogne de l'avis d'un type qui a trouvé le
moyen de mettre dans le noyau un serveur web...
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.

Oui: on parlait de l'enfer des dlls, parce que chaque application y allait
de l'installation de sa dll supposée "shared" par dessus celle installée
pour que son appli. fonctionne... quitte à casser le fonctionnement des
autres. Et Linux est tombé dans les mêmes erreurs: le loader d'ELF de Linux
regarde dans les chemins "génériques" (un peu partout de fait de
l'idiosyncrasie des distro. Linux-desktop. Ensuite, il regarde les
registrations des librairies.

Et ne peut-on pas s'inspirer du fonctionnement des BSD ? Ah non,
c'est pas libre et c'est trop simple. Dans les BSD, le chemin des
bibliothèques est dans le fichier exécutable. Ça évite ce genre de
conneries (comme le segfault bien connu lorsqu'un exécutable utilise
deux versions de la même bibliothèque, l'une chargée par
l'exécutable et l'autre en tant que dépendance d'une autre
bibliothèque).
==> le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait
aussi pratique que Windows du point de vue des développements desktop, à
savoir regarder en priorité d'abord dans le même répertoire que
l'application chargée, si la librairie "NEEDED" ne s'y trouverait pas, par
le meilleur des hasards (avant d'aller voir dans )!!! La majorité des
applis-desktop Windows installent leurs dll juste à côté de l'exécutable
maintenant: ça n'est pas pour rien. Du coup, Linux-desktop a du retard quant
à la compréhension de l'utilisation simplifiée des librairies.

Il faudrait surtout éviter de réinventer l'eau tiède.
Le problème, c'est que si "monsieur Michut" achète un desktop-Linux, il se
fout complètement de l'administration zé des administrateurs: c'est *son*
ordinateur. Il veut pouvoir y installer facilement des logiciel pour éditer
des fichiers, écouter de la musique, voir des vidéos, et naviguer sur
internet. system.d, il s'en fout comme de l'an 40 (vu qu'on est le 8 mai)
==> il veut installer un logiciel pour Linux-desktop. Point barre.

Dans ce cas, on en fait un paquet pour linux-desktop et on n'invente
pas une nouvelle usine à gaz.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.

Les programmeurs chargent et déchargent les dll, créent et détruisent les
objets, selon les besoins contextuels des fonctionnalité demandé par
l'utilisateur. Toutes les fonctionnalités ne sont jamais chargées en même
temps en mémoire.

Ah ah... Jusqu'au jour où, comme les applications vont mettre des
plombes à se lancer, elles seront préchargées comme sous Windows.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).

L'empaquetage Debian ou Red-hat continuera; Mais là, ça deviendra un
empaquetage pour l'installation de l'OS-même, ou pour des paquets très
orientés shell. Bref, des paquets d'administration que "monsieur Michut"
voit défiler quand il accepte de mettre à jour son desktop-Linux.
Concernant Snap, les dépendances sont également correctement gérées. Mais
elles restent à 90% dans le
/home/.MrMichut/tous-les-fichiers-nécessaires-à-l-appli.

Et c'est bien là le problème. On rajoute une couche sur une autre
couche en espérant régler les problèmes de la première couche par
une seconde. C'est antinomique et aberrant. En un seul mot,
shadokien.
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.

Des machines *nix-desktop? Ouah!!? Vous travaillez sous quelles
distro.-desktop dans votre entreprise? Quand tu veux installer une
application pour retoucher une image, tu peux le faire sans attendre 3 jours
que ton administrateur ait terminé l'écriture de son script d'admin., ou sa
migration du serveur de BDD de l'entreprise, ou...?

Dans une entreprise qui se respecte, même sous Windows, tu ne peux
pas installer un logiciel qui n'est pas explicitement autorisé par
l'adminsys. Sinon, c'est le bordel assez rapidement. Autre
argument ?
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !

De telles applis existent déjà, sont téléchargeables depuis le logithèque
d'Ubuntu d'ailleurs (je viens de vérifier: Canonical a intégré son
snap-store dans la logithèque; c'est transparent sur cette distro.) ==> Gimp
n'a pas besoin de 32 Go de mémoire. Et "Mr Michut" n'installe pas une
serveur de BDD sur son poste. S'il le fait, alors il est conscient ou on lui
fera vite comprendre qu'il va devoir acquérir des compétences de DBA pour
PostgreSQL, MS-SQL (qui est maintenant disponible sous Linux), ou Firebird.
Mais dans ce cas, ça veut dire qu'il a décidé de s'intéresser à
l'informatique côté "cambouis", et non plus de rester dans la catégorie
simple consommateur multi-média.

Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD. Pour cela, je teste à la fois le fichier
image et la version compilée (par mes soins) pour debian/testing.
L'un et l'autre lancés, je mets ma machine à genou avec 32 Go de
mémoire parce FreeCAD vient avec toutes ses dépendances. Tant que tu
n'as que deux ou trois applications du genre, ça fonctionnera à peu
près. Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
On ne résout un problème qu'en l'attaquant à la base. Pas en
rajoutant une surcouche. Et c'est pour cela que Linux en poste de
travaille ne perce pas. Pourquoi s'emmerder avec un nouvel OS qui
a exactement les mêmes défauts que l'existant ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
zeLittle
Le #26516226
"JKB" a écrit dans le message de groupe de discussion :

Et ne peut-on pas s'inspirer du fonctionnement des BSD ? Ah non,
c'est pas libre et c'est trop simple. Dans les BSD, le chemin des
bibliothèques est dans le fichier exécutable. Ça évite ce genre de
conneries (comme le segfault bien connu lorsqu'un exécutable utilise
deux versions de la même bibliothèque, l'une chargée par
l'exécutable et l'autre en tant que dépendance d'une autre
bibliothèque).


Et bien +1 à BSD. Debian ferait bien de s'en inspirer alors.
Dans une entreprise qui se respecte, même sous Windows, tu ne peux
pas installer un logiciel qui n'est pas explicitement autorisé par
l'adminsys. Sinon, c'est le bordel assez rapidement. Autre
argument ?


Ben, c'est pour cela que certains viennent avec leur ImageApp (snap demain?)
d'un logiciel sur leur clé USB: ils peuvent ainsi lancerutiliser l'appli.
sans que l'adminsys sache même que ça existe :-D .
==> des tas de gens qui doivent faire une initiation à Linux le font ainsi,
contraints zé obligés car refroidis par des expériences malheureuses mais
inévitables: parce qu'ils savent que sans cela, ils prennent un risque
d'arriver le matin et le temps que l'adminsys d'un lycée ou d'un collège ait
fini d'installé le parc d'incitation pour de simples applis à destination
des béotiens venus apprendre, et bien ces derniers retourneront très
probablement chez eux avec l'idée que s'ils veulent installer un
Linux-desktop chez eux, 'va falloir apparemment qu'ils apprennent aussi de
l'administration système (d'ailleurs, y'en a peut être des rares qui
travaillent sous Linux-desktop au bureau, parmi lesquels un prorata a
développé ce sentiment...), alors que snap a été créé pour tenter de cacher
ce frein psychologique, et permettre au plus grand nombre n'avoir le
sentiment qu'utiliser un Linux-desktop n'est pas réservé à une élite.
Calimero
Le #26516253
Le 08/05/2019 à 13:59, zeLittle a écrit :
"JKB"  a écrit dans le message de groupe de discussion :

Et ne peut-on pas s'inspirer du fonctionnement des BSD ? Ah non,
c'est pas libre et c'est trop simple. Dans les BSD, le chemin des
bibliothèques est dans le fichier exécutable. Ça évite ce genre de
conneries (comme le segfault bien connu lorsqu'un exécutable utilise
deux versions de la même bibliothèque, l'une chargée par
l'exécutable et l'autre en tant que dépendance d'une autre
bibliothèque).

Et bien +1 à BSD. Debian ferait bien de s'en inspirer alors.


jp willm
Le #26516304
Le 08/05/2019 à 12:19, JKB a écrit :
Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.

Bon courage et merci, car ça semble plombé !
Mais je crache dans la soupe, car j'utilise FreeCAD 0.16 en appimage.
Sans barre d'outils personnalisée, je n'y serais probablement pas arrivé
à m'en sortir :
Pas question de travailler sur de gros fichiers sans avoir au moins 8Go
de RAM.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.

Moi aussi, mais jaune...
--
jp willm
http://perso.orange.fr/willms/index.html
JKB
Le #26516309
Le Thu, 9 May 2019 13:02:47 +0200,
jp willm
Le 08/05/2019 à 12:19, JKB a écrit :
Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.

Bon courage et merci, car ça semble plombé !
Mais je crache dans la soupe, car j'utilise FreeCAD 0.16 en appimage.

J'utilise une 0.0.19 en rolling release. Il y a quelques trucs qui
m'énervent dans les éditions des esquisses intermédiaires, mais
globalement, il vaut mieux un 0.0.19 qu'une 0.0.16...
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.

Moi aussi, mais jaune...

Meuh non... Il paraît que ce format, c'est pour notre bien.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme