Native Client van Google laat x86-code in webapplicatie draaien

Zoek- en advertentiebedrijf Google heeft een eigen variant van Microsofts Activex en Adobes Alchemy ontwikkeld. De Native Client van Google moet het mogelijk maken binnen webapplicaties code uit te voeren.

De Native Client is vooralsnog voornamelijk een onderzoeksproject: Google verwacht nog geen wijdverspreid gebruik van de opensource-technologie. Wel kunnen ontwikkelaars hun programmatuur aanpassen om de software als x86-code direct in de browser te laten draaien. Het doel is om webapplicaties sneller te maken door ze direct toegang tot de rekenkracht van de pc te geven, zodat de vertaalslagen die het gebruik van de browser met zich meebrengt, kunnen worden omzeild. Native Client zou als alternatief voor Googles langverwachte besturingssysteem gezien kunnen worden: het biedt de voordelen van een os in de zin dat Native Client over de systeembronnen kan beschikken, maar is minder complex.

Native Client werkt niet alleen onder Windows, maar is ook beschikbaar voor Mac OS X en Linux. Naast de client-software is uiteraard ook een browser nodig; daarnaast dient de gebruiker Python te installeren om scripts uit te kunnen voeren die voor installatie- en gebruiksgemak moeten zorgen. In een later stadium zal de Python-afhankelijkheid verdwijnen, zo belooft Google. Eenmaal geïnstalleerd kan Native Client software als stand-alone-applicatie uitvoeren, maar deze kan ook via de browser-plugin in bijvoorbeeld Firefox draaien. Om ontwikkelaars te tonen welke mogelijkheden het platform zoal biedt, heeft Google een aantal voorbeelden online gezet.

Applicaties worden met gcc gecompileerd en Google heeft een aantal maatregelen ingesteld die moeten voorkomen dat Native Client-applicaties malware kunnen bevatten. Naast de x86-architectuur werkt Google aan de vertaling van de client naar andere platforms als arm en ppc, zodat onder meer ook mobiele apparaten overweg kunnen met software die voor Native Client is geschreven.

Reacties (47)

[Little Penguin]

Ik zie de toegevoegde waarde van Native Client niet zo. Met de bestaande Netscape Plugin API is nu al mogelijk om extensies in de browser uit te voeren (nu is de NPAPI wel enigszins verouderen, maar die kan bijgewerkt worden zodat deze weer up-to-date is t.o.v. de 21e eeuw). Ook is het, mijns inziens, weer een extra API - bovenop alle bestaande API's.

Het enige voordeel van Native Client zou kunnen zijn dat je één binary hebt die gelijk voor de 3 meest gebruikte besturingssystemen (x86 based) geschikt is, dat is dan een pluspunt van Native Client - zeker als je 'm (zoals hierboven staat) buiten de browser om kunt draaien.

Ook bij het porten naar ARM en PowerPC is dat een voordeel, 1x maken en dan kunnen draaien op Symbian, Linux (Android/OpenMoko), Windows Mobile...

[EvilWhiteDragon]

Zeg maar een beetje zoals het idee is met .NET en java? Ik vraag me serieus af wat hier de meerwaarde van moet zijn, behalve dan dat google vast nog meer tools krijgt om je in de gaten te houden. En natuurlijk dat je nog een extra framework nodig bent, na flash, java, .NET, silverlight etc etc..

[Jaap-Jan]

Die Python afhankelijkheid komt doordat Native Client wordt gecompileerd met behulp van SCons, een alternatief voor de tradionele methode 'make'. Google gaat in een later stadium gewoon de software via installers leveren, zodat de afhankelijkheid van Python verdwijnt.

[Fuzzillogic]

Ja, goed idee, laten we het wiel weer opnieuw uitvinden. Wat kan dit wat Java niet kan, zonder het cross-platform-karakter te verliezen?

Ik snap die jongen van Google niet. Android bouwen ze notabene grotendeels op Java, en in de browser gaat ze weer native code gebruiken, met alle gedonder vandien.

[boe2]

Ach ja, alsof we niets geleerd hebben van "veilige" activeX applicaties: laten we nu maar meteen volledige applicaties native met directe processortoegang draaien vanuit de browser .

Overigens, het is al eerder genoemd, maar hiermee drijf je terug weg van platformonafhankelijkheid in plaats van daarnaartoe te bouwen zoals met gewone web frameworks. De enige reden dat x86 nog bestaat is omdat we er té afhankelijk van zijn en dat wil men nu nog wat versterken...

