pascalc a écrit 79 commentaires

Pour info, PHP 5.3 est encore en maintenance de sécurité pour deux ou trois mois seulement, sont support sera totalement abandonné à la sortie de la version 5.6 dans la beta1 est en préparation. D'ailleurs même les versions de maintenance de sécurité fournies par PHP en sont à 5.3.27. Personnellement je ne fais pas confiance à une distro qui continue à packager des versions de PHP de l'époque de Cro Magnon :)
Au moins sur Debian on a au minimum 5.4

Et pour toute version moderne de php, ça se teste sans Apache avec le serveur de dev intégré dans PHP:
git clone https://github.com/fguillot/kanboard.git
cd kanboard
php -S localhost:8080

et voilà !

Après, je peux être d'accord avec toi qu'un serveur de démo pour se faire une idée c'est une bonne idée, mais faut pas non plus dire que c'est insurmontable à tester, ça m'a pris moins de 30 secondes…

Dans la version française de la page, il est indiqué ceci :

«  Outre de nombreux particuliers, il est utilisé par un nombre croissant d'organisations, de France Télévision à Mozilla
Europe en passant par Opquast, qui utilisent ses fonctionnalités pour résoudre leurs problématiques de publication directe,
et se reconnaissent dans les valeurs défendues dans ce projet. »

Où est l'implication de ces organisations dans le projet ?

(note: je bosse pour Mozilla mais là je parle en mon nom, pas au nom de mon employeur)

Alors je vais te répondre en ce qui concerne Mozilla puisque Mozilla Europe est cité. Tout d'abord je rappelle tout de même que Mozilla Europe, ancienne association loi 1901, a été dissoute il y a déjà deux ans et que Mozilla n'utilise pas Dotclear mais Wordpress pour ses blogs, par contre plusieurs contributeurs francophones de Mozilla utilisent Dotclear (moi le premier) et MozFR.org, le site communautaire Mozilla francophone l'utilise aussi (vu que je l'y ai installé ;) )

Mozilla donc n'utilise pas Dotclear, mais deux employés Mozilla de Paris (julienw et moi) avons décidé de filer un coup de main au projet sur des aspects communautaires et organisationnels pour le moment. Pourquoi ? Parce qu'on pense que ça vaut le coup et parce qu'aider les projets qu'on utilise et qui nous sont chers, c'est à mon sens ne B.A BA du libre. Nous sommes d'ailleurs en train de préparer une rencontre Dotclear pour fin Septembre qui aura lieu dans les locaux de Mozilla Paris.

J'ajouterais que toutes les bonnes volontés sont les bienvenues, il s'est créé une vrai dynamique sur la liste de dev avec un total de 270 (!) messages juste aujourd'hui. Plein de gens qui veulent aider dans plein de domaines (code, doc, marketing, serveur, bêta-test, design…). http://ml.dotclear.net/listinfo/dev

Ça montre que la communauté Dotclear est bien plus grande que ce que beaucoup pensaient, que les gens sont attachés à ce projet et qu'il y a un gros potentiel de second soufle.

Concernant ta question initiale, je pense y avoir répondu pour Mozilla, maintenant je te retourne la question, penses-tu faire quelque chose pour aider Dotclear à rebondir ? ;)

