Продолжая следовать намеченному плану плану (http://www.opennet.me/opennews/art.shtml?num=41350) по объединению кодовых баз открытой системы контейнерной виртуализации OpenVZ (http://openvz.org/) и коммерческого продукта Virtuozzo (http://www.odin.com/ru/products/virtuozzo/) (Parallels Cloud Server), компания Parallels открыла (http://lists.openvz.org/pipermail/announce/2015-June/000592....) исходный код утилит (https://src.openvz.org/projects/OVZ) Virtuozzo под свободными лицензиями GPLv2 и LGPLv2. Теперь открыта разработка не только ядра (http://www.opennet.me/opennews/art.shtml?num=42113) RHEL7 для
будущей версии Virtuozzo/OpenVZ, но и пользовательских утилит Virtuozzo. Таким образом сторонние разработчики получили
возможность присылать патчи, участвовать в технических обсуждениях и
рецензировать код через рассылку OpenVZ (devel at openvz.org).
Список утилит:
- prlctl - универсальная утилита для управления контейнерами и виртуальными машинами
- libprlsdk - Virtuozzo API для C++ и Python
- prl-disp-service - сервис для управления контейнерами и виртуальными машинами
- libvzctl - низкоуровневая библиотека для управления контейнерами
- libvzevent - низкоуровневая библиотека для нотификаций событий от контейнеров из ядра
- vzctl - утилита для управления контейнерами
- vztt - утилита для управления темплитами контейнеров
Отдельно хотелось бы отметить, что основной утилитой для управления конетйнерами и виртуальными машинами
является prlctl. Утилита vzctl будет объявлена устаревшей в следующем релизе Virtuozzo, но в ближайшем релизе она будет присутствовать в целях совместимости.
Ожидается, что развитие Virtuozzo как единого с OpenVZ открытого продукта снизит трудозатраты персонала за счёт избавления от раздельной работы разными инструментариями, позволит привлечь к разработке независимых участников из сообщества и упростит процесс портирования специфичных для Virtuozzo патчей для
новых выпусков основного ядра Linux. Объединение также позволит решить проблему с совместимостью открытого и проприетарного решения - системы на базе OpenVZ смогут быть легко переведены на Virtuozzo.URL: http://lists.openvz.org/pipermail/announce/2015-June/000592....
Новость: http://www.opennet.me/opennews/art.shtml?num=42343
Ну наконец-то.
а что хорошего? нравятся друзья пропринетарщики?
> а что хорошего? нравятся друзья пропринетарщики?Нравится проект OpenVZ, причём уже много лет и в сугубо практической плоскости.
чем?
> чем?Тем, что есть и работает.
PS: тут была замордована пара комментариев, авторы которых ничего, кроме выкриков, предоставить не удосужились; основание -- п. 6 http://wiki.opennet.ru/ForumHelp (с каковыми правилами настоятельно рекомендую ознакомиться).
PPS: с обсуждением модерирования -- к администрации.
>> чем?
> Тем, что есть и работает.да да. а как же непреклонность к проектам которые заставляют подписывать передачу прав на присланный патч? или как только нужно самому то можно и прогнуться.. ?
Мы больше не заставляем контрибьюторов подписывать передачу прав. Если у вас есть патчи, которые вы хотите добавить, то присылайте в devel@. http://openvz.org/Mailing_lists
не прошло и 10 лет. Нет уж - спасибо.
> а как же непреклонность к проектам которые заставляют подписывать передачу
> прав на присланный патч?Вы о чём? Я видел такую бумагу, например, от проекта GNU -- а патчи таким проектам слать не доводилось.
>> а как же непреклонность к проектам которые заставляют подписывать передачу
>> прав на присланный патч?
> Вы о чём? Я видел такую бумагу, например, от проекта GNU
> -- а патчи таким проектам слать не доводилось.о практике со стороны OpenVZ. За которую все тут поливали грязью Oracle, Sun, MySQL и тп..
двуличность?
>> Вы о чём?
> всеТак ищите тех "всех" и их спрашивайте; а у меня к Oracle и упокоенному им Sun претензии изрядно другого характера, если что.
что не мешает вам поддерживать всех дружков которые так себя ведут.
как там arisu? забанили его или дружку можно оскорблять всех других?
> как там arisu? забанили его или дружку можно оскорблять всех других?Зачислить arisu в друзья Шигорина... вроде, грибной сезон еще не начался?!
> Тем, что есть и работает.Работает. Только мороки с ним много, по поводу чего на него многие откровенно положили с прибором. И нет, согласно ФЭДу, то что в альте таки поддерживается - это не заслуга альта, а недоработка ||.
нравится как он красиво обрезает пользователям функционал - лишь бы не конфликтовать с платной версией ?
Функционал - математическая функция. Разве его запрещают использовать в OpenVZ (а также во всяких KVM, Xen, qemu, VmWare, LXC, Doker, FreeBSD jail и даже в богомерзком HyperV)?Если же вы невежда и совершили такое чудовищное количество ошибок в слове функциональность, то поделитесь списком архиважной функциональности, которая есть в Virtuozzo и нету в OpenVZ?
учет трафика, шейпер на интерфейсы.
io limit открыт был только недавно.хватит или еще?
> учет трафика,Прекрасно работает для venetX интерфейсов, по крайней мере заббиксовский net.if. без проблем это делает
> шейпер на интерфейсы.
Никогда не сталкивался с необходимостью этого, но, думаю, это легко делается на хостноде теми же средствами, что используются вне виртуализации.
> io limit открыт был только недавно.
Не так уж недавно, три года назад. И ведь открыт же.
Всё вышеперечисленное, между прочим, интересно только для части целевой аудитории OpenVZ - хостеров, а те, обычно, в любом случае обвешают виртуализацию кучей своих костылей, которые будут делать то же самое.
>> учет трафика,
> Прекрасно работает для venetX интерфейсов, по крайней мере заббиксовский net.if. без проблем
> это делаети при этом не считается трафик который идет от одной виртуалки на другую?
>> шейпер на интерфейсы.
> Никогда не сталкивался с необходимостью этого, но, думаю, это легко делается на
> хостноде теми же средствами, что используются вне виртуализации.Когда-то OpenVZ отклонил это - сказав что конфликтует с платным функционалом.
>> io limit открыт был только недавно.
> Не так уж недавно, три года назад. И ведь открыт же.Каких 3 года ? харе врать то.. пол года назад. не больше. А существовал сколько?
> и при этом не считается трафик который идет от одной виртуалки на другую?Прям заинтриговали. Вы часом не из тех, кто мечтает биллить трафик по lo?
тот кто мечтает не считать такой трафик, в отличии от предыдущего автора.
А оно вот не получается.
> Каких 3 года ? харе врать то.. пол года назад. не больше. А существовал сколько?https://openvz.org/I/O_limits
Обратите внимание на дату последнего редактирования статьи.
Никак не могу понять, где вы обитаете, На Марсе уже больше года с тех пор прошло, на Юпитере и квартал не прошёл. Судя по всему, вы где-то в поясе астероидов живёте? Чудовищный пинг вам не мешает?
>> Каких 3 года ? харе врать то.. пол года назад. не больше. А существовал сколько?
> https://openvz.org/I/O_limits
> Обратите внимание на дату последнего редактирования статьи.
> Никак не могу понять, где вы обитаете, На Марсе уже больше года
> с тех пор прошло, на Юпитере и квартал не прошёл. Судя
> по всему, вы где-то в поясе астероидов живёте? Чудовищный пинг вам
> не мешает?считать то умеете? декабрь 13го (реально появилось позже) - начало 15. 15-14 у вас равно 3?
поздравляю - совравши..
К сожалению слово "Функционал" уже приелось в мире ПО в значении "функциональность". Тут бесполезно спорить. Язык - штука живая. Пора в словари правки вносить, и жить с этим спокойно.
> Ну наконец-то.дождались
Скорее бы ядро новое ядро в продакшн выпустили.
вот это конечно крутая маскировка авторства там:https://src.openvz.org/projects/OVZ/repos/prlctl/browse/src/...
оффтоп:
Классический пример вреда отступов табами. Пусть фанатики разъяснят, как здесь настроить, что бы не плыло.
У нас не было задачи вычистить авторство из кода.
первая доза бесплатно!
Чуваки думают медленно, но правильно. Успехов, чо. Мы, правда, уже на lxc переехали, но как оно из пелёнок вырастет - попробую, чисто из квасного патриотизма :)
> Мы, правда, уже на lxc переехали, но как оно из пелёнок вырастетБа, lxc уже выросло из пелёнок? Мы-то применяли, но для весьма специфической задачи, где весь код в слотах был тоже доверенный. И то обвязку сами рисовали.
> Ба, lxc уже выросло из пелёнок?OVZ в силу специфичной политики многие просто списали в утиль.
Он просто неудобен для почти всего кроме массовых хостингов. И чрезмерно интрузивный. Диктовать какие кернелы использовать? До такой бор3ости даже проприерасы типа нвидий не докатываются...
Есть вполне объективные причины использовать своё ядро.Как устроена разработка функциональности OpenVZ/Virtuozzo:
мы берем ядро RHEL (текущая версия 6, в разработке RHEL7) и портируем на это ядро свои патчи. Параллельно разрабатываем новую функциональность для контейнеров, которая нужна нашим пользователям. Процесс принятия патчей в апстрим очень долгий, потому что обсуждение может проходить в несколько итераций и во время обсуждения приходиться переписывать код. Поэтому мы новый код разрабатываем у себя в репозитории и как только появляется возможность пытаемся отдать наши патчи в апстрим. Вот на этом графике видно количество патчей, которые мы отдали в ванильное ядро - http://openvz.org/File:Kernel_patches_stats.pngВ нашем понимании, идеальное светлое будущее -- это когда OpenVZ патч к ядру будет нулевого размера, то есть мы хотим, чтобы вся функциональность, которая есть в OpenVZ, появилась в ванильном ядре. Когда это наступит? Я боюсь, что никогда, ибо мир неидеален. Но если, скажем, в ванилле будет 60 или 80% нашей функциональности -- я буду счастлив (сейчас там примерно 20-30%, точнее сложно сказать).
Как следствие, все последние разработки для контейнеров есть только в наших ядрах и в апстрим попадают с опозданием. Вы ведь RedHat не упрекаете в том, что они используют свои ядра, а не ванильные? Если вам нужен стабильный, надежный дистрибутив с поддержкой, то вы просто берете и используете RHEL, а не рассказываете всем какая плохая компания RedHat.
> Он просто неудобен для почти всего кроме массовых хостингов.
расскажите об этом нашим пользователям (Travis CI, Atlassian, Яндекс, Pixar).
> Есть вполне объективные причины использовать своё ядро.Они объективны только для разработчиков OVZ. А для всех остальных это просто куча неудобных им бестолковостей.
> Как устроена разработка функциональности OpenVZ/Virtuozzo:
> мы берем ядро RHEL (текущая версия 6, в разработке RHEL7) и портируем
> на это ядро свои патчи.Это как раз именно то за что я и не жалую OVZ нынче.
1) Если вы еще не заметили, рыночная доля шапки на серверах - не такая уж огромная. Шапка целит в узкий сегмент энтерпрайзов. Там мало кастомеров но с них приличная маржа. Остальное шапке малоинтересно. За это шапка малоинтересна всем остальным.
2) В остальных дистрах эти ядра даром никому не упали. И мало кто хочет это майнтайнить. Поэтому прстого способа воспользоваться технологией - нет.
3) Я не очень понимаю кто и как саппортит такие ядра. По сути у меня есть ощущение что в общем случае ответ - "никто и никак". В майнлайне с такими ядрами пошлют, а альтернативным центром компетенции по ядру линукса кроме них с большим скрипом можно посчитать шапку.
4) А вон там куча серверов на дебиане и убунте. Им ваши редхатовские кернелы - ортогональны. Вы им что имеете предложить? Ничего? А, ну ок. Тогда с нашей стороны будет большой спрос на какую-то более вменяемо сделанную замену.> которая нужна нашим пользователям. Процесс принятия патчей в апстрим очень долгий,
А древние кернелы от какого-то там редхата - просто мерзость. А куда на такой кернел вообще баги репортить? И кому? И на машине разработчика такому антику делать нечего. А вот лично мне линух нравится за то что под ним удобно разрабатывать: отпрототипил решение на десктопнике или ноутбучике у разработчика и вкатил на сервак побольше. Оно отмасштабировалось по ресурсам. А если масштабирование не надо - так порезать хост на контейнеры или виртуалки как раз и напрашивается. Чтобы там поселить пачку таких решений. Нo OVZ для этого не подойдет. Потому что разработчики на него будут смотреть волком - неудобная технология.
> в апстрим. Вот на этом графике видно количество патчей, которые мы
> отдали в ванильное ядро - http://openvz.org/File:Kernel_patches_stats.png"Менеджер румяным ч... графики чертил по стенам" (c). В смысле, патчи - это прекрасно. Но вот лично для себя я не вижу как я мог бы удобно пользоваться вашими семействами технологий. Ставить себе на машины где я разрабатываю окаменелый трэш имени редхата я не разу не планирую. Стало быть, быстренько собрать действующий макет - превращается в большой кус гемора на ровном месте. Возникает нефиговый спрос на решение где этого гемора не будет. И как видите, их прибавляется и они сразу на старте срубают неиллюзорную популярность.
> В нашем понимании, идеальное светлое будущее -- это когда OpenVZ патч к
> ядру будет нулевого размера,Вот и в моем тоже. Вот только я не живу вечно (видели картинку скелета на лавочке?). И ждать вашего светлого будущего, попутно погрызая непотребный кактус - мне не очень доставляет. И при всем уважении к хорошему управлению ресурсами в OVZ, имею заметить что он просто неудобен для всех кроме махровых хостеров, которые могут позволить себе обпрыг этих дурных грабель. И то - кастомерам оных не очень нравятся множественные дурные ограничения (в тои числе отсутствие ряда модулей в древних ядрах). По поводу чего, как я смотрю, нынче полно хостеров стали продавать KVMные виртуалки по цене грязи под ногами. И с моей стороны KVM виртуалка предпочтительнее, т.к. меньше грабель заезжает при настройке рукояткой в лоб.
> ванилле будет 60 или 80% нашей функциональности -- я буду счастлив
Ну а я поищу себе другое семейство технологий. Которое работает с обычными дистрами и обычными ядрами.
> (сейчас там примерно 20-30%, точнее сложно сказать).
ИМХО закончится это тем что шапка под давлением энтерпрайзных кастомеров запилит все это в майнлайн и ширпотребный системд. Для всех. А сверху будут накатываться шапочные же энтерпрайзные управляторы, для совсем толстых энтерпрайзников. И они будут "как родное" для большинства линуксных админов, просто некий доапгрейд уже знакомых технологий.
> в том, что они используют свои ядра, а не ванильные?
Мне редхат не нравится этим моментом и я им не пользуюсь. Де факто, редхатом нынче пользуется только небольшое количество энтерпрайзных кастомеров. Но они богатые буратины с большими инсталляциями. Только редхат сам не против их окучать, без всяких ||. А админы там тоже человеки. И им будет удобнее если система будет уметь подобные вещи сразу. Фичи в системд по части деплоя образов, регистрации контейнеров и виртуалок - как бы намекают что в шапке про это догадываются.
При том там задумка намного перспективнее: оно нормально интегрируется с хост системой, н основе имеющихся штатно тулсей. Гуест может логгить в журнал хоста, он виден штатными системными утилсами, которыми админы научатся рулить постепенно.
> и используете RHEL, а не рассказываете всем какая плохая компания RedHat.
Мне RHEL ни к чему. А редхат не плохая компания. Но своеобразная. Как и дистры. На мое мнение у них например совершенно гадостный пакетный менеджер. Ну и на десктопах они "для галочки". И в целом по совокупности - я их дистрами пользоваться не желаю. И использую в основном дебианы и убунты. Они работают. И на них я могу на десктопе или ноуте отпрототипиться а потом лить решение на крЮтой могучий сервак, буквально совсем без изменений. Это удобно и быстро. И к чему-то такому все и пытаются прийти.
Ну а разработчиков виртуализатора, смеющих диктовать мне какие ядра и дистры использовать - я понятно на каком месте вертел. Со своей стороны обещаю использовать какие-нибудь другие технологии.
> расскажите об этом нашим пользователям (Travis CI, Atlassian, Яндекс, Pixar).
Зачем? Пользователи голосуют ногами. И кстати IIRC яндекс где-то там убунты использовал. А так - ну как бы удачи вам с таким подходом к делу. Но зато для себя я теперь уверен что очень правильно прикинул что от OVZ лучше отказаться везде где получится. Слушать вот такой булшит от разработчиков я совершенно не желаю.
>> Есть вполне объективные причины использовать своё ядро.
> Они объективны только для разработчиков OVZ. А для всех остальных это просто
> куча неудобных им бестолковостей.Вы написали очень много слов с упреками в сторону разработчиков OpenVZ. Но для меня так и осталось непонятным: чем вас конкретно не устраивают ядра RHEL? Какие лично для вас неудобства в использовании стороннего ядра вместо ядра из дистрибутива?
>> Как устроена разработка функциональности OpenVZ/Virtuozzo:
>> мы берем ядро RHEL (текущая версия 6, в разработке RHEL7) и портируем
>> на это ядро свои патчи.
> 2) В остальных дистрах эти ядра даром никому не упали. И мало
> кто хочет это майнтайнить. Поэтому прстого способа воспользоваться технологией - нет.Это так (http://www.opennet.me/opennews/art.shtml?num=42369). Возможно потому что у них нет таких клиентов, которые есть у RedHat, которые просто используют одну инсталляцию и им не нужны новые ядра. Им нужно только исправление багов и проблем с безопасностью. Серверный рынок более консервативный, чем десктопный рынок.
> 4) А вон там куча серверов на дебиане и убунте. Им ваши
> редхатовские кернелы - ортогональны. Вы им что имеете предложить? Ничего? А,
> ну ок. Тогда с нашей стороны будет большой спрос на какую-то
> более вменяемо сделанную замену.В OpenVZ собираются ядра и под дебиан -
https://openvz.org/Download/kernel/rhel6/042stab108.2#DEBs> Но вот лично для себя я не вижу как
> я мог бы удобно пользоваться вашими семействами технологий. Ставить себе на
> машины где я разрабатываю окаменелый трэш имени редхата я не разу не планирую.А вы расскажите о своих сценариях использования виртуализации. В ваших ответах очень мало конкретики и деталей.
> А вы расскажите о своих сценариях использования виртуализации.Это User294, у него десктопные -- рассказывал уж.
> В ваших ответах очень мало конкретики и деталей.
Человек предпочитает bleeding edge и тратит время на объяснение непонятно кому, почему это диаметрально противоположно серверсайду...
Возможно, стоит где-то на сайте проекта завести страничку о том, чем отличается ovz от других систем контейнеризации/виртуализации и там же понятно объяснить, кто "не ваш клиент".
ничем - только качеством кода.. в худшую сторону.
из репозитория EL7 based.138e2b3 dummy: add dummy modules for service vz init script
ea54119 vzstat: port vzstat module from rh6
cd8b961 vzlist: return second pid in container's namespace
9ac9359 vzlist: fix get_vepids function
c3fd310 vzlist: fix obvious compilation errors
1de44af vzlist: add vzlist from 2.6.32-x as is
507e3e2 vznetstat: don't use vehooks
9ebbeab vznetstat: fix compilation
73391e3 vznetstat: apply vznetstat patches from 2.6.32 as isне страшно код разработчиков которые комитят даже без проверки сборки использовать?
> ничем - только качеством кода.. в худшую сторону.Вы гоните. Каждый понимающий в ядерном коде человек может оценить вклад ovz-шников в исправление ядра в целом, совершенно не по их специфической части. Это и дырки, и "просто" баги.
> не страшно код разработчиков которые комитят даже без проверки сборки использовать?
Вы, очевидно, ещё и лицемерите либо никогда не сталкивались с процессом выпуска софта.
Да, совсем хороший процесс позволяет устроить базовый regression testing _каждого_ коммита до его публикации даже на внутренних ресурсах (после чего --amend запрещён). При этом бывают ляпы такого характера, когда вручную проверять кажется бессмысленным в силу тривиальности, но при этом чего-то да не учёл, как выясняется при следующей же проверке.
> Вы гоните. Каждый понимающий в ядерном коде человек может оценить вклад ovz-шников в исправление ядра в целом, совершенно не по их специфической части. Это и дырки, и "просто" баги.и не так уж многое они исправили. Достаточно посмотреть changelog ядра. Не стыдно подлизывать многолетним нарушителям GPL ?
> Вы, очевидно, ещё и лицемерите либо никогда не сталкивались с процессом выпуска софта.
> Да, совсем хороший процесс позволяет устроить базовый regression testing _каждого_ коммита до его публикации даже на внутренних ресурсах (после чего --amend запрещён).Теперь я понимаю почему T-Platform умер. С такими познаниям в разработке софта.. Нормальный код должен быть проверен - как по компилируемости, так и на отсутствие явных ошибок (и не явных тоже).
Как пример рассмотрим то как идет в lkml - где без ACK или reviewed-by никто не примет твой комит.
Но видимо такие базовые правила не знакомы как Alt, T-Platform (судя по вашей реакции) - так и разработчикам OpenVZ (судя по коду в репозитории). Раз такие великие разработчики комитят код не проверяя есть там ошибки.. нет ошибок.. не компилируется - ну и ладно. Или хотите сказать что их великие админы не в состоянии настроить gerrit + jenkins ?! и о чудо - никто не даст сделать merge кода в репозиторий если патч не собирается..
Я уж не беру ошибку по которой в репозитарии с EL не работает tcp, постоянно сыпятся ошибки о превышении лимитов.PS. не надо позориться :-)
> на отсутствие явных ошибок (и не явных тоже).Вот пусть заодно господа из || расскажут - когда в последний раз их ядро сканили коверити? Манлайн нынче им вроде как в режиме continious окучивается.
> Теперь я понимаю почему T-Platform умер. С такими познаниям в разработке софта..Он, как ни странно, не умер.
> Как пример рассмотрим то как идет в lkml
Прям-таки все всё сыплют прям в lkml?
> Но видимо такие базовые правила не знакомы как Alt, T-Platform (судя по
> вашей реакции) - так и разработчикам OpenVZ (судя по коду в репозитории)....но на всех вышеперечисленных найдётся казахстанский гуру, который на опеннетике в половине случаев пишет в нетрезвом виде, судя по броскам между хамством и меланхолией.
> PS. не надо позориться :-)
Ну так и не позорьтесь, не сопляк уже.
>> Теперь я понимаю почему T-Platform умер. С такими познаниям в разработке софта..
> Он, как ни странно, не умер.умер.. умер.. не будем ворошить труп :)
>> Как пример рассмотрим то как идет в lkml
> Прям-таки все всё сыплют прям в lkml?Как не странно :) и в ext4-devel тоже.
>> Но видимо такие базовые правила не знакомы как Alt, T-Platform (судя по
>> вашей реакции) - так и разработчикам OpenVZ (судя по коду в репозитории).
> ...но на всех вышеперечисленных найдётся казахстанский гуру, который на опеннетике в половине
> случаев пишет в нетрезвом виде, судя по броскам между хамством и
> меланхолией.ООО. ну спасибо хоть не песнь о ботах MS ;-) Но как я сказал мне жаль ваших учеников (вы же там кого-то учите?) и ваших работодателей. Которые получили не компетентного сотрудника - который не понимает минимальных требований по качеству кода. Можно пропустить логическую ошибку - но не проверить что твой код собирается, это уж попахивает пофигизмом и наплевательским отношением к качеству кода.
>> PS. не надо позориться :-)
> Ну так и не позорьтесь, не сопляк уже.смешной вы. Жаль мне ваших работодателей. А о выпуске серьезных проектов я знаю не по наслышке.
Только сейчас заметил вашу оговорку :)> Вы, очевидно, ещё и лицемерите либо никогда не сталкивались с процессом выпуска софта.
> Да, совсем хороший процесс позволяет устроить базовый regression testing _каждого_ коммита до его публикации даже на внутренних ресурсах (после чего --amend запрещён).То есть вы сами расписались в том что хороший процесс разработки у OpenVZ не получился, они не в состоянии его создать. Браво! А
> То есть вы сами расписались в том что хороший процесс разработки у
> OpenVZ не получился, они не в состоянии его создать.Я-то как раз не в курсе, как именно организована разработка OpenVZ, но видел довольно разные варианты и что-то могу оценить по косвенным признакам. Равно как и балаболов.
PS: и нет, это была не оговорка, а написанное в полном сознании.
Тогда мне жаль ваших работодателей и учеников.
Чему может научить такой специалист как вы? если вы минимальные требования к качеству кода и процессу разработки считаете чем-то запредельным.
> Чему может научить такой специалист как вы?А я и не учу писать код или организовывать его разработку, хотя участвовать в создании инфраструктуры для этого с нуля доводилось.
Собственно, покажите-ка свои прелестные коммиты, а я в них палочкой потыкаю.
Ага. щас :) могу лишь сказать - что благодаря моему патчу в OpenVZ появился udev support. swsoft тогда возился с 2.4 ядром и потребности в колбасе не было.
> Ага. щас :)Ну ква. :)
> могу лишь сказать - что благодаря моему патчу в OpenVZ появился udev support.
Спасибо!
> Вы гоните. Каждый понимающий в ядерном коде человек может оценить вклад
> ovz-шников в исправление ядра в целом,Кстати если что - тут кроме 294 еще какой-то аноним плевался.
А 294 имеет сообщить что вся эта дребедень с кастомнми ядрами имеет свойство заканчиваеться так как и должна. Однажды я засек у себя руткит, явно прилетевший на хост через прошибленный OVZшный контейнер. К своему большому неудовольствию я не смог найти код руткита. Он как-то очень уж хорошо прятался, а времени его сильно изучать не было. Но будучи "охотником за привидениями" я довольно быстро нашел аномалии в syscalls: все-таки интрузивому системному коду сложно прятаться на 100%.
Спасибо, но что-то мне не хочеся после этого древние самопальные ядра, поддерживаемые хрензнает кем хрензнает как. Пусть у них там хоть вагон заслуг в разработке чего угодно. И вообще, я немнго поинтересовался и судя по всему - блэкхэты этот серверный стабилизец долбят чартерными рейсами просто. Даже тут на опеннете было немеряно новостей когда редхат упортировал себе очередные баги. Которые в майнлайне потом починили а в редхате оно так и висело, пока не начали гасить эксплойтами крупным оптом. Мне такое счастье не надо.
> совершенно не по их специфической части. Это и дырки, и "просто" баги.
Да, вы правы: этого в VZшных ядрах - хватает. Имел неудовольствие проверить этот факт, получив расфигаченый хост. Хостеры на VZ как я понимаю в массе своей вообще просто кладут болт на такие вещи, на радость блэкхэтам :)
> Да, совсем хороший процесс позволяет устроить базовый regression testing _каждого_
Я видел как блэкхэты устраивают regression testing этому трэшу от редхата. Добавки что-то не хочется.
там проблема не в ядре от шапки. а в том что товарищи из OpenVZ выпускают обновления - весьма и весьма не спешно. Через недели после выхода ядра в шапке.
> там проблема не в ядре от шапки. а в том что товарищи
> из OpenVZ выпускают обновления - весьма и весьма не спешно.Проблема в том что в целом вся эта цепочка - КЛАСТЕРФАК. В майнлайне посадят плюху. По мере обнаружения - заштопают. Но шапка может уже успеть бэкпортнуть :) лажу :) себе в свой Супер Стабилизец. Насколько они дотумкают еще и фикс бэкпортнуть и когда это случится - очень отдельный вопрос. Только недавно был очередной сезон багов, уникальных для красношляпы и деривативов, как раз по этому поводу.
А тут в цепочке появляется еще какой-то народ. У которых компетенции и ресурсов еще поменьше чем у редхата. И которые тормозят ручным тормозом еще дополнительно. А потом еще возникают вопросы - что же вам не нравится во всем этом? Сам блин не понимаю, чего :)
да да. свежую плюху только нарыли в RHEL6.
если в условиях нехватки памяти вызвать fiemap на ext4 - получим deadlock. в 2.6.32 еще нету, 2.6.38 есть, в 3.5-3.10 уже нету. шапка бэкпортнула это откуда-то и имеем что имеем. в 3.10 изменено на другой механизм работы и в тихую убрана ошибка.А некоторым потом разбираться - чего это ext4 стоит раком под нагрузкой.
> Это User294, у него десктопные -- рассказывал уж.У меня на самом деле очень разные. И мне неудобно пользоваться разными семействами технологий в разных закоулках. И я заметил что не я такой один. Посмотрев как разрабатывают софт - я заметил что таковы очень многие разработчики. Linux хорош как раз тем что там можно использовать более-менее одинаковые технологии и на фазе разработки и в продакшне. За это пингвина очень любят разработчики всех мастей. В том числе и вебдевы.
А кто этого не понял - сам себе злобный баклан. Останется по популярности на уровне *bsd и прочих солярисов как очередное server-only. Куда и дорога. Если || хотят себе такой участи - флаг им в руки и барабан на шею. А когда разработчик может у себя дома в докере опенврт билдануть для какой-нибудь мыльницы, он потом и в продакшн докера сосватает. Как знакомый инструмент.
> Человек предпочитает bleeding edge
Человек предпочитает reuse знаний и собственное удобство. Если что - я только недавно последние серваки с убунтой 10.04 заапдейтил, когда сапопикал начали обещать репы совсем закрыть. Так что иногда я и понекромансить умею, если это экономит усилия (но о темной стороне лучше молчать в тряпочку, тем более что я не фанат некромансии).
> и тратит время на объяснение непонятно кому, почему
> это диаметрально противоположно серверсайду...По-моему такие подходы диаметрально противоположны здравому смыслу. А серверасайд - я уже видел что случилось с server-only бздами и *никсами. Если ovz метит туда же - окей, но я как-то предпочитаю вовремя отманеврировать чем неспешно тонуть с очередным титаником технологий.
> "не ваш клиент".
Судя по тому что я наблюдаю, || очень доступно объяснили это толпе народа. И да, я тоже теперь совершенно уверен: я - совершенно точно не их клиент. И сверну какое либо использование технологий от этих лиц, т.к. уже понятно что если хочется нормальное администрирование и разработку без проблем - это все совершенно точно не про OVZ/Virtuozzo.
> Вы написали очень много слов с упреками в сторону разработчиков OpenVZ. Но
> для меня так и осталось непонятным: чем вас конкретно не устраивают ядра RHEL?Наверное, тем что они в половине случаев ортогональны моим желаниям и предпочтениям.
> Какие лично для вас неудобства в использовании стороннего ядра
> вместо ядра из дистрибутива?1) Отсутствие по дефолту.
2) Непонятки с оперативностью и качеством поддержки.
3) Непригодность такого подхода для ряда конфигураций (например, рабочей машины разработчика).Для лично меня по прошлому опыту - сторонние модули и ядра являются крайне нежелательными элементами системы. Мне нравится рабочий процесс у майнлана. Я могу понять дефолтное ядро в дистре. Но что-то сверх того - просто за пределами моей толерантности.
> только исправление багов и проблем с безопасностью. Серверный рынок более
> консервативный, чем десктопный рынок.А потом начинается очень забавное удивление, когда какой-то глючный и дырявый хипстерский докер вдруг в два счета отжимает полрынка на ровном месте и показывает "как это надо было на самом деле".
> В OpenVZ собираются ядра и под дебиан -
Прекрасно, но в общем случае я не хочу никакие левые побочные ядра. Ни на сервере, ни на десктопе, ни где там еще. Мне нравится как люди работают в майнлайне. На остальных это нравится - распостраняется сильно местами и с большими оговорками, как максимум - на дистроклепателей (я считаю что они могут майнтайнить ядро как и остальной софт и что это не есть логически противоречивое действо). И да, я при этом ожидаю некий набор политик например по части секурити и прочая. А тут какие-то || сильно сбоку и рассказами что туда не ходи, сюда ходи. Лучше не бывает.
> А вы расскажите о своих сценариях использования виртуализации.
На самом деле самые разные. Начиная от серверов и заканчивая отпиловкой сервисов на десктопе или в эмбедовке в целях изоляции или формирования кастомной сборочницы. Я не вижу какого дьявола так должно быть нельзя. Для этого нет никаких реальных причин. Ну в смысле у || они есть, называемые "собственной бестолковостью" и "переклином на одном юзкейсе". Но мне совсем не хочется пожизненно делать из паралесовских тараканов в голове свои проблемы.
ИМХО же те кто сможет все это удачно объединить и отмасштабирвать - и получат EPIC WIN. Вот лично я - буду работать с их технологиями. И применять в каждой дырке. Потому что это ИМХО должно быть вот так. И как я вижу - к этому все идет.
Старый хлам выбросить решили?
