Native Client портирован для архитектур ARM и x86-64

Android? Кстати, раз уж они придумали NDK для Android то почему его так же не сделать на LLVM? Ведь приложения на Java будут работать на любой архитектуре, а нативные будучи скомпилированные под процессор уже не будут универсальны... А с LLVM будут...

> Google Native Client (abbreviated as NaCl)

Улыбнуло.

позволяющая выполнят

>Ведь приложения на Java будут работать на любой архитектуре

Анабиозникам мы сообщим, что на андроиде не та ява, и она несовместима с другими платформами. Сами разработчики писали, что совместимости не будет в ближайшее время (а может и вообще).

>Native Client — это технология позволяющая выполнят нативные приложения в окне браузера.

Типа ActiveМПХ?

Я слышал, что она несовместима с сановской жабой. А по поводу совместимости байт-кода с различными аппаратными архитектурами — самому интересно, всё время думал, что совместимость есть.

Типа ActiveМПХ?

Вкратце - нет. Там sandbox, из которого фиг вылезешь.

Это анонимус платформу с архитектурой перепутал, бывает. Совместима, конечно же, есть андроид на x86 и на арме. Совместимости с саном нет и не будет. Подозреваю, что сан хотел много денех, за что был послан подальше и поделом (RIP).

> Анабиозникам мы сообщим, что на андроиде не та ява, и она несовместима с другими платформами. Сами разработчики писали, что совместимости не будет в ближайшее время (а может и вообще).

Уж спасибо КО, но это мы и без вас знали. Речь идет об архитектурах процессора, поддерживаемых андроидом, и всю эту переносимость убивает NDK без LLVM...

>выполнят нативные приложения в окне браузера

зачем?

секурити опастносте!!!111

это сильно увеличит скорость выполнения.

> Анабиозникам мы сообщим, что на андроиде не та ява

превед анабеознег. man dx, RTFM Android SDK

> зачем?

Честно, я тоже об этом долго размышлял, когда впервые услышал о NC, уж больно странной кажется эта идея со стороны гугла. Думаю, NC позволит превратить гуглу свою хромоось не просто в браузер, но в полноценный тонкий клиент - без какой либо зависимости от всякого хлама типа жабы или дотнета (и без присущих им тормозов). Короче, моё мнение - гугл захватывает мир^W^W делает NC в первую очередь для ChromeOS, а андройд пока полигон для испытаний.

те нативные приложения будут так же тянуться с их сервера? и весь сыр бор, просто ,что бы сделать что то менее тормознутое чем монстры на ажаксе?

В андроиде используется стекориентированная виртуальная машина дарвик. Для неё используется свой собственный байткод. Есть транслятор который переводит ЖВМ классы в дарвик класы. Так что явы на андроиде по сути своей нет. Полученные классы выполняются на любой виртуальной машине дарвик в том числе и на ПС.

По поводу ллвм - смысла в этом особого нет, так как дарвик писался с расчётом на мобильные устройства и ллвм не даст никаких приимуществ.

По поводу сан хотела много денег - ))))) нужно же иногда и головой подумать, прежде чем делать громкие заявления. Дарвик и хотспот принципиально разные виртуальные машины. Как я уже писал - дарвик стекориентирована и это сделано специально для ускорения работы на гаджетах. Но писать томкет под дарвик - затея вообще говоря безсмысленная, потому не будет никогда совместимости в байткодах!

Андроид - выгодная для сан платформа, и дарвик - это единственная нормальная альтернатива безбожно устаревшему для современных гаджетов джаваМЕ. Так что вполне вероятно, что порт может быть сделан совсем в другую сторону, то есть например библиотеки джаваФх будут портированы под дарвик. Хотя конечно последниее заявления Оракла были очень громкими и обещали что наконец-то настанет write once - run everywhere!

Да_л_вик. И она регистровая.

В хроме всё ещё старая версия ABI

> выполнят

выполнять

fxd.

Через это можно запускать кроссплатформенный флеш

выполнят нативные приложения в окне браузера

зачем?

вот уж дествительно!

что за мода такая — пихать всё подрят внутрь «окна браузера»

(если уж написали нативное приложение, то сам иегова велел запускать его БЕЗ браузера :))

Google хочет превратить Web в основную платформу для
работы всех приложений и контролировать почти всё.
NaCl нужен для тяжёлых вычислений на клиенте
(графические и видео- редакторы). NaCl лучше,
чем ActiveX (безопасно) и Ява (быстро).

>Да_л_вик. И она регистровая.

+1

Стековая - это как раз jvm

активный икс под ляликс? нет пути!

