dans ce cas, moi je te dirais : je ne vois pas une seule raison de rester sous svn par rapport à Mercurial, puisque Mercurial est quasi aussi simple à utiliser que svn (les commandes se ressemblent pas mal avec svn), et fonctionne très bien sous windows.
ou à la limite, sans propose un tarif minimal, juste dire "ça coute tant par membres", et ensuite à chacun de donner en fonction de ses moyens, de ce qu'il juge etc..
Mais c'est vrai que d'avoir au moins une idée du cout, c'est je pense indispensable.
conçernant drizzle, c'est plutôt facile de forker quand on enlève plein de features.
Le truc qui m'a fait sursauter :http://drizzle.org/wiki/MySQL_Differences . Ils ont enlever les vues, les procédures stockées, les triggers, les requêtes préparées, et d'autres trucs. Bref, ils reviennent à mysql 3.
Bon, ok, c'est pour un usage plutôt spécifique (cloud computing et cie) mais bon...
oui c'est trivial. Mais il n'y a rien de spécifié dans les standards "pour faire un menu dynamique". Et vu qu'il y a mille manière de faire un menu dynamique, je vois pas pourquoi tu parles d'implémentation correcte de menu dynamique. Mais bon je pense avoir compris de travers ton premier commentaire.
>Rien n'empêche d'implémenter un draft, surtout que cela existe depuis très très longtemps 2002
C'est justement ce qui est fait dans Mozilla et Webkit. Cependant, comme c'est pas finalisé, ils ont mis leur prefixe -moz- et -webkit- (comme c'est autorisé dans la spec css), parce qu'effectivement, la spec peut changer d'ici l'etape "recommandation", et donc leur implementation ne plus correspondre avec la spec définitive (qui ne l'est toujours pas, definitive).
Maintenant, rien ne t'empêche à mettre les styles -moz-border-radius, -webkit-border-radius et même border-radius, en même temps dans ta feuille de style (comme ça, ton site sera pret ;-). Pour les autres navigateurs ne reconnaissant pas ces styles, bah tant pis, coin carré, et c'est pas un drame ;-)
>Faire un site portable est un enfer...
bah oui, et c'est pour ça que Mozilla et Webkit font la course à l'implementation des standards, car ça force les autres à suivre (en particulier IE). Et même si IE8 a encore du retard, beaucoup de progrés ont été fait, pour le bien des developeurs web.
>Je me suis contenté de t'expliquer ce que pouvait être un menu dynamique "standard". Et très humblement en plus car il y a peut-être d'autres méthodes.
Oui la méthode que tu as indiqué est celle que nous avons expliqué sur openweb.eu.org, (crée par moi et 10 autres gus dans un garage en 2003).
>dire "Firefox sait faire" ne fait pas (mais alors pas du tout) avancer le schmilblick.
Si, bien au contraire. Si IE8 (et puis avant IE7) respecte un peu mieux les standards, c'est grâce à quoi à ton avis ? Grâce au fait que Firefox respecte les standards (ou presque : disons que l'on s'efforce d'implémenter au maximum tout les standards, mais c'est un travail de longue haleine), et grâce au fait que les developpeurs gueulent après les mauvais navigateurs, qui ne fonctionnent pas comme attendu quand on utilise les standards. Ils gueulent, font pour certains le forcing à utiliser des navigateurs plus respectueux, d'où perte de marché pour les mauvais, ce qui forcent ceux-ci à réagir et à donc s'améliorer.
Et ça ne fait pas avancer le schmilblick seulement du coté des mauvais, mais aussi des "bons". Pour preuve cette deuxième guerre des navigateurs qui a démarré depuis le succés de Firefox.
Toutefois, c'est une guerre "saine", dans le sens où c'est plutôt une course à l'implémentation des standards.
Donc, oui, que "Firefox sait faire", ou même que "Webkit/Opera/Whatever sait faire", ça fait avancer le schmilblick.
Y a qu'à voir les avancées sur le support de CSS de Firefox 3.5 par rapport à 3.0 (et 3.0 par rapport à 2.5), forcées plus ou moins par les tests Acid, mais aussi par d'autres avancées dans Webkit comme les css transforms (spec qui est maintenant devenu un draft au W3C).
>Seul le respect des standards établis fera avancer le Web dans la bonne direction.
C'est justement ce qui se passe chez toutes les equipes de dev des navigateurs, IE compris.
Cependant, la spécification ne précise pas que le choix doit être persistant. Donc <mode mauvaise foi>Firefox respecte le standard de ce point de vu là</mode mauvaise foi> :-)
>Certes il n'y a pas de balise menudynamique mais il est possible d'en faire en HTML "standard"
Oui ok, mais je ne comprend pas : sous firefox, il n'y a pas besoin de faire du js pour ça, je vois donc pas où veut en venir Alenvers.
C'est certes emmerdant que dans certains navigateurs, on ne puisse toujours pas faire des choses simples et pourtant très utile, mais on ne va quand même pas arrêter d'implémenter des nouveaux trucs parce que d'autres sont à la traîne. Sinon personne n'avancerait ou n'innoverait.
Comment ça menu dynamique ? C'est quoi un menu "dynamique" pour toi ? Y a des choses en HTML "standard" ou "css" qui permettent de faire des menus dynamiques ?
>Coins arrondi
Mozilla a été le premier à implementer les coins arrondis. ça fait des années que je fais des coins arrondis en CSS. Mise à part ça, les coins arrondis ne sont pas un standard, vu que la specification est encore en brouillon...
>Feuilles de style alternatives
Firefox supporte très bien les css alternatives: menu affichage > style de la page
>Si j'ai bien compris, la personne qui maintient cette branche est un salarié de la MoFo
Plus que ça même. Pour ceux qui ont la flemme de lire son post, c'est un contributeur de longue date de valgrind.
Un premier port pour mac a été fait par un autre contributeur, employé Apple, il y a plus de 4 ans, mais ça avait été retombé plus ou moins dans l'oublie.
Nicholas a alors été embauché par Mozilla pour continuer à bosser dessus car de plus en plus de dev Mozilla sont sous Mac...
>Il m'a toujours semblé que Thunderbird était surtout un moyen pour la MoFo de prouver qu'on pouvait faire autre chose avec ses technologies (gecko, XUL ...)
pas du tout, c'est juste le descendant de la suite mozilla qui contenait browser, client mail, client irc et editeur html.
Firefox a ensuite été crée, n'ayant que la fonction navigateur. Et ne voulant plus continuer le developpement de la suite Mozilla, il a été logique de continuer à proposer une alternative de Mozilla Mail sous forme d'appli standalone : Thunderbird.
Le client irc, chatzilla, est toujours dispo sous forme d'extension pour firefox ou d'appli xulrunner.
> la cerise sur le gâteau : pouvoir définir un certains nombres de comportements ou d'options de thunderbird (voire même d'autres logiciels), avec juste une chaine de caractères simples et surtout en une seule ligne (par exemple les options "citer sous la réponse + mettre un texte alternatif aux images + autoriser un antivirus externe à scanner les messages etc" pourraient s'afficher dans une chaîne genre xDfpOKRT, automatiquement générée bien entendu,
Euh, copier le fichier prefs.js du profil (ou une partie de ce ficher, qui, je le rappelle, contient toutes les options du logiciel), ça ne serait pas plus simple ?
Je n'ai pas vérifié si c'etait une généralité, voir un "standard", mais j'ai remarqué que souvent, il suffisait d'enficher la prise avec le logo usb vers le haut, pour que ça rentre dans le bon sens....
Le développement de Gecko a débuté en 1998, mais la plupart des devs de Gecko avaient déjà une grosse expérience puisqu'ils venaient des équipes de Netscape 4 et précédent. Et puis le développement de Gecko (qui se faisait au sein de la societé Netscape), était fait par des devs à temps complets. Ce n'était pas le cas des devs de KHTML. le developpement de kHTML (tel qu'il est aujourd'hui) n'a réellement débuté qu'en 1999. À ceci il faut ajouter que Gecko, à la même époque, supportait non seulement HTML, mais aussi MATHML et surtout XUL/XBL, qui était une révolution à l'époque. Et puis certaines briques comme NSS (1) et NSPR (2) ont été reprises de feu Netscape 4.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
>c'est que l'avantage qu'il pourrait exister à faire des applis en utilisant XulRunner n'est en réalité pas du tout un avantage mais un boulet?
Si tu veux faire de l'optimisation PGO, oui. Mais c'est le même problème pour toutes les libs des systèmes linux, il me semble.
> Un peu comme il faudrait une libc pour chaque applis?
Oui. C'est pourquoi il n'y a pas d'optimisation PGO sur la libc (enfin à ce qu'il me semble). Ni sur aucune autre lib linux. Ni sur tout ce qui est partagé quoi.
>Et que en conclusion il faudrait avoir un Xul pour chaque applis fondé dessus?
Si tu recherches les perfs, évidement. C'est tout le problème des profiles d'optimisations. C'est pourquoi PGO est peu utilisé en fin de compte.
De toute façon, en pratique, toutes les grosses applis XUL (songbird, Thunderbird, Miro etc) ont leur propre XulRunner, parce que patchés à leur sauce, parce que options de compils spécifiques etc...
>1. À quoi ça sert de proposer les binaires sur mozilla.org ?
Pouvoir utiliser les binaires vanilla (sans patchs dans tout les sens), tester, avoir les mises à jour pour les nightlies. Et pouvoir l'installer où on veut.
C'est surtout pour les tests et pour ceux qui ont des distribs qui ne reposent pas sur des systemes de paquages ou qui ne proposent pas de paquets firefox.
J'utilise ces binaires et ça me pose pas de problèmes.
>2. Il ne faut pas prétendre être le plus Linux-friendly
Sous gnome, je double click sur le tar.gz (tout comme sur un deb), ça me decompresse le truc, j'ai alors plus qu'à cliquer sur le binaire firefox. Bref, je ne trouve pas tant moins user friendly qu'un deb.
Et puis de toute façon, installe le paquet de ta distro (ce que tu n'as en général pas à faire puisque c'est souvent installé d'office), et tu auras une icone dans ton menu application. Pourquoi voudrais-tu donc un .deb ou .rpm ?
>3. Il faut reconnaître que Windows et Mac sont favorisés
Et je rajouterai ceci : fourni un .deb générique, c'est à coup sûr avoir des retour d'utilisateurs qui auront des problèmes à installer un paquet, pour des problemes de compatibilité avec leur distro, de conflit avec l'eventuel paquet firefox préinstallé etc... Je doute que faire un deb générique qui fonctionne sans problème sur les dizaines de distro existantes soit si trivial que ça... Au moins, un tar.gz, il y a plus de chance que ça fonctionne.
La raison de la non activation de PGO pour les builds linux semble être le manque de temps pour configurer les machines de build automatiques, et faire du PGO avec GCC est apparement un peu plus acrobatique et prend plus de ressources que faire du PGO avec visual C++. Il y a peut etre aussi une histoire de version de GCC par défaut... Enfin bon, pas clair tout ça. Il y a en tout cas un bug pour ceux qui veulent être au courant de quand ça sera fait officiellement. https://bugzilla.mozilla.org/show_bug.cgi?id=418866.
Mais ça ne concerne que les builds vanilla. Pour les builds dans vos distros, plaignez vous aux mainteneurs des paquets qui n'ont pas activé les options adéquates. exemple chez Ubuntu : https://bugs.launchpad.net/xulrunner/+bug/213708
Un des problèmes dans les distro, c'est qu'ils veulent fournir un paquet xulrunner qui soit utilisé par Firefox (Firefox est en fait une appli XulRunner).
Or, si on optimise XulRunner pour Firefox, il se peut que ce ne soit pas du tout optimisé pour d'autres applications utilisant XulRunner. Rappel: l'optimisation PGO consiste à optimiser les parties de codes d'un binaire qui sont les plus sollicités (selon un profile d'execution donc, d'où l'acronyme PGO). Bref, en optimisant le binaire XulRunner pour executer Firefox, ça va optimiser par exemple les parties du moteur de rendu les plus sollicités pour afficher une page web (et probablement au détriment d'autres parties). Hors, ces optimisations peuvent être totalement inutiles (et peut être même avec l'effet inverse) pour une application XulRunner qui n'affiche pas de page web.
Problème donc pour les mainteneurs des paquets Firefox : soit ils livrent d'un coté un Firefox complet optimisé en PGO, et de l'autre un paquet XulRunner non optimisé indépendant du paquet Firefox, soit ils livrent un paquet XulRunner dépendant de Firefox et utilisable par toutes les applis xulrunner, mais alors sans optimisation PGO.
Doit y avoir d'autres raisons, mais j'ai pas plus investigué.
autre chose, et de taille : l'interface de Mozilla est faite en XUL (du XML + CSS + JS). C'est forcement plus lent qu'un appel direct à des libs de toolkit (surtout au demarrage). Par contre, c'est de loin ce qu'il y a de plus customisable, couplé avec le principe des overlays (les quelques milliers d'extensions le montrent). Chrome n'aura jamais une extensibilité aussi flexible. Le système d'extension de Chrome sera une sorte de page web dans laquelle on fait appel à des API figées en javascript, le tout executé dans une sandbox à priori.
Bref, l'extensibilité a un prix. Faudra voir si Chrome trouvera le bon compromis.
Il y a aussi le fait que Mozilla utilise la lib graphique cairo, qui, à l'origine, n'était pas super rapide. (Elle a toutefois bien progressé à ce niveau là depuis, heureusement).
Et puis Mozilla a un lourd passif, avec du code qui date d'il y a 10 ans, avec ses défauts (et ses avantages). Pour le développement de webkit, les devs ont eu l'avantage d'avoir moins de code legacy à se trainer.
Il ne faut pas non plus oublier que parmis les développeurs de Chrome, il y en qui viennent de Mozilla, ont donc une grosse experience, et savent ce qu'il est bien de faire ou de ne pas refaire.
[^] # Re: Bon bon bon...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Support Mercurial sur google code. Évalué à 2.
[^] # Re: je DETESTE les prix libres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 7.
Mais c'est vrai que d'avoir au moins une idée du cout, c'est je pense indispensable.
[^] # Re: Attention chérie ca va forker
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Oracle rachète Sun. Évalué à 3.
Le truc qui m'a fait sursauter :http://drizzle.org/wiki/MySQL_Differences . Ils ont enlever les vues, les procédures stockées, les triggers, les requêtes préparées, et d'autres trucs. Bref, ils reviennent à mysql 3.
Bon, ok, c'est pour un usage plutôt spécifique (cloud computing et cie) mais bon...
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 3.
oui c'est trivial. Mais il n'y a rien de spécifié dans les standards "pour faire un menu dynamique". Et vu qu'il y a mille manière de faire un menu dynamique, je vois pas pourquoi tu parles d'implémentation correcte de menu dynamique. Mais bon je pense avoir compris de travers ton premier commentaire.
>Rien n'empêche d'implémenter un draft, surtout que cela existe depuis très très longtemps 2002
C'est justement ce qui est fait dans Mozilla et Webkit. Cependant, comme c'est pas finalisé, ils ont mis leur prefixe -moz- et -webkit- (comme c'est autorisé dans la spec css), parce qu'effectivement, la spec peut changer d'ici l'etape "recommandation", et donc leur implementation ne plus correspondre avec la spec définitive (qui ne l'est toujours pas, definitive).
Maintenant, rien ne t'empêche à mettre les styles -moz-border-radius, -webkit-border-radius et même border-radius, en même temps dans ta feuille de style (comme ça, ton site sera pret ;-). Pour les autres navigateurs ne reconnaissant pas ces styles, bah tant pis, coin carré, et c'est pas un drame ;-)
>Faire un site portable est un enfer...
bah oui, et c'est pour ça que Mozilla et Webkit font la course à l'implementation des standards, car ça force les autres à suivre (en particulier IE). Et même si IE8 a encore du retard, beaucoup de progrés ont été fait, pour le bien des developeurs web.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 4.
en effet, contributeur depuis 2003.
>Je me suis contenté de t'expliquer ce que pouvait être un menu dynamique "standard". Et très humblement en plus car il y a peut-être d'autres méthodes.
Oui la méthode que tu as indiqué est celle que nous avons expliqué sur openweb.eu.org, (crée par moi et 10 autres gus dans un garage en 2003).
>dire "Firefox sait faire" ne fait pas (mais alors pas du tout) avancer le schmilblick.
Si, bien au contraire. Si IE8 (et puis avant IE7) respecte un peu mieux les standards, c'est grâce à quoi à ton avis ? Grâce au fait que Firefox respecte les standards (ou presque : disons que l'on s'efforce d'implémenter au maximum tout les standards, mais c'est un travail de longue haleine), et grâce au fait que les developpeurs gueulent après les mauvais navigateurs, qui ne fonctionnent pas comme attendu quand on utilise les standards. Ils gueulent, font pour certains le forcing à utiliser des navigateurs plus respectueux, d'où perte de marché pour les mauvais, ce qui forcent ceux-ci à réagir et à donc s'améliorer.
Et ça ne fait pas avancer le schmilblick seulement du coté des mauvais, mais aussi des "bons". Pour preuve cette deuxième guerre des navigateurs qui a démarré depuis le succés de Firefox.
Toutefois, c'est une guerre "saine", dans le sens où c'est plutôt une course à l'implémentation des standards.
Donc, oui, que "Firefox sait faire", ou même que "Webkit/Opera/Whatever sait faire", ça fait avancer le schmilblick.
Y a qu'à voir les avancées sur le support de CSS de Firefox 3.5 par rapport à 3.0 (et 3.0 par rapport à 2.5), forcées plus ou moins par les tests Acid, mais aussi par d'autres avancées dans Webkit comme les css transforms (spec qui est maintenant devenu un draft au W3C).
>Seul le respect des standards établis fera avancer le Web dans la bonne direction.
C'est justement ce qui se passe chez toutes les equipes de dev des navigateurs, IE compris.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 2.
Cependant, la spécification ne précise pas que le choix doit être persistant. Donc <mode mauvaise foi>Firefox respecte le standard de ce point de vu là</mode mauvaise foi> :-)
http://www.w3.org/TR/html401/present/styles.html#h-14.3
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 3.
Oui ok, mais je ne comprend pas : sous firefox, il n'y a pas besoin de faire du js pour ça, je vois donc pas où veut en venir Alenvers.
C'est certes emmerdant que dans certains navigateurs, on ne puisse toujours pas faire des choses simples et pourtant très utile, mais on ne va quand même pas arrêter d'implémenter des nouveaux trucs parce que d'autres sont à la traîne. Sinon personne n'avancerait ou n'innoverait.
[^] # Re: Je serais déjà content avec beaucoup moins
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les possibilités des nouvelles techno web. Évalué à 2.
Comment ça menu dynamique ? C'est quoi un menu "dynamique" pour toi ? Y a des choses en HTML "standard" ou "css" qui permettent de faire des menus dynamiques ?
>Coins arrondi
Mozilla a été le premier à implementer les coins arrondis. ça fait des années que je fais des coins arrondis en CSS. Mise à part ça, les coins arrondis ne sont pas un standard, vu que la specification est encore en brouillon...
>Feuilles de style alternatives
Firefox supporte très bien les css alternatives: menu affichage > style de la page
# salarié et contributeur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal valgrind sous darwin. Évalué à 7.
Plus que ça même. Pour ceux qui ont la flemme de lire son post, c'est un contributeur de longue date de valgrind.
Un premier port pour mac a été fait par un autre contributeur, employé Apple, il y a plus de 4 ans, mais ça avait été retombé plus ou moins dans l'oublie.
Nicholas a alors été embauché par Mozilla pour continuer à bosser dessus car de plus en plus de dev Mozilla sont sous Mac...
[^] # Re: Thunderbird pour qui ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 3.
pas du tout, c'est juste le descendant de la suite mozilla qui contenait browser, client mail, client irc et editeur html.
Firefox a ensuite été crée, n'ayant que la fonction navigateur. Et ne voulant plus continuer le developpement de la suite Mozilla, il a été logique de continuer à proposer une alternative de Mozilla Mail sous forme d'appli standalone : Thunderbird.
Le client irc, chatzilla, est toujours dispo sous forme d'extension pour firefox ou d'appli xulrunner.
[^] # Re: mort le mail??
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 2.
Euh, copier le fichier prefs.js du profil (ou une partie de ce ficher, qui, je le rappelle, contient toutes les options du logiciel), ça ne serait pas plus simple ?
# Logo
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal pas de détrompeur USB.... Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 9.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
(1) http://en.wikipedia.org/wiki/Network_Security_Services
(2) http://en.wikipedia.org/wiki/Netscape_Portable_Runtime
(3) http://en.wikipedia.org/wiki/XPCOM
[^] # Re: La réponse est dans la question
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
j'ai déjà expliqué plus haut
>vu que chaque appli de la MoFo a son XULRunner ?
les applis que j'ai cité, excepté Thunderbird, ne sont pas des applis de la MoFo.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 3.
Si tu veux faire de l'optimisation PGO, oui. Mais c'est le même problème pour toutes les libs des systèmes linux, il me semble.
> Un peu comme il faudrait une libc pour chaque applis?
Oui. C'est pourquoi il n'y a pas d'optimisation PGO sur la libc (enfin à ce qu'il me semble). Ni sur aucune autre lib linux. Ni sur tout ce qui est partagé quoi.
>Et que en conclusion il faudrait avoir un Xul pour chaque applis fondé dessus?
Si tu recherches les perfs, évidement. C'est tout le problème des profiles d'optimisations. C'est pourquoi PGO est peu utilisé en fin de compte.
De toute façon, en pratique, toutes les grosses applis XUL (songbird, Thunderbird, Miro etc) ont leur propre XulRunner, parce que patchés à leur sauce, parce que options de compils spécifiques etc...
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 10.
Pouvoir utiliser les binaires vanilla (sans patchs dans tout les sens), tester, avoir les mises à jour pour les nightlies. Et pouvoir l'installer où on veut.
C'est surtout pour les tests et pour ceux qui ont des distribs qui ne reposent pas sur des systemes de paquages ou qui ne proposent pas de paquets firefox.
J'utilise ces binaires et ça me pose pas de problèmes.
>2. Il ne faut pas prétendre être le plus Linux-friendly
Sous gnome, je double click sur le tar.gz (tout comme sur un deb), ça me decompresse le truc, j'ai alors plus qu'à cliquer sur le binaire firefox. Bref, je ne trouve pas tant moins user friendly qu'un deb.
Et puis de toute façon, installe le paquet de ta distro (ce que tu n'as en général pas à faire puisque c'est souvent installé d'office), et tu auras une icone dans ton menu application. Pourquoi voudrais-tu donc un .deb ou .rpm ?
>3. Il faut reconnaître que Windows et Mac sont favorisés
pas du tout. Il y a des raisons pertinentes à ne pas fournir des paquets:
https://bugzilla.mozilla.org/show_bug.cgi?id=419473#c1
Et je rajouterai ceci : fourni un .deb générique, c'est à coup sûr avoir des retour d'utilisateurs qui auront des problèmes à installer un paquet, pour des problemes de compatibilité avec leur distro, de conflit avec l'eventuel paquet firefox préinstallé etc... Je doute que faire un deb générique qui fonctionne sans problème sur les dizaines de distro existantes soit si trivial que ça... Au moins, un tar.gz, il y a plus de chance que ça fonctionne.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 3.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 2.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 8.
Pour les différences entre win et linux, cf commentaire plus haut. Il y a en effet des optimisations PGO faites lors du build sous windows : https://developer.mozilla.org/En/Building_with_Profile-Guide(...)
La raison de la non activation de PGO pour les builds linux semble être le manque de temps pour configurer les machines de build automatiques, et faire du PGO avec GCC est apparement un peu plus acrobatique et prend plus de ressources que faire du PGO avec visual C++. Il y a peut etre aussi une histoire de version de GCC par défaut... Enfin bon, pas clair tout ça. Il y a en tout cas un bug pour ceux qui veulent être au courant de quand ça sera fait officiellement. https://bugzilla.mozilla.org/show_bug.cgi?id=418866.
Mais ça ne concerne que les builds vanilla. Pour les builds dans vos distros, plaignez vous aux mainteneurs des paquets qui n'ont pas activé les options adéquates. exemple chez Ubuntu : https://bugs.launchpad.net/xulrunner/+bug/213708
Un des problèmes dans les distro, c'est qu'ils veulent fournir un paquet xulrunner qui soit utilisé par Firefox (Firefox est en fait une appli XulRunner).
Or, si on optimise XulRunner pour Firefox, il se peut que ce ne soit pas du tout optimisé pour d'autres applications utilisant XulRunner. Rappel: l'optimisation PGO consiste à optimiser les parties de codes d'un binaire qui sont les plus sollicités (selon un profile d'execution donc, d'où l'acronyme PGO). Bref, en optimisant le binaire XulRunner pour executer Firefox, ça va optimiser par exemple les parties du moteur de rendu les plus sollicités pour afficher une page web (et probablement au détriment d'autres parties). Hors, ces optimisations peuvent être totalement inutiles (et peut être même avec l'effet inverse) pour une application XulRunner qui n'affiche pas de page web.
Problème donc pour les mainteneurs des paquets Firefox : soit ils livrent d'un coté un Firefox complet optimisé en PGO, et de l'autre un paquet XulRunner non optimisé indépendant du paquet Firefox, soit ils livrent un paquet XulRunner dépendant de Firefox et utilisable par toutes les applis xulrunner, mais alors sans optimisation PGO.
Doit y avoir d'autres raisons, mais j'ai pas plus investigué.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 10.
Bref, l'extensibilité a un prix. Faudra voir si Chrome trouvera le bon compromis.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 8.
Et puis Mozilla a un lourd passif, avec du code qui date d'il y a 10 ans, avec ses défauts (et ses avantages). Pour le développement de webkit, les devs ont eu l'avantage d'avoir moins de code legacy à se trainer.
Il ne faut pas non plus oublier que parmis les développeurs de Chrome, il y en qui viennent de Mozilla, ont donc une grosse experience, et savent ce qu'il est bien de faire ou de ne pas refaire.
[^] # Re: que la loi soit inapplicable n'a aucune importance
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Merci aux électeurs de l’UMP. Évalué à 2.
[^] # Re: Merci au PS et à ses électeurs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Merci aux électeurs de l’UMP. Évalué à 3.
[^] # Re: que la loi soit inapplicable n'a aucune importance
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Merci aux électeurs de l’UMP. Évalué à 1.