Native Client включён в состав Chrome

[GetWindowsDirectory]

очень хочется верить, что за 2 года Google тщательно проработали механизм безопасности. технология тянет на революционную (:

[zone19]

ActiveX — это все-таки обычный exe-шник который запускается браузером. Здесь же что-то вроде виртуальной машины для x86, что гораздо круче.

[NekitoSP]

Но в том же ActiveX можно было сделать что-то вроде «песочницы», чтобы все подряд не выполнялось, но вот кое-кто не позаботился об этом, и теперь это, возможно, будет все-таки революционной технологией, но только не для МС.

[shoguevara]

К сожалению, об этом осведомлены не все разработчики компонент…

[rumkin]

Технология это не только первое внедрение, но и PR, не Билл Гейтс придумал MS DOS, но грамотно его продал. Не Страуструп придумал объектный подход к программированию на C, но он стал отцом C++, вдохновленный другими языками. Примеров не счесть. Так что неудивительно, что Гугл переоткрыл то что было сделано ранее, но в новой форме. Когда-то и javascript был в забвении и прозябал в виде сценариев для эффектиков и снежиночек, пока не наступила пора ajax, jQuery и т.п.

[bruce]

Да.

[bolk]

А вы почитайте, там всё достаточно здорово и остроумно сделано.

[naum]

Т.е. Delphi нельзя? А VB в native тоже? Видать и с другими языками будет проблема, да? Не позорьтесь, речь идет о native коде в принципе, любую скомпилированную либу можно без проблем подключить и использовать. Понятное дело что удобные АПИ для других ЯП появятся в ближайшее время, стоит только продукту попасть в продакшен.

[ArtemSmirnov]

Вообще любой язык проблема только в биндингах, Native Client выполняет код для x86, просто ализар верятно сам не знает про что пишет

[naum]

Я об этом и говорю.

[ArtemSmirnov]

Извиняюсь, просто меня самого так бесило незнание того о чем говорят что только прочитав часть коментария написал комент.

[7vies]

Думается мне, будут проблемы с подключением других ЯП и библиотек, т.к. безопасность. Это же не виртуализация, а статический анализ машинного кода — чтобы позвать функцию из внешней библиотеки, нужно и её проанализировать и доказать что она безопасна.

[dikarik]

Там нечего хитрого. Предоставляется доступ к ограниченному API (как для JS, грубо говоря) для обычного кода, созданного слегка модифицированным кодогенератором, который использует ограниченный набор инструкцийи выравнивает jmp по границе в 16, кажется, байт — чтобы сделать невозможными фокуусы вроде «джамп на адрес». Соответственно, клиент проверяет корректность набора опкодов и выравнивания — и всё.

[7vies]

Так а причём тут «хитро»? Вызов внешних библиотек-то явно ограничен, иначе бы ни о какой безопасности и речи не шло, а значит и будут сложности с другими платформами, и даже банально с сишными библиотеками, которые придётся пересобирать под их модифицированным компилятором и поди ещё обязательно статически линковать.

[dikarik]

Насколько я помню, статически линковать не обязательно, а пересобрать — да. Смотрите на это как на веб-аналог андроидского NDK — т.е. нативный код, ориентированный прежде всего на оптимизацию быстродействия. Хотя, вероятно, позже появятся и поддерживающие его библиотеки.

[Deranged]

Проблема не столько в самих расширениях, сколько в рантайм библиотеках их языков. Например MSVCRT.dll для Visual C++ или RTL.bpl для Delphi. Эти библиотеки тянут функции операционной системы, поэтому из загружать в браузер никак нельзя.
Подозреваю, что Google просто предоставит собственный рантайм или статическую либу, на основе функций из которой и будет строиться браузерное приложение.
Поэтому что бы написать приложение для NPAPI придется тщательно настраивать набор импортируемых модулей в своём проекте. Т.е. дельфийские формы или MFC заюзать не получится в любом случае, только компилятор.

[7vies]

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

[7vies]

Да, но они ведь уже запускали что-то вроде doom, так что эта проблема уже должна быть решена. Главное, что dll для C/C++ рантайма не необходима, в других языках может быть другая ситуация.

[bolk]

Нужен не просто компилятор, а особый компилятор, которые генерирует особый машинный код.

[ztarlitz]

а разве NaCl не был в хроме? Я почему-то был уверен что он давно уже в хроме.

[VladX]

Чёрт, один я прочитал NaCl как натрий-хлор? :)

