Mathieu Schroeter a écrit 130 commentaires

Si tu regardes ici http://download.blender.org/release/ , tu verras 50 et non 5.

Ma dernière source date de longtemps.. j'avais réécrit le script Perl ndiswrapper en C pour le projet GeeXboX (car on intègre pas l'interpréteur Perl). Et comme un con je testais les différences de vitesse pour parser les fichiers .ini entre le script Perl et mon code en ayant gardé le flag -g et j'en revenais pas d'être à peine plus rapide. J'ai refais en le supprimant, et j'ai gagné bcp de temps à l'exécution.

Quand je parle de temps c'est des ordres de grandeur dans les centaines de millisecondes. Ça date de longtemps (quelques années) je n'ai plus trop les valeurs en tête.

Mais je n'ai pas de documents pour appuyer mes dires.

De toute façon Ubuntu n'étant pas recompilé spécialement pour la machine de test les benchs à ce niveau ne montrent qu'une seule chose. Quand on compile pour la machine les performances sont meilleurs, ce qui est une évidence en soit. Faudrait aussi savoir si d'un côté c'est bourré de symboles de debuggage et pas de l'autre. C'est facile de descendre les perfs avec des `-g` en parallèle à des `-O2`. Ce qui est sûrement le cas chez Ubuntu. A vérifier..

Il existe des micro-contrôleurs interprétant le Java. Je ne me suis jamais intéressé à ces 'chips' alors je n'en sais pas plus, mais ça suggère qu'ils puissent être utilisés comme base pour y faire tourner un noyau écrit en Java. Ou tout du moins quelque chose qui ressemble à un noyau.

D'ailleurs, quelqu'un qui réclame aussi un 'auto-save' mais qui ne démoli pas, mais construit: http://www.mail-archive.com/gimp-developer@lists.xcf.berkele(...)

C'est un exemple de lien parmi beaucoup de discussions sur cette fonctionnalité. Un petit tour rapide avec un moteur de recherche et des mots clefs tel que 'gimp auto-save' donnent des résultats intéressants.

J'avoue en avoir un peu *marre* de ce mode de pensée genre 'ah ben ma pov lucette mais le petit sylvain il a beaucoup travaillé sur ce collier de nouille vous pourriez au moins le porter tous les jours'.

Ce n'est pas ce que je voulais dire.. mais pour reprendre ton exemple:

'ah ben ma pov lucette mais le petit sylvain il a beaucoup travaillé sur ce collier de nouille vous pourriez au moins respecter son travail, quitte à ne pas le porter au lieu de le démolir'

Reste aussi à savoir à quel niveau le plantage se situe (Gimp en lui même ou une des nombreuses bibliothèques liées dynamiquement) et de quel type (sûrement une erreur de segmentation).

De même que le problème peut entièrement venir de la personne, dans le sens où si tu fais du développement et que tu installes des bibliothèques ''peut être'' instables dans ton /usr/local/lib et dont Gimp dépend, elles seront considérées par le chargeur de programme à la places de celles des 'packages' qui se situe dans /usr/lib.


