Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
HTML5? Flash? Даешь баннеры на Native Client, жрущие 100% ресурсов!
habrahabr.ru/blogs/jquery/113681/
Я думаю, что JavaScript сделает это.
Я думаю, что JavaScript сделает это.
Нафиг-нафиг. Идея гугля превратить веб-браузер в замену ОС абсолютно не радует.
Native Client — это альтернатива ActiveX. Знаете сколько банк-клиентов работают только под IE?
Теперь будут только под хром? ;)
Почему бы и нет? У меня лично от хрома только хорошее впечатление по производительности RIA
ru.wikipedia.org/wiki/Native_Client
> Native Client поддерживается в браузерах Firefox, Safari, Opera, и Google Chrome запускаемых под Windows, Mac, или Linux c архитектурой x86.
К слову, ARM-девайсы похоже идут лесом.
> Native Client поддерживается в браузерах Firefox, Safari, Opera, и Google Chrome запускаемых под Windows, Mac, или Linux c архитектурой x86.
К слову, ARM-девайсы похоже идут лесом.
>Native Client — это альтернатива ActiveX
Будут так же ненавидеть :)
Будут так же ненавидеть :)
> Будут так же ненавидеть :)
Только пользователи Internet Explorer и владельцы устройств на базе ARM, потому что похоже в этот раз только они остались за бортом.
Только пользователи Internet Explorer и владельцы устройств на базе ARM, потому что похоже в этот раз только они остались за бортом.
Хотя вот тут подсказывают habrahabr.ru/blogs/google_chrome/114114/#comment_3677493 что с ARM не всё так печально, как я предполагал.
Конечно же НЕ будут ненавидеть. Это же революционная технология от компании, которая не делает зла. Для полного счастья не хватает только яблочка.
Native Client это скорее альтернатива NSAPI, учитывая целевой браузер )
А другого не дано. JavaScript нельзя довести до состояния производительности, необходимого для, например, Photoshop. Так что, путь будет именно таким, браузеры превратятся в OS, или OS превратятся в браузеры.
Ну и чтобы получить Photoshop в браузере — нужно будет скачать бинарников на 100 — 200 мб, при заходе на сайт?
Так не проще один раз скачать нормальный Photoshop?
Единственный плюс будет в том что он будет в окне браузера? Сомнительный плюс.
Да и зачем ещё одна операционная система внутри операционной системы?
Так не проще один раз скачать нормальный Photoshop?
Единственный плюс будет в том что он будет в окне браузера? Сомнительный плюс.
Да и зачем ещё одна операционная система внутри операционной системы?
Скачать бинарники надо будет только 1 (один) раз.
нормальный фотошоп тоже нужно будет скачать 1 раз.
В чем преимущество браузерного? А как ассоциации файлов делать?
Предпросмотр в проводнике? Или проводник тоже в браузере?
Не вижу ни одного плюса от этой технологии — раз уж качать бинарники — то проще скачать нормальную программу.
В чем преимущество браузерного? А как ассоциации файлов делать?
Предпросмотр в проводнике? Или проводник тоже в браузере?
Не вижу ни одного плюса от этой технологии — раз уж качать бинарники — то проще скачать нормальную программу.
Преимущество — без привязки к оборудованию лицензии. Можно работать в любом месте.
Файлы в прекрасном будущем — тоже будут все в сети.
Файлы в прекрасном будущем — тоже будут все в сети.
Мне в последнее время всё больше кажется, что «можно работать в любом месте (обычно имеется в виду интернет-кафе)», что называется, за уши притянуто. Такое чувство, что всем вокруг вдруг стало жизненно необходимо работать где угодно, только не с рабочего компа в офисе. И городить все эти костыли с исполнением «настоящего» кода в браузере… вас история уязвимостей в ActiveX ничему не научила?
Я работаю в любом месте.
Хочется больше мобильности и меньше хлама.
Хочется больше мобильности и меньше хлама.
Одно только сочетание «рабочий комп и домашний» уже заставляет людей мучиться на тему «забыл нужный файл на флэшку скопировать».
И потом, это же не полная замена десктопной парадигме, а альтернатива. Кто предпочитает десктоп, будет сидеть с ним. Кто хочет по полной использовать облака (а таких куча, начиная со школьников, у которых все видео и фото вконтакте) — смогут использовать их более эффективно, чем сейчас.
И потом, это же не полная замена десктопной парадигме, а альтернатива. Кто предпочитает десктоп, будет сидеть с ним. Кто хочет по полной использовать облака (а таких куча, начиная со школьников, у которых все видео и фото вконтакте) — смогут использовать их более эффективно, чем сейчас.
А зачем весь? Он будет лежать на каком-нибудь Amazon'е, а юзер будет подкачивать себе только нужные компоненты. В photoshop же куча dll'ок и ресурсов, там нет exe'шника на 200mb.
Ну с Photoshop может и не очень хорошая идея в браузере запускать, а вот кое-что другое было супер.
Может быть и не все так плохо.
Меня вообще вся это интернетизация пугает. Я хочу хранить файлы у себя на харде, чтобы мои игры обрабатывал мой процессор и моя видяха и чтобы я не зависел так сильно от интернета.
Ведь есть и места где интернета и нету, хоть и таких, даже в России, становиться всё меньше, но на рыболовных судах спутниковые тарелки у нас точно не скоро появятся.
Ведь есть и места где интернета и нету, хоть и таких, даже в России, становиться всё меньше, но на рыболовных судах спутниковые тарелки у нас точно не скоро появятся.
у вас в статье ошибочка малёха
«в брайзере» fix плиз.
«в брайзере» fix плиз.
По-моему, всё, что необходимо для отображения чего хочешь в браузере — CSS, JavaScript, HTML5, Flash, Flex, Silverlight, Java Applets, WPF + ClickOnce — уже придумано. В чём смысл? В создании из браузера комбайна? В облегчении жизни web-разработчикам?
Я, конечно, всеми руками за прогресс и за новые идеи. И очень надеюсь, что Native Client не повторит историю ActiveX. Web всегда пытался абстрагироваться от машинного кода в целях кросплатформенности, не обратный ли процесс мы наблюдаем?
ЗЫ. Хочу, чтобы в мире web был только HTML5, CSS, JavaScript — на клиенте, а всё остальное — на сервере.
Я, конечно, всеми руками за прогресс и за новые идеи. И очень надеюсь, что Native Client не повторит историю ActiveX. Web всегда пытался абстрагироваться от машинного кода в целях кросплатформенности, не обратный ли процесс мы наблюдаем?
ЗЫ. Хочу, чтобы в мире web был только HTML5, CSS, JavaScript — на клиенте, а всё остальное — на сервере.
Смысл в том, чтобы Quake запустить в окошке браузера, желательно, почти не переписывая.
«Хочу, чтобы в мире web был только HTML5, CSS, JavaScript — на клиенте, а всё остальное — на сервере.»
А вот я бы не прочь, чтобы было все, что есть и даже больше, но люди понимали, что нужно «use right tool for the right job». И само собой — то, что можно сделать на HTML5, CSS, JavaScript — делалось бы только и только с HTML5, CSS и JavaScript. Но вот то, для чего хорошо бы Flash или Silverlight — чтобы именно их и использовали, а не насиловали «HTML5, CSS и JavaScript».
А вот я бы не прочь, чтобы было все, что есть и даже больше, но люди понимали, что нужно «use right tool for the right job». И само собой — то, что можно сделать на HTML5, CSS, JavaScript — делалось бы только и только с HTML5, CSS и JavaScript. Но вот то, для чего хорошо бы Flash или Silverlight — чтобы именно их и использовали, а не насиловали «HTML5, CSS и JavaScript».
Для запуска приложений в окне браузера есть:
— ClickOnce — работает только в IE+.net (ещё выдаёт тупое сообщение с подтверждением запуска)
— XBAP — работает только в IE+.net прямо в окне браузера (правда есть плагин для FF)
По этим двум технологиям в любом случае необходимо, чтобы у вас была цифровая подпись (её можно получить за 100 баксов). Поэтому это секурно, т.к. если начнём распространять вирусы, то подпись отзовут, а на нас могут подать в суд (в теории).
У гугла есть более крутая технология. Называется OneClick. О ней он к сожалению ничего не рассказывает, но использует для установки Google Chrome: www.google.com/chrome/eula.html?hl=ru
После нажатия "Принять условия и установить" сразу же запускается exe-доунлоудер! Покопавшись в коде я понял, что установка проходит через уже установленный на многих компьютерах Google Update.
Если бы Google дал возможность другим разработчикам так же запускать свои приложения, то можно будет делать полноценный Web-приложения!!!
А секурность добиваться опять таки за счёт цифровых подписей и необходимости регистрироваться в каком-нибудь каталоге Google, через который уже и будет вестись установка по OneClick. Но скорей всего этого никогда не будет…
— ClickOnce — работает только в IE+.net (ещё выдаёт тупое сообщение с подтверждением запуска)
— XBAP — работает только в IE+.net прямо в окне браузера (правда есть плагин для FF)
По этим двум технологиям в любом случае необходимо, чтобы у вас была цифровая подпись (её можно получить за 100 баксов). Поэтому это секурно, т.к. если начнём распространять вирусы, то подпись отзовут, а на нас могут подать в суд (в теории).
У гугла есть более крутая технология. Называется OneClick. О ней он к сожалению ничего не рассказывает, но использует для установки Google Chrome: www.google.com/chrome/eula.html?hl=ru
После нажатия "Принять условия и установить" сразу же запускается exe-доунлоудер! Покопавшись в коде я понял, что установка проходит через уже установленный на многих компьютерах Google Update.
Если бы Google дал возможность другим разработчикам так же запускать свои приложения, то можно будет делать полноценный Web-приложения!!!
А секурность добиваться опять таки за счёт цифровых подписей и необходимости регистрироваться в каком-нибудь каталоге Google, через который уже и будет вестись установка по OneClick. Но скорей всего этого никогда не будет…
>>>Если бы Google дал возможность другим разработчикам так же запускать свои приложения, то можно будет делать полноценный Web-приложения!!!
А почему сейчас то нельзя?
google-chrome --app=«your-web-app.com/»
А почему сейчас то нельзя?
google-chrome --app=«your-web-app.com/»
Посмотрите как начинается установка Google Chrome. Она начинается без всяких вопросов.
Так любой exe-шник не запустишь в любом браузере. А Google может.
Так любой exe-шник не запустишь в любом браузере. А Google может.
Это другое. У Google через Google Update запускается exe-шник, а не веб-приложение.
Лично мне это и нужно. Нужен доступ к WinAPI, а из браузера это не возможно. Поэтому, хоть приложение и имеет цифровую подпись, остаются только советовать пользователя кликать вместо «Сохранить» кнопочку «Запустить».
Но в окне браузера уже ничего не сделаешь… Можно только открыть новое и в нём вывести результат взаимодействия с системой.
Но в окне браузера уже ничего не сделаешь… Можно только открыть новое и в нём вывести результат взаимодействия с системой.
У гугла есть более крутая технология. Называется OneClick
Чем она более крутая?
Тем, что работает из любого браузера и нет ни каких диалогов на подтверждение запуска exe-шника. Повторюсь опять: смотрите как устанавливается Google Chrome!
У меня Google Chrome устанавливается через ClickOnce. А у вас?
Вы уверенны?
Если вы используете IE и увидели вот такое сообщение:
… тогда это был действительно ClickOnce. Если установщик Google Chrome запустился без всяких вопросов и из любого другого браузера, то это OneClick.
Если вы используете IE и увидели вот такое сообщение:
… тогда это был действительно ClickOnce. Если установщик Google Chrome запустился без всяких вопросов и из любого другого браузера, то это OneClick.
У вас всегда есть возможность сненсти Гугль Хром и запустить инсталяцию заново чтобы поглядеть что там юзается. Можете в Гугле поискать. Можете просто поискать clickonce_bootstrap в AppData.
О чём вы????
Я изучил js код и говорю вам, что там используется их собственная технология OneClick. Работает она через Google Update.
Если к вам хоть как-то попал любой из продуктов Google, то Хром сможет устанавливаться без всяких вопросов при помощи OneClick.
Я изучил js код и говорю вам, что там используется их собственная технология OneClick. Работает она через Google Update.
Если к вам хоть как-то попал любой из продуктов Google, то Хром сможет устанавливаться без всяких вопросов при помощи OneClick.
Я про ClickOnce который юзается в инсталяхе Гугл Хрома и который я вижу каждый раз когда инсталю Гугл Хром.
У Хрома ClickOnce идёт на подхвате, если через OneClick установить не получается.
Привожу код со страницы загрузки:
Привожу код со страницы загрузки:
function installApp(opt_navDocument) {
sendDlPagePing("install", getInstallSource());
var method = getInstallSource();
if (method === 'oneclick') {
installViaOneClick(opt_navDocument);
} else if (method === 'clickonce') {
installViaClickOnce(opt_navDocument);
} else {
installViaDownload(opt_navDocument);
}
}
На самом то деле из этого кода никак не следует кто и что у кого на подхвате. Более того, по логике вещей 'oneclick' должен быть вторичен, потому как это ActiveX контрол (или плагин для ФФ) который должен быть уже установлен чтобы работать, а clickonce это та штука что уже может быть установленна.
Не пойму зачем вы спорите? Не проще открыть код и убедиться что я не просто так говорю?
Причина по которой первым идёт OneClick, как я уже говорил, это то, что ни каких диалогов запроса пользователю не идёт! Далее идёт ClickOnce. Он запрашивает разрешение.
OneClick работает когда установлен Google Update
ClickOnce работает когда установлен .net начиная со 2-ой версии
Если на компьютере ничего этого нет, то начинается стандартная загрузка.
Причина по которой первым идёт OneClick, как я уже говорил, это то, что ни каких диалогов запроса пользователю не идёт! Далее идёт ClickOnce. Он запрашивает разрешение.
OneClick работает когда установлен Google Update
ClickOnce работает когда установлен .net начиная со 2-ой версии
Если на компьютере ничего этого нет, то начинается стандартная загрузка.
Простите что так долго не отвечал.
Итак что же такое OneClick.
1. АктивХ или плагин к барузеру (не екстеншен).
2. Инсталится при помощи ClickOnce или msi.
3. Является мостом к Google Update.
4. Вся секурити основывается на том факте что кроме Гугловых продуктов оно больше загрузать ничего не будет. Гугловым продуктам мы доверяем, так что тут проблем как бы и нет.
А теперь расмотрим ClickOnce. Это технология которая которая позволяет делать инсталлеры для всего чего угодно. Естесвенно что отвевенность о том что поставит пользователь, лежит тока на этой технологии.
Вы бы согласились ставить все что угодно без вопросов? Например при помощи OneClick, тока допропорядочность Гугла гарантирует, что вам при каждом заходе на любой сайт Гугла не будет сталится тот или иной продукт Гугла.
Итак что же такое OneClick.
1. АктивХ или плагин к барузеру (не екстеншен).
2. Инсталится при помощи ClickOnce или msi.
3. Является мостом к Google Update.
4. Вся секурити основывается на том факте что кроме Гугловых продуктов оно больше загрузать ничего не будет. Гугловым продуктам мы доверяем, так что тут проблем как бы и нет.
А теперь расмотрим ClickOnce. Это технология которая которая позволяет делать инсталлеры для всего чего угодно. Естесвенно что отвевенность о том что поставит пользователь, лежит тока на этой технологии.
Вы бы согласились ставить все что угодно без вопросов? Например при помощи OneClick, тока допропорядочность Гугла гарантирует, что вам при каждом заходе на любой сайт Гугла не будет сталится тот или иной продукт Гугла.
Теперь всё верно :)
Я был бы готов заплатить компании Google, для того чтобы получить возможность запускать своё приложение через OneClick.
Как осуществить секурность? Очень просто!
1. Приложение должно быть подписано цифровой подписью.
2. Исходный код должен быть проверен компанией Google (или любой другой кто реализует функционал подобный OneClick).
Если обнаружилось, что приложение распространяет вредоносный код, то отзываем его лицензию, направляем антивирусным компаниям отчет.
P.S. Я сомневаюсь что нам дадут такой инструмент, но я считаю, что это было бы очень удобно и разумно!
Я был бы готов заплатить компании Google, для того чтобы получить возможность запускать своё приложение через OneClick.
Как осуществить секурность? Очень просто!
1. Приложение должно быть подписано цифровой подписью.
2. Исходный код должен быть проверен компанией Google (или любой другой кто реализует функционал подобный OneClick).
Если обнаружилось, что приложение распространяет вредоносный код, то отзываем его лицензию, направляем антивирусным компаниям отчет.
P.S. Я сомневаюсь что нам дадут такой инструмент, но я считаю, что это было бы очень удобно и разумно!
>работает только в IE+.net (ещё выдаёт тупое сообщение с подтверждением запуска)
Неправда же. Как минимум, в FF оно тоже работает. А «тупое сообщение» (вместо запуска очередного трояна без всяких вопросов) оно выдаёт только если приложение не подписано или требует слишком много прав.
P.S. Если вы знаете как в Chrome/Firefox запустить неподписаный exe'шник без всяких «тупых вопросов», то поделитесь способом.
Неправда же. Как минимум, в FF оно тоже работает. А «тупое сообщение» (вместо запуска очередного трояна без всяких вопросов) оно выдаёт только если приложение не подписано или требует слишком много прав.
P.S. Если вы знаете как в Chrome/Firefox запустить неподписаный exe'шник без всяких «тупых вопросов», то поделитесь способом.
thumbs up to google! это будущее интернета — приложения ничем не устапающие нативным в браузере, имхо
по поводу страхов что десктоп умрет — дудки, тут все что будет — все в исходниках по нормальному стандарту, т.е. все написанное под накл на веб щелчком пальцев от веба легко отделяется. дырки опять-же найдутся и позакрываются быстрее чем с ActiveXами
т.е. выигрывают все
по поводу страхов что десктоп умрет — дудки, тут все что будет — все в исходниках по нормальному стандарту, т.е. все написанное под накл на веб щелчком пальцев от веба легко отделяется. дырки опять-же найдутся и позакрываются быстрее чем с ActiveXами
т.е. выигрывают все
Ух, я уже предвкушаю новую эпоху вирусов, которые будут работать в разных браузерах и под разными ОСями благодаря Native Client. Кому плюнуть в лицо пожать руку за такое достижение?
Native Client пытается разрушить устоявшийся каноны веба:
1) Переносимость (или NativeClient стоит ожидать на ARM и прочих платформах?)
2) Клиент остается тонким (Java и Flash не в счет — они очень сильно ограничены на машине клиента), или проще-говоря браузер выполняет роль интерпретатора представления (MVC).
3) Малый порог вхождения и простота разработки
Native Client пытается разрушить устоявшийся каноны веба:
1) Переносимость (или NativeClient стоит ожидать на ARM и прочих платформах?)
2) Клиент остается тонким (Java и Flash не в счет — они очень сильно ограничены на машине клиента), или проще-говоря браузер выполняет роль интерпретатора представления (MVC).
3) Малый порог вхождения и простота разработки
Фишка Native Client как раз в том, чтобы засунуть приложение в песочницу, у которой нет выхода во внешний мир. Эту защиту достаточно сложно пробить, потому что NaCl просто не выполняет код, в котором есть обращения к базовой OS.
Порог вхождения не факт, что и большой. Hello World остаётся таким же простым кодом в три строчки.
Порог вхождения не факт, что и большой. Hello World остаётся таким же простым кодом в три строчки.
1) Песочницы бывают разные. Полную изоляцию способна дать только виртуальная машина. Но и тут Native Client заранее проигрывает, поскольку есть уже отлаженные и популярные технологии вроде Java и Flash которые уже обкатаны и работают почти везде.
А без виртуальной машины — либо код будет сильно обрезан, а не полный набор x86 со всеми рюшечками и расширениями (а это падение производительности. Тогда нафиг такое надо?) либо зияющая бесконечная дыра в безопасности;)
2) Порог вхождения в классических технологиях (HTML+CSS+JS) гораздо ниже чем в С\С++. JS разрабу минимизировали головную боль с утечкой памяти, нету возни с указателями и хэндлами и т.д.
А без виртуальной машины — либо код будет сильно обрезан, а не полный набор x86 со всеми рюшечками и расширениями (а это падение производительности. Тогда нафиг такое надо?) либо зияющая бесконечная дыра в безопасности;)
2) Порог вхождения в классических технологиях (HTML+CSS+JS) гораздо ниже чем в С\С++. JS разрабу минимизировали головную боль с утечкой памяти, нету возни с указателями и хэндлами и т.д.
По первому: у NC своя изолированная libc, плюс хардварная изоляция кода и доступности памяти для запущенного приложения.
>> Но и тут Native Client заранее проигрывает, поскольку есть уже отлаженные и популярные технологии вроде Java и Flash
Так что нет. Изучите сабж сначала.
>> Но и тут Native Client заранее проигрывает, поскольку есть уже отлаженные и популярные технологии вроде Java и Flash
Так что нет. Изучите сабж сначала.
Достаточно выполнить четыре простых действия чтобы вся изолированная библиотека слетела на нет — выделить память, записать туда нужный машинный код, поменять флаги защиты страницы, совершить jmp в этот блок кода.
Как сделать чтобы это не тормознула защита? Всего два слова: обфускация кода.
Подобное отлично работало, работает и будет работать с антивирами и песочницами. И тут без полной виртуализации или защиты уровня ядра нечего не сможете сделать.
Аппаратная виртуализация — штука хитрая.
Во-первых, она есть далеко не везде.
Во-вторых, изолированные код и память — это более чем достаточно для злоумышленника. Вредитель без напрягов сможет слушать входящие пакеты, докапыватся к ОС-хосту через сетевые интерфейсы и блочные устройства и т.д.
Как сделать чтобы это не тормознула защита? Всего два слова: обфускация кода.
Подобное отлично работало, работает и будет работать с антивирами и песочницами. И тут без полной виртуализации или защиты уровня ядра нечего не сможете сделать.
Аппаратная виртуализация — штука хитрая.
Во-первых, она есть далеко не везде.
Во-вторых, изолированные код и память — это более чем достаточно для злоумышленника. Вредитель без напрягов сможет слушать входящие пакеты, докапыватся к ОС-хосту через сетевые интерфейсы и блочные устройства и т.д.
Почитайте, пожалуйста, как устроен в Native Client. А то в настоящий момент вы говорите ерунду.
А как поменять флаги защиты страницы?
1. Ни Java, ни Flash не дадут такой производительности, как откомпилированный код. Из x86 NaCl вырезает только syscall'ы, так что полная производительность сохраняется. Дыры в безопасности же никакой нет, потому что во внешний мир код может смотреть только через подсистемы браузера. Ну и всё делается именно ради производительности.
2. Закон сохранения возни во Вселенной работает. В JS не надо возиться с указателями, зато надо воевать с прототипами.
2. Закон сохранения возни во Вселенной работает. В JS не надо возиться с указателями, зато надо воевать с прототипами.
Во-первых,
— en.wikipedia.org/wiki/Google_Native_Client «An ARM implementation is now also available,[4] and x86-64 is also supported. Note, however, that currently all three implementations can only use code compiled to the host's native instruction set. PNaCl (pronounced: pinnacle, Portable Native Client) is being developed to address this issue. To run an application portably under PNaCl, it needs to be compiled to LLVM intermediate language (bitcode).»
— www.llvm.org/devmtg/2010-11/ «Portable Native Client» (тех. детали)
Во-вторых, вот хочу я создать систему грид вычислений и попытаться привлечь туда побольше народу через NC, вообще не для неспециалистов: клик, запустился мой рантайм, загрузил данные которые надо просчитать. Никаких оверхедов по производительности, в сравнении с каким-нибудь флешем; ничего не надо инсталлировать. Но запускать такое на мобильнике я совершенно точно не буду. По крайней мере не в ближайшие 5 лет.
Т.е. не на то расчёт.
В-третьих, это не замена чего-либо. Порог вхождения никак не повышается, а вот выбор возможностей и технологий — наоборот. Питон/руби вместо яваскрипта? Пожалуйста. Но что называется, если не нужно, то не используй.
***
Мне самому не нравится тенденция прогиба под приложения в браузере. Браузер как центр всего. ОС в ОС. Что-то в этой концепции криво (или реализациях. концепция-то очень крутая).
Но в NC всё правильно делают. Чёрт с ним с браузером, центром всего. Они делают портабельный и лёгкий сандбокс/jail — это очень круто и нужно.
— en.wikipedia.org/wiki/Google_Native_Client «An ARM implementation is now also available,[4] and x86-64 is also supported. Note, however, that currently all three implementations can only use code compiled to the host's native instruction set. PNaCl (pronounced: pinnacle, Portable Native Client) is being developed to address this issue. To run an application portably under PNaCl, it needs to be compiled to LLVM intermediate language (bitcode).»
— www.llvm.org/devmtg/2010-11/ «Portable Native Client» (тех. детали)
Во-вторых, вот хочу я создать систему грид вычислений и попытаться привлечь туда побольше народу через NC, вообще не для неспециалистов: клик, запустился мой рантайм, загрузил данные которые надо просчитать. Никаких оверхедов по производительности, в сравнении с каким-нибудь флешем; ничего не надо инсталлировать. Но запускать такое на мобильнике я совершенно точно не буду. По крайней мере не в ближайшие 5 лет.
Т.е. не на то расчёт.
В-третьих, это не замена чего-либо. Порог вхождения никак не повышается, а вот выбор возможностей и технологий — наоборот. Питон/руби вместо яваскрипта? Пожалуйста. Но что называется, если не нужно, то не используй.
***
Мне самому не нравится тенденция прогиба под приложения в браузере. Браузер как центр всего. ОС в ОС. Что-то в этой концепции криво (или реализациях. концепция-то очень крутая).
Но в NC всё правильно делают. Чёрт с ним с браузером, центром всего. Они делают портабельный и лёгкий сандбокс/jail — это очень круто и нужно.
так а при чем тут мобильники — ARM не только мобилки уже.
1) Использование LLVM упустил, конечно это хорошо, но только подтверждает невозможность полной изоляции программы == появлению вредоносного кода(
2) Если пользователь захочет принять участие в грид вычислениях — он согласится скачать и установить нормальную прогу, а не держать открытым браузер. Я уж не говорю о том, что Native Client — сам по себе плагин, что подразумевает что его тоже надо установить. Пропустит ли мозила и MS его в свои браузеры или забанит из-за вопросов безопасности — большой вопрос.
+ А кто мешает таким же образом зомбировать сеть? Native Client приложение в духе «весёлая ферма» будет весело вести DDoS серверов.
***
Песочница хорошо работает, только если её контролирует ядро (как в беркли). Хром не имеет возможности работы в режиме ядра (да и это было-бы идиотизмом).
2) Если пользователь захочет принять участие в грид вычислениях — он согласится скачать и установить нормальную прогу, а не держать открытым браузер. Я уж не говорю о том, что Native Client — сам по себе плагин, что подразумевает что его тоже надо установить. Пропустит ли мозила и MS его в свои браузеры или забанит из-за вопросов безопасности — большой вопрос.
+ А кто мешает таким же образом зомбировать сеть? Native Client приложение в духе «весёлая ферма» будет весело вести DDoS серверов.
***
Песочница хорошо работает, только если её контролирует ядро (как в беркли). Хром не имеет возможности работы в режиме ядра (да и это было-бы идиотизмом).
1) habrahabr.ru/blogs/google_chrome/114114/#comment_3677552 LLVM — прежде всего для портабельности, а не для изоляции.
2) Будет например возможность работать как в AIR, не надо держать браузер открытым.
***
Не вижу аргументов для подтверждения. Доказать обратное я тоже не могу.
Но почти наверняка баг/дыра в коде виртуализации, встроенного в ядро, окажется намного критичнее такого же бага в юзерспейс «VM». А у NC ещё и двойная защита: хардварная и софтварная.
2) Будет например возможность работать как в AIR, не надо держать браузер открытым.
***
Не вижу аргументов для подтверждения. Доказать обратное я тоже не могу.
Но почти наверняка баг/дыра в коде виртуализации, встроенного в ядро, окажется намного критичнее такого же бага в юзерспейс «VM». А у NC ещё и двойная защита: хардварная и софтварная.
По второму пункту — и чем же тогда эта технология будет лучше того-же Adobe AIR?
1) Она потребует такой-же установки
2) Ей придется захватывать рынок. Вы хотите писать ПО для пустующего рынка? Или всё же напишите приложение на JS\Java\Flash не ожидая год-два с надеждой появления технологии на нужных Вам платформах? Вспомните, сколько времени ушло хрому для появления версии под линукс;)
3) Java, JavaScript, Flash — сейчас используют полноценную компиляцию, либо JIT (в зависимости от платформы), так что больших отличий в производительности Вы не увидите. Хорошая песочница — вещь весьма прожорливая.
***
Вы не понимаете фундаментальной причины дыры в безопасности. Приложения в песочнице созданной ОС (Jail, OpenVZ и т.д.) попадают в неё в следствии осознанного желания установить пользователем ПО в изолированную среду. Как следствие — в изоляции работает не так много программ. Теперь представьте, что будет, если в изоляцию еще и пихать всю дребедень из браузера — бешенный рост затрачиваемых ресурсов на все-возможные таблицы изолированных дескрипторов, виртуальные стеки и т.д. Аппаратная виртуализация — это не панацея, а узко-специализированное решение для весьма специфичных задач.
П.С. И между прочим, виртуализации\песочницы уровня ядра тоже используют аппаратные возможности по полной.
1) Она потребует такой-же установки
2) Ей придется захватывать рынок. Вы хотите писать ПО для пустующего рынка? Или всё же напишите приложение на JS\Java\Flash не ожидая год-два с надеждой появления технологии на нужных Вам платформах? Вспомните, сколько времени ушло хрому для появления версии под линукс;)
3) Java, JavaScript, Flash — сейчас используют полноценную компиляцию, либо JIT (в зависимости от платформы), так что больших отличий в производительности Вы не увидите. Хорошая песочница — вещь весьма прожорливая.
***
Вы не понимаете фундаментальной причины дыры в безопасности. Приложения в песочнице созданной ОС (Jail, OpenVZ и т.д.) попадают в неё в следствии осознанного желания установить пользователем ПО в изолированную среду. Как следствие — в изоляции работает не так много программ. Теперь представьте, что будет, если в изоляцию еще и пихать всю дребедень из браузера — бешенный рост затрачиваемых ресурсов на все-возможные таблицы изолированных дескрипторов, виртуальные стеки и т.д. Аппаратная виртуализация — это не панацея, а узко-специализированное решение для весьма специфичных задач.
П.С. И между прочим, виртуализации\песочницы уровня ядра тоже используют аппаратные возможности по полной.
1) Браузер уже стоит.
2) Браузер уже стоит.
3) Как говорится, а мужики-то и не знали. Чего с NC вообще мудохаются?
Давно динамические языки по всем пунктам обгоняют статические? Даже в случае каких-нибудь яв/сишарпов, мега-преимущество JIT'а: генерация нативного кода подстроенного под хост платформу — никакого выигрыша не видно. Они нивелируются внутренними процессами VM, как то: GC, тонны эксепшанов, проверки-перепроверки-анбоксинги, секурность. Вот в Си (в данном случае PNaCl, вкупе с LLVM) да, можно ожидать преимущества.
***
ಠ_ಠ
Чем будет отличаться один дескриптор чего-нибудь, предоставленный ОС, от обёрнутого мной в пару десятков доп. строк кода? Это и так все давно делают в своих фреймворках.
Какие виртуальные стеки? "nativeclient myapp.bc" и всё. Считайте что это такой же JIT, без хуков: один раз настраивается среда для приложения и дальше оно творит что там ему надо. Если таки хочется managed ресурсов, запускайте в NC любимые интерпретаторы чего угодно.
И вообще, мне непонятны эти сравнения и утверждения что хардвар вдруг начнёт тормозить и жрать кучу ресурсов. А софтварные VM значит не тормозят и не жрут кучу ресурсов?
П.С. Н-ну да. И как я писал выше, круто когда баг на таком лоу левеле обвалит всю систему/откроется дыра для выполнения любого кода под рутом.
2) Браузер уже стоит.
3) Как говорится, а мужики-то и не знали. Чего с NC вообще мудохаются?
Давно динамические языки по всем пунктам обгоняют статические? Даже в случае каких-нибудь яв/сишарпов, мега-преимущество JIT'а: генерация нативного кода подстроенного под хост платформу — никакого выигрыша не видно. Они нивелируются внутренними процессами VM, как то: GC, тонны эксепшанов, проверки-перепроверки-анбоксинги, секурность. Вот в Си (в данном случае PNaCl, вкупе с LLVM) да, можно ожидать преимущества.
***
ಠ_ಠ
Чем будет отличаться один дескриптор чего-нибудь, предоставленный ОС, от обёрнутого мной в пару десятков доп. строк кода? Это и так все давно делают в своих фреймворках.
Какие виртуальные стеки? "nativeclient myapp.bc" и всё. Считайте что это такой же JIT, без хуков: один раз настраивается среда для приложения и дальше оно творит что там ему надо. Если таки хочется managed ресурсов, запускайте в NC любимые интерпретаторы чего угодно.
И вообще, мне непонятны эти сравнения и утверждения что хардвар вдруг начнёт тормозить и жрать кучу ресурсов. А софтварные VM значит не тормозят и не жрут кучу ресурсов?
П.С. Н-ну да. И как я писал выше, круто когда баг на таком лоу левеле обвалит всю систему/откроется дыра для выполнения любого кода под рутом.
1. Опять же, вы просто не понимаете, как устроена песочница NaCl. Там статическая верификация кода, а не динамическая. Это потребляет относительно немного ресурсов. Основной механизм изоляции в песочнице: не допускать программу к системным вызовам. Что сможет сделать код, у которого нет доступа к системным вызовам? О каком доступе к сетевым картам и DDoS вы говорите? Я вот совершенно не понимаю, как без обращения к ядру можно получить доступ непонять куда, чтобы DDoS организовать.
2. Гарантировать отсутствие системных вызовов достаточно просто: 2.1 статически проверяем код на то, что там нет таких вызовов; 2.2 гарантируем, что программа не сможет самостоятельно генерировать новый исполняемый native-код — это делается очень простой манипуляцией флагами при выделении памяти.
Всё. Участие песочницы в cpu-time жизни приложения этим и ограничивается, тут нет никаких особых накладных расходов. Native Quake выдаёт 200 fps, все довольны.
3. Java и прочие такой производительности не дадут. JIT — это, конечно, круто, но не достаточно круто из-за сборки мусора и динамической типизации, которые означают, в принципе, что вы должны быть в коде готовы к тому, что выполнение пойдёт не по откомпилированной цепочке, а в другую сторону — на обслуживание runtime. Да, JIT вам даст 10x кратное преимущество перед интерпретацией, но у классического, статически типизированного языка с оптимизирующим копмилятором, вы не победите при помощи языка, обвешанного сложными ООП-наворотами, сборщиками мусора и (Flash, JS) динамическими типами. Просто по определению такого языка, by design, на единицу вычислений нужно делать больше работы. Можно круто оптимизировать, но победить Си таким способом не выйдет. Что уже долго и упорно показывает shootout.alioth.debian.org
4. А теперь примите во внимание всяческие LLVM, которые являются в том числе и JIT-ами для Си-подобных языков, и которые способны осуществлять их runtime-специализацию, которая только добавит производительности всяким С/С++, FORTRAN'ам да Pascal'ам. В итоге… Ну и как с этим будет соревноваться JavaScript, если у него один цикл сборки мусора будет занимать в сложном приложении больше времени, чем одна полезная итерация алгоритма?
2. Гарантировать отсутствие системных вызовов достаточно просто: 2.1 статически проверяем код на то, что там нет таких вызовов; 2.2 гарантируем, что программа не сможет самостоятельно генерировать новый исполняемый native-код — это делается очень простой манипуляцией флагами при выделении памяти.
Всё. Участие песочницы в cpu-time жизни приложения этим и ограничивается, тут нет никаких особых накладных расходов. Native Quake выдаёт 200 fps, все довольны.
3. Java и прочие такой производительности не дадут. JIT — это, конечно, круто, но не достаточно круто из-за сборки мусора и динамической типизации, которые означают, в принципе, что вы должны быть в коде готовы к тому, что выполнение пойдёт не по откомпилированной цепочке, а в другую сторону — на обслуживание runtime. Да, JIT вам даст 10x кратное преимущество перед интерпретацией, но у классического, статически типизированного языка с оптимизирующим копмилятором, вы не победите при помощи языка, обвешанного сложными ООП-наворотами, сборщиками мусора и (Flash, JS) динамическими типами. Просто по определению такого языка, by design, на единицу вычислений нужно делать больше работы. Можно круто оптимизировать, но победить Си таким способом не выйдет. Что уже долго и упорно показывает shootout.alioth.debian.org
4. А теперь примите во внимание всяческие LLVM, которые являются в том числе и JIT-ами для Си-подобных языков, и которые способны осуществлять их runtime-специализацию, которая только добавит производительности всяким С/С++, FORTRAN'ам да Pascal'ам. В итоге… Ну и как с этим будет соревноваться JavaScript, если у него один цикл сборки мусора будет занимать в сложном приложении больше времени, чем одна полезная итерация алгоритма?
>> 3) Малый порог вхождения и простота разработки
Для Native Client можно будет писать приложения на Mono, т.е. на C#.
Я считаю это большой плюс, поскольку C#разработчики теперь смогут делать кроссплатформенные RIA приложения (Silverlight не в счет).
Для Native Client можно будет писать приложения на Mono, т.е. на C#.
Я считаю это большой плюс, поскольку C#разработчики теперь смогут делать кроссплатформенные RIA приложения (Silverlight не в счет).
Отлично. Ждем, пока native client победит silverlight. Правда, тут, скорее от программистов зависит, однако, что-то мне подсказывает, что, например, в linux, пока moonlight грузится, NaCl уже нарисует трехмерный интерфейс :)
P.S.
Первый абзац — опечатка: «непосредственно в брайзере»
P.S.
Первый абзац — опечатка: «непосредственно в брайзере»
Гугл, вместо того, чтобы выдумывать очередной велосипед, мог бы взять, да Moonlight-у помочь. Тем более, что уже и стандартизовано всё, и под виндой работает, и под макой, и тулзов понаписано и компонентов.
А то вся эта история с HTML5/Flash/Silverlight похода на басню крылова про рака, щуку и лебедя.
А то вся эта история с HTML5/Flash/Silverlight похода на басню крылова про рака, щуку и лебедя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Native Client: К взлету готов!