Guillaume POIRIER a écrit 243 commentaires

  • [^] # Re: C'est reparti pour la "4k source compo" !

    Posté par  . En réponse à la dépêche C'est reparti pour la "4k source compo" !. Évalué à 2.

    Perso, au temps de mon vieux 486, il y avait une demo 4k qui s'appelait "MARS", reproduisant un paysage en relief dans lequel on pouvait meme se balader avec la souris. Halucinant !
    C'est pas celle-ci?
    ftp://x2ftp.oulu.fi/pub/msdos/programming/misc/mars.lzh(...)
    et le source:
    http://www.programmersheaven.com/d/click.aspx?ID=F15222&AltURL=(...)
  • [^] # Re: C'est reparti pour la "4k source compo" !

    Posté par  . En réponse à la dépêche C'est reparti pour la "4k source compo" !. Évalué à 1.

    Après quelques recherches, voilà l'URL de cette magnifique démo 64k, émulant Magic Carpet: http://www.madchat.org/esprit/artgfx/demo/magic64.exe(...)
    Est-ce que ça peut marcher avec DOSemu?
  • # Re: C'est reparti pour la "4k source compo" !

    Posté par  . En réponse à la dépêche C'est reparti pour la "4k source compo" !. Évalué à 2.

    C'est rigolo: du temps des démos sous DOS, les 4k étaient clairement les plus dures, mais nombre d'entre elles comportaient un compresseur de binaire à la volée.
    Je me rappelle d'ailleurs d'une démo (peut-être pas dans la série 4k) qui reproduisait une démo de "Magic Carpet", le jeux mythique de Bullfrog (Ah! Hi-Octane, Syndicate...). Clairement impressionnant pour la taille du binaire.
    Forcément, avec un source, pas moyen d'utiliser des méthodes de compression à part bien sûr d'utiliser des noms de variables d'1 ou deux caractères
  • [^] # Re: Jusqu'a quand des 2.4.x

    Posté par  . En réponse au journal Jusqu'a quand des 2.4.x. Évalué à 3.

    Il ne faut pas perdre de vu que l'"ajout de support matériel" pour la plupart se limite à l'ajout de drivers, qui de toute façon n'impactent pas sur le reste du noyau.
    Aussi, si tu prends une plate-forme telle que le PPC, l'ajout de support peut juste se résumer corriger/ajouter quelques petits truc pour gérer le "nouveau" G5.
    Ce qui est sûr toutefois, c'est que le 2.4.x n'aurait pas dût théoriquement se voir ajouter le support de XFS, car ce genre de fonctionnalité est déjà plus profondément ancré dans le système, cepandant, devant la pression des utilisateurs, et étant donné qu'XFS avait prouvé qu'il fonctionnait tout à fait correctement, il a été ajouté à Linux 2.4.x dans les séries de dev postérieures à la sortie de Linux 2.6.0
    Pour résumer, dans le 2.4.x, la politique, c'est de "faire que ça continue de fonctionner" alors qu'avec le 2.6.x, c'est "faire que ça fonctionne mieux" (dans le sens où certains sous-systèmes ont encore besoin d'être "tunés")

    J'espère avoir été suffisement clair...
  • [^] # Re: BlueFish 0.13

    Posté par  . En réponse au journal BlueFish 0.13. Évalué à 3.

    Bluefish is a powerful editor for experienced web designers and programmers. Bluefish supports many programming and markup languages, but it focuses on editing dynamic and interactive websites.
    C'est pas le but... BlueFish, c'est plutôt pour du webdesign.
    Va plutôt voir du côté de anjuta http://anjuta.sourceforge.net/(...) pour faire de la prog bash ou perl!
    Quand au VHDL, clairement, le meilleur éditeur pour c'est c'est Xemacs+mode vhdl.
  • # Re: creation site sur Windows

    Posté par  . En réponse au journal creation site sur Windows. Évalué à -2.

    Je sais pas si c'est aussi WISIWIG que tu le veux, mais le must de l'édition de pages HTML et même html+css, c'est quand même Dreamweaver: http://www.macromedia.com/fr/software/dreamweaver/(...)
    ... et comme t'as pas précisé si tu voulais du propriétaire on non...
  • # Re: Mandrakelinux 10.0 Official est arrivée !

    Posté par  . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 4.

    En tant qu'incondiotionnel de mandrake, je trouve ça quand même très raisonnable et très bien bien joué de passer par l'étape "community": quand on voit tous les journaux des semaines passées d'utilisateurs qui avaient des problèmes avec ma mdk-10.0, elle n'était clairement pas finie!

    Pour continuer la série de bonnes nouvelle... à quand la sarge?
  • # Re: idée XUL..

    Posté par  . En réponse au journal idée XUL... Évalué à 2.

    Pour ceux qui voudraient approfondir, linuxmag a fait un dossier spécial sur mozilla a xul (numéro 56)
    Ça a le mérite d'être détaillé et en français
  • # Re: XviD 1.0.0-rc4 iz aoûteu

    Posté par  . En réponse au journal XviD 1.0.0-rc4 iz aoûteu. Évalué à 1.

    J'avais ici posé deux question à propos de xvid et transcode:
    Comment peut-on faire pour créer des presets d'encodade dans le fichier xvid4.cfg de façon à ne plus avoir à éditer ce fichier à la main ou avec xvid4conf, mais en précisant à transcode lors de l'encodage quelle section du fichier xvid4.cfg est à suivre pour l'encodage courant.
    J'avais vu passer cette info il y a quelques mois sur la mailing-list de xvid ou transcode, mais je n'arrive absolument plus à remettre la main dessus.

    Autre question plus générale: serait-il possible avec le codec lavc d'accélérer la première passe en désactivant quelques raffinements coûteux en temps de calcul (trellis, qpel) sans pour autant impacter de façon importante sur la qualité finale du fichier vidéo généré?
    Il me semble que c'est ce qui a été fait pour accélérer la première passe de Xvid (mais peut-être que les fonctions gourmandes ont été remplacées par des plus rapides mais moins fines?)

    En tous cas, merci pour tout ce boulot autour de Xvid (et merci pour le poisson, je me suis fait avoir)

    tiens, au fait, tu n'as pas mis le changelog:
    --------------------------------------------------------------------------
    This is the 4th release candidate of XviD 1.0.0. Codenamed "Hola"

    *This one isn't a joke, so you can really grab it*

    With the RC3 release we had valuable feedback which allowed us fixing some annoying bugs that don't belong to a 1.0 version. We really hope this RC will be the last one, before we can all enjoy 1.0.

    Changes since 1.0.0 RC3 (Ni Hao):

    * xvidcore
    o GMC 1 warp point (DivX5)
    o GMC 2 warp point fix
    o Minor postproc code fixes
    o Motion Vector clipping fix for stressing test cases.
    o Problems caused by wrong cooperation of bframes and frame dropping code.
    o Decoder provides quant information in stats.
    * VFW frontend
    o Multiple instance memory leak fix.
    o Improved bitrate calculator.
    o Some other minor changes.
    * DShow frontend
    o Release packages have all needed files to build from source.
  • [^] # Re: Fedora Core 2 Test 2 disponible pour x86 et x86-64

    Posté par  . En réponse à la dépêche Fedora Core 2 Test 2 disponible pour x86 et x86-64. Évalué à 1.

    On va dire que c'est plus propre et que c'est du joli boulot.
    Hum... peut-être, mais le plus gros avantage, c'est que grâce à la ré-écriture de la couche IDE du kernel, on peut graver des cd et extraire des pistes audio en utilisant le DMA, donc on déchage le CPU de la tâche de gestion de l'ide, ce qui est plutôt pas mal...
    ...Et crois d'ailleurs que même windows utilise une émulation scsi pour la gravure.... en revanche, l'extraction audio fonctionne depuis longtemps avec le dma si je n'abuse
  • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par  . En réponse à la dépêche Comparaison entre les noyaux 2.4.25 et 2.6.4. Évalué à 1.

    En tous cas, je suis content de constater que les dev du noyau ont bien tenu leurs promesses su début du lancement du 2.5.x, à savoir que cette nouvelle branche était vraiment plus ciblée gros systèmes, avec beaucoup de RAM, de process (ordonnanceur O(1), NTPL, ...)
    Comme quoi, contrairement à la politique, en informatique, on tient ses promesses!!!
  • [^] # Re: CPU cooler silencieux ...

    Posté par  . En réponse au journal CPU cooler silencieux .... Évalué à 1.

    J'ai pas cherché la dernière version, mais les tests que j'ai faits, XviD était horriblement lent.
    C'était vrai jusqu'à la beta 1 ou 2, mais depuis c'est largement plus rapide que lavc à réglages équivalent (tout à fond)
  • [^] # Re: CPU cooler silencieux ...

    Posté par  . En réponse au journal CPU cooler silencieux .... Évalué à 1.

    Je peux pas t'aider directement sur les problèmes de températures, mais si tu encodes à la volée en MPEG-4, as-tu pensé à utiliser XVID au lieu de libavcodec?
    C'est vraiment très optimisé (MMX, SSE, SSE2), donc tu pourrais peut-être gagner au niveau du pourcentage d'utilisation du CPU.
  • [^] # Re: L'OpenSource par Trolltech

    Posté par  . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.

    En gros, si la bibliothèque est en GPL, les programmes qui l'utilisent et sont distribués doivent aussi être distribués sous GPL, sinon c'est une violation de licence.

    Je pense qu'au contraire, la licence libre de QT est LGPL (ou licence dérivée), ce qui fait que si tu veux modifier la librairie, tu ne peux que la laisser en LGPL, par contre, tu peux tout à fait utiliser cette "boîte noire" dans un projet non-GPL (exemple: les librairies jpeg)
    NB: Le "L" de L-GPL est pour "librairie"
  • # Re: Critique "Le noyau Linux" aux Editions O'Reilly

    Posté par  . En réponse au journal Critique "Le noyau Linux" aux Editions O'Reilly. Évalué à 1.

    J'ai acheté ce livre, très bien écrit, pour comprendre comment fonctionnait le kernel linux.
    Cependant, je pense qu'il est préférable, si on veut avoir une culture plus générale en systèmes d'exploiration, de lui préférer le bouquin de Tanenbaum "Systèmes d'exploitation", qui non seulement plus général, mais surtout plus compréhensible car moins pollué par tout le code mis en exemple.
    Je dirais toutefois pour quelqu'un qui souhaiterait vraiment étudier le kernel de Linux, ce bouquin est excellent, car sans cette aide, c'est comme aller explorer la jungle amazonienne juste armé d'un canif!! ;-)
  • [^] # Re: BlueEyedOS devient LGPL

    Posté par  . En réponse à la dépêche BlueEyedOS devient LGPL. Évalué à 1.

    L'article d'OSNews "Making the Case for XFree86's Speed" sur lequel ils pointent me rassure un peu quand à la possibilité de rendre nos KDE/Gnome plus réactifs.
    Pourvu que ça vienne vite !


    Pour ceux qui aimeraient y jetter un oeil:
    http://www.osnews.com/printer.php?news_id=1905(...)
  • [^] # Re: Profils d'encodage dans transcode

    Posté par  . En réponse au journal Profils d'encodage dans transcode. Évalué à 1.

    Merci, je connais déjà xvid4conf, que j'utilise déjà...
    J'avais pourtant vu dans les archives de la mailing list de transcode qu'il était possible dans le fichier xvid4.cfg de définir des sections de presets numérotés de 0 à 9, que l'on pouvait ensuite dire à transcode "utilise la section X" lors de l'encodage.
    J'ai peut-etre mal lu, mais toujours est-il que je n'arrive plus à mettre la main sur ce post.... :-(
  • # Re: Analyse des sources de w2k

    Posté par  . En réponse au journal Analyse des sources de w2k. Évalué à 2.

    C'est vraiment fantastique ce code:

    The file private\ntos\w32\ntuser\kernel\swp.c from 11-Jul-1991 points at

    * for idiots like MS-Access 2.0 who SetWindowPos( SWP_BOZO
    * and blow away themselves on the shell, then lets
    * just ignore their plea to be removed from the tray

    Ils se foutent de la gueule des produits de leur propre boîte!!
    Ça serait presque digne de figurer en "fortune cookie" ;-)
  • [^] # Re: IBM demande à Sun de "libérer" Java

    Posté par  . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.

    On peut d'ailleurs noter qu'ils sont l'initiateur du projet "Jikes" ( http://www.research.ibm.com/jikes/(...) ) qui est un compilateur Java très rapide (je crois que c'est parcequ'il est pas écrit en Java, mais en grande partie en C ou C++).
    Ce qu'il est amusant de contater, c'est que quand bien même le projet a débuté en 98, il n'a jamais réussi à toucher un large public.
    On comprend ainsi d'autant mieux la volonté d'IBM que Sun libère Java.
  • [^] # Re: Media Player sous Linux

    Posté par  . En réponse au journal Media Player sous Linux. Évalué à 5.

    3- les windoziens que je fréquente sont tous passés à d'autres logiciels plus petits mais néanmoins plus efficace que leur usine à gaz. Je crois que zoomplayer en fait partie.
    Media Player Classic par exemple? ( http://sourceforge.net/projects/guliverkli/(...) )
    Même si j'utilise exclusivement Linux, il m'arrive d'échanger des vidéos dans des formats assez exotiques (matroska +ogg +XviD-1.0 par exemple), et ce logiciel les lis tous sans problème.
    Je me suis demandé à un moment si c'était un hack de MS media player, mais vu la légèreté de l'engin (environ 900ko), évidement que non.

    Bref, je pense vraiment que cet article de clubic ressemble vraiment à un hoax: Ça n'intéresse personne (on a déjà bien mieux) et ça colle pas trop avec la politique commerciale de MS...
  • [^] # Re: Kernel 2.6.3 dans les bacs

    Posté par  . En réponse à la dépêche Noyau 2.6.3 dans les bacs. Évalué à 1.

    Le changelog est ici:
    http://gcc.gnu.org/gcc-3.4/changes.html(...)
    et en gros il dit:
    Caveats

    * GNU Make is now required to build GCC.
    * With -nostdinc the preprocessor used to ignore both standard include paths and include paths contained in environment variables. It was neither documented nor intended that environment variable paths be ignored, so this has been corrected.
    * GCC no longer accepts the options -fvolatile, -fvolatile-global and -fvolatile-static. It is unlikely that they worked correctly in any 3.x release.
    * GCC no longer ships <varargs.h>. Use <stdarg.h> instead.
    * Support for all the systems obsoleted in GCC 3.3 has been removed from GCC 3.4. See below for a list of systems which are obsoleted in this release.
    * GCC now requires an ISO C90 (ANSI C89) C compiler to build. K&R C compilers will not work.
    * The implementation of the MIPS ABIs has changed. As a result, the code generated for certain MIPS targets will not be binary compatible with earlier releases.
    * The implementation of the SPARC ABIs has changed. As a result, the code generated will not be binary compatible with earlier releases in certain cases.
    * The configure option --enable-threads=pthreads has been removed; use --enable-threads=posix instead, which should have the same effect.
    * Code size estimates used by inlining heuristics for C, Objective-C, C++ and Java have been redesigned significantly. As a result the parameters of -finline-insns, --param max-inline-insns-single and --param max-inline-insns-auto need to be reconsidered.
    * --param max-inline-slope and --param min-inline-insns have been removed; they are not needed for the new bottom-up inlining heuristics.
    * The new unit-at-a-time compilation scheme has several compatibility issues:
    o The order in which functions, variables, and top-level asm statements are emitted may have changed. Code relying on some particular ordering needs to be updated. The majority of such top-level asm statements can be replaced by section attributes.
    o Unreferenced static variables and functions are removed. This may result in undefined references when an asm statement refers to the variable/function directly. In that case either the variable/function shall be listed in asm statement operand or in the case of top-level asm statements the attribute used shall be used to force function/variable to be always output and considered as a possibly used by unknown code.

    For variables the attribute is accepted only by GCC 3.4 and newer, while for earlier versions it is sufficient to use unused to silence warnings about the variables not being referenced. To keep code portable across different GCC versions, you can use appropriate preprocessor conditionals.
    o Static functions now can use non-standard passing conventions that may break asm statements calling functions directly. Again the attribute used shall be used to prevent this behavior.
    As a temporary workaround, -fno-unit-at-a-time can be used, but this scheme may not be supported by future releases of GCC.

    General Optimizer Improvements

    * Usability of the profile feedback and coverage testing has been improved.
    o Performance of profiled programs has been improved by faster profile merging code.
    o Better use of the profile feedback for optimization (loop unrolling and loop peeling).
    o File locking support allowing fork() calls and parallel runs of profiled programs.
    o Coverage file format has been redesigned.
    o gcov coverage tool has been improved.
    o make profiledbootstrap available to build a faster compiler.

    Experiments made on i386 hardware showed an 11% speedup on -O0 and a 7.5% speedup on -O2 compilation of a large C++ testcase.
    o New value profiling pass enabled via -fprofile-values
    o New value profile transformations pass enabled via -fvpt aims to optimize some code sequences by exploiting knowledge about value ranges or other properties of the operands. At the moment a conversion of expensive divisions into cheaper operations has been implemented.
    o New -fprofile-generate and -fprofile-use command line options to simplify the use of profile feedback.
    * A new unit-at-a-time compilation scheme for C, Objective-C, C++ and Java which is enabled via -funit-at-a-time (and implied by -O2). In this scheme a whole file is parsed first and optimized later. The following basic inter-procedural optimizations are implemented:
    o Removal of unreachable functions and variables
    o Discovery of local functions (functions with static linkage whose address is never taken)
    o On i386, these local functions use register parameter passing conventions.
    o Reordering of functions in topological order of the call graph to enable better propagation of optimizing hints (such as the stack alignments needed by functions) in the back end.
    o Call graph based out-of-order inlining heuristics which allows to limit overall compilation unit growth (--param inline-unit-growth).
    Overall, the unit-at-a-time scheme produces a 1.3% improvement for the SPECint2000 benchmark on the i386 architecture (AMD Athlon CPU).
    * More realistic code size estimates used by inlining for C, Objective-C, C++ and Java. The growth of large functions can now be limited via --param large-function-insns and --param large-function-growth.
    * A new cfg-level loop optimizer pass replaces the old loop unrolling pass and adds two other loop transformations -- loop peeling and loop unswitching -- and also uses the profile feedback to limit code growth. (The three optimizations are enabled by -funroll-loops, -fpeel-loops and -funswitch-loops flags, respectively).

    The old loop unroller still can be enabled by -fold-unroll-loops and may produce better code in some cases, especially when the webizer optimization pass is not run.
    * A new web construction pass enabled via -fweb (and implied by -O3) improves the quality of register allocation, CSE, first scheduling pass and some other optimization passes by avoiding re-use of pseudo registers with non-overlapping live ranges. The pass almost always improves code quality but does make debugging difficult and thus is not enabled by default by -O2

    The pass is especially effective as cleanup after code duplication passes, such as the loop unroller or the tracer.
    * Experimental implementations of superblock or trace scheduling in the second scheduling pass can be enabled via -fsched2-use-superblocks and -fsched2-use-traces, respectively.
  • # Re: Micro noyau

    Posté par  . En réponse au journal Micro noyau. Évalué à 4.

    As-tu déjà entendu parler de User Mode Linux? http://usermodelinux.org/(...)
    D'une certaine façon, ça devrait te permettre d'implémenter une partie de ce que tu veux, à savoir mettre une partie du kernel en espace utilisateur.

    Sinon, transformer linux en micro-kernel, à part pour la beauté du geste, est un projet mort-né vu l'opposition historique de Linus vis à vis des micro-kernel.

    Autre chose, ce que tu veux faire, a peut-être déjà été fait avec le projet mklinux: http://www.mklinux.org/(...) . Ils ont peut-être besoin d'un codeur aventureux comme toi!
  • [^] # Re: Outrepasser la protection "Copy Controlled"

    Posté par  . En réponse au journal Outrepasser la protection "Copy Controlled". Évalué à 1.

    Merci de ton expérience. J'utilisais aussi grip, mais couplé avec cdparanoïa. Oh cdparanoïa n'aimait pas du tout le cd, et ne voulait même pas le riper.
    J'ai donc utilisé (comme il m'a été soufflé ci-dessus) cdda2wav, qui a marché, mais le son produit était entâché de craquements.
    J'ai donc utilisé l'option "-paranoia" de cdda2wav, qui ainsi produit un son "cristal clear"...
    c'était simple, encore fallait-il il penser!!!
  • [^] # Re: Le Logo

    Posté par  . En réponse à la dépêche Zope 2.6.4 et 2.7.0 enfin stables. Évalué à 1.

    Les logos de cette page: http://pythonology.org/logos(...) pourraient faire l'affaire nan? Il suffit de les redimentionner, et hop, ça fait la rue michel!
  • [^] # Re: Zope 2.6.4 et 2.7.0 enfin stables

    Posté par  . En réponse à la dépêche Zope 2.6.4 et 2.7.0 enfin stables. Évalué à 2.

    C'est clair que des languages aussi bien fait, ça fait vraiment regretter d'être forcé à son boulot de programmer en C++ (ok, ont fait pas le même de logiciel avec l'un ou avec l'autre)
    Pour ceux qui voudraient se mettre à python, voilà une bonne URL pour commencer:
    http://www.ulg.ac.be/cifen/inforef/swi/python.htm(...)
    Sinon, pour ceux qui préfèrent le bon vieux papier le même auteur a fait un bouquin pour O'Reilly (qui reprend les infos du document sus-nommé)