Bonjour nal,
Je ne peux m'empêcher de mettre en parallèle les gains ahurissants de performance de Firefox depuis un an (cf la dernière dépêche en date) avec la dégradation tout aussi ahurissante des performances Intel depuis un an.
Tandis que les développements du premier sont entièrement tendus vers les moyens d'accroître la vitesse et la réactivité du logiciel (en même temps que sa sécurité et de proposer des outils de défense de la vie privée aux utilisateurs), le deuxième ne cesse de tenter de réparer les failles béantes de sécurité causées par ses choix bon marché d'optimisation de performance sur ses processeurs actuellement en circulation.
Du coup, en tant qu'utilisateur de Firefox ET d'un processeur Intel, je me demande si les gains de performance de Firefox suffiront à contrebalancer les dégradations de performance de mon processeur en 2019 (voyez les résultats pour un processeur Intel Core i7 3700K/3770K de même génération « Ivy Bridge » que le mien sur ces tests menés par Phoronix [1]).
Drôle d'époque.
[1] Pour comprendre le test :
Tests were done on Ubuntu 19.04 with the Linux 5.0 kernel while toggling the mitigation levels of off (no coverage) / auto (the default / out-of-the-box mitigations used on all major Linux distributions for the default protections) / auto,nosmt (the more restricted level that also disables SMT / Hyper Threading). The AMD CPUs were tested with off/auto as in the "auto,nosmt" mode it doesn't disable any SMT as it doesn't deem it insecure on AMD platforms.
Quand je lis par exemple :
The Core i7 3770K Ivybridge system took 2.3x longer to run this test under the complete mitigations or 1.6x the time if just using the default mitigations
[The i7 3770K] saw around a 14% hit to the default mitigated performance as well but that extended to 18~19% if disabling Hyper Threading in the name of security
Je me dis 1°) que c'est pas gagné 2°) que le mérite des uns (Mozilla) et l'incompétence des autres (Intel) n'est pas assez soulignée.
# Nuance
Posté par Thomas Douillard . Évalué à 10.
Juste pour quand même nuancer, le genre de problèmes qui affectent les processeurs Intels, ils sont potentiellement aussi présents en grand nombres dans les logiciels qui sont comparables en terme de complexité. Ça a moins de conséquences évidemment parce qu’il y a plus de souplesses pour corriger et c’est évidemment plus facile de déployer du logiciel que de remplacer des microprocesseurs.
Mais certes si il y a des erreurs de faites côté Intel, c’est quand même un peu fort de déclarer les uns compétents et les autres incompétents parce qu’il y a des erreurs de faites. Il y a aussi des erreurs chez Mozilla … C’est juste que ça fait moins mal quand les extensions sont désactivées pendant un week-end et qu’on a plus de chances d’oublier rapidement …
Mais ça reste compliqué pour moi d’imaginer un monde ou un composant d’une complexité comme un processeur soit exempt de bug, même avec l’équipe la plus compétente du monde. Ou alors ce serait au détriment d’autres aspects, probablement.
[^] # Re: Nuance
Posté par barmic . Évalué à 4.
J'avoue que :
Sans plus d'arguments ça me paraît osé.
Sinon je ne crois pas que Firefox soit CPU bound. Si mon intuition est vrai tu va pouvoir dormir tranquillement sur ton manichéisme :)
[^] # Re: Nuance
Posté par Anonyme . Évalué à 5.
Depuis le lancement de l'HyperThreading des craintes ont été émises sur la sécurité, il me semble que c'est quasiment pareil avec le mécanisme d'exécution spéculative.
Intel avait dix ans pour corriger leur implémentation du SMT.
D'ailleurs leur dernière génération n'est pas concernée par Zombieload, comme si ils étaient au courant depuis un moment et qu'enfin ils se sont décidé à agir après le fiasco Meltdown et Foreshadow.
En attendant, AMD va lancer sa troisième génération de processeurs Ryzen d'ici quelques mois. Il y aura de bonnes affaires dans le matériel d'occasion.
[^] # Re: Nuance
Posté par barmic . Évalué à 5.
Des gens qui crient au loup, il y en a tout le temps. Est-ce qu'il y a eu des démonstrations avant l'an dernier ? Si les gars en 10 ans n'avaient pas plus d'arguments que "ça paraît louche", c'est que tout ce dont on parle n'est pas si triviale que ça. Sinon je peux annoncer que SHA-3 est très louche à mon avis d'un point de vue sécurité et quand il commencera à s'effriter, dire que je l'avais bien dit.
[^] # Re: Nuance
Posté par anaseto (site web personnel) . Évalué à 3.
Dans le cas d'Intel et Meltdown (Spectre était plus subtil) le risque potentiel devait être à mon avis assez évident pour Intel : aller spéculativement chercher des choses en mémoire (et donc modifier le cache avec) avant de faire le test vérifiant que le processus peut accéder à cette mémoire, ça « paraît risqué », quoiqu'on pense de cette formule :-) C'est le genre d'optimisation tordue dont les conséquences sont floues : ils ont parié et perdu.
Pour les failles utilisant le SMT, pareil : optimisations tordues. OpenBSD trouvait ça suffisamment louche pour avoir désactivé ça il y a un an, l'histoire leur a donné raison bien vite. Pas étonnant, car la méfiance s'étant installée, plus de monde cherche les failles.
[^] # Re: Nuance
Posté par Thomas Douillard . Évalué à 0.
Et encore, même si il y a des exploits qui traînent, c’est quoi la probabilité que les failles soient exploitables dans de vraies attaques ?
Ça reste sans doute un outil dans l’arsenal du pirate, pas dit qu’en vrai il ait l’occasion sérieuse de l’utiliser un jour (je précise que j’ai absolument aucune idée de la situation dans le cas de ces failles précisément). Il doit falloir quand même des conditions assez compliquées à atteindre avant d’être en capacité d’exploiter de telles failles et de réussir.
[^] # Re: Nuance
Posté par anaseto (site web personnel) . Évalué à 10.
Spectre était pas totalement évident à exploiter et le leakage d'information se faisait à moindre vitesse (moins de 50K/s de mémoire) et c'est pourquoi il a suscité moins de réactions. Meltdown était exploitable avec autour de 500K/s de fuite d'information par n'importe quel utilisateur d'un système en exécutant un programme pas trop long (sans les patchs dans les navigateurs pour réduire la précision des timers, c'était exploitable depuis javascript, probablement à moindre vitesse) — c'est bien pour cela que ça a enragé autant de monde et que les OS ont mis en place des patchs rapidement malgré la perte importante de performances et donc le coût de ces patchs. Notons que les chiffres que je donne, c'était avec les premiers prototypes pour exploiter la faille, il se peut que des gens aient réussi à faire mieux depuis.
Si tu veux voire des exemples, le site officiel de Meltdown a quelques vidéos, comme celle-ci.
[^] # Re: Nuance
Posté par anaseto (site web personnel) . Évalué à 3.
Maintenant que j'y pense, ce point n'est de mémoire pas correct : en ce qui concerne Meltdown, depuis javascript, c'est plus compliqué que ça : les proofs of concept javascript que j'ai vus sont pour Spectre. Meltdown est facile à exploiter depuis du code compilé uniquement, donc impacte surtout les systèmes multi-utilisateur où il est facile d'exécuter son propre binaire ; après, javascript/wasm utilisent un JIT : peut-être qu'il y a moyen quand même d'écrire du javascript/wasm qui compile vers ce qu'il faut, mais c'est moins évident a priori, en tous cas je ne vois perso pas à quoi ça ressemblerait.
[^] # Re: Nuance
Posté par Rico Belo . Évalué à 0.
J'ajouterais que les failles récentes dont on parle (spectre, meltdown, etc) ne sont pas spécifiques aux processeurs Intel, mais à tous les processeurs exploitant une architecture superscalaire et ayant recours aux branchements spéculatifs. Cela inclut entre-autres Intel, AMD, mais aussi certains CPU ARM par exemple…
Après le bench que tu cites démontre simplement que si Intel est le plus impacté en termes de perfs pures, c'est surtout dû au fait que Intel avait poussé plus loin que AMD les optimisations sur le branchement spéculatif, et que la perte de cet "avance" remet les 2 fondeurs sur un pied d'égalité sur le sujet de l'écart de perfs !
[^] # Re: Nuance
Posté par anaseto (site web personnel) . Évalué à 6.
Meltdown est spécifique à Intel. Il me semble que certains problèmes récents du SMT (ZombieLoad) ne concernent que Intel également. AMD a son lot de bugs également, ceci dit, il semble juste que pour la spéculation ils aient été un peu plus raisonnables, mais l'histoire nous dira.
Spectre est plus général et affecte en effet la plupart des archis (pas toutes).
[^] # Re: Nuance
Posté par Anonyme . Évalué à 3.
Même chose pour Foreshadow, que j'ai cité dans mon précédent message, qui est une vulnérabilité dans l'implémentation du jeu d'instruction SGX propre aux CPU Intel de génération Skylake et suivantes.
[^] # Re: Nuance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Une vulnérabilité dans un jeu d'instructions dédié à la sécurité, c'est moche :(
La connaissance libre : https://zestedesavoir.com
[^] # Re: Nuance
Posté par Anonyme . Évalué à 2.
Pire, trois vulnérabilités : une par an.
# Autre(s) facteur(s)
Posté par AncalagonTotof . Évalué à 5. Dernière modification le 26 mai 2019 à 01:00.
Un navigateur est une telle usine à gaz qu'il me semble difficile de mesurer leur performances.
D'autant plus qu'il y a des facteurs externe pas évident à prendre en compte.
Exemple : Google.
Google et Mozilla ont longtemps collaboré.
Jusqu'à ce que Google développe Chrome.
Et là, bizarrement, Firefox a vu ses perfs baisser sur les sites Google.
Un des coups de p… Phourbe … Dont je me rappelle à peu près bien, ça a été de placer une frame invisible devant les vidéos de YouTube. Je parle de Google, qui possède YouTube, et qui bricole le "site web" YouTube pour ajouter cette frame.
Chrome, évidemment, a tout de suite géré cette transparence. Aidé par le hardware probablement.
Firefox, lui, s'est mis à ramer sévère. Sur YouTube.
Après, c'est la course à l'échalote. Firefox a fini par rattraper ce retard. Puis le suivant. Puis le suivant …
Autre exemple, encore une fois très détaché de Mozilla : sur mon MacBook Pro (Late 2013), Firefox a commencé à ramer de la mort qui tue vers février/mars de cette année.
Première piste : ça avait peut-être quelque chose à voir avec les 350 ou 400 onglets ouverts … Mais …
Seconde piste : c'est la période à laquelle je me suis décidé à passer à Mojave, la dernière version de macOS. Mouais, j'ai l'impression que Tim voudrait que je change mon Mac … Ou que j'utilise Safari …
Des clous !
Tiens, au passage, depuis quelques mois, PathFinder voudrait que j'upgrade aussi ($20 pour la version 8). Bizarre, depuis ce moment, il devient périodiquement super lent. Vérification faite, c'est normal, quand on consomme presque 100% des 16 Go de RAM ! Prend moi pour une buse, une fuite mémoire, jamais vue jusque là ?…
Mais je sens que je commence à m'égarer … Qui a dit comme d'hab ?!?!
Pour le premier exemple, voilà l'idée que se fait Google de la concurrence libre et non faussée … Votez bien tout à l'heure !
# Skylake ralentit Internet
Posté par AlexTérieur . Évalué à 4.
Ça contrebalance ce qu'on s'est tapé par le passé.
-->[]
# Mauvaise foi ?
Posté par LaBienPensanceMaTuer . Évalué à 1.
<avocat du diable>
En même temps, si le navigateur Mozilla avait pas été codé avec les pieds pendant des années, ils (Mozilla) ne parviendraient pas à un tel gain de perf …
</avocat du diable>
[^] # Re: Mauvaise foi ?
Posté par antistress (site web personnel) . Évalué à 3.
spafo :)
[^] # Re: Mauvaise foi ?
Posté par damaki . Évalué à 10. Dernière modification le 27 mai 2019 à 11:09.
Pendant ce temps là, ça fait des années que Chrome se goinfre de RAM et personne ne se plaint de ce problème de perfs. Les memory leaks de Firefox eux sont corrigés depuis des années.
Il y a effectivement une part de mauvaise foi dans ces histoires de perfs de Firefox, en défaveur de Firefox et inversement en faveur de Chrome.
[^] # Au pied de la lettre
Posté par nico4nicolas . Évalué à 10. Dernière modification le 27 mai 2019 à 12:30.
Pour prendre le contre-pied, ce que tu écris est bête comme tes pieds ! Mozilla est parti du bon pied et ils ont mis Google au pied du mur tandis que IE est en train de partir les pieds devant. Ils (Mozilla) se sont peut être pris les pieds dans le tapis à un moment mais ils se sont bien remis sur pied tout en gardant les pieds sur terre et, aujourd'hui, Chrome et Firefox sont sur un pied d'égalité. Grace à eux, nous sommes en mesure de trouver chaussure à notre pied et ça, c'est le pied !
[^] # Re: Au pied de la lettre
Posté par LaBienPensanceMaTuer . Évalué à 5.
Dans cette prose, très foot-fetish, il y a peu d'éléments concrets….
De mon côté, concrétement, ce que j'ai vu, c'est que certes Chrome se goinfre de RAM, mais se sort beaucoup mieux des situations ou il en "prend trop"…
Le Firefox de ma Debian (60.6.1esr (64-bit)) ne sait juste pas s'arrêter. Il consomme, consomme jusqu'à rendre le système totalement inutilisable avec, comme seule issue, l'intervention de l'OOM-Killer après 30 minutes de moulinage inutile ou … le reboot.
Peut être que la différence entre Chromium et Firefox se limite à:
Mais toujours est il que rien que ce petit if suffit à faire la différence …
D'ailleurs, si Mozilla avait mis Google "au pied du mur", on ne verrait pas autant de chromium sur les linux….
Je continue à faire de la resistance et à ne pas utiliser Chromium…
Même si ça s'est amélioré avec le temps, je suis désolé, mais Chromium reste bien meilleur sur des machines qui remplisse la condition ( RAM < 32 GiB && Onglets ouverts > 10 )
[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 6.
C'est un peu plus compliqué que ça :
(cf: https://linux.die.net/man/3/malloc)
[^] # Re: Au pied de la lettre
Posté par LaBienPensanceMaTuer . Évalué à 2.
Tu me parles de Linux, mais je te parle de Firefox et Chromium tout deux sur plateforme Linux
Donc pourquoi Chromium s'en sort mieux ?
[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 2.
Je n'en sait rien je dis juste que c'est pas juste la gestion du retour du
malloc(3)[^] # Re: Au pied de la lettre
Posté par Anthony Jaguenaud . Évalué à 2.
Ce qu’il te dit c’est que le bout de code que tu as écris, Linux ne retournera jamais NULL… donc ce n’est pas la bonne façon de savoir si on peut allouer. De toute façon, tant qu’il y a du swap, tu peux allouer.
La bonne solution c’est les limitation cgroup.
[^] # Re: Au pied de la lettre
Posté par LaBienPensanceMaTuer . Évalué à 3.
J'entend, mais il ne faut pas prendre mon exemple "naif" au pied de la lettre.
Les faits sont là: sur du site gourmand (type "Top 10 des ") avec du JS dans tout les sens et de la régie publicitaire aggressive, Firefox finit inexorablement par consommer trop de mémoire, rendant par la même occasion le système instable voir totalement inutilisable.
Dans le même contexte, Chromium n'a pas se comportement: il aura tendance à planter tout seul dans sons coin.
Donc je suis d'accord avec le fait qu'il existe de workaround système pour limiter la casse, mais la question demeure: pourquoi et comment Chromium s'en tire mieux sur ce type de problème ?
[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 3.
J'en sait rien, j'ai juste donné une information.
[^] # Re: Au pied de la lettre
Posté par Kerro . Évalué à 5. Dernière modification le 29 mai 2019 à 22:03.
Chez moi c'est l'inverse : Chrome bouffe toute la mémoire très rapidement, alors que Firefox ne m'oblige à relancer la machine qu'environ une fois par mois (avant je n'étais jamais obligé de redémarrer, depuis quelques mois même fermer la session ne libère pas toute la mémoire).
[^] # Re: Au pied de la lettre
Posté par Sufflope (site web personnel) . Évalué à -1.
Vu que j'utilise Firefox en le laissant ouvert des jours / semaines / (nan pas des mois faut quand même reboot pour les màj) avec au moins autant d'onglets que tu décris, sans avoir de soucis, je me permets une hypothèse
Quand on utilise une distrib obsolète dont les développeurs se croient meilleurs que les autres et patchent tout ce qui passe, quitte à générer des certificats SSL déterministes par exemple, et qu'on a un souci que n'ont pas les autres, peut-être qu'il faut creuser par là ?
[^] # Re: Au pied de la lettre
Posté par Faya . Évalué à 3.
OK, et quand ça me fait la même chose que ce qu'il décrit sur une Arch avec un Firefox à jour ?
C'est simple, je suis maintenant obligé de fermer Firefox (& Thunderbird) tous les soirs pour ne pas risquer de retrouver ma machine figée, RAM & SWAP pleines, CPU à 100%.
Alors moi aussi je fais de la résistance, je reste sous FF, j'aime mon workflow et mes extensions, mais franchement ça me démange de passer sous Chromium. Si Chromium gérait Firefox Sync je pense que ça serait déjà fait.
[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 4.
Tu as regardé en fin de journée quels onglets consomment le plus de ressources ? Ça te permettrait de le fermer ou de le décharger. Je sais que j'ai eu des problèmes avec l'une des pages de Jenkins par exemple.
Après ta machine qui n'arrive pas à sortir de la veille le matin c'est surprenant que ce soit de la faute à Firefox
[^] # Re: Au pied de la lettre
Posté par Grunt . Évalué à 10.
De manière générale ça ne rime pas à grand chose de comparer des navigateurs Web si on ne se met pas d'accord sur les pages Web consultées.
Je n'y connais rien en technologies Web, mais j'ai l'impression qu'il y a des différences énormes entre les pages Web. Entre par exemple LinuxFr, sur lequel naviguer, faire défiler, interragir, donne l'impression de travailler avec une feuille de papier : c'est léger, c'est mobile c'est fluide, c'est facile d'écrire dessus.
Et puis il y a des sites qui donnent l'impression d'être des plaques d'acier, pour lesquels il faut du matériel puissant si on veut simplement les faire défiler ou écrire quelque chose dessus.
Des sites de merde qui réagissent si on les fait défiler, ou juste si on passe la souris au-dessus d'un élément, ce que je trouve intrusif au possible : pour moi, la souris ne doit avoir aucun effet tant que je ne presse pas un bouton. Sinon ça donne l'impression d'avoir un stylo qui coule : pour agir sur une zone en venant d'une autre, je dois faire ultra attention aux zones que je traverse.
Des sites épais, avec des couches de pop-up, des couches transparentes qui empêchent le clic droit sur les images, des couches successives de code javascript (du code qui appelle une bibliothèque depuis un autre site et s'en sert pour traiter des données venant d'un CDN).
Je pense que "protéger les utilisateurs" sur Internet devrait passer par des limitations techniques à la lourdeur et aux capacités des sites Web. Il y a des contrôles qui devraient rester souverains, comme fermer une page Web, accéder forcément aux menus d'une image ou d'une vidéo en y faisant un clic droit, survoler des éléments à la souris sans modifier l'aspect du site, sélectionner du texte et avoir accès à son menu contextuel. Et l' "épaisseur" (le rapport entre la surface affichée à l'écran et le volume total de données à traiter) des sites devrait avoir une limite, afin de limiter la puissance de calcul nécessaire : pas plus de tant de calculs par seconde, par pixel de site Web.
Chaque fois que j'ai Firefox qui mouline et galère, je commence par me demander : est-ce que le site Web n'abuse pas trop ? Toujours la réponse est "oui". Je comprends bien qu'on fasse la course à la puissance et qu'on se fasse des compromis de principe (sur la vie privée, la confidentialité..) pour prendre la voiture Google qui fait 300 chevaux au lieu de la voiture Mozilla avec son petit moteur de 70 chevaux. Mais personnellement je préfère me demander : Est-ce qu'on a vraiment besoin d'une remorque d'une tonne pour aller chercher le pain en voiture ?
Est-ce normal de charger du code de dizaines de sources différentes et de construire en local un rendu complexe uniquement à partir de données distantes et de règles de plus en plus nombreuses d'interprétation de ces données, juste pour faire quelque chose qu'on savait faire sans navigateur Web dans les années 90 : échanger des messages, lire des mails ou consulter les informations.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Au pied de la lettre
Posté par Faya . Évalué à 4.
Les pages ouvertes sont clairement responsables. Slack, Jenkins, la famille Atlassian, sans compter certains sites d'informations débordants de pub. Mais le problème c'est que Firefox ne se limite pas. Si un site/script demande toute la RAM, bin il la lui donne… Sans compter les erreurs du style
Unresponsive script "chrome://messenger/content/folderPane.js:503"qui font monter le processeur à 100% , sans possibilité de reprendre la main (c'est moins fréquent mais tout aussi bloquant).[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 2.
Mon point c'est que même si ça montre des problèmes chez Firefox.
Personnellement il faudrait que je remonte le problème que j'ai constaté. C'est la page de Jenkins qui affiche les builds en pipeline. Si je la garde ouverte des heures avec un build toutes les 20 minutes, elle consomme beaucoup de ressources. Je présume que les manipulations du DOM que fait Jenkins crée une fuite mémoire sur Firefox (aucune idée de si ça marche bien chez la concurrence), mais je ne suis pas allé plus loin.
[^] # Re: Au pied de la lettre
Posté par Faya . Évalué à 4. Dernière modification le 01 juin 2019 à 03:11.
Et comme j'en fais partie depuis… longtemps, j'ai déjà pratiqué quasiment tout ce que tu as proposé sauf les cgroups. Déjà j'utilise 3 profils différents de FF selon l'activité, j'ai autotab-discard qui décharge les onglets non utilisés depuis 10 minutes, je n'ouvre certains sites que dans Chromium, etc…
Et comme j'ai mis en place ces rustines j'arrive à conserver ma routine et mon butineur favori. Mais avoue que c'est chiant… Je n'imaginais pas en passant sous Arch il y a 10 ans que mon plus gros (seul ?) soucis de stabilité serait mon navigateur. D'ailleurs en ces temps béni je n'avais aucun soucis avec Firefox !
[^] # Re: Au pied de la lettre
Posté par barmic . Évalué à 3.
C'est très très très bizarre. Soit on est beaucoup à avoir beaucoup de chance, soit il y a un problème avec ton utilisation (je ne suis pas que ton utilisation est mauvaise, mais que tu fais des choses ou visite des sites qui font planter ton Firefox) ou ton installation (peut-être que le Firefox d'aujourd'hui est is sensible à une bibliothèque qui ne lui convient pas).
Évidemment, à ta place, j'aurais tendance à investiguer ce qui peut être réglé de ton côté. Si tu ne trouves pas de site qui pose problème, je regarderai au niveaux de ton profile et des extensions.
Mon point n'est pas d'incriminer toi plutôt que Firefox, juste d'essayer de comprendre d'où ça vient. Au contraire ça montre un problème dans Firefox de résilience, mais qui devrait être évitable.
J'imagine que Firefox est plus lent (ou plus consommateur de ressources) que la concurrence, qu'il n'a plus beaucoup de part de marché mais s'il en était au point que tu décrit, il n'existerait plus.
[^] # Re: Au pied de la lettre
Posté par antistress (site web personnel) . Évalué à 3.
moi le seul souci de RAM que j'ai constaté (de longue date, jamais investigué encore) c'est que la consommation RAM augmente au fur et à mesure des fichiers téléchargés
Si je télécharge des fichiers de plusieurs centaines de méga j'ai intêret à redémarrer
[^] # Re: Au pied de la lettre
Posté par Mildred (site web personnel) . Évalué à 3.
Par hasard, ils ne sont pas téléchargés par défaut dans
/tmpqui est un ramfs ?[^] # Re: Au pied de la lettre
Posté par antistress (site web personnel) . Évalué à 4.
non, dans /mnt/data/Téléchargements
[^] # Re: Au pied de la lettre
Posté par niclone (site web personnel) . Évalué à 1.
Peut être en le lançant avec ulimit, genre :
ulimit -d 2000000 && firefox
ou avec -v (virtual memory size), voir les deux…
[^] # Re: Au pied de la lettre
Posté par nico4nicolas . Évalué à 4.
Il n'y a absolument aucun élément concret. J'admets bien volontiers que mon commentaire était inutile. J'ai été vexé de lire que Mozilla Firefox avait été codé avec les pieds des années. Si leur code a été écrit avec les pieds, qu'en est-il du mien ? Au mieux, je l'aurais écrit avec le front ou, de façon plus réaliste, avec le dos.
https://archive.mozilla.org/pub/firefox/releases/1.0/source/
Historiquement, Google a lancé Chrome en réponse à l'émergence de Firefox, 2 extraits (sortis de leur contexte) de Wikipedia :
Cela vient justifier le "ils ont mis Google au pied du mur" en les "forçant" à rentrer dans les browser wars (que Google remporte haut la main).
Dans tous les cas, je te remercie d'avoir élevé la discussion qui volait au ras du sol.
[^] # Re: Au pied de la lettre
Posté par LaBienPensanceMaTuer . Évalué à 3.
Et désolé si je t'ai vexé, en particulier si tu es contributeur au projet.
J'ai volontairement un peu forcé le trait car l'auteur du journal l'avait fait dans l'autre sens… et de façon assez peu objective au final.
Bien que libriste, utilisateur quotidien de GNU/Linux et son écosystème (en particulier Firefox), j'ai toujours du mal avec le manque d'objectivité ;-)
Firefox reste un excellent produit, surtout venant d'une communauté de développeur pour beaucoup bénévoles.
Ok, ce contexte est le bienvenue :)
[^] # Re: Au pied de la lettre
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 28 mai 2019 à 14:48.
J'assume la subjectivité d'un journal ;)
Et je redis qu'Intel s'en sort honteusement bien dans cette affaire, étant donné qu'il vend ses processeurs au prix de leurs performances et qu'il y a donc préjudice pour ses clients dont moi.
# désactivez use smooth scrolling
Posté par Gabin3 . Évalué à 1.
Mon seul manque après avoir goûté à Chrome, c'était la rapidité du scroll et je l'ai retrouvée sur Firefox en désactivant use smooth scrolling. A part ça, je n'ai rien à envier à Chrome.
# Linux 5.3 Could Finally See FSGSBASE - Performance Improvements Back To Ivybridge
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 17 juin 2019 à 23:58.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.3-FSGSBASE
Je n'ai pas les compétences techniques pour savoir si c'est une bonne nouvelle ou si ça ouvre de nouvelles brèches pour compenser les pertes de performances lié au colmatage des anciennes brèches, ce qui pourrait être lassant à force ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.