LINUX.ORG.RU

Какую виртуальную машину вы используете ДОМА, способную поддерживать более ОДНОЙ ОС

 ,


0

3
  1. Выстроил по алфавиту.
  2. Проприетарщина, оффтопик не игнорируются.
  3. Песочницы, вроде Jail(FreeBSD) - не рассматриваются, т.к. интересует статистика по VMам, способным запускать более одной ОС (DOSBox катит, т.к. кроме MS-DOS способен запускать любую x86-DOSку).
  4. Поддерживаемые платформы не интересуют, но подбор был под x86/amd64.
  1. VirtualBox 344 (66%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. KVM (все модификации) 148 (28%)

    *****************************************************************************************************************************************

  3. QEMU (все модификации) 142 (27%)

    ************************************************************************************************************************************

  4. DOSBox 72 (14%)

    ******************************************************************

  5. VMware (все модификации) 54 (10%)

    **************************************************

  6. Hyper-V 22 (4%)

    ********************

  7. Другое - указать в комментариях 20 (4%)

    ******************

  8. Bhyve 8 (2%)

    *******

  9. Bochs 6 (1%)

    *****

  10. Parallels Workstation 6 (1%)

    *****

  11. Virtual PC 2 (0%)

    *

Всего голосов: 824, всего проголосовавших: 521

★★★★★

Проверено: Satori ()

Ответ на: комментарий от Shaman007

Ну и qemu потому что я работал в RedHat (на самом деле нет, ЭОС: предоставленные в опросе платформы виртуализации решают несколько разные задачи и quemu решает, например, задачи кросс-компиляции, а другие из списка - не решают).

/sarcasm

Shaman007 ★★★★★
()
Ответ на: комментарий от x905

Как пользователь, лэхко побачыты(tm), что вмваря под онтопиком заводится лишь на определённых версиях ядра, то есть всякие тецтинги, рачи и прочий блидинэдж — в пролёте.

А вот под оффтопик вмваря вполне ня! Мы лет 9 назад ещё качали для неё с какого-то японского сайта (ныне почившего, по ходу) готовые образы разных ОС — на потыкать. Там и линукс впервые увидели, Ubuntu Studio 9.04, кажется.

mertvoprog
()
Ответ на: комментарий от x905

я, как пользователь, это где замечу ?

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

Linfan ★★★★★
()
Последнее исправление: Linfan (всего исправлений: 3)
Ответ на: комментарий от mertvoprog

вмваря под онтопиком заводится лишь на определённых версиях ядра

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

Linfan ★★★★★
()
Ответ на: комментарий от Linfan

Смотря где и на какой вмваре.

вот что ты пишешь - ниразу не замечал, но я же «домашний» пользователь - запускаю редко 2d игры (венда) или тесты со снапшотами

x905 ★★★★★
()
Ответ на: комментарий от drfaust

Ты все правильно сделал, VirtualBox тоже умеет в KVM.

slapin ★★★★★
()
Ответ на: комментарий от fornlr

А что там такое даже есть? Я думал там только shared folders… :/

slapin ★★★★★
()
Ответ на: комментарий от x905

вот что ты пишешь - ниразу не замечал

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

Linfan ★★★★★
()
Ответ на: комментарий от Linfan

Работает VMWare нормально, только очень интрузивная. Но она такая с самого начала была. Энтерпрайз однако.

slapin ★★★★★
()
Ответ на: комментарий от Linfan

Сейчас для вмвари ничего патчить не нужно, виртуальные дрова все есть в дистрах / ядре, но работает даже без них с урезанием фич. Тоже умеет в KVM.

slapin ★★★★★
()
Ответ на: комментарий от Shaman007

Через дорогу таки перешел! Молодец! :)

slapin ★★★★★
()
Ответ на: комментарий от Linfan

Нудно собирать модули. Те, что идут в поставке, могут чуть отставать и приходится иногда подпатчить, но тут все как в виртуалбоx.

slapin ★★★★★
()
Ответ на: комментарий от Linfan

