Компания Google сообщила (http://blog.chromium.org/2013/01/native-client-support-on-ar...) об успехах в создании многоплатформенного варианта технологии Native Client (https://developers.google.com/native-client/) (NaCl), которая позволяет выполнять приложения, написанные на C и С++, в специальном изолированном окружении web-браузера. В тестовый выпуск Native Client SDK 25 (https://developers.google.com/native-client/sdk/download) добавлен (https://developers.google.com/native-client/sdk/release-notes) набор инструментов и компиляторов, необходимых для сборки NaCl-приложений для платформ ARM, в дополнение к ранее поддерживаемой архитектуре x86. Поддержка ARM позволит организовать распространение NaCl-приложений не только для традиционных ПК, но и для мобильных устройств, базирующихся на платформах Android и Chrome OS.
Для адаптации уже собираемых с использованием Native Client и newlib (http://www.sourceware.org/newlib/) приложений для платформы ARM достаточно прикрепить к приложению ARM .nexe и внести изменения в сборочный манифест (https://developers.google.com/native-client/devguide/coding/...). Что касается клиентского ПО, то начиная с версии Chrome 25 в браузер будет добавлена обновлённая реализация системы плагинов Pepper (http://www.chromium.org/nativeclient/getting-started/getting...-), поддерживающая выполнение NaCl-программ на платформе ARM. Изначально Native Client был интегрирован в Chrome начиная с выпуска 10 (активирован по умолчанию в Chrome 14) и дополнительно поставлялся в виде браузерного плагина для Firefox, Safari и Opera.
Кроме того, в течение 2013 года планируется выпустить Native Client нового поколения, который будет поставляться под именем Portable Native Client (http://src.chromium.org/viewvc/native_client/data/site/pnacl...) и будет обеспечивать полную независимость от архитектуры, на которой производится запуск NaCl-приложений. Благодаря поставке NaCl-приложений не в машинном коде, а в биткоде LLVM, появится возможность выполнять NaCl-приложения на разных платформах, без подготовки отдельных сборок для каждой из платформ (биткод LLVM будет транслироваться в машинный код текущей платформы на стороне браузера).
Native Client продвигается как платформа для создания универсальных web-приложений, написанных на языке C/C++ и использующих специальный API для выполнения свойственных web-приложениям действий. SDK базируется на GCC и стандартных инструментах разработки GNU. Собранные с использованием Native Client приложения выполняются в виртуальном окружении внутри браузера всего на 3% медленнее по сравнению с производительностью работы немодифицированных версий тех же программ. С точки зрения разработчика окружение Native Client выглядит как небольшая операционная система со своим, основанным на GCC, инструментарием для кросс-компиляции, частичной поддержкой POSIX и базовым мультимедийным API, который можно использовать для работы с аудио и видео, обрабатываться события от мыши и клавиатуры.
Также доступен ряд свойственных web-приложениям функций, таких как загрузка внешней страницы. В этом плане Native Client позволяет организовать выполнение тех же функций, что может обычное web-приложение на JavaScript. Инструкции при работе программы в Native Client не преобразуются в байткод виртуальной машины, а выполняются как есть, с максимально возможной производительностью. Безопасность в Native Client достигается через изоляцию системных вызовов и прерываний - разрешено выполнение ограниченного набора системных вызовов, остальное либо запрещено, либо эмулируется специальным runtime-кодом. Сетевые и дисковые функции, а также операции для работы с памятью, обрабатываются специальной подсистемой. Обращение за пределы дозволенных областей памяти блокируются через задействования системы обработки исключений CPU.URL: http://blog.chromium.org/2013/01/native-client-support-on-ar...
Новость: http://www.opennet.me/opennews/art.shtml?num=35907
звоните в микрософт, пусть срочно патентуют "ехе" в конце имени файла. этак можно будет ещё по паре баксов сверху наваривать
Одни переходят на HTML5, другие делают Native Client для браузера. Интересно чем это закончится.
Единство и борьба противоположностей во всей красе :-) Только вот мало надежды, что даже Mozilla это поддержит, а об остальных и говорить нечего.
зачем поддержка от мозиллы - сами для нее плагин пишут:
"Изначально Native Client был интегрирован в Chrome начиная с выпуска 10 (активирован по умолчанию в Chrome 14) и дополнительно поставлялся в виде браузерного плагина для Firefox, Safari и Opera. "
NaCl не альтернатива HTML5, это альтернатива JS.
Для веб-приложений - ох, не факт, если взлетит. Всё же HTML, даже пятый, для формочек подходит очень условно, там вечно в вёрстке куча странностей. Не удивлюсь совершенно, если (при условии повсеместного распространения NaCl) вместо приложений на HTML5 будет какой-нибудь QT/NaCl/Canvas. Или вообще нативная отрисовка через OpenGL ES в выделенном буфере примерно как у флеша.
> Всё же HTML, даже пятый, для формочек подходит очень условно, там вечно в вёрстке куча странностейэто временная проблема. потомучто:
1. всё больше и больше мир технологий плавно переходит к тому что вёрстка должна выполнятся -- именно на стороне клиента а не сервера. и HTML5 не протеворечит этой тенденции.
и это справедливо! сервер должен выдавать только статические файлы (html,js,css,png,xml) и чистые данные (json), а не заниматься HTML-вёрсткой.2. нет нужды дожидаться когда в HTML5 появтся очередные виды Layout . уже сейчас можно можно создавать/использовать Javascript-Фрэймворки, которые будут выполнять реализации различных Layout.
> Не удивлюсь совершенно, если (при условии повсеместного распространения NaCl) вместо приложений на HTML5 будет какой-нибудь QT/NaCl/Canvas. Или вообще нативная отрисовка через OpenGL ES в выделенном буфере примерно как у флеша.
тоесть всё что перечисленно в пунктах выше [1]и[2] -- реализовывается более дешёвыми человекочасами, чем переход к "QT/NaCl/Canvas" [хотя это и ведь тоже частный случай вёрстки на стороне клиента:)] :)
Ок. Как на HTML5 можно сделать, чтобы некий элемент формы забрал всё оставшееся свободное место по X или по Y?Джаваскрит-фреймворки - это отдельная песня. Оверхед там просто феерический - помнится, сенча успешно тормозила на своих же демках. И это логично - когда вместопростейших операций по отрисовке надо поднять кучу DOM-объектов и задать довольно сложное поведение по их прееключению/смене стиля - откуда здесь скорость?
Другое дело, если б разработчики HTML5 дали какую-то низкоуровневую механику для построения контролов - хотя бы стандартизировали бы доступ к Shadow DOM, плюс создали хоть один лайаут, имеющий понятие free space у контейнера, и дающий соответствующие средства маштабирования его детей - тогда может и вышло бы что. Неужели так трудно с Gtk или виндового декларативного языка содрать (забыл, как там его)?
А пока, разумеется, форма на Qt делается много быстрее (хотя бы за счёт того, что там костыли из стилей рисовать не надо). Портирование кутей на канвас - да, займёт время. Думаю, что довольно небольшое - там чуть ли не линейный маппинг одних примитивов в другие. Кроме того, - процесс разработки десктопных приложений наработан за много лет, для вебовских и близко ничего подобного пока нет.
Пока что HTML5 - это не дешевый, а просто единственный способ разработки приложений, которые не надо было бы устанавливать, мучаться с апдейтом и при этом чтобы они запускались более-менее везде (тот же флеш на айпаде не взлетит, как известно, джавы - тем более много где нет). Здесь вообще не о скорости разработки речь, а о том, что альтернатив нет.
NaCl
прочичал как натрий хлор
А надо было как хлорид натрия
>NaCl
>прочичал как натрий хлорТак в этом-то вся и соль. :)
Вот что значит советская средняя школа.
это типа Java апплета, только на C
Нет.
При чём 2-а раза — сабж продолжает выполнятся в песочнице и не имеет доступа к ресурсам и библам целевой системы, апплеты же ограничены искус..но, но фактически ничем не отличаются от клиентского ПО на жабе.Зыж
Проще понять сабж, представив как ПО выполняющееся в черуте/контейнере/виртуалке(с_натяжкой).
В данный момент это машинный код, выполняемый в песочнице, который безопаснее чем байт-код
Использование LLVM - это круто. Насчёт языков программирования, так можно будет задействовать и Python, и Lua. Это не проблема. Мне интересно, есть ли возможности писать OpenGL приложения на NaCl. По идее - можно. И ещё. Будет ли добавлена возможность дёргать вызовы системных либ за пределами песочницы(естественно только для доверенных приложений).
> писать OpenGL приложения на NaClПоддерживается OpenGL ES.
Эх, выстрелила бы эта штука, можно было бы о JS забыть как о страшном сне для всего мало-мальски серьёзного. Правда, на что менять - не совсем понятно, но это уже дело наживное.
Эм, ну не получится.Отображение через прямоугольник, а вот доступ к файлам и ещё кое чему через мост на js.
Ну, мост - это не страшно. Страшно, когда на JS пишется развесистая логика, а в нём ни типизации, ни контрактов, ни интерфейсов - ничего, сплошной duck typing.
NaCl в андроиде - это типа виртуалка в виртуалке?
Почему в виртуалке? На андроиде три тысячи лет как NDK есть, там и будет жить.
Если этот NaCl такой изумительный инструмент (нативно в Chrome, в виде плагинов для остальных браузеров), то почему на нем не запилят, например, воспроизведение видео в web? Зачем-то используют Адоб Флэш...
> почему на нем не запилят, например, воспроизведение видео в web?потому что оно и так нативно запилено через тэг video
> Зачем-то используют Адоб Флэш...
извращенцы
А еще на нем работает эмулятор Спектрума =) usp
Сплошные приветы из 90-х на этой неделе. Facebook поиском на естественном человеческом языке озаботился, Google Java-апплеты реанимировать хочет...
ждём Qt под NaCl
Был билд, пробовал его 2 года назад. С трудом но кое-что работало.
где же их язык Go :(
На их же серверах. Ваш К.О.
> Кроме того, в течение 2013 года планируется выпустить Native Client нового поколения, который будет поставляться под именем Portable Native Client...всё это имеет определённую степень замечательности -- ТОЛЬКО лишь в том случае если разработчики web-приложений НЕ будут использовать NaCL (отличный от PNaCL).
тобишь если Google выпустит PNaCL но НЕ закроет проект старого NaCL -- то это будет эпичный FAIL
кто-нибудь вообще его пользует?
Portable Native Client - вот это правильно! Я прям угадал, что так будет.Надо было Ведроид на подобной технологии делать, а не Далвик мутить.
Все серьёзные приложения под Ведроид по факту нативный код юзают.
Новый ActiveX от Google? О_о
Таки кошерный ;-)
Такими темпами выпилят жабу из ведройда.