Stephane Marchesin a écrit 254 commentaires

Non car le noyau contient des informations sur sa compilation :
la date/heure de compilation, l'utilisateur qui l'a compilé, le numéro de la compilation.

Regarde le début de ton dmesg, il contient toutes ces infos qui changent dans le temps.

Justement, il me semble bien que Chirac à fait un jour un discourt officiel pour dénoncer les idées prônées par le FN.

Ah oui, c'est vrai. Et ça terminait par quelque chose comme "Et ce n'est pas être raciste que de dire cela", non ?
-> http://www.elysee.org/TEXTES/odeur.shtml(...)

Ce sont des fonctions flottantes, ce qui est louche si tu es en train de compiler un module noyau (puisqu'il ne devrait pas y en avoir dans le noyau - sauf exceptions, dans ce cas il faut les délimiter par kernel_fpu_begin/end et de toute manière on ne fait pas appel à la librairie mathématique).

Je pense que c'est gcc qui génère du code flottant pour "optimiser" certaines choses (à cause du fait qu'il s'agit de code c++ surement) Il faudrait peut etre lui dire de se calmer mais je vois pas trop comment...

Voilà, désolé mais c'est tout ce que je sais :)

Des compilos pour vertex et pixel shaders ?
En tout cas pour les vertex shaders, avec vertex_program_ARB, y'a pas besoin de compiler ...
Si, c'est possible justement, et c'est meme recommandé pour des raisons de performances. En effet, les cartes graphiques se différencient de plus en plus et il y a donc des optimisations nécessaires à faire dépendant de ces cartes (surtout pour les pixels shaders, qui sont beaucoup plus sensible au type de carte graphique). Du coup, la tendance actuelle est de compiler de manière dynamique les pixels shaders à partir de routines de pseudo-C directement sur la machine cible.

Maintenant, si c'est des vertex shaders d'OpenGL 2.0, alors on y est pas encore...
Attention OpenGL 2.0 c'est aussi et surtout la généralisation des pixels shaders. Et quand on y sera à OpenGL 2.0, si on a pas de compilo de pixel shaders libre, ben on aura l'air fins, tiens...

D'ailleurs, des compilos libres pour les shaders ça existe. Enfin à ma connaissance il y en a un seul, qui est la version 1.0 du compilateur de pixel shaders de nvidia (que nvidia a libéré ; il me semble que la licence est une BSD-like mais c'est à vérifier). Par contre les sources de versions 1.1 et 1.2 n'ont pas été distribuées et aucune initiative libre n'existe pour maintenir le compilateur 1.0 libre de nvidia. Le code ne m'a pas l'air impossible à maintenir, il fait dans les 20000 lignes.

Et si on veut suivre la tendance, c'est-à-dire avoir une compilation dynamique des pixels shaders, il faut que la licence du compilateur suive la licence des programmes. De ce point de vue, un compilateur de pixel shaders libres serait une très bonne chose.

C'est vrai que ces docs sont particulièrement imbitables. Mais pour ce qui était du débat autour de la brevetabilité, ça avait vraiment divisé au sein des partis. Je crois que les débats autour de la propriété intellectuelle et des choses qui s'en rapprochent sont globalement orthogonaux aux clivages gauche/droite/extrêmes plus «classiques».

Dans les deux cas de votes que j'ai regardé (celui-là et celui sur les brevets), les groupes qui ont voté quasi-complètement contre (à une ou deux esceptions près) sont les verts et l'exteme gauche. Pour le reste, c'est vrai que ça dépasse les clivages classiques.

En tout cas, ce que je retiens du problème des brevets logiciel, c'est que les députés sont capables de comprendre un domaine qui leur est totalement étranger, à condition de savoir leur montrer qu'on existe, et que l'Europe n'est pas une institution vide de sens et de pouvoir.

Hum, je vais te répondre dans le désordre, d'abord vide de pouvoir, puis vide de sens.