Le changement d'User Agent a été annulé avec la 17.0.1 à cause des régressions dy type de celles de FCKEditor, c'est l'une des principales raisons de la 17.0.1, ces problèmes de compatibilité n'ont pas été rapportés par les bêta-testeurs (vu que les testeurs sont pour beaucoup des geeks, ils ont tendance à aller sur les nouveaux sites à la mode écrits récemment et qui ne font pas d'UA sniffing).

Pas de problème pour avoir le client en 1.7 et le serveur en 1.6, c'est prévu pour (voir mon message précédent) :
http://subversion.apache.org/docs/release-notes/1.7.html#compatibility

Tu ne bénéficies évidemment que des gains côté client, pas côté serveur mais dans mon cas, les gains sont très appréciables.

D'après les notes de version, oui tu bénéficierais des avantages côté client:
http://subversion.apache.org/docs/release-notes/1.7.html

Mai bon, vu que 1.4.x et 1.5.x ne sont plus des versions supportées, ça serait probablement à tester préalablement.

J'ai compilé svn 1.7 hier car je travaille sur de nombreux projets sous SVN et j'en suis très satisfait, les améliorations en termes de rapidité sur des dépôts très volumineux (dizaines de milliers de fichiers et dossiers) sont énormes grâce à la modernisation du format de dépôt local (facteur 10 pour moi, je passe d'une à deux minutes pour un svn up à quelques secondes). Ce qui est vraiment bien c'est que je bénéficie du gros des améliorations alors que le serveur sur lequel je travaille est toujours en 1.6 et ne migrera probablement pas avant longtemps. TortoiseSVN a aussi été mis à jour pour mes contributeurs sous Windows et ils sont apparemment aussi très contents des gains de perf.

Si votre serveur est en 1.6, n'hésitez donc pas à passer votre client en 1.7, inutile d'attendre une migration en 1.7 des dépôts :)

Je ne sais pas d'où ça sort, mais les nightlies de Firefox ne cachent pas www, seulement http:// et je n'ai pas vu de bug à ce sujet, source ?

argument débile (comme ta question remarque).

Tu tapes https:// devant l'url

Tu as rapporté ton bug dans bugzilla ?

>Même Mozilla n'a pas intégré le support de WebM dans une version finie.

Firefox 4 l'intègre par défaut, des centaines de millions d'internautes auront dans les mois qui viennent un lecteur webm sur leur machine.

C'est à mon avis un des problèmes majeurs de Linux, les linuxiens ne veulent plus utiliser que des logiciels dans les dépôts, donc ils ne remontent les bugs que sur les versions finales ou dans le meilleur des cas en toute fin de cycle de développement alors que les Windowsiens et Macqueux remontent les bugs dès le début du développement.

Pour des logiciels avec des cycles de release rapides comme Firefox, les bugs rapportés par les Linuxiens (quand ils sont renvoyés upstream par les distros, ce qui est un autre problème...), le sont sur des branches en fin de vie, souvent trop tard donc.

Il y a déjà peu de linuxiens, mais ceux qui testent, rapportent des bugs et font des patchs sont devenus rarissimes et cela pour tous les logiciels libres. A la limite, si on veut avoir des bêta testeurs aujourd'hui, il faut penser dès le départ à faire une version Windows sinon c'est mort.

Super ta mentalité et le mépris affiché pour ceux qui font du bêta test, ça donne vachement envie de te connaître...

C'est ridicule de prendre les buillds 64 bits expérimentaux, s'ils ne sont pas mis en avant par mozilla c'est qu'ils ne sont pas prêts, et c'est bien pour ça que seuls les seuls builds officiels proposés au téléchargement sont les 32 bits qui eux bénéficient de meilleures perfs et d'une meilleure stabilité.

Euh, désolé mais les perfs relatives entre Chrome et Firefox sur ta machine ne sont pas *du tout* les mêmes que sur ma machine ni les mêmes que celles que je constate sur les machines autour de moi quel que soit le système ou la configuration matérielle.

Par ailleurs, tu as présenté ton article comme une comparaison objective et scientifique des performances de Firefox par rapport à Chrome, hors ce n'est clairement pas le cas et ça aurait été bien de le mettre en préambule.

Je te rappelle que sur une machine très équivalente à la tienne avec Firefox qui tourne dans un XP virtualisé, j'éxplose les perfs de ta machine sous Firefox.

Au passage, chez moi la version de dev de Chrome 7 a les mêmes perfs que les nightlies de Chromium et est nettement plus rapide que la version stable de Chrome (350ms versus 550 pour la stable), donc même pour Chrome tes résultats sont douteux.

avec des profils propres et séparés pour 3.6 et trunk?

Oui, on les compile déjà pour les nightlies d'ailleurs:
http://nightly.mozilla.org/

On va avoir le JIT sur 64 bits aussi avec Fx4, mais effectivement ce n'est pas encore activé par défaut donc si Patrick est sur un XP en 64 bits, il ne bénéficie pas des perfs de la compilation JIT de 3.6 et 4.0pre. Patrick tu es en 64 bits?

Tant qu'à utiliser un truc en constant développement comme Chromium, pourquoi ne pas utiliser une version de développement de Firefox ?

>Dommage que Firefox 4 ne soit pas utilisable sur gnu/linux, sinon je l'utiliserai !

Qu'est-ce que c'est que cette histoire de pas utilisable sous Linux ? Ca marche très bien, la preuve je l'utilise pour te répondre là !! :)

Nvidia et trunk (4.0b6pre), ceci dit ça fait plusieurs mois que toutes les démos que je vois tourner pour webgl tournent chez moi

ça marche très bien chez moi webGL, tu as mis l'option webgl.enabled_for_all_sites à true?

Le différentiel sur ma propre machine entre Chromium et Firefox n'a rien à voir avec le tien, et on parle là de navigateurs sur la même machine, sous Ubuntu pas sous Windows.

Pour le fun, j'ai lancé Firefox Trunk dans un XP à l'intérieur d'une VM sur cette même machine et même là, avec des perfs qui sont celles d'une VM c'est à dire très dégradées, j'ai un résultat deux fois meilleurs que les tiens (658ms).

Je veux bien que l'on ait des configs différentes mais tes résultats sont tout trois fois plus lents que les miens et restent deux fois plus lents quand je passe par une VM donc à mon avis, tu as pas le JIT activé dans tes prefs. Tu peux réessayer avec un profil vierge?

J'ai à peu près la même configuration matérielle (Core 2 duo 2,40Gz) mais des résultats différents que toi sur Sunspider tant pour 3.6 que pour 4.0trunk, par contre mes résultats Chromium sont à peu près similaires aux tiens:

Sunspider:
Firefox 3.6 : 1300ms
Firefox Trunk : 485ms
Chromium dev: 333ms

Comme tu peux le constater, l'écart est bien plus faible sur ma machine que sur la tienne entre Chromium et Firefox que ce soit la version du trunk ou celle de dev. Par ailleurs j'ai presque un facteur 3 entre Fx3.6 et 4 alors que tu n'as quà peine un facteur 2,

En fait tu as même des perfs nettement plus basses que mon collègue qui a une machine à 1,87Gz et qui a 600ms sur Sunspider!

Pour avoir des performances dégradées similaires à tes résultats, il faut que le JIT soit désactivé chez moi, ce qui arrive quand on installe Firebug par exemple.

La question est donc est-ce que tu as Firebug d'installé dans tes profils et est-ce que tout simplement le jit est activé dans about:config ? :)

euhh, chez moi la vitesse de démarrage est de moins de deux secondes à froid et quasiment instantanné à chaud sur une machine bas de gamme de plus d'un an, donc c'est largement amélioré !!