Edouard Gomez a écrit 450 commentaires

Autant il est vrai que le film est un peu (beaucoup) faiblard et n'apporte rien par rapport au deux autres.

Par contre il y a un point que j'ai particuièrement apprécié par rapport aux deux premiers opus: la fin. Dans les deux premiers, la fin suivait le classique Happy Ending: "J'ai (encore) sauvé le monde". La le 3eme se finit par: "Bah finalement le destin est ce qu'il est; on ne sauve pas le monde avant que la catastrophe ait même eu lieu.". Bon en dehors de la fin, le film est digne de figurer au "worst awards" des films d'été.

Telecharger le bittorrent est bien plus efficace tellement le serveur de la warner est surchargé:
http://www.gametab.com/files/torrents.php?fuse=62(...)

A noter que le trailer a été encodé avec les pieds, c'est blocky sur plein de scènes... ce qui est d'autant plus dommage que ceux de Reloaded étaient super bien encodés (bitrate adapté) avec de plus une résolution à la limite du raisonnable (1000x554) pour la machine de l'utilisateur lambda.

Moi je lui est collé un pot Ninja, j'ai changé le carbu et maintenant mon disque dur va a 120km/h le vent dans le dos sur une pente...

Bon je sais ou se trouve la sortie -->[]

En dehors du temps passé à boire (de l'eau), et à tenter de trouver un coin de ma chambre un peu moins chaud (34°C, fenêtre orienté plein SUD -- AÏE)...

J'ai environ mis 3 heures sans trop forcer. Le plus chiant c'est de se plonger dans le code source, car il faut trouver l'endroit le plus pratique où insérer le code de sortie vers le fichier AVI. Puis bon, cette démo était bien conçue[1], dans la mesure où le rendu dépendait d'une horloge unique (et non du nombre de frames rendues), donc obtenir un framerate de 25fps contant a été plutôt facile (si ce n'est réussir à trouver le code précis encore une fois, et vérifier que tu casses rien au passage puisque tout dépend de cette unique horloge).

Après j'ai dû batailler pour réinsérer le track son (trop court, ralongé grace à audacity -- premier soft qui m'est venu à l'esprit -- puis j'ai dû le traficoter pour virer les entetes qui plaisaient pas a transcode)... enfin rien de compliqué, mais fallait le faire :-)

Sinon pour l'encodage, le rendu/encodage initial (640x480) se faisait à 4/3 de temps réel donc, en environ 5 minutes j'avais l'AVI sans piste audio. Rajouter le track audio c'est une question de 30s... pour finir fallait le réencoder en 320x240, quelques minutes aussi.

[1] le code est quand même un peu cracra.

Je donnerai pas plus de 0.3€ pour ce journal en effet ;-)

J'ai dû mal me faire comprendre, voila ce que je vois chez moi... bon je sais, c'est tiré par les cheveux et je -->[]

http://ed.gomez.free.fr/vrac/scrinechiote.png(...)

Il lui fait un doigt en ascii art si je me trompe pas, alors contribuer un patch c'est peut etre trop demander.

Comme sait si bien le dire mmenal sur #linuxfr@freenode, le HURD n'est pas un noyau !

La réponse habituelle est qu'il s'agit plutôt d'un pépin...

McBride est déjà passé demander des sous à MrJournal !

La preuve: http://linuxfr.org/~McBride/4491.html(...)

XviD, DivX >= 4, FFMPEG, 3ivX, Quicktime générent du contenu ISO MPEG4 (sauf bug involontaire). La différence entre tous ces codecs c'est les algorithmes employés et les fonctionnalités permises.

Donc pour clarifier les choses: "lire du XviD", ca revient à lire du ISO MPEG4 Simple Advanced Profile (pour le CVS depuis plus de 8mois)... ou du Simple Profile (pour la série 0.9.x). Les profiles servent juste à indiquer quel sous ensemble de fonctionnalités a été utilisé parmi celles dispos dans le standard MPEG4; ca permet aux industriels de fabriquer du matériel intéropérable pour un profile donné.

Donc "lire du XviD" n'implique pas du tout qu'il y ait du code XviD qq part. Cela implique par contre la présence d'un décodeur MPEG4. En ce qui concerne Sigma, si cette boite avait aussi mis XviD dans ses puces, le matériel devant être acheté, et la puce devant faire l'objet d'un reverse engineering... bah on a pas vérifié (manque d'envie, de moyens financiers et techniques, de temps).