[Rukapul]

Dit gaat helemaal niet om X86 of niet. Het gaat erom dat webapplicaties via de browser direct resources van het systeem kunnen gebruiken: CPU en wat al niet meer.

Die architectuur heeft zich de afgelopen jaren bewezen niet goed te werken. Het is een eindeloze strijd geworden tegen incompatiblitieit en security vulnerabilities. Wanneer leert de mensheid eens dat een bepaald architectuur / paradigma intrinsiek niet kan werken.

De alternatieven zoals Java hebben ook hun nukken (vendor lock-in, developmentcycles, distributie, kwaliteit), maar zijn vanuit een architectuur oogpunt juist: heldere interfaces, vanaf de start een sandbox and security model, etc.

Het enige wat de mensheid nog kan hopen is dat deze berichtgeving onvolledig is en dat de X86 code in een virtual machine draait met een goed security model. Mocht dit het geval zijn dan is X86 nog een onhandige keuze gezien haar complexiteit.

[Verwijderd]

Laten we dit alsjeblieft niet gaan doen! We zitten nu al veel te hard aan de x86-architectuur vast vanwege de closed source software cultuur. Als het web straks ook nog op voorgecompileerde x86-code gaat draaien, dan komen we er nooit meer vanaf.

Het zou ook een probleem worden voor het opkomende gebruik van internet in telefoons en mini-laptopjes. Die draaien in het algemeen geen x86, en zijn niet krachtig genoeg om het te emuleren.

[ILUsion]

De meeste netbooks draaien juist wel op x86 (alle netbooks waar Windows op kan draaien moeten x86 zijn). Er zijn wel uitzonderingen, maar die zijn heel beperkt. Telefoons is natuurlijk een andere zaak.

Maar inderdaad noem ik dit ook niet direct een positieve vordering: door x86-code over het weg als applicatie aan te bieden, maak je het onmogelijk voor niet-x86-architecturen om die applicatie te gebruiken (tenzij met emulatie, in welk geval het dan beter zou zijn om een platformonafhankelijke manier te vinden; Java, Flash, Python, ... er zijn genoeg mogelijkheden om alles platformonafhankelijk te hebben, en waar elke architectuur tegen gelijkaardige problemen aanloopt). Ik zie het voordeel niet van native code te gaan verspreiden, vermits het me nogal lomp lijkt om zware applicaties over het net te draaien; zodat je normaal ook niet te veel last hebt van een extra platformonafhankelijke laag).

En x86 zal wellicht niet zomaar verdwijnen, maar denk ook eens aan andere apparaten: consoles (Wii, XBox360, PS3, ...) zullen nog steeds belangrijk blijven en volgens mij ook een grotere functie krijgen als surfmachines. Van het moment dat je daar die x86-technologie op wilt draaien, kom je in de problemen, vermits geen enkele van die machines x86 is (de oude XBox wel, maar die is dan weer niet voorzien om mee op internet te gaan zonder allerlei stoten uit te halen).

[Verwijderd]

Euh, ik zie xboxlive niet echt als een stoot, het apparaat was er technisch meer dan op voorbereid, en zelfs dashboard zou aan te passen zijn om een browser, mailclient en chatfunctie te implementeren, dit is echter, net als de beloofde MPC extensies nooit uitontwikkeld omdat de 360 de schappen inmoest en het apparaat spontaan uitgefaseerd werd. Bovendien werden de productieprocessen van de CPU's gestopt dus zou MS zelf P3's met half cache en custom nvidiachips in opdracht moeten laten bakken hadden ze doorgegaan.

[kidde]

alle netbooks waar Windows op kan draaien moeten x86 zijn

Da's niet helemaal waar; Windows CE draait ook op MIPS en ARM.

[roy-t]

Ik snap dit systeem ook niet helemaal, tegenwoordig hebben we interpreted talen zoals.Net en Java waarin je zelfs prima games kan maken en die slechts marginaal achter lopen qua snelheid.

Deze talen zijn platform onafhankelijk (ja mensen zelfs .Net is platform onafhankelijk!) En kunnen dus op elk systeem gebruikt worden waar een Virtual Machine voor geschreven is.

Om dit nu alleen mogelijk te maken voor X86 code lijkt me een grote fout. Zo zorg je er wel even snel voor dat je veel code kunt draaien maar op de lange termijn zorgt dit voor de nieuwe apps voor veel meer werk. (ze moeten immers herschreven/hercompiled worden voor andere platforms en er moet gechecked worden welk platform aanwezig is op de client pc.)