[VasG]

Более того, если бы не ваш комментарий, я бы долго сидел и думал при чем тут соль… Сказывается направленность образования, пардон)

[severality]

NaCl, а к нему Pepper (перец). Разработчики не заморачивались с названиями :)

[TiGR]

NaCl в Cr. Это хлорид натрия в хромированной упаковке?

[vvzvlad]

логотип — солонка

[DIHALT]

Патентуй идею :)

[RussianNeuroMancer]

Он был выключен по-умолчанию. Теперь наверное включили.

[polyakstar]

Прощай кроссплатформенность веба?

[rumkin]

Пошли на второй заход ))

[dmbreaker]

Потом будет PNaCl и все станет кроссплатформенным. Странно, что они сразу его не включили…

[mariofag]

>запускать x86-код
meh. HTML5, кросс-платформенность, ChromeOS и при это — код для x86. По-моему, это движение не вперёд, а назад.

[mariofag]

*при этом

[fuCtor]

Это движение в сторону я бы сказал.

[aleks_raiden]

Увы это единственный способ делать то, что сегодня хотят клиенты — во многих специфических областях

[f0rmat1k]

Ну да, единственный? А флеш? На флеше можно сделать практически все, что угодно.

[f0rmat1k]

Минусующие карму, вы бы хоть писали за что? Или тупо за нелюбовь к флешу? Дак я и не агатирую, просто привожу факты.

[aleks_raiden]

Нет, не все, и не все на приемлемой скорости

[f0rmat1k]

Про какую скорость вы говорите? На нем многое работает: видеотрансляции, всевозможные игры, тубы. Что касается рендеринга графики, то тоже все в порядке, подрубили ж аппаратное скорение. По крайней мере если визуально так сравнивать, то обработка флешевого 3д и нативного на моей машине происходит с одинаковой скоростью.

Скорость более чем приемлимая имхо.

[aleks_raiden]

Например, сложный финансовый анализ над загруженными данными, к которым одновременно приходит постоянно новые данные.

[david_mz]

Java?

[aleks_raiden]

нет, далеко не всегда подходит + требует от клиента телодвижений больше, чем трейдер может (хочет) сделать

[bfDeveloper]

Тогда покажите мне игру на флеше с уровнем физики хотя бы как в World of Goo. Таких нет. Есть множество синтетических тестов, показывающих разницу в скорости с native кодом в разы, а то и на порядки.
Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.

[frog]

Для последних версий Flash'a просто не успели еще ничего написать. Но вот скажем можно посмотреть демку (это для беты fp 11), которая о многом говорит:
www.youtube.com/watch?v=EzZS7RoJFEE&feature=youtu.be&hd=1

А с нативным кодом виртуальные машины просто не нужно сравнивать.

[bfDeveloper]

Не увидел физики вообще. Да, 3D движок красивый, но, во-первых это не имеет отношения к физическому моделированию, во-вторых не верю в то, что эта демка имеет схожие системные требования с её аналогами с классической демосцены.

[dikarik]

К примеру, для шифрования скорость непотребная совершенно. Хочешь видео — приходится использовать кодеки, понимаемые плеером. И так далее, и тому подобное. Нет уж, NaCl интереснее, да ещё и не привязан к конкретному языку программирования.

[bruce]

Допустим я хочу запустить в браузере видеокодек какого-нибудь изощренного формата, для которого нет нативной поддержки. Или, скажем, эмулятор Nintendo 64. Все это:

1) Невозможно реализовать на других языках с приемлимой скоростью.
2) Уже существует огромное количество кода на С под подобные предметные области. Портировать на другие языки может быть просто не практично.

[rabsa]

Флеш, по крайней мере на данный момент, — довольно небезопасная технология. И сравнивать её с Native Client, думаю не стоит.

[Azzie]

