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:
/lib/x86_64-linux-gnu/libresolv-2.28.s 91K
/lib/x86_64-linux-gnu/ld-2.28.so 162K
/lib/x86_64-linux-gnu/libc-2.28.so 1.8M
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.
Donc, plus gros, oui, mais ou? Sur le disque ou en mémoire? Lequel est le plus important?
et surtout en cas de faille de sécurité sur une lib (au hasard la libc), il faut recompiler tout le système
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 freem . En réponse au message Différence entre une application AppImage et une application installée. É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).