Journal Pourquoi chromium est il si rapide sous linux ?

Posté par  (site web personnel) .
Étiquettes : aucune
11
7
avr.
2009
"Chromium" c'est la branche libre de "google chrome", le navigateur de google ... (Depuis hier, les onglets sont disponibles, ce qui le rends déjà plus utilisable ;-)

Là n'est pas la question cher journal ...

La question est pourquoi, et comment, google arrive à créer un navigateur aussi rapide ?!? Certes, il n'est vraiment qu'en alpha (et n'est pas encore full-featured).
Mais comment font il pour fournir un navigateur aussi rapide/réactif sous linux que sous windows ?!?

Quand d'autres, comme mozilla, n'y arrive pas sous linux ?!?
C'est une vrai question

  • # Mozilla...

    Posté par  (site web personnel) . Évalué à 10.

    Si Mozilla ne sait pas, pose la question à l'équipe de Konqueror, ils savent très bien comment faire un navigateur réactif sous Linux :)

    Tu peux sans doute également poser la question chez Opera.

    Finalement, la question serait plutôt « Mais comment fait Mozilla pour avoir un navigateur aussi poussif sous Linux ? »

    • [^] # Re: Mozilla...

      Posté par  . Évalué à 1.

      Le point commun entre les versions Linux de Konqueror et Opera c'est qu'ils utilisent Qt. C'est peut être à cause de ça.

    • [^] # Re: Mozilla...

      Posté par  (site web personnel) . Évalué à 8.

      J'ai oublié de préciser que j'ai pas un ordinateur dernier cri ...
      et que le lancement de chromium(-browser) est instantanné, que le changement d'onglet est immédiat ...
      Bref que tout cela est bien plus réactif que n'importe quel navigateur sous linux : firefox, mais également epiphany, midory, konqueror, opera et consorts ...
      C'est vraiment bluffant ... en tous points ...

      • [^] # Re: Mozilla...

        Posté par  . Évalué à -8.

        Chromium ça m'fait vraiment trop penser à "scrotum"...

        Pourquoi on a droit à des noms débiles dans le libre???? pourquoi?!!

  • # gtk ?

    Posté par  (site web personnel) . Évalué à 1.

    Ben mozilla win32 (avec wine) sous Linux est plus rapide que mozilla-gtk sous linux.
    Faudrait peut être chercher du côté des libs de bases utilisées... comme le toolkit graphique en l'occurence...

    • [^] # Re: gtk ?

      Posté par  . Évalué à 9.

      Rien à voir. En passant, le navigateur Google utilise Gtk...
      Il me semble avoir lu que le problème est qu'il y a une optimisation sous Windows qui n'est pas encore activé par défaut sous Linux (ça le sera pour FF 3.1).
      C'est tout... Affaire suivante.

      Et inutile de gerber sur Mozilla, Mozilla est le plus Linux friendly de tous.

      • [^] # Re: gtk ?

        Posté par  (site web personnel) . Évalué à 3.

        Rien à voir rien à voir, c'est un peu rapide ta conclusion.
        Que y'es des optimisations pas activées, c'est une différence qui rentre sûrement en compte, mais les libs utilisées comme GTK est une autre différence.
        Le fait que le navigateur Google utilise GTK ne prouve rien du tout : on a aucune idée du niveau d'utilisation de ces libs et de leurs impacts sur les 2 navigateurs.
        Ca reste un hypothèse qu'il faudrait approfondir pour voir si le toolkit n'a pas d'impact sur Firefox.

        Sinon pour l'optimisation, je comprends pas, quelle bonne raison y-a-t-il pour qu'elle ne soit pas activée aujourd'hui, sachant que visiblement ca n'empêche absoluement pas firefox de marcher sous linux avec (avec wine) ?

        Et inutile de gerber sur Mozilla
        Euh, j'essayais justement de dédouaner Mozilla...

        • [^] # Re: gtk ?

          Posté par  . Évalué à 1.

          > Rien à voir rien à voir, c'est un peu rapide ta conclusion.

          Rien à voir de chez rien à voir, le bench en question n'est même pas un bench graphique. Donc inutile de chercher un troll là où il n'y en a pas.

          > Sinon pour l'optimisation, je comprends pas, quelle bonne raison y-a-t-il pour qu'elle ne soit pas activée aujourd'hui

          Je n'en sais rien. Mais la théorie du complot ne doit certainement avoir aucun rapport.

          • [^] # Re: gtk ?

            Posté par  (site web personnel) . Évalué à 1.

            Rien à voir de chez rien à voir, le bench en question n'est même pas un bench graphique
            Si tu parles du bench Google V8, effectivement, sur cette partie gtk n'a peut être pas d'impact, mais ca ne permet pas de conclure sur la réactivité du bouzin dans son ensemble. Peut être que GTK a un impact non négligeable sur ce que ne test pas Google v8 (c'est à dire tout le reste).

      • [^] # Re: gtk ?

        Posté par  . Évalué à 3.

        Mozilla est le plus Linux friendly de tous.

        Ou pas. J'attends toujours un rpm et un deb (au moins génériques).

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: gtk ?

          Posté par  . Évalué à 6.

          et de pouvoir indiquer les programmes externes sans indiquer tout le path…

        • [^] # Re: gtk ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Pourquoi faire ? puisque les distros proposent eux mêmes les paquets rpm, deb, cequetuveux ?

          • [^] # Re: gtk ?

            Posté par  . Évalué à -1.

            Je suis tout à fait d'accord.

            Mais alors :
            1. À quoi ça sert de proposer les binaires sur mozilla.org ?
            2. Il ne faut pas prétendre être le plus Linux-friendly (puis ne sont pas faites certaines choses que des concurrents font).
            3. Il faut reconnaître que Windows et Mac sont favorisés (puisqu'on utilise bien leurs systèmes d'installation).

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: gtk ?

              Posté par  (site web personnel, Mastodon) . Évalué à 10.

              >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

              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  (site web personnel, Mastodon) . Évalué à 3.

          quelques elements de réponses : https://bugzilla.mozilla.org/show_bug.cgi?id=419473#c1

    • [^] # Re: gtk ?

      Posté par  (site web personnel, Mastodon) . Évalué à 8.

      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: gtk ?

        Posté par  (site web personnel) . Évalué à 7.

        Il y a aussi le fait que Mozilla utilise la lib graphique cairo
        Ben oui mais non, Cairo est aussi utilisé sous Windows (microsoft ou wine).
        Ca explique peut être une différence de perf entre mozilla et chrome, mais pas entre mozilla win32 et mozilla linux.

        • [^] # Re: gtk ?

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Certes. je parlais effectivement des différences entre Mozilla et Chrome.

          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  . Évalué à 4.

            En résumé ce que tu dis 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? Et que en conclusion il faudrait avoir un Xul pour chaque applis fondé dessus? Un peu comme il faudrait une libc pour chaque applis? C'est un peu lourd comme approche que ce soit en place disque et/ou en RAM non?

            • [^] # Re: gtk ?

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              >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...

              • [^] # Re: gtk ?

                Posté par  . Évalué à 1.

                Du coup, pourquoi PGO n'est-il pas plus mis en avant pour Firefox, vu que chaque appli de la MoFo a son XULRunner ?

                • [^] # Re: gtk ?

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  > pourquoi PGO n'est-il pas plus mis en avant pour Firefox

                  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  (site web personnel, Mastodon) . Évalué à 10.

        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.

      • [^] # Re: gtk ?

        Posté par  (site web personnel) . Évalué à 3.

        Et puis Mozilla a un lourd passif, avec du code qui date d'il y a 10 ans [...]. Pour le développement de webkit, les devs ont eu l'avantage d'avoir moins de code legacy à se trainer.

        Webkit vient de KHTML qui a 10 ans lui aussi.
        (Mais Mozilla est peut être encore plus vieux ?)

        • [^] # Re: gtk ?

          Posté par  (site web personnel, Mastodon) . Évalué à 9.

          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.

          (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: gtk ?

      Posté par  (site web personnel) . Évalué à 4.

      Soit dit en passant, Firefox n'utilise pas GTK+, il utilise juste le moteur de thème de GTK+, comme fait Qt 4.5...

      Et la lenteur de GTK ne pourrait pas justifier la vitesse de Firefox, le plus gros du rendu n'ayant rien à voir avec la bibliothèque graphique.

      • [^] # Re: gtk ?

        Posté par  (site web personnel) . Évalué à 2.

        le plus gros du rendu n'ayant rien à voir avec la bibliothèque graphique.
        Quand on cherche des problèmes de perf, on cherche pas là où y'a le plus de code, mais là où y'a le plus de temps passé.
        Je sais pas moi, il suffit d'une méthode GTK appelée pourjenesaisquelleraison qui prenne un temps déraisonnable pour qu'il y est une impression de lenteur.
        Après ca n'a peut être effectivement rien à voir avec GTK, je cherches juste une explication.

  • # Normal

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    << you are the captain of the cargo ship Chromium B.S.U., and responsible for delivering supplies to our troops on the front line. >>

    Normal que ce soit rapide, sinon on serait pas dans la merde...




    PS: j'espère que n'est que le nom de la branche et pas de la version nux, parce que c'est très moyen d'utiliser un nom déjà pris

    • [^] # Re: Normal

      Posté par  . Évalué à 4.

      Ça arrive de prendre des noms déjà pris ou évocateurs d'autres noms (et ça reste très moyen dans tous les cas, on est d'accord)

      * Phoenix -> Firebird -> Firefox (changements successifs en partie dus à l'existence d'autres projets)
      * gentoo (gestionnaire de fichiers sous gtk1 avant d'être une distribution linux)
      * gnuplot (logiciel de tracé de graphes antérieur au projet GNU, signifiant « new plot »)

      Y'a aussi des choix peu habiles involontaires : « fedor » en portugais signifie « puanteur ».

      • [^] # Re: Normal

        Posté par  . Évalué à -1.

        "* gentoo (gestionnaire de fichiers sous gtk1 avant d'être une distribution linux)"

        Euh rien a voir :)

        Source : http://en.wikipedia.org/wiki/Gentoo_(file_manager)

        • [^] # Re: Normal

          Posté par  (site web personnel) . Évalué à 5.

          Bhe si à voir: C'est parce que ça n'a rien à voir que ça a à voir.
          Tu vois le rapport ?

          • [^] # Re: Normal

            Posté par  . Évalué à 5.

            J'ai juste compris que tu pourrais être ministre de la culture...

            • [^] # Re: Normal

              Posté par  . Évalué à 1.

              Ça a à voir que gentoo (la distribution) a été assez maladroite de choisir un nom identique au projet de gestionnaire de fichiers qui existait antérieurement (et qui est présent dans la distribution). La maladresse vient du fait que la phrase « j'installe gentoo » est ambigüe. Personnellement j'ai les deux sur ma machine...

              Chez Mozilla, ils avaient trouvé une une excellente paire de noms : Firebird/Thunderbird. Mais quand se sont rendus compte que Firebird était déjà pris, ils ont eu le courage de changer d'idée et ont pris Firefox, sacrifiant au passage la jolie « symétrie » des deux noms.

              • [^] # Re: Normal

                Posté par  . Évalué à 1.

                Bof, ils auraient très bien pu changer Thunderbird en Thunderfox, au moins on aurait bien compris qu'ils n'avaient aucune espèce de considération pour leur client mail… Il a juste fallu attendre 2 ans pour s'en rendre compte.

  • # Onglets?

    Posté par  . Évalué à 1.

    (Depuis hier, les onglets sont disponibles, ce qui le rends déjà plus utilisable ;-)
    J'ai les onglets depuis un moment sous chromium (au moins 3 semaines). Mais c'était juste décoratif, car on pouvait pas en changer, ni en fermer d'autres que le courant.
    J'ai pas encore compilé récemment, y'a un changement ?

    • [^] # Re: Onglets?

      Posté par  . Évalué à 1.

      les onglets sont actif sous chrome. donc chrome ne se base pas vraiment sur chromium non ? je suis un peu perdu la.

    • [^] # Re: Onglets?

      Posté par  (site web personnel) . Évalué à 2.

      oui les onglets étaient présents depuis qques temps ... mais étaient inutilisable ... depuis peu, ils sont utilisables et fonctionnels

  • # A marche pô

    Posté par  . Évalué à 5.

    Chez moi Chromium ne marche pas, il se lance certe mais j'ai plein de problèmes : les onglets ne fonctionnent pas, impossible d'accéder à mon routeur avec un 192.168.0.1, impossible de poster un message sur un forum. Je préfère de loin mon firefox « un peu plus lent » qui fonctionne parfaitement avec mes plugins.

    • [^] # Re: A marche pô

      Posté par  . Évalué à 8.

      En même temps, c'est une version pre-alpha : si ça marche, c'est juste un effet de bord involontaire !

      • [^] # Re: A marche pô

        Posté par  . Évalué à 4.

        Oui, il arrive que parfois, ça tombe en marche \o/

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # arora

    Posté par  . Évalué à 3.

    Tu as déjà utilisé arora ? (http://code.google.com/p/arora/ )
    C'est un navigateur léger basé sur QT4/Webkit (en fait c'est une évolution du code de démo Webkit dans QT4). Très rapide et réactif (et il paraît que c'est encore mieux avec QT4.5), la seule chose qui me manque est adblock (mais privoxy aide bien...), et occasionnellement flash (mais ça fait aussi du bien de s'en passer, pour une navigation plus légère et plus libre :)

  • # Parcequ'il a des turbo réacteurs interstellaires

    Posté par  . Évalué à 8.

    (et des armes à faire pâlir un super flix protectueur de l'OTAN)

    # apt-cache search chromium
    chromium - fast paced, arcade-style, scrolling space shooter
    chromium-data - data pack for chromium

  • # La réponse est dans la question

    Posté par  . Évalué à 9.

    comment, google arrive à créer un navigateur aussi rapide ?!? [...] [il] n'est pas encore full-featured

    Ben voilà, tu as ta réponse : en faisant moins de choses, c'est facile d'être plus rapide. On verra s'il est toujours aussi vif en full-featured (notamment avec le système d'extensions).

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Firefox 3.1 beta 3

    Posté par  . Évalué à 4.

    Intrigué par les réponses de Laurent J ici, j'ai téléchargé une version binaire de Firefox 3.1 (la beta 3) et je dois avouer qu'il a raison : de gros progrès ont été fait dans la rapidité d'affichage des pages, en particulier lorsqu'elles sont farcies de javascript.
    Je n'ai pas eu le temps de tester le comportement avec Flash (ce qui ne concerne pas directement Mozilla mais plutôt Adobe) mais vivement la sortie de Firefox 3.1 (et son intégration à Fedora).
    Bye

  • # La bonne question

    Posté par  . Évalué à -3.

    Pourquoi Google n'a pas fournit un navigateur web à la fin des années 90?

  • # Part de Chromium dans Chrome

    Posté par  (site web personnel) . Évalué à 2.

    Bonjour,

    Je profite de ce sujet pour vous demander cette question qui concerne un mémoire que je réalise sur le libre dans Chromium : quelle est la part de Chromium dans Chrome ? Qu'ajoute Chrome à Chromium ?

    Est-ce seulement le Logo de Google et le moteur par défaut Google ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.