Le projet Quantum est un projet visant à améliorer les performances de Gecko, initialement c'était limité à l'intégration de composants de Servo mais un sous-projet, Quantum Flow, a été créé et est dédié au refactoring du code existant mais n'a pas de lien avec Servo.
Quantum Flow donne des gains de perf énormes depuis plusieurs mois (comme quoi quand on nettoie son code ça va toujours mieux ;) ) et chaque version de Firefox bénéficie de ces améliorations. Firefox 57 verra l'activation de composants de Servo, en particulier Stylo (parser CSS) ainsi que la nouvelle interface (Photon) qui apporte aussi des gains de performance dans l'interface en elle-même.
Firefox Nightly a donc Flow (derniers patchs) + Stylo + Photon déjà utilisables si tu veux avoir un avant-goût de ce que sera la refonte de Firefox avec la version 57 de novembre. Évidemment c'est une alpha, c'est moins stable et pas pour un utilisateur lambda.
Le petit paragraphe sur Nightly date de novembre et la plupart des fonctionnalités présentées à l'époque sont sorties dans la version grand public :)
Je profite donc de ce billet de sortie pour rappeler qu'un premier pas pour aider Mozilla à développer Firefox mieux et plus rapidement est d'utiliser la version Nightly ! Si vous laissez la télémétrie activée et que vous renvoyez vos rapports de plantage, sa simple utilisation est une aide précieuse pour les développeurs. Si vous rapportez en plus des bugs dans notre bugzilla (https://bugzilla.mozilla.org) c'est évidemment encore mieux mais déjà l'utiliser nous aide à détecter des tas de problèmes et régressions au plus tôt et on préfère faire un retour arrière en 10mn sur un patch intégré il y a 2 jours que passer des heures ou des jours sur le même problème une fois la régression livrée au grand public (voire être forcés de faire une nouvelle version pour un problème qu'on aurait pu découvrir plus tôt).
Tous les développements lourds liés à Quantum arriveront à un moment sur Nigthly, e10s était sur Nightly 1 an avant la version grand public, toutes les nouvelles fonctionnalités sont aussi sur Nightly longtemps avant la version finale.
Évidemment Nightly n'est pas pour tout le monde, ça n'est pas dans les dépôts de votre distro, ça se met à jour (automatiquement) quotidiennement, ça n'a pas le "polish" d'une version finale… mais je pense que si vous lisez LinuxFR c'est que vous avez un certain bagage technique et qu'utiliser une version en plein développement et mettre de temps en temps les mains dans le cambouis ne vous fera pas peur.
IMHO, cela ne veut pas dire qu'il faut aller jusqu'à inclure des extensions dans le cœurs (c'est très mal passé pour la tentative pocket). Car cela augment la taille du logiciel inutilement. L'idée même d'un système d'extension est bien d'avoir un cœur réduit qui soit "étendable".
Oui mais non c'est pas comme ça que ça se passe et heureusement (pour Firefox comme les autres) :)
Historiquement, dans le projet mozilla, de nombreuses fonctionnalités ont existé sous forme d'extensions avant d'intégrer le logiciel de base. Pour donner quelques exemples : les onglets (et oui, en 2002 il fallait une extension appelée MultiZilla pour avoir des onglets !), pouvoir réorganiser les onglets à la souris, le bloqueur de popups, le gestionnaire de téléchargement, la synchronisation des marque-pages, la correction automatiques des erreurs courantes de saisie d'une url, annuler la fermeture d'un onglet, "copier et aller" dans le champ d'adresse, zoomer une image, la correction orthographique dans les formulaires, l'autocomplétion des champs de formulaire, zoomer/dézoomer la page ou le texte, le partage de liens, épingler des onglets, le mode plein écran…
Personne ne voudrait utiliser un navigateur sans ces fonctionnalités parce que tout le monde considère qu'elles font parties des fonctionnalités attendues du logiciel mais ce n'a pas toujours été le cas et je me souviens encore de débats d'il y a une quinzaine d'années qui disaient que les onglets étaient une fonctionnalité uniquement pour les utilisateurs très avertis et que ça ne devrait pas être intégré dans Netscape 6.
Donc ta logique c'est que PHP c'est sale initialement et que puisque le langage s'améliore avec le temps et qu'il faut refactoriser du code d'il y a 15 ans pour enlever des trucs sales qui ont disparu depuis des années du langage, PHP est sale parce qu'il s'améliore et donc te force aujourd'hui à coder plus proprement ? Donc quoi que fassent les devs de PHP, avec cette logique, c'est mal, autant dire que tu souhaites que le langage n'évolue pas pour ne pas avoir à faire évoluer du vieux code. Au passage, migrer une appli d'une version non supportée depuis une dizaine d'année à PHP 5.4 qui n'est plus non plus supportée, c'est pas très malin, l'effort de portage vers 5.6 aurait été le même et bien plus pérenne. Et si on prend la même échelle de temps entre PHP 4 et 5.4, migrer une appli Python 1.6 à 3.2 ça se fait sans douleur peut-être ? Est-ce même faisable par rapport à PHP ?
HTML 5 est aussi douteux par rapport à XHTML, Javascript a un système de types encore plus bizarre que celui de PHP (et 'use strict' c'est quand même bien similaire à declare(strict=1) dans PHP). Et pourtant, malgré leurs défauts ce sont ces langages qui dominent le web et de très très loin, tout simplement parce qu'ils sont pragmatiques et qu'ils permettent à tous de créer pour le web. Le web ne migrera pas à Haskell ou autre langage "pur", même s'il y aura de plus en plus de langages qui correspondent à la résolution de problématiques serveur spécifiques, je suis ravi que l'élitisme (dans le plus mauvais sens du terme, qui est de faire tout ce qui est possible pour que ceux qui ne font pas partie du "sérail" de l'informatique pro) ne soient pas gagnants et que la création sur le web reste le plus ouvert possible au plus grand nombre. De manière générale, je ne comprends pas comment on peut détester un langage au point de perdre son temps à le basher partout sur les news le concernant, personnellement par exemple je n'aime pas Python, je suis un hérétique, j'en fais au boulot quand je suis forcé et je reconnais ses qualités, mais ça ne m'amuse juste pas de faire du Python ou du Django. C'est pas pour ça que je vais aller sur tous les posts concernant les nouveautés de Python pour par exemple regretter que les scripts que j'ai écrit en Python il y a 2 ans ne marchent plus en Python 3 alors que des scripts que j'ai écrit en PHP il y a 10 ans marchent toujours en PHP 7 et rendent le même service à leur utilisateurs. Certains d'entre nous veulent faire du code pour répondre aux besoins de vrais utilisateurs et cela à long terme.
Ceux qui n'aiment pas PHP ont plein de choix aujourd'hui pour utiliser des langages qui leur semblent plus cohérents/propres/religieusement casher pour faire des applis web, mais toujours taper sur PHP sur des points de détail, franchement, c'est puéril. PHP est là sur le long terme, l'écrasante majorité du web est en PHP, ce sont des milliards de lignes de code, ça ne changera pas du jour au lendemain et ce n'est pas parce que PHP existe et évolue en bien que ça nuit aux autres langages.
De la même manière, la syntaxe et la grammaire du français, de l'anglais et de toutes les langues dans le monde sont complètement dinques, et pourtant le monde ne parle pas en esperanto, un langage bien propre, bien pur, sans aucune incohérence, le monde doit être très con de préférer des langues compliquées à des langues bien conçues à la cohérence parfaite comme l'Esperanto ou le Volapük…
C'est pas ce que m'a dit le lead dev (Frank Paul) qui était tout surpris et heureux de savoir que ça tournait avec PHP 7 (manque de communication entre les devs Dotclear ? ;) )
La différence de perf HHVM/PHP 7 est pas énorme maintenant et j'ai l'impression que HHVM tire surtout son épingle du jeu sur des grosses infras (wikipedia, facebook…) ce qui est normal vu qu'il a été créé pour répondre aux problématiques de Facebook, le plus gros site web au monde (1 milliard d'uttilisateurs connectés en permanence). Par contre HHVM est compatible PHP mais pas entièrement, il y a tout de même de la réécriture de code à mettre en place pour tirer partie de HHVM alors que PHP 7 est largement une solution "drop-in" si on a du code relativement PHP récent.
De mon point de vue donc, PHP 7 est une solution de migration beaucoup plus simple et efficace, par contre si on a du vieux code PHP (genre pre-5.3), à mon avis il y a un gros boulot de nettoyage pour que ça marche dans PHP 7 ou dans HHVM, dans ce cas, vu qu'il faut réécrire plein de trucs, ça peut être intéressant de passer à Hack/HHVM plutôt que migrer à PHP 7.
Après, il est évident que tant php 7 que HHVM sont sur un chemin de convergence, il y a dans PHP 7 des nouveautés prises directement d'HHVM et Facebook participe à l'écosystème PHP, par exemple ils ont fourni la première spec officielle PHP qui a été adoptée par php.net et qui est maintenue conjointement par les deux équipes et pour chaque RFC de PHP 7, les devs HHVM donnent leur feedback et ont aussi un droit de vote.
Personnellement, je pense qu'HHVM a sa place dans l'écosystème PHP, ils ont la possibilité d'avancer plus vite que php.net étant donné leurs ressources humaines et des contraintes plus faibles (pas de consensus communautaire nécessaire par exemple) par contre l'équipe de PHP fait de mon point de vue des choix plus pérenne en regardant ce qui marche dans HHVM (et d'autres langages) et en implémentant que ce qui a un impact réel tout en maintenant une compatibilité ascendante maximale avec les dizaines de milliers de libs php existantes, ce qui n'est pas forcément un objectif d'HHVM qui peut donc implémenter et expérimenter des fonctionnalités plus rapidement mais pas forcément plus proprement. Si on lit la liste php-internals, on voit que même des devs facebook disent que la syntaxe de la feature X était pas forcément un bon choix et que si PHP.net implémente la feature plus proprement, ils feront évoluer HHVM et Hack pour se rapprocer de l'implém officielle.
Pour moi la grande qualité d'HHVM c'est d'avoir rebooté la communauté PHP sur les questions de performances, la compétition est une bonne chose et la collaboration aussi, sur ce coup, l'investissement de Facebook, Intel et Microsoft en plus de Zend et des centaines de contributeurs bénévole a vraiment fait évoluer le langage mais aussi l'écosystème PHP dans le bon sens.
La plupart des frameworks et CMS actuels sont déjà compatibles PHP 7, évidemment dans leurs versions récentes. De ce que j'ai testé, même des applis qui n'ont pas été testées sous PHP 7 comme Dotclear mais qui ont toujours fait attention à ne pas utiliser de fonctionnalités marquées comme E_DEPRECATED tournent sans aucun changement.
Si je regarde mon propre code, tout ce que j'ai écrit depuis 2011 (quand j'ai commencé à m'intéresser à faire du code plus pérenne, à ne jamais avoir la moindre notice ou warning dans mes logs, à suivre les recommandations PSR…) tourne sans aucun ajustement sous PHP 7. Ce que j'ai écrit avant était plus du PHP 4 que 5 en fait et je ne sais pas s'il tourne avec PHP 7, probablement pas, mais la compatibilité ascendante avec tout ce qui est sorti depuis 5 ans est très bonne en tous cas. Après, c'est à chacun de voir s'il veut passer du temps à migrer du vieux code d'il y a 10 ou 20 ans à PHP 7, mais pour du code en production maintenu correctement et si on ne parle pas de centaines de milliers de lignes de code, ça ne devrait pas être un boulot énorme.
On prendra ces chiffres avec des pincettes du fait de leur description imprécise et de leur origine (Zend), l'entreprise ayant intérêt à présenter PHP sous le meilleur jour possible.
Étant donné que PHP 7 est sorti, il était facile de vérifier par soi-même que effectivement les gains de perf et dé mémoire sont là et pas qu'un peu. Sur une vue spécifique je sais peu optimisées et peu performante sur une de mes applis voici les résultats:
PHP 5.6
Memory peak: 34340864 (32.75MB)
Elapsed time (s): 1.0683
PHP7
Memory peak: 8912896 (8.5MB)
Elapsed time (s): 0.402
Je n'ai pas changé une seule ligne de code de mon appli qui fonctionne parfaitement en PHP 7, apparemment je tombe pile poil dans du code qui a été particulièrement optimisé en PHP 7 (c'est une API externe JSON traitant des arrays de dizaines de milliers d'items à base de regex + un peu de calculs mathématiques), donc dans mon cas, les gains sont encore plus importants que ceux mis en avant par Zend, presque un facteur 3 pour le temps de calcul de la requête, conso mémoire divisée par 4.
Sur la plupart des autres vues plus simples de l'appli, je vois au moins 50% de perfs en plus, tant côté temps de génération que mémoire. Je pourrais probablement mettre la même appli sur un petit VPS pas cher au lieu d'un dédié péchu comme actuellement et ne perdre aucune performance (et inversement, en passant à PHP 7 sur le matos actuel je pourrais servir beaucoup plus de requêtes simultanées, mais j'ai pas encore à gérer le problème de se faire slashdotter ;) ).
Au contraire, la phrase que tu cites est de moins en moins vraie…
(Perso, par exemple, je ne considère pas Google Analytics comme bon pour la santé du web. bon pour celui qui l'utilise, je n'en doute pas, mais la c'est la santé du web qui est mise en avant)
Je veux bien comprendre que tu penses que l'utilisation de GA (même dans une version entreprise qui a des garanties contractuelles sur la vie privée que la version gratuite) soit mauvaise pour le Web et que Mozilla aurait dû choisir autre chose, mais peux-tu nous dire quoi ? Nombreux ont cité Piwik, c'est très bien, mais même l'offre commerciale de Piwik annonce une limite mensuelle d'interactions analysées à 500 millions par mois et les volumes de pages vues des sites Mozilla sont bien plus grands que ça. Donc Mozilla aurait dû installer Piwik sur tous ses sites, mettre en place ses propres serveurs et faire marcher ça à une échelle que le projet Piwik visiblement n'est pas capable lui-même de gérer ?
La migration à GTK3 est prise en charge majoritairement par des employés de Redhat et de Collabora, s'ils ne travaillaient pas sur ce portage, ils travailleraient sur d'autres projets de leurs boîtes et pas sur du Firefox, il n'y a donc pas de perte de ressources chez Mozilla pour autre chose.
À ma connaissance, Mozilla n'embarque pas Cairo, il utilise le Cairo du système sous Linux donc je ne pense pas non plus que ce point porterait problème (Mozilla est aussi un des contributeurs code historiques à Cairo).
Personnellement, j'aimerais que Firefox soit encore mieux intégré à Linux, même si son intégration est déjà pas mal, surtout par rapport à Chrome. Par exemple, j'ai un nouveau portable avec une résolution type retina et les navigateurs (ainsi que des applis comme Atom basée sur Webkit) ne suivent pas le scaling système. Pour Chromium c'est juste inutilisable, je lis à peine les titres sur les onglets par exemple. Pour Firefox et Thunderbird, au moins il y a une option pour changer l'échelle du rendu html (et donc d'une grosse partie de l'UI) c'est layout.css.devPixelsPerPx que je mets à 1.20, mais si Firefox était encore mieux intégré au système, il pourrait aller chercher cette info tout seul plutôt que j'aie à la changer dans about:config. Il me semble que le support des écrans HiDPI sous Gnome sera vraiment pris en charge correctement via gtk3/Wayland donc pour moi c'est un bon exemple de ce qu'apporte le portage vers gtk3.
De ce que j'ai lu sur la liste php-internals, ils ne sont pas chauds du tout pour ajouter plus d'alias au langage et ils n'introduiront jamais non plus une cassure complète de la compatibilité ascendante qui reviendrait à tuer tout l'écosystème PHP, donc ça m'étonnerait que ça se fasse, en tout cas pas avec l'approche proposée par ce dev.
La perf semble être l'un des principaux objectifs, il y a aussi des nettoyages cassant légèrement la compatibilité ascendante qu'ils ne se permettaient pas sur 5.x, l'un des gros patchs qui a landé juste après la fusion de la branche PHPNG (réécriture du moteur dans un objectif de perfs) est l'amélioration et l'harmonisation du support 64 bits entre les plateformes (OS) supportés.
Je pense que la principale raison pour laquelle il y a un changement de version majeure est que de nombreuses améliorations voulues par les développeurs ne passeraient pas le vote pour 5.x car ils casseraient (un peu) la compatibilité ascendante. Le système de roadmap de PHP6 a été une catastrophe pour le projet puisque ne parvenant pas à maintenir la branche 5.x et à atteindre tous les objectifs de la 6 en même temps par manque de bras, la 6 n'est jamais sortie mais des fonctionnalités majeures pourtant prêtes sur la branche 6 ne sortaient pas non plus. L'abandon de la 6 a conduit à la 5.3 avec le gros des fonctionnalités backportées, puis en 2011 à un nouveau cycle de release annuel où ils livrent ce qui est prêt quand c'est prêt et tout changement passe par un système de RFC avec patch associé obligatoire plutôt que par une feuille de route yakafokon ;) (plus agile en fait, ils sont aussi passé sur github + travis). Donc pour savoir ce qu'il y aura dans la 7, il faut suivre les RFC (en gros il y a une nouvelle RFC par semaine) et leur implémentation.
s/on donne pas assez/on donne pas du tout/ non ? ;)
Heureusement que Mozilla ne compte pas sur les dons pour vivre, il n'y aurait pas assez pour payer 10 développeurs par an, ça ne doit même pas représenter 0.5% de ses revenus. Et pour être honnête, les dons viennent du grand public, pas des libristes. Si un libriste veut aider, qu'il participe au projet plutôt que de filer 5€ pour se donner bonne conscience, ça aura infiniment plus d'impact ! C'est un vrai projet libre où les bénévoles sont associés à la quasi totalité des décisions, même les plus importantes. Quand on dit « Mozilla fait ceci, Mozilla c'est cela » c'est juste occulter le fait que Mozilla c'est aussi les milliers de bénévoles qui y participent dans le monde. Mozilla ne cesse de faire des appels à contribution dans tous les domaines, gouvernance incluse. Rares sont les participants, nombreux sont les inspecteurs des travaux finis, les arrivés après la bataille, les commentateurs sportifs qui mettent toute leur énergie dans des billets d'humeur assassins plutôt que de changer le monde avec les outils qu'ont leur met à disposition à portée de clic.
La comparaison avec Google est aussi de mon point de vue fausse, il faut éviter de confondre « je ne suis pas d'accord avec Mozilla sur certains points ou nos interprétation divergent » avec « Mozilla sont des salauds sans morale puisqu'ils ne partagent pas mon point de vue sur x, ne veulent pas faire y, ou n'ont pas priorisé z ». Je me souviens du web et du libre avant Mozilla, c'était pas joli joli. Des fois c'est bien aussi de reconnaître que même quand on est pas d'accord sur des parties d'un projet (et je suis le premier à ne pas être d'accord sur tout ce que fait Mozilla alors que je bosse pour eux, j'aimerais aussi qu'on utilise pas Google Analytics pour le site par exemple), l'ensemble du projet a un impact positif sur l'écosystème et que le bilan est globalement bon. Attaquer systématiquement les projets sur des points mineurs, ça s'appelle en anglais du bikesheding, ça sert juste à rien.
OpenSSH, Mozilla, Libreoffice, tous les projets importants du libre attendent que les libristes s'impliquent réellement. Certains le font et font d'ailleurs énormément, j'ai le plaisir et le privilège de bosser avec des centaines de bénévoles chez Mozilla qui ont décidé de prendre les choses à bras le corps et de faire bouger les lignes, j'ai été moi même un de ces bénévoles. Mais il faut reconnaître que la plupart des gens qui s'identifient comme libristes sont sur le bord du terrain, comptent les points et critiquent ceux qui ont le ballon. Combien de projets clefs pour le libre ont moins de 2 développeurs mais 500 personnes sur la mailing liste? Si les sympathisants du libre voulaient bien devenir libristes actifs, le monde serait meilleur, ils se rendraient probablement compte aussi que la critique est facile mais l'art bien difficile ;)
Je sais pas ce que tu cherches en fait, essayer de démontrer que Linux c'est de la merde par rapport à Mac ou Windows ? Je comprends pas en quoi ton message apporte quoi que ce soit de constructif. Firefox est sous linux une appli Linux et se comporte au maximum comme tel. Si tu veux avoir un Firefox identique à celui de Windows et qui correspond à tes critères d'esthétique, tu peux toujours utiliser la version Windows sous Wine, mais ça règlera pas le fait que toutes tes autres applis auront cette barre de titre que tu juges horrible. Dans ce cas là tu peux te faire ton propre thème Gnome, ou alors juste rester sous Mac/Windows.
Faut pas exagérer, en mode plein écran avec Unity (et une extension avec Gnome Shell) il y a plus d'espace pris par la barre de titre. C'est une appli GTK, elle a une barre de titre, c'est juste normal sous Linux. La nouvelle version 29 prend moins de place verticale que la 28 mais on va pas faire des patchs crades pour fusionner artificiellement la barre de titre sous Linux, ça sera pour GTK3 qui permet d'écrire dans la barre de titre. Et puis je connais personne même sous Linux qui n'a pas sa fenêtre maximisée quand il surfe, on dirait que tu découvres que sous Gnome toutes les fenêtres ont une barre de titre :)
Sur ces captures j'ai essayé d'avoir un thème Ubuntu/Gnome assez classique (radiance), il y a d'autres thèmes où la barre est plus petite, Numix par exemple.
J'ai pingué sur Twitter et j'ai proposé des captures équivalentes sous Linux et en français (là ce sont des captures Mac/Windows tirées du web), en attedant qu'un gentil rédacteur veuille bien mettre à jour le billet, tu peux les voir ici: http://chevrel.org/screenshot/linuxfr/
Ceux qui disent que c'est une copie de Chrome sont soit d'une mauvaise foi crasse, soit n'ont jamais ouvert les deux navigateurs côte à côte pour comparer. Il existe une tendance chez certains à idolâtrer tout ce que fait Google et à taper sur Mozilla et Firefox systématiquement. C'est sûrement plus facile de taper sur la communauté d'à côté que de faire vraiment avancer le libre.
Par ailleurs, ces mêmes personnes n'ont jamais critiqué Chrome pour avoir tout copié sur Firefox, rappelons que Chrome est sorti des années après Firefox, que certains des devs de chrome étaient chez Mozilla. Dans les premières versions, des panneaux de préférence complets de Chrome étaient des copies conformes de ceux de Firefox au pixel près, d'où est-ce que vous croyez que les thèmes légers, les extensions ou les outils de webdev ont été copiés dans Chrome ? Donc Chrome aurait le droit de copier Firefox/IE/Safari, ça c'est cool, mais Mozilla n'aurait pas le droit de s'inspirer des autres quand ils ont de bonnes idées ? Le vrai projet libre c'est celui qui réinvente la roue perpétuellement et se moque des besoins des utilisateurs c'est ça ? Parce que vous croyez que quand Google fait une étude d'impact d'UX sur les navigateurs et que Mozilla en fait une, les résultats et donc les conséquences sur le logiciel sont radicalement différents ?
Le truc le plus hallucinant c'est qu'on reproche à un projet libre de parfois s'inspirer d'autres projets sur le code, les idées ou le design. Allô ? C'est la base du libre de pouvoir réutiliser le travail fait par les autres plutôt que de réinventer perpétuellement la roue. Il faudrait maintenant faire du libre mais ne jamais reprendre rien d'aucun autre projet ? Mais faites du proprio ça ira plus vite !
Je me souviens de la sortie initiale de Firefox et donc de la transition de Mozilla Suite à Firefox chez Mozilla, déjà à l'époque on pouvait lire ici-même exactement les mêmes critiques nous reprochant d'avoir tout copié sur IE. Aujourd'hui c'est des débats sur le taux de courbure de l'onglet par rapport à ceux de Chrome, à l'époque c'était des débats sur la forme des flèches et de la couleur de l'icône de maison dans la barre d'outils trop ressemblants à ceux d'Internet Explorer. Je me demande si ce sont les mêmes génies qu'hier qui s'expriment ou s'ils ont eu des enfants :D
Je pense que tu confonds google.com et la page d'accueil intégrée à firefox, about:home, qui contient bien un champ de recherche google mais qui fiat partie de Firefox et donc toutes les annonces faites dessus sont de Mozilla.
A noter que Anthony Ferrara, auteur de la librairie et de l'implémentation de celle-ci dans le cœur de PHP a plusieurs fois dit que le travail de backport du fix de sécurité dans Debian 5.3.3 était mal fait et qu'il ne changerait pas le prérequis à 5.3.7 :)
[^] # Re: Rust, Servo, projet Quantum
Posté par pascalc . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 9. Dernière modification le 11 août 2017 à 15:03.
Ce que tu cherches c'est Firefox Nightly https://nightly.mozilla.org
Le projet Quantum est un projet visant à améliorer les performances de Gecko, initialement c'était limité à l'intégration de composants de Servo mais un sous-projet, Quantum Flow, a été créé et est dédié au refactoring du code existant mais n'a pas de lien avec Servo.
Quantum Flow donne des gains de perf énormes depuis plusieurs mois (comme quoi quand on nettoie son code ça va toujours mieux ;) ) et chaque version de Firefox bénéficie de ces améliorations. Firefox 57 verra l'activation de composants de Servo, en particulier Stylo (parser CSS) ainsi que la nouvelle interface (Photon) qui apporte aussi des gains de performance dans l'interface en elle-même.
Firefox Nightly a donc Flow (derniers patchs) + Stylo + Photon déjà utilisables si tu veux avoir un avant-goût de ce que sera la refonte de Firefox avec la version 57 de novembre. Évidemment c'est une alpha, c'est moins stable et pas pour un utilisateur lambda.
[^] # Re: Ce qui m'interpelle
Posté par pascalc . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à 2.
Sa copine/copain a dû le larguer pour un mozillien, je ne vois que ça ;)
[^] # Re: Avant...
Posté par pascalc . En réponse à la dépêche Firefox zone en version 51 . Évalué à 10.
Si tu appuies sur la touche MAJ de ton clavier en cliquant, c'est le menu contextuel de Firefox qui s'affichera, pas celui imposé par la page.
# Contribuer à mozilla en utilisant Nightly
Posté par pascalc . En réponse à la dépêche Firefox zone en version 51 . Évalué à 10.
Bonjour,
Le petit paragraphe sur Nightly date de novembre et la plupart des fonctionnalités présentées à l'époque sont sorties dans la version grand public :)
Je profite donc de ce billet de sortie pour rappeler qu'un premier pas pour aider Mozilla à développer Firefox mieux et plus rapidement est d'utiliser la version Nightly ! Si vous laissez la télémétrie activée et que vous renvoyez vos rapports de plantage, sa simple utilisation est une aide précieuse pour les développeurs. Si vous rapportez en plus des bugs dans notre bugzilla (https://bugzilla.mozilla.org) c'est évidemment encore mieux mais déjà l'utiliser nous aide à détecter des tas de problèmes et régressions au plus tôt et on préfère faire un retour arrière en 10mn sur un patch intégré il y a 2 jours que passer des heures ou des jours sur le même problème une fois la régression livrée au grand public (voire être forcés de faire une nouvelle version pour un problème qu'on aurait pu découvrir plus tôt).
Si vous voulez en savoir plus sur l'actualité de Nightly en anglais, vous pouvez suivre le blog (https://blog.nightly.mozilla.org/) et le compte Twitter (https://twitter.com/FirefoxNightly/). Et la page de téléchargement est https://nightly.mozilla.org
Tous les développements lourds liés à Quantum arriveront à un moment sur Nigthly, e10s était sur Nightly 1 an avant la version grand public, toutes les nouvelles fonctionnalités sont aussi sur Nightly longtemps avant la version finale.
Évidemment Nightly n'est pas pour tout le monde, ça n'est pas dans les dépôts de votre distro, ça se met à jour (automatiquement) quotidiennement, ça n'a pas le "polish" d'une version finale… mais je pense que si vous lisez LinuxFR c'est que vous avez un certain bagage technique et qu'utiliser une version en plein développement et mettre de temps en temps les mains dans le cambouis ne vous fera pas peur.
Quelques fonctionnalités actuellement activées uniquement sur Nightly 54 pour vous donner une idée :
- Les onglets d'identité contextuels https://tech.mozfr.org/post/2016/09/10/Les-onglets-contextuels-dans-Firefox-Nightly
- De nouveaux thèmes clairs/sombres par défaut proches de ceux de la Dev Edition https://twitter.com/FirefoxNightly/status/820954456829423616
- Electrolysis-multi, on commence cette semaine à augmenter le nombre de processus pour le contenu web
- Un bouton directement dans l'interface pour nous signaler un site incompatible avec Firefox (https://miketaylr.com/posts/2017/01/report-site-issue-button-in-firefox-nightly.html)
- Une plus grande sécurité avec du sandboxing sous Linux (https://groups.google.com/forum/#!searchin/mozilla.dev.platform/linux$20sandbox%7Csort:relevance/mozilla.dev.platform/V-5G9dWJEXo/S9qxkg9EAgAJ)
- De manière générale des performances accrues
- De nombreux petits changements d'interface et de fonctionnement (par exemple un champ de recherche pour les balises <select> de plus de 40 options, un affichage des titres des onglets légèrement différent, un nouveau look pour de nombreux dialogues, widgets et le lecteur vidéo…)
Merci de votre aide !
Pascal Chevrel
(employé Mozilla)
[^] # Re: Flexibilité du développement
Posté par pascalc . En réponse à la dépêche Firefox 50 Cent. Évalué à 10.
Oui mais non c'est pas comme ça que ça se passe et heureusement (pour Firefox comme les autres) :)
Historiquement, dans le projet mozilla, de nombreuses fonctionnalités ont existé sous forme d'extensions avant d'intégrer le logiciel de base. Pour donner quelques exemples : les onglets (et oui, en 2002 il fallait une extension appelée MultiZilla pour avoir des onglets !), pouvoir réorganiser les onglets à la souris, le bloqueur de popups, le gestionnaire de téléchargement, la synchronisation des marque-pages, la correction automatiques des erreurs courantes de saisie d'une url, annuler la fermeture d'un onglet, "copier et aller" dans le champ d'adresse, zoomer une image, la correction orthographique dans les formulaires, l'autocomplétion des champs de formulaire, zoomer/dézoomer la page ou le texte, le partage de liens, épingler des onglets, le mode plein écran…
Personne ne voudrait utiliser un navigateur sans ces fonctionnalités parce que tout le monde considère qu'elles font parties des fonctionnalités attendues du logiciel mais ce n'a pas toujours été le cas et je me souviens encore de débats d'il y a une quinzaine d'années qui disaient que les onglets étaient une fonctionnalité uniquement pour les utilisateurs très avertis et que ça ne devrait pas être intégré dans Netscape 6.
[^] # Re: Typage strict
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 3.
Donc ta logique c'est que PHP c'est sale initialement et que puisque le langage s'améliore avec le temps et qu'il faut refactoriser du code d'il y a 15 ans pour enlever des trucs sales qui ont disparu depuis des années du langage, PHP est sale parce qu'il s'améliore et donc te force aujourd'hui à coder plus proprement ? Donc quoi que fassent les devs de PHP, avec cette logique, c'est mal, autant dire que tu souhaites que le langage n'évolue pas pour ne pas avoir à faire évoluer du vieux code. Au passage, migrer une appli d'une version non supportée depuis une dizaine d'année à PHP 5.4 qui n'est plus non plus supportée, c'est pas très malin, l'effort de portage vers 5.6 aurait été le même et bien plus pérenne. Et si on prend la même échelle de temps entre PHP 4 et 5.4, migrer une appli Python 1.6 à 3.2 ça se fait sans douleur peut-être ? Est-ce même faisable par rapport à PHP ?
[^] # Re: Typage strict
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 8.
HTML 5 est aussi douteux par rapport à XHTML, Javascript a un système de types encore plus bizarre que celui de PHP (et 'use strict' c'est quand même bien similaire à declare(strict=1) dans PHP). Et pourtant, malgré leurs défauts ce sont ces langages qui dominent le web et de très très loin, tout simplement parce qu'ils sont pragmatiques et qu'ils permettent à tous de créer pour le web. Le web ne migrera pas à Haskell ou autre langage "pur", même s'il y aura de plus en plus de langages qui correspondent à la résolution de problématiques serveur spécifiques, je suis ravi que l'élitisme (dans le plus mauvais sens du terme, qui est de faire tout ce qui est possible pour que ceux qui ne font pas partie du "sérail" de l'informatique pro) ne soient pas gagnants et que la création sur le web reste le plus ouvert possible au plus grand nombre. De manière générale, je ne comprends pas comment on peut détester un langage au point de perdre son temps à le basher partout sur les news le concernant, personnellement par exemple je n'aime pas Python, je suis un hérétique, j'en fais au boulot quand je suis forcé et je reconnais ses qualités, mais ça ne m'amuse juste pas de faire du Python ou du Django. C'est pas pour ça que je vais aller sur tous les posts concernant les nouveautés de Python pour par exemple regretter que les scripts que j'ai écrit en Python il y a 2 ans ne marchent plus en Python 3 alors que des scripts que j'ai écrit en PHP il y a 10 ans marchent toujours en PHP 7 et rendent le même service à leur utilisateurs. Certains d'entre nous veulent faire du code pour répondre aux besoins de vrais utilisateurs et cela à long terme.
Ceux qui n'aiment pas PHP ont plein de choix aujourd'hui pour utiliser des langages qui leur semblent plus cohérents/propres/religieusement casher pour faire des applis web, mais toujours taper sur PHP sur des points de détail, franchement, c'est puéril. PHP est là sur le long terme, l'écrasante majorité du web est en PHP, ce sont des milliards de lignes de code, ça ne changera pas du jour au lendemain et ce n'est pas parce que PHP existe et évolue en bien que ça nuit aux autres langages.
De la même manière, la syntaxe et la grammaire du français, de l'anglais et de toutes les langues dans le monde sont complètement dinques, et pourtant le monde ne parle pas en esperanto, un langage bien propre, bien pur, sans aucune incohérence, le monde doit être très con de préférer des langues compliquées à des langues bien conçues à la cohérence parfaite comme l'Esperanto ou le Volapük…
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 3.
C'est pas ce que m'a dit le lead dev (Frank Paul) qui était tout surpris et heureux de savoir que ça tournait avec PHP 7 (manque de communication entre les devs Dotclear ? ;) )
https://twitter.com/franckpaul/status/665543117148397568
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 10. Dernière modification le 10 décembre 2015 à 11:50.
La différence de perf HHVM/PHP 7 est pas énorme maintenant et j'ai l'impression que HHVM tire surtout son épingle du jeu sur des grosses infras (wikipedia, facebook…) ce qui est normal vu qu'il a été créé pour répondre aux problématiques de Facebook, le plus gros site web au monde (1 milliard d'uttilisateurs connectés en permanence). Par contre HHVM est compatible PHP mais pas entièrement, il y a tout de même de la réécriture de code à mettre en place pour tirer partie de HHVM alors que PHP 7 est largement une solution "drop-in" si on a du code relativement PHP récent.
De mon point de vue donc, PHP 7 est une solution de migration beaucoup plus simple et efficace, par contre si on a du vieux code PHP (genre pre-5.3), à mon avis il y a un gros boulot de nettoyage pour que ça marche dans PHP 7 ou dans HHVM, dans ce cas, vu qu'il faut réécrire plein de trucs, ça peut être intéressant de passer à Hack/HHVM plutôt que migrer à PHP 7.
Après, il est évident que tant php 7 que HHVM sont sur un chemin de convergence, il y a dans PHP 7 des nouveautés prises directement d'HHVM et Facebook participe à l'écosystème PHP, par exemple ils ont fourni la première spec officielle PHP qui a été adoptée par php.net et qui est maintenue conjointement par les deux équipes et pour chaque RFC de PHP 7, les devs HHVM donnent leur feedback et ont aussi un droit de vote.
Personnellement, je pense qu'HHVM a sa place dans l'écosystème PHP, ils ont la possibilité d'avancer plus vite que php.net étant donné leurs ressources humaines et des contraintes plus faibles (pas de consensus communautaire nécessaire par exemple) par contre l'équipe de PHP fait de mon point de vue des choix plus pérenne en regardant ce qui marche dans HHVM (et d'autres langages) et en implémentant que ce qui a un impact réel tout en maintenant une compatibilité ascendante maximale avec les dizaines de milliers de libs php existantes, ce qui n'est pas forcément un objectif d'HHVM qui peut donc implémenter et expérimenter des fonctionnalités plus rapidement mais pas forcément plus proprement. Si on lit la liste php-internals, on voit que même des devs facebook disent que la syntaxe de la feature X était pas forcément un bon choix et que si PHP.net implémente la feature plus proprement, ils feront évoluer HHVM et Hack pour se rapprocer de l'implém officielle.
Pour moi la grande qualité d'HHVM c'est d'avoir rebooté la communauté PHP sur les questions de performances, la compétition est une bonne chose et la collaboration aussi, sur ce coup, l'investissement de Facebook, Intel et Microsoft en plus de Zend et des centaines de contributeurs bénévole a vraiment fait évoluer le langage mais aussi l'écosystème PHP dans le bon sens.
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 7.
La plupart des frameworks et CMS actuels sont déjà compatibles PHP 7, évidemment dans leurs versions récentes. De ce que j'ai testé, même des applis qui n'ont pas été testées sous PHP 7 comme Dotclear mais qui ont toujours fait attention à ne pas utiliser de fonctionnalités marquées comme E_DEPRECATED tournent sans aucun changement.
Si je regarde mon propre code, tout ce que j'ai écrit depuis 2011 (quand j'ai commencé à m'intéresser à faire du code plus pérenne, à ne jamais avoir la moindre notice ou warning dans mes logs, à suivre les recommandations PSR…) tourne sans aucun ajustement sous PHP 7. Ce que j'ai écrit avant était plus du PHP 4 que 5 en fait et je ne sais pas s'il tourne avec PHP 7, probablement pas, mais la compatibilité ascendante avec tout ce qui est sorti depuis 5 ans est très bonne en tous cas. Après, c'est à chacun de voir s'il veut passer du temps à migrer du vieux code d'il y a 10 ou 20 ans à PHP 7, mais pour du code en production maintenu correctement et si on ne parle pas de centaines de milliers de lignes de code, ça ne devrait pas être un boulot énorme.
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 8.
Sur OVH, il est déjà possible de passer son mutu en PHP 7:
https://forum.ovh.com/showthread.php/106907-Testez-PHP7-en-avant-premi%C3%A8re
# Gains de perf réels et impressionnant sur mon appli
Posté par pascalc . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 10.
Étant donné que PHP 7 est sorti, il était facile de vérifier par soi-même que effectivement les gains de perf et dé mémoire sont là et pas qu'un peu. Sur une vue spécifique je sais peu optimisées et peu performante sur une de mes applis voici les résultats:
PHP 5.6
Memory peak: 34340864 (32.75MB)
Elapsed time (s): 1.0683
PHP7
Memory peak: 8912896 (8.5MB)
Elapsed time (s): 0.402
Je n'ai pas changé une seule ligne de code de mon appli qui fonctionne parfaitement en PHP 7, apparemment je tombe pile poil dans du code qui a été particulièrement optimisé en PHP 7 (c'est une API externe JSON traitant des arrays de dizaines de milliers d'items à base de regex + un peu de calculs mathématiques), donc dans mon cas, les gains sont encore plus importants que ceux mis en avant par Zend, presque un facteur 3 pour le temps de calcul de la requête, conso mémoire divisée par 4.
Sur la plupart des autres vues plus simples de l'appli, je vois au moins 50% de perfs en plus, tant côté temps de génération que mémoire. Je pourrais probablement mettre la même appli sur un petit VPS pas cher au lieu d'un dédié péchu comme actuellement et ne perdre aucune performance (et inversement, en passant à PHP 7 sur le matos actuel je pourrais servir beaucoup plus de requêtes simultanées, mais j'ai pas encore à gérer le problème de se faire slashdotter ;) ).
[^] # Re: "Promouvoir l’ouverture, l’innovation et la bonne santé du Web"
Posté par pascalc . En réponse au journal Retour sur les décisions, les projets et les polémiques de Mozilla des dernières années. Évalué à 4.
Je veux bien comprendre que tu penses que l'utilisation de GA (même dans une version entreprise qui a des garanties contractuelles sur la vie privée que la version gratuite) soit mauvaise pour le Web et que Mozilla aurait dû choisir autre chose, mais peux-tu nous dire quoi ? Nombreux ont cité Piwik, c'est très bien, mais même l'offre commerciale de Piwik annonce une limite mensuelle d'interactions analysées à 500 millions par mois et les volumes de pages vues des sites Mozilla sont bien plus grands que ça. Donc Mozilla aurait dû installer Piwik sur tous ses sites, mettre en place ses propres serveurs et faire marcher ça à une échelle que le projet Piwik visiblement n'est pas capable lui-même de gérer ?
[^] # Re: Et quid du portage gtk3 ?
Posté par pascalc . En réponse à la dépêche Firefox 35 heures. Évalué à 5.
La migration à GTK3 est prise en charge majoritairement par des employés de Redhat et de Collabora, s'ils ne travaillaient pas sur ce portage, ils travailleraient sur d'autres projets de leurs boîtes et pas sur du Firefox, il n'y a donc pas de perte de ressources chez Mozilla pour autre chose.
Le bug de suivi pour le portage vers gtk3 est celui-là : https://bugzilla.mozilla.org/show_bug.cgi?id=627699
À ma connaissance, Mozilla n'embarque pas Cairo, il utilise le Cairo du système sous Linux donc je ne pense pas non plus que ce point porterait problème (Mozilla est aussi un des contributeurs code historiques à Cairo).
Personnellement, j'aimerais que Firefox soit encore mieux intégré à Linux, même si son intégration est déjà pas mal, surtout par rapport à Chrome. Par exemple, j'ai un nouveau portable avec une résolution type retina et les navigateurs (ainsi que des applis comme Atom basée sur Webkit) ne suivent pas le scaling système. Pour Chromium c'est juste inutilisable, je lis à peine les titres sur les onglets par exemple. Pour Firefox et Thunderbird, au moins il y a une option pour changer l'échelle du rendu html (et donc d'une grosse partie de l'UI) c'est layout.css.devPixelsPerPx que je mets à 1.20, mais si Firefox était encore mieux intégré au système, il pourrait aller chercher cette info tout seul plutôt que j'aie à la changer dans about:config. Il me semble que le support des écrans HiDPI sous Gnome sera vraiment pris en charge correctement via gtk3/Wayland donc pour moi c'est un bon exemple de ce qu'apporte le portage vers gtk3.
[^] # Re: Noms de fonctions dans la bibliothèque standard
Posté par pascalc . En réponse à la dépêche Sortie de PHP 5.6. Évalué à 5.
De ce que j'ai lu sur la liste php-internals, ils ne sont pas chauds du tout pour ajouter plus d'alias au langage et ils n'introduiront jamais non plus une cassure complète de la compatibilité ascendante qui reviendrait à tuer tout l'écosystème PHP, donc ça m'étonnerait que ça se fasse, en tout cas pas avec l'approche proposée par ce dev.
[^] # Re: Objectifs ?
Posté par pascalc . En réponse à la dépêche Sortie de PHP 5.6. Évalué à 10.
La perf semble être l'un des principaux objectifs, il y a aussi des nettoyages cassant légèrement la compatibilité ascendante qu'ils ne se permettaient pas sur 5.x, l'un des gros patchs qui a landé juste après la fusion de la branche PHPNG (réécriture du moteur dans un objectif de perfs) est l'amélioration et l'harmonisation du support 64 bits entre les plateformes (OS) supportés.
La liste des choses déjà implémentées est là:
https://wiki.php.net/rfc#php_70
Je pense que la principale raison pour laquelle il y a un changement de version majeure est que de nombreuses améliorations voulues par les développeurs ne passeraient pas le vote pour 5.x car ils casseraient (un peu) la compatibilité ascendante. Le système de roadmap de PHP6 a été une catastrophe pour le projet puisque ne parvenant pas à maintenir la branche 5.x et à atteindre tous les objectifs de la 6 en même temps par manque de bras, la 6 n'est jamais sortie mais des fonctionnalités majeures pourtant prêtes sur la branche 6 ne sortaient pas non plus. L'abandon de la 6 a conduit à la 5.3 avec le gros des fonctionnalités backportées, puis en 2011 à un nouveau cycle de release annuel où ils livrent ce qui est prêt quand c'est prêt et tout changement passe par un système de RFC avec patch associé obligatoire plutôt que par une feuille de route yakafokon ;) (plus agile en fait, ils sont aussi passé sur github + travis). Donc pour savoir ce qu'il y aura dans la 7, il faut suivre les RFC (en gros il y a une nouvelle RFC par semaine) et leur implémentation.
[^] # Re: Vie privée et Piwik
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 2.
Oui, avec les revues de patch par Mozilla évidemment. On collabore avec Redhat depuis des années sur tout ce qui touche au support Linux.
[^] # Re: Vie privée et Piwik
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 10.
s/on donne pas assez/on donne pas du tout/ non ? ;)
Heureusement que Mozilla ne compte pas sur les dons pour vivre, il n'y aurait pas assez pour payer 10 développeurs par an, ça ne doit même pas représenter 0.5% de ses revenus. Et pour être honnête, les dons viennent du grand public, pas des libristes. Si un libriste veut aider, qu'il participe au projet plutôt que de filer 5€ pour se donner bonne conscience, ça aura infiniment plus d'impact ! C'est un vrai projet libre où les bénévoles sont associés à la quasi totalité des décisions, même les plus importantes. Quand on dit « Mozilla fait ceci, Mozilla c'est cela » c'est juste occulter le fait que Mozilla c'est aussi les milliers de bénévoles qui y participent dans le monde. Mozilla ne cesse de faire des appels à contribution dans tous les domaines, gouvernance incluse. Rares sont les participants, nombreux sont les inspecteurs des travaux finis, les arrivés après la bataille, les commentateurs sportifs qui mettent toute leur énergie dans des billets d'humeur assassins plutôt que de changer le monde avec les outils qu'ont leur met à disposition à portée de clic.
La comparaison avec Google est aussi de mon point de vue fausse, il faut éviter de confondre « je ne suis pas d'accord avec Mozilla sur certains points ou nos interprétation divergent » avec « Mozilla sont des salauds sans morale puisqu'ils ne partagent pas mon point de vue sur x, ne veulent pas faire y, ou n'ont pas priorisé z ». Je me souviens du web et du libre avant Mozilla, c'était pas joli joli. Des fois c'est bien aussi de reconnaître que même quand on est pas d'accord sur des parties d'un projet (et je suis le premier à ne pas être d'accord sur tout ce que fait Mozilla alors que je bosse pour eux, j'aimerais aussi qu'on utilise pas Google Analytics pour le site par exemple), l'ensemble du projet a un impact positif sur l'écosystème et que le bilan est globalement bon. Attaquer systématiquement les projets sur des points mineurs, ça s'appelle en anglais du bikesheding, ça sert juste à rien.
OpenSSH, Mozilla, Libreoffice, tous les projets importants du libre attendent que les libristes s'impliquent réellement. Certains le font et font d'ailleurs énormément, j'ai le plaisir et le privilège de bosser avec des centaines de bénévoles chez Mozilla qui ont décidé de prendre les choses à bras le corps et de faire bouger les lignes, j'ai été moi même un de ces bénévoles. Mais il faut reconnaître que la plupart des gens qui s'identifient comme libristes sont sur le bord du terrain, comptent les points et critiquent ceux qui ont le ballon. Combien de projets clefs pour le libre ont moins de 2 développeurs mais 500 personnes sur la mailing liste? Si les sympathisants du libre voulaient bien devenir libristes actifs, le monde serait meilleur, ils se rendraient probablement compte aussi que la critique est facile mais l'art bien difficile ;)
[^] # Re: Capture d'ecran sous linux ?
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 5.
Je sais pas ce que tu cherches en fait, essayer de démontrer que Linux c'est de la merde par rapport à Mac ou Windows ? Je comprends pas en quoi ton message apporte quoi que ce soit de constructif. Firefox est sous linux une appli Linux et se comporte au maximum comme tel. Si tu veux avoir un Firefox identique à celui de Windows et qui correspond à tes critères d'esthétique, tu peux toujours utiliser la version Windows sous Wine, mais ça règlera pas le fait que toutes tes autres applis auront cette barre de titre que tu juges horrible. Dans ce cas là tu peux te faire ton propre thème Gnome, ou alors juste rester sous Mac/Windows.
[^] # Re: Vie privée et Piwik
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 10.
Qui est maintenu par une seule personne, employé de Mozilla.
[^] # Re: Capture d'ecran sous linux ?
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 3.
Faut pas exagérer, en mode plein écran avec Unity (et une extension avec Gnome Shell) il y a plus d'espace pris par la barre de titre. C'est une appli GTK, elle a une barre de titre, c'est juste normal sous Linux. La nouvelle version 29 prend moins de place verticale que la 28 mais on va pas faire des patchs crades pour fusionner artificiellement la barre de titre sous Linux, ça sera pour GTK3 qui permet d'écrire dans la barre de titre. Et puis je connais personne même sous Linux qui n'a pas sa fenêtre maximisée quand il surfe, on dirait que tu découvres que sous Gnome toutes les fenêtres ont une barre de titre :)
Sur ces captures j'ai essayé d'avoir un thème Ubuntu/Gnome assez classique (radiance), il y a d'autres thèmes où la barre est plus petite, Numix par exemple.
[^] # Re: Capture d'ecran sous linux ?
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 2.
J'ai pingué sur Twitter et j'ai proposé des captures équivalentes sous Linux et en français (là ce sont des captures Mac/Windows tirées du web), en attedant qu'un gentil rédacteur veuille bien mettre à jour le billet, tu peux les voir ici:
http://chevrel.org/screenshot/linuxfr/
[^] # Re: Vie privée
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 10.
+1
Ceux qui disent que c'est une copie de Chrome sont soit d'une mauvaise foi crasse, soit n'ont jamais ouvert les deux navigateurs côte à côte pour comparer. Il existe une tendance chez certains à idolâtrer tout ce que fait Google et à taper sur Mozilla et Firefox systématiquement. C'est sûrement plus facile de taper sur la communauté d'à côté que de faire vraiment avancer le libre.
Par ailleurs, ces mêmes personnes n'ont jamais critiqué Chrome pour avoir tout copié sur Firefox, rappelons que Chrome est sorti des années après Firefox, que certains des devs de chrome étaient chez Mozilla. Dans les premières versions, des panneaux de préférence complets de Chrome étaient des copies conformes de ceux de Firefox au pixel près, d'où est-ce que vous croyez que les thèmes légers, les extensions ou les outils de webdev ont été copiés dans Chrome ? Donc Chrome aurait le droit de copier Firefox/IE/Safari, ça c'est cool, mais Mozilla n'aurait pas le droit de s'inspirer des autres quand ils ont de bonnes idées ? Le vrai projet libre c'est celui qui réinvente la roue perpétuellement et se moque des besoins des utilisateurs c'est ça ? Parce que vous croyez que quand Google fait une étude d'impact d'UX sur les navigateurs et que Mozilla en fait une, les résultats et donc les conséquences sur le logiciel sont radicalement différents ?
Le truc le plus hallucinant c'est qu'on reproche à un projet libre de parfois s'inspirer d'autres projets sur le code, les idées ou le design. Allô ? C'est la base du libre de pouvoir réutiliser le travail fait par les autres plutôt que de réinventer perpétuellement la roue. Il faudrait maintenant faire du libre mais ne jamais reprendre rien d'aucun autre projet ? Mais faites du proprio ça ira plus vite !
Je me souviens de la sortie initiale de Firefox et donc de la transition de Mozilla Suite à Firefox chez Mozilla, déjà à l'époque on pouvait lire ici-même exactement les mêmes critiques nous reprochant d'avoir tout copié sur IE. Aujourd'hui c'est des débats sur le taux de courbure de l'onglet par rapport à ceux de Chrome, à l'époque c'était des débats sur la forme des flèches et de la couleur de l'icône de maison dans la barre d'outils trop ressemblants à ceux d'Internet Explorer. Je me demande si ce sont les mêmes génies qu'hier qui s'expriment ou s'ils ont eu des enfants :D
[^] # Re: Web we want
Posté par pascalc . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 10.
Je pense que tu confonds google.com et la page d'accueil intégrée à firefox, about:home, qui contient bien un champ de recherche google mais qui fiat partie de Firefox et donc toutes les annonces faites dessus sont de Mozilla.
[^] # Re: Version PHP
Posté par pascalc . En réponse à la dépêche Kanboard, un logiciel libre pour gérer ses projets avec la méthode Kanban. Évalué à 1.
A noter que Anthony Ferrara, auteur de la librairie et de l'implémentation de celle-ci dans le cœur de PHP a plusieurs fois dit que le travail de backport du fix de sécurité dans Debian 5.3.3 était mal fait et qu'il ne changerait pas le prérequis à 5.3.7 :)