Наверх ▲

Native Client

Евгений Эльцин Евгений Эльцин Разработчик ПО в Google.
Евгений Эльцин: Меня зовут Евгений Эльцин, я работаю в московском офисе компании Google. Сегодня я хочу рассказать вам о проекте Native Client (сокращение тоже легко запомнить: NaCl – «натрий хлор»). Этот проект посвящен исполнению нативного кода в браузере. Сразу скажу, что это не совсем характерный проект для Google.

Проект делается, в том числе, и в московском офисе. Native Client - это проект с открытым исходным кодом. На код можно посмотреть, попробовать его использовать. Если интересно, то всегда можно выкачать исходники, собрать инструментарий и попробовать написать что-нибудь свое. Будем очень рады, если вы попробуете это сделать и поделитесь с нами результатом!

Для начала расскажу, какую задачу мы пытаемся решить, и зачем вообще мы начали этот проект.

Потом продемонстрирую, что у нас получилось, и подскажу, для чего это хорошо применять. Чуть подробнее остановлюсь том, как это работает. Упомяну технические детали.

Затем постараюсь объяснить, как это будет выглядеть для пользователя. Поясню, что уже работает, что еще не работает.

Напоследок порассуждаю, чем можно воспользоваться, чтобы заработало что-то еще. Эта часть доклада рассчитана непосредствнно на разработчиков.

Какую задачу мы пытаемся решить с помощью этого проекта?

У нас есть клиентская часть веб-приложения и есть десктоп-приложение. На данный момент они, к сожалению, довольно сильно отличаются по своим возможностям. Хорошие черты есть и там, и там. А вот разницу в возможностях хотелось бы уменьшить (в хорошем смысле).

В частности, мы хотим наделить веб-приложение хорошими свойствами десктоп-приложения. Что именно мы относим к хорошим свойствам десктоп-приложений?

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

Второе хорошее свойство – свободный выбор языка для клиентской части приложений. Сейчас, к сожалению, этот выбор очень сильно ограничен. Надо, чтобы была возможность выбирать языки, которые вам хочется использовать.

Допустим, уже есть что-то написанное на определенном языке и хорошо работающее. Очень хочется, чтобы можно было взять это и добавить ваши предложения, не переписывая их как-то кардинально.

С другой стороны, веб-приложение обладает такими свойствами, которых мы не хотели бы лишиться. В первую очередь, веб-приложения гораздо более безопасны по сравнению с десктоп-приложениями. Если вы скачаете откуда-то веб-приложение и запустите его на своем компьютере, у вас вряд ли возникнут какие-то неприятные неожиданности. Мы хотим, чтобы то, что мы делаем, оставалось безопасным.

Еще одно свойство веб-приложения, которое не хочется никоим образом испортить, - это переносимость. Чтобы работали веб-приложения, нужен всего лишь относительно современный браузер. Мы хотим, чтобы ситуация с переносимостью изменилась как можно меньше.

Итак, давайте посмотрим на то, как сейчас обстоят дела в области разработки клиентской части веб-приложений. На одном краю находятся интерпретируемые языки (я назвал их так). Конкретно речь идет о JavaScript. Что хорошего и плохого можно сказать о JavaScript?

JavaScript интерпретируется, и благодаря этому он довольно безопасен. Когда мы что-то интерпретируем, мы всегда можем внимательно следить за тем, что происходит, и, если необходимо, остановить нежелательные процессы.

По той же самой причине JavaScript часто работает медленно. Для многих задач, требующих высокой производительности, возможностей JavaScript не хватает. Мы хотим каким-то образом с этим бороться. Мы хотим улучшить производительность, сохранив безопасность.

В принципе, мы определили для себя одно направление, в котором можно двигаться. Это так называемая компиляция «на лету» (Just-In-Time Compilation). Есть еще один язык, который часто используется на клиентской части веб-приложения. Это Java. В Java компиляция «на лету» была предусмотрена изначально. К сожалению, в JavaScript компиляция «на лету» перешла лишь относительно недавно. В качестве примеров ее реализации можно привести новый движок в Mozilla и решение AV8 от Google.

Работает ли эта технология? Безусловно. Она очень хорошо работает. Во многих случаях производительность поднимается весьма ощутимо. Но иногда этой производительности все же не хватает.

