Mozilla interrompt le projet Electrolysis d'un Firefox multi-processus
Une première version de Fennec à UI native sans XUL est disponible
Le 2011-11-21 10:25:41, par Idelways, Expert éminent sénior
Pour de meilleures performances et compétitivité, Mozilla avait annoncé l'abandon de la technologie d'interface XUL sur Firefox Mobile. Une décision concrétisée aujourd'hui par la sortie d'une version à interface native sur le canal Nightly.
Des widgets constituent les différents composants de la nouvelle interface (barre d'adresse, contenu, futures extensions, etc.). L'objectif est de réduire le temps de démarrage et offrir une meilleure réactivité et une consommation de mémoire plus économe, assure Mark Finkle, membre de l'équipe de Fennec et auteur de cette capture d'écran :
Concession et clairement pas une révolution. L'abandon de XUL sur mobile peut être perçu comme un compromis douloureux, un retour à la raison pour le navigateur qui a bâti une partie de son succès sur l'extensibilité de la technologie.
Mais ce n'est pas le seul abandon de raison à regretter chez la fondation en cette période.
Les efforts pour munir Firefox de multiprocessus complet viennent d'être mis en pause en raison de la complexité de l'entreprise, annonce Lawrence Mandel, chef de projet à Mozilla. Le projet Electrolysis devait aboutir à une exécution séparée de l'interface et des pages, pour une meilleure sécurité et réactivité de l'interface. Il n'est désormais plus sur la liste des priorités de la fondation aux ressources limitées.
Firefox arrive à exécuter les plug-ins (Flash, QuickTime, Silverlight) dans des processus séparés depuis la version 3.6.4, mais les extensions en XUL et l'interface générale s'exécutent toujours dans le même processus système que les pages. Cette situation limite entre autres les possibilités d'optimisation de la sécurité (sandboxing...) et des performances : exploiter plusieurs coeurs de processeur notamment.
L'interruption du projet Electrolysis peut être perçue comme une conséquence de l'accélération du rythme de développement de Firefox (une version majeure chaque 6 Mois).
L'équipe de développement préfère se concentrer désormais sur de petites initiatives plutôt que de se mobiliser longtemps sur des projets de fonds, lourds investissements : « Convertir un produit établi, comme Firefox, d'une architecture mono- à multiprocessus requière l'implication et la coordination de plusieurs équipes [...] Electrolysis requiert un investissement considérable en ressources et en temps [...] Combien de temps ? À ce point, nous n'avons pas une réponse définitive comme il y a plusieurs [variables] inconnus », explique Lawrence Mandel sur son blog.
Les navigateurs de Google et de Microsoft tournent déjà en multiprocessus au moment où la fondation met temporairement au placard son projet.
N'ayant pas les mêmes moyens matériels ni humains que les deux concurrents géants, cette décision est donc la meilleure chose à faire à condition que Firefox se montre plus présent et plus compétitif dans d'autres volets tels que le mobile et l'open web.
Sources :
Et vous ?
Des widgets constituent les différents composants de la nouvelle interface (barre d'adresse, contenu, futures extensions, etc.). L'objectif est de réduire le temps de démarrage et offrir une meilleure réactivité et une consommation de mémoire plus économe, assure Mark Finkle, membre de l'équipe de Fennec et auteur de cette capture d'écran :
Concession et clairement pas une révolution. L'abandon de XUL sur mobile peut être perçu comme un compromis douloureux, un retour à la raison pour le navigateur qui a bâti une partie de son succès sur l'extensibilité de la technologie.
Mais ce n'est pas le seul abandon de raison à regretter chez la fondation en cette période.
Les efforts pour munir Firefox de multiprocessus complet viennent d'être mis en pause en raison de la complexité de l'entreprise, annonce Lawrence Mandel, chef de projet à Mozilla. Le projet Electrolysis devait aboutir à une exécution séparée de l'interface et des pages, pour une meilleure sécurité et réactivité de l'interface. Il n'est désormais plus sur la liste des priorités de la fondation aux ressources limitées.
Firefox arrive à exécuter les plug-ins (Flash, QuickTime, Silverlight) dans des processus séparés depuis la version 3.6.4, mais les extensions en XUL et l'interface générale s'exécutent toujours dans le même processus système que les pages. Cette situation limite entre autres les possibilités d'optimisation de la sécurité (sandboxing...) et des performances : exploiter plusieurs coeurs de processeur notamment.
L'interruption du projet Electrolysis peut être perçue comme une conséquence de l'accélération du rythme de développement de Firefox (une version majeure chaque 6 Mois).
L'équipe de développement préfère se concentrer désormais sur de petites initiatives plutôt que de se mobiliser longtemps sur des projets de fonds, lourds investissements : « Convertir un produit établi, comme Firefox, d'une architecture mono- à multiprocessus requière l'implication et la coordination de plusieurs équipes [...] Electrolysis requiert un investissement considérable en ressources et en temps [...] Combien de temps ? À ce point, nous n'avons pas une réponse définitive comme il y a plusieurs [variables] inconnus », explique Lawrence Mandel sur son blog.
Les navigateurs de Google et de Microsoft tournent déjà en multiprocessus au moment où la fondation met temporairement au placard son projet.
N'ayant pas les mêmes moyens matériels ni humains que les deux concurrents géants, cette décision est donc la meilleure chose à faire à condition que Firefox se montre plus présent et plus compétitif dans d'autres volets tels que le mobile et l'open web.
Sources :
Et vous ?
-
DonQuicheExpert confirméLe multiprocessus est un bonus sympathique en termes de sécurité mais ça n'est vraiment intéressant que si c'est très bien fait. Pas comme Chrome que j'avais adopté et que je suis définitivement en train de chasser puisque, outre une grosse consommation mémoire, il rame affreusement depuis quelques semaines/mois en présence de nombreux onglets (typiquement : jusqu'à une minute pour charger google.fr alors que l'UI répond correctement et qu'il ne me faut que deux secondes pour basculer sur Fx, ouvrir un onglet et charger la même page) ou face à certains sites (LeMonde.fr). Et j'ai dans l'idée que le multiprocessus n'est pas étranger à ces anomalies même s'il y a un problème dans l'implémentation elle-même.
Outre les problèmes potentiels, même si c'est correctement fait, le bénéfice reste mince et pas indispensable. Qui plus est, refaire l'appli dans ce sens doit effectivement être très lourd et très complexe (pelletées de bogues à la clé) et il est vraisemblable qu'il y ait des projets plus intéressants.le 21/11/2011 à 21:30 -
UtherExpert éminent séniorRien a voir, les itérations courtes n’empêchent pas de travailler sur des évolutions lourdes, au contraire.
Ils ont juste estimé que le rapport travail gain n'était pas suffisant par rapport à ce que permettent de gagner les autres initiatives en cours. Si un jour cela redeviens intéressant, ils s'y remettront.
Il est a noter que dans le cas de Google, ils sont partis de rien ce qui a grandement simplifié les choses.
Je n'ai jamais été convaincu que les gains éventuels du projet méritaient tant d'effort, sans compter la consommation mémoire qui aurait été forcément accrue.
C'est un joli argument marketing, mais l’instabilité de Chrome ne m'a pas convaincu que ça soit la panacée, loin le là.le 21/11/2011 à 13:29 -
danielhagnoulRédacteurBonjour[...] L'équipe de développement préfère se concentrer désormais sur de petites initiatives plutôt que de se mobiliser longtemps sur des projets de fonds, lourds investissements [...] Les navigateurs de Google et de Microsoft tournent déjà en multiprocessus au moment où la fondation met temporairement au placard son projet. [...]
Fâcheuse nouvelle, il est indispensable de garder une émulation entre les navigateurs si l'on ne veut pas retomber dans une période de stagnation à la sauce IE.
Même pour l'avenir des autres navigateurs il est important que Firefox soit compétitif.
Depuis la sortie de Chrome, j'utilisais Firefox et Firebug pour le développement et Chrome pour le reste. Depuis quelques mois, je préfère les outils du développeur de Chrome, intégré au navigateur et plus puissant.
J'utilise et je recommande Firefox, depuis longtemps, mais là je m'interroge et l'avenir de Firefox m'inquiète.le 21/11/2011 à 13:37 -
bhamp0Membre avertiBizarrement, moi c'est l'inverse. Je suis passé sous Chrome parce que Firefox était complètement instable. Et je précise que j'utilise très peu de plugins sous Chrome ou FF, uniquement les intéressants ; sous FF : Adblock ; sous Chrome : Adblock, Mail Checker Plus for Google Mail, Google Tasks.le 21/11/2011 à 14:40
-
David_gMembre éclairéIls sont plus puissant en quoi ? (no troll, j'utilise pas chrome et donc je connais pas les outils de dev de Chrome)intégré au navigateur et plus puissant.le 21/11/2011 à 17:36
-
danielhagnoulRédacteurle 23/11/2011 à 1:47
-
Chuck_NorrisMembre émériteDonc si j'ai bien compris en gros : le fait que Mozilla ait décidé de manière unilatérale sans que personne ne les y oblige à sortir une version toutes les 6 semaines fait qu'il devient impossible d'améliorer le navigateur sur des points essentiels parce que le développement serait trop long pour tenir dans les fameuses 6 semaines définies ? J'ai bon ?le 21/11/2011 à 22:11