Une réorganisation de Google pour consolider le présent et assurer le futur

Anthony Nelzin-Santos |

Consolider le présent pour assurer le futur, tel semble être le motif de la réorganisation de Google qu’est en train de mener Larry Page. Hier, il a rapproché Android et Chrome OS ; aujourd’hui, il a séparé les cartes et le commerce. Dans les deux cas, il a joué la carte de la cohérence et en a fait bénéficier la division expérimentale Google X.






Larry Page.




La nomination de Sundar Pichai à la tête de la division Android a fait tant de bruit qu’un petit détail du communiqué de presse a failli passer inaperçu : Larry Page invite Andy Rubin à créer de nouveaux « moonshots ». Une expression qui désigne les projets fous de la division Google X, qui travaille notamment sur un ascenseur spatial, une intelligence artificielle passant le test de Turing plus de neuf fois sur dix, une voiture qui se conduit toute seule et enfin les Google Glass.



Rubin pourrait donc rejoindre Google X, ce qui lui colle plutôt bien : cet ingénieur de talent a créé Danger (vendu à Microsoft) et Android (vendu à Google). Jeff Huber, le vice-président en charge de la division Géo et commerce aujourd’hui explosée, a quant à lui confirmé son départ pour Google X. Huber est tout aussi inventif que Rubin : avant de reprendre la division de Marissa Mayer, il dirigeait l’ingénierie de Google. Google X semble donc prendre du poids au sein de la firme de Mountain View : dirigée par Sergei Brin, l’autre fondateur de la société, cette division est responsable de quelques-uns des produits les plus stratégiques pour le futur de Google.



Le remaniement opéré par Larry Page permet donc de mieux cadrer le futur de la société, mais aussi de consolider les activités existantes. Les activités Géo vont ainsi logiquement rejoindre l’équipe recherche, tandis que la division publicité va évidemment hériter des activités Commerce. Sundar Pichai avait prophétisé le rapprochement inévitable d’Android et de Chrome OS, il dirige désormais les deux.

