Laurent J a écrit 2933 commentaires

c'est pour montrer que linux fonctionne aussi sur le matériel de la pomme. non ?

tu veux dire que tu es jaloux de l'interface kikoolol de skype sous windows ? :-)

Personnellement, je préfère la "sobriété" de leur client linux.

Le truc qui me fait peur, c'est quid de l'avenir de la version linux. Parce que pour moi, sous linux, je n'ai pas trouvé d'équivalent qui me permettent de converser avec des user windows, mac sans problèmes (à moins que l'offre open source ait évoluée ces derniers mois).

(non, ceci n'est pas un troll)

donc effectivement, le ministère propose de désactiver des sécurités. génial.

bah si j'ai bien compris, c'est le site du ministère qui utilise une version du protocol SSL toute moisie, vulnérable...

Mais que font les admin sys de ces sites ? :-)

QML +CSS, du js, avec des composants en C++...

Aller, encore quelques petits efforts et on fera du XUL-like. Finalement, la plateforme Mozilla et XUL a de l'avenir malgré ses 12 ans d'age.. :-)

Et sinon, embarquer V8 n'est apparemment pas une super idée pour le moment (c'est le gars de Nginx qui le dit). Alors que SpiderMonkey est quasi aussi performant, et propose du javascript plus évolué (iterateur, generateur, array comprehension etc). Ceci dit, le choix de V8 est assez naturel puisque webkit est utilisé..

le souci de tmpfs en ram, c'est qu'il faut recopier toutes les sources (plusieurs megas) dans ce système de fichier, ce qui est plutôt long à faire. Et quand on y fait des modifs, faut faire une sauvegarde à chaque modif (si la machine venait à s'éteindre...).

Ou on peut y mettre le résultat de la compil, mais là le problème c'est qu'à chaque fois que tu rallumes la machine, c'est la compil tout entière qu'il faut te retaper (25min à 2h selon les machines).

bref, pas l'idéal le tmpfs je pense. (ou alors laisser allumer la machine 24/24)

et ton frigo, il fait comment pour aller commander tout seul ce qui manque ? hein ? (sauf si il est wifi)

:-)

Pendant qu'on y est, que pensez-vous de l'usage d'un SSD dans un contexte où il y a beaucoup de lecture écriture ? J'ai souvent besoin de compiler des gros trucs (genre Firefox).

C'est bien gérer maintenant les histoires de gestion d'allocations des mémoires dans le SSD, pour éviter que ce soit toujours la même partie du SSD qui soit utilisé ? ou est-ce que maintenant les composants sont suffisamment "costaud" pour durer longtemps avec des cycles lecture/écriture soutenu ?

Une idée, pour éviter d'avoir une config trop chère : c'est de prendre un SSD avec une capacité juste suffisante pour le système et les logiciels (40 ou 60 Go suffisent la plupart du temps), histoire de booster ton système, et un bon vieux DD grosse capacité pour ton home.

J'ai pas testé mais ça pourrait le faire je pense (pour les desktops)

c'est plus accessible dans le sens où :

• il n'y a pas besoin de fournir un alt.
• ça prend 2 à 4 octets, là où pour l'image + code html, ça en prend des dizaines (oui, le volume d'un fichier, ça fait parti de l'accessibilité)
• il n'y a pas que le HTML dans la vie, tout les formats de documents n'acceptent pas forcément l'incrustation d'images. Cela peut donc être utile "d'illustrer" des formats de fichiers purement textuel par exemple.

Il y a maintenant 4 depots : central, aurora, beta, release.

Central (minefield). Comme indiqué, c'est le champs de mine. C'est commit à tout va.

Aurora, c'est une image de central à un instant donné, + les corrections pour stabiliser. Au bout de 6 semaines, le code va dans la branche beta

Beta = version plutôt stable, qui est là pour débusquer les derniers bugs. De par son nom, il a une audience plus large. En fait, à chaque branche, l'audience (le nombre de personne qui veut tester) est plus grande, mais la stabilité aussi. Au bout de 6 semaines, basculement du code dans la branche release.

Release = image de la branche beta à un moment donné, c'est à dire image de la beta au moment où la beta est bonne pour être utilisé par tout le monde.