Ага, пердолиться с пересборкой ядра лишь для того, чтобы завести вмварю, когда полно аналогов ;) Тем более, виртуалбокс вон вроде давно умеет вмваревские диски подключать.

mertvoprog
()
Ответ на: комментарий от slapin

но тут все как в виртуалбоx

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

Linfan ★★★★★
()
Ответ на: комментарий от mertvoprog

пердолиться с пересборкой ядра

Когда семья, дети и работа отъедают львиную долю времени, дай бог чтобы не отставать сильно от мейнстрима.

Linfan ★★★★★
()
Ответ на: комментарий от slovazap

значит и jail с разными юзерспейсами должны считаться

Не совсем. Jail может запускать только ELF от FreeBSD. Jail — это почти chroot.

Поинт был в том что в jail можно запустить целый дистрибутив.

Не целый. Ядро будет от хоста, плюс изоляция. Ну и у FreeBSD есть всего полтора дистрибутива (*BSD между собой несовместимы, у них разное ядро), которые отличаются между собой почти ничем.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Не совсем. Jail может запускать только ELF от FreeBSD. Jail — это почти chroot.

Зачем ты мне это рассказываешь? Я жейлами пользуюсь больше десятка лет. Они ничего не запускают, запускает ядро FreeBSD, и запускает оно ELF от FreeBSD и Linux. А jail - способ изоляции, позволяющей установить внутрь целиковый дистрибутив linux, в отличие от запуска отдельного приложение со своими библиотечками в compat/linux. Всё вместе это не менее достойно быть в списке чем dosbox который запускает разные вкусы досов.

Ну и у FreeBSD есть всего полтора дистрибутива (*BSD между собой несовместимы, у них разное ядро), которые отличаются между собой почти ничем.

Я не предлагал запускать дистрибутивы FreeBSD.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

запускает ядро FreeBSD, и запускает оно ELF от FreeBSD и Linux.

Для запуска ELF от Linux нужно устанавливать компаты при любом раскладе.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Мы же говорим о запуске дистрибутива, там всё есть. Для запуска одного приложения это лежит в порте linux_base, но мы не о нём.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

А как же systemd? Сейчас дистрибутивов Linux без systemd можно на пальцах одной лапки пересчитать. Проблема заключается в cgroups. Если я ошибаюсь, ткни меня носом в соответствующий тред/мейл/багрепорт фряхи, я не нашёл.

mord0d ★★★★★
()
Ответ на: комментарий от slovazap

systemd я не запускал, и даже уверен что он не запустится. Мне в нём нужды никакой не было.

Так и мне в нём нужды нет, но не пилить же для этих нужд свой дистрибутив (с пакетной базой, ага). Фактически из non-systemd у нас есть Void, Alpine и NixOS, остальные так или иначе тянут зависимостью хоть что-нибудь. И я почти уверен, что в NixOS используется cgroups, потому вряд ли он взлетит.


ткни меня носом в соответствующий тред/мейл/багрепорт фряхи, я не нашёл.

UPD:

Нашёл это, но:

But be careful, not everything works perfectly

ЧТД.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Так и мне в нём нужды нет, но не пилить же для этих нужд свой дистрибутив (с пакетной базой, ага).

Как это связано? Я юзал обычную убунту с systemd, не запуская systemd. Но да, в дистрибутиве без systemd скорее всего можно будет использовать больше плюшек, типа нативной системы запуска сервисов.

И я почти уверен, что в NixOS используется cgroups, потому вряд ли он взлетит.

Вообще-то, https://www.freshports.org/sysutils/nix

But be careful, not everything works perfectly

А как вы хотели? Это же не Linux. YMMV, как говорится, но это частные проблемы, я лично на них ни разу не наступал. Так и не во всех виртуалках не всё всегда запускается, а в том же dosbox и подавно (в своё время когда игрался с x86 ассемблером, в dosbox не запустился, ЕМПИП, даже norton commander, не говоря даже об отладчиках, хотя там и встоенный есть; в итоге использовал тормозной bochs).

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Как это связано?

