1957 — Мин. обороны США приняла решение о создании распределёной системы передачи информации
1969 — ARPANET увидела свет
>Пользуясь интернетом уже около 80 лет :)
2011 — 80 = 1931.
У меня возникает только три вопроса:
1) Вы пользовались интернетом за 26 лет до того, как возникла идея и за 38 лет до его рождения?
2) Ребят, а сколько же Вам лет тогда? (Чтобы иметь доступ к военным сетям, Вам должно было быть минимум по 20 лет. 20+80 = 100. Кэп, поделись секретом, как дожить до 100 лет и при этом оставаться способным изучать новые технологии)
3) Ребят, а что Вы курите?
Правильнее заметить, что виртуальный товар\валюта не может стать эквивалентом реального товара\валюты. Это всё лишь спекулятивная ниша, которая способна только поглотить материальные блага взамен на фантик)
По второму пункту — и чем же тогда эта технология будет лучше того-же Adobe AIR?
1) Она потребует такой-же установки
2) Ей придется захватывать рынок. Вы хотите писать ПО для пустующего рынка? Или всё же напишите приложение на JS\Java\Flash не ожидая год-два с надеждой появления технологии на нужных Вам платформах? Вспомните, сколько времени ушло хрому для появления версии под линукс;)
3) Java, JavaScript, Flash — сейчас используют полноценную компиляцию, либо JIT (в зависимости от платформы), так что больших отличий в производительности Вы не увидите. Хорошая песочница — вещь весьма прожорливая.
***
Вы не понимаете фундаментальной причины дыры в безопасности. Приложения в песочнице созданной ОС (Jail, OpenVZ и т.д.) попадают в неё в следствии осознанного желания установить пользователем ПО в изолированную среду. Как следствие — в изоляции работает не так много программ. Теперь представьте, что будет, если в изоляцию еще и пихать всю дребедень из браузера — бешенный рост затрачиваемых ресурсов на все-возможные таблицы изолированных дескрипторов, виртуальные стеки и т.д. Аппаратная виртуализация — это не панацея, а узко-специализированное решение для весьма специфичных задач.
П.С. И между прочим, виртуализации\песочницы уровня ядра тоже используют аппаратные возможности по полной.
Достаточно выполнить четыре простых действия чтобы вся изолированная библиотека слетела на нет — выделить память, записать туда нужный машинный код, поменять флаги защиты страницы, совершить jmp в этот блок кода.
Как сделать чтобы это не тормознула защита? Всего два слова: обфускация кода.
Подобное отлично работало, работает и будет работать с антивирами и песочницами. И тут без полной виртуализации или защиты уровня ядра нечего не сможете сделать.
Аппаратная виртуализация — штука хитрая.
Во-первых, она есть далеко не везде.
Во-вторых, изолированные код и память — это более чем достаточно для злоумышленника. Вредитель без напрягов сможет слушать входящие пакеты, докапыватся к ОС-хосту через сетевые интерфейсы и блочные устройства и т.д.
1) Использование LLVM упустил, конечно это хорошо, но только подтверждает невозможность полной изоляции программы == появлению вредоносного кода(
2) Если пользователь захочет принять участие в грид вычислениях — он согласится скачать и установить нормальную прогу, а не держать открытым браузер. Я уж не говорю о том, что Native Client — сам по себе плагин, что подразумевает что его тоже надо установить. Пропустит ли мозила и MS его в свои браузеры или забанит из-за вопросов безопасности — большой вопрос.
+ А кто мешает таким же образом зомбировать сеть? Native Client приложение в духе «весёлая ферма» будет весело вести DDoS серверов.
***
Песочница хорошо работает, только если её контролирует ядро (как в беркли). Хром не имеет возможности работы в режиме ядра (да и это было-бы идиотизмом).
1) Песочницы бывают разные. Полную изоляцию способна дать только виртуальная машина. Но и тут Native Client заранее проигрывает, поскольку есть уже отлаженные и популярные технологии вроде Java и Flash которые уже обкатаны и работают почти везде.
А без виртуальной машины — либо код будет сильно обрезан, а не полный набор x86 со всеми рюшечками и расширениями (а это падение производительности. Тогда нафиг такое надо?) либо зияющая бесконечная дыра в безопасности;)
2) Порог вхождения в классических технологиях (HTML+CSS+JS) гораздо ниже чем в С\С++. JS разрабу минимизировали головную боль с утечкой памяти, нету возни с указателями и хэндлами и т.д.
Ух, я уже предвкушаю новую эпоху вирусов, которые будут работать в разных браузерах и под разными ОСями благодаря Native Client. Кому плюнуть в лицо пожать руку за такое достижение?
Native Client пытается разрушить устоявшийся каноны веба:
1) Переносимость (или NativeClient стоит ожидать на ARM и прочих платформах?)
2) Клиент остается тонким (Java и Flash не в счет — они очень сильно ограничены на машине клиента), или проще-говоря браузер выполняет роль интерпретатора представления (MVC).
3) Малый порог вхождения и простота разработки
Гель для бритья — жижа предназначенная для нанесения на морду людских особей с целью поддержания стадно-эстетических взглядов общества. Подавляет девиантные взгляды и развивает стремление к строгому дрескоду у субъекта опытов. Побочный результат — раздраженность из-за зуда кожи и лени.
Логика, ёпта!
Аналогично. Появляется мерзкий голосок в глубине души и начинает ворчать:
А нафига мне это надо? Смотри, корова летит! Пошли пивка в пабе попьём, пятница же! Ух, какая краля, сдался тебе этот квазинейронный генетический поисковик букавок?
Когда HTML5 получит повсеместное использование, можно будет делать еще проще — брать DIV`ы нужного размера с CSS закруглением. CSS-кой поворачивать их на нужный угл и устанавливать прозрачность.
Пока-что такой вариант не очень резонный из-за достаточно большой аудитории пользователей IE старых браузеров, а прикручивание костылей для совместимости с HTML5 добавит дополнительный трафик(
У данной проблемы с ходу могу предложить два универсальных решения:
1) Рисуем в виде с прозрачным фоном PNG ленту кадров. Дальше юзаем CSS sprite для смены кадра.
2) Рисуем только один кадр, который также сохраняем в PNG с прозрачным фоном и юзаем JS для поворота рисунка на угол.
Мозилла черезчур увлеклась игрой в Дон Кихота. Вечно ищет себе мельниц с которыми подраться, а что ездит на старой кляче (gecko) даже не замечает. Я конечно за функциональность и всё такое, но как говорится: «лучше меньше, но лучше!». Вместо производительности, которой мозиловцы тычат майкрософту мы имеем тормознутость (и упоси боже залить еще и кучу плагинов) и кучу ненужного функционала (который тоже кушает ресурсы).
Первой мельницей стала мозайка… (mozilla = mosaic killer)
Теперь ослик.
Что дальше?
Хочешь красивый рендеринг страничек — бери сафари. Хочешь скорости — бери хром. Хочешь плюшечек — бери лисичку. Хочешь головной боли — бери ослика)
1969 — ARPANET увидела свет
>Пользуясь интернетом уже около 80 лет :)
2011 — 80 = 1931.
У меня возникает только три вопроса:
1) Вы пользовались интернетом за 26 лет до того, как возникла идея и за 38 лет до его рождения?
2) Ребят, а сколько же Вам лет тогда? (Чтобы иметь доступ к военным сетям, Вам должно было быть минимум по 20 лет. 20+80 = 100. Кэп, поделись секретом, как дожить до 100 лет и при этом оставаться способным изучать новые технологии)
3) Ребят, а что Вы курите?
1) Она потребует такой-же установки
2) Ей придется захватывать рынок. Вы хотите писать ПО для пустующего рынка? Или всё же напишите приложение на JS\Java\Flash не ожидая год-два с надеждой появления технологии на нужных Вам платформах? Вспомните, сколько времени ушло хрому для появления версии под линукс;)
3) Java, JavaScript, Flash — сейчас используют полноценную компиляцию, либо JIT (в зависимости от платформы), так что больших отличий в производительности Вы не увидите. Хорошая песочница — вещь весьма прожорливая.
***
Вы не понимаете фундаментальной причины дыры в безопасности. Приложения в песочнице созданной ОС (Jail, OpenVZ и т.д.) попадают в неё в следствии осознанного желания установить пользователем ПО в изолированную среду. Как следствие — в изоляции работает не так много программ. Теперь представьте, что будет, если в изоляцию еще и пихать всю дребедень из браузера — бешенный рост затрачиваемых ресурсов на все-возможные таблицы изолированных дескрипторов, виртуальные стеки и т.д. Аппаратная виртуализация — это не панацея, а узко-специализированное решение для весьма специфичных задач.
П.С. И между прочим, виртуализации\песочницы уровня ядра тоже используют аппаратные возможности по полной.
Как сделать чтобы это не тормознула защита? Всего два слова: обфускация кода.
Подобное отлично работало, работает и будет работать с антивирами и песочницами. И тут без полной виртуализации или защиты уровня ядра нечего не сможете сделать.
Аппаратная виртуализация — штука хитрая.
Во-первых, она есть далеко не везде.
Во-вторых, изолированные код и память — это более чем достаточно для злоумышленника. Вредитель без напрягов сможет слушать входящие пакеты, докапыватся к ОС-хосту через сетевые интерфейсы и блочные устройства и т.д.
2) Если пользователь захочет принять участие в грид вычислениях — он согласится скачать и установить нормальную прогу, а не держать открытым браузер. Я уж не говорю о том, что Native Client — сам по себе плагин, что подразумевает что его тоже надо установить. Пропустит ли мозила и MS его в свои браузеры или забанит из-за вопросов безопасности — большой вопрос.
+ А кто мешает таким же образом зомбировать сеть? Native Client приложение в духе «весёлая ферма» будет весело вести DDoS серверов.
***
Песочница хорошо работает, только если её контролирует ядро (как в беркли). Хром не имеет возможности работы в режиме ядра (да и это было-бы идиотизмом).
А без виртуальной машины — либо код будет сильно обрезан, а не полный набор x86 со всеми рюшечками и расширениями (а это падение производительности. Тогда нафиг такое надо?) либо зияющая бесконечная дыра в безопасности;)
2) Порог вхождения в классических технологиях (HTML+CSS+JS) гораздо ниже чем в С\С++. JS разрабу минимизировали головную боль с утечкой памяти, нету возни с указателями и хэндлами и т.д.
плюнуть в лицопожать руку за такое достижение?Native Client пытается разрушить устоявшийся каноны веба:
1) Переносимость (или NativeClient стоит ожидать на ARM и прочих платформах?)
2) Клиент остается тонким (Java и Flash не в счет — они очень сильно ограничены на машине клиента), или проще-говоря браузер выполняет роль интерпретатора представления (MVC).
3) Малый порог вхождения и простота разработки
Логика, ёпта!
А нафига мне это надо? Смотри, корова летит! Пошли пивка в пабе попьём, пятница же! Ух, какая краля, сдался тебе этот квазинейронный генетический поисковик букавок?
Пока-что такой вариант не очень резонный из-за достаточно большой аудитории пользователей
IEстарых браузеров, а прикручивание костылей для совместимости с HTML5 добавит дополнительный трафик(1) Рисуем в виде с прозрачным фоном PNG ленту кадров. Дальше юзаем CSS sprite для смены кадра.
2) Рисуем только один кадр, который также сохраняем в PNG с прозрачным фоном и юзаем JS для поворота рисунка на угол.
Первой мельницей стала мозайка… (mozilla = mosaic killer)
Теперь ослик.
Что дальше?
Хочешь красивый рендеринг страничек — бери сафари. Хочешь скорости — бери хром. Хочешь плюшечек — бери лисичку. Хочешь головной боли — бери ослика)
П.С. Хабр торт!