Vlákno názorů k článku Google má s projekty Chrome a Chrome OS velké plány od Lael Ophir - Google Chrome... Native Client, který vývojářům umožňuje vedle...

Google Chrome... Native Client, který vývojářům umožňuje vedle obvyklých webových technologií... požívat ve svých aplikacích také nativní kód napsaný v jazyce C++ nebo v klasickém C - OMG. Jako by nestačila ta spousta děr v prohlížečích a dalším C/C++ SW. Ještě necháme dělat stejné příšernosti vývojáře webových aplikací, aby byly děravé nejen browsery, ale i webové aplikace.

Dnešní webové technologie jsou jedna velká tragédie. Otevřete pár tabů v browseru, sežere to giga paměti (po pár hodinách díky resource leaks i výrazně víc), a ta spousta na pozadí běžících skriptů vám div nezavaří CPU. K tomu se webové aplikace ovládají výrazně hůř než ty desktopové, a když mají vypadat alespoň trochu slušně, tak se i dost obtížně píšou (HTML na to prostě není stavěné).
Ale musí se nechat, že evangelisté webových technologií přišli na to, jak dnešní nadupané počítače vytížit věcmi, které bez problémů zvládaly desktopy s Windows XP a 128MB RAM :)

Souhlasím s tím, že JS mor je zlo. Ještě tak kdyby bylo možno pozastavit skripty v záložkách a oknech, které nejsou v popředí, dalo by se to přežít. Co se týče NaCl, myslím, že to je slepá ulička a v mainstreamu se to nechytne.

Snad poprvé musím souhlasit.
Tyhle věci jsou opravdu hnus stejně jako šmíráctví s nimi spojené.
Z Google se ve spojení s masou hloupých uživatelů stává nebezpečné monstrum, vedle kterého bude Microsoft zanedlouho jen drobnou nepříjemností.

Webové technologie byly, jsou a budou tragédie a to už z podstaty věci, neboť potenciál HTML a lehkého skriptovacího jazyka JS je vyčerpán.
Například ani po 18-ti letech existence webových technologií dosud neexistuje plnohodnotný emailový klient, dosud jim kdykoliv dá na p*del průměrný desktopový.
Situace se nezlepší ani do budoucna, pokud se nestane nějaký zázrak a neprovede se upgrade na něco solidnějšího než HTML a JS.

A mě zrovna připadá Native Client jako velmi dobrý krok. Je to podmnožina C/C++ a není s tím možno dělat všechno a sockety mi tam určitě budou chybět.

Ale pokud se podíváme na Windows, tak tam se těží z binární kompatibility (ne 100%) a to Linuxu vyloženě chybí. Pokud tedy Google přišel s SDK, které má interface k javascriptu a bude zajištěna přenostitelnost a relativní bezpečnost (je strojově prověřen výsledný binární kód a podezřelé části vedou k odmítnutí celku) takto pouštěných aplikací, tak je to krok kupředu.

Ještě čekám na podporu dalších jazyků a nejsem si jist, jak se toto bude stavět k externím knihovnám, protože se obávám, že budou muset také projít validací - tj. bude je možno asi jedině přímo zakompilováním do kódu.

