Виртуальные машины не то чтобы зло...

[vak]

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

К примеру, Питон, отличный язык, но построенный вокруг специальной виртуальной машины. Вопрос на засыпку: сколько разных копий Питона установлено на вашем компьютере? Я глянул на своём маке:

• собственно Питона установлено четыре версии: 2.7, 3.8, 3.9, 3.10
• копия Питона 3.7 внутри приложения LibreOffice
• три лишних копии Питона 3.8 в приложениях XCode, Apple CLI Tools и KiCad
• ещё одна копия Питона 3.9 в компиляторе для ESP32
• плюс десять копий Питона 3.10 в утилитах awscli, bpytop, gallery-dl, glances, meson, scons, sip, sphinx-doc, xonsh, youtube-dl

Итого 19 штук одного Питона. Отдельно можно посчитать Java, .NET, Ruby, Guile, Lua и другие. Налицо нездоровая тенденция виртуальных машин плодиться и замусоривать пространство. Версии плодятся, и чтобы избежать проблем несовместимости каждый софтверный продукт стремится тащить с собой отдельную копию каждой виртуальной машины. 

Comments

[ircicq]

VM разные

Java и .NET имеют JIT и исполняются в машинных кодах.
Python (обычно) нет.

[vak]

JIT или не JIT - несущественно с точки зрения заявленной проблемы. Для Питона тоже есть JIT-реализации.

[ircicq]

Это проблема DLL hell - более общая, и свойственна не только виртуальным машинам.

Любой крупный продукт тащит привязку к конкретным версиям shared libraries,
а уж containerized-приложения по-определению.

[vak]

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

[x86128]

Проблема есть, какого-то универсального решения - нет.
А решать как-то надо, вот инженеры и придумали (в век резиновой памяти) запекать все в навозные шарики контейнеры и поставлять пользователям чтобы зависимости были только от ядра ОС.

[x86128]

Забавно, но если заменить VM на shared library суть поста не изменится :)
Так сложилось что разработчики пишут ПО с разной скоростью и догоняют апстримы как придется, вот и получается что наши системы вынужденно замусореваются такими зависимостями

[euthanasepam]

> Налицо нездоровая тенденция виртуальных машин плодиться и замусоривать пространство.


Они же не сами плодятся. Их плодят-с. Чтобы, как мне тут пишут в свежем утреннем рекламном письме, «to deliver and transform applications in less time». Пользователь-то всё стерпит…

[dmytrish]

Цікаво, що легкі, embeddable віртуальні машини мають тенденцію плодитись сильніше. Моя гіпотеза: власна копія JVM в програмі буде значно рідшою, ніж копія CPython, і тим більше lua.

Та сама логіка працює щодо статично лінкованих програм так само: в них купа дубльованих і трохи різних версій одних і тих самих бібліотек, тільки що ми навіть не можемо побачити, копія чого саме запечена в купу великих бінарників.

Так, Linux shared libraries і перевикористання пакунків це справді аномалія і дуже багато роботи, щоб протестувати це все разом.

Edit: про недоліки VMs додам ще про те, що embedded VMs створюють ефект внутрішньої платформи, де раптово перестають ефективно працювати інструменти для машинного коду, без VM-specific tooling все різко стає непрозорим: профайлинг, дебаг, security audits. І навіть коли воно є, зробити корисні висновки стає складніше.

[doldonius]

Так фигушки нам эти RISCи в машинных кодах чего исполнят. У них внутре неонка микрокодовая, которая процессором с некоей системой команд только прикидывается.

[ivanrubilo]

Уже и у цисков давно микрокод только для юбервафель типа строковых операций и всяких хитрых режимов типа SGX, остальное стараются притянуть чтобы нативненько.

[doldonius]

Да цискари-то отродясь хитренькие были.

[ivanrubilo]

Так все хитрожопенькие - отличить цискаря от рискаря нонче довольно сложно для any sufficiently advanced micro architecture.

[vak]

Нету в рисках микрокода. Вас кто-то обманул.

[doldonius]

Скорее всего, сам запутался. С тех пор, как через саппорт в админы угодил, так глубоко лазить стало некогда.

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

[caztd]

-- это проблема не новая
-- конечно, любой package manager решает ту же самую проблему вполне себе эффективно
-- ну да, возьмем к примеру npm
-- б*ъ*/*%*&*ъ!!!!

[vak]

А не надо брать _любой_ package manager, надо брать хороший. Cargo вот решает.

[caztd]

поговорим об этом когда у cargo будет столько же идиотов пользователей как у npm.