Отдельный программист нужен потому, что обычно железячник если и умеет в программирование, то учился он этому самостоятельно и как следствие про организацию кода, рефакторинг использование VCS и тому подобные «организационные» моменты скорее всего даже не слышал. Я это сейчас в соседнем отделе наблюдаю - мрак, хотя потихоньку учатся.
нет не меньший... в свое время memcg ухудшало производительность подсистемы памяти на 15%, причем это в, так сказать, холостом режиме когда фитча просто вкомпилена в ядро... наверняка и остальные контейнерные фитчи и неймспейсы добавляют свой оверхед.
тут уже упоминался mirage заточеный под Xen, есть также ErlangOnXen - оба этих проекта предоставляют необходимый минимум для рантайма OCaml и Erlang соответственно. То что ничего кроме рантайма не поддерживается позволяет реализовать управление ресурсами со многими, весьма валидными, допущениями что в свою очередь приводит к достаточно простому и быстрому коду. Да, есть оверхед со стороны гипервизора, но зато в данном сценарии получаем трушную изоляцию.
Есть и другой проект со схожими идеями - OSv. Проект хоть и начинался как прослока для поддерки JVM, но уже разошелся и предоставляет некий бинарный шим,да такой что на нем вполне неплохо себя чувствуют и тот же Ocaml и Erlang и много чего другого. Интересным является тот факт что среди основателей проекта люди внесшие значительный вклад в подсистемы KVM и CGroups, так что их «сравнительные» презентации достаточно любопытны ;)
не очень понятно что имеется ввиду под «включать», но пример с memcg выше подразумевал что соответствующая опция ядра была в значении 'y' при сборке. регрессия в производительности имела место быть просто при загрузке с таким ядром.