ndesmoul a écrit 363 commentaires

Si tu n'as pas de risque que ton Stringbuffer soit modifié de manière concurrente par deux threads, mieux vaut utiliser un StringBuilder qui est la même chose qu'un StringBuffer mais en non synchronisé et donc un peu plus rapide.

Oui je suis assez d'accord. Sauf que Java c'est tout de même plus rapide que Perl ou Python qui sont purement interprétés.

Bah disons que la vitesse de SWT est (était?) meilleure sous Windows que sous Linux. Pour ce qui est de Swing (le toolkit graphique standard de Java) les perfs ont été pas mal améliorées dernièrement.

Je suis pas certain que cela soit lié au Garbage collector sauf ponctuellement. Par contre les optimisation de la JVM peuvent jouer au début. Par exemple la première fois que tu cliques sur un menu il met une seconde à s'afficher alors que c'est instantané ensuite.

Pour faire rapidement une GUI en Swing, jette un coup d'oeil du côté de Netbean qui propose maintenant une système de création d'interface qui semble assez bien foutu (mais je ne l'ai pas testé de manière appronfondie).

Le gros problème de Java c'est qu'il bouffe pas mal de mémoire vive... Si tu est un peu juste ça peut ramer effectivement.

Le ressenti lourdeur peut venir aussi de l'interface graphique. Azureus et Eclipse utilise SWT et sont plutôt moins réactifs (en tout cas Eclipse) sous Linux que sous Windows, encore que la différence tend à diminuer mais c'est très subjectif.
D'ailleurs curieusement les dernières versions de Netbeans semblent plutôt plus réactives qu'Eclipse.

Sinon il sera sans doute possible de faire des choses intéressantes avec QT:
http://www.trolltech.com/developer/downloads/qt/qtjambi-tech(...)

Je suis d'accord sur l'utilisation "typique" (à part que ces petits bouts de code sont trop petits pour être vraiment typiques).

C'est juste que ce test donne l'impression que Java est intrinséquement lent pour ce genre de calculs alors qu'en fait il s'en sort plutôt bien. D'autre part BigInteger est intégré au JDK et donc le choix logique, alors que GMP n'est pas une lib "standard" du C (même si c'est le choix sans doute le plus judicieux).

Elle est bonne celle là!

Parceque GMP est la seule bibliothèque disponible en C? Au cas ou tu aurais un doute, ce n'est pas le cas, même si c'est sans doute une des plus performante maintenant. Zut alors encore des gens qui ont réinventé la roue!

Ce test est sensé comparer les perf de 2 langages. Ici on a l'impression que Java est très lent pour ce genre de calculs alors que ce sont les optimisations en assembleur qui boostent les perfs du programme en C. Si on refaisait le test avec un lib écrite exclusivement en C on aurait des résultats beaucoup plus proches entre les deux langages.

Il est tout à fait possible de faire appel à GMP depuis un programme Java. Avec Swig c'est même relativement facile.
Mais est-ce que la comparaison aurait toujours un sens?

Je ne sais pas pour ces petits bouts de code mais ce n'est pas ce que j'ai constaté en pratique. Comme je l'ai dit j'ai déjà traduit du code de C vers java et les performances étaient très proches entre les 2. Genre 48 ms pour la version C, 50 ms pour Java. Par contre le premier passage était clairement plus long (qqch comme 300ms, me souviens plus exactement).

D'autre part tous les langages ne semblent pas logés à le même enseigne.
Par exemple, vu la grosse différence entre C et Java pour le test pidigits j'ai regardé le code C. Je sais pas ce que c'est sensé faire mais c'est visisiblement des calculs sur de grands entiers. Sauf que le programme C utilise la bibliothèque GMP, codé en C certes, mais avec des optimisations en ASSEMBLEUR.

Pour avoir déjà testé GMP je peux t'assurer que ces optimisations en assembleur c'est pas que de la frime! (tu gagnes facilement un facteur 5 voir plus sur certains calculs). D'ailleurs pour ceux que ça intéresse la lib OpenSSL a également de telles optimisations (très efficaces pour le calcul d'exponentielles modulaires).
Dans la version Java on utilise la classe BigInteger qui est du java à 100% (oui j'ai vérifié).

Euh... y a comme qui dirait triche là! Et association de malfaiteur en plus puisque la version D est complice!

A prendre avec des pincette oui. Surtout que si on regarde comment sont lancés les programmes java, il semble que ces bench ne laissent pas le temps à la JVM de faire toutes ces optimisations. Ils sont lancés avec en version -server qui est celle qui optimise le mieux mais qui également démarre le plus lentement et met le plus de temps à optimiser le code.

Si une fonction n'est lancée qu'une fois il y a peu de chance pour que la JVM ai eu le temps de l'optimiser au mieux.

Pour ma part j'ai transcrit dernièrement du code C vers du Java (en l'occurence un algo de code correcteur d'erreur) et les performances sont plus qu'honorables. La première fois que la méthode est exécutée ça peut être dix fois plus lent, mais une fois optimisée par la JVM j'ai constaté une dégradation des perfs inférieure à 10%.

Je ne te comprend pas. Tu sors des exemples qui justement soulignes les plus de Java à ce niveau.

Je te signale qu'il vaut mieux que ton programme te retourne un null pointer exception plutôt qu'il fasse n'importe quoi et qu'il accède à un espace mémoire où il n'est pas sensé aller. En C si tu as de la chance tu as un coredump. Mais parfois ça passe avec des conséquences difficilement prévisibles.
Si tu as une telle exception c'est que le programme est buggé mais il va pas foutre le bordel ailleurs.
De même que dès qu'il y a un dépassement de tableau un programme Java va te sortir une exception (ou te donnant même la ligne de code incriminée ce qui est bien pratique...). En C parfois ça passe et d'autres fois non. Quel est le plus sûr ici à ton avis?

Enfin quel est le problème avec les cast? En C il n'y a pas de vérification. En Java si et tu ne peux pas faire n'importe quoi. Encore une fois Java qui est un langage à typage fort est bien plus sûr à ce niveau.

Courant 2007, TOUT le Java de SUN sera sous GPL. La JVM (et compilateur?) sont déjà sortis. Devraient suivre bientôt toutes les bibliothèques standards (modulo d'éventuels bouts de code sur lesquels SUN n'auraient pas les droits).

D'autre part le projet Harmony continue et est parait-il bien avancé.

Pfff. Pas de bol, je venais juste de compiler (hier) la RC2 !

Me reste plus qu'à recommencer (en même temps ça devrait être plus simple maintenant vu que j'ai installé tous les paquets nécessaires)...

J'espère qu'ils ont corrigé le problème que j'ai rencontré euh... bah oui hier!

J'ai configuré le logiciel pour qu'il stocke les tags dans les images. Ca semble fonctionner mais assigner un tag à une sélection d'images ne fonctionne pas à partir du panneau droit: seule la première image est affectée. Par contre ça fonctionne via un clic droit, assigner tag... C'est un peu long d'ailleurs si on a sélectionner beaucoup d'images.

Si j'ai bien compris ca stocke les tags au format IPTC en conservant l'arborescence (avec des '/') des tags définis dans Digikam (personne/famille/bidule).

Sinon quelqu'un sait comment faire pour que le logiciel aille écrire automatiquement dans les images les tags assignés depuis une version précédente?

Bah, le x264 cest un très bon codec video (considéré comme le meilleur actuellement) mais c'est aussi le plus gourmand. Pour peu que la résolution de la vidéo soit importante, tu peux facilement mettre à genoux une machine moyennement puissante.

Y a aussi le fait que le décodeur H264 n'est peut-être pas encore parfait: sous mplayer j'ai parfois des saccades avec des vidéos h264 mais elles sont souvent dues à une erreur de décodage si j'en crois les messages d'erreurs affichés par mplayer.

Rien à voir avec le Matroska qui comme précisé avant n'est qu'un conteneur. Pour t'en convaincre tu n'as qu'à récupérer le flux video et un des flux audio et le mettre dans un avi.

Je ne suis pas vraiment convaincus par tes arguments concernants une session SSL. Autoriser qu'une clé secrète se retrouve en RAM serait tellement stupide que je vois mal les constructeurs commettre une telle bourde.

Mais de toute façon je ne suis guère convaincu par les TPM en eux même, sauf éventuellement pour authentifier une machine. Si on se place au niveau de l'utilisateur un objet personnel comme une carte à puce (ou un dongle) est beaucoup plus appropriée. (Et certaines cartes à puce savent faire du SSL de manière adéquate).

Le problème est qu'une puce TPM n'est pas équipée ni conçue pour négocier une session SSL, et que de ce fait, même si elle peut être utilisée pour faire des opérations de cryptage intervenant dans le SSL, elle n'est pas capable de gérer tout le protocole.

Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?

Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.

Alors là je ne vois pas du tout pourquoi.

En SSL, soit le client n'a pas de certificat et seul le serveur en a un, soit les deux parties possèdent un certificat et il faut en plus protéger la clé privée du client associée à son certificat (qui lui est bien évidemment publique). Mais la puce est sensée savoir le faire.

Dans les deux cas SSL permet de se mettre d'accord sur une clé de session qu'on aimerait bien protéger (puis jeter). J'ignore comment, dans les faits, une puce TPM gère ça, mais je ne vois pas de raison forçant à avoir la clé générée en RAM. Tout ce qu'on a à fournir à la puce c'est le certificat et l'aléa envoyé par le serveur. La puce peut sans doute même se charger de générer l'aléa du client à destination du serveur.

Pour moi la clé ne se retrouve donc jamais en clair en RAM. Si c'est le cas j'aimerai que tu m'expliques plus précisemment comment.

Par contre les données à chiffrer le sont forcément à un moment ou un autre: si on a accès à la RAM pourquoi se fatiguer à aller chercher une clé de chiffrement alors qu'il suffit de lire les données en clair?

Je ne voit pas pourquoi la puce TPL serait limitée au TCPA. Normalement l'utilisateur peut décider de générer ses propres clés conservées dans la puce TPM qui joue le rôle de coffre fort. Après un logiciel de messagerie peut très bien s'interfacer avec la puce comme il le ferait avec un banal carte à puce.

D'autre part une clé est dédiée à un algo donné. Par exemple une clé RSA est faite pour l'algo RSA pas pour du DSA. Normalement il faut même spécifier si la clé est prévue pour faire du chiffrement ou de la signature.
Si tu veux utiliser un algo exotique inconnu de la puce TPM, cela signifie juste que tu ne pourras pas stocker la clé correspondante sur la puce et que se sera au logiciel de faire tout le boulot. En gros si la clé que tu veux utiliser est dans la puce, elle fait le boulot, sinon c'est ton application.

Pour moi une puce TPM n'a d'intérêt que côté client et n'a pas pour but d'accélerer les calculs cryptos. Pour cela il existe d'autres solutions comme celles que tu cites, dédiées aux serveurs.

Euh, non. L'intérêt de la puce TPM c'est qu'elle fait elle-même tous les calculs cryptographiques (enfin ceux qui font intervenir les clés stockées dans la puce).

Les clés ne sortent pas du composant. On peut voir cette puce comme une carte à puce intégrée au PC. Le logiciel crypto s'interface avec la puce TPM en lui disant de chiffrer/déchiffrer/signer, ...

Avec une puce TPM les clés cryptographiques ne sont jamais en RAM!

Cela n'en fait pas un système inviolable pour autant. Si tu as un accès physique à la puce, des attaques similaires à celles existantes dans le domaine des cartes à puce sont envisageables. Attaques qui ont parfois des contremesures d'ailleurs... Mais de telles attaques sont tout de même plus complexes à mettre en oeuvre...

Donc un logiciel espion ou l'attaque présente ne fonctionnent pas ici.

Par contre si la puce sert à déchiffrer un message, il est évident que le dit message va se retrouver en clair en RAM.

Si c'est juste pour transférer des fichiers d'un ordi à un autre et que tu utilises kde sur la machine "cliente", il y a encore plus simple. Tu installes un serveur ssh sur la machine sur laquelle tu veux te connecter. A priori rien à changer par rapport à la config par défaut. A partir du moment où tu peux te connecter en ssh il n'y a plus rien à configurer.

Sur la machine cliente tu lances konqueror avec comme url fish://adressemachine/

Konqueror va te demander le login et mot de passe de la machine distante et en cas de succès afficher son système de fichier.

C'est bien pour copier, migrer des fichiers. Par contre pour voir un film/écouter des mp3 c'est pas adapté car Konqueror va rapatrier tout le fichier avant de le passer au logiciel de lecture.

Tu relances le même programme que tu as dû utiliser pour l'installation (Cygwin.exe ou CygwinSetup.exe,... je sais plus le nom).

Tu repasses alors par les mêmes étapes que lors de l'installation et au moment du choix des packages tu remarqueras qu'il marque comme présents ceux déjà installés et que tu peux en installer d'autres.

Voilà.

Je viens d'essayer Autostitch. Effectivement ça marche très très bien avec Wine.
Il suffit de choisir les photos et il fait tout tout seul comme un grand avec un résultat généralement excellent. Rien à voir avec Hugin avec qui j'ai déjà dû lutter à chaque panorama pour arriver à quelquechose de correct (quand j'y arrive car ce logiciel est très capricieux).