Нет никакого байткода. В NaCl — ограниченное подмножество x86 инструкций, причем ограниченное очень тривиально => весьма простой и очевидно корректный валидатор.

[CLR]

Не PNaCl единым, они сразу разными путями идут, например уже переделали JIT компилятор с Mono CLR в нативный код именно для NaCl (а также свой v8). В итоге получаем код JavaSript/C# (я не очень разбираюсь в этой области, но что там еще есть — vb/delphi/etc?) -> CIL bytecode -> JIT (на стороне клиента) -> native code (NaCl)

[Azzie]

А валидация все равно будет на уровне нативного кода.

Кстати, это не байткод, а биткод :)

[yorick_kiev_ua]

Как я подозреваю у него нет, например, доступа к диску и вообще к устройствам, кроме микрофона/диномиков/камеры и т.п…

[Emin]

1. Записать в файл, загрузить файл с сервера, загрузить на компьютер пользователя, сохранить информацию на компьютере флэш умеет. Что ещё нужно веб-приложению?
2. Ещё принтеры поддерживаются. К каким ещё устройствам должно иметь доступ веб-приложение?

[yorick_kiev_ua]

>>Записать в файл, загрузить файл с сервера, загрузить на компьютер пользователя, сохранить информацию на компьютере флэш умеет

Это просто разные представления о доступе. То, что вы говорите — умеет и броузер. А может ли флеш без диалогов и т.п. просто вычитать файл c:\1.txt (а если нет — то создать его)?

[Emin]

Чтение файлов с диска пользователя без запроса — это нарушение конфиденциальности.
Открыл сайт, а он без твоего спроса конфиденциальную информацию с диска на сервер перекачивает. Или наоборот что-то дописывает в системные файлы.

[yorick_kiev_ua]

То-есть говоря по-просту: не умеет. Это и имелось в виду под «нет доступа».

[rumkin]

Ну Flash вообще-то технология временная. Он лишь показал что именно нужно разработчикам: видео, аудио, векторная графика, динамические запросы, WebGL… Но теперь его время уходить или превратиться во что-то более крутое.

[entze]

Банк-клиент с доступом к хардварному токену.

[vvzvlad]

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

[vvzvlad]

да, но КАК.

картинку не буду вставлять.

[yorick_kiev_ua]

Ага, с одной стороны имеем все проблемы разработки «под броузер», а с другой не получаем удобств веб-приложений.

[GIum]

вот-вот, да еще и писать на чем-нибудь низкоуровневом

[dikarik]

Писать там можно на чём угодно. К примеру — вполне реально прикрутить Cython.

[dikarik]

Гугл активно занимается реализацией NaCl на база llvm — там вроде как с кроссплатформенностью нормально. Впрочем, и сейчас можно скомпилировать несколько бинарников (x86, amd64, arm) — от операционной системы код не зависит, только от архитектуры процессора.

[diamant]

технологии Native Client, которая позволяет запускать x86-код в браузере

x86-64 и ARM тоже.
К [if IE] и [if Opera] добавятся [if ARM] и [if x86-32] :)

[muromec]

мне вот дико интересно, как они будут держать его внутри песочници и как обеспечивать кроссплатформенность (для ARM он у них тоже есть).

[redchrom]

Для каждой архитектуры нужно отдельный бинарик собирать. По поводу секурити самому интересно.

[Gorthauer87]

Си и Си++ все равно в пролете!

[redchrom]

Про LLVM bitcode это проект PNaCL — но он ещё в разработке, а пока нужно обирать под каждую архитектуру.

[redchrom]

Согласен, в текущем виде NaCL не интересен. С другой стороны правильно, что зарелизили — народ поиграется, потестит сэндбокс, pepper и т.д. А там глядишь и PNaCL подоспеет.
Что до верификации то принципиальной разницы нет — они всё равно только проверяют, чтобы сисколов не было, а само приложение всё равно в сэндбоксе и отдельном адресном пространстве.

[dikarik]

Прочтите родные доки — там очень простой и остроумный верификатор. А PNaCl — интересен, конечно, но возникают вопросы: 1) скорость компиляции; 2) LLVM-байт-код, насколько я помню, не кроссплатформеный