Какие еще проблемы есть проблемы при выборе пути компиляции «на лету»? Обычно хорошие Just-In-Time-компиляторы получаются довольно сложными. Сложность создает предпосылки для появления уязвимостей. Чем сложнее программа, тем больше шанс, что в ней допущена ошибка, - просто потому, что она такая большая.

Есть еще одна трудность, связанная с особенностями языка JavaScript. JavaScript – динамично меняющийся язык. Чтобы сделать серьезную оптимизацию, нужно спрогнозировать, что будет происходить в течение хоть сколько-нибудь продолжительного отрезка времени. Относительно JavaScript делать предположения довольно сложно, все может поменяться. Поэтому JavaScript довольно непросто оптимизировать.

Путь компиляции «на лету» очень хороший. По нему, безусловно, надо идти. Но есть смысл попробовать что-нибудь еще.

Какие еще возможности существуют?

Еще есть возможность исполнять нативный код так, как он есть, на клиенте. Есть плагины, есть ActiveX, мы загружаем нативный код из Интернета и исполняем. При этом то, что мы загрузили и запустили, не не должно сделать нам ничего плохого.

К сожалению, не существует надежных средств, которые позволяли бы проследить за тем, что происходит, когда мы запускаем native код. С производительностью у ActiveX все хорошо, но ситуация с его безопасностью нас совсем не устраивает. Очень хочется подойти к проблеме именно с этой стороны. Хочется попробовать сделать нативный код более контролируемым.

К сожалению, это непросто, потому что операционная система мало чем может помочь в этом деле. Насколько я знаю, в Windows 7 есть некоторые средства, позволяющие регулировать ActiveX отдельно от браузера. До этого, кажется, не было вообще ничего, что позволяло как-то работать с ActiveX.

Наш проект направлен именно на решение этой задачи - мы хотим сделать нативный код более контролируемым, в идеале - таким же безопасным, как JavaScript.

Что такое Native Client?

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

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

У системы, которая у нас сейчас получается, есть своя область применения. Не нужно бросаться переписывать весь веб на нативный код. Это абсолютно ни к чему. Тем не менее, есть вещи, для которых Native Client предоставляет очень хороший инструментарий.

В первую очередь, можно взять те приложения, которые написаны для десктопа, и перенести их в веб практически в том виде, в каком они есть. Например, не нужно переписывать ваш код с C++ на JavaScript. Можно взять код C++ и воспользоваться непосредственно им.

В результате использования нашей системы производительность, конечно, уменьшится, но весьма незначительно. При этом ваша программа приобретет хорошие черты веб-приложения. В частности, с точки зрения пользователей, веб-приложение – очень простая штука. Вы заходите на его страницу, используя URL, – и все. Ничего не надо специально скачивать и устанавливать. С точки зрения простого пользователя это должно быть довольно удобно.

Что еще можно сделать с помощью Native Client?

Если вашему приложению требуются какие-то высокопроизводительные вычислительные куски, то можно взять то, что уже написано на таких языках, как C, C++ и других, и добавить их в ваше веб-приложение.

В качестве примера приведу то, что у нас уже работает. Библиотеки, которые осуществляют шифрование, библиотеки для вычислительной геометрии - все это вы можете взять и встроить в свое веб-приложение.

Плюс ко всему этому – никто не мешает вам написать что-то свое на C, C++ или даже на таком языке, как Assembler. Вы можете писать вставки на Assembler, если вам это действительно нужно, хотя и с некоторыми ограничениями. Можете даже все приложение написать, используя Assembler. Можете использовать полноценные потоки, которых пока нет в других языках (в HTML 5 есть обработчики, но это не совсем то же самое, что потоки).

Если вы используете Assembler, то расширение системы команд в вашем распоряжении. Хотите векторные инструкции? Они будут.

Наконец, стоит рассказать об одной из самых привлекательных вещей, которую можно сделать с помощью Native Client.

Можно взять существующие плагины, которые написаны на нативном коде и запускать их под Native Client’ом. Нам больше не надо будет просить пользователей поверить на слово, что наш код хороший. Есть много вещей, которые хочется сделать безопасными, но при этом все-таки не выкидывать из экосистемы. Я думаю, для них Native Client может стать выходом.

К сожалению, все это не совсем бесплатно. Во-первых, мы не можем запускать бинарники в том виде, в котором они есть. Вам придется воспользоваться нашим инструментарием и перекомпилировать программы из исходных текстов. При этом вам, скорее всего, придется делать какое-то портирование.