Merci du conseil!

A utiliser avec parcimonie donc, quoique sur des paysages j'ai vu des exemples assez intéressants. Les couleurs étaient peut-être pas tout à fait naturelles mais le résultat était tout de même très estétique (bien plus que les images d'origine). Après c'est une question de goût.

Tiens, je ne connaissais pas Bible. Il a l'air intéressant ce logiciel et en plus il est disponible sous Linux (mais pas libre).
En pratique ça donne quoi? Est-ce qu'il vaut l'investissement selon toi?

Ca pourra m'intéresser quand j'aurai investi dans un réflex numérique. Les limitations de mon Olympus 750 UZ commencent vraiment à me gêner même si je considère toujours que c'est un très bon appareil, notamment son l'optique.

Je reflechit a voix haute, mais ya pas moyen d'embarquer les sous titre dans le conteneur? ca parait le plus propre.
bno ca implique d'avoir un lecteur qui est capable de lire ledit sous titre, mais ca peut etre interessant.


Euh... OGM, MKV, (...?), sont des conteneurs qui permettent d'embarquer les soustitres (en plusieurs langues si on veut) à part mais dans le même fichier (je suis clair là?)
Ils permettent aussi d'ailleurs d'avoir plusieurs bandes son.

Je crois qu'il s'agit d'une applet KDE. Si c'est bien celle que je crois, cette applet lance un mini serveur http permettant très facilement de partager un dossier ou fichier sur le web. C'est assez pratique d'ailleurs.

Pour l'enlever:

clic bouton droit sur une zone sans icône de la barre des taches, un menu s'affiche:

faire "Enlever du tableau de bord" -> "Applet" -> applet que tu veux enlever

Est-ce que c'est ce logiciel ?
http://dvdshrink.sourceforge.net/

Il ne semble pas disponible via urpmi, par contre le site propose dans la section téléchargement un rpm indépendant de l'architecture. (J'ai pas testé)

Je me demande si le futur ordi à 100$ du MIT pourrait pas faire l'affaire: écran relativement petit mais avec une bonne résolution, pas de problème de batterie (on tourne la manivelle et c'est bon), robuste (adapté à la plage?) et tournant avec des logiciels libres. J'en veux un!

Mais encore faudrait-il qu'il soit commercialisé et pas réservé à l'éducation.