Christophe Merlet a écrit 2466 commentaires

Que penser du fait que le gars qui a écrit i love you ait été retrouvé.

Pas grand chose sinon que l'auteur n'a pas voulu être discret...
Voici les deux premières lignes du virus :
rem barok -loveletter(vbe) <i hate go to school>
rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / =
Manila,Philippines

Il fallait au moins le FBI et la CIA réuni pour trouver le coupable...

Je précise que gimp-print supporte complètement les epson 6 couleurs et les impressions à 2880 dpi (comme sur ma 880) et _surtout_ est GPL...

Je suis tenté de répondre que c'est avec les Epson que l'on obtient les meilleurs résultats sous Linux. J'ai une Epson Stylus Color 880 sur iMac (USB) et je la fait fonctionner grace à :
cups : http://www.cups.org/(...)
gimp-print : http://gimp-print.sourceforge.net/(...)
gtklp : http://www.stud.uni-hannover.de/~sirtobi/gtklp/(...)

Sans rentrer dans les détails je dirait simplement que cups rend l'impression sous Linux aussi convivial que sous Windows et je suis bien content que Mandrake ai décidé d'utiliser ce système.

Ce fût vraiment subliminal...
Le CCC a eu droit a un peu plus de temps mais ils n'ont même pas évoqué l'ICANN.

Alors juste une stat de plus...

Sur un iMac DV SE 400MHz 128Mo la compilation de Qt 2.2.1 prend 1h30.
Pour comparaison mes stats précédentes était sur un PIII 650MHz 128Mo.

Il semble donc qu'un PowerPC est moins performant qu'un PIII pour compiler du C++.
Fort heureusement cela n'est pas vrai pour tout ;)

Une différence tout de même entre les deux machines. Le PIII utilise le kernel 2.4.0-test9 et une glibc optimisé. Le iMac utilise le kernel 2.2.16 et la glibc d'origine.

Il ne faut par contre pas espérer de stats sur KDE2. D'abord parceque je ne me le suis pas déjà installé avec les anciennes options de compilation, ensuite parceque je ne vais pas faire une double compilation vu le temps que ça me prend. Déjà que je le fais sur PIII et PowerPC...

Voici les chiffres avec Qt-2.2.1.

Avant (-O3 -s -march=pentiumpro) :
libqt-mt.so.2.2.1 : 7078752 octets sur disque
libqt.so.2.2.1 : 7056768 octets sur disque
designer : 2623656 octets sur disque et 7752 ko en mémoire

Aprés (-O3 -s -march=pentiumpro -fno-exceptions -fno-rtti) :
libqt-mt.so.2.2.1 : 4735176 octets sur disque
libqt.so.2.2.1 : 4720488 octets sur disque
designer : 1711568 octets sur disque et 6048 ko en mémoire

Soit un gain total sur disque de 5600 ko
et un gain de 1700 ko de mémoire rien que pour designer.
J'ai aussi gagné 5 minutes (51 au lieu de 56 mn) en temps de compilation.

Je suis sur le cul. Si les gains sont les mêmes pour les bibliothèques et applications KDE et se cumulent, c'est gigantesque...

Osons, osons supprimer les exceptions...

J'ai essayé avec qt-1.45 (C'est beaucoup plus rapide a compiler). Je n'ai activé que -fno-exceptions en plus de mes habituelles options (-fno-rtti fait perdre la compatibilité binaire).

Voici les chiffres :
Avec mon ancien Qt-1.45 (-03 -s -march=pentiumpro) que je croyais optimisé :
libqt.so.1.45 = 1917745 octets sur disque
kfm = 6808 ko en mémoire vive

Avec mon nouveau Qt-1.45 (-03 -S -march=pentiumpro -fno-exceptions) :
libqt.so.1.45 = 1455496 octets sur disque
kfm = 6004 ko en mémoire vive

Soit un gain de 500ko sur disque et de 800 ko en mémoire !!!
Et a l'exécution c'est effectivement plus rapide.

Si je spécule sur Qt-2.2.1 (libqt-mt et libqt sont chacune 7 Mo) les gains vont être énorme.
Allez c'est parti je recompile QT2.

Mais pourquoi Qt et KDE n'inclue pas cette option par défaut depuis toujours ??????????????

Comme le dit le thread le C++ utilise normalement les exceptions pour faire remonter les erreurs. Il est donc a mon avis dangereux de désactiver les exceptions car, d'après certains, cela peut résulter en un plantage pur et simple. Si Qt n'utilise effectivement pas les exceptions pour traiter les erreurs, alors espérons que dans la prochaine version elles soit désactiver par défaut. Idem pour KDE.

GCC active par défaut les exceptions lorsqu'il compile du code C++ et les désactive pour du code C.
On ne devrait normalement pas surcharger les options -fno-exceptions et -fno-rtti en dehors du Makefile a moins d'avoir une parfaite maitrise du code. Enfin je crois...

Mais beaucoup disent que cela améliore énormement les performances...

A ce propos j'avais posé la question ya un an :
http://news.gnome.org/gnome-news/938480153/938556407/938562945/9386(...)

ee est lent du fait qu'il charge l'intégralité de l'image en mémoire pour l'afficher...

Je précise qu'Apache et Squid supporte les connexions pipelinées depuis les versions 1.2. Il était temps que Netscape/Mozilla le supporte enfin...

Le pipelining est la possibilité d'envoyer plusieurs requêtes simultanément à la suite les unes des autres sans avoir a attendre de confirmation pour chaque requête. Les réponses du serveurs sont elles aussi sérialisées.
Au final beaucoup moins de paquets circulent sur le réseau donc c'est plus rapide et plus encore lorsque les données sont compressées à la volée. C'est mieux que plusieurs téléchargement HTTP1/0 en parallèle.

Un vieux document explique bien cela :
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html(...)

Whaou !
Je suis impressionné par cette milestone.

Le rendu des polices de caractères n'est pas génial et ya encore pas mal de bogues cosmètiques mais à part ça je surfe plus vite qu'avec Netscape.

Dans les préférences, sous Debug/Networking activez le pipelining, ça améliore vachement (surtout avec un proxy squid)

Je viens de le faire et ça marche !
$ touch "Et ta mère, ça va?.txt"

Où est le problème ?

C'est nul de dévoiler aussi vite le pot au rose !
Y'aura même pas eu de troll :-((

N'en reste pas moins que Pan est un excellent logiciel.

> Quoi ? T'utilises pas encore OpenSSH ?! :-)

Forcément, c'est interdit en France !
Du moins si j'en crois ce lien http://www.scssi.gouv.fr/present/chiffre/liste.html(...)

Selon le décret n°99-200 du 17 mars 1999, l'utilisation et l'importation de produits de chiffrement utilisant des clés de longueur inférieure ou égale à 128 bits sont libres à condition d'avoir été déclarées.

Donc il faut utiliser SSF http://ccweb.in2p3.fr/securite/ssf/(...)
"SSF est une adaptation de la suite publique "SSH Unix", destinée à l'usage sur le territoire français en conformité avec la législation française concernant la cryptologie.
SSF-128 est un produit dont la taille de l'espace de clé est limitée à 2128, et dont l'usage est libre (les utilisateurs n'ont aucune démarche à effectuer).
Il a fait l'objet de la déclaration n° 9908271 auprès du SCSSI."

Quelqu'un confirme un bonne fois pour toute afin de lever un doute...

Oui tout le monde n'utilise que 1% de sa distrib !
Le problème c'est que ce 1% n'est pas le même pour tout le monde...