Большая часть того, что вам придется делать, связана с общением с окружающей средой: интерфейс с видео, с аудио и так далее. Код, который осуществляет вычисление, вам, скорее всего, практически не придется менять (с очень большой вероятностью – вообще не придется менять). Возможно, придется немного подкорректировать ваши вставки на Assembler. В общем-то, все.

Но далеко не все интерфейсы, которые доступны обычному десктоп-приложению, доступны под Native Client. Тут ничего не поделаешь. Одно из самых существенных ограничений, которое у нас сейчас есть и для которого у нас пока нет хорошего решения (решения есть, но не все они нам нравятся), это запуск другого процесса (форк). Это пока не реализовано должным образом.

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

Как это работает?

Прежде всего, все вопросы вертятся вокруг двух вещей: безопасности и производительности. Что такое производительность, более или менее понятно.

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

Например, если у вас есть плагин для браузера, у него есть интерфейс, по которому плагин может "общаться" с браузером. Никаких других взаимодействий с внешней средой, кроме как посредством вызова функций этих интерфейсов, у нас не будет.

Каким образом можно обеспечить безопасность нативного кода?

Довольно известно – надо посадить код в «клетку», создать вокруг него «песочницу». Код исполняется в «песочнице». Отсутствие посторонних эффектов достигается тем, что мы следим, чтобы не было ни чтений, ни записи, ни уже тем более передачи управления за границу «песочницы».

Исключение составляют те самые явно выписанные безопасные интерфейсы. С точки зрения приложения Native Client, это системные вызовы. Под Linux у нас есть перенумерованные системные вызовы, есть инструкция syscall, которая запускает этот системный вызов. Точно так же это выглядит с точки зрения Native Client. Есть системные вызовы, с помощью них приложение "общается" с миром за пределами своей «клетки».

Каким образом можно создать такую «песочницу»?

Есть два пути, по которым мы пытались пойти. Один из путей – сделать систему полностью динамической. Она может брать существующий нативный код и в процессе исполнения следить за тем, чтобы все было хорошо.

В качестве примера можно привести Valgrind – двоичный компилятор, который исполняет код и следит за тем, что он делает, с разными целями. К сожалению, этот путь нас не устраивает. Это сложный путь, и часто он не обеспечивает необходимой производительности. Если вы работали с Valgrind, вы знаете, что это замечательный инструмент, чтобы отлаживать вашу программу и искать трудные ошибки. Но как постоянная платформа для запуска приложений Valgrind вряд ли вас устроит - налицо очень сильное замедление работы.

Полностью динамические системы нас не устраивают. Значит, достаточно много работы надо возложить на статическую часть. Это значит, что мы будем генерировать нативный код не как придется, а так, как надо.

Наша «песочница» устроена следующим образом. Есть некоторое соглашение, согласно которому должен быть сгенерирован нативный код. Коды-генераторы, языки типа Assembler, инструменты разработчика должны следовать этим соглашениям. Какие-то определенные инструменты разработчика у нас не снабжены статусом "trusted" ("проверенный и допустимый"). Они могут быть какими угодно.

Как осуществляется контроль? Есть часть со статусом "trusted", которая в данном случае встроена в браузер. Это загрузчик, части которого являются валидаторами. Исполняемый код загружается, проверяется, и, если он прошел все проверки, на него передается управление.

Это достаточно простая часть, там нет абсолютно ничего сложного, нет никакой особенной динамики. Все, что нужно сделать, это дизассемблировать, посмотреть, что происходит, и установить правильные начальные указатели. В общем, все. Часть со статусом "trusted" довольно простая, и мы очень надеемся, что ее простота позволит ей быть достаточно надежной и не создавать проблем.

Что такое валидация кода?

Если кто-нибудь из вас занимался чем-то подобным (двоичной трансляцией, валидацией), то вы знаете: чтобы проверить код, нужно сначала его найти. Это уже может быть проблемой. Обычно все, что известно про приложение, это точка входа.

Все, что мы можем сделать с обычным бинарником, это дизассемблировать, начиная от точки входа. Это все. Совершенно необязательно, что мы найдем так весь код, потому что у нас есть передачи управления (есть косвенные), есть самомодифицирующийся код, код, генерирующийся в среде выполнения, и так далее.