Ook is het zo dat de software nu waarschijnlijk al in een soort van VM draait, dus is er sowieso al een zelfde vertraging als het gebruik van interpreted code.

Google: ik snap 'm niet

[Verwijderd]

Wat is het probleem daarmee?
Het heeft de afgelopen 30 jaar fatsoenlijk gewerkt waarvoor de komende 30 jaar niet?

[Verwijderd]

De afgelopen 30 jaar is de x86-architectuur onwijs uitgebreid. Het is een ingewikkeld monster geworden, wat niet handig is voor embedded toepassingen. Op telefoons zie je veel vaker ARM, en bij de consoles zie je PPC. De x86-architectuur is alleen nog zo populair bij desktop-pc's voor algemeen gebruik (Dell, Apple, zelfbouw) omdat alle closed-source programma's niet native draaien op de betere architecturen.

De afgelopen 30 jaar kon je wel op al die platformen internetten (nouja, de afgelopen 10 jaar ofzo). De iPhone begint een best populair internet-device te worden. Als de komende 30 jaar deze Native Client van Google vaker gebruikt gaat worden, dan zullen de mobiele gebruikers de boot missen.

[Klaus_1250]

Volgens mij ligt het er ook aan dat aan dat alternatieve architecturen nooit een processor fabrikant hadden die tegen de performance en prijs per MIPS van het x86-platform kon opboxen.

De Commodore Amiga en Apple gebruikten het 68k platform. Deed in de begintijd niet onder voor x86, na de 386 konden ze het niet meer bijbenen. (kon je 12 jaar geleden trouwens gewoon mee internetten, alhoewel dat Internet niet te vergelijken is met nu)

Apple is overgegaan op de PPC-architectuur, maar ook dat heeft het op de desktop niet gered qua performance / prijs. En nu gebruiken ze x86.

[kokx]

Tuurlijk redden die andere architecturen het niet op prijs/prestatie. Het budget om te ontwikkelen is er gewoon bijna niet meer. x86 heeft daar gewoon een te groot monopolie voor, terwijl x86 by design gewoon ondergeschikt is aan veel andere modernere architecturen.

[kidde]

dat alternatieve architecturen nooit een processor fabrikant hadden die tegen de performance en prijs per MIPS van het x86-platform kon opboxen.

Maw x86 is goedkoop vergeleken met de concurrenten.

Ooit was Microsoft Windows ook het goedkoopste OS (gratis vziw). Nu is het dat niet meer en de nadelen van afhankelijkheid zijn zichtbaar; o.a. door misbruik van een economische machtspositie door Microsoft.

Zelfde begint langzaam te gelden voor Intel: Ook vermeend misbruik van een economische machtspositie, en iedereen die het in zijn hoofd haalt te concurreren met Intel's core business krijgt geen licenties meer op bepaalde Intel-platforms; recentelijk overkwam VIA dit. In sectoren waar Intel niet zo actief is wordt nu geld gebruikt dat komt uit de markt van de economische marktpositie (x86) om concurrenten uit de markt te drukken - o.a. door onder de kostprijs te verkopen - en daarna als enigste alternatief over te blijven; waarna Intel voor goud kan gaan en meer dan 10x de kostprijs vragen kan; net zoals Microsoft met Windows deed dus.

Deze afhankelijkheid leidt uiteindelijk tot een beperking van de innovatie, en dat is slecht voor de vooruitgang van de techniek.

[Verwijderd]

Het zou ook een probleem worden voor het opkomende gebruik van internet in telefoons en mini-laptopjes. Die draaien in het algemeen geen x86, en zijn niet krachtig genoeg om het te emuleren.

Uh no flame intended maar onder welke steen heb jij gelegen?

mini laptopjes draaien vrijwel allemaal op een Atom of Celeron -> x86
en in de toekomst komt er nog veel meer moois op x86. Ik denk serieus dat ARM het heel moeilijk gaat krijgen.

Daarnaast, het is aan de andere kant wel makkelijk dat je maar 1 architectuur hoeft te ondersteunen. En ook met een desktop kan ik dingen gaan doen die te zwaar zijn voor het beestje, gewoon weten wat je in handen hebt en op basis daarvan iets wel of niet doen. Ik kan ook wel met mijn oude p2 video gaan bewerken maar daar wordt ik ook niet vrolijk van

[kidde]

