Comments 105
очень хочется верить, что за 2 года Google тщательно проработали механизм безопасности. технология тянет на революционную (:
Революционнее, чем ActiveX?
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, думаю не стоит.
Как сказать, кстати. И там, и там байткод.
Если верификатор байт-кода так упорно не получается у Adobe, где гарантии, что Google справится?
Если верификатор байт-кода так упорно не получается у Adobe, где гарантии, что Google справится?
Нет никакого байткода. В NaCl — ограниченное подмножество x86 инструкций, причем ограниченное очень тривиально => весьма простой и очевидно корректный валидатор.
Байткод будет. Они же не дураки, чтобы заставлять разработчиков компилировать под все платформы. PNaCl уже в разработке, см. ниже.
Не 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 и распространяется в виде LLVM bitcode (который может выполняется на некоторой условной NaCl-машине).
После загрузки код верифицируется клиентом и транслируется в родной код (ARM, x86, x64), который и запускается на выполнение. В каком-то смысле можно привести аналогии с Java, Java bytecode, JVM и JIT.
К примеру, вставить в исходник ассемблерный кусок будет нельзя, а вот LLVM bitcode — можно (если он ничего не нарушает, конечно)
(кстати, надо кому-нибудь собраться и написать нормальную статью по этой технологии..)
Код собирается под LLVM и распространяется в виде LLVM bitcode (который может выполняется на некоторой условной NaCl-машине).
После загрузки код верифицируется клиентом и транслируется в родной код (ARM, x86, x64), который и запускается на выполнение. В каком-то смысле можно привести аналогии с Java, Java bytecode, JVM и JIT.
К примеру, вставить в исходник ассемблерный кусок будет нельзя, а вот LLVM bitcode — можно (если он ничего не нарушает, конечно)
(кстати, надо кому-нибудь собраться и написать нормальную статью по этой технологии..)
Си и Си++ все равно в пролете!
Про LLVM bitcode это проект PNaCL — но он ещё в разработке, а пока нужно обирать под каждую архитектуру.
Ох, лучше бы они PNaCl подождали, прежде чем внедрять.
Я больше верю в верификатор байт-кода, чем в верификатор x86/arm/x64. Ну и плюс остальные плюшки.
Я больше верю в верификатор байт-кода, чем в верификатор x86/arm/x64. Ну и плюс остальные плюшки.
Согласен, в текущем виде 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
LLVM сейчас вполне себе на переднем крае компиляторов. И да, конечно, он не кроссплатформенный, он скорее платформонезависимый. Там есть какой-то момент, когда они имеют «промежуточное представление» кода (IR), которое может быть напрямую оттранслировано в машинный код (вероятно, с какими-то оптимизациями под native instruction set).
The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent.
Т.е. они просто выхватывают из компилятора то, из чего он сам бы на след. этапе делал машинный код, верифицируют и вперед.
The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent.
Т.е. они просто выхватывают из компилятора то, из чего он сам бы на след. этапе делал машинный код, верифицируют и вперед.
Как я понимаю (чисто теоретически), они используют виртуальную машину, которая выступает мостом между браузером и процессором, но имеет свое адресное пространство, которое не пересекается с пространством ОС. Гугл вообще обожает виртуальные машины (ну или делает вид что обожает :) возьмите хотя бы V8 каждый браузер — отдельный процесс, вот вам уже защищенность — в другой процесс влезть сложнее.
Нашёл, что у них есть проект PNaCL — используют промежуточное представление LLVM и компилируют на таргете. Вот это как раз то, о чём я всегда мечтал, а native client в котором нужно для каждой архитектуры компилять — не нужен.
И как с этой хренью разруливать сишные макросы, которые различные для разных платформ?
Не использовать такие макросы. PNaCL подразумевает, что есть одна 32х-битная виртуальная, определяет размер и представление типов и возможно даст пару интрисиков для SIMD. Если сильно нужно, то можно использовать обычные условные конструкции самого языка, а llvm выпилит неиспользуемые куски.
Тогда 99% C++ либ сразу лесом идут
Не думаю, ведь все эти либы прекрасно (как правило) умеют понимать, с какими реалиями им приходится сталкиваться; большинство определяет для себя свои типы, пользуясь машинными (просто в данном случае они получат размеры в PNaCl-машине).
Нифига, просто добавляется новый таргет в кучку ифдефов, где уже есть linux, win32, etc…
Ну или уже на уровне llvm придется извращаться
Такими темпами, браузеры видимо вскоре заменят операционную систему. Будем устанавливать не linux/windows/macos, а хромы, огнелисы, оперы и т.п.
Эх, лучше бы сделали возможность отключить передачу личной информации lexchange.ya.ru/replies.xml?item_no=3248
Считаю что одна из целей google и не только, собрать как можно больше информации о людях, представьте — позволить человеку добровольно поведать о себе все, а так-же о его скелетах в шкафу. Шикарная база получится! Скоро наверное предложат имплантировать датчики каждому клиенту, чтобы уж наверняка под колпак взять.
См. www.dirty.ru/comments/320301
Представляете себе контекстную рекламу, предлагающую Вам средства для нормализации артериального давления, например?
(хотя именно мне конкретно эти датчики кажутся мне хорошей идеей)
Представляете себе контекстную рекламу, предлагающую Вам средства для нормализации артериального давления, например?
(хотя именно мне конкретно эти датчики кажутся мне хорошей идеей)
Кто то тут жаловался, что при использовании Native Client в Android невероятно медленная отрисовка на экран (90% времени копируется изображение)… это я о том, что крутая скорость машины будет полностью перекрываться ограниченной скоростью передачи данных в/из песочницы.
а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.
а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.
И чем это лучше Java-апплетов тех же? Теже опкоды, тоже вирт. машины, разве что название другое и браузерно-зависимое.
Пол года назад был рад узнать, что работа над Native Client активно ведется в российском подразделении Google.
Что не может не радовать — так это то, что получают распространение технологии типа байткода LLVM и OpenSource native client, а не поганая, закрытая, платная, ненадежная, глючная, уязвимая проприетарщина, как это было раньше (ActiveX, Java, Flash и т.д.).
В этом плане Гугл делает очень хорошее дело, не пытаясь создать свою закрытую платформу.
В этом плане Гугл делает очень хорошее дело, не пытаясь создать свою закрытую платформу.
Only those users with full accounts are able to leave comments. Log in, please.
Native Client включён в состав Chrome