Виртуализация процессора это уже эмуляция, а не виртуализация. Либо слой трансляции, но это тоже не синоним эмуляции, так как там нету цели имитации конкретной модели процессора.
Эм, контейнеры для которых портировали под Windows Server runc и которые запускаются не через виртуалку WSL по определению нативные. То что они не совместимы с Docker для Linux, и наоборот, уже другая история.
Есть ещё нативные Docker-контейнеры для Windows-сервера, но меня терзают сомнения о том как много людей знает об их существование, и какой процент из знающих их использует.
UML-схемы он на удивление хорошо генерирует по примеру из имеющихся изображений, которые как правило в низком разрешение. С учётом того что я не дизайнер, получилось не хуже, чем если бы я вручную это всё делал в draw.io, да и быстрее, чем если бы сам копировал с картинки в mermaid.js.
Wine это совсем другая история, это слой совместимости. Если говорить в общем, то он конвертирует системные вызовы на уровне процессора характерные для Windows в аналогичные для Linux.
Эти ссылки - точно не доказательство, что esx = linux.
Нет, но за 10 лет там накопились далеко не только эти ссылки.
KVM для VMW Workstation: Broadcom не хочет тратить деньги на бесплатный продукт, пытается перейти на opensource хоть в чем-то малом( VMW Workstation для Win смогут на KVM перевести?
Как я уже упомянул выше, это не аргумент в сторону того что VMware стащили ядро Linux для ESXi, это упоминание другого интересного мне инфоповода, в контексте обсуждения VMware вообще, а не конкретно этого судебно дела.
Да(как намек), слой Linux совместимости в FreeBSD ее тоже Линуксом делает?
И то, и то продукты с открытым исходным кодом, их лицензии позволяют копировать друг друга на все 100%. ESXi - закрытый, проприетарный продукт. Продукт от компании которая практически монополист на рынке виртуализации. И если когда-нибудь эти судебные дела продолжатся и будет подтверждено, что ядро ESXi это просто форк Linux, то тем самым они нарушили лицензию и хотели сэкономить на отчислениях за это.
Это лишь вершина айсберга из 10 лет разбирательств, ядро ESXi всегда считалось Linux-подобным, а эти подозрения и разбирательства могут указывать на то, что это вовсе просто его форк.
Что раздувать-то? )
Потому что на рынке принято защищать свою интеллектуальную собственность, особенно если у тебя её использует практически монополист рынка виртуализации и не делает тебе многомиллионных отчислений за это.
kvm это вообще к чему?
К теме моего поста и обсуждения VMware в целом, я же написал в самом начале "И немного в сторону", указав, что это не относится напрямую к ветке обсуждения.
Против лома нет приёма, против социальной инженерии или уязвимости на уровне перефирии, к примеру взлома удалённого доступа к KVM(который для доступа к серверам, а не который виртуальная машина), виртуалки тоже не защитят. Да и Spectre с Meltdown исправили в новых моделях процессоров.
Как уже отметили, это пользовательский интерфейс для взаимодействия с виртуальными машинами. Docker тут как и в ряде других случаев будет выступать просто инструментом для установки его.
Спасибо, буду стараться.) Хотя в завершающей 1/3 от статьи, вроде наконец-то тестировал уже всё как надо. Но в комментариях появилось много интересных предложений для нового тестирования, так что продолжению скорее всего точно быть. Плюс интересно ещё поэкспериментировать с FFmpeg не в консоли, а с подключением его отдельных библиотек в коде, под конкретные задачи.
И по стилю, скорее всего дальше будет также. Не хочется вырезать неудачные дубли и трудности, так как примеров того когда всё идёт как надо достаточно. А когда всё пошло не по плану, обычно отбраковывается и свет никогда не видит, хотя интересного и полезного, там порой не меньше.
Спасибо что напомнили про Gstreamer, в данном случае хотелось конкретно на примере ffmpeg поэкспериментировать, так как с ним привыкли работать. FFmpeg ещё на удивление ведёт себя в лучшую сторону когда работаешь с его модулями по отдельности через код на плюсах, а не в консоли. Пока что правда непонятно, почему так.
С ffmpeg у меня странности ещё продолжились дальше, когда я решил его использовать не из под консоли, а по документации подключая его модули в программе на плюсах. Разницы в производительности я от этого не ожидал, но она снова откуда-то взялась.
Ну а ещё в исходниках ffmpeg убивает околонулевое количество комментариев.
В первых 2/3 напутал, я про это и сам отписался. Хотя по идее mpeg4 тоже аппаратно поддерживается, но вот фильтр на рескейл определённо грузил только процессор.
ffmpeg-cuda -hwaccel cuda -hwaccel_output_format cuda -i bbb_sunflower_2160p_30fps_normal.mp4 -vf "scale_cuda=1920:1080" -c:v hevc_nvenc -preset medium output_cuda.mp4
Тут уж и кодек указан аппаратный, и фильтр на рескейл аппаратный, мониторинг показывал что GPU был загружен, а CPU почти простаивал. Или же этого тоже недостаточно и ещё что-то нужно было указывать в параметрах команды для большего аппаратного ускорения?
После того как я заметил что mpeg4 напутал с h264/h265 я же вроде бы так и сделал, да и мониторинг у меня отражал что CPU почти не грузился(в статью правда это уже не вошло).
ffmpeg-cuda -hwaccel cuda -hwaccel_output_format cuda -i bbb_sunflower_2160p_30fps_normal.mp4 -vf "scale_cuda=1920:1080" -c:v hevc_nvenc -preset medium output_cuda.mp4
Читал во время написания поста, перечитал опять и честно говоря так и не понял, где именно везде у меня кодек для CPU.
ffmpeg-cuda -hwaccel cuda -hwaccel_output_format cuda -i bbb_sunflower_2160p_30fps_normal.mp4 -vf "scale_cuda=1920:1080" -c:v hevc_nvenc -preset medium output_cuda.mp4
Кодек - hevc_nvenc использует GPU.
NVENC can be used for H.264 and HEVC encoding. FFmpeg supports NVENC through the h264_nvenc and hevc_nvenc encoders. In order to enable it in FFmpeg you need:
Фильтр - scale_cuda - использует GPU.
An example using scale_cuda and encoding in hardware, scale_cuda is available if compiled with ffnvcodec and --enable-cuda-llvm (default is on, requires nvidia llvm to be present at runtime):
Да и мониторинг через nvtop и htop, указывает на загрузку GPU, а не CPU.
После проведения этого эксперимента, я уже ни в чём не уверен, но исходя из моего перечитывания SDK Nvidia и спецификаций использованных нами карточек, в профили мы попадали.
Ну вот, для mpeg4, внезапно, как оказалось может. Не удивлюсь уже, если за пределами mpeg4 vs h264 и при других задачах, помимо просто рескейла/смены битрейта ещё какие-то сюрпризы вскроются.
Виртуализация процессора это уже эмуляция, а не виртуализация.
Либо слой трансляции, но это тоже не синоним эмуляции, так как там нету цели имитации конкретной модели процессора.
Эм, контейнеры для которых портировали под Windows Server runc и которые запускаются не через виртуалку WSL по определению нативные. То что они не совместимы с Docker для Linux, и наоборот, уже другая история.
https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd#runhcs
Есть ещё нативные Docker-контейнеры для Windows-сервера, но меня терзают сомнения о том как много людей знает об их существование, и какой процент из знающих их использует.
UML-схемы он на удивление хорошо генерирует по примеру из имеющихся изображений, которые как правило в низком разрешение. С учётом того что я не дизайнер, получилось не хуже, чем если бы я вручную это всё делал в draw.io, да и быстрее, чем если бы сам копировал с картинки в mermaid.js.
Wine это совсем другая история, это слой совместимости. Если говорить в общем, то он конвертирует системные вызовы на уровне процессора характерные для Windows в аналогичные для Linux.
Нет, но за 10 лет там накопились далеко не только эти ссылки.
Как я уже упомянул выше, это не аргумент в сторону того что VMware стащили ядро Linux для ESXi, это упоминание другого интересного мне инфоповода, в контексте обсуждения VMware вообще, а не конкретно этого судебно дела.
И то, и то продукты с открытым исходным кодом, их лицензии позволяют копировать друг друга на все 100%. ESXi - закрытый, проприетарный продукт. Продукт от компании которая практически монополист на рынке виртуализации. И если когда-нибудь эти судебные дела продолжатся и будет подтверждено, что ядро ESXi это просто форк Linux, то тем самым они нарушили лицензию и хотели сэкономить на отчислениях за это.
Это лишь вершина айсберга из 10 лет разбирательств, ядро ESXi всегда считалось Linux-подобным, а эти подозрения и разбирательства могут указывать на то, что это вовсе просто его форк.
Потому что на рынке принято защищать свою интеллектуальную собственность, особенно если у тебя её использует практически монополист рынка виртуализации и не делает тебе многомиллионных отчислений за это.
К теме моего поста и обсуждения VMware в целом, я же написал в самом начале "И немного в сторону", указав, что это не относится напрямую к ветке обсуждения.
С учётом того что люди активно путают эти два понятия, вынужден не согласиться.
Увидели не мы, а разработчики ядра, которые с VMware судятся последние лет 10 кажется.
https://www.theregister.com/2015/03/05/vmware_sued_for_gpl_violation_by_linux_kernel_developer/
https://sfconservancy.org/news/2019/apr/02/vmware-no-appeal/
И немного в сторону из совсем свежего, для VMware Workstation они теперь используют KVM в качестве гипервизора.
https://www.heise.de/en/news/VMware-makes-a-splash-KVM-instead-of-proprietary-hypervisor-10001742.html
Против лома нет приёма, против социальной инженерии или уязвимости на уровне перефирии, к примеру взлома удалённого доступа к KVM(который для доступа к серверам, а не который виртуальная машина), виртуалки тоже не защитят.
Да и Spectre с Meltdown исправили в новых моделях процессоров.
Как уже отметили, это пользовательский интерфейс для взаимодействия с виртуальными машинами. Docker тут как и в ряде других случаев будет выступать просто инструментом для установки его.
Спасибо, буду стараться.)
Хотя в завершающей 1/3 от статьи, вроде наконец-то тестировал уже всё как надо.
Но в комментариях появилось много интересных предложений для нового тестирования, так что продолжению скорее всего точно быть. Плюс интересно ещё поэкспериментировать с FFmpeg не в консоли, а с подключением его отдельных библиотек в коде, под конкретные задачи.
И по стилю, скорее всего дальше будет также. Не хочется вырезать неудачные дубли и трудности, так как примеров того когда всё идёт как надо достаточно. А когда всё пошло не по плану, обычно отбраковывается и свет никогда не видит, хотя интересного и полезного, там порой не меньше.
Спасибо что напомнили про Gstreamer, в данном случае хотелось конкретно на примере ffmpeg поэкспериментировать, так как с ним привыкли работать.
FFmpeg ещё на удивление ведёт себя в лучшую сторону когда работаешь с его модулями по отдельности через код на плюсах, а не в консоли. Пока что правда непонятно, почему так.
С ffmpeg у меня странности ещё продолжились дальше, когда я решил его использовать не из под консоли, а по документации подключая его модули в программе на плюсах. Разницы в производительности я от этого не ожидал, но она снова откуда-то взялась.
Ну а ещё в исходниках ffmpeg убивает околонулевое количество комментариев.
В первых 2/3 напутал, я про это и сам отписался. Хотя по идее mpeg4 тоже аппаратно поддерживается, но вот фильтр на рескейл определённо грузил только процессор.
Тут уж и кодек указан аппаратный, и фильтр на рескейл аппаратный, мониторинг показывал что GPU был загружен, а CPU почти простаивал. Или же этого тоже недостаточно и ещё что-то нужно было указывать в параметрах команды для большего аппаратного ускорения?
После того как я заметил что mpeg4 напутал с h264/h265 я же вроде бы так и сделал, да и мониторинг у меня отражал что CPU почти не грузился(в статью правда это уже не вошло).
Спасибо за замечание, в следующем посте по этой теме или аналогичными, буду писать словами развёрнуто, а не только процентами.
Читал во время написания поста, перечитал опять и честно говоря так и не понял, где именно везде у меня кодек для CPU.
Кодек - hevc_nvenc использует GPU.
Фильтр - scale_cuda - использует GPU.
Да и мониторинг через nvtop и htop, указывает на загрузку GPU, а не CPU.
После проведения этого эксперимента, я уже ни в чём не уверен, но исходя из моего перечитывания SDK Nvidia и спецификаций использованных нами карточек, в профили мы попадали.
Ну вот, для mpeg4, внезапно, как оказалось может.
Не удивлюсь уже, если за пределами mpeg4 vs h264 и при других задачах, помимо просто рескейла/смены битрейта ещё какие-то сюрпризы вскроются.
Спасибо за совет, в следующий раз когда буду более подробно и под другим углом проводить тесты + скорее всего с другим железом, учту это.