Matthew Szulik quitte Red Hat
Le CEO et président de Red Hat Matthew Szulik a décidé d'abandonner ses fonctions pour des raisons de santé de sa famille. Il reste toutefois à la tête du directoire. Il est remplacé par James Whitehurst (COO de Delta Airlines).
Tests de performance JavaScript dans les navigateurs
Un benchmark JavaScript a été réalisé à l'aide de SunSpider du projet WebKit. Les navigateurs testés sont Opera 9.5, Safari 3, IE7 et Firefox 2. La machine était une dual-core 3.0 GHz Core 2 Duo munie de 4 Gio de RAM et de... argh Windows Vista 32-bit. Firefox 3.0 beta 2 apporte de grandes améliorations.
Valgrind 3.3.0
La célèbre suite d'outils libres de profiling et de débogage est passée en version 3.3.0. Helgrind et Massif ont été revus en profondeur, Cachegrind et Memcheck ont été améliorés, Omega et DRD sont deux outils expérimentaux qui font leur apparition, la documentation a été réorganisée, et on assiste à des gains en terme de mise à l'échelle.
Les petites brèves de LinuxFR : trois nouvelles toutes simples, regroupées, qui n'auraient pas matière à être développées jusqu'à en faire une dépêche à part entière. Vous pouvez contribuer des dépêches sur linuxfr.org/submit.html.
Vu l'utilisation massive de JavaScript (avec web 2.0, ajax, ...) au lieu d'interpréter le javascript (ce qui doit être fait par la plupart des navigateurs aujourd'hui), ne pourrait ton pas faire du JIT (compilation à la volé du code http://fr.wikipedia.org/wiki/Compilation_%C3%A0_la_vol%C3%A9(...) ).
> Firefox 3.0 beta 2 apporte de grandes améliorations.
Au passage, je signale que la consultation des pages de linuxfr rame horriblement avec Firefox 3.0 (beta2).
La navigation et le scroll des pages est très très lourd et lent, lorsqu'on est loggué (nb : je n'ai aucune extension active, et n'ai pas ce problème avec Firefox 2.0). C'est un bug de Firefox, ou un problème dans le js de dflp ?
Hmm, nous n'utilisons pas les mêmes versions en fait (et visiblement les devs / gros patchs continuent d'aller bon train entre chaque béta de FF 3). Ici :
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2
Ce qui n'exclue pas bien entendu la possibilité d'un problème chez moi (mais dans ce cas je ne saurais expliquer pourquoi le FF 2.0 standard d'Ubuntu sur la même machine n'a pas ce problème avec dflp, ni pourquoi les autres sites chargés en js que je fréquente habituellement n'ont pas ce problème avec mon FF 3.0b2).
Bon de toutes façons, si ce n'est pas un problème avec mon setup particulier, les rapports de bugs ne tarderont pas après la sortie de FF 3.0 : j'y verrai plus clair le moment venu.
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
tout se passe bien. Peut-être un problème avec la version Linux ?
C'est bizarre quand même ces dates qui diffèrent. Les dev de Firefox utiliseraient des versions différentes de Gecko dans les builds Linux et Windows ?
PS: "Windows NT 5.1" => pas taper, je suis au boulot
Domage que la breve valgrind ne soit pas une vrai news.
Ca aurrait été l'ocasion de parler de se formidable outil de débugage et de profilage, qui permet de trouver très rapidement des problèmes dans vos programmes C ou C++.
Basé sur une technique d'instrumentation just in time (il modifie le code machine pour appeler ses propres routines).
A la base, valgrind (memcheck) est un outil de détection d'accès illégaux a la mémoire. Il détecte les fuites de mémoire (memory leak), les accès après libération de pointeur, allocation trop courtes et j'en passe.
La puissance de son outil JIT permet de créer une multitude d'outils de debugages.
Helgrind permet de détecter les problèmes liés au multithread.
Massif est un profileur de memoire, il permet de détailler combien de mémoire prends votre programme
Callgrind est un outil de profilage JIT (a la difference de gprof, pas besoin de compiler avec des options spéciales)
Cache grind permet de détecter les problemes de performances liés aux caches miss et autres branch prediction.
Ces deux outils disposent d'un outil tiers appelé kcachegrind, qui permet de visualiser tout ca. La triplette est en fait pour moi le meilleur outil de profiling que je connaisse.
Valgrind permet aussi de créer relativement facilement ses propres outils d'instrumentations.
Le seul problème de valgrind est qu'il est fortement lié a l'architecture i386. les ports pour d'autres architectures sont en cours, mais un peu moins actifs, ca marche pas aussi bien.
Le seul problème de valgrind est qu'il est fortement lié a l'architecture i386.
Il a l'air de tourner pas mal sur ppc.
Par contre valgrind ralenti les programmes ce qui peut changer le comportement (par exemple dans le cas multi thread).
Je crois aussi que tout est sérialisé (pas de SMP).
C'est pas l'outil parfais, mais il reste quand même formidable.
J'avais vu dans la doc que tout est effectivement sérialisé : valgrind émule un CPU et ne fait tourner qu'un thread/process à la fois, mais il les croise (interleave) beaucoup plus fréquemment qu'un CPU normal, ce qui permet quand même de détecter les bugs de synchronisation.
Developer-visible changes:
- Internally, the code base has been further factorised and abstractified, particularly with respect to support for non-Linux OSs.
Bientôt peut être un port récent et stable sur BSD, valgrind étant le seul outil indisponible sur cette plateforme et la raison pour laquelle j'ai encore Slackware au taf :)
(oui je sais, j'ai qu'à envoyer des patchs et toussa, surtout maintenant que j'ai fini zelda je vais avoir un peu de temps libre)
J'aime bien les petites brèves. C'est une excellente initiative.
Matthew Szulik aurait mérité une "vraie" dépêche en première page. Mais le personne est discret et probablement que personne n'a fait cette "vraie" dépêche (en tout cas pas moi :-)).
C'est tout de même le PDG depuis 10 ans de la distribution la plus importante, souvent la plus innovante (avec de sérieuses prises de risque pour faire avancer le libre), qui a fait Fedora, qui a le plus contribué au libre (au moins au niveau code), qui a acheté plein de boite pour mettre le code en GPL (près et peut-être plus de 200 millions de $), qui a dit "chiche" pour OLPC, qui a systèmatiquement dit non aux accords à la con type MS/Novell, qui a fait que Red Hat est toujours resté commauté friendly (n'est-ce pas Centos et autres clones), etc...
Il mérite mieux que d'être noyé dans des brèves de seconde page. M'enfin, il ne doit pas s'en plaindre. Le vedettariat n'était pas son truc.
Espérons que son successeur porte aussi fort le libre que lui.
ça me semble intéressant de pouvoir suivre l' évolution des plans de carrières de ces personnels (en général) qui ne sont pas à l' origine des pro-libres, mais qui travaillent et ont travaillés pour un socièté éditrice de LL, et aussi largement contribué à faire avancer le schmilblick.
(et ne vais pas remettre une couche sur ce que tu dit d' elle, de redhat, étant 100% d' accord)
A titre informatif ça serait vraiment très intéressant. (c' est clair que c' est peut être pas la vocation de linuxfr de parler de ça. Mais en regrettant aussi que personne d' autres ne le fasse)
dit IsNotGood, tu te sentirai pour nous faire une dépêche sur ce sujet que tu maitrises ? Merci d' avance.
# JavaScript
Posté par M . Évalué à 2.
On me souffle à l'oreille que tamarin (http://www.mozilla.org/projects/tamarin/) devrait pouvoir faire du JIT.
Quelqu'un sait il ou tamarin en est ?
PS : pourquoi faire des bench sur de tel montre au lieu de config moyenne.
[^] # Re: JavaScript
Posté par GCN (site web personnel) . Évalué à 1.
J'ai déjà vu des personnes fâchées avec les "S" mais pas à ce point là :).
Hop --> [] !
[^] # Re: JavaScript
Posté par herodiade . Évalué à 2.
Au passage, je signale que la consultation des pages de linuxfr rame horriblement avec Firefox 3.0 (beta2).
La navigation et le scroll des pages est très très lourd et lent, lorsqu'on est loggué (nb : je n'ai aucune extension active, et n'ai pas ce problème avec Firefox 2.0). C'est un bug de Firefox, ou un problème dans le js de dflp ?
[^] # Re: JavaScript
Posté par NeoX . Évalué à 1.
chez moi avec :
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a8) Gecko/2007100619 GranParadiso/3.0a8
ca tourne nickel
[^] # Re: JavaScript
Posté par herodiade . Évalué à 1.
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2
Ce qui n'exclue pas bien entendu la possibilité d'un problème chez moi (mais dans ce cas je ne saurais expliquer pourquoi le FF 2.0 standard d'Ubuntu sur la même machine n'a pas ce problème avec dflp, ni pourquoi les autres sites chargés en js que je fréquente habituellement n'ont pas ce problème avec mon FF 3.0b2).
Bon de toutes façons, si ce n'est pas un problème avec mon setup particulier, les rapports de bugs ne tarderont pas après la sortie de FF 3.0 : j'y verrai plus clair le moment venu.
[^] # Re: JavaScript
Posté par doupatex . Évalué à 1.
Ici avec :
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
tout se passe bien. Peut-être un problème avec la version Linux ?
C'est bizarre quand même ces dates qui diffèrent. Les dev de Firefox utiliseraient des versions différentes de Gecko dans les builds Linux et Windows ?
PS: "Windows NT 5.1" => pas taper, je suis au boulot
[^] # Re: JavaScript
Posté par NeoX . Évalué à 1.
"nightly build"
# Et en Français ?
Posté par TazForEver . Évalué à 1.
# une news valgrind!
Posté par Pierre . Évalué à 0.
Ca aurrait été l'ocasion de parler de se formidable outil de débugage et de profilage, qui permet de trouver très rapidement des problèmes dans vos programmes C ou C++.
Basé sur une technique d'instrumentation just in time (il modifie le code machine pour appeler ses propres routines).
A la base, valgrind (memcheck) est un outil de détection d'accès illégaux a la mémoire. Il détecte les fuites de mémoire (memory leak), les accès après libération de pointeur, allocation trop courtes et j'en passe.
La puissance de son outil JIT permet de créer une multitude d'outils de debugages.
Helgrind permet de détecter les problèmes liés au multithread.
Massif est un profileur de memoire, il permet de détailler combien de mémoire prends votre programme
Callgrind est un outil de profilage JIT (a la difference de gprof, pas besoin de compiler avec des options spéciales)
Cache grind permet de détecter les problemes de performances liés aux caches miss et autres branch prediction.
Ces deux outils disposent d'un outil tiers appelé kcachegrind, qui permet de visualiser tout ca. La triplette est en fait pour moi le meilleur outil de profiling que je connaisse.
Valgrind permet aussi de créer relativement facilement ses propres outils d'instrumentations.
Le seul problème de valgrind est qu'il est fortement lié a l'architecture i386. les ports pour d'autres architectures sont en cours, mais un peu moins actifs, ca marche pas aussi bien.
[^] # Re: une news valgrind!
Posté par Bruno Michel (site web personnel) . Évalué à 3.
C'est par là : https://linuxfr.org/submit.html
[^] # Re: une news valgrind!
Posté par M . Évalué à 2.
Il a l'air de tourner pas mal sur ppc.
Par contre valgrind ralenti les programmes ce qui peut changer le comportement (par exemple dans le cas multi thread).
Je crois aussi que tout est sérialisé (pas de SMP).
C'est pas l'outil parfais, mais il reste quand même formidable.
[^] # Re: une news valgrind!
Posté par Gabriel Linder . Évalué à 1.
[^] # Re: une news valgrind!
Posté par Gabriel Linder . Évalué à 1.
Developer-visible changes:
- Internally, the code base has been further factorised and abstractified, particularly with respect to support for non-Linux OSs.
Bientôt peut être un port récent et stable sur BSD, valgrind étant le seul outil indisponible sur cette plateforme et la raison pour laquelle j'ai encore Slackware au taf :)
(oui je sais, j'ai qu'à envoyer des patchs et toussa, surtout maintenant que j'ai fini zelda je vais avoir un peu de temps libre)
[^] # Re: une news valgrind!
Posté par M . Évalué à 2.
[^] # Re: une news valgrind!
Posté par Troy McClure (site web personnel) . Évalué à 2.
# Petites brèves
Posté par IsNotGood . Évalué à 3.
Matthew Szulik aurait mérité une "vraie" dépêche en première page. Mais le personne est discret et probablement que personne n'a fait cette "vraie" dépêche (en tout cas pas moi :-)).
C'est tout de même le PDG depuis 10 ans de la distribution la plus importante, souvent la plus innovante (avec de sérieuses prises de risque pour faire avancer le libre), qui a fait Fedora, qui a le plus contribué au libre (au moins au niveau code), qui a acheté plein de boite pour mettre le code en GPL (près et peut-être plus de 200 millions de $), qui a dit "chiche" pour OLPC, qui a systèmatiquement dit non aux accords à la con type MS/Novell, qui a fait que Red Hat est toujours resté commauté friendly (n'est-ce pas Centos et autres clones), etc...
Il mérite mieux que d'être noyé dans des brèves de seconde page. M'enfin, il ne doit pas s'en plaindre. Le vedettariat n'était pas son truc.
Espérons que son successeur porte aussi fort le libre que lui.
[^] # Re: Petites brèves
Posté par bubar🦥 (Mastodon) . Évalué à 2.
ça me semble intéressant de pouvoir suivre l' évolution des plans de carrières de ces personnels (en général) qui ne sont pas à l' origine des pro-libres, mais qui travaillent et ont travaillés pour un socièté éditrice de LL, et aussi largement contribué à faire avancer le schmilblick.
(et ne vais pas remettre une couche sur ce que tu dit d' elle, de redhat, étant 100% d' accord)
A titre informatif ça serait vraiment très intéressant. (c' est clair que c' est peut être pas la vocation de linuxfr de parler de ça. Mais en regrettant aussi que personne d' autres ne le fasse)
dit IsNotGood, tu te sentirai pour nous faire une dépêche sur ce sujet que tu maitrises ? Merci d' avance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.