это не активХ, сколько повторять — бинарник верифицируется

жду не дождусь, чтобы ява померла вместе с саном (и теперь уже ораклом), а вместо ява-апплетов стандартом стало NaCl

> жду не дождусь, чтобы ява померла

Да, ты не дождешься.

ну хотя бы сан умер — это уже позитив

он это заслужил тем, как все затопил своим маркетоидным поносом на тему явы

теперь осталось дождаться, когда гугль раскрутит NaCl

> Да, ты не дождешься.

Кстати, насчет явы и нейтив клиента.

Интересно их сравнить с точки зрения, например, какой-либо сетевой игрушки, которая позволять скачивать неизвестный код и вызывать его допустим отдельной нитью/процесом с общими данными на чтение и неким буфером, куда этот код пишет. Можно ли это делать безопасно, так, чтобы код не мог напакостить? (предположим, что возвращаемые кодом структуры данных простые — типа отрендеренных картинок и не требуют верификации)

> скачивать неизвестный код и вызывать его допустим отдельной нитью/процесом

NaCl не позволяет запускать неизвестный код без верификации. И я сильно подозреваю, что верификацию пройдут только специальным образом скомпилированные бинари.

предположим, что неизвестный код — это именно NaCl c информацией для верификации и скомпилирован особым образом, либо jar явы, ява-апплет,...

а вот у явы из запущенной нити видно много чего, и рефлекшен никто не отменял

я знаю что рефлекшн можно запретить для приватных членов/методов, но даже если левый код начнет дергать публичные — че будет...?

может можно пускать ява-код отдельным процессом, но как тогда иметь общие струтктуры данных?

> че будет...?

А почитать описание NaCl тебе религия не позволяет?

а там не просто прочитать надо, а разбираться в деталях... впрочем, как в том же вопросе в случае явы

может кто-нить добрый и знающий разъяснит (и про яву тоже)

По поводу сан хотела много денег - ))))) нужно же иногда и головой подумать

Ну вот ты и подумай. Хотя лучше почитай - http://www.betaversion.org/~stefano/linotype/news/110/.

Проблема не только в деньгах, хотя гуглу не вперлось требовать с вендоров деньги для сана, не беря их для себя, платный андроид никогда бы не взлетел. Но проблема еще и в том, что контроль со стороны сана и JCP за «стандартами» гуглу тоже не нужен, ему нужна возможность устанавливать свои стандарты и быстро наращивать функциональность, а не советоваться с левыми компаниями на каждый свой чих.

> Google хочет превратить Web в основную платформу для

работы всех приложений и контролировать почти всё.

NaCl нужен для тяжёлых вычислений на клиенте

(графические и видео- редакторы). NaCl лучше,

чем ActiveX (безопасно) и Ява (быстро).

намеренья эти конешно блогие^W ужасные! :-)

но вот сама всё идея реализации... :-/ :-/ :-/ :-/ :


если в NaCl — будет (или уже_существует?) функция его использования БЕЗ создания «отдельного квадратика» внутри web-странички, для непосредственно этих самых «быстрых вычислений», а выводить результаты чтобы можно былобы через обычный Document-Object-Model или <convas />...

....то тогда даю добро на эту разработку! :-)

а если такого не предусматривается, и разработчики ГНК (NaCl) хотят сделать очередной «браузер-в-браузере» — то... ...НУ ТУПОЖЕ БЛИН!!! СКОЛЬКО УЖЕ МОЖНО?


(и да да, говорю сразу: однопиксельный «квадратик» — ТОЖЕ является «квадратиком» :-/ , хоть его и почти невидно . это напоминание для любителей хаков на ровном месте )

может можно пускать ява-код отдельным процессом, но как тогда иметь общие струтктуры данных?

кстате — ВОТ ЭТО совсем и не проблемма. мультинитевость — не eденственный способ работать с общими данными (мультинитевость — это вообще НЕ обязательная технолоия при разработки приложения — её запросто можно избежать, ровно как и shared_memory )

традиционно — в unix — использовалась мультипроцессность, и процессы нормально обменивались друг-с-другом состоянием через общие PIPE`ы ...

....а на динамических языках — даже есть эмуляция_мультинитевости через эти самые: мультипроцессность+PIPE`ы

....

вот правда — незнаю какой там функционал в Java-библиотеке — касательно PIPE`ов и процессов .. :-( :-(

Мммм... Кросплатформенный фреймворк для написания вирусов.

Типа замена флеша?

Самым интересным на московском GDD'09 был как раз доклад
Виктора Хименко о NaCl, посмотрите: http://www.youtube.com/watch?v=Oknm3_82Pc0