[redchrom]

1) Подозреваю, что несколько медленнее чем JIT (в виду разных техник) но не сильно. И уж наверняка будут кэшировать результат.
2) Я конкретно о IR LLVM ничего не знаю (может там несколько уровней), но PNaCL просто определит абстрактную 32х-битную машину для которой будет генерить промежуточный код.

nativeclient.googlecode.com/svn/data/site/pnacl.pdf

[rumkin]

Как я понимаю (чисто теоретически), они используют виртуальную машину, которая выступает мостом между браузером и процессором, но имеет свое адресное пространство, которое не пересекается с пространством ОС. Гугл вообще обожает виртуальные машины (ну или делает вид что обожает :) возьмите хотя бы V8 каждый браузер — отдельный процесс, вот вам уже защищенность — в другой процесс влезть сложнее.

[redchrom]

Нашёл, что у них есть проект PNaCL — используют промежуточное представление LLVM и компилируют на таргете. Вот это как раз то, о чём я всегда мечтал, а native client в котором нужно для каждой архитектуры компилять — не нужен.

[Gorthauer87]

И как с этой хренью разруливать сишные макросы, которые различные для разных платформ?

[redchrom]

Не использовать такие макросы. PNaCL подразумевает, что есть одна 32х-битная виртуальная, определяет размер и представление типов и возможно даст пару интрисиков для SIMD. Если сильно нужно, то можно использовать обычные условные конструкции самого языка, а llvm выпилит неиспользуемые куски.

[Gorthauer87]

Тогда 99% C++ либ сразу лесом идут

[redchrom]

Нифига, просто добавляется новый таргет в кучку ифдефов, где уже есть linux, win32, etc…

[Gorthauer87]

Ну или уже на уровне llvm придется извращаться

[NEMMO]

Такими темпами, браузеры видимо вскоре заменят операционную систему. Будем устанавливать не linux/windows/macos, а хромы, огнелисы, оперы и т.п.

[TiGR]

Ну, осталось в добавок к ХромОС выпустить ОпераОС, FirefoxOS и ИЕОС, и дело в шляпе.

[tibalt]

причем будет иеос6, иеос7 и т.д., все несовместимые)

[AstonMartin]

Эх, лучше бы сделали возможность отключить передачу личной информации lexchange.ya.ru/replies.xml?item_no=3248

[NEMMO]

Считаю что одна из целей google и не только, собрать как можно больше информации о людях, представьте — позволить человеку добровольно поведать о себе все, а так-же о его скелетах в шкафу. Шикарная база получится! Скоро наверное предложат имплантировать датчики каждому клиенту, чтобы уж наверняка под колпак взять.

[rPman]

Кто то тут жаловался, что при использовании Native Client в Android невероятно медленная отрисовка на экран (90% времени копируется изображение)… это я о том, что крутая скорость машины будет полностью перекрываться ограниченной скоростью передачи данных в/из песочницы.

а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.

[dmOx]

И чем это лучше Java-апплетов тех же? Теже опкоды, тоже вирт. машины, разве что название другое и браузерно-зависимое.

[dikarik]

Тем, что не завязано на java и нет виртуальной машины как таковой, а есть очень шустрая верификация подмножества нативного кода?

[dmOx]

По моему лучше уж пусть завязано на Java будет чем на Chrome, нет?

[afaber]

У Java есть один фатальный недостаток… (С)

[bolk]

Нет там опкодов. Там нативный код.

[bolk]

Не знаю, PNaCl не ковырял. И в новости не про него, кажется.

[dmbreaker]

Это не те опкоды. Скажем так: у java — «высокоуровневые опкоды», а у LLVM очень низкоуровневые.

[step_na_habre]

Пол года назад был рад узнать, что работа над Native Client активно ведется в российском подразделении Google.

[egorinsk]

Что не может не радовать — так это то, что получают распространение технологии типа байткода LLVM и OpenSource native client, а не поганая, закрытая, платная, ненадежная, глючная, уязвимая проприетарщина, как это было раньше (ActiveX, Java, Flash и т.д.).

В этом плане Гугл делает очень хорошее дело, не пытаясь создать свою закрытую платформу.