Forums d'assistance et de discussion sur les logiciels produits par Mozilla ou créés à partir des technologies Mozilla. Ce site ne dépend pas de la fondation Mozilla et est maintenu par un collectif de bénévoles.
Quand tout est (trop ?) bien organisé, il y a besoin d'une ouverture. Ici on parle de tout, mais pas de n'importe quoi et toujours dans le respect d'autrui, vous êtes prévenus.
J'espère ne pas engager un troll, mais après la sortie de Google Chrome et son buzz, j'aimerais connaître les merveilles auxquelles nous avons n'avons pas échappées
quelques propositions
-la barre d'onglet n'importe où, et surtout pas près des onglets
-l'usage indécent des effets de transparence. Super sur les ordinateurs portables!!
-Absence de menu. Où chercher la configuration about.chrome ou autre.. Il faut au moins quelque-chose de parlant.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Chez les papous il y a des papas à poux
Chez les papous il y a des papas pas à poux
Chez les papous il y a des papas papous
Chez les papous il y a des papas pas papous
---
Franquin (Avant 1999JC)
J'aime bien la possibilité de bouger la barre d'onglets où on veut.
J'aime bien les effets de transparence !
Et le menu, je préfère qu'il n'y en ait pas, plutôt qu'il prenne toute une barre !
La vraie fausse bonne idée c'est un processus par onglet? Pourquoi:
1) on peut arriver à la même robustesse sans (javascript/html, c'est uniquement du code 'interne'; seuls plugins et dll dans les extensions sont hors de contrôles. Eux peuvent être envoyés dans des processus séparés).
2) Gourmandise mémoire. Alors que cela râlait encore il y a 5 mois sur Firefox bouffe trop de RAM, maintenant les mêmes tolèrent plus d'utilisation RAM.
Néanmoins cela ne veut pas dire que ce que fait Firefox aujourd'hui est bien. J'aimerais bien voir une amélioration du threading ainsi que le lancement des plugins dans un processus séparé (comme le fait Opera).
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
pirlouy a écrit :Et le menu, je préfère qu'il n'y en ait pas, plutôt qu'il prenne toute une barre !
Assez d'accord, d'ailleurs je n'ai pas attendu chrome pour le virer avec Personal Menu
teoli2003 a écrit :2) Gourmandise mémoire. Alors que cela râlait encore il y a 5 mois sur Firefox bouffe trop de RAM, maintenant les mêmes tolèrent plus d'utilisation RAM.
Non mais Teoli a carrément raison quand il dit que certaines personnes qui prétendent préférer Chroma à Firefox utilisent l'argument de la consommation mémoire pour ça. Aberrant.
Je ne suis également pas convaincu que ce soit une bonne idée, surtout que je ne vois pas du tout en quoi ça évite la fragmentation de la mémoire... Ce n'est pas parce que tu fermes un onglet, que l'ouverture du suivant va pouvoir se faire au même endroit (dans la mémoire).
Avoir plusieurs processus différents n'est pas un handicap sur des systèmes gérant au mieux la mémoire virtuelle.
Un processus c'est des segments de code, de donnees statiques et dynamiques, une Pile et éventuellement des segments de mémoire partagée.
Certains OS acceptent d'avoir des codes réentrants, cela veut dire qu'un seul segment de code est chargé en mémoire même s'il y a plusieurs processus exécutant ce code. Bien entendu les données sont propores à chaque processus.
Donc en bilan mémoire, l'écart peut être faible entre les 2 choix d'implémentation. (à vérifier dans l'environnement à Bill)
Le fractionnement de la mémoire existe à plusieurs niveaux: physique et au niveau de la gestion de la mémoire virtuelle. La mort d'un process permet d'améliorer la fragmentation physique et, bien entendu virtuelle.
Ne parlons même pas de l'effet sur la gestion de mémoire dynamique des processus!
En fait c'est un peu spécial ce que tu nous dis. Ouvrir plusieurs processus serait avantageux parce que s'il y en a un qui meurt ça améliore la situation ?
Je ne suis pas sûr de comprendre ce que tu appelles le fractionnement « physique » de la mémoire. La RAM ce n'est pas comme un disque, il n'y a aucun coût à sauter d'une adresse à l'autre bout de l'espace d'adressage. Le seul problème éventuel c'est que tu peux réserver trop de place pour ton processus.
♫ Li tens s'en veit, je n'ai riens fais ;
Li tens revient, je ne fais riens. ♪
Un OS attribue de la mémoire page par page à un processus. Le processus utilise cette mémoire et la rend à l'OS quand elle est vide. En cas de fragmentation, il ne peut le faire car même si elle a "plein de vide", elle ne l'est pas entièrement. (Même si le programme a dit "Je n'ai plus besoin de cette partie de la page").
Lorsque l'on ferme un processus, toutes les pages associées sont rendues à l'OS. Donc en ce sens oui, cela peut limiter la fragmentation.
Il y a deux mais:
1) la fragmentation n'est plus le problème majeur de Firefox;
2) il y a de la mémoire partagée entre les processus, et là, la fragmentation peut avoir lieu.
La question là est: qu'est-ce qui doit être partagé? L'historique, le cache mémoire, les marque-pages, les extensions(?)...
Ou plutôt qu'est-ce qui n'est pas partagé? Le JS de la page, le code source, les piles de communications, même pas le rendu de la page puisque c'est dans la même fenêtre (d'ailleurs cela est-il possible avec zéro-copie dans tous les OS supportés?)
Car plus il y a de choses partagées plus on risque à nouveau la fragmentation, et les crashs globaux en cas de corruption de cette partie.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Moi ce que je vois surtout dans un processus par onglet c'est d'utiliser l'ordanceur du système pour les gérer et ça c'est cool quand on voit les grosses applications qui apparaissent pour navigateur. Ca permet aussi de bénéficier de son système SMP au mieux.
La fragmentation mémoire a pas lieux d'être on s'en fout comme l'a dit Benoit de où se trouve les données en RAM, l'accès en mémoire est à temps constant quelque soit la position en RAM. De plus (sous linux tout du moins) le programme n'a pas les moyens de contrôler où vont ses données vut que le noyau ne lui donne qu'une mémoire virtuelle via la pagination mémoire.
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008062910 Iceweasel/3.0 (Debian-3.0~rc2-2)
La fragmentation de la mémoire n'a pas d'influence sur les temps d'accès aux données. Mais elle influe sur l'espace globale utilisé puisque la gestion dynamique de la mémoire va automatiquement morceller les grandes zones en petites zones au fur et à mesure des allocations-libérations. Il existe des mécanismes de ramasse-miettes (realloc,...) pour éviter d'avoir trop de pages à faible taux d'occupation maintenues en mémoire. Les zones mal-libérées font également grossir les processus.
En ayant un processus par onglet, on s'affranchit d'une grande part des problèmes de dégénérescence liée aux traitements effectués.
Moi je pense que un processus par onglet est une bonne idée, on doit pouvoir ouvrir plusieurs cessions ( j'entends des logins différents ) Google ( ou autres) avec cela.
Alors, je viens d'installer Chromium, et tout de suite :
Le bug 61098 est résolu simplement par une case à cocher "Ne plus permettre au script blablabla...". Mais tant que la fenêtre d'alerte est affichée, l'interface n'est pas accessible. Donc le fait d'avoir plusieurs processus ne résout en tous cas pas ça.
Pour les cookies, ils sont partagés : si je me loggue dans un onglet et que j'en ouvre un autre sur le même site, je suis loggué (testé sur bugzilla). Ce qui est logique au fond
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
