Comments 36
Долго думал о том, как можно использовать виртуализацию на ультра мобильных устройствах — так и не придумал. Вот может через n лет, когда мой сервер всегда будет со мной, у меня в кармане…
+7
Иногда на одну ОСь мощностей не хватает, а тут еще несколько. Через пару лет, пожалуй )
+3
Даже страшно представить как это всё будет тормозить.
+2
супер новость.
проблема с 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.
+13
Пролетала как-то новость, что Google занята финансированием и поиском решений, переноса нынешних серверных архитектур на ультра-мобильные платформы, т.к. их дата-центры занимают уже очень много места и потребляют много электроэнергии.
0
В чём смысл существования ОС?
Может сделать JVM под гипервизор и запускать Java-приложения? Они переносимы по определению. JVM с библиотеками имеет стандартный API. Операционная система превращается в уровень программной абстракции над железом, не более.
Может сделать JVM под гипервизор и запускать Java-приложения? Они переносимы по определению. JVM с библиотеками имеет стандартный API. Операционная система превращается в уровень программной абстракции над железом, не более.
0
согласен, и это один из ключевых доводов в пользу создания j2me.
но JVM:
— ограничивает средства и решения разработки;
— требует отказа от существующего стека програм.
в то время как полноценный гипервайзор вбирает в себя Java в том числе.
но JVM:
— ограничивает средства и решения разработки;
— требует отказа от существующего стека програм.
в то время как полноценный гипервайзор вбирает в себя Java в том числе.
0
>но 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.
Ну ладно, отвлёкся немного. Основная мысль моя в том, что необходимые мобильные приложения легче переписать и оптимизировать, чем тащить (не сопровождать!) их с устаревшими ОС. Это лучше всего отразиться на потреблении памяти, ресурсов процессора и на времени автономной работы.
0
то что вы написали — это возможность изоляции приложений в целях безопасности личных данных и настроек (например, для скаченного приложения запустить отдельную виртуальную машину — пусть там работает) — было бы неплохо сперва реализовать на уровне десктопных операционных систем, чтобы не приходилось запускать отдельную виртуальную машину с отдельной ОС в ней.
что-нибудь типа клика правой кнопкой мышки по файлу — «запустить в изолированной среде...», выбрать доступные ресурсы (железо, службы, память, максимальная загрузка процессора, досупные папки в файловой системе, сетевые порты и т.п. и т.д.)
что-нибудь типа клика правой кнопкой мышки по файлу — «запустить в изолированной среде...», выбрать доступные ресурсы (железо, службы, память, максимальная загрузка процессора, досупные папки в файловой системе, сетевые порты и т.п. и т.д.)
+1
в идеале каждая прикладная (и не только) программа должна запускаться в такой изолированной среде.
можно, конечно, попытаться реализовать это созданием отдельных пользователей для разных (групп) программ
можно, конечно, попытаться реализовать это созданием отдельных пользователей для разных (групп) программ
0
думаю, это несложно сделать даже используя нехитрый баш-скрипт (если loop файл в качестве жесткого диска использовать, то вообще околотривиальная задача)
0
UFO just landed and posted this here
UFO just landed and posted this here
это, простите, как?
судя по всему там архитектура такая же как и у ESX и Xen, т.е. между железом и доменами (в терминах Xen) расположен тоненький слой hypervisor'а.
скорее всего есть привилегированный домен — domain0, который арбитрирует все запросы domainU к железу.
судя по всему там архитектура такая же как и у ESX и Xen, т.е. между железом и доменами (в терминах Xen) расположен тоненький слой hypervisor'а.
скорее всего есть привилегированный домен — domain0, который арбитрирует все запросы domainU к железу.
+2
UFO just landed and posted this here
просто не совсем понятен смысл.
лозунг разработчиков hypervisor'ов «чем меньше, тем лучше», в том смысле, что не «хайпервайзерское» это дело еще у юзера интересоваться, что он желает и запросы обрабатывать.
Hypervisor — это по сути минимальный набор API, который позволяет распределять ресурсы девайса гостевым ОС. В каком-то смысле — это МетаОС.
Вы захотите, чтобы он у вас спрашивал какую ОС грузить, кто-то пожалуется, что шрифт некрасивый и бэкграунда нет, кому-то не понравится, что нельзя одновременно с двумя VM работать и пошло поехало :) придется заново колесо изобретать, в то время как все работает и так неплохо. Грузите domain0 (можно самую минималистичную, если очень хочется) и оттуда рулите своими виртуальными машинами. Каждый на своем месте.
лозунг разработчиков hypervisor'ов «чем меньше, тем лучше», в том смысле, что не «хайпервайзерское» это дело еще у юзера интересоваться, что он желает и запросы обрабатывать.
Hypervisor — это по сути минимальный набор API, который позволяет распределять ресурсы девайса гостевым ОС. В каком-то смысле — это МетаОС.
Вы захотите, чтобы он у вас спрашивал какую ОС грузить, кто-то пожалуется, что шрифт некрасивый и бэкграунда нет, кому-то не понравится, что нельзя одновременно с двумя VM работать и пошло поехало :) придется заново колесо изобретать, в то время как все работает и так неплохо. Грузите domain0 (можно самую минималистичную, если очень хочется) и оттуда рулите своими виртуальными машинами. Каждый на своем месте.
+1
UFO just landed and posted this here
а не желаете написать подробную статью про организацию и настройку гипервизора и виртуальных машин?
чтобы сразу всё и в одном месте
чтобы сразу всё и в одном месте
+1
довольно долго сидел под ubuntu+xen
нужно было написать драйвер — процесс «перезагрузки» domainU занимал несколько секунд — красота!
но все равно глючил частенько.
нужно было написать драйвер — процесс «перезагрузки» domainU занимал несколько секунд — красота!
но все равно глючил частенько.
0
UFO just landed and posted this here
А что это за вмятина на линуксе со стороны гипервизора? Намек на его дырявость? :)
0
обидно что нельзя скачать, и попробовать потестировать.
Да и вообще — не совсем понятно — под какую программную платформу это написано…
Да и вообще — не совсем понятно — под какую программную платформу это написано…
0
А я с мобильника тупо звоню.
0
Прикиньте, все абоненты сотовой сети будут носить сервера в своих мобильных. Не нужно будет держать серверные и т.д.
-1
UFO just landed and posted this here
Думаю, это специальная приманка для гиков — поставь на свой винмобайл Android, не угробив телефон
-1
Sign up to leave a comment.
А вы уже используете свой мобильный в качестве платформы для нескольких гостевых ОС?