Mais pour le savoir avant de dire que 'GIMP EST UNE SALE MERDE' et insulter au passage tous les gens qui ont travaillé sur ce logiciel (à priori l'auteur de ce journal ne doit pas faire grand chose pour la communauté au vue de sa réaction puérile), il existe des outils tel que gdb, strace ou encore ldd pour visualiser les liens et peut être trouver d'où est venu le problème. Et dès ce moment, le journal pourrait devenir constructif, même que le problème pourrait être corrigé...

qui sait..

mais je trouve tout simplement déprimant le manque d'originalité dans les jeux open-source...

L'important est que celui qui conçoit le jeu, prend lui même du plaisir à le faire. Peu importe l'originalité, les graphismes ou je ne sais quoi.. Ce n'est pas une compétition, il n'y a pas de business derrière. Et quand un projet devient conséquent, il est exclus de le réaliser seul à moins de se 'casser le cul' et de transformer ce qui était un hobby en une corvée; ou alors de faire traîner le projet sur 10 ans en se demandant si ça en vaut vraiment le coup.
Pour ce qui est de la question de l'originalité, ça ne se commande pas; mais ça ne veut pas dire qu'il faut se priver du plaisir de développer quelque chose que l'on a envie uniquement parce que ça ne colle pas à l'étiquette (originale qui est met plein les yeux).

D'un point de vue développeur maintenant.. il est intéressant de voir comme les gens qui utilisent certains logiciels libres, ont l'impression que c'est fait pour eux.. et qui ne comprennent pas forcément qu'il y ait une importance plus grande dans le développement sur des aspects qui semblent parfois complètement inutiles à 95% des utilisateurs.
La raison étant simplement que l'un des développeur avait juste envie de la fonctionnalité en question et peu importe que 95% des gens réclament une autre (qui si ça se trouve est bien chiante à coder). A moins d'être payé pour bosser sur un logiciel libre, il ne faut pas oublier que beaucoup font en premier lieu les choses pour eux et pour leur entourage; voir peut être par défis ou curiosité.. et tant mieux si c'est utile à d'autres.
Et ça vaut également pour les jeux ou n'importe quels projets libres (jusque dans certaines limites de popularité).

Si les extra-terrestres débarquent à Genève, l'empathie ne sera pas suffisante pour émouvoir les spectatueurs américains. Le publique français, pourtant plus proche de Genève que de New-York, ne sera pas non plus touché par le pauvre sort réservé à la cité de Calvin.

Pauvres extra-terrestres.. 'toujours' les méchants...
La faute aux 'specta-tueurs', comme le suggère ton erreur de frappe.

Hélas, trois fois hélas, le 31 juillet il a été annoncé que plusieurs plugins de SquirrelMail avaient en fait été trojanés :

Ce qui me surprend c'est que SquirrelMail en lui même est stocké chez SourceForge:
http://prdownloads.sourceforge.net/squirrelmail/squirrelmail(...)

Mais les plugins (j'en ai pris un au hasard) sont stockés chez eux:
http://www.squirrelmail.org/plugins/server_settings_backend-(...)


Quelle est la logique? Bénéficier du mirroiring avec SquirrelMail mais pas avec les plugins? Je ne vois pas qu'est-ce qui les empêches de tout basculer chez SF.

Pour le peu que je sache, et bien qu'ayant écrit une fois un petit système de fichier basé sur l'API haut-niveau de Fuse, la lecture n'est pas très affectée à cause du cache effectué par Fuse. A l'écriture je ne sais pas, je me suis principalement contenté de la lecture seule. Et l'utilisation de l'API bas-niveau fait sûrement une différence non négligeable.

En googlant un peu, j'ai trouvé cet ancien (plus d'une année) benchmark de ZFS-Fuse http://www.linux.com/archive/feature/138452 qui donnent quelques conclusions sur les performances aussi à l'écriture.

Fuse est un outil très puissant, sûr, accessible et très bien construit. Je ne vois pas ce que tu lui reproches.

Je pense plutôt que c'est zfs-fuse qui ne te donne pas satisfaction?!

La toute première impression que j'ai eu en voyant le logo:

.. une souris à trois boutons ...

L'optique de quoi? Vu qu'un disque magnéto-optique stock en magnétique, l'oxydation pourrait affecter ce qui est ferro-magnétique comme un disque dur je suppose?!.. L'optique étant juste là pour chauffer le point à magnétiser.

En attendant, de tels supports, bien que relativement limités en capacité offrent des garantis de 30 ans et parfois plus. Le nombre de réécritures n'étant pas non plus un problème, et sûrement moins qu'un disque dur vu qu'il n'y a pas de moteur avec le support.


J'ai l'impression donc qu'on ne parle pas du tout de la même chose.

Les mémoires flash maintiennent l'information de manière capacitive. Le magnétisme c'est beaucoup plus fiable sur le long terme.

Je pense que le meilleur support actuel reste toujours et encore le magnéto-optique. Et en deuxième position la bande magnétique. Après c'est une question de volume et de coût. Mais stocker sur du flash c'est une énorme bêtise.

Ce n'est pas un choix de GCC car le flag est passé explicitement quand tu utilises -O2 -O3 ou -Os. GCC estime donc rien du tout, il fait ce qu'on lui demande.

Néanmoins, ce problème est peut être une bonne occasion d'ajouter un flag d'avertissement (actif également avec -Wall ?) si GCC applique cette optimisation?!
Bien que dès le moment qu'on la lui demande directement il n'y a pas vraiment de raison de créer un warning. Quand on passe des flags à GCC on est sensé savoir ce qu'on fait et accepter les conséquences.

Voici le flag:


-fdelete-null-pointer-checks
Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null.

In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior.

Enabled at levels -O2, -O3, -Os.


Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.
Ça s'appelle de l'optimisation, dans le cas contraire il suffit de compiler le noyau en -O0 et tu es sûr qu'il ne supprimera pas le test (et accepter les conséquences au niveau des performances). Autrement faut chercher quel flag de GCC effectue ce type d'optimisation dans son manpage monstrueux.

En suivant à la lettre la procédure sur la page http://trac.wildfiregames.com/wiki/BuildInstructions#LinuxOS(...) il n'y a aucune difficulté à compiler le jeu. Je l'ai testé en x86_64 et mise à part un bug qui s'est produit pendant une partie solo au niveau de PulseAudio, ainsi que de son statut pre-alpha; il est très jouable.
J'ai été aussi surpris par la qualité de la musique. Il y a vraiment du potentiel la derrière..

J'ai jeté un œil rapidement à cette doc et elle ne date pas d'hier.. C'était encore l'époque sans epslatex (pré-gnuplot 4). En fonction de la complexité des graphiques, je te conseille vivement epslatex. A moins que tu désires pouvoir manipuler le contenu du dessin sous LaTeX en plus du texte.

Le second exemple présenté sur le billet est intéressant parce que ça permettrait de se passer de l'étape « création d'un graphe avec un tableur, copie d'écran et recadrage » qui est assez fastidieuse ; et on découvre que la légende est trop petite sur le document final ce qui oblige à tout recommencer.

Avec Gnuplot tu peux sauver le graph pour LaTeX tout en ayant la courbe séparée du texte en utilisant epslatex : http://www.gnuplot.info/docs/node373.html
Ça te créer un fichier .eps + un fichier .tex qu'il suffit d'inclure dans le document. Ou alors tu peux créer un fichier LaTeX indépendant.

Et est-ce que Microsoft à participé à l'écriture de la norme ODF et/ou a proposé des corrections constructives (et bien entendu reçu des objections, sinon la question ne se poserait pas) avant d'avoir proposé l'Office OpenXML en tant que norme?

Qu'est-ce qui justifie de créer Office OpenXML au lieu de combler les lacunes de la norme ODF?


Et finalement peu importe le type de fichier en question... je crois que c'est suffisamment évident que tout ce que fais Microsoft c'est avant tout pour son propre intérêt. Que XPS soit meilleur ou non que PDF ils en ont sûrement rien à faire.. tant que le format arrive à s'imposer parmi la "plèbe".. Tout ça n'est que de la stratégie..

si on veut garder son historique
Bon... j'ai lu de travers.. une extension pour désactiver le a:visited semble exister depuis des années https://addons.mozilla.org/fr/firefox/addon/1502

A priori, de juste désactiver complètement l'historique via les "préférences > vie privée" de Firefox, puis relancer le navigateur, ça règle le cas définitivement.. a:visited se comporte comme si rien n'avait été visité.

L'un des développeur est tout d'abord dev chez e17 et synchronise Enna avec le dépôt e17. La version de développement étant localisée dans les dépôts de GeeXboX.

En fait, un jour on l'a contacté pour lui dire qu'on était intéressé par intégrer sa solution dans GeeXboX et pas mal de devs GeeXboX ont apportés un nombre importants de contributions. Il a alors été décidé d'utiliser un dépôt directement chez nous.

Mais Enna existait déjà avant.