Есть еще одна неприятная проблема. Инструкции не однобайтные, поэтому если мы делаем передачу и управление, то мы вполне можем передать управление не в начало инструкции, а в ее середину. Проверяли мы один код, а исполнять будем другой. Довольно неприятно. Этого мы тоже не хотим.

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

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

Дальше мы должны проверить, каким образом передается управление в рамках этого сегмента. Если передача управления прямая (явно написано, на какой адрес мы пойдем), никаких проблем. Однако если передача управления косвенная, мы заранее не знаем, куда придем. С этим нужно как-то бороться.

Две проблемы: границы и передача управления в середину инструкции. Про границы расскажу чуть позже. Передача управления в середину инструкции – очень сложная проблема, которая, к сожалению, требует больших жертв.

Что делаем мы, чтобы решить эту проблему. Все наши инструкции мы организуем в бандлы (англ. bundle). Мы выбрали размер бандлов 32 байта. Мы экспериментировали с разными размерами, этот продемонстрировал нам лучшие результаты по производительности.

Каждый выровненный на 32 байта адрес в сегменте кода – это то, куда потенциально может прийти управление. Ни одной инструкции не разрешается пересекать границу 32 байт. Если необходимо, генератор кода всегда может вставить NOP’ы (это один из источников потери производительности в нашем случае). Когда валидатор загружает код, он проверяет, что каждый 32-байтный выровненный адрес – это адрес, где инструкция начинается, а не середина инструкции.

Дальше косвенные передачи управления, генерируется такой код, чтобы быть абсолютно уверенным в том, что он пойдет на выровненный на 32 байта адрес. Генератор кода должен сгенерировать определенную последовательность, которую валидатор умеет распознавать. Валидатор должен проверить, что любая косвенная передача управления находится в середине такой последовательности.

В качестве примера – то, что происходит на архитектуре x86. Есть обычный косвенный вызов. Мы превращаем его в загрузку адреса в регистр. Дальше мы выравниваем этот адрес на 32 байта и только потом передаем управление. Если валидатор видит передачу управления каким-то другим способом косвенно, то такой код к исполнению он не допускает.

Теперь расскажу про границы. В частности, в архитектуре x86 границы контролировать довольно просто, поскольку есть сегментные регистры. Мы всегда можем выставить сегментные регистры так, чтобы аккуратно защитить наш код и данные. Этим занимается наш загрузчик со статусом "trusted". Задача валидатора в данном случае – чтобы в коде не было инструкции, которая неправильно использует сегментные регистры (пытаются писать сегмент кода или исполнять сегмент данных).

На других архитектурах ситуация гораздо сложнее. Работа с «песочницей» там устроена сложнее.

Как устроено общение с окружающей средой?

Тоже довольно просто. Мы делаем такие штуки, которые у нас называются «трамплины». По сути дела, это следующее. Нативный код выполняет обычный переход на допустимый, с точки зрения валидатора, адрес. Однако, код, на который он переходит, не принадлежит приложению, его создает сам загрузчик в момент загрузки программы.

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

Если кратко, с тем, как это реализовано, в общем-то, все. Что есть в настоящий момент и что будет дальше?

Сейчас у нас есть поддержка для трех архитектур (x86, 64-хбитный x86, ARM). Работает это все и под Windows, и под Linux, и под MacOS.

С браузерами ситуация немного сложнее. Изначально была поддержка Google Chrome и плагин для Firefox. Сейчас есть большое желание инженеров Chrome переделать интерфейс плагина с браузером. Поэтому то, что сейчас есть в плагине для Firefox, отличается от того, что есть в Chrome.

Какие-то примеры могут работать только в Chrome. Более того, поскольку эти интерфейсы – по-прежнему предмет разработки, они только приобретают окончательную форму. Что-то может работать только в Chrome 5, что-то – только в Chrome 6 и так далее. Мы надеемся, что это очень скоро прекратится. Тем не менее, сейчас это есть.

Если у вас стоит девелоперская сборка Chrome, то вы можете попробовать это использовать наше решение уже сейчас, если запустите Chrome с флагом командной строки “—enable-nacl”.

Теперь вернемся к вопросу переносимости. Он довольно сложный. Как его решают сейчас и как собираются решать потом? Сейчас это устроено так, что разработчик собирает свой код в столько бинарников, сколько архитектур он собирается поддерживать (в данный момент – 3). Клиентская страничка автоматически убирает нужный бинарник, скачивает его и запускает.