Daarnaast, het is aan de andere kant wel makkelijk dat je maar 1 architectuur hoeft te ondersteunen.

Jaja, en voor de overheid is het makkelijk als ze maar met één bouwbedrijf hoeven te onderhandelen, voor jouw is het makkelijk als er maar één supermarktketen is in Nederland (makkelijker voor zegeltjes sparen etc.; je weet altijd welke producten wel en niet goed zijn) vooral als dat gekoppeld is aan de enige tankstationketen in Nederland (nog sneller zegeltjes sparen!) en voor Adobe en AutoDesk is het makkelijk software te maken die alleen onder Windows draait. Net zoals het voor OEM's handig is alleen Intel x86 processoren te verkopen; vooral als ze daar geld op toe krijgen.

[blouweKip]

Opzich is dit goed, het grootste probleem op de software markt is nu het feit dat het gros van de software niet os-onfahankelijk is binnen het x86 platform waardoor je dus eigenlijk minder keuze en innovatie hebt.

Als dat kan worden opgelost door zoiets als dit (wat ik overigens niet denk) dan win je daar als consument alleen maar mee, ongeacht de vraag of x86 wel goed is.

[tHe_BiNk]

De kans is groot dat alle mobiele apparaten (smartphones etc.) over 5 jaar ook gewoon x86 kunnen runnen. Dus we zitten er toch echt nog een hele tijd aan vast. En 1 x86 applicatie kunnen runnen op bijna alle apparaten, al dan niet via een web interface, heeft ook zo zijn voordelen.

[SA007]

Volledig met je eens, eigenlijk is x86 een gedrocht van een architectuur.

Die mij maar ARM, cpu die synchroon loopt met je systeem, geen cache nodig, dus hele goedkope en zuinige processors.

Als ik me niet vergis heeft intel met de itanium geprobeerd x86 bij 64 bit 's van de kaart te vegen maar is dat helaas mislukt

[Verwijderd]

waarom zou je zo graag van x86 af willen, omdat er betere alternatieven zijn? het kan me toch jeuken wat voor architectuur er wordt gebruikt, zolang de ontwikkeling van de hardware als de software maar hard vooruit blijft gaan. Wat dat betreft is het juist een groot voordeel dat er een dominante architectuur is.
En het is niet de schuld van x86 dat er een closed source software cultuur is, dat zijn de gebruikers die hier de keuzes voor maken.

[Verwijderd]

En het is niet de schuld van x86 dat er een closed source software cultuur is, dat zijn de gebruikers die hier de keuzes voor maken.

Ik zei het dan ook andersom: het is de schuld van de closed source software cultuur dat de x86-architectuur nog zo volop aanwezig is. Als open source dominant was geweest, dan zou één of andere ultra-parallelle RISC-architectuur nu de klok slaan.

[kidde]

dan zou één of andere ultra-parallelle RISC-architectuur nu de klok slaan.

Zoals je idd. kan zien bij de snelste computer ter wereld; bij supercomputers ís vrije software (tevens open source) dominant, en de snelste daarvan heeft inderdaad geen CISC-architectuur; maar "nona-core" RISCs; waarbij dat 'nona-core' wegens het ontwerp van die processoren vrij eenvoudig uit te breiden is (zeggen de makers zelf).

[WinL]

Grappig....

Kom nou, laat het web waarvoor het web is. Dit ruikt naar:
ik g**l op webapplicaties maar de browser is toch beperkend. Ik ga dit niet toegeven en ik ga geen echte native applicatie bouwen. Dus, maak ik maar iets als ActiveX. Ook al geven wij een anti-malware garantie, zeker zijn kunnen we niet.

Laten we het probleem toch aanpakken bij de wortels. Maak software die native via een simpele muisklik is op te starten van een USB-stick EN in een extra veilige modus kan draaien. Dit laatste is in Vista al mogelijk. Het eerste is een kwestie van fatsoenlijke software schrijven.

[Reactie gewijzigd door WinL op 24 juli 2024 23:57]

[2playgames]

Applicaties over internet is geen slecht idee. Het probleem is de huidige uitwerking waarbij die dingen in de browser draaien en HTML/Javascript gebruiken. Beide horen voor het bekijken van websites (documenten) gebruikt te worden.

Naar mijn mening moet er een echt applicatieplatform komen. Je hebt flash, java, silverlight, etc., maar die draaien allemaal nog op een webpagina, in het browservenster met alle toeters en bellen (en niet te vergeten de vorige-knop, die met veel apps niet samenwerkt).

