Native Client - natív x86 kód futtatása böngészőben

A Google által fejlesztett Native Client egy nyílt forrású (BSDL) technológia, amely lehetővé teszi natív x86 kódok webböngészőben való futtatását. A Native Client fejlesztésének jelenlegi korai szakaszában úgy döntöttek a készítők, hogy kiadják az anyagot szélesebb körű tesztelésre, hogy visszajelzéseket kapjanak a biztonsággal foglalkozóktól és a szélesebb nyílt forrású közösségtől. A fejlesztők remélik, hogy egy nap a Native Client lehetővé teszi majd a webfejlesztők számára, hogy gazdagabb és még dinamikusabb böngésző-alapú alkalmazásokat fejleszthessenek.

A Native Client teszteléséhez le kell tölteni a megfelelő csomagot: Linux, Mac, Windows

A telepítés után futtathatók a demók (például Quake böngészőben). A részletekről bővebbet a Getting Started útmutatóból lehet megtudni.

A Native Client-ről bővebben itt és a projekt weboldalán lehet többet megtudni.

Hozzászólások

Azt hittem a böngésző technológiák egyik alappillére a platformfüggetlenség. Erre nesze itt van ez. Komolyan gondolják?

Remélem a Java Applet sorsára jut ez a kezdeményezés, legalábbis elterjedtségben ...

Ezúton kérnék elnézést a java mikulástól ...

A webböngészőben szivem szerint nem nagyon engednék futtatni semmit, ami csak egy kicsit is kapcsolódhat a rendszerhez, pl. írhat ide - oda..etc

Ha már lesz ez, remélem a scriptblock tudja majd blokkolni...

majd jön a browser kernel modul, lesz 'modprobe firefox' ...

Ez valami vicc? Újra fel akarják találni az ActiveX-et, amikor nagy nehezen sikerült megszabadulni tőle? Nem értem, hogy mire lenne jó.
Webes alkalmazások készítésére, amik kihasználják a kliens erőforrásait, ott van a JavaScript, Flash, Java, Silverlight. Mitől lenne egy x86 kód gazdagabb, dinamikusabb? Mit tudna, amit a felsoroltak nem? Leszámítva a kb. 20% teljesítményt.
Az önálló, asztali programokat, mint amilyen a Quake, pedig mi értelme beleerőltetni a böngésző ablakán belülre? Letöltöm a kódot, elindítom, lesz egy saját ablakkerete, és fut. Böngésző nélkül.

Nem vicc. Szerintem a valódi cél, hogy a stuff fusson ARM, meg PPC alapú vason is (a blogból egy idézet: "We're working on supporting other CPU architectures (such as ARM and PPC) to make this technology work on the many types of devices that connect to the web today."), a korai beharangozó/hírverés meg azért kell, hogy mire odáig jut a dolog, addigra legyen felhasználói bázisa is.

Gondolom, valami zárt, virtualizált környezet ez, saját oprendszer-szerűséggel. Pl. egy Xen/Vmware/stb. guest sem fér hozzá semmihez, amit a host nem enged.
Nem rossz ötlet ez. Ha sikerül nekik, kinyírják vele a Microsoft Silverlight-ját és a Java új applet-szerűségét egyszerre. Hosszabb távon a Flash-t is kinyírhatja.

Ez ott bukik el, hogy a xen/vmware/stb-nek mindenkepp van valami magasabb privilegitasi szinten futo komponense (gondolj a vmware kernel modulra, vagy akar a vmx contextben futo hypervisorra - ennek hianyaban nem hogy nem gyorsabb, de kifejezetten lassabb lesz, mint a jelenlegi megoldasok), ez pedig olyasmi, amit az ember nem szivesen parositana egy web-browserrel.
Persze sandbox-olni lehet ezek nelkul is, kerdes, hogy mennyire lesz konnyen megkerulheto, es mennyire lesz lassu.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Szerintem meg az a 20% nem annyi, hanem esetenként jóval több, ami igenis számít. Próbálj meg pl. linux alatt fullscreenben flash videót nézni... És ha még tényleg platformfüggetlen is, akkor simán életképes lehet a dolog.
És belegondolva, mi az ami nem tetszik az embereknek a plugin-os megoldásoknál általában:
-nem eléggé platformfüggetlen
-gyenge teljesítmény (pl. lassan töltödő java virtuális gép)
Ezekre ad remélhetőleg megoldást a natív kliens. Ha meg nem, akkor szvsz gyorsan el is fog tűnni a süllyesztőben.

+1 Néha úgy érzem, hogy a fejlesztők próbálkozásai meg újítási vágyaik arra, hogy létrehozzanak valami újat lehetőleg a piac-ból megpróbálva hosszabb távra kihasítani egy kisebb szeletet -nem feltétlen áll összhangban azzal a motivációval, hogy az r1 userek rendszere alaptelepítésben megfelelő biztonságú legyen lehetőleg bloatware hülyeségek és mesterségesen generált igények figyelembevétele nélkül.

Azt azér' nem hinném.
Vagy akkor ki lehet Aromó, a fékezhetetlen agyvelejű nyúl, vagy Nagy Zoárd a lépkedő fenyőfa, van talán valahol egy Dömdödöm is, találhatnánk olyan nagyon kék lovat, mint Ló Szerafin, és vajon a többieket: Mikkamakkát, Mamintit, stb, stb, hol keressük? :)
(vajon Lázár Ervin az egyik kedvenc íróm?)

Áhhhh... ne törődj velük...
Kómirelű kőtyual!
Remélem Te érted :-)
...
Esetleg a gyengébbek kedvéért: http://mek.oszk.hu/kiallitas/lazar/html/mesek_domdodom.htm
Alapmű elektronikából és informatikából.

- Állj - mondta Mikkamakka -, ezt nem te írtad!
- Hát kicsoda? - háborgott Bruckner Szigfrid. - Ki az ördög írta volna, itt van, nézd meg a papírt, nem az én írásom ez?!
...
- Ki az a Petőfi Sándor?! - kiabált Bruckner Szigfrid. - Sohase hallottam a nevét.

A mai napig bizonytalanságban éltünk, nem tudtuk mi az a "google OS". Most már tudjuk: Windows Vista a Firefoxban!

Mivel a hivatalos oldalról láthatóan nehezére esik egyeseknek összeszedni az infót, itt van ez:
ArsTechnica

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Hí..., de nagyon nem szimpatikus ....
Nem elég az a "kedves" javascript és a hasonlőan "kedves" flash?
Számomra ez hatalmas biztonsági résnek tűnik.
Nekem holmi jött-ment weboldal nem futtasson x86-os kódot a gépemen.

Kovezzetek meg, de szerintem eppenhogy jo dolog. A chrome bevezette, hogy a pluginek kulon processzkent futnak, ez pedig a kovetkezo lepes: a pluginek fussanak sandboxban. Szerintetek a jelenlegi allapot jobb, amikor az osszes plugin hozzafer a teljes rendszeredhez, a bongeszot futtato felhasznalo jogaival?

Igy legalabb kialakulhat egy kozos plugin keretrendszer (ha a google megfeleloen tudja tolni), aminek a jogosultsagait megfeleloen finomhangolhatjuk majd.