Laurent J a écrit 2933 commentaires

En plus, de l'aide est explicitement demandé pour corrigé ce bug. Bref, toute contribution est la bienvenue.

Les développeurs ne sont pas non plus des machines. Ce genre de bug, c'est typiquement un bug qui a été "oublié" au fil du temps. Pas d'une mauvaise volonté, mais parce que les évolutions à faire dans le logiciel ont fait qu'effectivement, à force d'avoir d'autres priorités, ben on l'oublie. Y en a pas mal des bugs "oublié". Et à force, certains deviennent même complètement obsolète, ou ont été "corrigé" implicitement par d'autres évolutions/corrections. J'en ai déjà fermé des bugs comme ça.

Et si ce bug a été oublié, c'est qu'il semble que finalement ce ne soit pas un problème pour la majorité des utilisateurs non-windows. Si ça l'est, pourquoi alors aucune de ces personnes ne relance le bug ? Ou même tente de le corriger... Par exemple, je n'ai pas l'impression que tu ais posté un commentaire dessus par exemple, rien que pour signaler que le bug existe toujours (puisque ce problème semble vraiment t'ennuyer).

> Tout le monde sait que la MoFo ne se fout pas de Linux,

Ça n'a pas l'air d'être le cas. Fait une recherche sur linuxfr, tu verras.

>gérer des EULA vs corriger la fenêtre d'ouverture des binaires pour ne pas aller chercher dans /usr/bin.