Мы хотим попробовать уйти от этого и сделать систему, которая будет распространять исходный код в переносимом независимом промежуточном представлении. В качестве такого представления мы пытаемся использовать bitcode, который делает система компиляции LLVM.

Соответственно, приложение будет существовать в Интернете только в виде bitcode и транслироваться непосредственно в момент загрузки на клиенте. Причем этот транслятор необязательно должен иметь статус "trusted". Он точно так же может запускаться под Native Client’ом. Еще один вариант – запустить translation-сервера, которые будут транслировать и кэшировать bitcode.

Есть очень интересные возможности решить проблему переносимости таким способом.

Как это будет выглядеть с точки зрения простого пользователя?

Пришел на страничку – приложение запустилось. Что внутри? Как я уже говорил, внутри есть просто HTML-элемент, в котором указаны 3 (сейчас) бинарника. Клиент умеет выбирать нужный бинарник, исходя из того, на какой архитектуре он запущен.

Дальше с этим объектом можно общаться при помощи JavaScript - использовать его функции, запускать его работу, что-то от него получать, что-то ему передавать.

Кроме того, это решение работает как плагин. Интерфейс между браузером и Native Client’ом – это интерфейс браузер-плагин.

Что уже есть?

Я перечислил очень мало. В принципе, самые простые примеры вместе с исходным кодом есть в галерее. Ссылка на галерею есть на страничке проекта, на code.google.com. Там очень простые примеры, которые, в основном, показывают суть технологии. Есть очень много вещей, которые мы пробовали компилировать и запускать, которые работают.

Мы пробовали сделать это с оригинальным Quake – все отлично. Это не GQuake, никакой не переписанный, а тот, который есть на C, C++. Компилируем, запускаем. Всякие вычислительные модули. Точно так же можно запустить Python, Ruby, Lua.

Это хороший вариант, чтобы программировать ваш клиент, например, на языке Python. Также работает Mono (dotnet-машина с открытым исходным кодом). Если вам нравится C-Sharp, можно пользоваться им.

Если кто-то слышал, есть платформа для игр Unity и Unity 3D. Она тоже у нас работает. 

Что у нас есть для разработчиков?

Для разработчиков это выглядит следующим образом. Кто-то переживал насчет трех разных бинарников для трех разных архитектур – это действительно неприятно. Тем не менее, с точки зрения разработчика, платформа Native Client всегда выглядит одинаково независимо от целевой архитектуры и от операционной системы хост-компьютера.

Это всегда модель данных ILP32. Указатели переменных типа "long integer" у нас 32-битные. "Общение" с операционной системой напоминает Linux. Это Linux, у которого есть не все доступные системные вызовы. Бинарники, в которые мы распространяем, это обычные ELF.

"Общение" с браузером проходит по тем интерфейсам, которые изначально для этого предназначены. Изначально это Netscape Plugin API. Как я уже говорил, с точки зрения команды Chrome, в нем есть недостатки. Они попытались его переработать. То, что делают они, называется Pepper.

В этом смысле между браузерами сейчас есть несовместимость. Это все только-только приходит в норму именно по той причине, что сделана попытка переработать "общение" плагина и браузера. С нашей и вашей помощью это должно быть сделано.

Из чего состоят инструменты разработчика?

Кто знаком с разработкой под Linux – это честный инструментарий Gnu. В данном случае компилятор gcc и стандартные библиотеки, которые к нему прилагаются. У нас не самый свежий gcc. Тем не менее, в ближайшее время мы собираемся это поправить.

Если вы собираетесь писать под Native Client, то мы портировали уже достаточно большое количество библиотек. Это все выложено в Интернете в виде патчей. На иллюстрации есть примеры тех библиотек, которые уже портированы. Их довольно много, я перечислил те, которые пришли в голову. В частности, компрессия, кодировка, XML и еще много чего.

Чего еще нет, и в чем хотелось бы видеть участие разработчиков со стороны? Хочется иметь GTK. Пока мы не пробовали его портировать. Хочется SDL. Если мы портируем SDL, у нас сразу откроется огромное количество игрушек и другого обеспечения, которое использует SDL. Наш порт SDL есть, но он пока очень слабый. Просто руки не доходят сделать его более или менее прилично.

