> Jabber séduit aujourd'hui à la fois les particuliers
bof. Jabber est tres bien en theorie, en pratique c'est la galere.
Je suis sur jabber.org et ca plante regulierement. Pour les autres protocoles je suis sur charente.de et ca fonctionne pas au moins 1 fois par semaine !
Je n'ai pas encore trouve de serveur jabber efficace qui plante pas et qui supporte les autres protocoles. Il y a peut etre un serveur wpoeirlw.qrdwoijulw.sz qui fonctionne correctement mais comment etre sur de la perenite de ce genre de serveur ?
Bref ce qu'il faut a jabber c'est un serveur public officiel avec un nom approprie (jabber.com, jabber.org ou jabber.net) qui supporte le multi-protocoles et qui ne plante pas. Sinon c'est du vent.
J'utilise donc jabber mais je ne le recommande jamais autour de moi de peur de donner une mauvaise image a jabber et au logiciels libres (je recommande en revanche miranda et gaim).
Sur le forum hardware.fr il y a enormement de plaintes envers Free (contre FT c'etait aussi le cas, mais la c'est vraiment pas dans les memes proportions et quand on lit les temoignages ca semble souvent justifie).
Regarde par toi meme sur ce forum en faisant une recherche: http://forum.hardware.fr/forum1.php3?cat=4&config=&interfac(...)
Je ne sais pas si c'est mieux avec Tele2, mais Free est surement l'un des pires FAI ADSL en ce moment !
Bref je me contente de mon ADSL chez France Telecom/Wanadoo qui coute plus cher mais qui marche nikel 24h/24 depuis 2 ans.
> Avec une distrib où les paquets sont précompilés, il est tout à fait
> possible de compiler soi-même des paquets.
Tu n'as pas compris ce que je voulais dire, je me suis probablement mal exprime. Ce n'est pas un probleme de possibilite de recompiler un package mais un probleme de distribution de logiciels sous brevets.
XviD n'est pas dans la Debian de base ni dans les autres distribs, il faut telecharger des packages non officiels et probablement hors la loi. SuSE a modifie le logiciel MPlayer a cause des problemes de brevets.
RedHat a supprime le support MP3 de XMMS pour les meme raisons.
Mais imagine que RedHat propose en lieu et place du package binaire de XMMS, un package contenant que le code source. Etant donner que (si j'ai tout bien compris) les brevets logiciels n'implique que le binaire et pas le code source d'un logiciel, RedHat pourrait donc distribuer le code source de XMMS avec le support du MP3. Ensuite une jolie fenetre qui propose l'utilisateur de compiler XMMS et automagiquement l'utilisateur peut beneficier du *vrai* XMMS mais aussi de MPlayer, de XviD ect...
Je vois un autre intérêt des distros sources, les brevets logiciels !
Un projet comme XviD http://xvid.org/(...) ne peut pas redistribuer de binaire puisqu'il y a des brevets sur le MPEG-4.
J'imagine qu'une distrib qui fournirait les sources de XviD ne serait pas inquiété par les brevets.
Cela permettrait aussi d'activer certaines options dans des softs, de distribuer des softs ou il y a des problemes de licences cf MPlayer et Debian...
Egalement de proposer a la carte les softs qui posent problemes que dans certains pays (puisque l'on precise a l'install dans quel pays ont est et donc pas besoin de faire un cd NON-US par exemple).
Ceci dit j'ai peut etre tord parceque personne n'evoque cet atout des distribs sources.
Ca ne te derange peut etre pas que les drivers video soient pas libre mais moi ca me derange:
- difficulte d'installation
- que pour i386
- bugs
ect...
Je vois pas en quoi c'est drole, je trouve meme ca plutot triste.
Si Loki n'a pas reussi c'est que:
- se procurer les jeux Loki etaient plus difficiles que les versions windows dispo a la fnac
- difference de prix: souvent on trouvait la version windows a bas prix contrairement a la version Loki
- beaucoup de linuxiens ont un dual boot avec windows d'installe
- les drivers acceleres sous Linux ont des problemes (incompatibilite, pas libre, moins rapide...)
- retard de disponibilite de la version Loki
- il pouvait y avoir des bugs
- parceque les jeux portes etaient pas toujours super
- parceque la majorite des linuxiens sont des etudiants sans un sous
Les linuxiens supportent leur plateforme mais pas de la meme maniere que les communautes BeOS, MacOS, Amiga...
- ils font des rapports de bugs pour leurs logiciels libres preferes
- ils font des traductions
- ils font des dons
- ils donnent de l'argent pour le passage de Blender en logiciel libre
- ils creent des sites web pour promouvoir linux
- ils creent de la documentation
- ils militent pour la liberte et la non brevabilite des logiciels et du vivant
ect...
Moralite le communaute BeOS pleure derriere leur OS, les amigaistes aussi et idem pour les ataristes.
Je doute pas de ta bonne fois et ton envie d'aider le logiciel libre mais j'en ai marre de tes debats a 2balles (pourquoi j'y repond alors ;)
D'ailleurs ca ferait du bien a la communaute Linuxfr (et surtout sur hardware.fr OSA) si tu arretais tes posts debiles.
De la part d'une entreprise qui a 95% de part de marche et qui possede des ressources financieres inimaginables, heureusement qu'ils peuvent mettre un peu d'argent dans la R&D !
Si j'etais toi je ne venterais pas des quelques inventions de Microsoft vu les moyens financiers qu'ils possedent.
> ma inbox est coupe en 2 folder [...]
> j'aimerais repecher des mail du folder spam et les placer dans ham
Si j'ai bien compris tu veux simplement deplacer des emails d'un repertoire IMAP vers un autre repertoire de ton compre IMAP.
Ba je fais ca tous les jours avec un simple glisser/deposer sous Mozilla Mail et KMail. Avec gnus je ne sais pas comment faire.
Pour bogofilter (http://bogofilter.sourceforge.net/(...) j'ai jamais essaye), si tu as des false positif peut etre dois-tu modifier la configuration.
J'utilise SpamAssassin (http://spamassassin.org/(...) ) en configuration de base depuis 4 mois et apres 2000 spams recus j'ai jamais eu de false positif. Par contre j'ai deja eu quelques vrais negatifs parcequ'ils ne contenaient qu'une simple image (malin les spammeurs).
J'ai fait 6 mois de gtk 1.2 en C++ sous Linux et Windows il y a environ 1 an dans une boite a plein temps. Ba sous windows c'etait vraiment pas la joie, il y avait des differences de comportement importantes et puis comme la doc est inexistante. Tu es oblige de bidouiller pour que ca fonctionne de la meme facon sous Linux et Windows. Autant utiliser wxWindows.
Depuis ca a peut etre change, mais bon niveau programmation Qt est de toute facon loin devant gtk ahma et il n'est pas exclus d'avoir une version GPL de Qt sous windows d'ici quelques mois.
> un compilateur pour un nouveau langage en s'appuyant sur gcc.
C'est surtout ca je pense. Ils ne doivent pas tout reinventer puisque gcc est la base. gcc compile deja du C, C++, Objective-C, Fortran et ADA. Sachant que Java est tres proche de C++ et meme plus simple comme language (quoique avec l'introduction des templates dans Java), ils ont donc une base qui fonctionnent bien, maintenu, deja optimise... maintenant ils doivent refaire toutes les libs Java ce qui n'est pas une mince affaire (et d'ailleurs Mono ils sont pas pres d'y arriver vu le travail que ca demande).
D'ailleurs il me semble que gcj est bien plus populaire (et plus avance ?) que les autres JVM libre, non ?
Il me semble que l'un des principaux interets de compiler Java c'est que cela occupe moins de memoire et demarre plus vite car il n'y a pas de JVM a lancer qui bouffe plein de RAM.
gThumb 2.1.2 - gdk_pixbuf - http://gthumb.sourceforge.net/(...)
test.jpg - 8s
test.png - 23s
test.tif - 10s
nota: j'ai modifie les preferences pour que les images soient affichees a leurs tailles orginales comme la majorite des softs.
GImageView 0.2.23 - gdk_pixbuf ? - http://gtkmmviewer.sourceforge.net/(...)
test.jpg - 5s - 8s
test.png - 21s - 23s
test.tif - 24s - 24s
nota: la 1er fois l'image est redimmensionnee a la taille de la fenetre alors que la 2e fois j'ai configure le soft pour que l'image soit a la taille originale
GTK See 0.5.2 - directement libjpeg, libpng... ? - http://gtksee.berlios.de/(...)
impossible a faire fonctionner avec la commande: $time gtksee test.jpg
GLiv 1.7.1 - gdk_pixbuf/OpenGL - http://gliv.tuxfamily.org/(...)
test.jpg - 9s
test.png - 15s
test.tif - 10s
nota: je n'ai pas l'acceleration OpenGL (driver nv pour nvidia TNT2) et donc le zoom est lent ainsi que lorsque l'on bouge la fenetre
qiv 1.8 - Imlib1 - http://www.klografx.net/qiv/(...)
test.jpg - 5s
test.png - 12s
test.tif - 6s
nota: on retrouve les memes valeurs que pour KuickShow qui utilise egalement Imlib1. qiv est tres tres minimaliste.
XnView 1.50 - motif - http://www.xnview.com/(...)
test.jpg - 8s
test.png - 12s
test.tif - 5s
nota: soft proprietaire avec une jolie barre de progression, existe aussi pour windows
J'ai refait un test de GQview en supprimant le repertoire .gqview (il y a un repertoire thumbnails dedans) et cela confirme encore les resultats:
$ time gqview test.jpg
real 0m2.637s
$ time gqview test.png
real 0m2.629s
$ time gqview test.tif
real 0m6.777s
Pour moi c'est LE grand gagnant puisque meme apres avoir charger un png de 16Mo en 2s, on peux zoomer, bouger... instannement ! C'est encore plus rapide que ACDSee. En revanche j'ai des problemes (le pc swap a mort alors que j'ai 320Mo de RAM) avec un TIFF de 75Mo alors que Gwenview n'a pas "trop" de probleme.
Un dernier test de Gwenview parceque j'aime beaucoup l'interface et que le zoom/deplacement dans l'image est tres rapide:
1er lancement du logiciel depuis un reboot:
$ time gwenview test.jpg
real 0m10.570s
2e lancement (programme deja present en memoire):
$ time gwenview test.jpg
real 0m7.484s
$ time gwenview test.png
real 0m12.842s
$ time gwenview test.tif
real 0m7.509s
Les chiffres confirment bien les resultats que j'ai obtenu la 1er fois.
Pour eog les differences de resultats obtenues avec GQview m'ont suppris vu qu'ils utilisent tous les deux gdk-pixbuf. J'ai refait des tests et j'ai trouve des valeurs plus faibles (pour gthumb j'ai teste dans tous les sens, je comprend pas les resultats aussi mauvais):
eog
test.jpg - 6.686s (desactivation du zoom de meilleur qualite) - 7.151s (avec le zoom de mauvaise qualite) - (8s lors du 1er test)
test.png - 10.986s - 11.105s - 15s
test.tif - 4.968s - 5.629s - 8s
Personnelement je pense que GQview (gdk_pixbuf et le plus rapide de tres loin), gwenview (superbe interface sous KDE et la vitesse est correct) et eog (gdk_pixbuf en gtk2, viewer officiel de Gnome) sont interessants.
Les viewers bases sur Imlib1 ne sont pas interessants car Imlib1 n'est plus "maintenu". Pour Imlib2 l'avenir est plutot incertain vu E17 et le depart de Raster. Les viewers OpenGL sont probablement rapides avec l'acceleration mais malheureusement l'OpenGL accelere sous XFree est plutot chaotique (pas de driver, driver proprio...) et lorsque l'on voit la vitesse de GQview il y a moyen de faire suffisamment rapide sans OpenGL (si quelqu'un pouvait tester avec l'acceleration OpenGL). Ceci est mon avis et n'engage que moi.
Maintenant il faudrait pousser les tests sur les 3-4 meilleurs logiciels et en deduire l'occupation memoire, si le zoom/scroll est rapide ou pas, si la qualite du zoom est bien, puis ensuite etudier les fonctionnalites (convertion des images dans d'autres formats) et l'ergonomie.
> tu comptes entre le moment ou tu lances le soft et le moment ou l'image est affichée ?
Le moment ou je lance le soft. Mais comme je manipule beaucoup les logiciels en les lancant plusieurs fois, toutes les librairies sont chargees en memoire. Par exemple Gwenview s'ouvre instannement la 2e fois qu'on le lance, c'est le meme principe que le quickload de Mozilla sous Windows.
Par rapport au temps de chargement des images (c'est pourquoi j'ai pris des grosses images qui ne representent pas forcement la realite - qui peut le plus peut le moins) cela represente un temps minime.
De toute facon meme si la methode n'est pas parfaite je ne vois pas de meilleure methode a part le chrono mais c'est assez fastidieux et pas tres precis face a la commande time.
J'ai compte de tete donc c'est pas tres precis (j'ai fait aussi 2 fois le test).
Je le trouve peu moins rapide que ACDSee surtout que le scroll au niveau de l'image est tres lent une fois celle si charge contrairement a ACDSee. De plus le chargement des images n'est pas progressif: on a l'impression que le soft se bloque pendant quelques secondes.
Je ne discute que la vitesse des logiciels, pas les fonctionnalites - sinon The Gimp serait probablement gagnant ;)
Au passage je fais un test avec Mozilla en comptant de tete:
Mozilla charge les images progressivement (ca donne l'impression de vitesse et c'est tres bien: l'utilisateur fait une action et il a le debut du resultat instannement plutot que d'etre devant un ecran noir) mais j'ai attendu le chargement des images entierement. Finalement c'est pas si impressionant que je voulais bien le croire surtout que le scroll des images est assez lent ensuite.
Avec Mozilla Firebird les valeurs depassent largement 20s sur test.png car il redimensionne automatiquement a la taille de la fenetre.
> gqview (que je n'ai jamais vu planter dailleurs)
Essaye avec un repertoire contenant plusieurs images d'environ 50Mo si tu peux, je suis interesse de savoir si c'est mon installation ou pas. Gwenview m'a egalement claque dans les doigts avec le meme repertoire.
> avec tout ce qui est cache et tout, c'est pas tres precis tout ca...
Si je pense que c'est suffisamment precis, logiquement les softs ne mettent pas en cache une image passee en parametre depuis la console (je fais $time soft image puis je ferme le programme). D'ailleurs je n'ai pas trouve de grandes differences entre mon 1er et 2e test tout comme aucun repertoire .xvpics n'a ete cree. Le seul probleme est le temps que je met pour fermer le programme (j'ai tronque apres la virgule donc ca compense) + le temps de chargement des differentes libs en memoire la 1er fois mais comme j'ai beaucoup trifouille tous les programmes les libs etaient donc charges en memoire.
Sinon pour GQview j'ai fait plusieurs fois le test meme en deplacant l'image dans le cadre et les valeurs sont veridiques.
Il faut aussi relativiser les valeurs, certains viewers affichent les images dans la resolution d'origine alors que d'autre redimensionne l'image a la taille de la fenetre.
Egalement certains logiciels ont une interface complexe/complete a charger avec pleins de fonctions. Aussi les logiciels chargent les images en fonction de leurs besoins: The Gimp 1.2.5 est tres lent la 1er fois mais logiquement apres il n'y a plus de ralentissement lors des manipulations.
De toute facon ce qu'il faut en deduire c'est que gdk_pixbuf est tres bon et ca se sent ensuite lorsque l'on manipule les images avec eog (zoom instantane par exemple). En revanche Qt est vraiment execrable meme pire que Imlib1 (j'ai carrement fait un programme de 5 lignes pour confirmer les resultats de Kview). J'ai toujours entendu beaucoup de mal de Imlib1 (c'est probablement pas pour rien que GQview est passe de Imlib1 a gdk_pixbuf) et Imlib2 n'est pas beaucoup meilleur si l'acceleration OpenGL n'est pas active (ou alors feh n'utilise pas Imlib2 correctement).
Require: gtk+/gdk and Imlib
Donc c'est "deja" teste puisque KuickShow utilise Imlib1, il peut y avoir des differences certe mais ca va donner sensiblement la meme chose.
C'est difficile de tester tout les viewers de la terre. L'interet est de tester les librairies derrieres les softs.
ACDSee affiche progressivement les images, le logiciel ne se bloque pas completement lors du chargement. De plus il y a une barre de progression discrete en bas de l'image (le temps s'affiche dans cette barre de progression).
Le logiciel "triche" (et c'est tres bien) car il pre-charge les images suivantes du repertoire lorsque l'on visionne une image.
Les nouvelles versions de ACDSee sont probablement plus rapides.
Bref GQview est tres rapide et Gwenview a une ergonomie parfaite. Je pense que ACDSee est encore devant. Qt est tout de meme tres lent pour manipuler les images, gdk_pixbuf est bien plus rapide.
Finalement la situation sous GNU/Linux est pas si desespere comme je voulais bien le croire mais Konqueror pour les images est vraiment vraiment trop lent.
Avec Mozilla 1.4 sous windows 2000 et Mozilla Firebird (moins car l'image est mise a l'echelle de la fenetre), l'affichage de test.jpg et test.png est tres rapide avec un affichage progressif, je suis impressionne !
nota: l'image test.tif est directement issue du scanner donc non compresse.
Pour moi eog et GQview se debrouillent le mieux, mais lorsque l'on utilise GQview dans un repertoire avec plusieurs grosses images (50Mo) ca a plante plusieurs fois. Konqueror avec test.jpg (5Mo) rame incroyablement. The Gimp est lent mais ce n'est pas le meme type de logiciel. J'aime beaucoup Gwenview, aussi rapide que ACDSee avec un affichage progressif et cela serait parfait.
J'ai ete tres decu par feh (Imlib2) qui est pas vraiment rapide contrairement a la pub: If it does it it likely does it faster than any other library you can find (this includes gdk-pixbuf, gdkrgb, etc.) Evidemment je n'ai pas l'OpenGL accelere avec le driver nv de ma TNT2.
Je me souviens que GQview etait en Imlib1 il y a quelques temps.
J'ai essaye Compupic et c'est pas top contrairement a ce que je pensais, l'unique avantage de ce soft est qu'il affiche les images progressivement plutot que de se bloquer jusqu'a la fin de l'affichage comme les autres softs.
Je reboot sous windows et je fais les tests avec ACDSee32 2.42 (une veille version qui date de 1998).
Procedure de test:
Je lance le soft avec en parametre l'image et la commande time. Des que l'image s'affiche je fais un ctrcl-c dans la console. J'ai fait les tests 2 fois.
# Re: Jabber : du protocole ouvert à l'entreprise commerciale
Posté par tanguy_k (site web personnel) . En réponse au journal Jabber : du protocole ouvert à l'entreprise commerciale. Évalué à 2.
bof. Jabber est tres bien en theorie, en pratique c'est la galere.
Je suis sur jabber.org et ca plante regulierement. Pour les autres protocoles je suis sur charente.de et ca fonctionne pas au moins 1 fois par semaine !
Je n'ai pas encore trouve de serveur jabber efficace qui plante pas et qui supporte les autres protocoles. Il y a peut etre un serveur wpoeirlw.qrdwoijulw.sz qui fonctionne correctement mais comment etre sur de la perenite de ce genre de serveur ?
Bref ce qu'il faut a jabber c'est un serveur public officiel avec un nom approprie (jabber.com, jabber.org ou jabber.net) qui supporte le multi-protocoles et qui ne plante pas. Sinon c'est du vent.
J'utilise donc jabber mais je ne le recommande jamais autour de moi de peur de donner une mauvaise image a jabber et au logiciels libres (je recommande en revanche miranda et gaim).
# Re: ADSL: Tele2 vs Free
Posté par tanguy_k (site web personnel) . En réponse au journal ADSL: Tele2 vs Free. Évalué à 1.
Regarde par toi meme sur ce forum en faisant une recherche:
http://forum.hardware.fr/forum1.php3?cat=4&config=&interfac(...)
Je ne sais pas si c'est mieux avec Tele2, mais Free est surement l'un des pires FAI ADSL en ce moment !
Bref je me contente de mon ADSL chez France Telecom/Wanadoo qui coute plus cher mais qui marche nikel 24h/24 depuis 2 ans.
[^] # Re: Siemens étudie Linux pour la bureautique
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Siemens étudie Linux pour la bureautique. Évalué à 3.
Ca c'est ta traduction pour la fin de son post.
Maintenant j'aimerais bien connaitre ta traduction pour le debut du post, a savoir:
J'aimerai qu'on m'explique en quoi kde est plus proche de windows que gnome ? [...]
je trouve gnome tout aussi proche de windows que kde
[^] # Re: quelle approche ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mesure du bénéfice de l'approche Gentoo. Évalué à 1.
> possible de compiler soi-même des paquets.
Tu n'as pas compris ce que je voulais dire, je me suis probablement mal exprime. Ce n'est pas un probleme de possibilite de recompiler un package mais un probleme de distribution de logiciels sous brevets.
XviD n'est pas dans la Debian de base ni dans les autres distribs, il faut telecharger des packages non officiels et probablement hors la loi. SuSE a modifie le logiciel MPlayer a cause des problemes de brevets.
RedHat a supprime le support MP3 de XMMS pour les meme raisons.
Mais imagine que RedHat propose en lieu et place du package binaire de XMMS, un package contenant que le code source. Etant donner que (si j'ai tout bien compris) les brevets logiciels n'implique que le binaire et pas le code source d'un logiciel, RedHat pourrait donc distribuer le code source de XMMS avec le support du MP3. Ensuite une jolie fenetre qui propose l'utilisateur de compiler XMMS et automagiquement l'utilisateur peut beneficier du *vrai* XMMS mais aussi de MPlayer, de XviD ect...
[^] # Re: quelle approche ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mesure du bénéfice de l'approche Gentoo. Évalué à 5.
Je vois un autre intérêt des distros sources, les brevets logiciels !
Un projet comme XviD http://xvid.org/(...) ne peut pas redistribuer de binaire puisqu'il y a des brevets sur le MPEG-4.
J'imagine qu'une distrib qui fournirait les sources de XviD ne serait pas inquiété par les brevets.
Cela permettrait aussi d'activer certaines options dans des softs, de distribuer des softs ou il y a des problemes de licences cf MPlayer et Debian...
Egalement de proposer a la carte les softs qui posent problemes que dans certains pays (puisque l'on precise a l'install dans quel pays ont est et donc pas besoin de faire un cd NON-US par exemple).
Ceci dit j'ai peut etre tord parceque personne n'evoque cet atout des distribs sources.
[^] # Re: Les utilisateurs Linux ne supportent ils pas leur OS favori ?
Posté par tanguy_k (site web personnel) . En réponse au journal Les utilisateurs Linux ne supportent ils pas leur OS favori ?. Évalué à 1.
- difficulte d'installation
- que pour i386
- bugs
ect...
Je vois pas en quoi c'est drole, je trouve meme ca plutot triste.
> J'ai envie de t'insulter aussi
ba vas-y te gene pas, t'es la pour ca
# Re: Les utilisateurs Linux ne supportent ils pas leur OS favori ?
Posté par tanguy_k (site web personnel) . En réponse au journal Les utilisateurs Linux ne supportent ils pas leur OS favori ?. Évalué à 5.
- se procurer les jeux Loki etaient plus difficiles que les versions windows dispo a la fnac
- difference de prix: souvent on trouvait la version windows a bas prix contrairement a la version Loki
- beaucoup de linuxiens ont un dual boot avec windows d'installe
- les drivers acceleres sous Linux ont des problemes (incompatibilite, pas libre, moins rapide...)
- retard de disponibilite de la version Loki
- il pouvait y avoir des bugs
- parceque les jeux portes etaient pas toujours super
- parceque la majorite des linuxiens sont des etudiants sans un sous
Les linuxiens supportent leur plateforme mais pas de la meme maniere que les communautes BeOS, MacOS, Amiga...
- ils font des rapports de bugs pour leurs logiciels libres preferes
- ils font des traductions
- ils font des dons
- ils donnent de l'argent pour le passage de Blender en logiciel libre
- ils creent des sites web pour promouvoir linux
- ils creent de la documentation
- ils militent pour la liberte et la non brevabilite des logiciels et du vivant
ect...
Moralite le communaute BeOS pleure derriere leur OS, les amigaistes aussi et idem pour les ataristes.
Je doute pas de ta bonne fois et ton envie d'aider le logiciel libre mais j'en ai marre de tes debats a 2balles (pourquoi j'y repond alors ;)
D'ailleurs ca ferait du bien a la communaute Linuxfr (et surtout sur hardware.fr OSA) si tu arretais tes posts debiles.
[^] # Re: Rodidjiu d'crénom
Posté par tanguy_k (site web personnel) . En réponse au journal Rodidjiu d'crénom. Évalué à 2.
De la part d'une entreprise qui a 95% de part de marche et qui possede des ressources financieres inimaginables, heureusement qu'ils peuvent mettre un peu d'argent dans la R&D !
Si j'etais toi je ne venterais pas des quelques inventions de Microsoft vu les moyens financiers qu'ils possedent.
# Re: gnus & imap & move messages
Posté par tanguy_k (site web personnel) . En réponse au journal gnus & imap & move messages. Évalué à 1.
> j'aimerais repecher des mail du folder spam et les placer dans ham
Si j'ai bien compris tu veux simplement deplacer des emails d'un repertoire IMAP vers un autre repertoire de ton compre IMAP.
Ba je fais ca tous les jours avec un simple glisser/deposer sous Mozilla Mail et KMail. Avec gnus je ne sais pas comment faire.
Pour bogofilter (http://bogofilter.sourceforge.net/(...) j'ai jamais essaye), si tu as des false positif peut etre dois-tu modifier la configuration.
J'utilise SpamAssassin (http://spamassassin.org/(...) ) en configuration de base depuis 4 mois et apres 2000 spams recus j'ai jamais eu de false positif. Par contre j'ai deja eu quelques vrais negatifs parcequ'ils ne contenaient qu'une simple image (malin les spammeurs).
[^] # Re: Rodidjiu d'crénom
Posté par tanguy_k (site web personnel) . En réponse au journal Rodidjiu d'crénom. Évalué à 2.
> franchement, vous leur feriez confiance ? ;)
T'as deja vu la gueule de certain developpeurs de logiciels libres ?
personnelement je crois que c'est bien pire que cette photo
# Re: Rodidjiu d'crénom
Posté par tanguy_k (site web personnel) . En réponse au journal Rodidjiu d'crénom. Évalué à 1.
> "sans microsoft, l'informatique grand public ne serait pas ce qu'elle est aujourd'hui"
http://www.apple.com/(...)
http://www.osnews.com/printer.php?news_id=4042(...)
http://www.wikipedia.org/wiki/Amiga(...)
http://histoire.info.online.fr/gui.html(...)
http://www.tt-hardware.com/article.php?sid=4320(...)
http://members.fortunecity.com/pcmuseum/next.htm(...)
http://members.fortunecity.com/pcmuseum/os2.htm(...)
http://members.fortunecity.com/pcmuseum/amigawb.htm(...)
http://apple2history.org/history/appy/ahc.html(...)
J'arrive plus a mettre la main sur un site web qui presentait des captures d'ecrans de windows, amiga, next...
[^] # Re: Ruby 1.8.0 est sorti
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Ruby 1.8.0 est sorti. Évalué à 2.
J'ai fait 6 mois de gtk 1.2 en C++ sous Linux et Windows il y a environ 1 an dans une boite a plein temps. Ba sous windows c'etait vraiment pas la joie, il y avait des differences de comportement importantes et puis comme la doc est inexistante. Tu es oblige de bidouiller pour que ca fonctionne de la meme facon sous Linux et Windows. Autant utiliser wxWindows.
Depuis ca a peut etre change, mais bon niveau programmation Qt est de toute facon loin devant gtk ahma et il n'est pas exclus d'avoir une version GPL de Qt sous windows d'ici quelques mois.
[^] # Re: Ruby 1.8.0 est sorti
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Ruby 1.8.0 est sorti. Évalué à 1.
Qt est dispo sous licence GPL pour Unix et MacOS X de facon stable.
Reste plus que wxWindows qui est vraiment portable partout (Unix, MacOS X et Windows) sous licence LGPL.
[^] # Re: hum
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 1.
C'est surtout ca je pense. Ils ne doivent pas tout reinventer puisque gcc est la base. gcc compile deja du C, C++, Objective-C, Fortran et ADA. Sachant que Java est tres proche de C++ et meme plus simple comme language (quoique avec l'introduction des templates dans Java), ils ont donc une base qui fonctionnent bien, maintenu, deja optimise... maintenant ils doivent refaire toutes les libs Java ce qui n'est pas une mince affaire (et d'ailleurs Mono ils sont pas pres d'y arriver vu le travail que ca demande).
D'ailleurs il me semble que gcj est bien plus populaire (et plus avance ?) que les autres JVM libre, non ?
[^] # Re: hum
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 3.
[^] # Re: hum
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 1.
# Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 3.
test.jpg - 8s
test.png - 23s
test.tif - 10s
nota: j'ai modifie les preferences pour que les images soient affichees a leurs tailles orginales comme la majorite des softs.
GImageView 0.2.23 - gdk_pixbuf ? - http://gtkmmviewer.sourceforge.net/(...)
test.jpg - 5s - 8s
test.png - 21s - 23s
test.tif - 24s - 24s
nota: la 1er fois l'image est redimmensionnee a la taille de la fenetre alors que la 2e fois j'ai configure le soft pour que l'image soit a la taille originale
GTK See 0.5.2 - directement libjpeg, libpng... ? - http://gtksee.berlios.de/(...)
impossible a faire fonctionner avec la commande: $time gtksee test.jpg
GLiv 1.7.1 - gdk_pixbuf/OpenGL - http://gliv.tuxfamily.org/(...)
test.jpg - 9s
test.png - 15s
test.tif - 10s
nota: je n'ai pas l'acceleration OpenGL (driver nv pour nvidia TNT2) et donc le zoom est lent ainsi que lorsque l'on bouge la fenetre
qiv 1.8 - Imlib1 - http://www.klografx.net/qiv/(...)
test.jpg - 5s
test.png - 12s
test.tif - 6s
nota: on retrouve les memes valeurs que pour KuickShow qui utilise egalement Imlib1. qiv est tres tres minimaliste.
XnView 1.50 - motif - http://www.xnview.com/(...)
test.jpg - 8s
test.png - 12s
test.tif - 5s
nota: soft proprietaire avec une jolie barre de progression, existe aussi pour windows
J'ai refait un test de GQview en supprimant le repertoire .gqview (il y a un repertoire thumbnails dedans) et cela confirme encore les resultats:
$ time gqview test.jpg
real 0m2.637s
$ time gqview test.png
real 0m2.629s
$ time gqview test.tif
real 0m6.777s
Pour moi c'est LE grand gagnant puisque meme apres avoir charger un png de 16Mo en 2s, on peux zoomer, bouger... instannement ! C'est encore plus rapide que ACDSee. En revanche j'ai des problemes (le pc swap a mort alors que j'ai 320Mo de RAM) avec un TIFF de 75Mo alors que Gwenview n'a pas "trop" de probleme.
Un dernier test de Gwenview parceque j'aime beaucoup l'interface et que le zoom/deplacement dans l'image est tres rapide:
1er lancement du logiciel depuis un reboot:
$ time gwenview test.jpg
real 0m10.570s
2e lancement (programme deja present en memoire):
$ time gwenview test.jpg
real 0m7.484s
$ time gwenview test.png
real 0m12.842s
$ time gwenview test.tif
real 0m7.509s
Les chiffres confirment bien les resultats que j'ai obtenu la 1er fois.
Pour eog les differences de resultats obtenues avec GQview m'ont suppris vu qu'ils utilisent tous les deux gdk-pixbuf. J'ai refait des tests et j'ai trouve des valeurs plus faibles (pour gthumb j'ai teste dans tous les sens, je comprend pas les resultats aussi mauvais):
eog
test.jpg - 6.686s (desactivation du zoom de meilleur qualite) - 7.151s (avec le zoom de mauvaise qualite) - (8s lors du 1er test)
test.png - 10.986s - 11.105s - 15s
test.tif - 4.968s - 5.629s - 8s
Personnelement je pense que GQview (gdk_pixbuf et le plus rapide de tres loin), gwenview (superbe interface sous KDE et la vitesse est correct) et eog (gdk_pixbuf en gtk2, viewer officiel de Gnome) sont interessants.
Les viewers bases sur Imlib1 ne sont pas interessants car Imlib1 n'est plus "maintenu". Pour Imlib2 l'avenir est plutot incertain vu E17 et le depart de Raster. Les viewers OpenGL sont probablement rapides avec l'acceleration mais malheureusement l'OpenGL accelere sous XFree est plutot chaotique (pas de driver, driver proprio...) et lorsque l'on voit la vitesse de GQview il y a moyen de faire suffisamment rapide sans OpenGL (si quelqu'un pouvait tester avec l'acceleration OpenGL). Ceci est mon avis et n'engage que moi.
Maintenant il faudrait pousser les tests sur les 3-4 meilleurs logiciels et en deduire l'occupation memoire, si le zoom/scroll est rapide ou pas, si la qualite du zoom est bien, puis ensuite etudier les fonctionnalites (convertion des images dans d'autres formats) et l'ergonomie.
[^] # Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 2.
Le moment ou je lance le soft. Mais comme je manipule beaucoup les logiciels en les lancant plusieurs fois, toutes les librairies sont chargees en memoire. Par exemple Gwenview s'ouvre instannement la 2e fois qu'on le lance, c'est le meme principe que le quickload de Mozilla sous Windows.
Par rapport au temps de chargement des images (c'est pourquoi j'ai pris des grosses images qui ne representent pas forcement la realite - qui peut le plus peut le moins) cela represente un temps minime.
De toute facon meme si la methode n'est pas parfaite je ne vois pas de meilleure methode a part le chrono mais c'est assez fastidieux et pas tres precis face a la commande time.
[^] # Re: KDE 3.1.3
Posté par tanguy_k (site web personnel) . En réponse à la dépêche KDE 3.1.3. Évalué à 1.
un grand merci alors ;)
J'ai continue la discussion dans un journal parceque je pense que ca doit interesser quelques personnes.
http://linuxfr.org/~tanguy_k/4436.html(...)
[^] # Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 3.
test.jpg - 6s
test.png - 10s
test.tif - 5s
J'ai compte de tete donc c'est pas tres precis (j'ai fait aussi 2 fois le test).
Je le trouve peu moins rapide que ACDSee surtout que le scroll au niveau de l'image est tres lent une fois celle si charge contrairement a ACDSee. De plus le chargement des images n'est pas progressif: on a l'impression que le soft se bloque pendant quelques secondes.
Je ne discute que la vitesse des logiciels, pas les fonctionnalites - sinon The Gimp serait probablement gagnant ;)
Au passage je fais un test avec Mozilla en comptant de tete:
Mozilla 1.4 - windows 2000 - http://www.mozilla.org/(...)
test.jpg - 8s
test.png - 14s
test.tif - non gere
Mozilla charge les images progressivement (ca donne l'impression de vitesse et c'est tres bien: l'utilisateur fait une action et il a le debut du resultat instannement plutot que d'etre devant un ecran noir) mais j'ai attendu le chargement des images entierement. Finalement c'est pas si impressionant que je voulais bien le croire surtout que le scroll des images est assez lent ensuite.
Avec Mozilla Firebird les valeurs depassent largement 20s sur test.png car il redimensionne automatiquement a la taille de la fenetre.
Pour tester ACDSee 2.43 il faut telecharger ACDSee classic: http://download.com.com/3000-20-1808446.html?legacy=cnet(...)
cette version est introuvable sur le site web officiel.
nota: j'ai d'abord lance les softs puis ouvert les images avec contrairement aux tests sous linux.
[^] # Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 2.
Essaye avec un repertoire contenant plusieurs images d'environ 50Mo si tu peux, je suis interesse de savoir si c'est mon installation ou pas. Gwenview m'a egalement claque dans les doigts avec le meme repertoire.
> avec tout ce qui est cache et tout, c'est pas tres precis tout ca...
Si je pense que c'est suffisamment precis, logiquement les softs ne mettent pas en cache une image passee en parametre depuis la console (je fais $time soft image puis je ferme le programme). D'ailleurs je n'ai pas trouve de grandes differences entre mon 1er et 2e test tout comme aucun repertoire .xvpics n'a ete cree. Le seul probleme est le temps que je met pour fermer le programme (j'ai tronque apres la virgule donc ca compense) + le temps de chargement des differentes libs en memoire la 1er fois mais comme j'ai beaucoup trifouille tous les programmes les libs etaient donc charges en memoire.
Sinon pour GQview j'ai fait plusieurs fois le test meme en deplacant l'image dans le cadre et les valeurs sont veridiques.
Il faut aussi relativiser les valeurs, certains viewers affichent les images dans la resolution d'origine alors que d'autre redimensionne l'image a la taille de la fenetre.
Egalement certains logiciels ont une interface complexe/complete a charger avec pleins de fonctions. Aussi les logiciels chargent les images en fonction de leurs besoins: The Gimp 1.2.5 est tres lent la 1er fois mais logiquement apres il n'y a plus de ralentissement lors des manipulations.
De toute facon ce qu'il faut en deduire c'est que gdk_pixbuf est tres bon et ca se sent ensuite lorsque l'on manipule les images avec eog (zoom instantane par exemple). En revanche Qt est vraiment execrable meme pire que Imlib1 (j'ai carrement fait un programme de 5 lignes pour confirmer les resultats de Kview). J'ai toujours entendu beaucoup de mal de Imlib1 (c'est probablement pas pour rien que GQview est passe de Imlib1 a gdk_pixbuf) et Imlib2 n'est pas beaucoup meilleur si l'acceleration OpenGL n'est pas active (ou alors feh n'utilise pas Imlib2 correctement).
[^] # Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 1.
ca utilise gdk_pixbuf, j'ai teste eog et GQview qui utilisent gdk_pixbuf donc...
[^] # Re: Test visionneurs d'images sous GNU/Linux
Posté par tanguy_k (site web personnel) . En réponse au journal Test visionneurs d'images sous GNU/Linux. Évalué à 1.
Donc c'est "deja" teste puisque KuickShow utilise Imlib1, il peut y avoir des differences certe mais ca va donner sensiblement la meme chose.
C'est difficile de tester tout les viewers de la terre. L'interet est de tester les librairies derrieres les softs.
[^] # Re: KDE 3.1.3
Posté par tanguy_k (site web personnel) . En réponse à la dépêche KDE 3.1.3. Évalué à 3.
test.jpg - 4s
test.png - 9s
test.tif - 3s
ACDSee affiche progressivement les images, le logiciel ne se bloque pas completement lors du chargement. De plus il y a une barre de progression discrete en bas de l'image (le temps s'affiche dans cette barre de progression).
Le logiciel "triche" (et c'est tres bien) car il pre-charge les images suivantes du repertoire lorsque l'on visionne une image.
Les nouvelles versions de ACDSee sont probablement plus rapides.
Bref GQview est tres rapide et Gwenview a une ergonomie parfaite. Je pense que ACDSee est encore devant. Qt est tout de meme tres lent pour manipuler les images, gdk_pixbuf est bien plus rapide.
Finalement la situation sous GNU/Linux est pas si desespere comme je voulais bien le croire mais Konqueror pour les images est vraiment vraiment trop lent.
Avec Mozilla 1.4 sous windows 2000 et Mozilla Firebird (moins car l'image est mise a l'echelle de la fenetre), l'affichage de test.jpg et test.png est tres rapide avec un affichage progressif, je suis impressionne !
nota: l'image test.tif est directement issue du scanner donc non compresse.
[^] # Re: KDE 3.1.3
Posté par tanguy_k (site web personnel) . En réponse à la dépêche KDE 3.1.3. Évalué à 3.
test.jpg - 5Mo compression 5%
test.png - 16Mo compression 6
test.tif - 56Mo 3021x4866pixels 32bpp
QPixmap (5 lignes de code avec QPixmap) - Qt
test.jpg - 10s
test.png - 14s
test.tif - pas gere
Kview 3.0 - Qt
test.jpg 12s
test.png - 17s
test.tif - 11s
GQview 1.2.2 - gdk_pixbuf 0.22 - http://gqview.sourceforge.net/(...)
test.jpg - 2s
test.png - 2s
test.tif - 8s
Gwenview 0.17.0pre3 - Qt - http://gwenview.sourceforge.net(...)
test.jpg - 10s
test.png - 13s
test.tif - 8s
eog 2.2 - gdk_pixbuf 0.22 - http://www.gnome.org/gnome-office/eog.shtml(...)
test.jpg - 8s
test.png - 15s
test.tif - 8s
PixiePlus 0.5.4 - Qt - http://mosfet.org/pixie/(...)
test.jpg - 13s
test.png - 18s
test.tif - 13s
KuickShow 0.8.5 - Imlib1 - http://kuickshow.sourceforge.net/(...)
test.jpg - 6s
test.png - 12s
test.tif - 6s
feh 1.2.6 - Imlib2
test.jpg - 5s
test.png - 11s
test.tif - 5s
Pour moi eog et GQview se debrouillent le mieux, mais lorsque l'on utilise GQview dans un repertoire avec plusieurs grosses images (50Mo) ca a plante plusieurs fois. Konqueror avec test.jpg (5Mo) rame incroyablement. The Gimp est lent mais ce n'est pas le meme type de logiciel. J'aime beaucoup Gwenview, aussi rapide que ACDSee avec un affichage progressif et cela serait parfait.
J'ai ete tres decu par feh (Imlib2) qui est pas vraiment rapide contrairement a la pub: If it does it it likely does it faster than any other library you can find (this includes gdk-pixbuf, gdkrgb, etc.) Evidemment je n'ai pas l'OpenGL accelere avec le driver nv de ma TNT2.
Je me souviens que GQview etait en Imlib1 il y a quelques temps.
J'ai essaye Compupic et c'est pas top contrairement a ce que je pensais, l'unique avantage de ce soft est qu'il affiche les images progressivement plutot que de se bloquer jusqu'a la fin de l'affichage comme les autres softs.
Je reboot sous windows et je fais les tests avec ACDSee32 2.42 (une veille version qui date de 1998).
Procedure de test:
Je lance le soft avec en parametre l'image et la commande time. Des que l'image s'affiche je fais un ctrcl-c dans la console. J'ai fait les tests 2 fois.