Pour les curieux, voila un tableau qui récapitule les fonctionnalités des différents codecs MPEG4:
http://www.mplayerhq.hu/%7Emichael/codec-features.html(...)

A noter que DivX qui est de loin le plus utilisé, est aussi de loin le moins respectueux du standard. Pour ma part, je conseille FFMPEG en tant que décodeur (le plus complet, puis mplayer/xine l'utilisent, ça tombe bien) et XviD comme codeur (bah oui, sinon je coderais pas sur ce projet)

Au delà tu tapage médiatique qu'on a pu faire pour les faire plier... on a eu droit à rien, et comme tu le signales si bien, Sigma a même sauvé les apparences en disant que c'était leur choix de publier les sources.

Donc pour faire cours:
- l'affaire Sigma vs XviD est fini depuis longtemps.
- XviD n'y a rien gagné et les auteurs encore moins.
- Sigma n'a jamais avoué clairement leur faute, et Sigma s'est bien foutu de la gueule du Libre à travers leur attitude.

A savoir qu'aux états unis, nous (auteurs d'XviD) aurions pu demander des dommages et intérets pour non respect de nos droits d'auteurs, mais n'ayant pas une thune à perdre dans des procès, et vu le flou juridique autour de la légalité même d'XviD[1], nous ne nous y sommes pas risqué... des fois que ca se retourne contre nous.

[1] le MPEGLA ne souhaite pas se prononcer sur la légalité de codecs distribués ss forme de sources. En effet, il est très difficile de juger si un source est un produit fini et donc soumi aux licenses MPEGLA, ou s'il s'agit d'une réécriture de l'implémentation de référence, auquel cas le MPEGLA ne pourrait demander des royalties.

Dans le même style, une petite devinette:

C'est Exponentielle et Logarithme qui vont au restaurant. Qui paye ?
Solution: Exponentielle, car le logarithme népérien.

Bon j'assume et je -->[]

Et quid de la SID ?

Bah spareil:

leeloo $ gcc --version
gcc (GCC) 3.3.1 20030722 (Debian prerelease)

Oui un gcc 3.3.1...

Et qui ose dire que la Debian utilise des antiquités en guise de logiciels ?
Bon je ->[]

>Malheureusement, la puissance de portage rendait WineX trop facile à installer. Pas vraiment besoin de portage pour installer winex facilement. Faudrait aussi interdire de publier ce genre de chose:

./configure \
    --enable-opengl \
    --enable-pthreads \
    --prefix=/opt/winex
make clean all
su -c "make install"
echo "PATH=\$PATH:/opt/winex/bin" >> $HOME/.bashrc
echo "LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:/opt/winex/lib"  >> $HOME/.bashrc

Sinon t'as bien raison de dire qu'ils cherchent juste à se faire aider par des développeurs, car j'ai pas vu de fichier INSTALL présentant la config de winex après installation.

>Je crois que la fréquence de rafraîchissement est de 50Hz (la même que pour le 220V). Ou alors, si l'image est entrelacée, ça nous donne du 25Hz (je ne sais plus si c'est entrelacé ou pas en fait).

La télé en France c'est:
- rafraichissement de 50 hertz.
- une trame par rafraichissement (soit les lignes paires, soit les lignes impaires).
- 2 trames pour une image complète, soit 25 images/s.

Voilà, avec çà t'as plus de doutes a avoir...

La solution serait plutot de démarrer deux serveurs X11, un pour l'écran du portable, l'autre pour la sortie TV.

Doit y avoir mieux quand meme comme solution.

COPITEUR !

Bug, tous les journaux publiant des URLs ne génèrent plus de balises <a href="ton url">le lien</a>

2

C'est pas la 1.4 qui devait sortir en septembre 2002 ? Je m'en souviens à l'époque je me disais "attends la 1.4 et juge la gentoo sur cette version aboutie". Que s'est il passé pour que le développement de la distrib eut été bloqué aussi longtemps ?

LS0vLS0tLy4uLy0tLi4tLSAuLS0tLy4gLi0tLi8uLS4vLi8uLi0uLy4vLi0uLy4gLi0uLi8uIC0t
Ly0tLS8uLS4vLi4uLy4gLS8uLS4vLi0vLS4vLi4uLy4uLS4vLS0tLy4tLi8tLS8uIC4vLS4gLS4u
Li8uLS8uLi4vLi8tLi4uLi8uLi4uLS8uLS4tLi0=

