En écrivant ce billet, pas une seconde (je le jure :-)) je n'imaginais que Google allait lancer cette bombe atomique que représente Native Client.
Pour être franc, après ce commentaire d'alex suite à mes réflexions sur la stratégie de Google, j'ai commencé par feuilleter les quelques articles de presse ici ou là annonçant la nouvelle. Evidemment, pour le technicien que je suis, ni 01 ici, ni ZdNet n'ont réussit concrètement à m'expliquer l'architecture de NC (au passage, les initiales de Native Client sont les mêmes que Network Computer, CQFD). J'ai donc pris le taureau par les cornes (décidément, c'est la semaine exploratoire après JavaFX) et parcouru les documentations techniques et whitepaper disponibles sur le site.
Il ne m'a pas fallu bien longtemps pour comprendre que j'avais affaire à ce qui deviendra bientôt une véritable bombe atomique technologique.
Suite:
Le chaînon manquant était donc là, sous nos yeux, dans les cartons, silencieux. Le fameux rêve que carressait Google depuis des années allait enfin prendre forme.
Donc oui, Native Client "est", je dis bien "est" un mini système d'exploitation destiné à s'exécuter dans un navigateur. Voilà pour la version courte. Pour les détails, nous y venons.
Tout le monde sait aujourd'hui qu'on est capable d'exécuter un jeu d'instruction (natif) quelconque par le biais d'une machine virtuelle. VMWare, VirtualPC et VirtualBox nous démontrent tous les jours que le concept de multi-plateformes est une réalité. A noter que je parle bien "d'instructions natives", pas de "byte-code" intermédiaire transformé en x86 après le passage d'un JIT (Just In time Compiler). Pour peu qu'on est ait réglé quelques détails d'implémentation tels que l'alignement, la gestion des threads et la communication inter-process, il est tout à fait possible d'exécuter une machine virtuelle au sein d'un navigateur via un plugin. Toute l'ingéniosité de Google a été de prendre ses distances avec l'architecture des JVM telles qu'on la connait pour se focaliser sur l'essentiel.
Une machine virtuelle interprétant du byte-code est par définition lente. Car elle doit non seulement interpréter un jeu d'instruction intermédiaire, mais ensuite Jitter (c'est à dire convertir en langage machine natif) ce byte-code pour l'exécuter dans un contexte "managé". Par managé, j'entends Ramasse miette + Gestion des threads + Exception, etc.... Le moteur Flash est une machine virtuelle basée sur du Byte Code (voir ici un désassembleur de byte Code flash). La CLR de .NET est une machine virtuelle basée sur le byte code MSIL. Java utilise le fameux byte-code Java. Native Client n'utilise PAS de JIT, ni de machine virtuelle, il exécute directement du code natif. Et pas n'importe lequel. En effet, quel est le jeu d'instruction le plus largement supporté aujourd'hui sur le marché ? x86. Que ce soit un MAC, un Linux ou un XP/Vista, ces trois OS ont en commun le même jeu d'instruction x86 (depuis peu pour MAC d'ailleurs).
Le runtime de Google est une sorte de conteneur Elf (le format binaire des exécutables natifs), il s'appelle d'ailleurs Secure Elf Loader. La seule restriction de cette approche est de s'interdire pour l'instant les jeux d'instruction ARM et PPC (plutôt utilisé pour les serveurs et les mobiles soit dit en passant).
Si tout cela est possible, c'est parce que Google a pris soin de modifier le compilateur gcc pour générer des binaires compatibles NaCL. Notamment la question récurrente de l'alignement, le codage du return (équivalent du longjump) et quelques détails d'implémentation. Je quote ici le contenu exacte de ces modifications GCC pour les puristes :
We modifed gcc for NaCl by changing the alignment of function entries (-falign-functions) to 32 bytes and by changing the alignment of the targets branches (-falign-jumps) to 32 bytes. We also changed gcc to use nacljmp for indirect control transfers, including indirect calls and all returns. We made more signi?cant changes to the assembler, to implement NaCl's block align-ment requirements. To implement returns, the assembler ensures that call instructions always appear in the final bytes of a 32 byte block. We also modified the assembler to implement indirect control transfer sequences by expanding the nacljmp pseudo-instruction as a properly aligned consecutive block of bytes. To facilitate testing we added support to use a longer nacljmp sequence, align the text base, and use an and and or that uses relocations as masks.
Après quelques tests, il s'avère que l'overhead induit par ces petits aménagements pénalisent le runtime par rapport à du "vrai" natif de ... 1%. Comparez ce chiffre à l'overhead de la JVM Java ou de la CLR et vous comprendrez tout l'intérêt d'un runtime x86 patché.
La Sandbox
Evidemment, le simple fait d'exécuter des instructions natives dans un navigateur soulève instinctivement un sentiment de défiance par rapport à la sécurité. Quid des accès hors contexte mémoire (JMP non protégé, accès à d'autres zones mémoires, etc ...). Google offre là un superbe terreau pour l'exécution de virus et autres chevaux de troie.
Pour résoudre ce problème, la société a construit une sorte de bac à sable ou sandbox (procédé également utilisé par les VM classiques) avec un pré-vérificateur de code. A l'exécution, un processus fils NaCl est lancé avec les traces activées. Lorsqu'une instruction tracée sort du cadre de la liste blanche (déterminée à l'avance), elle est interceptée puis le processus est automatiquement tué. Comme c'est un fils, le père (à fortiori le processus du navigateur) reste intègre. Simple et efficace.
La sandbox assure également que les processus NaCl n'accéderont pas aux drivers de l'OS cible ni leur noyau. A noter que certains OS se prémunissent déjà des accès extra-contexte via des mécanismes d'isolation mémoire.
Pour couronner le tout, le runtime NaCl intègre un ensemble de services techniques, souvent l'apanage des systèmes d'exploitation d'ailleurs ; Un noyau POSIX (Thread, E/S, ...) et des APIs de communication (Inter/Intra processus, mémoire partagée, etc ...).
Qu'est-ce que cela signifie concrètement ?
C'est à ce moment là qu'on est censé avoir la chaire de poule. NaCl n'est ni plus ni moins qu'un mini-système d'exploitation embarqué dans le navigateur. Contrairement à Flash, Silverlight ou JavaFX, NaCl s'éxécute en mode natif sans compilateur JIT. Les performances sont donc largement supérieures à ses principaux rivaux. Et pour enfoncer le clou, il dispose d'un moteur de rendu vectoriel (c'est déjà le cas dans la version alpha disponible sur le site) lui permettant d'exécuter des applications graphiques à vitesse grand V.
Mais quelles sont ses défauts alors ?
Evidemment, si les choses étaient aussi simples, Google seraient d'ici un an ou deux le maître incontesté des architectures logicielles. Non, la réalité est plus complexe. Car, si Google joue avec NaCl sur le terrain des performances, il perd également en chemin celui de la simplicité du développement. Avec NaCl, on refait un retour d'une dizaine d'années en arrière à l'époque du C et du malloc() avec la gestion des threads à la main. Aucun développeur n'est prêt aujourd'hui à troquer sa JVM Java ou sa CLR contre du bon vieux code C ou C++ des années 90. La firme n'arrive déjà pas à séduire la communauté des développeurs avec sa plateforme AppEngine de Cloud Computing basée sur Python. Si un ou plusieurs langages de plus haut niveau ne font pas leur apparition, cette magnifique plateforme risque de disparaître aussi vite qu'elle est apparue. Or, pour proposer un langage objet à la Java ou C#, il faudra passer par l'étape VM, à moins qu'ils ne génèrent directement du code x86 sans passer le JIT. Une équation qui semble difficile à résoudre. Le prix à payer pour plus de performances est souvent lourd en phase de codage. Qui plus est, il y a un adage connu qui dit la chose suivante : "Those that don't understand java are doomed to repeat it.".
Conclusion
On le pressentait tous, Google ne pouvait pas rester indéfiniment spectateur dans la bataille que se livre Microsoft, Sun et Adobe sur le Web de demain. Avec NaCl, il a clairement posé les premières briques de l'outil qui lui permettra de dominer toute la chaîne du Web. De A à Z.
Il faut se rendre à l'évidence, la virtualisation a radicalement changé l'approche et la vision que nous avons du système d'exploitation. Un OS est devenu une commodité ("comodity" comme disent les anglo-saxons). Le navigateur est la machine virtuelle qui nous permettra de lancer les applications Cloud de demain, hébergé on ne sait où par on ne sait qui. Le marché est désormais prévenu, les dés sont jetés. Une nouvelle ère s'annonce...
Flux de commentaires pour cet article
Je pousserai ta métaphore de la bombe atomique. J'irai plus loin, NaCl (le nom rigolo de ce concept rigolo) c'est pas de la bombe atomique, c'est Tchernobyl. J'ai dû regarder mon calendrier pour vérifier qu'on était pas le premier avril. Ou un running gag dans slashdot. Mais non.
Résumons:
* Un véritable OS dans le browser. Euh, non, c'est un truc qui vérifie vaguement de l'assembleur, moins bien que ne le fait une JVM ou une CLR au hasard. Pas de scheduling de threads, pas de gestion de mémoire, pas d'interruptions, pas d'API. En gros si un OS c'est DOS, là oui, NaCl est un véritable OS.
* Des super performances. Euh, non. Il y a un truc qui s'appelle le JIT qui permet de compiler dans un assembleur. En x86 ! en x64 ! sur ARM ! Et c'est dans une JVM ou une CLR ! De la bombe atomique ! Et Javascript avec V8, Tamarin, SpiderMonkey utilise des approches plus malines encore pour des performances tout à fait acceptables. Et ça sert à quoi de l'assembleur dans le browser au fait ? Ah oui, à faire tourner Quake et à faire un encodeur vidéo. Yawn. C'est vrai que ça manque les encodeurs vidéos en natif. D'ailleurs on n'arrive toujours pas à lire de la vidéo dans un browser. Il était temps que google se penche sur le sujet.
* Un gain de productivité ENORME. Imaginez, vous pouvez faire du RIA en C ! Avec gcc (patché par Google) ! Tout ce que le C a récemment apporté à la productivité du développeur ! Tout le bonheur d'une gestion de mémoire moderne et sans souci, le plaisir de bénéficier d'une programmation dynamique, des bibliothèques pléthoriques, un multithreading aisé et naturel, des toolkits graphiques tous plus beaux et fonctionnels les uns que les autres. De la bombe atomique.
* Une garantie de qualité comme tous les produits grand public de Google. Le célèbre google search et ses trous de sécurité à répétition ! L'ultime Picasa et ses mises à jour tous les dix ans ! Le fabuleux Chrome fabuleusement rapide pendant les dix minutes avant son plantage, multi-plate forme tant qu'on est en Win32 et sans add-ons parce que bon faut pas déconner on va pas permettre à AdBlock de bousiller notre unique source de revenus, la pub.
Honnêtement, je ne comprends pas d'où sort ce truc. Un gag créé à la faveur du 20% d'un employé facétieux ? Ca me fait penser au compilateur .Net qui permettait de faire de l'asp.net en x86 qui compilait en IL pour compiler en x86 en JIT. Mais en moins rigolo. Ou alors c'est à la base d'un autre produit à sortir, un truc qui permettrait d'empêcher AdBlock de virer les pubs codées en dur dans les registres x86, ou euh, non, vraiment je vois pas.
Pour finir j'ai bien rigolé en lisant le titre de l'article d'Ars Technica sur le sujet: "Safer than ActiveX". En anglais on appelle ça To damn with faint praise.
Je partage parfaitement cette analyse, et comme toujours Google est là où on l'attends le moins :
Il ne s'agit pas de communiquer sur un "Google OS", mais sur un "native client" , quand l'heure sera arrivée, Google saura démontrer son avancée technologique.
je pense que tu t'emballes un peu trop en voyant dans Native Client le chaînon manquant de l'offre Google. Pour les raisons de productivité que tu soulignes, Native Client ne peut être directement le socle de déploiement des futures applications RIA, si ce projet survit (c'est un projet de recherche et non en phase beta comme Chrome ou d'autres de Google) il permettra peut être à des éditeurs de faire fonctionner dans un navigateur un OS complet (Linux) ou encore une VM (Java, C#, ...).
Mais dans ce cas pourquoi passer par le plugin Native Client ? Si on est mauvaise langue on peut dire que Native Client propose la même chose que les ActiveX ou les plugins Firefox, il y ajoute la SandBox et peut-être un jour une meilleure portabilité, mais ça n'a de sens que si on ne fait pas confiance aux fournisseurs or vue le modèle de développement proposé par NaCl ce n'est pas tout le monde qui développera des applications pour.
L'argument des performances ne tient pas : le frein à l'adoption de Flash, Silverlight ou JavaFX n'est pas lié à leur capacité de calcul mais à l'éternel problème d'installation d'un plugin.
Ca reste intéressant comme axe de recherche mais, à mon avis, c'est loin d'être un tsunami sur le monde du RIA.
Et puis comme cette période de fin d'année est propice aux prévisions futuristes, je prévois l'abandon de ce projet courant 2010 :-) A moins que ne sorte rapidement un compilateur d'applications GWT vers x86 pour NaCl...
T'es très remonté contre Google dis moi :-)
D'un point de vue technique, NC n'est qu'un brouillon de ce qu'il sera plus tard. Effectivement, on est à des années lumière d'un vrai OS. Mais l'idée est là. Je ne suis pas persuadé non plus que x86 soit la meilleure chose (notamment parce qu'un langage Assembleur est justement conçu pour ne pas être multi-plateformes). Mais c'est une migration en douceur vers le NC ultime.
Pour tout te dire, il y a quelques années, j'avais rédigé un poisson d'avril pour DotNetGuru dans lequel j'évoquais la création d'une carte matérielle destinée à exécuter nativement du bytecode -> http://www.dotnetguru.org/articles/CILCard/PCDotNET.htm.
J'y crois encore. Les architectures matérielles telles qu'elles existent aujourd'hui sont devenues totalement inadaptées aux runtime de plus haut niveau. Remplacer x86 par un jeu d'instruction XY (ByteCode .NET ou JVM) en l'intégrant directement au niveau CPU et Bus logiciel me semble plus intelligent que revenir 10 ans en arrière.
Mais laissons un peu de crédit à NC. On verra bien s'ils nous font coder en C ;-)
Sami
ps: ceci dit j'ai bien rigolé sur la métaphore tchernobyl :-)
Restera la question du déploiement, du code natif qui tourne chez un client, c'est n'est pas pour demain la veille, surtout quand on voit le mal qu'on peut avoir à convaincre certains IT avec des applets Java (et oui ça arrive).
Ceci étant dit, est-ce qu'on sera limité à C ou pourra t'on avoir d'autres langages notamment orienté objet ?
Et on peut rêver qu'une implémentation GWT produise non seulement du Javascript mais aussi ce bytecode x86, qui serait utilisé à pleine vitesse en présence d'un navigateur équipé de NativeClient.
A suivre en tout cas, et on comprend aussi pourquoi Google a voulu SON navigateur, parce qu'il sera le socle de ce Navigateur 2.0 (que dis-je 3.0).
D'ailleurs pourra t'on encore parler de navigateur ou de navig-os ?
Comme Henri le précise bien, Chrome n'est rien de plus que le socle principal de cette plateforme. Imaginons que d'ici deux ou trois ans tout le monde adopte Chrome pour sa rapidité, son efficacité ou sa forte intégration avec les services Google (j'extrapole hein ;-)). Le problème du plugin ne se posera plus vu que nativement Chrome disposera de Native Client.
Les autres enrageront de ne pas pouvoir faire tourner les magnifiques applications compatibles Chrome (pas Quake hein ;-)) et switcheront de navigateurs ou installeront le plugin NC .
Encore une fois, aujourd'hui effectivement c'est du C bas niveau pas très beau. Mais ce n'est qu'un projet de recherche comme vous le soulignez tous. Si demain un langage objet complet fait son apparition et permet d'avoir des applications très riches dans le navigateur, les gens n'hésiteront pas longtemps.
A terme, on peut même se poser la question de l'intérêt du navigateur, un PC capable de booter sur un micro-noyau contenant un Runtime NC minimal (cf projet http://www.thinkgos.com/ ou le projet Joli Cloud de Tarik Krim) suffirait.
Je te l'accorde, pour l'instant techniquement Native Client n'est pas une technologie viable. Mais il faut la voir comme la première brique d'un ouvrage qui se veut bien plus immense.
Attention, je constate, je ne dis pas que ça me fait plaisir :-). J'essaye d'avoir une vision froide et objective sur ce sujet qui instinctivement déchaîne les passions.
Sami
Je suis comme toi j'essaye d'analyser avec le plus de détachement possible (même si suis pro-java et pro-Google ;-))
Si on pousse ta réflexion un cran plus loin, à savoir que nous sommes en 2011 et que Chrome représente 90% du marché : à quoi servirait Native Client puisque qu'il faudra de toute façon ajouter le support de langages de plus haut-niveau. Si Google continue sur GWT il serait plus simple d'intégrer à Chrome une VM (Dalvik?) plutôt que de mettre en avant Native Client.
Native Client pourrait être un plus indéniable s'il ne nécessitait pas une recompilation des applications x86.
Pour terminer tu as totalement raison d'orienter la réflexion sur la pertinence du navigateur à long terme (merci pour le lien vers thinkgos). Avec le développement de la virtualisation et du Cloud computing on peut imaginer des changements assez radicaux dans la façon d'envisager les RIA.
On fera le point dans 5 ans :-)
Content de voir que tu n'as pas pris mal ma ratiocination sur NaCl. Ca devait être l'air frais de l'hotel Ibis dans lequel j'étais exilé, ou le bruit de la Nationale devant mes fenêtres. Et puis je passe pour un idiot après mes vannes sur Chrome alors que l'animal vient de passer RC aujourd'hui.
Cela dit, je ne vois pas trop l'intérêt du machin comme plate-forme utilisable par le développeur. Pour google, sûrement, ça leur permettrait de déployer leur applis maison en virant Java, Flash et Javascript (je ne compte pas Silverlight, pour une fois MS va devoir ratrapper un tel retard en part de marché que c'est vraiment pas gagné pour eux) de la pile logicielle du navigateur.
Mais ce machin est tellement à rebours de toutes les tendances actuelles qu'on se demande ce qu'ils ont fumé.
Le gros focus de Google pour l'instant avec Native Client c'est la sécurité. A noter que les accès mémoire (les JUMP) sont gérés en White List.
Pour en avoir discuté avec des googlers, cela fait quelques temps qu'ils rongeaient leur freins de ne pouvoir en parler avant la release alpha.
Il faut également comprendre que NaCl est, dans un premier temps, utile pour Google en interne pour améliorer la gestion des ressources au sein de leur infrastructure.
Même si l'explication est assez technique, je crois avoir bien compris la subtilité de NaCl (bien que n'étant pas développeur de formation et de profession), c'est donc un exploit car c'est la seul article valable sur le sujet que j'ai pu lire.
Je pense que Flash est et restera la solution la plus performante pour faire des RIA, c'est à dire pour animer du contenu avec du son, de la vidéo, des transitions, des effets spéciaux... Pour les applications en ligne c'est différent car les différentes solutions (Flex, Silverlight, Curl, GWT...) proposent des avantages / inconvénients qu'il faut savoir apprécier en fonction du contexte.
Mais à n'est pas mon propos. En fait je souhaiterais juste que quelqu'un me confirme qq chose à propos de NaCl : Jusqu'à présent les éditeurs de logiciels devaient développer pour 3 plateformes (Windows, Mac et Linux). Avec NaCl, est-ce que la promesse n'est pas de développer une seule fois (en C ou C++) pour les 3 plateformes ?
Ce discours est d'autant plus intéressant pour les éditeurs qu'en plus le problème de la distribution / MaJ de leur logiciel est résolu avec le modèle SaaS (pas de distribution "physique" dans une boite, rien d'installer sur le poste client).
Peut-être qu'au final ce NaCl est surtout une bombe atomique pour l'industrie logicielle plus que pour l'industrie du web (et plus précisément des RIA) où Adobe est encore loin devant ses concurrents.
Est-ce que NaCl ne serait pas une brique supplémentaire (après Chrome et Google Desktop) pour asseoir la suprématie de Google qui petit à petit est en train de paralyser Windows, d'infiltrer Apple (cf. le CEO qui siège au board), d'asphyxier Sun et de tenir à l'écart IBM ?
Bref je pense que le tableau d'ensemble (the Big Picture) est bien plus vaste que nous ne l'imaginions...
/Fred
Merci pour vos retours, c'est vrai qu'il est difficile d'expliquer NaCL qui pour l'instant reste une infrastructure essentiellement technique.
Pour répondre à ta question Fred, oui le but d'NaCl est de proposer un langage universel (l'assembleur x86) qui s'exécuterait sur les 3 plateformes d'une manière native, c'est à dire sans ajouter d'intermédiaire technique comme le ferait une VM Flash ou Java. Une sorte d'OS multi-plateformes.
Sur le reste, c'est à dire la portée et les impacts stratégico-politico-techniques de NaCl, vous vous ferez tous les deux vos opinions respectives sur la chose (même si Fred, tu as finalement déjà un peu évoqué dans ton commentaires les principaux "risques" et "dangers" de la stratégie actuelle de Google).
J'ajoute encore que j'ai une approche de pur technicien dans cet article. Dans les enjeux, NaCl dépasse le simple cadre d'un mini-OS. Evidemment. Mais je suis sûr que vous saurez tous commenter mieux que moi les effets pervers d'un monopole annoncé (hein quoi j'ai dis "monopole"?).
Sami
NB: mais l'avenir n'est pas là ...
On parle de clouding, crée des widgets web sur son OS, crée des widgets sur le web, on crée un OS sur le browser; ... bref pourquoi a -t-on l'idée de faire tout ça ?
Mais bon sang, mais c'est bien sûr, parce que l'OS ne fait pas son boulot tout simplement !
Et oui, plutot que de développer un OS dans le navigateur, mieux vaudrait tout simplement supprimer le bon vieux navigateur qui n'a que trop vécu ...
C'est à l'OS directement de nous proposer des services à distance ...
Oui, une application WORD hébérgée en local ou au Japon devrait pouvoir s'éxécuter de la même façon ...
Visualiser un PDF en local ou au Japon idem ...
Accéder à un site web ... Eh bien un site web ne devrait être qu'une application comme une autre ...
a l'extrême limite en HTML + AJAX, mais franchement si on devait faire un site web local, on ferait mieux non ?
HTTP devrait en somme être un protocole invisible, que l'on n'utilise pas directement, mais sur lequel l'OS repose.
Plus besoin d'AS,de serveurs, ...
All in one: l'OS !
Mais bien sûr Microsoft ne voit pas les choses comme ça ...
Pour moi la vraie question est : Comment va-t-on pouvoir interfacer du JS/HTML avec le C en question ?
Pour l'anecdote, ça me rappelle par certains côtés iXalance (http://www.libsdl.org/projects/ixalance/), un loader de code qui permettait de charger et d'exécuter la même démo en code natif sous BeOS, WIN32 ou Mac.