Комментарии 36
Долго думал о том, как можно использовать виртуализацию на ультра мобильных устройствах — так и не придумал. Вот может через n лет, когда мой сервер всегда будет со мной, у меня в кармане…
Иногда на одну ОСь мощностей не хватает, а тут еще несколько. Через пару лет, пожалуй )
Даже страшно представить как это всё будет тормозить.
супер новость.
проблема с hypervisor'ами под мобильные устройства, вопреки устоявшемуся мнению, заключается не столько в вычислительных мощностях (а при нынешних тенденциях через год-два в карманах пользователя будет аналог макбук про лежать), а скорее в ограниченной (и совершенно непоспевающей за мощностью) батарейки мобильных устройств.
виртуализация в мобильных устройствах (необязательно мобильных телефонах) — это возможность изоляции приложений в целях безопасности личных данных и настроек (например, для скаченного приложения запустить отдельную виртуальную машину — пусть там работает), довольно точного распределения ресурсов (выделить 30% CPU), возможность иметь сконфигурированную виртуальную машину со всеми необходимыми настройками и программами для конкретного места или времени (на работе — принимать звонки от коллег, перенаправлять звонки от друзей на автоответчик и т.д., после работы — звонок от шефа не принимать, от друзей — ставить конкретную мелодию :-)), причем все это делается автоматически с учетом времени, GPS координат и прочего. Кроме того, можно давать в аренду свои вычислительные мощности (за деньги, за услуги, льготы oт тех же ОпСоСов) не боясь за личные данные. (вроде SETI@home). Такие проекты уже есть и ждут своего часа выйти в массы. Ограничений несколько — нет полноценного hypervisor'а (уже есть) и батарейка (ждем прорыва в этой области)
Группа в нашем универе, в которой я работаю, уже больше года портирует Xen на ARM. В этом нас очень поддерживают (морально в основном и материально иногда) Нокиа и Samsung. Последний, кстати, уже портировал Хen на какой-то из своих ARM-ов, но уже полгода кормит нас обещаниями полностью открыть измененное ядро. Надеюсь, к НГ выполнят свое обещание. =)
Кстати, разговаривал месяц назад с ребятами с Google- они тоже не прочь заиметь виртуализацию в Android.
проблема с hypervisor'ами под мобильные устройства, вопреки устоявшемуся мнению, заключается не столько в вычислительных мощностях (а при нынешних тенденциях через год-два в карманах пользователя будет аналог макбук про лежать), а скорее в ограниченной (и совершенно непоспевающей за мощностью) батарейки мобильных устройств.
виртуализация в мобильных устройствах (необязательно мобильных телефонах) — это возможность изоляции приложений в целях безопасности личных данных и настроек (например, для скаченного приложения запустить отдельную виртуальную машину — пусть там работает), довольно точного распределения ресурсов (выделить 30% CPU), возможность иметь сконфигурированную виртуальную машину со всеми необходимыми настройками и программами для конкретного места или времени (на работе — принимать звонки от коллег, перенаправлять звонки от друзей на автоответчик и т.д., после работы — звонок от шефа не принимать, от друзей — ставить конкретную мелодию :-)), причем все это делается автоматически с учетом времени, GPS координат и прочего. Кроме того, можно давать в аренду свои вычислительные мощности (за деньги, за услуги, льготы oт тех же ОпСоСов) не боясь за личные данные. (вроде SETI@home). Такие проекты уже есть и ждут своего часа выйти в массы. Ограничений несколько — нет полноценного hypervisor'а (уже есть) и батарейка (ждем прорыва в этой области)
Группа в нашем универе, в которой я работаю, уже больше года портирует Xen на ARM. В этом нас очень поддерживают (морально в основном и материально иногда) Нокиа и Samsung. Последний, кстати, уже портировал Хen на какой-то из своих ARM-ов, но уже полгода кормит нас обещаниями полностью открыть измененное ядро. Надеюсь, к НГ выполнят свое обещание. =)
Кстати, разговаривал месяц назад с ребятами с Google- они тоже не прочь заиметь виртуализацию в Android.
Пролетала как-то новость, что Google занята финансированием и поиском решений, переноса нынешних серверных архитектур на ультра-мобильные платформы, т.к. их дата-центры занимают уже очень много места и потребляют много электроэнергии.
В чём смысл существования ОС?
Может сделать JVM под гипервизор и запускать Java-приложения? Они переносимы по определению. JVM с библиотеками имеет стандартный API. Операционная система превращается в уровень программной абстракции над железом, не более.
Может сделать JVM под гипервизор и запускать Java-приложения? Они переносимы по определению. JVM с библиотеками имеет стандартный API. Операционная система превращается в уровень программной абстракции над железом, не более.
согласен, и это один из ключевых доводов в пользу создания j2me.
но JVM:
— ограничивает средства и решения разработки;
— требует отказа от существующего стека програм.
в то время как полноценный гипервайзор вбирает в себя Java в том числе.
но JVM:
— ограничивает средства и решения разработки;
— требует отказа от существующего стека програм.
в то время как полноценный гипервайзор вбирает в себя Java в том числе.
>но JVM:
>— ограничивает средства и решения разработки;
Мобильные приложения настолько малы в сравнении с настольными, что легче заново написать такое же под определённую операционку/JVM, чем портировать старое вместе с его индивидуальным операционным окружением. Да, да, про версию ОС помним.
>— требует отказа от существующего стека програм.
Не только — также потребуется отказ и от вирусов и от антивирусов, которые не прибавляют быстродействия любой операционке, не говоря уж о мобильных. :)
С Mobile Virtualization Platform буквально всё придётся носить с собой, в том числе привинтивную антивирусную защиту, иначе опасность не заставит себя долго ждать и проявится в регулярном падении гостевых ОС с находящимися в них инфицированными приложениями.
Так называемые вирусы на Java представляют собой «албанские вирусы», просящие разрешения у неискушённого пользователя«что-то сделать ради какого-то вау-эффекта. К размножению эти художества не способны. Это в плюс к тому, что антивирус не нужен, не будет отжираться энергия аккумулятора на сканирование памяти и ФС.
Что касается стандартного JVM API для мобильных платформ
Пока что всё предствляет не целостную платформу и рантайм, а „кусочную“ — поддержка отдельных JSR'ов на совести производителя и зависит от аппаратной обеспеченности конкретной железки: частота процессора, размер экрана, наличие звукового синтезатора и воспроизводящего тракта, наличие/отсутсвие видеокамеры, наличие/отсутствие графического ускорителя и т.д…
На Google Android (JVM Dalvik) уже можно запускать J2ME приложения в режиме эмуляции: код запущенного в нём J2ME-приложения так же проходит JIT-компиляцию, как и библиотечный код самой JVM Dalvik (рантайм), так что разница в быстродействии между нативным приложением (они сами пишутся на Java) и мидлетом должна быть по идее ничтожна. Конечно, MicroEmulator всё же неполноценная замена ральных связей мидлета и J2ME-платформы, но это хотя бы „что-то“, шаг в режим эмуляции по типу WINE.
Ну ладно, отвлёкся немного. Основная мысль моя в том, что необходимые мобильные приложения легче переписать и оптимизировать, чем тащить (не сопровождать!) их с устаревшими ОС. Это лучше всего отразиться на потреблении памяти, ресурсов процессора и на времени автономной работы.
>— ограничивает средства и решения разработки;
Мобильные приложения настолько малы в сравнении с настольными, что легче заново написать такое же под определённую операционку/JVM, чем портировать старое вместе с его индивидуальным операционным окружением. Да, да, про версию ОС помним.
>— требует отказа от существующего стека програм.
Не только — также потребуется отказ и от вирусов и от антивирусов, которые не прибавляют быстродействия любой операционке, не говоря уж о мобильных. :)
С Mobile Virtualization Platform буквально всё придётся носить с собой, в том числе привинтивную антивирусную защиту, иначе опасность не заставит себя долго ждать и проявится в регулярном падении гостевых ОС с находящимися в них инфицированными приложениями.
Так называемые вирусы на Java представляют собой «албанские вирусы», просящие разрешения у неискушённого пользователя«что-то сделать ради какого-то вау-эффекта. К размножению эти художества не способны. Это в плюс к тому, что антивирус не нужен, не будет отжираться энергия аккумулятора на сканирование памяти и ФС.
Что касается стандартного JVM API для мобильных платформ
Пока что всё предствляет не целостную платформу и рантайм, а „кусочную“ — поддержка отдельных JSR'ов на совести производителя и зависит от аппаратной обеспеченности конкретной железки: частота процессора, размер экрана, наличие звукового синтезатора и воспроизводящего тракта, наличие/отсутсвие видеокамеры, наличие/отсутствие графического ускорителя и т.д…
На Google Android (JVM Dalvik) уже можно запускать J2ME приложения в режиме эмуляции: код запущенного в нём J2ME-приложения так же проходит JIT-компиляцию, как и библиотечный код самой JVM Dalvik (рантайм), так что разница в быстродействии между нативным приложением (они сами пишутся на Java) и мидлетом должна быть по идее ничтожна. Конечно, MicroEmulator всё же неполноценная замена ральных связей мидлета и J2ME-платформы, но это хотя бы „что-то“, шаг в режим эмуляции по типу WINE.
Ну ладно, отвлёкся немного. Основная мысль моя в том, что необходимые мобильные приложения легче переписать и оптимизировать, чем тащить (не сопровождать!) их с устаревшими ОС. Это лучше всего отразиться на потреблении памяти, ресурсов процессора и на времени автономной работы.
то что вы написали — это возможность изоляции приложений в целях безопасности личных данных и настроек (например, для скаченного приложения запустить отдельную виртуальную машину — пусть там работает) — было бы неплохо сперва реализовать на уровне десктопных операционных систем, чтобы не приходилось запускать отдельную виртуальную машину с отдельной ОС в ней.
что-нибудь типа клика правой кнопкой мышки по файлу — «запустить в изолированной среде...», выбрать доступные ресурсы (железо, службы, память, максимальная загрузка процессора, досупные папки в файловой системе, сетевые порты и т.п. и т.д.)
что-нибудь типа клика правой кнопкой мышки по файлу — «запустить в изолированной среде...», выбрать доступные ресурсы (железо, службы, память, максимальная загрузка процессора, досупные папки в файловой системе, сетевые порты и т.п. и т.д.)
в идеале каждая прикладная (и не только) программа должна запускаться в такой изолированной среде.
можно, конечно, попытаться реализовать это созданием отдельных пользователей для разных (групп) программ
можно, конечно, попытаться реализовать это созданием отдельных пользователей для разных (групп) программ
думаю, это несложно сделать даже используя нехитрый баш-скрипт (если loop файл в качестве жесткого диска использовать, то вообще околотривиальная задача)
это, простите, как?
судя по всему там архитектура такая же как и у ESX и Xen, т.е. между железом и доменами (в терминах Xen) расположен тоненький слой hypervisor'а.
скорее всего есть привилегированный домен — domain0, который арбитрирует все запросы domainU к железу.
судя по всему там архитектура такая же как и у ESX и Xen, т.е. между железом и доменами (в терминах Xen) расположен тоненький слой hypervisor'а.
скорее всего есть привилегированный домен — domain0, который арбитрирует все запросы domainU к железу.
просто не совсем понятен смысл.
лозунг разработчиков hypervisor'ов «чем меньше, тем лучше», в том смысле, что не «хайпервайзерское» это дело еще у юзера интересоваться, что он желает и запросы обрабатывать.
Hypervisor — это по сути минимальный набор API, который позволяет распределять ресурсы девайса гостевым ОС. В каком-то смысле — это МетаОС.
Вы захотите, чтобы он у вас спрашивал какую ОС грузить, кто-то пожалуется, что шрифт некрасивый и бэкграунда нет, кому-то не понравится, что нельзя одновременно с двумя VM работать и пошло поехало :) придется заново колесо изобретать, в то время как все работает и так неплохо. Грузите domain0 (можно самую минималистичную, если очень хочется) и оттуда рулите своими виртуальными машинами. Каждый на своем месте.
лозунг разработчиков hypervisor'ов «чем меньше, тем лучше», в том смысле, что не «хайпервайзерское» это дело еще у юзера интересоваться, что он желает и запросы обрабатывать.
Hypervisor — это по сути минимальный набор API, который позволяет распределять ресурсы девайса гостевым ОС. В каком-то смысле — это МетаОС.
Вы захотите, чтобы он у вас спрашивал какую ОС грузить, кто-то пожалуется, что шрифт некрасивый и бэкграунда нет, кому-то не понравится, что нельзя одновременно с двумя VM работать и пошло поехало :) придется заново колесо изобретать, в то время как все работает и так неплохо. Грузите domain0 (можно самую минималистичную, если очень хочется) и оттуда рулите своими виртуальными машинами. Каждый на своем месте.
А что это за вмятина на линуксе со стороны гипервизора? Намек на его дырявость? :)
обидно что нельзя скачать, и попробовать потестировать.
Да и вообще — не совсем понятно — под какую программную платформу это написано…
Да и вообще — не совсем понятно — под какую программную платформу это написано…
А я с мобильника тупо звоню.
Прикиньте, все абоненты сотовой сети будут носить сервера в своих мобильных. Не нужно будет держать серверные и т.д.
Думаю, это специальная приманка для гиков — поставь на свой винмобайл Android, не угробив телефон
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А вы уже используете свой мобильный в качестве платформы для нескольких гостевых ОС?