Wat dat betreft zet Google Chrome al een goede stap met z'n "application shortcut"-functie.

[kidde]

ik g**l op webapplicaties

Wat denk je, het gaat om Google. Een bedrijf dat het moet hebben van controle over hun gebruikers; anders valt er geen geld te verdienen. Controle verwerven over gebruikers door middel van software die via USB-stick verspreid wordt is lastig voor een bedrijf als Google; daar hebben ze niet echt de distributiekanalen voor.
Voor het verspreiden van applicaties via een eigen ActiveX variant is het makkelijker controle te houden over gebruikers en ze gepersonaliseerde advertenties voor hun neus te schuiven.

[jj71]

Dit zal wel handig zijn om bijvoorbeeld Google Earth vanuit de browser te draaien, Google had hier toch een al plugin voor (die alleen op Windows werkt)?

De Native Client zelf is er wel voor Windows, Mac OS X en Linux, maar betekent dit ook dat native code die je in de Native Client draait onafhankelijk is van het besturingssysteem? Of gaat dit ervoor zorgen dat we straks websites krijgen die alleen in Windows werken (omdat de native code gebruik maakt van Win32 calls)?

Ik vraag me eigenlijk af waarom Google dit heeft gemaakt, want zelfs voor heftige 3D-applicaties heb je helemaal geen native x86 code nodig (kijk bijvoorbeeld eens naar NASA World Wind, een soort Google Earth maar dan in platform-onafhankelijk Java).

[Verwijderd]

Ehm?

Copy and Paste van Nasa's website.

NASA World Wind leverages Microsoft .NET technology for rapid development and to easily access open standards such as XML, WMS, and other graphics standards. Real-time 3D graphics are driven by DirectX allowing a wide base of compatibility with accelerated video hardware.

Lijkt mij toch JUIST x86 afhankelijk.

[Verwijderd]

Zowel .NET als DirectX zijn in de basis gewoon platformonafhankelijk. Microsoft heeft er echter alleen voor gekozen om client spul uit te brengen voor x86.

[SuperNull]

Hopelijk pakken ze dit aan met een soort van hypervisor zoals huidige VM's dat doen. Dan kan de code en redelijk snel draaien en toch in een sandbox blijven zodat het niet mogelijk is om de computer van de gebruiker te kapen.
Het probleem van de huidige VMs is dat hardware accelerated DirectX/OpenGL gebruiken problematisch is. Daarnaast zal de browser met een VM aan boort een stuk zwaarder draaien dan we gewent zijn.

Als Google dit kunstje echter goed van de grond kan krijgen, kan het een flinke klap voor MS zijn. Als het trendy wordt om software voor in browsers in plaats van direct voor het OS te schrijven kan het MS nogal wat marktaandeel kosten.

[Reactie gewijzigd door SuperNull op 24 juli 2024 23:57]

[Dingen]

Als Google dit kunstje echter goed van de grond kan krijgen, kan het een flinke klap voor MS zijn. Als het trendy wordt om software voor in browsers in plaats van direct voor het OS te schrijven kan het MS nogal wat marktaandeel kosten.

Daar hoef je niet op te wachten hoor, op dit moment zijn er al vele webapplicaties beschikbaar die een alternatief bieden voor traditionele desktop software. Elke webapplicatie is een bedreiging voor Microsoft, omdat je voor webapplicaties geen Windows nodig hebt. Of dat nou iets simpels als GMail is of een applicatie in zo'n uitgebreide X86-client, maakt niet veel uit.

[kidde]

Elke webapplicatie is een bedreiging voor Microsoft, omdat je voor webapplicaties geen Windows nodig hebt.

Zie daar de reden dat ze met .NET kwamen en dat iedereen proberen op te dringen; een platform waarvoor Windows altijd eerder en betere ondersteuning zal bieden dan andere OSen. Wel jammer voor Microsoft dat Google - een Linux-tent - dat ook snapt en het daarom praktisch niet gebruikt.

[ieperlingetje]

Nog een cliënt in de browser? Laat webapps in de browser draaien en gewone programma's lokaal op de pc aub. Er zijn voorbeelden genoeg dat je hiermee het complete beveiligingsmodel om zeep helpt.

[kidde]

Volgens mij laat InfernoOS zien dat dit niet noodzakelijk het geval hoeft te zijn; al is er helaas niet zoveel bekend rond de veiligheid van de Inferno IE-plugin.