Comments 105
очень хочется верить, что за 2 года Google тщательно проработали механизм безопасности. технология тянет на революционную (:
ActiveX — это все-таки обычный exe-шник который запускается браузером. Здесь же что-то вроде виртуальной машины для x86, что гораздо круче.
Но в том же ActiveX можно было сделать что-то вроде «песочницы», чтобы все подряд не выполнялось, но вот кое-кто не позаботился об этом, и теперь это, возможно, будет все-таки революционной технологией, но только не для МС.
К сожалению, об этом осведомлены не все разработчики компонент…
Технология это не только первое внедрение, но и PR, не Билл Гейтс придумал MS DOS, но грамотно его продал. Не Страуструп придумал объектный подход к программированию на C, но он стал отцом C++, вдохновленный другими языками. Примеров не счесть. Так что неудивительно, что Гугл переоткрыл то что было сделано ранее, но в новой форме. Когда-то и javascript был в забвении и прозябал в виде сценариев для эффектиков и снежиночек, пока не наступила пора ajax, jQuery и т.п.
Да.
А вы почитайте, там всё достаточно здорово и остроумно сделано.
Т.е. Delphi нельзя? А VB в native тоже? Видать и с другими языками будет проблема, да? Не позорьтесь, речь идет о native коде в принципе, любую скомпилированную либу можно без проблем подключить и использовать. Понятное дело что удобные АПИ для других ЯП появятся в ближайшее время, стоит только продукту попасть в продакшен.
Вообще любой язык проблема только в биндингах, Native Client выполняет код для x86, просто ализар верятно сам не знает про что пишет
Думается мне, будут проблемы с подключением других ЯП и библиотек, т.к. безопасность. Это же не виртуализация, а статический анализ машинного кода — чтобы позвать функцию из внешней библиотеки, нужно и её проанализировать и доказать что она безопасна.
Там нечего хитрого. Предоставляется доступ к ограниченному API (как для JS, грубо говоря) для обычного кода, созданного слегка модифицированным кодогенератором, который использует ограниченный набор инструкцийи выравнивает jmp по границе в 16, кажется, байт — чтобы сделать невозможными фокуусы вроде «джамп на адрес». Соответственно, клиент проверяет корректность набора опкодов и выравнивания — и всё.
Так а причём тут «хитро»? Вызов внешних библиотек-то явно ограничен, иначе бы ни о какой безопасности и речи не шло, а значит и будут сложности с другими платформами, и даже банально с сишными библиотеками, которые придётся пересобирать под их модифицированным компилятором и поди ещё обязательно статически линковать.
Проблема не столько в самих расширениях, сколько в рантайм библиотеках их языков. Например MSVCRT.dll для Visual C++ или RTL.bpl для Delphi. Эти библиотеки тянут функции операционной системы, поэтому из загружать в браузер никак нельзя.
Подозреваю, что Google просто предоставит собственный рантайм или статическую либу, на основе функций из которой и будет строиться браузерное приложение.
Поэтому что бы написать приложение для NPAPI придется тщательно настраивать набор импортируемых модулей в своём проекте. Т.е. дельфийские формы или MFC заюзать не получится в любом случае, только компилятор.
Подозреваю, что Google просто предоставит собственный рантайм или статическую либу, на основе функций из которой и будет строиться браузерное приложение.
Поэтому что бы написать приложение для NPAPI придется тщательно настраивать набор импортируемых модулей в своём проекте. Т.е. дельфийские формы или MFC заюзать не получится в любом случае, только компилятор.
Нужен не просто компилятор, а особый компилятор, которые генерирует особый машинный код.
а разве NaCl не был в хроме? Я почему-то был уверен что он давно уже в хроме.
Чёрт, один я прочитал NaCl как натрий-хлор? :)
Более того, если бы не ваш комментарий, я бы долго сидел и думал при чем тут соль… Сказывается направленность образования, пардон)
NaCl, а к нему Pepper (перец). Разработчики не заморачивались с названиями :)
NaCl в Cr. Это хлорид натрия в хромированной упаковке?
Он был выключен по-умолчанию. Теперь наверное включили.
Прощай кроссплатформенность веба?
>запускать x86-код
meh. HTML5, кросс-платформенность, ChromeOS и при это — код для x86. По-моему, это движение не вперёд, а назад.
meh. HTML5, кросс-платформенность, ChromeOS и при это — код для x86. По-моему, это движение не вперёд, а назад.
*при этом
Увы это единственный способ делать то, что сегодня хотят клиенты — во многих специфических областях
Ну да, единственный? А флеш? На флеше можно сделать практически все, что угодно.
Минусующие карму, вы бы хоть писали за что? Или тупо за нелюбовь к флешу? Дак я и не агатирую, просто привожу факты.
Нет, не все, и не все на приемлемой скорости
Про какую скорость вы говорите? На нем многое работает: видеотрансляции, всевозможные игры, тубы. Что касается рендеринга графики, то тоже все в порядке, подрубили ж аппаратное скорение. По крайней мере если визуально так сравнивать, то обработка флешевого 3д и нативного на моей машине происходит с одинаковой скоростью.
Скорость более чем приемлимая имхо.
Скорость более чем приемлимая имхо.
Например, сложный финансовый анализ над загруженными данными, к которым одновременно приходит постоянно новые данные.
Тогда покажите мне игру на флеше с уровнем физики хотя бы как в World of Goo. Таких нет. Есть множество синтетических тестов, показывающих разницу в скорости с native кодом в разы, а то и на порядки.
Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.
Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.
Для последних версий Flash'a просто не успели еще ничего написать. Но вот скажем можно посмотреть демку (это для беты fp 11), которая о многом говорит:
www.youtube.com/watch?v=EzZS7RoJFEE&feature=youtu.be&hd=1
А с нативным кодом виртуальные машины просто не нужно сравнивать.
www.youtube.com/watch?v=EzZS7RoJFEE&feature=youtu.be&hd=1
А с нативным кодом виртуальные машины просто не нужно сравнивать.
К примеру, для шифрования скорость непотребная совершенно. Хочешь видео — приходится использовать кодеки, понимаемые плеером. И так далее, и тому подобное. Нет уж, NaCl интереснее, да ещё и не привязан к конкретному языку программирования.
Допустим я хочу запустить в браузере видеокодек какого-нибудь изощренного формата, для которого нет нативной поддержки. Или, скажем, эмулятор Nintendo 64. Все это:
1) Невозможно реализовать на других языках с приемлимой скоростью.
2) Уже существует огромное количество кода на С под подобные предметные области. Портировать на другие языки может быть просто не практично.
1) Невозможно реализовать на других языках с приемлимой скоростью.
2) Уже существует огромное количество кода на С под подобные предметные области. Портировать на другие языки может быть просто не практично.
Флеш, по крайней мере на данный момент, — довольно небезопасная технология. И сравнивать её с Native Client, думаю не стоит.
Нет никакого байткода. В NaCl — ограниченное подмножество x86 инструкций, причем ограниченное очень тривиально => весьма простой и очевидно корректный валидатор.
Не PNaCl единым, они сразу разными путями идут, например уже переделали JIT компилятор с Mono CLR в нативный код именно для NaCl (а также свой v8). В итоге получаем код JavaSript/C# (я не очень разбираюсь в этой области, но что там еще есть — vb/delphi/etc?) -> CIL bytecode -> JIT (на стороне клиента) -> native code (NaCl)
А валидация все равно будет на уровне нативного кода.
Кстати, это не байткод, а биткод :)
Кстати, это не байткод, а биткод :)
Как я подозреваю у него нет, например, доступа к диску и вообще к устройствам, кроме микрофона/диномиков/камеры и т.п…
1. Записать в файл, загрузить файл с сервера, загрузить на компьютер пользователя, сохранить информацию на компьютере флэш умеет. Что ещё нужно веб-приложению?
2. Ещё принтеры поддерживаются. К каким ещё устройствам должно иметь доступ веб-приложение?
2. Ещё принтеры поддерживаются. К каким ещё устройствам должно иметь доступ веб-приложение?
>>Записать в файл, загрузить файл с сервера, загрузить на компьютер пользователя, сохранить информацию на компьютере флэш умеет
Это просто разные представления о доступе. То, что вы говорите — умеет и броузер. А может ли флеш без диалогов и т.п. просто вычитать файл c:\1.txt (а если нет — то создать его)?
Это просто разные представления о доступе. То, что вы говорите — умеет и броузер. А может ли флеш без диалогов и т.п. просто вычитать файл c:\1.txt (а если нет — то создать его)?
Ну Flash вообще-то технология временная. Он лишь показал что именно нужно разработчикам: видео, аудио, векторная графика, динамические запросы, WebGL… Но теперь его время уходить или превратиться во что-то более крутое.
Банк-клиент с доступом к хардварному токену.
да, но КАК.
картинку не буду вставлять.
картинку не буду вставлять.
Ага, с одной стороны имеем все проблемы разработки «под броузер», а с другой не получаем удобств веб-приложений.
вот-вот, да еще и писать на чем-нибудь низкоуровневом
Гугл активно занимается реализацией NaCl на база llvm — там вроде как с кроссплатформенностью нормально. Впрочем, и сейчас можно скомпилировать несколько бинарников (x86, amd64, arm) — от операционной системы код не зависит, только от архитектуры процессора.
технологии Native Client, которая позволяет запускать x86-код в браузере
x86-64 и ARM тоже.
К [if IE] и [if Opera] добавятся [if ARM] и [if x86-32] :)
мне вот дико интересно, как они будут держать его внутри песочници и как обеспечивать кроссплатформенность (для ARM он у них тоже есть).
Для каждой архитектуры нужно отдельный бинарик собирать. По поводу секурити самому интересно.
Си и Си++ все равно в пролете!
Про LLVM bitcode это проект PNaCL — но он ещё в разработке, а пока нужно обирать под каждую архитектуру.
Согласен, в текущем виде NaCL не интересен. С другой стороны правильно, что зарелизили — народ поиграется, потестит сэндбокс, pepper и т.д. А там глядишь и PNaCL подоспеет.
Что до верификации то принципиальной разницы нет — они всё равно только проверяют, чтобы сисколов не было, а само приложение всё равно в сэндбоксе и отдельном адресном пространстве.
Что до верификации то принципиальной разницы нет — они всё равно только проверяют, чтобы сисколов не было, а само приложение всё равно в сэндбоксе и отдельном адресном пространстве.
Прочтите родные доки — там очень простой и остроумный верификатор. А PNaCl — интересен, конечно, но возникают вопросы: 1) скорость компиляции; 2) LLVM-байт-код, насколько я помню, не кроссплатформеный
1) Подозреваю, что несколько медленнее чем JIT (в виду разных техник) но не сильно. И уж наверняка будут кэшировать результат.
2) Я конкретно о IR LLVM ничего не знаю (может там несколько уровней), но PNaCL просто определит абстрактную 32х-битную машину для которой будет генерить промежуточный код.
nativeclient.googlecode.com/svn/data/site/pnacl.pdf
2) Я конкретно о IR LLVM ничего не знаю (может там несколько уровней), но PNaCL просто определит абстрактную 32х-битную машину для которой будет генерить промежуточный код.
nativeclient.googlecode.com/svn/data/site/pnacl.pdf
Как я понимаю (чисто теоретически), они используют виртуальную машину, которая выступает мостом между браузером и процессором, но имеет свое адресное пространство, которое не пересекается с пространством ОС. Гугл вообще обожает виртуальные машины (ну или делает вид что обожает :) возьмите хотя бы V8 каждый браузер — отдельный процесс, вот вам уже защищенность — в другой процесс влезть сложнее.
Нашёл, что у них есть проект PNaCL — используют промежуточное представление LLVM и компилируют на таргете. Вот это как раз то, о чём я всегда мечтал, а native client в котором нужно для каждой архитектуры компилять — не нужен.
И как с этой хренью разруливать сишные макросы, которые различные для разных платформ?
Такими темпами, браузеры видимо вскоре заменят операционную систему. Будем устанавливать не linux/windows/macos, а хромы, огнелисы, оперы и т.п.
Эх, лучше бы сделали возможность отключить передачу личной информации lexchange.ya.ru/replies.xml?item_no=3248
Считаю что одна из целей google и не только, собрать как можно больше информации о людях, представьте — позволить человеку добровольно поведать о себе все, а так-же о его скелетах в шкафу. Шикарная база получится! Скоро наверное предложат имплантировать датчики каждому клиенту, чтобы уж наверняка под колпак взять.
Кто то тут жаловался, что при использовании Native Client в Android невероятно медленная отрисовка на экран (90% времени копируется изображение)… это я о том, что крутая скорость машины будет полностью перекрываться ограниченной скоростью передачи данных в/из песочницы.
а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.
а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.
И чем это лучше Java-апплетов тех же? Теже опкоды, тоже вирт. машины, разве что название другое и браузерно-зависимое.
Пол года назад был рад узнать, что работа над Native Client активно ведется в российском подразделении Google.
Что не может не радовать — так это то, что получают распространение технологии типа байткода LLVM и OpenSource native client, а не поганая, закрытая, платная, ненадежная, глючная, уязвимая проприетарщина, как это было раньше (ActiveX, Java, Flash и т.д.).
В этом плане Гугл делает очень хорошее дело, не пытаясь создать свою закрытую платформу.
В этом плане Гугл делает очень хорошее дело, не пытаясь создать свою закрытую платформу.
Sign up to leave a comment.
Native Client включён в состав Chrome