Pour la capacité des députés à voter, effectivement ils me semblent etre capables de voter correctement un texte dans un domaine qui leur est inconnu. Mais nous pouvons regarder les choses de manière un peu différente. Par exemple, suite à ce vote, certains pays européens (à ma connaissance Royaume Uni : http://www.ffii.org.uk/council.html,(...) Suède : http://swpat.ffii.org/news/04/sver0116/index.en.html(...)) et groupes de lobying (EICTA pour ne pas le citer : http://swpat.ffii.org/news/03/eicta1127/index.en.html(...)) ont contesté le vote démocratique du parlement. Eh bien ce vote est en train d'etre annulé, et le conseil des ministres est en train d'envisager l'adoption, à la place du texte amendé, d'un texte autorisant une brevetabilité non limitée (http://swpat.ffii.org/news/04/cons0129/index.en.html(...)). Bien sur, ce texte ne sera pas voté mais adopté par un "commité de propritété intellectuelle". Je pense dont etre en droit de me poser des questions (comme par exemple : "Si je fais du lobbying, est-ce qu'on va aussi faire passer un texte qui m'arrange ?" ou encore "Qui dois-je arroser et avec combien de millions ?"). Ca ne te dérange pas qu'on se moque du processus démocratique et du vote des députés pour faire passer un autre texte sans le voter ? En tout cas le parlement ne m'a pas l'air d'y trouver à redire, pour le pouvoir on repassera.

D'autre part, j'ai l'impression que l'Europe sert de support à des legislations venant tout droit des USA (pas seulement sur les brevets et la propriété intellectuelle en général, mais aussi sur la dégradation des standards de qualité alimentaire par exemple). Et il me semble que ce n'est pas seulement du mimétisme par rapport aus USA, ils ont bien joué un role dans le vote sur les brevets logiciels en nous expliquant comment bien breveter : http://swpat.ffii.org/papers/eubsa-swpat0202/usrep0309/index.en.htm(...)
D'autre part, je suis pret à parier qu'aucun pays ne viendra contester la directive qui a été voté avant-hier.
Bref je commence à avoir de très sérieux doutes quand à l'intéret de l'Europe dans la défense de libertés individuelles, puisque les décisions m'ont l'air d'etre prises dans le sens d'une réduction de celles-ci.

Par contre, la "mondialisation" dans le mauvais sens du terme, on y va tout droit.

ou si on n'est pas trop loin de strasbourg allons à ce rassemblement :
http://www.ipjustice.org/CODE/rally.shtml(...)

Ah ben tiens c'est marrant ça, parce que j'y étais justement à ce rassemblement, et c'était aujourd'hui ! Il n'y avait pas foule, puisqu'on était moins d'une vingtaine. Il parait d'ailleurs que cette manif n'était pas trop déclarée (ou a été déclarée trop à la bourre), mais bon vu l'affluence ça a pas trop posé problème. Enfin, merci quand meme aux allemands du CCC d'avoir fait le déplacement, j'ai bien l'impression qu'ils étaient plus nombreux que les français, on pourrait prendre exemple je crois.

M'enfin, mieux vaut tard que jamais pour s'intéresser, d'ailleurs on me dit dans mon oreillette qu'il n'est pas trop tard pour mettre un lien instructif :
http://www.ipjustice.org/CODE/top8_fr.shtml(...)
(ou pourquoi cette loi sur l'application des droits de propriété intellectuelle est mauvaise).

[oui il y a déjà eu des journaux sur le sujet, oui j'ai posté une dépeche, non elle n'est pas passée on dirait, ou alors les modérateurs attendent eux aussi demain]

Pour netpanzer c'est un peu spécial puisqu'il s'agissait d'un jeu propriétaire qui a été libéré par la suite (quand ils ont vu qu'ils ne pourraient pas le terminer).

Donc ils ont libéré le code et les données, mais je pense effectivement que les "sources" des images ont disparu dans l'histoire (en tout cas je ne les ai jamais vues, et j'ai pourtant suivi ça presque depuis le début).

Hehehe... je fais du rendu volumique avec 450 images 1024*1024 je vois bien le problème (j'ai 1Go de ram et 3 Go de swap :)

Pour ton swap, mets le plutôt au début du disque c'est là qu'il est le plus rapide (par exemple juste après /boot).

Sauf si ça sature auquel cas c'est possible... et comme il décrit un grésillement on peut penser qu'il s'agit d'un son saturé.

Bon, en même temps, je l'ai pas entendu le son :)

Oui, on peut sûrement...

#!/bin/bash
for i in `seq 1 2`;
do
beep -f 220 -l 300 # la
beep -f 329 -l 300 # mi
beep -f 220 -l 300 # la
beep -f 293 -l 600 # ré
beep -f 220 -l 300 # la
beep -f 110 -l 300 # la
beep -f 261 -l 600 # do
beep -f 196 -l 300 # sol
beep -f 110 -l 300 # la
beep -f 293 -l 600 # ré
beep -f 220 -l 300 # la
beep -f 164 -l 300 # mi
beep -f 110 -l 600 # la
beep -f 329 -l 300 # mi
beep -f 220 -l 300 # la
beep -f 293 -l 600 # ré
beep -f 220 -l 300 # la
beep -f 110 -l 300 # la
beep -f 261 -l 600 # do
beep -f 196 -l 300 # sol
beep -f 110 -l 300 # la
beep -f 293 -l 600 # ré
beep -f 261 -l 300 # do
beep -f 248 -l 300 # si
beep -f 220 -l 300 # la
done

Ok, ok, je -->[] en faisant le duck walk avec une gibson SG...

Pourquoi tu n'utilises pas directement kwebdesktop ? Ca fait exactement ce que tu veux.
kwebdesktop --help pour plus d'info

Voila un autre bench apache vs thttpd sur une machine bi processeur :

http://www.zeuscat.com/andrew/work/aprbench/(...)

Les resultats sont similaires, on voit que thttpd a de meilleurs performance (meilleur débit, latence plus basse) que apache 1.X et 2.X, alors que thttpd n'utilise qu'un des deux processeurs.

Faut pas pousser non plus, sur un monoprocesseur, il a de très bonnes perfs. Et comme je ne vois pas de serveur quadri processeur chez moi, je trouve le principe du select() très bien. On ne peut pas trouver de meilleures performances dans l'absolu, mais dans la situation qui m'intéresse (machine mono proc un peu vieille servant des pages statiques), c'est un bon choix.

D'ailleurs, il y a des benchs sur le site de thttpd qui montrent les bonnes perfs des serveurs monothreads :
http://www.acme.com/software/thttpd/benchmarks.html(...)
Et clairement les designs utilisant les threads ont de moins bonnes perfs sur un mono processeur.
On pourrait penser que comme c'est sur leur site ils favorisent leur propre serveur, mais j'ai pu reproduire des résultats similaires sur une page statique sur archi i386 en testant apache vs thttpd vs mathopd vs awhttpd (ce dernier n'est pas dans le bench donné en lien, mais il est monothread basé sur select() et se place au meme niveau que thttpd/mathopd).

Renseigne-toi un peu sur savannah avant de hurler au troll, et tu verras qui s'occupe le plus de l'administration de ce serveur. Regarde par exemple qui modère les nouveaux projets et qui répond aux "feature request".

Bref pas la trace d'un poil de troll ici.

Je pense au contraire que ça lui permet d'avoir une vision "de l'intérieur" qui est ma foi assez intéressante (et différente des communiqués qu'on trouve sur le site).
D'ailleurs, après la lecture de ces quelques mails je m'interroge sur ce que va devenir savannah. J'espère par exemple que les services ne seront pas réduits et que nous (utilisateurs) n'aurons pas trop d'ennuis (par exemple, j'ai lu que tout le monde allait devoir utiliser gpg, ca ne me gène pas mais j'attends de voir la suite, le problème avec les machines qui se sont faites hacker c'est qu'après tout le monde est parano, et des fois un peu trop...).

"Paris demande un délai pour réexaminer la directive européenne" :
http://www.zdnet.fr/actualites/technologie/0,39020809,39130973,00.h(...)

Pour utiliser Memtest86, pas besoin de la Mandrake, ça s'installe très bien dans ton bootloader favori, ou sur une disquette.
Je n'ai jamais fait une telle affirmation ;)

Par contre, c'est quand même fort si un supermount défaillant peut mettre tout le système en rade. Bon, je pense que tout ce qui est compilé dans le kernel peut le faire ?
Ben le système n'est pas vraiment en rade, puisque c'est juste un oops. Souvent, on trouve juste une entrée dans les logs et la machine continue de tourner plus ou moins normalement (ne pas confondre un kernel oops qui n'est pas fatal avec un kernel panic qui lui arrete tout). Les oops que j'ai ne m'empechent pas de redémarrer proprement la machine en général.

Tu crois vraiment que c'est un problème de mémoire (si tu veux en etre sur il y a toujours memtest86) ?

Sachant que tu es sous mandrake, je dirais plutot un problème avec supermount, d'autant plus que le truc a oopsé dans le vfs. J'ai entendu dire que mandrake avait mis à jour supermount, tu devrais peut-etre essayer de mettre à jour ton noyau.

Si brancher ton lecteur à chaud fait sauter ton alim, tu peux essayer avec une deuxième machine sur laquelle tu auras préalablement branché l'alimentation de ton lecteur CD. Ensuite, tu allumes cette deuxième machine au lieu de brancher l'alim a chaud, il y a beacoup moins de risque de faire sauter quelque chose comme ça.

Merci beaucoup, ca marche !

Alors, je résume la démarche parce qu'on peut pas dire que ce soit évident :

-> Sur le site de LG ( http://us.lgservice.com/(...) ) :
- Se munir du fichier Dead.gif
- Se munir du flasher correspondant à ton cd (le fichier zip contenant xferlg.exe et le firmware)

-> Faire une disquette de boot dos 6.0 (je l'ai prise là : http://utils.skull-tech.com/bootdisks/boot600.exe(...) )
- copier xferlg.exe et le firmware sur la disquette

-> Eteindre son PC
-> Brancher le lecteur CD sur la deuxième nappe ide MAIS ne pas brancher le cable d'alimentation du CD ! Je pense qu'il vaut mieux ne pas avoir un autre disque sur la deuxième nappe ide.
-> mettre le jumper du CD comme c'est marqué sur Dead.gif
-> Allumer le PC (oui, le cable d'alimentation du CD n'est toujours pas branché) et booter la disquette DOS
-> Quand la disquette a booté appuyer sur le bouton eject du CD et tout en gardant eject appuyé, brancher le cable d'alimentation du CD (oui, c'est du hotplug), la led du CD clignote un court instant puis reste allumée
-> Relacher le bouton eject apres que la led se soit arretée de clignoter
-> lancer xferlg [le nom du firmware sans l'extension .lge]
-> Eteindre le PC
-> Remettre le jumper du CD dans sa position d'origine (master ou slave)
-> Ca marche !

Merci encore !

C'est intéressant, tu as une url ? Je viens de parcourir la discussion sur slashdot et personne ne dit avoir réussi à récupérer un lecteur. Par contre j'ai trouvé des trucs comme "Is my only solution to scream "LG Sucks!" and defestrate the drive, or are there less primitive ways to do this ?" mais bon c'est slashdot hein :)

Est-ce que quelqu'un a réussi à faire marcher le correctif pour récupérer un lecteur LG ? J'arrive bien à booter en déplacant le jumper et en appuyant sur eject, mais l'outil pour flasher me dit qu'il ne trouve pas le lecteur CD (ca n'a pas l'air de marcher non plus pour le monsieur "auslander" dans ce thread :
http://www.mandrakeusers.org/index.php?showtopic=9483(...) )

Est-ce que qulequ'un a réussi à récupérer un cd-rom LG en suivant les instructions de dead.gif ? J'ai essayé, ca n'a pas marché, pas plus que pour le monsieur ("auslander") à la fin de ce topic : http://www.mandrakeusers.org/index.php?showtopic=9483(...)

J'ai la meme erreur, en gros, il me dit qu'il ne trouve pas le lecteur CD. J'ai mis le CD sur la 2e nappe ide, j'ai aussi essayé la première nappe, rien n'y fait.

Oui, n'hésitez pas s'il y a des questions à me les poser (j'ai activé le forward mail de linuxfr), par exemple pour connaitre son numéro de révision, ou un des divers numéros qui ornent tout appareil electronique. J'ai gardé ce lecteur cdrom en me disant justement que je finirai bien par tomber sur quelqu'un qui cherche à résoudre le problème et que ça pourrait alors servir.

De plus, je ne comprends pas le problème ?? Comment un lecteur CD peut il être incompatible Linux ? C'est à cause des drivers ? Et pour ça merde juste avec la Mandrake 9.2 ? Quelqu'un dans la salle qui sait m'expliquer quel est le problème ?

Ca m'est arrivé. Mon lecteur était un LG, un 40x. Par contre ce n'était pas avec la dernière mandrake mais il y a plus longtemps avec un noyau un peu experimental, un 2.4.21-pre2-jp15 : http://www.ussg.iu.edu/hypermail/linux/kernel/0212.3/0131.html(...)

J'ai compilé et installé ce noyau, et au boot le noyau parlait de problèmes ide. J'ai essayé de rebooter, mais le lecteur cdrom bloquait tout mon ide1. Bref il était mort, et j'ai dû le débrancher.

Par contre, je ne comprends absolument pas la raison, c'est resté un mystère pour moi. J'ai écrit à Jörg Prante (l'auteur du patch), mais il m'a dit qu'il ne savait pas trop, et on a conclu à une coïncidence. Je viens de comprendre plusieurs mois après en lisant linuxfr :)

Bah après tout, si ce lectreur cdrom n'etait pas censé marcher avec linux, je ne vois pas ce que j'aurais pu en faire...

Hum, si on regarde la config du gars, il a de la sdram sur un athlon xp. Le facteur limitant pour la vitesse sera donc la ram chez lui. Maintenant si on descend dans la thread, on trouve le meme gars qui a testé sur un autre PC avec de la ddr, et du coup on voit la différence :

http://www.aceshardware.com/forum?read=105046721(...)