>Et puis, à force, on va peut-être réussir à l'optimiser cette algo ;-)
Bon j'ai regardé ou perdait son temps le processeur grâce à oprofile... le résultat est plutot simple: 96.5933% des instructions retirées le sont dans GREYCstoration::compute_LIC_back_forward(int, int);
La moindre optim la dedans devrait faire des miracles, je regarderai de plus près si j'ai du temps libre... d'autant plus que mon profilage est partiel, j'aurais dû utiliser CPU_CLK_UNHALTED pour avoir une estimation des cycles passés dans les fonctions.
PearPC émule le hardware atour d'un PowerPC, tout comme bochs le fait pour les x86. Dans ce cas, je ne vois pas en quoi PearPC serait coupable de violation de license Apple car il permet à un utilisateur d'installer MacOSX sur du x86.
Dans ces conditions, les coupables ne sont pas les auteurs de PearPC, mais bien l'utilisateur qui installe MacOSX sur PearPC en ne respectant pas la license MacOSX qui lui est concédé. Je te rappelle que l'utilisateur *accepte* la license lors de l'installation de l'OS, pas l'auteur de PearPC.
La plus grosse partie de ta memoire est utilisée par le cache FS, ce qui en gros est bon pour toi, puisque ca evite des acces disque par la suite. Puis dans la messure ou tu as 512MB de RAM, pourquoi ne pas laisser le noyau les utiliser à sa guise ?
En tout cas je vois rien d'alarmant dans ton free.
Le seul truc qui peut etre derangeant c'est le comportement du 2.6 qui tend trop facilement à utiliser la swap même lorsqu'il pourrait vider un peu plus le cache FS. Con Kolivas poste des patchs qui visent à améliorer ce genre de choses sur son site, son patch modifie aussi completement le scheduler au passage, tu peux tester, les con kolivas sont les noyaux les plus stables que j'ai trouvé pour des workstations.
http://members.optusnet.com.au/ckolivas/kernel/(...)
>Ca confirme donc mon attitude : mettre autant de free qu'il y a de malloc.
La parité free/malloc ne garantie en rien qu'il n'y ait pas de leak, car souvent la libération de la memoire se fait a divers endroits suivant le chemin suivi par le code.
Le cas typique:
int foobar()
{
void *pt1, *pt2;
if (!(pt1 = malloc(1))) {
fprintf(stderr, "holly shit");
return(-1);
}
if (!(pt2 = malloc(1))) {
fprintf(stderr, "holly shit");
free(pt1);
return(-1);
}
/* Faire un truc interessant ici */
free(pt1);
free(pt2); /* 3 free, mais deux malloc seulement :-) */
return(0);
}
Tout ceci est dû au fait que CVS est basé sur RCS, un très vieux vieux vieux logiciel de versionning, avec toutes les limitations qui vont avec.
Si tu veux pouvoir versionner repertoires, droits sur fichiers et tracer des deplacements de fichiers, je te conseille de regarder du coté de gnuarch, ou bien de subversion, et encore d'autres logiciels qui tentent d'aller plus loin que CVS.
S'il n'a jamais dans tes intentions de te servir de se repertoire, et bien saches que bien que ce soit porc, c'est la seule facon de proceder :-)
Donc effaces le repertoire sur le repository. Mais soit bien sûr qu'aucune version des fichiers du projet ne depende de ce repertoire, sinon effacer le rep sur le serveur revient a casser la continuité de l'historique du projet.
Mais bon, mieux vaut avoir un mot de passe robuste, un nom d'utilisateur pas trop banal, ou comme suggéré au dessus, changer le port par défaut de ssh.
Bof, mieux vaut se faire une clef RSA/DSA 1024bit pour se connecter et utiliser un agent a clefs... les pirates pourront toujours tenter de casser le challenge echangé entre le serveur et toi.
Voir les man pages de ssh-keygen, ssh-add sous Unix. Sous windows, on trouve le couple putty/pageant et le generateur de clef dont j'ai oublié le nom.
De plus grosse bénéfice c'est qu'on tape son mot de passe en local pour decrypter sa clef privée, puis ensuite on le retappe plus jamais pour se connecter aux hosts distants puisque c'est l'agent de clefs qui fait la negociation du challenge. Et meme pour les gros paranos, l'agent peut etre mis en mode "forward" qui fait que si tu te connectes en ssh a partir d'un host distant où tu es connecté en ssh, et bien le challenge se ballade jusqu'a ton host local pour que ta clef privé n'ait pas à se trouver sur différents hosts.
Pour les debianeux, on peut aller admirer son user agent dans l'url about:
Et la surprise (qui n'en est pas une), chez debian ca fait deja un bout de temps que mozilla et tous ses derives sont marqués du sceau de debian au niveau des user agent. Je pense que ca suffit deja amplement a reconnaitre les mozilla "officiels" du reste pour tout ce qui est stats, rapports de bugs et compagnie, pour peu que leurs outils l'incluent dans le rapport.
ffdshow n'est qu'un frontend des decodeurs de ffmpeg, or le shoutout traite de codec, c'est a dire a la fois de co(dage) et dec(odage). Quand je disais que les utilisateurs de windows semblent bouder ffmpeg, je pensais surtout a la partie codage, pas la partie decodage utilisée dans vlc qui est très apprécié des windowsiens
Ca ne va pas vraiment repondre a ta question mais pourquoi ne pas utiliser les outils J2EE pour l'authentification.
Cela consiste a proteger des zones, si l'objet Principal en session ne renvoit pas le bon role, alors l'uilisateur est renvoyé via j_security_check vers la page adequate. Il faut donc definir des realms, et tout les zoes protegees dans le web.xml.
Je n'ai pas d'url a proposer, dsl, mais je suis sûr qu'une ame charitable ou Google en dernier recours pourraient te trouver ca :-)
Sinon j'ai pas vu d'erreurs flagrantes dans ton code.
>y a quand meme de grosses differences d'architecture entre les 2.
Oui un pipeline grossomodo deux fois plus long, ce qui rend le P4 extremement sensible aux ruptures de flux d'instructions et aux miss au niveau du cache L1/L2.
C'est d'ailleurs un peu pour ça que le p4 s'est vu doté d'hyperthreading, histoire de remplir tous ces étages de pipelines qui ne servaient à rien lorsqu'une bulle apparaissait dans le flux d'instructions.
>alors le P3 qui explose le P4, ca je pense pas par contre.
Conclusion, le p4 est un bon radiateur avec option d'éxecution d'instructions IA32. Mais le p4 n'est pas aussi performant que l'est un p3 à fréquence égale.
>Un patch est un patch. Tu l'envoies à Linus et il l'applique ou pas à son arbre.
Ah non, tu envoies à Linus un patch corrigeant un bug pour le 2.6.7, bug toujours présent dans le 2.6.9. Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus, car le code a beaucoup changé sur la forme... bah ton patch a de fortes chances d'etre rejeté.
Donc non, le probleme d'un patch, c'est qu'il doit etre relativement synchronisé avec la version de dev. Tous les patchs ne se valent pas.
Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
>Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
Non arch et SVN ont des formats de patchsets connus, et rien n'empeche de creer des passerelles equifonctionnelles pour qu'un patchset arch soit repercuté sur le repository SVN et vice versa.
Avec BitKeeper, tu pries pour que Larry accepte de te coder la passerelle dont tu reves, et surtout comme tu connais pas ce que fait bitkeeper, tu reves pour que un patchset ne soit pas dégradé au passage. eg: BitKeeper -> CVS est un changement à perte, puisque tu n'es plus capable d'extraire un patchset particulier en raison du fait que CVS versionne par fichier et non l'arbre complet.
Linus a fait le choix d'utiliser BitKeeper, soit, voyons pourquoi ce choix n'impacte pas seulement son workflow mais bien le workflow de tous les contributeurs importants.
Le principal point à prendre en considération est que linus est celui qui pour l'instant maintient la branche principale, les autres devs maintiennent des branches secondaires et donc l'une des taches les plus courantes pour ces developpeurs, c'est de se resynchroniser avec la branche principale sous peine de se rajouter de la charge de travail à devoir réadapter leurs patchs par pans entiers.
Or si linus n'expose ses derniers changements que via BitKeeper, les autres devs sont obligés d'utiliser BitKeeper... ce qui en soit ne serait pas ultra choquant même s'il est non libre. LE plus gros problème est la license de BitKeeper, qui non content d'etre non libre (ce qui deja réduit la liberté des hackers noyaux qui doivent l'utiliser pour se resynchroniser), elle impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper. Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.
Donc le choix de Linus n'impacte pas seulement comment les autres développeurs doivent travailler (via BitKeeper pour ne pas morfler), il réduit de facon indirecte les options de travail d'un dévéloppeur noyau. Donc prend n'importe quel dev noyau, qui aime CVS/Arch/SVN/Darcs/Monotone, bah s'il respecte la license, il aurait pas le droit de contribuer activement a ces projets.
PS: ce genre de clause doit surement etre illégale en France, un peu comme la clause de non concurrence d'un contrat de travail doit etre limité dans le temps, dans l'espace et le domaine d'activité, ou bien compensée financièrement.
PPS: la clause super tordue de BitKeeper n'est la que pour la version Freeware dispo pour tout un chacun, la version payée ne l'integre pas il me semble.
Le top moumoutte, ca serait d'avoir une repertoire IMAP SPAM recevant tous les mails dont le score est > "seuil choisi par l'utilisateur", de telle facon que le systeme de mail ecreme deja le spam puisque seul INBOX est recupere par fetchmail (par defaut).
Et le sumum ! la boite SPAM, seulement alimentée par le systeme de score (sinon je sens l'abus de bouger tous les gros emails dans cette boite pour circonvenir au quota), ne serait pas comptabilisée dans les 25MB de l'espace alloué à notre courrier Free.fr, car dès qu'on recoit des worms, la boite explose en une journée, nous privant des vrais emails pour peu que je parte en week end :-)
Je sais que c'est pas beau de regarder chez les concurrents, mais yahoo.fr fait ca tres clean par exemple :-)
Non, je tourne toujours à 1500-2000 worms par semaine (ma mbox junk-worm fait environ 150MB toutes les semaines).
Question spam, style enlarge your ... ou take a blue pill, ou cheap drug store, ou I have a cancer please gimme money... ou encore I am the president of the congo republic gimme money... ca tourne a une 100ene par semaine.
Sinon y'a aussi les retours de serveurs qui croient que tu envoies des virus, et la je compte plus.
Donc, définitivement non, le spam et worms c'est toujours autant la merde pour moi.
Pour ce qui concerne ton graveur, nul besoin de graver en mode SCSI avec un noyau 2.6, il suffit d'utiliser le device IDE directement genre:
cdrecord -v -tao dev=/dev/hdd monimage.iso
Ca marche tel quel.
PS: je doute que mandrake ne fournisse pas un cdrecord patché avec le support IDE.
>Personnellement j'utilise gphoto2 en ligne de commande ( gphoto2 -P ). Par contre par défaut sous debian il fallait que je sois root pour pouvoir y accéder ( lancer l'utilitaire avec sudo est une solution ). Je ne sais pas si c'est le cas sous mandrake.
Pour que les appareils photos soient utilisables par un user un peu plus normal, creer un groupe "camera", et avec l'aide de hotplug:
cat /etc/hotplug/usb/ixus.usermap
# Benq DC1300
usbcam 0x0003 0x04a5 0x3003 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS
usbcam 0x0003 0x04a9 0x3047 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 2 (PTP mode)
usbcam 0x0003 0x04a9 0x3072 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 300
usbcam 0x0003 0x04a9 0x304d 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 330
usbcam 0x0003 0x04a9 0x3066 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 400
usbcam 0x0003 0x04a9 0x3075 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 400 (PTP mode)
usbcam 0x0003 0x04a9 0x3075 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS i (PTP mode)
usbcam 0x0003 0x04a9 0x309b 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS II (normal mode)
usbcam 0x0003 0x04a9 0x3072 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon DIGITAL IXUS v
usbcam 0x0003 0x04a9 0x3052 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v2
usbcam 0x0003 0x04a9 0x3065 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v3 (normal mode)
usbcam 0x0003 0x04a9 0x3070 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v3 (PTP mode)
usbcam 0x0003 0x04a9 0x3071 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
=====================
Penser a rajouter les users souhaites dans le groupe "camera".
En gros le usermap decrit a hotplug quoi lancer pour chaque couple (vendor, product), usbmap ne fait qu'automatiser un chmod/chown. Tester en branchant l'ixus, et en regardant les droits attribuer a l'inode correspondant a l'APN dans /proc/bus/usb/.../...
>il parait que le code de devfs était pas super en plus
Oui, le code etait sujet à pas mal de racing conditions, et à des modprobe storms. En gros, comme l'ouverture d'un inode /dev/truc spawnait un modprobe pour charger le module adequat, si un process ouvrait sauvagement un device plein de fois, il arrivait que le noyau lance plusieurs modprobe en parallele... rien de bon
Mais le point le plus bloquant concernant devfs, c'est le fait que le mainteneur est injoignable, et personne n'est en mesure de reprendre le code (surtout un manque d'envie).
Greg KH s'est donc dis que grace a hotplug[1] + sysfs[2] et un daemon udevd serialisant les evenements hotplug[3], il etait en mesure de "peupler" /dev dynamiquement un peu comme devfs le faisait, mais cette fois ci uniquement coté userspace. Cependant udev n'est pas equivalent a devfs, en particulier, udev ne charge pas les modules a l'ouverture de l'inode du device (car le module n'etant pas chargé, aucun evennement hotplug n'est généré, donc aucun appel a udev n'est fait)... Voila voila.
Il y avait une conférence enregistrée en MPEG4 où Greg KH expliquait tout çà, je n'ai malheureusement pas l'url dans mes signets. Peut etre quelqu'un pourra la poster.
[1] chaque module détectant des changements d'état parmi les devices qu'il prend en charge lance /sbin/hotplug, en fait `cat /proc/sys/kernel/hotplug` en placant des variables d'environnement adequat... le reste est fait en userspace, montage d'un volume, mise en place des droits, creation d'un symlink /dev/mon_jukebox, etc...
[2] filesystem virtuel habituelment monté sur /sysfs qui représente le matériel géré par le noyau sous une forme arborescente logique et présentant l'état de chaque device.
[3] udevd est en gros une sorte de fifo à evennements hotplug, et qui en fonction des regles contenues dans /etc/udev.d/* cree les bons noeuds dans /dev
La réponse est simple:
Un mutex est un service qui fait que tout demandeur du mutex reste bloqué si celui ci est déjà en cours d'utilisation.
Un sémaphore est une réserve de jetons, une fois la réserve epuisée, le demandeur de jeton est bloqué. Si un sémaphore ne possède qu'un jeton, son fonctionnement simule celui d'un mutex.
Donc moralité, ne pas confondre le contenu (marquer une ressource comme mutuellement exclusive) avec la forme (pthread mutex, sémaphore IPC à un jeton, futex, spinlock etc...)
>comme souvent les programmes passe 80% de leur temps dans 20% de leur code gagner quelque cycles sur le task-switching provoque un gain de temps non negligable.
Premierement, le coup des 80/20 c du mythe, un programme bien conçue répartit le boulot de facon harmonieuse sur l'ensemble du code et n'aboutit jamais à de telles proportions, a moins d'avoir une vue macroscopique de ton appli.
Ces 80% dont tu parles n'ont rien a voir avec le task switching. Car à moins que ton appli soit mal concu et soit IO bound il n'y a aucune raison qu'elle passe son temps à switcher en mode noyau<->mode utilisateur. Une application IO bound n'est de toute facon pas optimisable, à moins de réduire les entrées sorties, ou d'optimiser les entrées sorties elles même.
De plus le task switching depend bcp de l'implémentation hardware pour sauvergarder/restaurer les contextes CPU/Memoire paginée.
>Sur un calcul qui tourne plusieurs jours en gagner une heure ou deux est toujours interressant.
Si tu sais que ton appli va tourner des jours, et est tres gourmande en CPU, la premiere chose a laquelle il faut penser c'est de parametrer le scheduler afin qu'il lui alloue des time slices plus grands, ou des time slice plus reguliers, nice est la pour ca. Des fois il faut même faire tourner la tache dans un mode non SCHED_NORMAL, genre SCHED_ISO (Patch Con kolivas, mode RT du pauvre :-) ), SCHED_RT (si tu veux vraiment que ta tache soit prioritaire vis a vis de toutes les taches NORMAL) ou SCHED_BATCH (Patch con kolivas, si ta tache est absolument non prioritaire, genre seti@home)...
Bref, l'important c'est 1) que le programme qui tourne soit optimisé 2) parametrer ton noyau pour donner plus d'importance à ce même programme. Et à moins que ton programme depende d'une entree sortie sur un quelconque périphérique, à même code noyau et machine et code user, le fait de changer de compilo pour le noyau n'apportera pas grand chose.
Exemple:
xvidcore 1.1-cvs sur un noyau vanilla (decompression d'une sequence mpeg4): 215s
xvidcore 1.1-cvs sur un noyau con kolivas buggé dans sa gestion des time slice (vers les 2.6.7-ckX): 187s
xvidcore 1.1-cvs noyau vanilla, les deux choses compilés avec des options "alacon" genre -O9 -fplein-de-trucs-toussa, 213s.
Le gain de perf n'etait pas du a un chgt de compilo, mais bien au fait que le scheduler allouait des timeslices trop importants aux taches gourmandes en CPU (laissant ainsi les autres taches sans CPU... il s'agissait d'un bug), mais c'est pour te montrer que l'algorithmie donne des résultats plus "voyants" que l'optimisation brute par chgt de compilo/options.
[^] # Re: effet video
Posté par Edouard Gomez (site web personnel) . En réponse au journal Greffon Gimp GREYCstoration. Évalué à 1.
Bon j'ai regardé ou perdait son temps le processeur grâce à oprofile... le résultat est plutot simple: 96.5933% des instructions retirées le sont dans GREYCstoration::compute_LIC_back_forward(int, int);
La moindre optim la dedans devrait faire des miracles, je regarderai de plus près si j'ai du temps libre... d'autant plus que mon profilage est partiel, j'aurais dû utiliser CPU_CLK_UNHALTED pour avoir une estimation des cycles passés dans les fonctions.
Aux amateurs d'optim, le profile et les sources annotées sont sur:
http://ed.gomez.free.fr/vrac/GREYCstoration/(...)
Mais biensûr, en bon optimiseur que vous êtes, oprofile n'a plus aucun secret pour vous et donc mon profilage partiel ne vous servira a rien.
[^] # Re: Le projet PearPC...
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Maui X-Stream aurait volé du code sous GPL et se serait approprié le copyright de PearPC. Évalué à 3.
Dans ces conditions, les coupables ne sont pas les auteurs de PearPC, mais bien l'utilisateur qui installe MacOSX sur PearPC en ne respectant pas la license MacOSX qui lui est concédé. Je te rappelle que l'utilisateur *accepte* la license lors de l'installation de l'OS, pas l'auteur de PearPC.
# Rien d'anormal
Posté par Edouard Gomez (site web personnel) . En réponse au message Consommation mémoire trop importante. Évalué à 6.
total used free shared buffers cached Mem: 516072 506048 10024 0 36256 330484 -/+ buffers/cache: 139308 376764 Swap 265032 0 265032La plus grosse partie de ta memoire est utilisée par le cache FS, ce qui en gros est bon pour toi, puisque ca evite des acces disque par la suite. Puis dans la messure ou tu as 512MB de RAM, pourquoi ne pas laisser le noyau les utiliser à sa guise ? En tout cas je vois rien d'alarmant dans ton free. Le seul truc qui peut etre derangeant c'est le comportement du 2.6 qui tend trop facilement à utiliser la swap même lorsqu'il pourrait vider un peu plus le cache FS. Con Kolivas poste des patchs qui visent à améliorer ce genre de choses sur son site, son patch modifie aussi completement le scheduler au passage, tu peux tester, les con kolivas sont les noyaux les plus stables que j'ai trouvé pour des workstations. http://members.optusnet.com.au/ckolivas/kernel/(...)[^] # Re: Plop
Posté par Edouard Gomez (site web personnel) . En réponse au message free() or not free() ?. Évalué à 2.
int foobar() { void *pt1, *pt2; if (!(pt1 = malloc(1))) { fprintf(stderr, "holly shit"); return(-1); } if (!(pt2 = malloc(1))) { fprintf(stderr, "holly shit"); free(pt1); return(-1); } /* Faire un truc interessant ici */ free(pt1); free(pt2); /* 3 free, mais deux malloc seulement :-) */ return(0); }# Sainul ca lag !
Posté par Edouard Gomez (site web personnel) . En réponse au journal $ ping -c 1 titan. Évalué à 3.
Ok je -->[]
[^] # Re: Pas réveillé, moi, ce matin !
Posté par Edouard Gomez (site web personnel) . En réponse au message Question de developpeur à propos de cvs.. Évalué à 2.
Si tu veux pouvoir versionner repertoires, droits sur fichiers et tracer des deplacements de fichiers, je te conseille de regarder du coté de gnuarch, ou bien de subversion, et encore d'autres logiciels qui tentent d'aller plus loin que CVS.
[^] # Re: Pas réveillé, moi, ce matin !
Posté par Edouard Gomez (site web personnel) . En réponse au message Question de developpeur à propos de cvs.. Évalué à 2.
Donc effaces le repertoire sur le repository. Mais soit bien sûr qu'aucune version des fichiers du projet ne depende de ce repertoire, sinon effacer le rep sur le serveur revient a casser la continuité de l'historique du projet.
[^] # Re: Mes stats...
Posté par Edouard Gomez (site web personnel) . En réponse au message sshd : c'est quoi ces logs ?. Évalué à 2.
Bof, mieux vaut se faire une clef RSA/DSA 1024bit pour se connecter et utiliser un agent a clefs... les pirates pourront toujours tenter de casser le challenge echangé entre le serveur et toi.
Voir les man pages de ssh-keygen, ssh-add sous Unix. Sous windows, on trouve le couple putty/pageant et le generateur de clef dont j'ai oublié le nom.
De plus grosse bénéfice c'est qu'on tape son mot de passe en local pour decrypter sa clef privée, puis ensuite on le retappe plus jamais pour se connecter aux hosts distants puisque c'est l'agent de clefs qui fait la negociation du challenge. Et meme pour les gros paranos, l'agent peut etre mis en mode "forward" qui fait que si tu te connectes en ssh a partir d'un host distant où tu es connecté en ssh, et bien le challenge se ballade jusqu'a ton host local pour que ta clef privé n'ait pas à se trouver sur différents hosts.
# Debian estampille deja firefox et mozilla a sa sauce
Posté par Edouard Gomez (site web personnel) . En réponse au journal ils sont tombés sur la tête. Évalué à 8.
Pour les debianeux, on peut aller admirer son user agent dans l'url about:
Et la surprise (qui n'en est pas une), chez debian ca fait deja un bout de temps que mozilla et tous ses derives sont marqués du sceau de debian au niveau des user agent. Je pense que ca suffit deja amplement a reconnaitre les mozilla "officiels" du reste pour tout ce qui est stats, rapports de bugs et compagnie, pour peu que leurs outils l'incluent dans le rapport.
[^] # Re: hop
Posté par Edouard Gomez (site web personnel) . En réponse au message De quoi debuter sous C#. Évalué à 2.
Je te pertinence pour les bookmarks :-)
[^] # Re: ffmpeg
Posté par Edouard Gomez (site web personnel) . En réponse au journal Comparatif de codecs vidéo doom9 2004. Évalué à 7.
# Hmmm
Posté par Edouard Gomez (site web personnel) . En réponse au message Question à 100 001 euros. Évalué à 1.
Cela consiste a proteger des zones, si l'objet Principal en session ne renvoit pas le bon role, alors l'uilisateur est renvoyé via j_security_check vers la page adequate. Il faut donc definir des realms, et tout les zoes protegees dans le web.xml.
Je n'ai pas d'url a proposer, dsl, mais je suis sûr qu'une ame charitable ou Google en dernier recours pourraient te trouver ca :-)
Sinon j'ai pas vu d'erreurs flagrantes dans ton code.
# Select
Posté par Edouard Gomez (site web personnel) . En réponse au message onClick désactivé après clickage. Évalué à 2.
Le seul workaround connu à ce jour est de desactiver les select de la page lorsque la boite pouvant masquer le select est mis en avant.
[^] # Re: boum !
Posté par Edouard Gomez (site web personnel) . En réponse au journal Comparatif CPU. Évalué à 7.
Oui un pipeline grossomodo deux fois plus long, ce qui rend le P4 extremement sensible aux ruptures de flux d'instructions et aux miss au niveau du cache L1/L2.
C'est d'ailleurs un peu pour ça que le p4 s'est vu doté d'hyperthreading, histoire de remplir tous ces étages de pipelines qui ne servaient à rien lorsqu'une bulle apparaissait dans le flux d'instructions.
>alors le P3 qui explose le P4, ca je pense pas par contre.
Conclusion, le p4 est un bon radiateur avec option d'éxecution d'instructions IA32. Mais le p4 n'est pas aussi performant que l'est un p3 à fréquence égale.
[^] # Re: A tester.
Posté par Edouard Gomez (site web personnel) . En réponse au message Gmail et acces POP3. Évalué à 2.
# A tester.
Posté par Edouard Gomez (site web personnel) . En réponse au message Gmail et acces POP3. Évalué à 2.
Il semblerait que l'option "fetchall" soit obligatoire avec gmail. Je testerai donc ce soir et mettrai à jour ce thread pour la postérité.
[^] # Re: bk et linux
Posté par Edouard Gomez (site web personnel) . En réponse au journal BitKeeper ou Arch. Évalué à 6.
Ah non, tu envoies à Linus un patch corrigeant un bug pour le 2.6.7, bug toujours présent dans le 2.6.9. Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus, car le code a beaucoup changé sur la forme... bah ton patch a de fortes chances d'etre rejeté.
Donc non, le probleme d'un patch, c'est qu'il doit etre relativement synchronisé avec la version de dev. Tous les patchs ne se valent pas.
Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
>Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
Non arch et SVN ont des formats de patchsets connus, et rien n'empeche de creer des passerelles equifonctionnelles pour qu'un patchset arch soit repercuté sur le repository SVN et vice versa.
Avec BitKeeper, tu pries pour que Larry accepte de te coder la passerelle dont tu reves, et surtout comme tu connais pas ce que fait bitkeeper, tu reves pour que un patchset ne soit pas dégradé au passage. eg: BitKeeper -> CVS est un changement à perte, puisque tu n'es plus capable d'extraire un patchset particulier en raison du fait que CVS versionne par fichier et non l'arbre complet.
# Pourquoi ca impacte tous les devs...
Posté par Edouard Gomez (site web personnel) . En réponse au journal BitKeeper ou Arch. Évalué à 10.
Le principal point à prendre en considération est que linus est celui qui pour l'instant maintient la branche principale, les autres devs maintiennent des branches secondaires et donc l'une des taches les plus courantes pour ces developpeurs, c'est de se resynchroniser avec la branche principale sous peine de se rajouter de la charge de travail à devoir réadapter leurs patchs par pans entiers.
Or si linus n'expose ses derniers changements que via BitKeeper, les autres devs sont obligés d'utiliser BitKeeper... ce qui en soit ne serait pas ultra choquant même s'il est non libre. LE plus gros problème est la license de BitKeeper, qui non content d'etre non libre (ce qui deja réduit la liberté des hackers noyaux qui doivent l'utiliser pour se resynchroniser), elle impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper. Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.
Donc le choix de Linus n'impacte pas seulement comment les autres développeurs doivent travailler (via BitKeeper pour ne pas morfler), il réduit de facon indirecte les options de travail d'un dévéloppeur noyau. Donc prend n'importe quel dev noyau, qui aime CVS/Arch/SVN/Darcs/Monotone, bah s'il respecte la license, il aurait pas le droit de contribuer activement a ces projets.
PS: ce genre de clause doit surement etre illégale en France, un peu comme la clause de non concurrence d'un contrat de travail doit etre limité dans le temps, dans l'espace et le domaine d'activité, ou bien compensée financièrement.
PPS: la clause super tordue de BitKeeper n'est la que pour la version Freeware dispo pour tout un chacun, la version payée ne l'integre pas il me semble.
[^] # Re: Spam et Free
Posté par Edouard Gomez (site web personnel) . En réponse au journal Moins de spam aujourd'hui ?. Évalué à 2.
Et le sumum ! la boite SPAM, seulement alimentée par le systeme de score (sinon je sens l'abus de bouger tous les gros emails dans cette boite pour circonvenir au quota), ne serait pas comptabilisée dans les 25MB de l'espace alloué à notre courrier Free.fr, car dès qu'on recoit des worms, la boite explose en une journée, nous privant des vrais emails pour peu que je parte en week end :-)
Je sais que c'est pas beau de regarder chez les concurrents, mais yahoo.fr fait ca tres clean par exemple :-)
# Hi, enlarge your bluepill and stock options
Posté par Edouard Gomez (site web personnel) . En réponse au journal Moins de spam aujourd'hui ?. Évalué à 3.
Question spam, style enlarge your ... ou take a blue pill, ou cheap drug store, ou I have a cancer please gimme money... ou encore I am the president of the congo republic gimme money... ca tourne a une 100ene par semaine.
Sinon y'a aussi les retours de serveurs qui croient que tu envoies des virus, et la je compte plus.
Donc, définitivement non, le spam et worms c'est toujours autant la merde pour moi.
[^] # Re: Essaie avec devfs
Posté par Edouard Gomez (site web personnel) . En réponse au message Pas de device pour le lecteur CD avec la 10.1. Évalué à 2.
Pour ce qui concerne ton graveur, nul besoin de graver en mode SCSI avec un noyau 2.6, il suffit d'utiliser le device IDE directement genre:
cdrecord -v -tao dev=/dev/hdd monimage.iso
Ca marche tel quel.
PS: je doute que mandrake ne fournisse pas un cdrecord patché avec le support IDE.
[^] # Re: gphoto2
Posté par Edouard Gomez (site web personnel) . En réponse au message Ixus 400 et mandrake. Évalué à 3.
Pour que les appareils photos soient utilisables par un user un peu plus normal, creer un groupe "camera", et avec l'aide de hotplug:
cat /etc/hotplug/usb/ixus.usermap
# Benq DC1300
usbcam 0x0003 0x04a5 0x3003 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS
usbcam 0x0003 0x04a9 0x3047 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 2 (PTP mode)
usbcam 0x0003 0x04a9 0x3072 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 300
usbcam 0x0003 0x04a9 0x304d 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 330
usbcam 0x0003 0x04a9 0x3066 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 400
usbcam 0x0003 0x04a9 0x3075 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS 400 (PTP mode)
usbcam 0x0003 0x04a9 0x3075 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS i (PTP mode)
usbcam 0x0003 0x04a9 0x309b 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS II (normal mode)
usbcam 0x0003 0x04a9 0x3072 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon DIGITAL IXUS v
usbcam 0x0003 0x04a9 0x3052 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v2
usbcam 0x0003 0x04a9 0x3065 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v3 (normal mode)
usbcam 0x0003 0x04a9 0x3070 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
# Canon Digital IXUS v3 (PTP mode)
usbcam 0x0003 0x04a9 0x3071 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
=====================
cat /etc/hotplug/usb/usbcam
#!/bin/bash
GROUP=camera
if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
then
chmod o-rwx "${DEVICE}"
chgrp "${GROUP}" "${DEVICE}"
chmod g+rw "${DEVICE}"
fi
=====================
chmod 755 /etc/hotplug/usb/usbcam
chown root:root /etc/hotplug/usb/usbcam
chown root:root /etc/hotplug/usb/ixus.usermap
=====================
Penser a rajouter les users souhaites dans le groupe "camera".
En gros le usermap decrit a hotplug quoi lancer pour chaque couple (vendor, product), usbmap ne fait qu'automatiser un chmod/chown. Tester en branchant l'ixus, et en regardant les droits attribuer a l'inode correspondant a l'APN dans /proc/bus/usb/.../...
[^] # Re: virtual filesystem
Posté par Edouard Gomez (site web personnel) . En réponse au message qu est ce que udev ? devfs ?. Évalué à 5.
Oui, le code etait sujet à pas mal de racing conditions, et à des modprobe storms. En gros, comme l'ouverture d'un inode /dev/truc spawnait un modprobe pour charger le module adequat, si un process ouvrait sauvagement un device plein de fois, il arrivait que le noyau lance plusieurs modprobe en parallele... rien de bon
Mais le point le plus bloquant concernant devfs, c'est le fait que le mainteneur est injoignable, et personne n'est en mesure de reprendre le code (surtout un manque d'envie).
Greg KH s'est donc dis que grace a hotplug[1] + sysfs[2] et un daemon udevd serialisant les evenements hotplug[3], il etait en mesure de "peupler" /dev dynamiquement un peu comme devfs le faisait, mais cette fois ci uniquement coté userspace. Cependant udev n'est pas equivalent a devfs, en particulier, udev ne charge pas les modules a l'ouverture de l'inode du device (car le module n'etant pas chargé, aucun evennement hotplug n'est généré, donc aucun appel a udev n'est fait)... Voila voila.
Il y avait une conférence enregistrée en MPEG4 où Greg KH expliquait tout çà, je n'ai malheureusement pas l'url dans mes signets. Peut etre quelqu'un pourra la poster.
[1] chaque module détectant des changements d'état parmi les devices qu'il prend en charge lance /sbin/hotplug, en fait `cat /proc/sys/kernel/hotplug` en placant des variables d'environnement adequat... le reste est fait en userspace, montage d'un volume, mise en place des droits, creation d'un symlink /dev/mon_jukebox, etc...
[2] filesystem virtuel habituelment monté sur /sysfs qui représente le matériel géré par le noyau sous une forme arborescente logique et présentant l'état de chaque device.
[3] udevd est en gros une sorte de fifo à evennements hotplug, et qui en fonction des regles contenues dans /etc/udev.d/* cree les bons noeuds dans /dev
# Pourquoi mutex.
Posté par Edouard Gomez (site web personnel) . En réponse au message speedtouch et modem_run. Évalué à 2.
Un mutex est un service qui fait que tout demandeur du mutex reste bloqué si celui ci est déjà en cours d'utilisation.
Un sémaphore est une réserve de jetons, une fois la réserve epuisée, le demandeur de jeton est bloqué. Si un sémaphore ne possède qu'un jeton, son fonctionnement simule celui d'un mutex.
Donc moralité, ne pas confondre le contenu (marquer une ressource comme mutuellement exclusive) avec la forme (pthread mutex, sémaphore IPC à un jeton, futex, spinlock etc...)
[^] # Re: Impressionnant
Posté par Edouard Gomez (site web personnel) . En réponse au message Linux 2.6.9 compile avec icc 8.1 sans modifs!. Évalué à 4.
Premierement, le coup des 80/20 c du mythe, un programme bien conçue répartit le boulot de facon harmonieuse sur l'ensemble du code et n'aboutit jamais à de telles proportions, a moins d'avoir une vue macroscopique de ton appli.
Ces 80% dont tu parles n'ont rien a voir avec le task switching. Car à moins que ton appli soit mal concu et soit IO bound il n'y a aucune raison qu'elle passe son temps à switcher en mode noyau<->mode utilisateur. Une application IO bound n'est de toute facon pas optimisable, à moins de réduire les entrées sorties, ou d'optimiser les entrées sorties elles même.
De plus le task switching depend bcp de l'implémentation hardware pour sauvergarder/restaurer les contextes CPU/Memoire paginée.
>Sur un calcul qui tourne plusieurs jours en gagner une heure ou deux est toujours interressant.
Si tu sais que ton appli va tourner des jours, et est tres gourmande en CPU, la premiere chose a laquelle il faut penser c'est de parametrer le scheduler afin qu'il lui alloue des time slices plus grands, ou des time slice plus reguliers, nice est la pour ca. Des fois il faut même faire tourner la tache dans un mode non SCHED_NORMAL, genre SCHED_ISO (Patch Con kolivas, mode RT du pauvre :-) ), SCHED_RT (si tu veux vraiment que ta tache soit prioritaire vis a vis de toutes les taches NORMAL) ou SCHED_BATCH (Patch con kolivas, si ta tache est absolument non prioritaire, genre seti@home)...
Bref, l'important c'est 1) que le programme qui tourne soit optimisé 2) parametrer ton noyau pour donner plus d'importance à ce même programme. Et à moins que ton programme depende d'une entree sortie sur un quelconque périphérique, à même code noyau et machine et code user, le fait de changer de compilo pour le noyau n'apportera pas grand chose.
Exemple:
xvidcore 1.1-cvs sur un noyau vanilla (decompression d'une sequence mpeg4): 215s
xvidcore 1.1-cvs sur un noyau con kolivas buggé dans sa gestion des time slice (vers les 2.6.7-ckX): 187s
xvidcore 1.1-cvs noyau vanilla, les deux choses compilés avec des options "alacon" genre -O9 -fplein-de-trucs-toussa, 213s.
Le gain de perf n'etait pas du a un chgt de compilo, mais bien au fait que le scheduler allouait des timeslices trop importants aux taches gourmandes en CPU (laissant ainsi les autres taches sans CPU... il s'agissait d'un bug), mais c'est pour te montrer que l'algorithmie donne des résultats plus "voyants" que l'optimisation brute par chgt de compilo/options.