La différence avec le processus précédent (pour Firefox 4), c'est qu'il y avait seulement deux dépôts : central et la branche "beta/release". Et beta/release était fusionné avec central à interval régulier. Ce qui provoquait des "freezes" de central, c'est à dire des periodes pendant lesquels on ne pouvait commiter que des corrections ou des nouvelles fonctionnalités "bloquantes", correspondantes à la roadmap.

Avant le dev de Firefox 4, il y avait encore un autre processus de dev un peu différent avec des freezes plus contraignants encore (la branche beta/release était en fait crée seulement peu de temps avant la release).

Et donc maintenant, dans le central, il n'y a plus de freeze. On peut commiter toutes les corrections et fonctionnalités que l'on veut (enfin, qui sont reviewés). Cela veut dire que c'est la fête tout les jours pour ceux qui suivent les nightly. Les testeurs des nightlies "central" ont des nouveautés tout les jours ou toutes les semaines. miam !

En résumé : la roadmap de développement de Firefox n'est plus orienté "features", mais c'est en quelques sortes du "rolling release". Une version ne sort plus "quand une feature est prête", mais à date fixe, toutes les douzes semaines (qui correspond à la période de stabilisation).

Possesseurs d'un Ipad, rassurez-vous, vous pouvez vous aussi attacher un clavier, pour pas cher en plus. C'est juste un peu moins beau.

C'est très pratique pour poster avec ses multis.

Elle l'utilise : tous les fichiers sources produits par Mozilla et ses contributeurs, sont explicitement sous les trois licences, MPL, GPL, LGPL. À toi de choisir celle qui te convient.

Exemple tout à fait pris au hasard parmi ce qui m'est venu en tête http://mxr.mozilla.org/mozilla2.0/source/content/base/src/nsXHTMLContentSerializer.cpp

Donc voilà, c'est une grosse déception, mais surtout une grosse bêtise de ma part d'avoir confié au nuage de la mofo tant de données personnelles, sans au préalable vérifier par moi-même que cela allait fonctionner correctement.

Si tu as si peur pour tes données personnelles, la première chose à faire, c'est de ne pas les confier à un quelconque nuage. point barre. (du bons sens quoi). Quant à être parano, autant être parano jusqu'au bout.

Et donc les paranos, ils installent leur propre serveur sync. Ça fonctionne très bien aussi.

Mais il n'y a pas de raison de faire du FUD comme ça envers la MoFo (et d'être parano), tout ce que tu stockes chez eux est chiffré avec une clé que seul toi possède (même quand ça stocke sur ton propre serveur).