Если вам хочется видеть что-то запущенным под Native Client, мы будем рады, если вы попробуете, запустите. Если не получится, то расскажете, почему не получилось.

В общем-то, все.

Вопросы и ответы

Вопрос из зала:
Планируете ли вы использовать, портировать Cute?
Евгений Эльцин:
Да, планируем.
Вопрос из зала:
Когда?
Евгений Эльцин:
Если честно, насколько я знаю, какие-то попытки на эту тему уже сделаны. Но точно, к сожалению, не могу сказать. Но Cute точно планируют портировать.
Вопрос из зала:
Сколько времени заняло портирование Quake?
Евгений Эльцин:
Про Quake я, к сожалению, точно не знаю.
Вопрос из зала:
Любой другой пример чего-нибудь большого.
Евгений Ельцин:
Хорошо. Есть такая забавная игрушка, называется Jump 'n Bump, SDL-ная. Кто-нибудь в нее играл? Там зайцы прыгают друг другу на голову, при этом в разные стороны летит кровь и ошметки. Очень весело. Это простая SDL-ная игрушка, она есть в дистрибутивах Ubuntu. Мой коллега портировал ее примерно за 3 дня, не отрываясь от основной работы. Это еще включало написание мини-порта SDL. Нужно было сделать кусочек SDL, который работает с видео и звуком. Остальная игрушка скомпилировалась практически без правок. Единственное, пришлось немного исправить ошибки в самой игрушке, потому что она пыталась писать за «песочницу». К сожалению, у нас еще до конца не работает общение с файлами через браузер. Поэтому пришлось файлы данных игрушки вкомпилировать в исходный код. Больше ничего делать не пришлось.
Вопрос из зала:
Какие примерно сроки для "production-ready"?
Евгений Эльцин:
Я думаю, что пробовать вы можете уже сейчас. Я уже говорил. Какой-то из следующих более или менее стабильных релизов Chrome будет с опцией enable-nacl, включенной по умолчанию.
Вопрос из зала:
Production ready – это как минимум еще Internet Explorer.
Евгений Эльцин:
Насчет Internet Explorer ничего не могу сказать.
Вопрос из зала:
Будет какая-то сертификация кода?
Евгений Эльцин:
В каком смысле?
Вопрос из зала:
Есть сервер, его взломали, код поменяли.
Евгений Эльцин:
Код всегда проверяется непосредственно перед исполнением. Подписывать мы его никак не будем. Что конкретно вы имеете в виду?
Вопрос из зала:
К примеру, будут какие-то серверы с сертификацией, которые будут считывать код, брать контрольную сумму и проверять на серверах.
Евгений Эльцин:
Что мы хотим так проверять?
Вопрос из зала:
В случае подмены кода.
Евгений Эльцин:
Подмены какого кода?
Вопрос из зала:
Того, который будет загружаться валидатором.
Евгений Эльцин:
С точки зрения безопасности нам это не нужно. У нас есть валидатор, который проверяет код непосредственно перед исполнением. Наверное, я не очень понял вопрос. Я не понимаю, зачем нужно подписывать код.
Вопрос из зала:
В случае если валидатор не до конца отработал, что-то пропустил.
Евгений Эльцин:
Если валидатор не до конца отработал, нашу технологию можно выбрасывать на помойку. Либо он работает, либо нет.
Вопрос из зала:
Насколько я понимаю, основная идея заключается в повышении производительности клиентской части. Если, допустим, используется приложение, написанное на dotnet, оно должно быть скомпилировано в вашей среде разработки, в инструментальной среде. Как в этом случае оно будет запускаться под тем же Linux. Для этого нужно устанавливать Mono?
Евгений Эльцин:
Чтобы запустить dotnet под Linux, нужно устанавливать Mono. Но в данном случае, чтобы запустить под Native Client’ом, нужно Mono, скомпилированное под Native Client.
Вопрос из зала:
Клиенту не нужно будет устанавливать Mono, чтобы выполнить код, который скомпилирован под ваше решение?
Евгений Эльцин:
Скорее всего, клиенту нужно будет установить Mono, скомпилированное под Native Client, которое будет дальше исполнять загруженный dotnet.
Вопрос из зала:
Соответственно, мы натыкаемся на те же проблемы. Если мы пишем на dotnet, то клиентское приложение под Windows, будет работать быстрее, чем под Linux. Или, наоборот, на Java, соответственно…
Евгений Эльцин:
Действительно, если сравнивать производительность приложения Mono под Native Client и Mono под Linux, то под Native Client оно будет работать медленнее. Зато вы гарантированы от тех дыр, которые потенциально есть в самом Mono и Java-машине. История развития Java-машины показывает, что, к сожалению, она совсем не безупречна. Мы стараемся именно эти дырки заткнуть. В данном случае если вы будете запускать Java, под Java-машиной внутри Native Client, будет медленнее. Если вы будете запускать dotnet под Mono внутри Native Client, будет медленнее, чем просто под Mono.
Вопрос из зала:
Если приложение написано на Cute (вы озвучиваете, что собираетесь поддерживать Cute), то библиотеки будут подставляться автоматически под Linux или под Windows?
Евгений Эльцин:
Библиотеки всегда будут одни и те же. Они будут под Native Client, если это бинарный код. Он всегда один и тот же. Его форма всегда выглядит одинаково.
Вопрос из зала:
Я имею в виду на клиентской части. Там тоже будети варинаты под одну, под другую систему?
Евгений Эльцин:
Наверное, я не совсем понял. Приложение Native Client – это веб-приложение. Код размещен на сервере. Когда вы заходите на страничку, вы загружаете его себе – на клиент, в кэш браузера или куда положено. Загружаете все, что прилагается к обычной веб-страничке. Соответственно, для всех библиотек они будут находиться в Интернете, скомпилированные заранее под 3 разных архитектуры сейчас и в bitcode потом. Они будут загружаться, повторно использоваться, кэшироваться, как положено.
Вопрос из зала:
Допустим, для Cute вы не будете делать никаких исключений?
Евгений Эльцин:
Исключения убивают идею. Либо мы исполняем все внутри нашей «песочницы», либо у нас проблемы. Мы опять паллиатив, а не какое-то более или менее окончательное решение.
Вопрос из зала:
Я так понимаю, под ARM это не будет работать?
Евгений Эльцин:
Почему?
Вопрос из зала:
Если Cute поддерживает ARM, наверное, не будет работать.
Евгений Эльцин:
Почему?
Вопрос из зала:
Тот же проект Mono для Linux, под ARM это не будет работать.
Евгений Эльцин:
Потому я и не хочу много и долго рассказывать про Cute, что там остаются серьезные вопросы. Тем не менее, все должно работать в итоге.
Вопрос из зала:
В каких еще браузерах это будет поддерживаться?
Евгений Эльцин:
Сейчас – Chrome (это наш основной фокус) и плагин для Firefox, который уже устарел. Мы очень надеемся, что в какой-то момент мы сумеем подтянуть все браузеры. Либо сами, либо с помощью сообщества.
Проект с открытым исходным кодом. Если вы захотите приложить руки и помочь – будем очень рады. Сейчас, можно считать, в основном, Chrome.
Вопрос из зала:
Насколько я понял, валидатор дизассемблирует?
Евгений Эльцин:
Да.
Вопрос из зала:
Несколько раз уже поднималась такая шумиха: некоторые государства законодательно запрещают дизассемблирование. Вы к этому готовы? Что-нибудь исследовали по этому поводу?
Евгений Эльцин:
Насчет юридических вопросов точно надо общаться не со мной.
Вопрос из зала:
Вы ничего не знаете про это?
Евгений Эльцин:
На эту тему, к сожалению, нет.
Вопрос из зала:
Получается, если они введут запрет, то валидатор как таковой может отвалиться?
Евгений Эльцин:
Вообще есть довольно много приложений, которые от этого пострадают. Тот же Valgrind, например. В принципе, на Intel Itanium есть программная система, которая бинарно транслирует код x86. Она тоже окажется под угрозой. Так что будет плохо.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Хейки Линнакангас привез из Финляндии сокровенную информацию о том, что творится в самом сердце ядра PostgreSQL.

Антон Немцев

Антон Немцев

Независимый frontend-разработчик c 14-летним стажем, создатель Frontender Magazine, докладчик на WSD, представитель ВСТ в Украине.

Доклад с примерами использования 3D/2D/анимации с помощью CSS для создания эмоционального дизайна.

Константин Осипов

Константин Осипов

Разработчик и архитектор СУБД Tarantool.

Доклад о новых возможностях Tarantool, появившихся за последние 6 месяцев, и диалог о планах команды на ближайшие полгода.