>For every 256 bytes of input, 30 bytes of output result, guaranteed. The big
>challenge that lies ahead is to 'verify' this works for all possibilities of
>bits (2^256 verifications).

Bah c'est simple, cette boite vient d'inventer la compression "à l'infini". Voici la recette:
- Découper un fichier en blocs de 256 octets.
- Passer le tout à la moulinette magique de compression i2bp^WFree Daemon Consulting.
- Egouter ensemble tous les résultats de 30 octets. Réserver au frais.
- Recommencer à la première étape jusqu'à obtention d'un bouillon compressé de 30 octets au total.

Pourvu que s'dure !

Petite correction, depuis la 8.0 les mdk possèdent un outil "équivalent" à apt-get:

Sous mdk: urpmi le_soft_que_tu_veux
Sous debian: apt-get install le_soft_que_tu_veux

Voila pour quoi je comprenais pas pourquoi mdk et rh (qui elle ne possede pas de urpmi de base, amoins d'installer apt4rpm dans un deuxieme temps) avaient trois *.

Bon maintenant si on parle de frontend à apt-get:
- aptitude (frontend console, mais fichtrement efficace, permet de vraiment bien manager ses packages avec quelques touches)
- synaptic (frontend GTK, pas testé donc chuteux... :-)

Puis je pense que la maintenabilité des distributions est importante aussi. Surtout si le public visé est un public professionnel... on a rarerement envie de se saboter une machine de prod pour upgrader la distribution. Ca devrait être un critère à prendre en compte.

Pour le système de notation, les étoiles sont trop restrictives et n'apportent pas assez d'information.

Pourquoi ne pas adapter la notation en fonction de ce que cela représente: Exemple:
Installation:
- peu de questions techniques
- configuration du matériel automatique
- ...
Certes ca complique un peu le systeme de notes, mais le lecteur y trouvera plus d'information. Mieux informé, un utilisateur ciblera mieux sa distrib.

Pour moi Debian Testing ou SID:

Installation:
- mode console
- questions pouvant être techniques.
- minimale (60MB) , c'est à l'utilisateur de rajouter par la suite les outils dont il veut se servir.

Installation des logiciels:
- Très simple en console avec apt-get, apt-cache. La gestion des dépendances est automatique.
- Ils existen des frontend: aptitude (console), synaptic (graphique)

Configuration:
- Les outils proposés sont souvent destinés à une administration à distance, et donc le plus souvent de petis utilitaires consoles.

Facilité d'utilisation:
- Une fois configurée, c'est votre GNU/Linux à vous... donc on s'y sent bien. La maintenabilité y joue aussi un grand role.

Stabilité:
- Les logiciels installés sont souvent très stable (certains diront même vieux). Mais ce choix est fait pour offrir un maximum de stabilité aux environnements de prod.

Dynamique:
- tout dépend de la version utilisée:
* SID: très dynamique (version de développement).
* Testing: dynamique mais pas trop (version qui deviendra Stable).
* Stable: Distribution gravée dans le marbre, gage de stabilité maximum.

Maintenabilité:
- Passer d'une version de distrib à une autre, upgrader tout son système peut se faire en une commande, et se fait très souvent sans aucun dommage notable sur la configuration de la machine.

Public visé:
- utilisateur plutot confirmé ou désireux de mettre les mains dans le camboui de temps à autre,
- ou ancien matériel,
- ou machine de prod,
- ou machine exotique (11 plateformes supportées).

Je pense qu'avant de mettre des étoiles, il serait bon de mieux connaitre les dites distributions (meme si tu avoue utiliser une MDK au quotidien et le reste n'étant que de rapides tests).

Car quand je vois:
Debian : ... Installation des logiciels : **
et toutes les autres distribs avoir trois étoiles... y compris windows qui ne possède pas de système de package proprement dit (les setup.exe certes c'est commun, mais ca ne prend pas soin de la cohérence du système)

Bah j'ai comme un petit doute.

Tout comme le manque d'outils graphiques sur la Red Hat me semble douteux pour la configuration puisqu'il y a plus de 3ans, y'avais linuxconf qui avait un frontend GTK et ncurses. Donc depuis ca a bien du progresser un chouilla.

Mince j'ai oublié de citer celui là:
http://abridgegame.org/darcs/(...)

Par contre, j'y ai pas touché mais son approche (telle qu'elle est décrite sur le site) du problème du versionning semble proche de celle d'Arch... mais je peux pas en dire plus.