Gérer les EULA, ce n'est pas important ? (vu le ramdam que ça fait , je doute que cela ne le soit pas) Et conçernant cette histoire d'ouverture de binaire, c'est quoi ? C'est répertorié au moins dans le bugzilla ? Es tu sûr que personne ne s'en occupe ? Es tu sûr que ce n'est pas un problème dans ta distrib ? (personnellement, j'en ai jamais entendu parlé, mais faut dire aussi que je ne lance jamais de binaire directement à partir de mon navigateur)

>j'ai été frappé des discussions autour des fuites de mémoire de Phoenix, retrouvé dans Firebird, puis dans Firefox

Peut être y avait-il des choses plus importante à faire. À l'époque de Firefox < 1.0, l'équipe de dev à temps plein était TRÈS réduite, 4-5 développeurs à tout casser (sans parler que la majorité des contributeurs étaient plus focalisé sur la suite Mozilla). Et puis faut arrêter de focaliser sur les fuites mémoires, il y en avait, oui, mais pas non plus des masses (si cela était si catastrophique, je doute qu'il y aurait aujourd'hui 200 millions d'utilisateurs).

Vu les millions de lignes de code, il en a fallu du temps pour

1) déveloper les outils qui allaient permettre de mieux cerner la provenance des leaks
2) trouver des solutions
3) implémenter les solutions (sur, j'insiste, des millions de lignes de code)

Et tout ça, en parallèle aux autres développements, tant au niveau de l'amélioration du moteur de rendu que de l'interface utilisateur. Si les efforts avaient été concentré uniquement sur les leaks, Firefox n'aurait jamais été à 30% de part de marché aujourd'hui, mais largement en dessous, c'est certain.

Bref, Mozilla a toujours été à l'écoute de la communauté. Seulement il y a des problèmes qui ne se résolvent pas en un claquement de doigt, surtout quand il y a peu de ressources (ce qui était le cas à la naissance de Firefox, je le rappelle)

>dire que la communauté est injuste

La MoFo n'a jamais dit que la communauté était injuste. Mais peut-être confond tu la MoFo avec quelques contributeurs isolés.

Tiens, moi, par exemple, je trouve que tes propos sont injustes, sur le fait que Mozilla ne tient pas compte de ce que dit la communauté (j'y reviens). C'est pas la MoFo qui le dit, c'est MOI. Et je n'ai aucun rôle "officiel" au sein de la Mofo, de la Moco, ou même de Mozilla Europe, je ne suis qu'un simple contributeur parmis tant d'autre, donc il ne devrait y avoir aucune confusion.

> prendre en compte ce que dit la communauté... Le troisième point reste encore à améliorer largement

Tu vois, là, je trouve que tu es vraiment injuste, parce que c'est totalement faux. Mozilla prend en compte ce que dit la communauté (et il y a un bugzilla OUVERT pour ceux qui veulent vraiment communiquer les problèmes à Mozilla, et pas juste raler dans leur coin)

Mais j'ai l'impression que c'est un peu le travers de notre société actuel : quand il y a un problème, les gens veulent qu'il soit réglé de suite, ou pensent que ça peut se régler tout de suite. Mais malheureusement, un problème ne se résout rarement en un claquement de doigt. Outre le fait qu'il peut y avoir des contraintes techniques qui empêche ou complexifie la résolution (et donc qu'il faille d'abord lever ces contraintes techniques, et donc retarde la résolution du problème initial), il y aussi des contraintes de ressources, tant humaine, que financière. Et puis aussi d'autres priorités, tout les problèmes n'ont pas la même importance, même si un problème spécifique t'ennui, TOI, plus que tout autre.

Tout ça, les gens l'oublie, y compris toi semble-t-il.

Alors oui, il y a des améliorations encore à faire (et je le dis dans le journal), mais un peu de patience, les contributeurs y travaillent, depuis toujours, parce qu'ils aiment leur projet. Et si tu trouves que ça ne va pas assez vite, pas de souci : poste tes patches sur http://bugzilla.mozilla.org .

>soit je suis parano ou j'ai l'esprit mal tourné.

oui, tu es parano, et tu as l'esprit mal tourné, et tu joue très mal avec les mots. Relis le journal. Je n'ai pas parlé de Mozilla dans linux, mais de "l'implication de Mozilla dans les projets autour de Linux", ou encore "l'implication de Mozilla dans le monde Linux". bon, il y a peut être le titre qui te dérange, mais nous sommes ici sur un site parlant de linux, et surtout je faisais référence à des commentaires de linuxiens.

Toutefois, par ces termes, il ne me semble pas avoir fait de discrimination vis à vis des autres os libre. Et ceux qui connaissent bien le libre, savent que quand on parle d'"implication dans des projets autour de linux", cela concerne aussi les autres OS libres, puisque bon nombre de ces projets sont aussi utilisés par ailleurs (en plus j'ai donné la liste, donc bon, quand on connait les projets...).

>Autant pour "un utilisateur Linux depuis le siècle dernier", ça fait preuve d'une grande inculture, soit d'un total manque de considération envers les termes libres et ce qu'ils représentent

Rien à fiche de ce que tu peux penser de moi. Mais franchement, poser un avis aussi tranché sur les compétences de quelqu'un, sur deux mots qu'il a écrit, c'est vraiment très petit. Qui es-tu pour juger de mon niveau de culture ? On se connait ?

> Encore une fois je peux me tromper,

Quand on doute de la compréhension d'un texte, on évite alors de porter des jugements aussi radicaux comme sur "le niveau de culture" ou encore d'un soit-disant "manque de considération envers les termes libres".

Je ne met pas Mac dans le même panier. C'était juste pour montrer que la plupart des devs n'utilisent pas Windows. Or dans bien des commentaires dont je fais allusion, on reprochait Mozilla de délaisser Linux au profit de Windows.

> qu'il faut le faire que pour leurs intranets

Là je dirais que c'est un problème de l'intranet : les responsables informatiques n'ont qu'à installer le certificat racine des sites intranet sur les postes de travail.

> vu l'etroite impliquation de JavaScript a avec le DOM

Il n'y a aucune implication de Javascript avec le DOM. Je pense que tu confond le langage javascript, avec l'API fourni par l'outil embarquant le moteur (Firefox par exemple).

Le langage Javascript inclus certes, quelques objets de bases (Array, Math etc..) mais le DOM ne fait pas parti du langage Javascript.

Le moteur javascript Seamonkey (comme d'autres je suppose) possède une API C externe permettant de déclarer dans un contexte javascript un ensemble d'objets, ceux que l'on veut, et c'est ce que fait Firefox, en déclarant les objets DOM. Et c'est ce que font les autres applications pour intégrer leur propre API (en claire, pour rendre scriptable leurs API internes)

Y a le même principe dans d'autres langages, comme Python ou PHP, où via des "bindings" on peut accéder à des libs tierces.

non, je ne parle pas de cacert, mais de startCom http://www.startssl.com/ (je viens de retrouver :-) ). Et je crois que parmis les autres autorités reconnu dans Firefox, il y en a des pas trop cher (en tout cas, à portée d'une bourse d'une association...)

Si j'ai bien suivi les débats là dessus, il n'y aura pas de changements fondamentaux dans ce processus. Pas de compromis avec la sécurité.

Mais bon, la 3.1 ne sort qu'à la fin de l'année-debut 2009, donc ça peut encore changer..

Sinon, procure-toi un certificat certifié par un organisme certifié de certification :-) (y en a un qui en file des gratos parmis ceux reconnu par Firefox, mais j'ai plus le nom)

Il y a un port QT (avec qt 4.4) de Firefox 3.1, c'est une contribution de Nokia. Il est pour l'instant plus déstiné aux mobiles, et j'ai remarqué qu'il y a encore des bugs pour le desktop "classique" (ça a peut être été corrigé depuis quelques semaines). Toute contribution est la bienvenue.

http://dot.kde.org/1218543988/

>oui, désolé de vous le dire les gentils lutins développeurs PHP mais votre langage préféré ne disposant pas de serveur d'application, le parsing des fichiers XML est à refaire à chaque requête

C'est pas parce que des frameworks utilisent XML pour certaines choses, qu'ils lisent les lisent à chaque requête. Jelix par exemple traduisent ces fichiers en classe PHP, à la volée, et mis dans des fichiers de caches. Tu vas me dire, pourquoi du XML alors ?

* avec xml, on est plus dans un processus déclaratif que programmatif : on peut donc définir certaines choses plus simplement, plus intuitivement (et derrière le PHP généré peut être complexe à souhait, c'est pas un problème)
* avec des fichiers XML : ça peut être généré et retravaillé facilement par des outils tiers. Ex, un fichier de déclaration de formulaire en XML : on peut avoir un plugin dans eclipse pour générer et modifier un formulaire en quelques cliques de souris. Va donc faire un outil qui arrive à modifier du PHP sans tout casser (même avec une API de reflexion...)
* certains se plaignent que le XML, c'est chiant à éditer à la main : à ceux là, je leur dis qu'il y a pléthore d'éditeur XML qui facilite l'édition de ces fichiers, pour peux que l'on fournisse les schemas. Et dans Jelix, on les fournis (en RelaxNG).

Bref, faut arrêter avec le XML bla bla c'est lourd bla bla c'est verbeux. Si on utilise les outils qui vont bien, et si le framework utilise le XML d'une manière intelligente, il n'y a aucun soucis.

Et puis, il faut pas oublier que créer une appli web, c'est généré du contenu XML (XHTML) ou SGML...

Ah ? leurs data-centers, et tout les cables qui en sort, c'est pas à eux ??? C'est une blague ?

PS: je n'ai ni actions ni machines chez OVH.

Euh... Non, tu ne fais pas que louer un serveur. Tu loue aussi de la bande passante. Tu payes pour avoir le droit de faire passer des informations dans les tuyaux d'OVH.

Et OVH fait ce qu'il veut de ses tuyaux. CQFD.


Note que c'est la même chose chez Dedibox. Des mecs qui utilisent les machines comme relay TOR ont eu leur compte fermé

(surtout que TOR, ça pompe pas mal aussi en bande passante...)

bon, déçu. le mot linux n'a même pas été prononcé une seule fois. Pas d'allusion au système d'exploitation. Visiblement, ils n'ont pas jugé utile d'intégrer ce qu'ils ont tourné dans les locaux de mandriva...

>En fait il convertit directement le JavaScript en langage machine (sans représentation intermédiaire, genre bytecode).

Si j'ai bien compris, c'est ce que fait aussi TraceMonkey, le nouveau moteur de FF 3.1 (au départ, je croyais qu'il convertissait en bytecode mais apparement non).

> Il y a quelques semaines quand Mozilla a expliqué que Firefox 3.1 améliorerai fortement les performances Javascript j'avais pensé que c'est une bonne nouvelle, mais que ça n'allait pas changer ma vie

Je ne sais pas si cette nouvelle va changer ta vie mais la voilà : Le moteur JS de Chrome, même si il est très bien codé de l'aveu même de Brendan Eich (l'inventeur de javascript et le createur du moteur js de mozilla), celui de Firefox 3.1 reste toujours devant celui de Chrome au niveau des perfs bruts du moteur js (tests sunspider).

http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac(...)

mais on a encore du boulot tout de même sur le DOM:

http://ejohn.org/blog/javascript-performance-rundown/

Mais on n'a pas dit notre dernier mot :-)

Qu'il y ait ce nouveau navigateur est génial : ca fait un 3ieme concurrent (et quel concurrent !) après opera et safari ( non je ne met pas IE dans le lot, le challenge est trop facile :-) ). Ce qui est particulièrement excitant et motivant :-)

Oh le gros troll


> a Google comme moteur de recherche par défaut

Et ? Il n'est pas le seul dans la liste des moteurs de recherche. Et puis grâce à Google, Mozilla permet d'avoir suffisement de financement pour développer Firefox et autres projets.

> utilise le "safe-browsing" qui va dire en gros à google toutes les adresses que vous allez visiter (mais c'est pour votre bien, hein)

Ou là, le gros FUD de la mort qui tue. Absolument faux. Désinformation totale.

> à une époque donnait une page google avec des liens redirigés et non directs

Jamais vu ça. M'enfin si c'est vrai, faut se plaindre à google, pas à Mozilla.

>Processing est un langage open source basé sur java

"basé", c'est un peu vite dit. Il a surtout une implémentation en java.

Il existe aussi une implémentation en javascript réalisée par John Resig (monsieur jQuery) :

http://ejohn.org/blog/processingjs/
http://ejohn.org/blog/overview-of-processing/

Pas besoin d'installer java, un browser (très récent) suffit :-)

Que ça peut être jouissif de pouvoir enfin moinsser certain journaux :-)

Je suis du même avis, ça m'embête de devoir reinstaller tout un système pour juste avoir les derniers logiciels "utilisateurs" (c'est pour ça d'ailleurs que j'utilise le binaire officiel de Firefox plutôt que celui de la distrib).

Cependant, le problème de cette idée de fournir ces logiciels en backport, c'est que ça demande du temps. Et les mainteneurs de paquets ont déjà assez de boulot comme ça pour mettre à jour les paquets des versions en développement des distribs.

Et je ne parle pas des backports sur les version n-2, n-3 des distribs, la charge de travail augmentant alors très rapidement (il faut avoir une machine avec ces vieilles distribs, probablement patcher le nouveau logiciel pour qu'il puisse encore fonctionner sur la vieille distrib etc...)

Bref, à mon avis, si les distribs ne font pas vraiment, c'est plus par manque de ressources qu'autre chose.

Coçernant Tamarin, c'est simple, les améliorations qui viennent d'être apportées, c'est un morceau de Tamarin cuisiné aux petits oignons avec des morceaux d'optimisations inédites dedans :-)

ah oui, au fait, pour ta plainte sur la lenteur de ff sous linux, va te plaindre aux équipes de Xorg et/ou du binding X de Cairo, et/ou peut être aussi de Gtk, puisque ce sont les seules différences avec la version windows.

Et pour couper court aux trolls, et que ça fait pas de mal de le repeter : non, Mozilla ne s'en fout pas de la plateforme linux (avec la version mobile de FF, ce serait trop con :-)). Les développeurs de Mozilla qui sont sous windows sont très peu nombreux, j'ai pu le constater au Mozilla Summit il y a quelques semaines (une majorité sont sur Mac cependant, en multiboot souvent pour pouvoir tester sur les autres plateformes, et pas mal sont sous linux).

Tout ce qui est en javascript dans Firefox (donc l'interface et quelques composants XPCom), sera bien entendu plus rapide. Tout dépend en fait ce que ça fait exactement, puisque les optimisations en questions sont des optimisations à la volée du code avant son execution proprement dit (en très gros, parce que j'avoue ne pas avoir tout compris, les améliorations en questions sont issues de recherches assez poussées de grosses têtes en université, et que parait-il, ce genre d'optimisation est l'avenir dans les interpréteurs de langage, les compilateurs en bytecode et cie...)

Oups désolé, j'ai un peu trop fait le raccourci dans ma tête "pour linux donc libre" :-)