Bonjour
Je me pose la question suivante :
Une application AppImage est-elle plus rapide en exécution qu'une application installée à partie d'un paquet d'installation.
Merci d'avance pour votre réponse
temp007_27
Forum Linux.debian/ubuntu Différence entre une application AppImage et une application installée
3
fév.
2021
# delicat à chiffrer
Posté par NeoX . Évalué à 7. Dernière modification le 03 février 2021 à 18:40.
de ce que je sais une AppImage, c'est comme un docker, tu as donc l'appli, les bibliothèques liés à cette appli, ca permet de s'installer n'importe où indépendamment des bibliothèques de la distribution qui parfois ne sont pas à jours par rapport à ton logiciel.
mais ton logiciel devra toujours charger ces bibliotheques pour démarrer.
Le logiciel de ta distribution, lui pourra utiliser les bibliothèques prechargées par un autre logiciel si c'est le cas, sinon devra aussi charger les bibliothques nécessaires.
plus d'infos sur l'AppImage
https://itsfoss.com/use-appimage-linux/
[^] # Re: delicat à chiffrer
Posté par freem . Évalué à 6.
Pas vraiment, c'est beaucoup moins évolué. AppImage, c'est simplement une image disque (nécessite fuse) qui contiens, comme tu l'indiques ensuite, d'une part le binaire, et d'autre part une partie des ressources dont le binaire à besoin, ce qui implique généralement une partie des bibliothèques partagées.
Bon, c'est plus qu'une image disque, puisque ça s'exécute, donc il y a une sorte de "bootloader", qui va également indiquer ou sont les libs à l'intérieur (on ne peux pas compter sur le ld de la distrib pour ça, l'organisation est probablement différente entre le côté "natif" et le côté "embarqué").
Autre point de différence par rapport à docker: pas de gestion de namespace, de cgroups et autres, sauf si c'est fait par l'appimage elle-même (peu probable), c'est donc "moins sécurisé". D'un autre côté, c'est aussi nettement plus simple techniquement et portable, ce qui a des avantages non-négligeables.
C'est valable également pour une partie des libs de l'appimage, celle-ci se reposant partiellement sur le système.
C'est d'ailleurs un point que j'ai tendance a reprocher tout en connaissant une partie de la réponse: pourquoi ne pas juste lier statiquement les libs partagées? Ça mènerait à une amélioration des performances après tout. Bon, la réponse, c'set que les écosystèmes C et C++ sont tellement partis dans le délire du link dynamique depuis tellement longtemps que lier en statique est bien souvent méga pénible et expose a des tonnes d'emmerdes.
Pour ce qui est de la performance, on pourrait avoir de meilleurs performances avec une appimage comparé à une installation système, sur un disque dur mécanique, du au fait que les données de l'appimage seront plus groupée, donc moins de déplacement de la tête de lecture.
Plus trop d'actualité, et l'impact est assez mineur (appimage sert surtout pour des applications de bureau à ma connaissance). Le reste, le travail de
ld, ben… ça c'est totalement aléatoire: si le dev à lié en statique le binaire dans l'appimage (pourquoi pas, après tout? ça permets d'avoir les données à côté et le fichier est simple a "installer" et exécuter:chmod +x $foo && ./$foo) alors il y a fort à parier que les performances soient plus élevée. Mais la distro aussi pourrait lier en statique.Il y a aussi, bien sûr, de nombreux autres facteurs: options de compilation, compilateur utilisé, différence de version des libs chargées par l'un ou l'autre… tout peut impacter la performance, donc on peut pas chiffre.
[^] # Re: delicat à chiffrer
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Pourrais-tu expliquer ce que tu entends par délire ? Parce que, bon, statique et dynamique, ça n'est pas forcément le même usage.
[^] # Re: delicat à chiffrer
Posté par freem . Évalué à 4.
Bonne remarque.
Ce que je voulais dire, c'est que la grande majorité de l'ecosysteme du C, du C++, me semble (oui, je mets de l'eau dans mon vin) oublier que le lien statique existe. On ne se pose quasi plus la question: le dynamique à plus de possibilités, donc autant l'utiliser.
Moi, j'ai un peu de mal avec ça,même si je sais que parfois c'est nécessaire, je pense que pour la majorité des applications que, moi, j'ai, ce serait plus efficace sur la perf et ferai utiliser du matos plus vieux.
Note: l'heure. Desolé :)
[^] # Re: delicat à chiffrer
Posté par gUI (Mastodon) . Évalué à 3.
Comme tout paradigme, l'appliquer sans réfléchir n'est jamais bon.
Le link statique a en effet énormément d'avantages, tout comme les variables globales ou les GOTO en C. Il faut juste savoir les utiliser à bon escient.
Tiens ce serait marrant de tester une distrib expérimentale 100% link statique (je sens que je vais ressortir un Yocto au prochain confinement moi)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: delicat à chiffrer
Posté par eric gerbier (site web personnel) . Évalué à 2.
le link statique a pour moi 2 gros inconvénients
- d'abord la taille des binaires qui va augmenter
- et surtout en cas de faille de sécurité sur une lib (au hasard la libc), il faut recompiler tout le système
[^] # Re: delicat à chiffrer
Posté par freem . Évalué à 2. Dernière modification le 10 février 2021 à 03:33.
Dans quelle mesure? Est-ce significatif par rapport au système?
Si je prend, par exemple, busybox de debian, le binaire statique pèse 1.9 megs.
Celui de la version dynamique pèse ~700 kilos.
Si j'ajoute le poids des libs:
Comme tu peux le voir, oui, dans le cas de la gblic ça va être pertinent, parce qu'elle est utilisée par l'ensemble du système. D'ailleurs, la plupart des appimage n'embarqueront pas de libc.
Par contre pour des libs peu usitées, je ne suis pas certain que ça soit si rentable que ça.
La conso de mémoire, par contre: dynamique:
Statique:
% ps -orss,vsz,args $(pidof busybox )
RSS VSZ COMMAND
4 2212 busybox sh
Donc, plus gros, oui, mais ou? Sur le disque ou en mémoire? Lequel est le plus important?
Non, juste relinker.
A ma connaissance, il n'existe que des distros qui filent soit les sources, soit les binaires finaux. Rien n'empêcherais en théorie une distro de filer les objets, et de juste faire le link à l'install.
Bien sûr, ça me semble très compliqué à réaliser, mais au niveau perfs, ça permettrait justement de ne link dynamique qu'a partir d'un certain nombre d'utilisations, voire en fonction de la fréquence d'usage.
Et question sécurité, pour le coup, l'avantage du link statique, c'est qu'on ne peux pas injecter de code avec un simple "export LD_PRELOAD=foobar" (ce qui est pratique pour le debug!).
De même, le bug de ta lib ne sera pas forcément dans tous les binaires, justement, contrairement au link dynamique.
D'ailleurs, le link statique est, il me semble, le chemin pris par go et rust, qui ont le vent en poupe ces derniers temps.
Bref, je pense que les deux approches sont valides, chacune brille a son niveau.
Les arguments que tu cites, même valides, ne sont que partiels (poids? En ram le static bouffe moins. Sécurité? Plus compliqué d'injecter du code, surface d'attaque réduite).
[^] # Re: delicat à chiffrer
Posté par cg . Évalué à 1.
Car il faut compiler chaque dépendance statiquement, et chaque dépendance de chaque dépendance, etc… C'est énormément de travail sur des grosses libs genre Qt ! On ne peut pas hélas faire juste un gros
cat *so > deps.a(certains langages comme Go s'en sortent bien de ce côté).Mais sur le fond je suis d'accord avec toi, j'aimerai que ce soit plus simple de produire des binaires statiques.
Voir aussi pour le fun Static Linux.
[^] # Re: delicat à chiffrer
Posté par NeoX . Évalué à 2. Dernière modification le 07 février 2021 à 17:25.
heureusement, on a inventé les makefile pour lister les dépendances, les compiler une seule fois, puis prendre les .o pour les ajouter à notre binaire
on ne recompile alors que les .o dont le code source a changé
[^] # Re: delicat à chiffrer
Posté par freem . Évalué à 2.
On est bien d'accords, malheureusement.
Tu connais beaucoup de gros projets dont le makefile n'est pas généré? Linux, peut-être, mais j'imagine qu'il ne link pas dynamique, de fait :)
Au-dela de ça, maintenir un makefile est assez difficile pour que les devs d'i3, notamment, soient passés aux autotools, puis (à en lire les commits) à meson.
Écrire son makefile est une plaie, vraiment. D'ailleurs, makefile pour quelle variante? Celle de GNU? De BSD? Un autre? Variante de quelle version?
Je préfère de loin écrire moi-même un ninja, c'est du même niveau, mais au moins je sais qu'il n'existe qu'une seule version, le fichier peut décrire pour quelle version il est censé fonctionner, et, d'ailleurs, ninja, contrairement à make (à ma connaissance), peut deviner de quels headers un .c ou .cpp à besoin, et ça, ça change la vie.
Il est aussi possible de gérer facilement quand une règle à plusieurs entrées et plusieurs sorties (utilisation de compilateurs de compilateurs (non, pas une faute de frappe)) ce que j'ai été incapable de faire proprement avec GNU make quand je me suis mis à coco-cppp.
Et puis, tout ça ne change pas le problème. Les outils en C et C++ sont, à ma connaissance, mauvais pour gérer l'ordonnancement des dépendances, et les link pètent tout le temps, avec des erreurs tout sauf compréhensibles (comment ça le symbole est pas présent? Le fichier contiens le symbole, est bien listé… ah putain il faut le décaler d'un cran dans la ligne de commande!!!).
Un jour, peut-être, je testerais mk de plan9… il paraît qu'il est intéressant, mais j'avoue que pour l'instant j'aime bien ninja (même si je devrais pas écrire mes ninja à la main…).
# A priori non
Posté par lolop (site web personnel) . Évalué à 4.
Sauf s'il y avait des options de compilation qui feraient que l'un est plus optimisé pour ta machine que l'autre, une fois chargé en mémoire la vitesse d'exécution sera la même.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# AppImage
Posté par temp007_27 . Évalué à 3.
Merci pour toutes vos réponses
J'ai appris des tas de choses
Je débute sur Ubuntu et ça m'aide
A bientôt
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.