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

    С 2008 года компания Google ведёт разработку открытой (open source) технологии Native Client, которая позволяет запускать x86-код в браузере, с ограничениями безопасности, как у JavaScript. Не нужно объяснять, что благодаря Native Client появится новое поколение браузерных приложений с прямым доступом к ресурсам центрального процессора. В каком-то роде это именно то промежуточное звено, которого не хватало между нативными приложениями и веб-приложениями.

    Два с половиной года Google работал над тем, чтобы устранить проблемы с безопасностью Native Client, и вот наконец-то это свершилось: вчера Native Client включён в состав последней беты Google Chrome 14.

    Приложения Native Client используют программные интерфейсы Pepper (PPAPI), которые являются апгрейдом Netscape Plugin API (NPAPI) — технологии, используемой в большинстве браузеров, кроме Internet Explorer (ActiveX).

    В новом релизе Chrome появилась также поддержка Web Audio API с различными аудиоэффектами, которые особенно пригодятся для создания игр.
    Поддержать автора
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 105

      0
      очень хочется верить, что за 2 года Google тщательно проработали механизм безопасности. технология тянет на революционную (:
        +13
        Революционнее, чем ActiveX?
          +8
          ActiveX — это все-таки обычный exe-шник который запускается браузером. Здесь же что-то вроде виртуальной машины для x86, что гораздо круче.
            +2
            Но в том же ActiveX можно было сделать что-то вроде «песочницы», чтобы все подряд не выполнялось, но вот кое-кто не позаботился об этом, и теперь это, возможно, будет все-таки революционной технологией, но только не для МС.
              0
              К сожалению, об этом осведомлены не все разработчики компонент…
                +6
                Технология это не только первое внедрение, но и PR, не Билл Гейтс придумал MS DOS, но грамотно его продал. Не Страуструп придумал объектный подход к программированию на C, но он стал отцом C++, вдохновленный другими языками. Примеров не счесть. Так что неудивительно, что Гугл переоткрыл то что было сделано ранее, но в новой форме. Когда-то и javascript был в забвении и прозябал в виде сценариев для эффектиков и снежиночек, пока не наступила пора ajax, jQuery и т.п.
              0
              Да.
              +1
              А вы почитайте, там всё достаточно здорово и остроумно сделано.
              +3
              Т.е. Delphi нельзя? А VB в native тоже? Видать и с другими языками будет проблема, да? Не позорьтесь, речь идет о native коде в принципе, любую скомпилированную либу можно без проблем подключить и использовать. Понятное дело что удобные АПИ для других ЯП появятся в ближайшее время, стоит только продукту попасть в продакшен.
                +4
                Вообще любой язык проблема только в биндингах, Native Client выполняет код для x86, просто ализар верятно сам не знает про что пишет
                  0
                  Я об этом и говорю.
                    0
                    Извиняюсь, просто меня самого так бесило незнание того о чем говорят что только прочитав часть коментария написал комент.
                  –1
                  Думается мне, будут проблемы с подключением других ЯП и библиотек, т.к. безопасность. Это же не виртуализация, а статический анализ машинного кода — чтобы позвать функцию из внешней библиотеки, нужно и её проанализировать и доказать что она безопасна.
                    +2
                    Там нечего хитрого. Предоставляется доступ к ограниченному API (как для JS, грубо говоря) для обычного кода, созданного слегка модифицированным кодогенератором, который использует ограниченный набор инструкцийи выравнивает jmp по границе в 16, кажется, байт — чтобы сделать невозможными фокуусы вроде «джамп на адрес». Соответственно, клиент проверяет корректность набора опкодов и выравнивания — и всё.
                      –1
                      Так а причём тут «хитро»? Вызов внешних библиотек-то явно ограничен, иначе бы ни о какой безопасности и речи не шло, а значит и будут сложности с другими платформами, и даже банально с сишными библиотеками, которые придётся пересобирать под их модифицированным компилятором и поди ещё обязательно статически линковать.
                        0
                        Насколько я помню, статически линковать не обязательно, а пересобрать — да. Смотрите на это как на веб-аналог андроидского NDK — т.е. нативный код, ориентированный прежде всего на оптимизацию быстродействия. Хотя, вероятно, позже появятся и поддерживающие его библиотеки.
                      +1
                      Проблема не столько в самих расширениях, сколько в рантайм библиотеках их языков. Например MSVCRT.dll для Visual C++ или RTL.bpl для Delphi. Эти библиотеки тянут функции операционной системы, поэтому из загружать в браузер никак нельзя.
                      Подозреваю, что Google просто предоставит собственный рантайм или статическую либу, на основе функций из которой и будет строиться браузерное приложение.
                      Поэтому что бы написать приложение для NPAPI придется тщательно настраивать набор импортируемых модулей в своём проекте. Т.е. дельфийские формы или MFC заюзать не получится в любом случае, только компилятор.
                        +1
                        Рантайм библиотеки-то как раз проблем нет статически прилинковать. А вот с системными вызовами уже сложнее, да и с любыми внешними библиотеками как я уже сказал.
                          +2
                          Скорее всего, не пойдет и рантайм без перекомпиляции, т.к. там код должен быть определенным образом выровнен в соответствии с требованиями Google (судя по статьям). Ну а когда перейдут на PNaCl — то пересборка очевидным образом будет необходима.
                            –1
                            Да, но они ведь уже запускали что-то вроде doom, так что эта проблема уже должна быть решена. Главное, что dll для C/C++ рантайма не необходима, в других языках может быть другая ситуация.
                              0
                              Думаю, они его собрали из исходников с помощью модифицированного GCC toolchain (который и предлагают скачать).
                      +2
                      Нужен не просто компилятор, а особый компилятор, которые генерирует особый машинный код.
                      +1
                      а разве NaCl не был в хроме? Я почему-то был уверен что он давно уже в хроме.
                        +36
                        Чёрт, один я прочитал NaCl как натрий-хлор? :)
                          +5
                          Более того, если бы не ваш комментарий, я бы долго сидел и думал при чем тут соль… Сказывается направленность образования, пардон)
                            0
                            NaCl, а к нему Pepper (перец). Разработчики не заморачивались с названиями :)
                            +6
                            NaCl в Cr. Это хлорид натрия в хромированной упаковке?
                              +4
                              логотип — солонка
                                0
                                Патентуй идею :)
                            +1
                            Он был выключен по-умолчанию. Теперь наверное включили.
                            +3
                            Прощай кроссплатформенность веба?
                              +2
                              Пошли на второй заход ))
                                0
                                Потом будет PNaCl и все станет кроссплатформенным. Странно, что они сразу его не включили…
                                +6
                                >запускать x86-код
                                meh. HTML5, кросс-платформенность, ChromeOS и при это — код для x86. По-моему, это движение не вперёд, а назад.
                                  0
                                  *при этом
                                    +8
                                    Это движение в сторону я бы сказал.
                                    +3
                                    Увы это единственный способ делать то, что сегодня хотят клиенты — во многих специфических областях
                                      –14
                                      Ну да, единственный? А флеш? На флеше можно сделать практически все, что угодно.
                                        –11
                                        Минусующие карму, вы бы хоть писали за что? Или тупо за нелюбовь к флешу? Дак я и не агатирую, просто привожу факты.
                                          +10
                                          Нет, не все, и не все на приемлемой скорости
                                            –9
                                            Про какую скорость вы говорите? На нем многое работает: видеотрансляции, всевозможные игры, тубы. Что касается рендеринга графики, то тоже все в порядке, подрубили ж аппаратное скорение. По крайней мере если визуально так сравнивать, то обработка флешевого 3д и нативного на моей машине происходит с одинаковой скоростью.

                                            Скорость более чем приемлимая имхо.
                                              0
                                              Например, сложный финансовый анализ над загруженными данными, к которым одновременно приходит постоянно новые данные.
                                                –1
                                                Java?
                                                  0
                                                  нет, далеко не всегда подходит + требует от клиента телодвижений больше, чем трейдер может (хочет) сделать
                                                +2
                                                Тогда покажите мне игру на флеше с уровнем физики хотя бы как в World of Goo. Таких нет. Есть множество синтетических тестов, показывающих разницу в скорости с native кодом в разы, а то и на порядки.
                                                Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
                                                Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.
                                                  –1
                                                  Для последних версий Flash'a просто не успели еще ничего написать. Но вот скажем можно посмотреть демку (это для беты fp 11), которая о многом говорит:
                                                  www.youtube.com/watch?v=EzZS7RoJFEE&feature=youtu.be&hd=1

                                                  А с нативным кодом виртуальные машины просто не нужно сравнивать.
                                                    0
                                                    Не увидел физики вообще. Да, 3D движок красивый, но, во-первых это не имеет отношения к физическому моделированию, во-вторых не верю в то, что эта демка имеет схожие системные требования с её аналогами с классической демосцены.
                                                  +1
                                                  К примеру, для шифрования скорость непотребная совершенно. Хочешь видео — приходится использовать кодеки, понимаемые плеером. И так далее, и тому подобное. Нет уж, NaCl интереснее, да ещё и не привязан к конкретному языку программирования.
                                                    0
                                                    Допустим я хочу запустить в браузере видеокодек какого-нибудь изощренного формата, для которого нет нативной поддержки. Или, скажем, эмулятор Nintendo 64. Все это:

                                                    1) Невозможно реализовать на других языках с приемлимой скоростью.
                                                    2) Уже существует огромное количество кода на С под подобные предметные области. Портировать на другие языки может быть просто не практично.
                                                  –1
                                                  Флеш, по крайней мере на данный момент, — довольно небезопасная технология. И сравнивать её с Native Client, думаю не стоит.
                                                    0
                                                    Как сказать, кстати. И там, и там байткод.

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

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

                                                          Это просто разные представления о доступе. То, что вы говорите — умеет и броузер. А может ли флеш без диалогов и т.п. просто вычитать файл c:\1.txt (а если нет — то создать его)?
                                                            0
                                                            Чтение файлов с диска пользователя без запроса — это нарушение конфиденциальности.
                                                            Открыл сайт, а он без твоего спроса конфиденциальную информацию с диска на сервер перекачивает. Или наоборот что-то дописывает в системные файлы.
                                                              0
                                                              То-есть говоря по-просту: не умеет. Это и имелось в виду под «нет доступа».
                                                        0
                                                        Ну Flash вообще-то технология временная. Он лишь показал что именно нужно разработчикам: видео, аудио, векторная графика, динамические запросы, WebGL… Но теперь его время уходить или превратиться во что-то более крутое.
                                                          0
                                                          Банк-клиент с доступом к хардварному токену.
                                                            0
                                                            а реализация доступа к устройствам? не все токены работают по одному протоколу
                                                            это я к тому, что на nacl тоже не все можно сделать
                                                            0
                                                            да, но КАК.

                                                            картинку не буду вставлять.
                                                            0
                                                            Ага, с одной стороны имеем все проблемы разработки «под броузер», а с другой не получаем удобств веб-приложений.
                                                            0
                                                            вот-вот, да еще и писать на чем-нибудь низкоуровневом
                                                              0
                                                              Писать там можно на чём угодно. К примеру — вполне реально прикрутить Cython.
                                                              0
                                                              Гугл активно занимается реализацией NaCl на база llvm — там вроде как с кроссплатформенностью нормально. Впрочем, и сейчас можно скомпилировать несколько бинарников (x86, amd64, arm) — от операционной системы код не зависит, только от архитектуры процессора.
                                                              +3
                                                              технологии Native Client, которая позволяет запускать x86-код в браузере

                                                              x86-64 и ARM тоже.
                                                              К [if IE] и [if Opera] добавятся [if ARM] и [if x86-32] :)
                                                                0
                                                                Нет, это будет сделано прозрачно (см. ниже).

                                                                Более того, для добавления новых архитектур нужно будет лишь обновить NaCl, без всяких пересборок программного кода.
                                                                0
                                                                мне вот дико интересно, как они будут держать его внутри песочници и как обеспечивать кроссплатформенность (для ARM он у них тоже есть).
                                                                  0
                                                                  Для каждой архитектуры нужно отдельный бинарик собирать. По поводу секурити самому интересно.
                                                                    +2
                                                                    Не нужно. Я немного пробежался по статьям.

                                                                    Код собирается под LLVM и распространяется в виде LLVM bitcode (который может выполняется на некоторой условной NaCl-машине).

                                                                    После загрузки код верифицируется клиентом и транслируется в родной код (ARM, x86, x64), который и запускается на выполнение. В каком-то смысле можно привести аналогии с Java, Java bytecode, JVM и JIT.

                                                                    К примеру, вставить в исходник ассемблерный кусок будет нельзя, а вот LLVM bitcode — можно (если он ничего не нарушает, конечно)

                                                                    (кстати, надо кому-нибудь собраться и написать нормальную статью по этой технологии..)
                                                                      –4
                                                                      Си и Си++ все равно в пролете!
                                                                        +1
                                                                        Про LLVM bitcode это проект PNaCL — но он ещё в разработке, а пока нужно обирать под каждую архитектуру.
                                                                          0
                                                                          Ох, лучше бы они PNaCl подождали, прежде чем внедрять.

                                                                          Я больше верю в верификатор байт-кода, чем в верификатор x86/arm/x64. Ну и плюс остальные плюшки.
                                                                            +1
                                                                            Согласен, в текущем виде NaCL не интересен. С другой стороны правильно, что зарелизили — народ поиграется, потестит сэндбокс, pepper и т.д. А там глядишь и PNaCL подоспеет.
                                                                            Что до верификации то принципиальной разницы нет — они всё равно только проверяют, чтобы сисколов не было, а само приложение всё равно в сэндбоксе и отдельном адресном пространстве.
                                                                              0
                                                                              Прочтите родные доки — там очень простой и остроумный верификатор. А PNaCl — интересен, конечно, но возникают вопросы: 1) скорость компиляции; 2) LLVM-байт-код, насколько я помню, не кроссплатформеный
                                                                                0
                                                                                1) Подозреваю, что несколько медленнее чем JIT (в виду разных техник) но не сильно. И уж наверняка будут кэшировать результат.
                                                                                2) Я конкретно о IR LLVM ничего не знаю (может там несколько уровней), но PNaCL просто определит абстрактную 32х-битную машину для которой будет генерить промежуточный код.

                                                                                nativeclient.googlecode.com/svn/data/site/pnacl.pdf
                                                                                  0
                                                                                  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.

                                                                                  Т.е. они просто выхватывают из компилятора то, из чего он сам бы на след. этапе делал машинный код, верифицируют и вперед.
                                                                          –1
                                                                          Как я понимаю (чисто теоретически), они используют виртуальную машину, которая выступает мостом между браузером и процессором, но имеет свое адресное пространство, которое не пересекается с пространством ОС. Гугл вообще обожает виртуальные машины (ну или делает вид что обожает :) возьмите хотя бы V8 каждый браузер — отдельный процесс, вот вам уже защищенность — в другой процесс влезть сложнее.
                                                                            0
                                                                            Нашёл, что у них есть проект PNaCL — используют промежуточное представление LLVM и компилируют на таргете. Вот это как раз то, о чём я всегда мечтал, а native client в котором нужно для каждой архитектуры компилять — не нужен.
                                                                              0
                                                                              И как с этой хренью разруливать сишные макросы, которые различные для разных платформ?
                                                                                0
                                                                                Не использовать такие макросы. PNaCL подразумевает, что есть одна 32х-битная виртуальная, определяет размер и представление типов и возможно даст пару интрисиков для SIMD. Если сильно нужно, то можно использовать обычные условные конструкции самого языка, а llvm выпилит неиспользуемые куски.
                                                                                  –1
                                                                                  Тогда 99% C++ либ сразу лесом идут
                                                                                    0
                                                                                    Не думаю, ведь все эти либы прекрасно (как правило) умеют понимать, с какими реалиями им приходится сталкиваться; большинство определяет для себя свои типы, пользуясь машинными (просто в данном случае они получат размеры в PNaCl-машине).
                                                                                      +1
                                                                                      Нифига, просто добавляется новый таргет в кучку ифдефов, где уже есть linux, win32, etc…
                                                                                      0
                                                                                      Ну или уже на уровне llvm придется извращаться
                                                                                0
                                                                                Такими темпами, браузеры видимо вскоре заменят операционную систему. Будем устанавливать не linux/windows/macos, а хромы, огнелисы, оперы и т.п.
                                                                                  –1
                                                                                  Ну, осталось в добавок к ХромОС выпустить ОпераОС, FirefoxOS и ИЕОС, и дело в шляпе.
                                                                                    +2
                                                                                    причем будет иеос6, иеос7 и т.д., все несовместимые)
                                                                                  +1
                                                                                  Эх, лучше бы сделали возможность отключить передачу личной информации lexchange.ya.ru/replies.xml?item_no=3248
                                                                                    0
                                                                                    Считаю что одна из целей google и не только, собрать как можно больше информации о людях, представьте — позволить человеку добровольно поведать о себе все, а так-же о его скелетах в шкафу. Шикарная база получится! Скоро наверное предложат имплантировать датчики каждому клиенту, чтобы уж наверняка под колпак взять.
                                                                                      0
                                                                                      См. www.dirty.ru/comments/320301

                                                                                      Представляете себе контекстную рекламу, предлагающую Вам средства для нормализации артериального давления, например?

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

                                                                                    а это значит, что типичная область применения — вычисления (в т.ч. обработка аудио и видео). Надеюсь доступ к хардварным сопроцессорам (3д аудио постпроцессоры, кодеры и декодеры видео, 3д ускорители,..) по схожей обработке будет предоставлен.
                                                                                      0
                                                                                      И чем это лучше Java-апплетов тех же? Теже опкоды, тоже вирт. машины, разве что название другое и браузерно-зависимое.
                                                                                        –1
                                                                                        Тем, что не завязано на java и нет виртуальной машины как таковой, а есть очень шустрая верификация подмножества нативного кода?
                                                                                          +1
                                                                                          По моему лучше уж пусть завязано на Java будет чем на Chrome, нет?
                                                                                            +3
                                                                                            У Java есть один фатальный недостаток… (С)
                                                                                          +1
                                                                                          Нет там опкодов. Там нативный код.
                                                                                            0
                                                                                            В NaCl нет (там native), а PNaCl (сейчас в разработке) — есть в виде platform-independent LLVM bitcode, или я где-то ошибаюсь?
                                                                                              0
                                                                                              Не знаю, PNaCl не ковырял. И в новости не про него, кажется.
                                                                                                0
                                                                                                Это не те опкоды. Скажем так: у java — «высокоуровневые опкоды», а у LLVM очень низкоуровневые.
                                                                                            0
                                                                                            Пол года назад был рад узнать, что работа над Native Client активно ведется в российском подразделении Google.
                                                                                              +5
                                                                                              Что не может не радовать — так это то, что получают распространение технологии типа байткода LLVM и OpenSource native client, а не поганая, закрытая, платная, ненадежная, глючная, уязвимая проприетарщина, как это было раньше (ActiveX, Java, Flash и т.д.).

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

                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                              Самое читаемое