la faute aux développeurs de ces logiciels qui assument que des segments de mémoire alloués à coup de malloc ou autre allocateur mémoire sont des segments de mémoire exécutables.
La plupart des applis cités utilisent des systèmes de plugins dynamiques faits maison, ca ne m'étonne donc guère que le XP SP2 "puisse" modifier leur comportement (rien ne dit que ca sera le cas à coup sûr).
[humour]
Et quid de mon droit à la copie privée hein ?!
Si j'adore mon billet de 50 Euro, pourquoi j'aurais pas le droit de le copier et de l'utiliser à la caisse de mon supermarché du coin au lieu d'user l'original ?
Je trouve scandaleux qu'on pense même une seule seconde à interdire la contrefacon de billets. A terme, ca nuira à la banque europeenne qui devra en réimprimer !
[/humour]
Hmmmm, comment c'est déjà la formule habituelle ?... Ah oui -->[]
J'y vois un gros intérêt pour la gestion du rendu.
En gros j'estime que vim est un bon editeur, mais les modes un peu complexes comme vimdiff pour faire des beaux merges etc etc, c'est limite imbitable. C'est d'ailleurs vraiment le dernier truc que je regrette depuis mon passage à vim depuis emacs (ediff rox).
Avec un belle intégration des toolkits visuels, je pense que la vue du diff, l'application de chunks etc y gagnerait en visibilité et praticité. Tout comme avoir des vrais sous fenetres avec un ^Wv au lieu d'un canva texte splitté par d'horribles "|"... tout ca c'est typiquement le boulot des widgets, c'est pas le role du canva texte de faire ce rendu, hors dans VIM aujourd'hui, le canva texte melange choux et carrotes (c'est aussi un problème sous emacs mais dans une moindre mesure).
avoir un front end GTK2 pour prouver que cette approche aurait dû être celle adoptée par le projet VIM.
Je trouve ca dommage que l'auteur de VIM n'ait pas voulu se pencher sur les problèmes monstrueux d'architecture de VIM pour tout ce qui concerne son interfaçage avec le monde extérieur (ie: les toolkits visuels).
Si Ysis arrive à compléter la boucle en proposant des frontends mieux intégrés que ceux de VIM (Qt, GTK2, Win32 etc...), belle preuve que leur choix avait été le bon.
Spa tout ca, mais je sens que mon frontend GTK, je vais l'attendre un moment vu que les devs sont principalement des utilisateurs de Qt...
Ralalala ca explique pourquoi le répertoire $HOME est indiqué par un ~ depuis quelques jours lorsque je lance un term... je cherchais quel était le package mis a jour qui avait modifié çà :-) j'avais pas eu l'idée de regarder du coté de bash qui bougeait assez rarement (ou du moins, uniquement des versions mineures)
le Windows XP SP1 a un uptime de 1183j (soit 3.24 ans) or le service pack SP1 de XP est sorti en septembre 2002 soit bientot 2ans... alors faut qu'on m'explique si XP implemente IPoT de http://kadreg.free.fr/ipot/(...)
Je parle meme pas du load a 100%, c'est tellement realiste...
Si tu utilises mencoder+xvid 1.0.x, tu peux specifier la taille de la partie vidéo en passant à mencoder une valeur negative en kiloctets.
Exemple vidéo de 2h avec son 96kbps sur un CD de 700MiB, il reste donc un total de:
700MiB-(2*3600)*(96kbps/8) = 632425kiB
-xvidencopts pass=2:bitrate=-632000 et hop tu calcules pas de bitrate.
Hmmm 3gp, c'est pas censé du mp4 version light pour mobiles ? si c'est le cas, ta vidéo est au format AVI (reconnaissable a l'entete RIFF), dans ce cas peut etre dois tu d'abord remuxer le contenu dans du vrai 3gp.
h263 est pris en charge par libavcodec, donc avec tous ses frontends (mplayer, vlc, xine) tu dois bien avoir le moyen de forcer l'utilisation de libavcodec pour decoder ces vidéos.
Il te faut:
- un noyau 2.6 (ne pas desactiver les futex) ou un noyau 2.4 avec ces sacrés futex backportés.
- une libc compilée avec support NPTL (enfin la partie PThreads, mais c'est inclus dedans)
- rien d'autre
A partir de là, je peux dire que la debian sarge et sid font l'affaire depuis un sacré moment.
>Moi, je dirais que non.... En général les développeurs propriétaires sont formés, ont des diplmes,etc.....
Hmmmm, arf... tu oublies un point extrement important: Beaucoup de developpeurs de logiciels libres sont aussi des développeurs proprios pour le salaire.
Car si on parles toujours des Torvalds, Cox, et autres grands codeurs du noyau, ou de logiciels vedettes de GNU/Linux, tu oublies la grosse masse qui partage bien les valeurs du libre ou de l'open source sans pour autant pouvoir en vivre dans la vraie vie qui a un coût :-) Pour ceux la, le salut monétaire passe par un emploi classique de codeur.
Et pour ce qui est des formations et diplomes a proprement parlé, ca n'influe absolument pas sur la qualité du développeur. Car les formations et diplomes sont plus des faire valoirs lors d'embauches ou lors de "je souhaite faire mon trou dans un nouveau projet/mon entreprise", qu'un réel savoir faire. Le diplome/formation dénote cependant bien que la personne a au moins la capacité de faire certaines taches, ce qui n'implique pas qu'elle les fera bien.
Y a que ca comme options proposées sur le routeur ?
Je demande car à priori si le forwarding de port est dispo, c'est qu'iptables doit etre compilé dans leur linux embarqué. Le truc génial serait donc d'avoir acces à la configuration complète et de faire se configurer un modem/routeur/firewall complet.
Les extensions ARB étaient déjà supportées, c'est multiplateforme et normalisé... donc tu aurais pu nous coder des beaux trucs depuis longtemps ! fénéant nondediou.
Les drivers opensource de XFree86 (nv) et proprio (nvidia) sont tous deux maintenus par NVidia(tm).
Dans un cas, le developpement se fait de facon totalement propriétaire, dans l'autre, un développeur a été embauché afin de le maintenir en open source (voir les copyrights des dits fichiers dans le CVS d'XFree86).
Dans les deux cas, c'est de l'obfuscation de spécification. Même le driver dit opensource est inexploitable, il écrit des valeurs magiques dans des registres quasi non documentés. Le driver proprio lui, masque le fonctionnel derriere des noms de fonctions incompréhensible, de telle sorte que le développeur moyen ne comprenne rien s'il lui venait l'idee de desassembler le .o fourni.
Le driver opensource présente enormement de limitations meme en 2D. L'exemple le plus concret consiste à lister les surfaces Xv disponibles sous les deux drivers. Pour nv, un seul slot est dispo, sur le driver proprio 127 slots sont dispos. D'autres limitations existent, le non support de XvMC, XRender il me semble aussi (déjà le support proprio est faiblard :-)...
Enfin bref, tout ca pour reprendre ta derniere phrase, et la corriger :-) C'est au niveau de la 3D qu'ils veulent garder leurs secrets
devient: C'est au niveau de toutes leurs specifications qu'ils veulent garder leurs secrets.
PS: ce qui ne m'empeche pas d'avoir une geforce car le support OpenGL fourni est de tres bonne facture bien que le driver soit proprio.
Hugin:
Suis le tutorial sur le site de hugin. La seule chose à particulière à faire, c'est de choisir ces deux options specificiques dans le paneau "Sticth"
- Multiple TIFF (dans la zone de saise de format, faire bien attention de nommer le fichier de sortie qqchose.tif, avec un seul "f" sinon on se retrouve avec un fichier vide)
- Nona stitcher (bouton tout en bas du paneau)
Enblend:
Cette etape est gourmande en RAM. Mon exemple tout pourri a base de 3 photos 1600x1200 bouffait 12MB de RAM par image chargée (car le stitching faisait du 3024x1074 au final), or enblend charge au moins 2 images a la fois, plus la pyramide utilisée pour le blending (la je saurais pas te dire combien ca prend, mais le 1er etage de la pyramide doit etre de la taille finale, donc c'est au moins 12MB de plus)... etc etc. Et ca c'etait pour un panoramique très simple, dans une résolution raisonnable.
La commande que j'ai utilisé (avec ma version patchée):
enblend -o final-result.tif stitched-output.tif
Ensuite tu decoupes les bords pour faire un truc rectangualire, tu met a l'echelle souhaitée et tu enregistres le final-result.tif dans le format que tu preferes grace a gimp.
TIFF c'est une sorte de fourre tout de l'image, il suffirait à hugin d'utiliser les TIFF LZW compressed (un peu comme les PNG) pour que la taille effective sur disque soit plus petite.
Mais au final, il faut bien te dire que enblend est un outil, ma foi, rudimentaire, qui de toute facon, utilisera une representation décompréssée de tes images... et dans ce cas, il vaut mieux ne pas perdre de temps a compresser les etapes intermediaires.
Pour une utilisation moins couteuse en memoire il faudrait que enblend utilise un algorithme qui gere le tiling (cad travailler sur de deptites portions d'images a la fois). Notes que je n'ai pas regardé les détails des algorithmes utilisés mais si l'objectif d'enblend est d'atténuer les différences lumineuses/contraste/colorifique sur l'ensemble des images, il me parait difficile de travailler sous forme de tile. Mais bon ca c'est juste un avis vite fait sur la question.
PS: le stitcher PTtruc, il sort rien chez moi, faudrait pe l'installer a coté... auquel cas, je resterai sur nona + mon patch.
>theora n'est pas compatible mpeg4 mais ne viole aucun brevet (du moins pas de brevet "connu")
Autant vorbis a été développé au bon moment (voir même déjà un peut tard à mon gout), cad à une époque ou peu de codecs audio existaient. Autant theora est developpé bien tardivement.
Theora arrive dans un marché archi saturé, et où l'utilisateur doit avoir une dizaine de codecs pour visioner toutes leur videotheque (mpeg1, mpeg2, mpeg4, real 9/10, real precedents, msmpeg4, wmv). Et l'utilisateur lambda ca le fait "chier". En tout cas c'est les retours qu'on a sur XviD de pas mal d'utilisateurs qui comprennent pas pourquoi on sort un format de plus (voir l'interview de l'equipe xvid pour comprendre que DivXNetworks maintient l'ignorance divx=mpeg4=xvid=...)
Et le pire reste à venir, maintenant que le format HD-DVD a été adopté avec pas moins de 3 codecs a supporter, mpeg2, mpeg4-avc (aka h264) et VC9 (aka WMV9 de MS).
J'apprécie d'ailleurs le fait que tu souligne que Theorra n'utilise du moins pas de brevets connus. Car en vidéo, c'est la jungle des brevets, le simple fait de coder une image differentielle par rapport à une image de référence sous forme de bloc (bref le principe de base de tout codeur hybride résidu visuel+chp vectoriel de mouvement) a été breveté (voir signature des emails de Michael Niedermayer, codeur sur FFMPEG). J'ai donc un énorme doute sur le fait que theora soit rellement libre de tout brevet dans l'absolu.
A noter que dans l'avenir, h264 pourrait etre la solution, vu que les industriels derriere cette norme pensent tout simplement laisser la norme en libre utilisation. La ce serait le pied pour tout le monde, autant pour nous pauvres "rebelles" libristes que les géants de l'electronique qui se feront un plaisir de matraquer le marché a coup de h264 c'est bien achetez en.
Au delà du résultat, que je trouve contestable, il est plus important de voir pourquoi ce benchmark ne peut être pris en considération lorsqu'on souhaite comparer Java et C en termes de perfs.
En résumant, j'estime que l'auteur compare du Java avec du très mauvais code C. Je ne sais pas quel est le niveau du codeur C/C++ derrière ces petits benchs, mais force est de constater qu'il n'a aucun bon sens, tant en terme de gestion de mémoire que de performances. Un comble lorsqu'on tente de comparer les performances de deux langages.
Je prend pour exemple le code du fichier matrix.cpp. Pour moi, codeur C depuis déjà quelques années, quand on me dit d'allouer une matrice, j'alloue directement un bloc de sizeof(element)*n*m, mais je n'alloue pas un tableau de pointeurs pour ensuite allouer chaque ligne separement, et ce pour deux raisons:
- c'est sous efficace en terme d'espace memoire (le surcout de n pointeurs) et c'est un surcout en terme d'appels à malloc.
- accéder à un élément devient couteux, car il y a deja une indirection memoire pour acceder a l'adresse de la ligne.
(- le traitement sequentiel des elements est non optimal a cause de la rupture en fin de chaque ligne)
Peut être le codeur cherchait à avoir un code syntaxiquement proche (eg: m[i][j] au lieu d'un m[i*n+j]).
D'ailleurs je doute que le new int[n][m] corresponde au code C proposé, je parierai bien 0.3 que la JVM alloue n*m*sizeof(int), et l'operateur d'acces mat[i][j] n'est qu'une vue de l'esprit, et est traduit dans un bytecode proche de mat[n*i+j].
J'invite tout le monde a se pencher sur le code pour comprendre que ce benchmark n'est tout simplement pas crédible. Le code C/C++ ne correspond pas du tout à ce qu'un codeur C/C++ typique aurait écrit, il resemble plus à une transcription litérale de la version Java. Et donc, ce bench compare Java, avec du C++ qui se prend pour du Java (mais sans jamais faire l'effort de simuler une gestion memoire equivalente, cad ne pas detruire les objets a chaque boucle mais le recycler comme le ferait le GC de la JVM, ou encore anticiper sur le compilateur pour ecrire du code efficace et simple, étape accomplie par le bytecode->code machine du JIT)
J'utilise Java tous les jours au boulot et j'en suis satisafait, je ne crache donc pas du tout sur Java. Par contre je crache sur ce benchmark qui compare des carrotes et des choux... oui c'est pas pareil, et on est bien incapable de conclure que les choux sont meilleurs que les carrotes.
Ah non, je peux dire qu'on conseille FFmpeg pour la lecture. Pour le codage, XviD c'est mieux(tm) et on conseillera jamais un autre codeur :-) Non mais, sinon pourquoi on bosserait du coup si c'était pour conseiller à la fois le codeur et le décodeur FFmpeg ? ;-)
J'ai bien compris que la version complète est dispo. Suse a toujours fait cela il me semble, seulement, ils mettent a disposition sur FTP toute l'arboresence des CDs (comprendre tous les RPMs, les images de boot et pleins d'autre trucs) sans pour autant donner directement accès à des ISOs préparées par eux.
Résultat, l'utilisateur doit faire une net install si j'ai bien compris ou rapatrier le tout et se construire son ISO lui meme (mais a la main). J'ai donc posé mes questions pour voir si je dis pas de betises.
# C'est surtout...
Posté par Edouard Gomez (site web personnel) . En réponse au journal Microsoft vient-il de se tirer une balle dans le pied ?. Évalué à 7.
La plupart des applis cités utilisent des systèmes de plugins dynamiques faits maison, ca ne m'étonne donc guère que le XP SP2 "puisse" modifier leur comportement (rien ne dit que ca sera le cas à coup sûr).
# Aussi...
Posté par Edouard Gomez (site web personnel) . En réponse au message Utilisation de Oprofile.. Évalué à 2.
Les outils c'est bien, mais rien ne vaut la synthèse faite par l'humain.
# Et quid du droit à la copie privée.
Posté par Edouard Gomez (site web personnel) . En réponse au journal blocage anticontrefaçons d'euros. Évalué à 8.
Et quid de mon droit à la copie privée hein ?!
Si j'adore mon billet de 50 Euro, pourquoi j'aurais pas le droit de le copier et de l'utiliser à la caisse de mon supermarché du coin au lieu d'user l'original ?
Je trouve scandaleux qu'on pense même une seule seconde à interdire la contrefacon de billets. A terme, ca nuira à la banque europeenne qui devra en réimprimer !
[/humour]
Hmmmm, comment c'est déjà la formule habituelle ?... Ah oui -->[]
[^] # Re: Y a plus qu'à...
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 4.
En gros j'estime que vim est un bon editeur, mais les modes un peu complexes comme vimdiff pour faire des beaux merges etc etc, c'est limite imbitable. C'est d'ailleurs vraiment le dernier truc que je regrette depuis mon passage à vim depuis emacs (ediff rox).
Avec un belle intégration des toolkits visuels, je pense que la vue du diff, l'application de chunks etc y gagnerait en visibilité et praticité. Tout comme avoir des vrais sous fenetres avec un ^Wv au lieu d'un canva texte splitté par d'horribles "|"... tout ca c'est typiquement le boulot des widgets, c'est pas le role du canva texte de faire ce rendu, hors dans VIM aujourd'hui, le canva texte melange choux et carrotes (c'est aussi un problème sous emacs mais dans une moindre mesure).
# Y a plus qu'à...
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 6.
Je trouve ca dommage que l'auteur de VIM n'ait pas voulu se pencher sur les problèmes monstrueux d'architecture de VIM pour tout ce qui concerne son interfaçage avec le monde extérieur (ie: les toolkits visuels).
Si Ysis arrive à compléter la boucle en proposant des frontends mieux intégrés que ceux de VIM (Qt, GTK2, Win32 etc...), belle preuve que leur choix avait été le bon.
Spa tout ca, mais je sens que mon frontend GTK, je vais l'attendre un moment vu que les devs sont principalement des utilisateurs de Qt...
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Nouvelle version majeure de bash. Évalué à 0.
[^] # Re: uptimes.hostingwired.com
Posté par Edouard Gomez (site web personnel) . En réponse au journal Uptime supérieur à pi années. Évalué à 6.
le Windows XP SP1 a un uptime de 1183j (soit 3.24 ans) or le service pack SP1 de XP est sorti en septembre 2002 soit bientot 2ans... alors faut qu'on m'explique si XP implemente IPoT de http://kadreg.free.fr/ipot/(...)
Je parle meme pas du load a 100%, c'est tellement realiste...
# Specifier la taille du fichier...
Posté par Edouard Gomez (site web personnel) . En réponse au journal Mencoder sux. Évalué à 3.
Exemple vidéo de 2h avec son 96kbps sur un CD de 700MiB, il reste donc un total de:
700MiB-(2*3600)*(96kbps/8) = 632425kiB
-xvidencopts pass=2:bitrate=-632000 et hop tu calcules pas de bitrate.
[^] # Re: Pango
Posté par Edouard Gomez (site web personnel) . En réponse au journal Sortie d'Inkscape 0.39. Évalué à 3.
Y'a des chances ! En effet, je rappelle à ceux qui ne le savent peut etre plus, on doit définir ca:
export GDK_USE_XFT=1
avant de lancer son serveur X pour profiter des polices lissées sur appli GTK2.
# Mauvaise extension ?
Posté par Edouard Gomez (site web personnel) . En réponse au journal Streaming RTSP. Évalué à 3.
# FFMPEG
Posté par Edouard Gomez (site web personnel) . En réponse au journal Streaming et téléphone. Évalué à 2.
# Pas grand chose de nécessaire en fait
Posté par Edouard Gomez (site web personnel) . En réponse au journal Q: Java et NPTL ?. Évalué à 2.
- un noyau 2.6 (ne pas desactiver les futex) ou un noyau 2.4 avec ces sacrés futex backportés.
- une libc compilée avec support NPTL (enfin la partie PThreads, mais c'est inclus dedans)
- rien d'autre
A partir de là, je peux dire que la debian sarge et sid font l'affaire depuis un sacré moment.
[^] # Re: Les développeurs du libre sont-ils....... meilleurs que les développ
Posté par Edouard Gomez (site web personnel) . En réponse au journal Les développeurs du libre sont-ils..... Évalué à 10.
Hmmmm, arf... tu oublies un point extrement important: Beaucoup de developpeurs de logiciels libres sont aussi des développeurs proprios pour le salaire.
Car si on parles toujours des Torvalds, Cox, et autres grands codeurs du noyau, ou de logiciels vedettes de GNU/Linux, tu oublies la grosse masse qui partage bien les valeurs du libre ou de l'open source sans pour autant pouvoir en vivre dans la vraie vie qui a un coût :-) Pour ceux la, le salut monétaire passe par un emploi classique de codeur.
Et pour ce qui est des formations et diplomes a proprement parlé, ca n'influe absolument pas sur la qualité du développeur. Car les formations et diplomes sont plus des faire valoirs lors d'embauches ou lors de "je souhaite faire mon trou dans un nouveau projet/mon entreprise", qu'un réel savoir faire. Le diplome/formation dénote cependant bien que la personne a au moins la capacité de faire certaines taches, ce qui n'implique pas qu'elle les fera bien.
[^] # Re: paramétrage
Posté par Edouard Gomez (site web personnel) . En réponse au journal Freebox V3 : fonctions routeur & Wifi disponibles.. Évalué à 7.
Je demande car à priori si le forwarding de port est dispo, c'est qu'iptables doit etre compilé dans leur linux embarqué. Le truc génial serait donc d'avoir acces à la configuration complète et de faire se configurer un modem/routeur/firewall complet.
[^] # Re: vive oglsl
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Nouveaux pilotes nvidia 6106. Évalué à 4.
;-)
[^] # Re: News
Posté par Edouard Gomez (site web personnel) . En réponse au journal Pilotes nvidia 6106. Évalué à 10.
Dans un cas, le developpement se fait de facon totalement propriétaire, dans l'autre, un développeur a été embauché afin de le maintenir en open source (voir les copyrights des dits fichiers dans le CVS d'XFree86).
Dans les deux cas, c'est de l'obfuscation de spécification. Même le driver dit opensource est inexploitable, il écrit des valeurs magiques dans des registres quasi non documentés. Le driver proprio lui, masque le fonctionnel derriere des noms de fonctions incompréhensible, de telle sorte que le développeur moyen ne comprenne rien s'il lui venait l'idee de desassembler le .o fourni.
Le driver opensource présente enormement de limitations meme en 2D. L'exemple le plus concret consiste à lister les surfaces Xv disponibles sous les deux drivers. Pour nv, un seul slot est dispo, sur le driver proprio 127 slots sont dispos. D'autres limitations existent, le non support de XvMC, XRender il me semble aussi (déjà le support proprio est faiblard :-)...
Enfin bref, tout ca pour reprendre ta derniere phrase, et la corriger :-)
C'est au niveau de la 3D qu'ils veulent garder leurs secrets
devient: C'est au niveau de toutes leurs specifications qu'ils veulent garder leurs secrets.
PS: ce qui ne m'empeche pas d'avoir une geforce car le support OpenGL fourni est de tres bonne facture bien que le driver soit proprio.
[^] # Re: Tutorial
Posté par Edouard Gomez (site web personnel) . En réponse au journal Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau.... Évalué à 2.
Recupere le patch mis à jour à la même adresse qu'auparavant et dis moi si ca marche correctement pour toi alors.
[^] # Re: Tutorial
Posté par Edouard Gomez (site web personnel) . En réponse au journal Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau.... Évalué à 2.
- option -g ds CXXFLAGS
- gdb enblend
[^] # Re: Tutorial
Posté par Edouard Gomez (site web personnel) . En réponse au journal Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau.... Évalué à 4.
Suis le tutorial sur le site de hugin. La seule chose à particulière à faire, c'est de choisir ces deux options specificiques dans le paneau "Sticth"
- Multiple TIFF (dans la zone de saise de format, faire bien attention de nommer le fichier de sortie qqchose.tif, avec un seul "f" sinon on se retrouve avec un fichier vide)
- Nona stitcher (bouton tout en bas du paneau)
Enblend:
Cette etape est gourmande en RAM. Mon exemple tout pourri a base de 3 photos 1600x1200 bouffait 12MB de RAM par image chargée (car le stitching faisait du 3024x1074 au final), or enblend charge au moins 2 images a la fois, plus la pyramide utilisée pour le blending (la je saurais pas te dire combien ca prend, mais le 1er etage de la pyramide doit etre de la taille finale, donc c'est au moins 12MB de plus)... etc etc. Et ca c'etait pour un panoramique très simple, dans une résolution raisonnable.
La commande que j'ai utilisé (avec ma version patchée):
Ensuite tu decoupes les bords pour faire un truc rectangualire, tu met a l'echelle souhaitée et tu enregistres le final-result.tif dans le format que tu preferes grace a gimp.
[^] # Re: Mais COMMENT on l'installe ?
Posté par Edouard Gomez (site web personnel) . En réponse au journal Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau.... Évalué à 7.
>la je trouve "LA" adresse sympa pour les debianeux (http://people.debian.org/~jordens/debs/(...))
Ce qui comme tu n'es point neuneu, se transforme en une magnifique ligne sources.list:
Tu prendras soin de remplacer les \ par des / dans l'entete de protocole http: de la ligne précédente (c'est pour eviter un lien généré par templeet).
Puis apt-get install hugin enblend.
Pour tester mon patch tu peux installer le package enblend dispo la:
http://ed.gomez.free.fr/vrac/enblend/enblend_1.3-1_i386.deb(...)
[^] # Re: salut :)
Posté par Edouard Gomez (site web personnel) . En réponse au journal Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau.... Évalué à 2.
Mais au final, il faut bien te dire que enblend est un outil, ma foi, rudimentaire, qui de toute facon, utilisera une representation décompréssée de tes images... et dans ce cas, il vaut mieux ne pas perdre de temps a compresser les etapes intermediaires.
Pour une utilisation moins couteuse en memoire il faudrait que enblend utilise un algorithme qui gere le tiling (cad travailler sur de deptites portions d'images a la fois). Notes que je n'ai pas regardé les détails des algorithmes utilisés mais si l'objectif d'enblend est d'atténuer les différences lumineuses/contraste/colorifique sur l'ensemble des images, il me parait difficile de travailler sous forme de tile. Mais bon ca c'est juste un avis vite fait sur la question.
PS: le stitcher PTtruc, il sort rien chez moi, faudrait pe l'installer a coté... auquel cas, je resterai sur nona + mon patch.
[^] # Re: Theora
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Gel du codec vidéo Ogg Theora. Évalué à 10.
Autant vorbis a été développé au bon moment (voir même déjà un peut tard à mon gout), cad à une époque ou peu de codecs audio existaient. Autant theora est developpé bien tardivement.
Theora arrive dans un marché archi saturé, et où l'utilisateur doit avoir une dizaine de codecs pour visioner toutes leur videotheque (mpeg1, mpeg2, mpeg4, real 9/10, real precedents, msmpeg4, wmv). Et l'utilisateur lambda ca le fait "chier". En tout cas c'est les retours qu'on a sur XviD de pas mal d'utilisateurs qui comprennent pas pourquoi on sort un format de plus (voir l'interview de l'equipe xvid pour comprendre que DivXNetworks maintient l'ignorance divx=mpeg4=xvid=...)
Et le pire reste à venir, maintenant que le format HD-DVD a été adopté avec pas moins de 3 codecs a supporter, mpeg2, mpeg4-avc (aka h264) et VC9 (aka WMV9 de MS).
J'apprécie d'ailleurs le fait que tu souligne que Theorra n'utilise du moins pas de brevets connus. Car en vidéo, c'est la jungle des brevets, le simple fait de coder une image differentielle par rapport à une image de référence sous forme de bloc (bref le principe de base de tout codeur hybride résidu visuel+chp vectoriel de mouvement) a été breveté (voir signature des emails de Michael Niedermayer, codeur sur FFMPEG). J'ai donc un énorme doute sur le fait que theora soit rellement libre de tout brevet dans l'absolu.
A noter que dans l'avenir, h264 pourrait etre la solution, vu que les industriels derriere cette norme pensent tout simplement laisser la norme en libre utilisation. La ce serait le pied pour tout le monde, autant pour nous pauvres "rebelles" libristes que les géants de l'electronique qui se feront un plaisir de matraquer le marché a coup de h264 c'est bien achetez en.
# Ce benchmark compare du Java à du C++ mais...
Posté par Edouard Gomez (site web personnel) . En réponse au journal Java et C++. Évalué à 7.
En résumant, j'estime que l'auteur compare du Java avec du très mauvais code C. Je ne sais pas quel est le niveau du codeur C/C++ derrière ces petits benchs, mais force est de constater qu'il n'a aucun bon sens, tant en terme de gestion de mémoire que de performances. Un comble lorsqu'on tente de comparer les performances de deux langages.
Je prend pour exemple le code du fichier matrix.cpp. Pour moi, codeur C depuis déjà quelques années, quand on me dit d'allouer une matrice, j'alloue directement un bloc de sizeof(element)*n*m, mais je n'alloue pas un tableau de pointeurs pour ensuite allouer chaque ligne separement, et ce pour deux raisons:
- c'est sous efficace en terme d'espace memoire (le surcout de n pointeurs) et c'est un surcout en terme d'appels à malloc.
- accéder à un élément devient couteux, car il y a deja une indirection memoire pour acceder a l'adresse de la ligne.
(- le traitement sequentiel des elements est non optimal a cause de la rupture en fin de chaque ligne)
Peut être le codeur cherchait à avoir un code syntaxiquement proche (eg: m[i][j] au lieu d'un m[i*n+j]).
D'ailleurs je doute que le new int[n][m] corresponde au code C proposé, je parierai bien 0.3 que la JVM alloue n*m*sizeof(int), et l'operateur d'acces mat[i][j] n'est qu'une vue de l'esprit, et est traduit dans un bytecode proche de mat[n*i+j].
J'invite tout le monde a se pencher sur le code pour comprendre que ce benchmark n'est tout simplement pas crédible. Le code C/C++ ne correspond pas du tout à ce qu'un codeur C/C++ typique aurait écrit, il resemble plus à une transcription litérale de la version Java. Et donc, ce bench compare Java, avec du C++ qui se prend pour du Java (mais sans jamais faire l'effort de simuler une gestion memoire equivalente, cad ne pas detruire les objets a chaque boucle mais le recycler comme le ferait le GC de la JVM, ou encore anticiper sur le compilateur pour ecrire du code efficace et simple, étape accomplie par le bytecode->code machine du JIT)
J'utilise Java tous les jours au boulot et j'en suis satisafait, je ne crache donc pas du tout sur Java. Par contre je crache sur ce benchmark qui compare des carrotes et des choux... oui c'est pas pareil, et on est bien incapable de conclure que les choux sont meilleurs que les carrotes.
[^] # Re: Lecteur xvid de salon
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Interview de l'équipe XviD et sortie de la version 1.0.1. Évalué à 5.
[^] # Re: Hmmm...
Posté par Edouard Gomez (site web personnel) . En réponse au journal SuSE 9.1 dispo sur le ftp de suse. Évalué à 2.
Résultat, l'utilisateur doit faire une net install si j'ai bien compris ou rapatrier le tout et se construire son ISO lui meme (mais a la main). J'ai donc posé mes questions pour voir si je dis pas de betises.