А связано это напрямую рантаймом. Если что-то хочет запускаться через systemd и/или юзает плюшки systemd и не сможет этого сделать, то оно не будет работать (хотя, подозреваю, в некоторых дистрибутивах типа Gentoo это как-то обыгрывается, но возможно придётся компилять).

Вообще-то, https://www.freshports.org/sysutils/nix

Есть dpkg, pacman, теперь и nix, но portage до сих пор не завезли. ☹

в своё время когда игрался с x86 ассемблером, в dosbox не запустился

Ну так DOSBox пилится для DOS-игр; работоспособность прочего софта никто никогда не гарантировал.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Есть dpkg, pacman, теперь и nix, но portage до сих пор не завезли. ☹

Раньше же был gentoo-stage-*, где можно было скомпилять свою генту в linux compat, с portage.

xtouqh
()
Ответ на: комментарий от mord0d

А связано это напрямую рантаймом. Если что-то хочет запускаться через systemd и/или юзает плюшки systemd и не сможет этого сделать, то оно не будет работать

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

Есть dpkg, pacman, теперь и nix, но portage до сих пор не завезли

Понятно почему - там есть бинарные пакетные менеджеры (потому что архив скачать-распаковать большого ума не нужно) и source based изначально нацеленные на кроссплатформенность. А portage ни тем, ни другим не является - это непереносимая linux-специфичная поделка, при том непонятно зачем нужная при наличии родных портов.

Ну так DOSBox пилится для DOS-игр; работоспособность прочего софта никто никогда не гарантировал.

Тем не менее он числится в вариантах опроса. С чего и начался разговор.

slovazap ★★★★★
()
Ответ на: комментарий от xtouqh

Раньше же был

Когда он нафиг был не нужен (ибо был жив Gentoo/FreeBSD).

можно было скомпилять свою генту в linux compat