Když se podíváme na Microsoft, tak tam lze pozorovat také určité vystřízlivění z velkého nadšení k skriptovacím jazykům (typu C#) a návrat k C/C++ - protože jen s kompilací do strojového kódu lze dosáhnout maximálního výkonu.

Jde o provokaci, nebo to opravdu myslíte vážně?

- C# je skriptovací jazyk?
- návrat MS ke kompilaci do strojového kódu?

Google může jen těžko zajistit binární kompatibilitu, když s tímto paskvilem míří na x86 i ARM. Binární kód pluginů a rozšíření je všude opouštěn, protože je jeho běh špatně kontrolovatelný a způsobuje nestabilitu. Tady se k němu budeme zjevně s velkou slávou vracet. A na schopnosti Googlu kontrolovat kvalitu aplikací ukazuje již jeho úspěšnost při filtraci malware na Google Play...

A co se týče celkového nápadu s dalším desktopovým prostředím, integrovaným do prohlížeče, před lety jsme nadávali Mozille, že balí do stejnojmenného prohlížeče i mailového klienta a spoustu dalšího balastu. A teď přijde Google ještě s větším zvěrstvem, přibalí nám k tomu pro jistotu i kancelářský balík. Mám bohužel pocit, že Google má sílu to prosadit.

Co je to „skriptovací jazyk“? Neexistuje definice. Nenacházím vlastnost, podle které by se to dalo určit.

O tom se přít nehodlám, ale to označení má dehonestující charakter a víceméně jím autor původního příspěvku nakreslil čáru mezi C++ a C#, přičemž v podstatě položil rovnítko mezi C# a například shell skripty. A to pomíjím takové detaily, jako je to, že aktuální překladač MS C++ generuje implicitně stejný kód, jako C#, tedy spravovaný.

Toz asi je neco spatne a je potreba se doucit co skriptovaci jazyk je a co neni. Strycek google pomuze.

C# - asi jsem se nevyjádřil dost přesně, ale kompiluje se tam jen do mezikódu, ten se potom interpretuje - což je určitě pomalejší než nativní kód procesoru.
MS - sorry, na zdroj si nevzpomenu, ale někde jsem četl, že po Vistách, které byly v C# se v W7 zase kód přepsal do C++ (ne 100%, ale že se ten poměr zase posunul směrem k C++).

Pokud má Google v rukou kompilátor, tak může celkem všechno - včetně výstupu dvou binárek pro odlišné architektury a může také zajistit, že na klienta půjde jen ta správná.

"protože je běh špatně kontrolovatelný" - ale toto je jen technologgický problém a google si myslí, že se mu jej podařilo překonat.
Něco jiného je udělat kompilátor, který zkompiluje obecný C/C++ kód a ten bude vždy pojede "správně a nezávadně" (a toto zřejmě NaCl neumí) a něco jiného je říci, že "tato konstrukce není povolena - napiště to jinak (odkaz na vzor)". Já neříkám, že bude možné zkompilovat tam linuxový kernel - nepůjde. Bude to podmnožina C/C++ a bude těžit z rychlosti.

Google bude mít k dispozici i svůj operační systém (Linux based), takže může zajistit dostatečnou izolaci prostředí běžící aplikace (když to jde u VPS, tak to půjde i v menším měřítku). Kompilátor pravděpodobně binárku podepíše, takže s ní nepůjde dále manipulovat a možná ten podepisovací kompilátor poběží jen na serverech googlu, aby se jim do toho někdo nenaboural (spekulace).

Mezikód nemusí být nutně pomalejší, než nativní kód. Mezikód je u většiny VM kompilován do nativního za běhu (JIT), čímž lze docílit mnohem lepší optimalizace na cílové CPU, než když zkompilujete klasickou aplikaci tak, aby běžela na většině dostupného HW.

U běžných aplikací je to ve výsledku stejně jedno, někdy je rychlejší to, někdy ono. Kde nativní kód poráží spravovaný na celé čáře, jsou paměťové nároky (bavíme se o korektně napsaných aplikacích).

Ohledně C# a interpretované režimu jsem psal výše, že takhle to v .NETu nejspíš nikdy nefungovalo, a určitě to tak nefunguje dnes.

Ad bude to podmnožina C/C++ a bude těžit z rychlosti - jaká podmnožina? Pokud jsem správně pochopil co jsem vygooglil, tak NaCl prostě zkompiluje jakýkoliv C/C++ zdroják pro cílovou architekturu, a spustí výsledek s nějakým sandboxingem. Běžící kód může dělat veškeré příšernosti včetně pointerové aritmetiky, OpenGL ES 2.0, sandboxovaného local file storage, full screen mode a mouse capture (vyjma toho prvního vše pomocí knihoven browseru Chrome).

Proč mě to děsí? Zkuste si v libovolném recentním browseru otevřít pár tabů Youtube nebo Facebooku, tedy velikých a známých webů. Pak zkuste sledovat, kolik paměti a CPU vám browser sežere. Zkuste to sledovat po 24 nebo 48 hodinách - spotřeba paměti vás asi udiví. Ty JavaScripty mají resource leaks, a browsery mimochodem často také. Některé příčiny resource leaks najdete tady:
http://www.ibm.com/developerworks/library/wa-memleak/

Takhle dneska vypadají velké a známé weby. A určitě jsem viděl i vyloženě špatné weby, které mají daleko větší resource leaks, zacyklené skripty nebo absurdně vytěžují CPU.

Teď si představte, že lidem, kteří nejsou schopní napsat slušně ani web v JS, dáte do ruky C/C++ s pointerovou aritmetikou, nejspíš i threadingem (aby mohli ten CPU vytížit ještě lépe), přístupem k OpenGL/WebGL (které při troše snahy dokáže provést DOS, zhavarovat systém, přečíst obsah obrazovky, vytvořit falešné security dialogy apod.), a zavřete to do sandboxu, který se pochopitelně dříve či později ukáže jako děravý. Aplikace napsané pro NaCl budou děravé stejně jako ty napsané v C/C++, vytěžovat CPU jako ty v JavaScriptu a Flashi, a jako bonus budeme mít spoustu nových bezpečnostních zranitelností. A co nám to celé má přinést? Věci které desktopy umí už minimálně 10 let.

V podstatě s vláknem musím souhlasit.
Dovoluji si pár citací (autora záměrně neuvádím):

Tak bohužel žádné citáty nebudou, protože nějaký čurák na Rootu neumí nastavit spamový filtr. (Slušněji to fakt říct už neumím.)

Ako by si ho nastavil ty?

Třeba captcha po detekci spamu? Přemýšlejte trochu.