Alors que Chrome OS déplace le débat au sein du navigateur, ce choix technologique ne va pas sans inconvénients : le code exécutable au sein d'un navigateur est autrement plus lent que du code natif. Un détail qui est d'autant plus gênant que Chrome OS se destine avant tout aux netbooks, qui sont déjà très limités en puissance. Pour y remédier, Google a mis au point une technologie qui semble toute indiquée pour son système d'exploitation.
Commençons par expliquer le pourquoi du comment : les applications exécutables contiennent du code binaire qui s'adresse tant au processeur qu'aux API (Application Programming Interface) du système d'exploitation. En tant que telles, les applications se destinent donc à un couple CPU/OS spécifique et ne peuvent être utilisées sur d'autres plateformes telle quelles. Le langage machine est spécifique à chaque processeur, et il est fastidieux d'apprendre ce langage à chaque fois qu'on programme pour un processeur différent, sans oublier qu'il est assez abscons et difficile d'accès. Afin de rendre la programmation plus accessible, on utilise un langage universel tel que le C, qui est converti dans le langage spécifique à la machine par un compilateur.
Le web se destinant à une multitude de postes clients, il a donc fallu trouver d'autres moyens pour exécuter des instructions, afin que ces opérations soient universelles. Ainsi, toutes les technologies qui exécutent du code côté client (JavaScript, Flash, Shockwave, Java…) sont basées sur une couche d'abstraction matérielle, par le biais d'un langage intermédiaire qui n'est pas compilé mais interprété. Un "interpréteur" spécifique à chaque machine se charge de traduire ce langage universel dans un langage compréhensible par la machine concernée, ce qui se fait au prix d'une exécution bien moins véloce. Par conséquent, toutes les fonctions "lourdes", comme par exemple le décodage d'une vidéo, sont transférées à l'intérieur des interpéteurs, ne laissant aux développeurs que la latitude d'y faire appel sans pouvoir les modifier ou créer leurs propres fonctionnalités évoluées.
L'autre inconvénient de cette approche, c'est que les fonctions en question ne seront disponibles que sur les plateformes qui disposent de l'interpréteur idoine. Il est ainsi impossible de lire les contenus en Shockwave sur une machine tournant sous Linux (à moins de passer par un intermédiaire supplémentaire tel que Wine). C'est notamment pour remédier à ce problème qu'on a intégré nombre de fonctions équivalentes dans le standards HTML 5. L'interpréteur n'est cette fois plus dans un plugin, mais intégré directement dans le navigateur.
La question de la fluidité d'exécution est devenue d'autant plus cruciale avec la multiplication des "web apps" et du "cloud computing" : si un certain nombre de fonctions peuvent être exécutées par le serveur, il reste important de limiter les accès et d'exécuter un certain nombre de fonctions côté client pour plus de réactivité. Les différents navigateurs sont entrés dans une course à la compatibilité et à la rapidité d'exécution de leur moteurs JavaScript précisément pour ces raisons. Mais aussi rapides qu'ils soient, les moteurs JavaScript ne pourront jamais arriver qu'à une fraction de la vitesse d'exécution du code natif. Il existait bien des moyens d'exécuter du code natif, comme par exemple les ActiveX, mais ceux-ci restent non seulement cantonnés à Windows, mais en outre ils posent de sérieux problèmes de sécurité, puisqu'ils sont susceptibles de faire tout un tas de misères à la machine sur laquelle ils s'exécutent.
C'est pour tâcher de remédier à ces différents problèmes que Google a mis en chantier une nouvelle technologie, nommée Native Client (NaCl pour faire plus court, et plus geek, puisque c'est également le symbole chimique du chlorure de sodium). Il s'agit d'un environnement permettant d'exécuter du code natif dans un navigateur web, tout en garantissant une certaine portabilité et plus de sécurité que les ActiveX.
Ainsi, il devient possible d'intégrer du code exécutable dans le navigateur, ce qui permet de faire bien plus de choses qu'avec les alternatives existantes jusqu'ici : créer son propre codec vidéo, intégrer des jeux tels que Quake, etc. Il est possible d'utiliser différents langages, y compris de l'assembleur.
Pour le moment NaCl fonctionne sur Windows, Mac OS X et Linux, mais il ne supporte que les processeurs x86 en 32 bits, cependant Google travaille au support du 64 bits ainsi que des processeurs ARM. Google n'a pas encore précisé comment elle comptait simplifier le support de multiples processeurs pour les développeurs. Le projet en est encore à ses balbutiements, et se présente pour le moment sous la forme… d'un plugin, ce qui va quelque peu à l'encontre des efforts du HTML 5, pourtant soutenus par Google. La firme de Mountain View a cependant d'ores et déjà intégré le code de Native Client dans son navigateur Chrome (quoi que désactivé par défaut), et enjoint les autres acteurs à en faire autant, sachant que NaCl est distribué en open source.
Ca ne suffira malheureusement pas à l'utiliser sur l'iPhone, à moins qu'Apple ne l'intègre elle-même dans une future version de Safari, puisque la licence de l'App Store interdit toute application permettant d'exécuter du code externe arbitraire. Quoi qu'il en soit, Google compte mettre cette fonction à profit dans Chrome OS, ce qui lui permettrait d'avoir des applications intégrées dans le navigateur presque aussi véloces et puissantes que n'importe quel exécutable autonome. Native Client ne permet pas pour le moment d'accéder à la carte graphique, les éléments graphiques sont donc entièrement calculés par le processeur, mais elle compte y mettre bon ordre en interfaçant NaCl avec son autre plugin, O3D, qui ouvrirait ainsi la porte d'OpenGL aux applications natives réalisées par ce biais (voir notre article Google sort un plugin 3D).
En somme, Google résout ici un problème épineux de Chrome OS, mais sachant que les systèmes d'exploitation concurrents n'ont pas les mêmes problématiques, il est difficile d'évaluer dans quelle mesure cette initiative trouvera un écho chez les autres fabricants de matériels et éditeurs de navigateurs. Google se confronte là à une autre quadrature du cercle : les développeurs n'ont d'intérêt que pour les technologies susceptibles de s'adresser à un assez grand nombre d'utilisateurs, et les utilisateurs n'installeront le plugin que s'ils rencontrent des contenus qui le nécessitent. Si NaCl a un intérêt tout trouvé pour les utilisateurs de Chrome OS, il faut encore que cette population atteigne une masse critique suffisante pour justifier l'investissement sur ces développements spécifiques.
Faute de quoi, ceux-ci devront se cantonner aux web apps en JavaScript, universellement reconnues, ce qui limitera la portée et l'intérêt du système d'exploitation de Google. Il ne faudra donc pas trop de la puissance du géant de l'Internet pour imposer ses technologies face à un marché qui ne voit pas toujours d'un très bon œil son expansionnisme.
Commençons par expliquer le pourquoi du comment : les applications exécutables contiennent du code binaire qui s'adresse tant au processeur qu'aux API (Application Programming Interface) du système d'exploitation. En tant que telles, les applications se destinent donc à un couple CPU/OS spécifique et ne peuvent être utilisées sur d'autres plateformes telle quelles. Le langage machine est spécifique à chaque processeur, et il est fastidieux d'apprendre ce langage à chaque fois qu'on programme pour un processeur différent, sans oublier qu'il est assez abscons et difficile d'accès. Afin de rendre la programmation plus accessible, on utilise un langage universel tel que le C, qui est converti dans le langage spécifique à la machine par un compilateur.
Le web se destinant à une multitude de postes clients, il a donc fallu trouver d'autres moyens pour exécuter des instructions, afin que ces opérations soient universelles. Ainsi, toutes les technologies qui exécutent du code côté client (JavaScript, Flash, Shockwave, Java…) sont basées sur une couche d'abstraction matérielle, par le biais d'un langage intermédiaire qui n'est pas compilé mais interprété. Un "interpréteur" spécifique à chaque machine se charge de traduire ce langage universel dans un langage compréhensible par la machine concernée, ce qui se fait au prix d'une exécution bien moins véloce. Par conséquent, toutes les fonctions "lourdes", comme par exemple le décodage d'une vidéo, sont transférées à l'intérieur des interpéteurs, ne laissant aux développeurs que la latitude d'y faire appel sans pouvoir les modifier ou créer leurs propres fonctionnalités évoluées.
L'autre inconvénient de cette approche, c'est que les fonctions en question ne seront disponibles que sur les plateformes qui disposent de l'interpréteur idoine. Il est ainsi impossible de lire les contenus en Shockwave sur une machine tournant sous Linux (à moins de passer par un intermédiaire supplémentaire tel que Wine). C'est notamment pour remédier à ce problème qu'on a intégré nombre de fonctions équivalentes dans le standards HTML 5. L'interpréteur n'est cette fois plus dans un plugin, mais intégré directement dans le navigateur.
La question de la fluidité d'exécution est devenue d'autant plus cruciale avec la multiplication des "web apps" et du "cloud computing" : si un certain nombre de fonctions peuvent être exécutées par le serveur, il reste important de limiter les accès et d'exécuter un certain nombre de fonctions côté client pour plus de réactivité. Les différents navigateurs sont entrés dans une course à la compatibilité et à la rapidité d'exécution de leur moteurs JavaScript précisément pour ces raisons. Mais aussi rapides qu'ils soient, les moteurs JavaScript ne pourront jamais arriver qu'à une fraction de la vitesse d'exécution du code natif. Il existait bien des moyens d'exécuter du code natif, comme par exemple les ActiveX, mais ceux-ci restent non seulement cantonnés à Windows, mais en outre ils posent de sérieux problèmes de sécurité, puisqu'ils sont susceptibles de faire tout un tas de misères à la machine sur laquelle ils s'exécutent.
C'est pour tâcher de remédier à ces différents problèmes que Google a mis en chantier une nouvelle technologie, nommée Native Client (NaCl pour faire plus court, et plus geek, puisque c'est également le symbole chimique du chlorure de sodium). Il s'agit d'un environnement permettant d'exécuter du code natif dans un navigateur web, tout en garantissant une certaine portabilité et plus de sécurité que les ActiveX.
Ainsi, il devient possible d'intégrer du code exécutable dans le navigateur, ce qui permet de faire bien plus de choses qu'avec les alternatives existantes jusqu'ici : créer son propre codec vidéo, intégrer des jeux tels que Quake, etc. Il est possible d'utiliser différents langages, y compris de l'assembleur.
Pour le moment NaCl fonctionne sur Windows, Mac OS X et Linux, mais il ne supporte que les processeurs x86 en 32 bits, cependant Google travaille au support du 64 bits ainsi que des processeurs ARM. Google n'a pas encore précisé comment elle comptait simplifier le support de multiples processeurs pour les développeurs. Le projet en est encore à ses balbutiements, et se présente pour le moment sous la forme… d'un plugin, ce qui va quelque peu à l'encontre des efforts du HTML 5, pourtant soutenus par Google. La firme de Mountain View a cependant d'ores et déjà intégré le code de Native Client dans son navigateur Chrome (quoi que désactivé par défaut), et enjoint les autres acteurs à en faire autant, sachant que NaCl est distribué en open source.
Ca ne suffira malheureusement pas à l'utiliser sur l'iPhone, à moins qu'Apple ne l'intègre elle-même dans une future version de Safari, puisque la licence de l'App Store interdit toute application permettant d'exécuter du code externe arbitraire. Quoi qu'il en soit, Google compte mettre cette fonction à profit dans Chrome OS, ce qui lui permettrait d'avoir des applications intégrées dans le navigateur presque aussi véloces et puissantes que n'importe quel exécutable autonome. Native Client ne permet pas pour le moment d'accéder à la carte graphique, les éléments graphiques sont donc entièrement calculés par le processeur, mais elle compte y mettre bon ordre en interfaçant NaCl avec son autre plugin, O3D, qui ouvrirait ainsi la porte d'OpenGL aux applications natives réalisées par ce biais (voir notre article Google sort un plugin 3D).
En somme, Google résout ici un problème épineux de Chrome OS, mais sachant que les systèmes d'exploitation concurrents n'ont pas les mêmes problématiques, il est difficile d'évaluer dans quelle mesure cette initiative trouvera un écho chez les autres fabricants de matériels et éditeurs de navigateurs. Google se confronte là à une autre quadrature du cercle : les développeurs n'ont d'intérêt que pour les technologies susceptibles de s'adresser à un assez grand nombre d'utilisateurs, et les utilisateurs n'installeront le plugin que s'ils rencontrent des contenus qui le nécessitent. Si NaCl a un intérêt tout trouvé pour les utilisateurs de Chrome OS, il faut encore que cette population atteigne une masse critique suffisante pour justifier l'investissement sur ces développements spécifiques.
Faute de quoi, ceux-ci devront se cantonner aux web apps en JavaScript, universellement reconnues, ce qui limitera la portée et l'intérêt du système d'exploitation de Google. Il ne faudra donc pas trop de la puissance du géant de l'Internet pour imposer ses technologies face à un marché qui ne voit pas toujours d'un très bon œil son expansionnisme.