Зачем, если можно было юзать sys-fbsd/* (или как оно там называлось, уже не помню)?

Теперь нельзя, Gentoo/FreeBSD никем не поддерживается, фактически мертво и вряд ли оживёт в ближайшем будущем (я боролся, но маразм победил).

mord0d ★★★★★
()
Ответ на: комментарий от slovazap

В остальных всё работает и ограничиваться без-systemd дистрами совершенно не обязательно.

Возможно я преувеличиваю. Меня вообще совместимость с Linux… напрягает.

А portage ни тем, ни другим не является - это непереносимая linux-специфичная поделка

Нет. Как я уже писал выше, раньше в нём была поддержка FreeBSD (с полным сетом всей базовой системы, расчленённым на несколько ебилдов). Никаких препятствий вернуть всё взад нет, но понадобится обновить (фактически — переписать) профиль, обновить ебилды (или хотя бы починить существующие, пусть и старые, 11.1) и, возможно, поправить еклассы. Я пытался, но в одну каску у меня просто не хватит терпения, а кроме меня, судя по всему, Gentoo/FreeBSD не интересен.

при том непонятно зачем нужная при наличии родных портов.

Справедливости ради:

  • Если софт можно собрать с/без юза (опции), этот юз обязательно присутствует в ебилде (и если он не работает, его маскируют), в портах в этом плане очень скудно;
  • В портаже полноценный мультилиб уже лет пять, порты до сих пор не умеют в нормальный мультилиб потому что его нет в FreeBSD;
  • Портаж архитектурно писался хакабельным: чтобы поправить логику ебилда не нужно редактировать ебилд, можно расширить функционал портажа не трогая сам портаж, порты на такое не рассчитаны;
  • Порты собирают пакеты по одному по очереди и большинство софта собирается в один поток (-j1), в портаже это настраивается и ничего не ломает.

Но с FreeBSD я не уйду. :3

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Как я уже писал выше, раньше в нём была поддержка FreeBSD

Это было больше десятка лет назад и давно закопано. Вернуть её обратно нельзя, ибо на linux, от ядра до структуры каталогов там завязано чуть более чем всё. Нет, там не нужны ебилды базы, там нужно переписать все ебилды чтобы они собирались на FreeBSD.

Вообще же у меня складывается впечатление что gentoo сдох - по той же repology видно что даже от FreeBSD от по свежести пакетов отстаёт уже почти в 2 раза. Если он сам по себе никому настолько не интересен, то под FreeBSD и подавно.

Если софт можно собрать с/без юза (опции), этот юз обязательно присутствует в ебилде (и если он не работает, его маскируют), в портах в этом плане очень скудно

Что значит «обязательно»? Если мантейнер почешется то присутствует, если нет то отсутствует.

В портаже полноценный мультилиб уже лет пять, порты до сих пор не умеют в нормальный мультилиб потому что его нет в FreeBSD;

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

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

Это уже наглая ложь - в портах вся логика в Mk и замечательно хакабельна. Напротив, из-за декларативной природы мейкфайлов централизованно менять поведение портов гораздо проще. Другими словами, порты с переопределёнными императивными do-build/do-install это исключение, в портаже - правило, а центализованно логику зашитую в ебилдах не поменяешь.

Порты собирают пакеты по одному по очереди и большинство софта собирается в один поток (-j1), в портаже это настраивается и ничего не ломает.

Опять ложь, 98% портов собирается с -j$(sysctl hw.ncpu), с -j1 собираются только порты которые ломаются при параллельной сборке и явно помечены MAKE_JOBS_UNSAFE. Разные порты собираются последовательно если собирать руками, но учитывая вышесказанное это не минус, так как все ядра можно загрузить и сборкой одного порта за раз, а при этом собирать несколько портов сразу неэфективно, посколько быстрее не будет, а памяти и места уйдёт больше. А в poudriere можно и несколько портов собирать параллельно.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Это было больше десятка лет назад и давно закопано.

Гораздо меньше.

и давно закопано.

Не так уж давно.

Вернуть её обратно нельзя

Можно, но требуется очень много времени и сил.

на linux, от ядра до структуры каталогов там завязано чуть более чем всё

А я не утверждал что там сохранена структура *BSD. Ну и пакеты ставятся точно так же в кучу как на Linux, а не в отдельный префикс.

Нет, там не нужны ебилды базы, там нужно переписать все ебилды чтобы они собирались на FreeBSD.

Внезапно, в ебилдах большинства ядрозависимых пакетов до сих пор (ну или как минимум были когда я окончательно сваливал с Linux) есть kern_fbsd, или как-то так.

Что значит «обязательно»?

Это значит что это прописано в их Porter’s Handbook, как бы оно ни называлось.

Если мантейнер почешется то присутствует, если нет то отсутствует.

Основное дерево не такая помойка как большинство сторонних оверлеев. Да, по свежести иногда отстаёт (ибо тестирование), но шлака там почти нет (как и в портах, впрочем).

со смертью 32битной архитектуры

Не надо выдавать желаемое за действительное.

На Celeron N3050 + 2G RAM (тот самый DEXP, который мне притащили пару дней назад) amd64 тормозит до состояния неюзабельности. Я признаю смерть x86 только тогда, когда совсем перестану встречать x86 железо (а до этого ещё очень далеко, у меня до сих пор Pentium III где-то бегает).

в портах вся логика в Mk и замечательно хакабельна.

Но для этого нужно сделать свою копию дерева портов и похакать.

централизованно менять поведение портов гораздо проще

Во-первых это надо редко, во-вторых в портаже за это отвечают еклассы.

а центализованно логику зашитую в ебилдах не поменяешь

Большая часть ебилдов не имеют в себе логики вообще, всё вынесено в еклассы. Ну а в портах не поменяешь логику per-package (а в портаже можно не только для конкретного ебилда, а ещё и для конкретной версии, а порты до сих пор могут держать только одну версию пакета).

98% портов собирается с -j$(sysctl hw.ncpu), с -j1 собираются только порты которые ломаются при параллельной сборке и явно помечены MAKE_JOBS_UNSAFE.

Эти 2% (ну может чуть-чуть больше) с MAKE_JOBS_UNSAFE способны съесть мозг.

А в poudriere можно и несколько портов собирать параллельно.

Так у poudriere и make.conf свой.

mord0d ★★★★★
()
Ответ на: комментарий от slovazap

Мультилиб стал не нужен со смертью 32битной архитектуры.

Отвечу коротко: wine.

Но, конечно, если запускать виндовый 32битный софт/игры не нужно, тогда согласен.

xtouqh
()
Ответ на: комментарий от mord0d

Это значит что это прописано в их Porter’s Handbook, как бы оно ни называлось.

Много где много чего прописано, что невозможно соблюсти на практике. Да и не нужно.

Не надо выдавать желаемое за действительное. На Celeron N3050 + 2G RAM

Не выдавайте - никому вы со своим селероном не сдались.

Но для этого нужно сделать свою копию дерева портов и похакать.

Без копии дерева портов вообще нет, не понимаю к чему вы это.

Во-первых это надо редко, во-вторых в портаже за это отвечают еклассы.

Вы сказали как аргумент за portage что можно хакать - когда я сказал что хакать можно и FreeBSD говорите что редко надо. Уж определитесь. Как там оно называется к дискуссии отношения не имеет.

Большая часть ебилдов не имеют в себе логики вообще, всё вынесено в еклассы.

Открыл первый попавшися ебилд, в src_prepare вызывается sed, потом epatch, потом eautoreconf, в src_configure - econf. Во FreeBSD будет GNU_CONFIGURE=true, патч достаточно положить в files, а для sed есть макрос. О, узнал что оказывается ещё и || die надо писать руками, это сразу куча граблей.

Я понимаю что поведение epatch/eautoreconf/econf можно менять, но во FreeBSD то же самое во-первых, в порте занимает в 3 раза меньше строк, во-вторых настраивается гораздо гибче - например, для портов использующих configure можно начать делать дополнительные действия во всех фазах - patch, configure, build и install фазах, не меняя ни одного порта. А для sed (который REINPLACE_CMD) не трогая ни одного порта недавно добавили механизм диагностики выявляющий вызовы sed’а которые ничего не меняют - т.е. ненужные или ошибочные. В portage такое можно сделать только заменив все sed’ы на какие-нибудь esed’ы. И так с любой командой.

Так что императивщина здесь работать никогда не будет, сколько бы полиморфизма под ней не лежало.

Ну а в портах не поменяешь логику per-package

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

(а в портаже можно не только для конкретного ебилда, а ещё и для конкретной версии, а порты до сих пор могут держать только одну версию пакета).

Ну во-первых, где надо это замечательно решается несколькими портами. И это работает гибче, потому что в зависимости от ситуации общий код можно не дублировать, а положить в какой-нибудь common.mk, или наследовать Makefile’ы через MASTERDIR, или наоборот полностью разделить порты, а не иметь общую свалку патчей для разных версий.

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

Эти 2% (ну может чуть-чуть больше) с MAKE_JOBS_UNSAFE способны съесть мозг.

Не больше - 1.94%. Не видел ни одного пакета из них который сколь либо долго собирается. А я в poudriere регулярно собираю тысячи пакетов. Последовательно, потому что work на tmpfs. График загрузки CPU получается вполне в полку.

Так у poudriere и make.conf свой.

Хотите свой, хотите сделайте симлинк на системный. При чём тут вообще make.conf?

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от xtouqh

Отвечу коротко: wine.

Ну так i386-wine сделали, никаких мультилиб не понадобилось. А если они больше ни для чего не нужны, то не должно быть и увеличивающих общую сложность системы глобальных механизмов.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Ну так i386-wine сделали, никаких мультилиб не понадобилось.

Да-да-да, как же… Вот сейчас имею x86 инстяллятор x86_64 игры, который перед завершением пытается дёрнуть x86 инстяллятор каких-то x86_64 библиотек. Сколько раз придётся переустанавливать Wine (учитывая что wine и i386-wine одновременно установить нельзя) чтобы получить результат?

mord0d ★★★★★
()

VirtualBox лидирует? Как можно до сих пор им пользоваться, когда он тормозит (по сравнению с тем же KVM) и сует в ядро свои неподписанные драйвера (и потом даже баг репорт не отправишь из-за этого)?

rupert ★★★★★
()
Ответ на: комментарий от mord0d

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

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.