Tags
#Google
avatar Anonyme (non vérifié) | 
Un peu comme a fait apple en faite ?
avatar joneskind | 
Ça fait très James Bond contre Dr No ce projet Google X ^_^. Bon, si Google me fait un jour voyager dans l'espace je veux bien arrêter d'être méchant. Mais je leur demanderai toujours plus de transparence, parce que tout ça c'est bien joli mais ça n'explique pas l'abandon de CalDAV et Google Reader, ou la fermeture sur AdBlock Plus (qui ne sert de toute façon à rien mais qui complique juste les projets de Mâme Michu). Allez Google, arrêtez vos conneries avec "Don't Be Evil".
avatar Wolf | 
C'est bien comme cela on pourra séparer Google en trois entreprises distinctes plus facilement.
avatar patrick86 | 
"le rapprochement inévitable d’Android et de Chrome OS" Là ils ont deux solutions : - soit ils mettent de l'Android dans Chrome OS pour en faire un truc utile ; - soit ils font l'inverse et rendent Android inutile. Quelle option vont-ils choisir ? Après l'abandons de Google Reader et CalDAV, la réponse n'est pas évidente…
avatar lmouillart | 
@patrick86 Comment je le vois ? Android intègre le runtime PNaCI soit au sein de Chrome (je penche pour cela), soit directement. L’intérêt ? Que les applications C/C++ tournent indifféremment sur ARM/Intel et Linux,OS X ou Windows
avatar Hari-seldon | 
Pour le test de tu ring il fait que la Logic floue soit au point et que la machine comprenne des concept et pas une chose specifique pointant vers un truc dans sa mémoire preinscrit. Un peu comme la différence entre nos langage ecrit et les idéogrammes japonais ( je schématise bien sur)
avatar joneskind | 
@lmouillart : Tu veux dire que le navigateur soit capable d'exécuter du code via un plugin en quelque sorte ? T'as pas peur que ça fasse double effet Java avec failles de sécurité et compagnie ? Ça me semble un peu dangereux, mais je t'avoue ne pas bien comprendre comment tout ça fonctionne. Si t'as 2 mn à m'accorder je suis preneur. ^_^
avatar tap | 
@joneskind: Actuellement Chrome OS fait déjà fonctionner des apps C/C++ via NaCl, voir par exemple From Dust : https://chrome.google.com/webstore/detail/from-dust/anelkojiepicmcldgnmkplocifmegpfj?hl=fr C'est carrément l'avenir de Chrome OS ce machin.
avatar LossId | 
@ joneskind : c'est quoi ton trus avec AdBlock Plus ?Tu peux être plus précis ?
avatar Fingah | 
@joneskind cela s'appelle NativeClient (d'où le NaCl comme diminutif et le "salt&pepper naming") et ça se passe par ici: https://developers.google.com/native-client/ l'aspect sécurité devrait être pas trop mal vu que le toolchain (compilateur, linker, ...) gère le sandboxing; la grosse question est plus du côté des performances même si l'API qui fait le lien entre l'appli web (HTML/Javascript) et le code (C/C++ mais d'autres langages seront très probablement ajoutés) est assez propre
avatar Fingah | 
@lmouillart "Que les applications C/C++ tournent indifféremment sur ARM/Intel et Linux,OS X ou Windows" non ce n'est pas le but premier de NativeClient (enfin la partie ARM/Intel plus ou moins) mais il n'y a pas de caractère multi-plateforme
avatar oomu | 
ha oui, NaCl, l'excellent cadeau pour les faiseurs de virus et autre pirates d'ordinateurs... rendons toujours plus simple l'exécution de code arbitraire NATIF au processeur depuis internet, et on verra ce qui se passe. Bien sur le sandbox sera imparable, mais évidemment que le processeur n'aura aucun bug d'escalade. - Sincèrement, je vois toujours ça comme une catastrophique fausse bonne idée. Déjà qu'avec du code interprété arbitraire récupéré depuis la jungle sauv.. internet, on a des problèmes, alors qu'au moins ce code peut être nettoyé, transformé, bridé, etc Avec du natif, non seulement ça complique tout éventuel bridage mais ouvre potentiellement la voie à ce qu'il soit, par erreur, interprété par le cpu bien au delà du cloisonnement prévu, avec plein accès, étant du code natif. Et non, le fait qu'il faille déclarer les zones mémoires dites exécutable pour que le CPU exécute, ne protège pas du risque théorique de bug. Le sandboxing d'Os X est un gain intéressant en sécurité, et c'est aussi du code natif, mais c'est loin d'être une protection absolue contre les éventuels bugs processeurs et systèmes. Ce qui limite le danger des Applications sur Os x, c'est que, généralement, on ne télécharge pas toutes les 5mn des applications de sites mystérieux sur internet. (sauf les fous et les pingres). Apple offre l'app store comme dépôt un minimum surveillé et les développeurs peuvent signer leurs programmes pour ajouter un minimum de garantie. Sur OS X les utilisateurs peuvent prendre leurs responsabilités et le téléchargement et exécution d'une Application est une opération relativement lourde et visible. Dans le cas de NaCl ( http://en.wikipedia.org/wiki/Google_Native_Client ), le téléchargement et exécution est rendu beaucoup trop facile, beaucoup trop transparent et beaucoup trop facile de distribuer via des sites piégés.
avatar oomu | 
En gros, faciliter le téléchargement et exécution de code natif au processeur augmente la surface potentielle de BUGS et donc de pièges que des gens vont exploiter.
avatar oomu | 
"non ce n'est pas le but premier de NativeClient (enfin la partie ARM/Intel plus ou moins) mais il n'y a pas de caractère multi-plateforme" encore heureux. Recréer le cataclysme Java, ça suffit une fois !
avatar tap | 
@oomu : pour qu'une app NaCl fonctionne sur Chrome/Chrome OS il faut qu'elle soit sur le Chrome Web Store. Bon on peut désactiver cette protection en ajoutant des flags à Chrome à l'execution de celui ci mais c'est quelque chose de volontaire.
avatar Fingah | 
@oomu c'est pas parce que c'est du code natif que tous les accès (i.e, toutes les possibilités) seront autorisés ... et puis le sandboxing de NativeClient est au niveau du browser pas au niveau de l'OS tu mélanges un peu tout dans ta réponse; NativeClient répond à une problématique simple: pourquoi utiliser du Javascript (ou autre) qui se traîne comme un veau plutôt que du code qui peut tourner à grande vitesse ? (exemple au hasard du rendu 3D) la sécurité dans ce cas est secondaire et je ne pense que le but soit d'avoir du NativeClient partout (ou solutions équivalents, vu que Adobe, Sun, MS bossent tous sur des projets semblables) mais sur des besoins ponctuels
avatar Malcolmm | 
Et en finir avec le passé .
avatar joneskind | 
@LossId : Une restriction qui est passée il n'y a pas longtemps autour d'une histoire de proxy qui ne peut plus se configurer tout seul. C'était une News MacGé.
avatar joneskind | 
@tap : Ok merci pour l'info. Mais comme dit plus bas, j'espère que le Sandboxing va être efficace parce qu'on voit bien avec les failles Java que malgré la VM qui est un bac à sable, c'est pas suffisant pour mettre le système à l'abri.
avatar Fingah | 
faut un peu arrêter le délire ... à partir du moment où tu éxécutes du code sur ta machine que tu n'as pas produit toi même ou relu attentivement il y a un risque pour la sécurité de la machine donc bon ... cliquons et restons zen

CONNEXION UTILISATEUR