Et si Sync ne fonctionnait vraiment pas, ça se saurait, depuis presque 3 ans que ça existe (sous forme d'extension avant Firefox 4). Tu as à priori un problème dans l'utilisation de Sync, ça ne veut pas dire que ça ne fonctionne pas en temps normal.

la version android repose sur le même code que la version desktop, à savoir le moteur Gecko 2.0 (C++).

Ainsi toutes les amélioratoins en terme de perf, et toutes les nouveautés technologiques (html5, CSS3, SVG, SMIL et cie) que vous avez dans Firefox 4 pour desktop, vous les avez dans la version mobile.

Grosso modo, il n'y a que l'interface qui change.

Et ce n'est pas étonnant, vu que c'est super-galère d'installer une béta (hors dépôt officiel donc...) sur Linux

Ah ? ftp.mozilla.org + tar xjf, c'est compliqué ?

sans compter les pseudos classes CSS3 :valid et :invalid pour styler les champs input valides/invalides.

Les dev chez Mozilla bossent sur TOUTES les plateformes, et pour cause, une bonne partie du code est indépendant de la plateforme. De plus, il y a des dizaines de machines qui lancent les tests unitaires sur toutes les plateformes.

Maintenant, pour te donner des chiffres sur le nombre de testeurs, je ne pense pas qu'on en ait : ce sont en grande majorité des bénévoles. L'équipe QA de Mozilla n'est qu'une goutte d'eau parmi tout les testeurs.

Les testeurs donc, c'est toi, moi etc.. Et il se trouve que la majorité de rapport de bugs ont été découvert par des utilisateurs sous windows. Donc que la majorité des testeurs sont sous windows.

Il nous manque clairement donc des utilisateurs linux pour tester.

Le vrai problème aurait été de garder l'ancienne interface. À la vue du succès des interfaces "light" avec les autres navigateurs, on ne pouvait que suivre dans cette direction. Et plus c'est minimaliste, plus il est difficile de se différencier.

Là où on peut se différencier, ce sont dans les interfaces et fonctionnalités annexes, l'agencement des éléments d'interface et c'est ce qu'essaye de faire Mozilla. D'ailleurs, je trouve que Fx4 s'intègre bien mieux dans Gnome que Chromium (qui a une barre de titre horrible par exemple, ne reprenant pas le thème gtk)

non, que les téléchargements des FTPs de Mozilla et leurs miroirs (et non, Mozilla va pas imposer à toutes les distribs de mettre les mouchards qu'il faut sur leurs serveurs respectifs). Et je crois que ça ne compte que les téléchargements initiés via le site, pas les mises à jour.

La grosse majorité des évolutions : on a l'impression qu'ils reprennent ce qui existe depuis un bail sous chromium/chrome (html5, forms, webgl, bookmarks sync..)

• sync, ça existe depuis un bail avec firefox 3.5, 3.6, bien avant Chrome. C'était juste disponible sous forme d'extension (que j'utilise personnellement depuis longtemps). Et le sync de Chrome n'est pas aussi complet que celui de Firefox (pas d'history). Et avec Firefox, tu peux avoir ton propre serveur sync (que j'utilise aussi)
• webgl: c'est marrant que tu trouve que ça existe depuis longtemps dans Chrome. C'est Mozilla qui a fait la première implémentation, il y a plusieurs années de ça, (dispo sous forme d'extension) et Mozilla qui a poussé à sa normalisation.
• html5: pareil, bon nombre de truc sont dispo dans Firefox depuis.. pfiouuu, ah ba tient, depuis au moins Firefox 3. (et je ne parle pas des trucs comme canvas dispo depuis Firefox 1.5...)
• le système d'extension light Jetpack, est né lui aussi bien avant celui de Chrome.

Mozilla ? Suiveurs ? Au niveau technologique, certainement pas. C'est juste qu'ils ont des cycles de releases plus long que Chrome, et qui donne l'impression qui suivent, mais finalement non, absolument pas. Et bon nombre de trucs sont développés sous forme d'extension dans le lab de Mozilla avant leur inclusion dans les versions stables. Suffit juste de suivre l'actu Mozilla sur planet.mozilla.org pour se tenir au courant et découvrir qui sont les suiveurs ;-)

Par contre je concède qu'au niveau interface, ils suivent un peu. Quoique, y a des trucs comme Panorama (même si buggé) qu'on ne retrouve pas chez les autres.

Pour ce qui est des onglets sandboxés, ce n'était pas une priorité haute : les statistiques ont montré que les crashs étaient surtout dûs aux plugins comme flash, et donc sandboxer les plugins a suffit à pas mal réduire les crashs. Et puis l’expérience avec Chrome a montré que les onglets sandboxés, ça bouffe beaucoup plus de mémoire (Chrome est un gouffre à mémoire chez moi).

Il faudrait surtout innover

tu ne lis pas les bons sites, et faut que tu te desintox un peu du tout google ;-)

Loin derrière tout le monde, faut pas exagérer. Il n'y a que Opera qui supporte convenablement l'ensemble des types d'input, les autres n'ayant qu'un support partiel ou buggé.

Chez Mozilla, déjà on a manqué de temps (il n'y a qu'un seul développeur sur le support des formulaires html5), et d'autre part, on préfère avoir une implémentation correcte plutôt que partielle.

Et sinon, l'implementation continue d'avancer. https://bugzilla.mozilla.org/show_bug.cgi?id=344614

(et même si ça n'est pas très utilisé, Firefox est le seul navigateur à supporter les formulaires XForms via une extension)

HTML5 n'est absolument pas un dialecte XML. XHTML5 oui par contre.

à l'origine, HTML est un dialecte SGML (un truc plus vieux que le XML). HTML5 par contre a plus ou moins coupé les ponts avec SGML. C'est du SGML++. Mais absolument pas XML. La spec HTML5 d'ailleurs fait bien la distinction entre HTML5 et XHTML5. Il y a la même grammaire (mêmes elements/attributs), c'est juste la syntaxe qui change.

tu confonds avec le langage XHTML 2, qui lui a vraiment été abandonné avant qu'il soit normalisé.

XHTML est toujours là, XHTML5 fait parti de HTML5. Un simple changement de syntaxe fait la différence.