Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de PieD :
- [09/06@18:42] Sortie de KDE 3.2.3
- [09/06@10:48] Mozilla avance toujours...
- [31/05@08:57] Vote pour une fonctionnalité dans KDE...
- [29/05@21:36] Linux Mag 62
- [26/05@13:48] KDE 3.3 alpha 1
- [22/05@20:31] Les logiciels libres sont forcément mieux !
- [15/05@21:58] Aide sur KIO...
- [15/05@21:37] Capture d'écran en vidéo
- [08/05@14:45] Problème en XUL
- [05/05@20:27] Palladium abandonné !!!
- [29/04@14:31] Le coin du développeur sous linux ?
- [19/04@12:14] Solidworks sous linux
- [12/04@19:50] Cherche à participer à un projet
- [09/04@16:22] Longhorn retardé !
- [31/03@20:12] MSN et ces licences
- [17/03@14:04] Marre !
- [03/03@12:07] Qui a un kit wanadoo Extense Wifi ?
Aujourd'hui, je présente à tout le monde mon petit script écrit à la va-vite ce matin sur du papier brouillon : il me permet de faire passer une installation de firefox 0.9Rc1 (mais ça marche aussi avec les nightly) de 19,1Mo à 10,2Mo en 1 minute 9 secondes sur mon athlon 2000+
Comme ça, je suis moins jaloux du travail fait sur la version win dont l'installeur ne pèse que 4,6Mo ;)
J'espère que vous trouverez des améliorations à y apporter !
Notamment, comment faire pour vérifier la présence d'un fichier ? Et quels autres fichiers puis-je compresser ?
Voici le script :
#!/bin/sh
export ff_dir="firefox-test"
cd $ff_dir
echo "UPX..."
upx --best firefox-bin
upx --best mozilla-xremote-client
upx --best xpicleanup
upx --best components/talkback/talkback
echo "JAR..."
cd chrome
for i in *.jar;
do
mkdir temp;
mv $i temp/$i;
cd temp;
unzip $i;
rm -f $i;
zip -r -9 $i *;
cp $i ../;
cd ..;
rm -fr temp;
done;
Il faut indiquer au début du script l'emplacement de firefox.
Je prépare la même chose pour l'installeur...
En espérant que ce script vous sera utile...
> Lire le journal (18 commentaires, moyenne: 1,6).
Premier changement
J'ai trouvé moi même une réponse à ma question comment savoir si un fichier existe... Voici donc une petite modification à faire au script :
remplacer la ligne upx --best components/talkback/talkback par
if [ -a "components/talkback/talkback" ] ; then
upx --best components/talkback/talkback;
fi
Comme ça ceux qui ont pas installé ce composant n'auront pas de problèmes...
-
[^]Re: Premier changement
Posté par Jazz () le 10/06/2004 à 18:45. (lien). Évalué à 1.if [ -a "components/talkback/talkback" ] ; then
Je pense que c'est plutôt ceci que tu veux:
if [ -f "components/talkback/talkback" ] ; then
-a, c'est le ET logique.-
[^]Re: Premier changement
Posté par Pinaraf (Jabber id, ) le 10/06/2004 à 18:54. (lien). Évalué à 1.J'ai lu cette info dans la page de man de bash et ça marche apparemment... Au début j'essayais avec -f (qui me semble plus logique) et ça marchait pas.
-
[^]Re: Premier changement
Posté par Jazz () le 10/06/2004 à 21:30. (lien). Évalué à 3.En effet, sous bash, -a marche. Mais seulement si sh est en réalité bash. Mieux vaut alors remplacer #!/bin/sh par #!/bin/bash. Sinon, man test.
Celà dit, bizarre que -f ne fontionne pas pour toi...-
[^]Re: Premier changement
-
-
-
Un peu HS, désolé....
Ce journal me donne l'occasion de poser une question que je me suis déjà posé y'a un moment : pourquoi les distributions linux n'utilisent-t-elles pas plus souvent upx pour compresser les exécutables les plus imposants, genre > 500ko ? Les paquets seraient ansi moins gros à télécharger, comme pour le cas de firefox ici, puisque upx compresse beaucoup plus les binaires que tar.gz & co. De nombreux Mo seraient gagnés mine de rien.
En plus sur les machines récentes le temps de chargement supplémentaire du à upx est à priori négligeable... Cela dit, vous me direz qu'avec l'internet rapide et les gros disques actuels on se moque de la taille des binaires...
Enfin voila, c'était ma question existentielle du jour (suis pas très inspiré en ce moment ^^)
-
[^]Re: Un peu HS, désolé....
Posté par Pinaraf (Jabber id, ) le 10/06/2004 à 18:38. (lien). Évalué à 2.Cela serait particulièrement intéressant pour un liveCd !
Mais bon, upx (avec l'option --best) reste lent à compacter donc ça enlève l'envie de compresser 1Go de programmes... Voici les résultats sur l'exécutable de firefox (sur mon Athlon XP2000+ toujours...)
[pierre@localhost firefox-base]$ time upx --best firefox-bin
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
UPX 1.24 Markus F.X.J. Oberhumer & Laszlo Molnar Nov 7th 2002
File size Ratio Format Name
-------------------- ------ ----------- -----------
9749588 -> 4055109 41.59% linux/386 firefox-bin
Packed 1 file.
41.23user 0.48system 0:48.83elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+25735minor)pagefaults 0swaps
48 secondes pour compresser 9,8Mo c'est plutôt chiant si le nombre de paquets est trop élevé...-
[^]Re: Un peu HS, désolé....
Posté par shinobufan (page perso, ) le 10/06/2004 à 18:51. (lien). Évalué à 2.Oui c'est clair vu comme ça ca parait un peu pénible... Mais ajouté au fur et à mesure aux scripts de génération de paquets (quelque soit leur format et la distrib concernée ^^) ca ne serait rien. 48 secondes après je sais pas combien de minutes (heures ?) de compilation...
Mais si ce n'est pas fait, c'est qu'il soit y avoir une raison. Je ne sais pas laquelle par contre !?-
[^]Re: Un peu HS, désolé....
Posté par -=[ Benoit Plessis ]=- (page perso, ) le 10/06/2004 à 19:27. (lien). Évalué à 1.Peut etre (et meme surement) qu'en plus de ralentir la creation de packages, ca va ralentir l'execution des programmes.
--
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libr-
[^]Re: Un peu HS, désolé....
Posté par shinobufan (page perso, ) le 10/06/2004 à 19:38. (lien). Évalué à 2.Justement, j'avais cru comprendre qu'après la décompression qui s'effectue au chargement du binaire en mémoire, le programme ne souffrait d'aucun ralentissement puisqu'il est déjà complètement décompressé, ni même de surconsommation mémoire ni rien du tout o_O Alors ou est la faille ? ;)
-
[^]Re: Un peu HS, désolé....
Posté par djapat () le 10/06/2004 à 22:42. (lien). Évalué à 2.Le fait de devoir décompresser consomera du cpu au chargement pour le décomprésser... et le fait que c'est compressé POURRAIT demander moi de temps de chargement (lecture du fichier sur le disque) étant donné que le fichier est plus petit.
L'avantage premier est le gain en espace dique et il se peut que le temps de le temps de chargement + le temps de décompréssion soit bénéfique ou pénalisant: tout dépend du cpu (486 33Mhz ou p4 3000Mhz), du disque (vieux ide ou scsi) et du taux de compression du programme...
-
-
-
-
-
[^]Re: Un peu HS, désolé....
Posté par Mickaël L () le 11/06/2004 à 08:50. (lien). Évalué à 2.> Les paquets seraient ansi moins gros à télécharger, comme pour le cas de firefox ici, puisque upx compresse
> beaucoup plus les binaires que tar.gz & co.
Ça change la taille une fois sur ton ordinateur, pas la taille du fuchier que tu télécharges avant de l'installer. Si celui qui fait le paquet fournit un /usr/bin/firefox compressé comme ça dans son .tgz (ou .deb, .rpm), la taille du paquet sera en gros la même que s'il ne le compresse pas (parce que faut pas rêver, un algo de compression marche toujours moins bien sur des données compressées).-
[^]Re: Un peu HS, désolé....
-
Compression de l'installeur
Les gains sont vraiment moins importants...
(perfs sur l'installeur : la dernière nightly passe de 8,1 à 7,9 Mo : ridicule quoi...)
Le script pour l'installeur est dispo sur :
http://www.pinaraf.xalp.org/compact_installer.sh(...)
Le script pour un dossier installé de firefox sur :
http://www.pinaraf.xalp.org/compact_firefox.sh(...)
Toute remarque est la bienvenue
-
[^]Re: Compression de l'installeur
upx --compress-icons=0 *.dll
t'es pas le seul à avoir eu cette idée.
Je l'utilisais pour mozilla <1.2 et qui mettait des plombes sans compression à charger surtout sur mon pauvre celeron de l'époque et de mon pauvre dd.
avec upx , tu peux compresser les dll sous "fenetre" et ca mettait 5 fois moins de temps a charger surtout que mon dd avait beaucoup de ko à lire ...
c'est utiliser par exemple par mame je crois.
Je trouvais par contre beaucoup moins efficasse le même traitement pour la version linux
Je suppose que maintenat ce qu'il faut utiliser c'est le prelink. Non ?
Ca doit donner des resultats aussi interessant en terme de temps de chargement ?
-
[^]Re: upx --compress-icons=0 *.dll
Cette page a été générée par Templeet en 0.0969s (dont 0.0164 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.