На проходящей в эти дни в Нью Йорке конференции Debconf10 анонсирован (http://lists.debian.org/debian-announce/2010/msg00009.html) выход на финишную прямую подготовки грядущего стабильного релиза Debian 6.0 "Squeeze". Состоялась полная заморозка пакетной базы, означающая, что отныне добавление новых возможностей остановлено и все усилия разработчиков будут сфокусированы на исправление остающихся блокирующих финальный релиз ошибок, которых остается (http://bugs.debian.org/release-critical/) еще более 500.Напомню, что в рамках инициативы (http://www.opennet.me/opennews/art.shtml?num=22794) по переходу на фиксированный по времени график подготовки релизов, первоначальный план предусматривал заморозку пакетной базы в декабре 2009 года. В конце осени заморозка пакетов была перенесена (http://www.opennet.me/opennews/art.shtml?num=24393) на март, при этом разработчики не теряли надежду выпустить финальный релиз в июле, накануне конференции DebConf. В начале апреля оставалось слишком ...
URL: http://lists.debian.org/debian-announce/2010/msg00009.html
Новость: http://www.opennet.me/opennews/art.shtml?num=27544
>В базовом ядре оставлена поддержка организации изолированных контейнеров на базе технологии OpenVZ.а из убунты OpenVZ убрали. кто знает, напишите почему.
>а из убунты OpenVZ убрали. кто знает, напишите почему.Проектом OpenVZ официально считаются стабильными только ядра, на основе ядер RHEL 4 и RHEL 5.
"Свежие" же, более младшие, чем 2.6.18 EL-ветки ядра стабильными не считаются, и имеют "обрезанный" функционал (например, убирают CPULIMIT)
На самом деле, все относительно, так как RHEL 5.5 вполне современное ядро (конечно, некоторых вещей, вроде Cgroups там нет, но жить это не мешает).Ubuntu и Debian используют "пионерские", и не очень стабильные, с точки зрения проекта OVZ, ядра.
Вероятно, столкнувшись с большим количеством проблем, OVZ и дропнули в Ubuntu.Добавлю, что в больших инсталляциях OpenVZ и Virtuozzo, практически всегда ставится на CentOS, а вот в контейнерах может быть все, что угодно.
>почему
Вероятно, из-за проблем с UDEV: из-за этого же чуть не дропнули в Debian.
спасибо за подробный ответ. все ясно и по делу.
sHaggY_caT - CPULIMIT это же огричение числа ядер на CT ?
> sHaggY_caT - CPULIMIT это же огричение числа ядер на CT ?Нет, то, о чем Вы говорите, это CPUS (причем, учитываются и потоки).
CPULIMIT, это жесткий лимит на количество процессорного времени, удобно комбинировать и с CPUS, и с CPUUNITS (приоритет)
мм, __вроде__бы__ у меня оно есть в 27 ядре . Как проверить ?
>мм, __вроде__бы__ у меня оно есть в 27 ядре . Как проверить
>?vzctl set <VEid> --cpulimit 30 && vzctl exec <VEid> cat /proc/cpuinfo
Какие возможности в каком ядре есть, можно посмотреть в вике на оффсайте. Все возможности есть только в стабильных ядрах.
Сейчас, кстати, добавили в vzctl и последнее RHEL 5-based ядро кучу вкусностей, вроде ядерного NFS внутри контейнера.
Будем надеяться, что теперь и в Ububntu бэк-портируют OpenVZ-ядро. А то в свежем LTS его ещё нет, приходится ютиться на на 8.04 LTS. Лично мне хочется верить в это :)
>Будем надеяться, что теперь и в Ububntu бэк-портируют OpenVZ-ядро. А то в
>свежем LTS его ещё нет, приходится ютиться на на 8.04 LTS.
>Лично мне хочется верить в это :)Лучше поставьте на HN CentOS, а вот в контейнерах разводите любимые убунты :)
Я подумаю, спасибо :)
мдя, нету - показывает реальные ядра
>мдя, нету - показывает реальные ядраНекоторые ставят на Debian OVZ RHEL 5 ядра через alien, говорят, что работает. Но это касалось Lenny...
У меня не дебиан. С Центоса тоже прошлось слезть - он потихонку превращался в помесь rawhide
и слаквари.
Linux first 2.6.27-openvz-kiprensky.1-r1-test x86_64
>У меня не дебиан. С Центоса тоже прошлось слезть - он потихонку
>превращался в помесь rawhide
> и слаквари.
>Linux first 2.6.27-openvz-kiprensky.1-r1-test x86_64На HN лучше вообще стараться не ставить софт, по-возможности, запихивать каждую программу в отдельный контейнер: вполне оправданный подход в случае не виртуализации, а контейнеров... А собирать софт можно и удобно rpmbuild'ом
З.Ы. Fedora на сервере, имхо, зло :)))
ммм, очень вкусный этот дебиан, надо будет поставить
>Код прошивок (firmware) выделен из основного ядра и поставляется отдельно.Имхо, зря: свобода, конечно, хорошо, но вот проблемы с железом (и с установкой на железо) обеспечены...
>Миграция со стандартной системной библиотеки GNU C Library (glibc) на eglibc >2.11 (Embedded GLIBC).
Интересно :), надеюсь, не будет регрессий
>Переход на новую систему инициализации insserv, учитывающую при загрузке >зависимости между init-скриптами и поддерживающую параллельную загрузку >скриптов инициализации, что приводит к заметному уменьшению времени загрузки;
И это, имхо, тоже зря: почему все так хотят закопать старый добрый System V?
> И это, имхо, тоже зря: почему все так хотят закопать старый добрый System V?наверное оно вызывает плохие ассоциации со SCO =)
> И это, имхо, тоже зря: почему все так хотят закопать старый добрый System V?Потому что в XXI веке он уже несколько неактуален. Долго стартует, не умеет рестарт сервисов при падении и их мониторинг, етц. Единственный его плюс - совместимость. Ну по такой логике MS-DOS лучшая система всех времен и народов :) с ней до сих пор совместимы слегка некоторые операционки :)
>е умеет рестарт сервисов при паденииА опция respawn?
>А опция respawn?Вообще да, кстати - в этом месте я ступил :(. Правда толку с такого рестарта не больно то и много: если демон просто повиснет, инит не допрет его перезапустить. Один фиг приходится чем-то еще довесочным это делать, что не прикольно совсем (в идеале система управления демонами должна бы и такое уметь, заменив собой кучи левых костылей). А отсутствие зависимостей старта демонов от событий/готовности железа и последовательный запуск поочередно - весьма тупо для XXI века. И не здорово совсем минуту ждать там где другие за 10 секунд запускаются. На серверах это может и не так важно. А в некоторых других местах зато - очень даже не лишне.
>>Переход на новую систему инициализации insserv, учитывающую при загрузке >зависимости между init-скриптами и поддерживающую параллельную загрузку >скриптов инициализации, что приводит к заметному уменьшению времени загрузки;
>
>И это, имхо, тоже зря: почему все так хотят закопать старый добрый
>System V?В данном случае ее не закапывают, а обеспечивают инвалидной коляской и парой костылей. Видимо автор новости очень спешил и сам не понял, что перевел.
>>Код прошивок (firmware) выделен из основного ядра и поставляется отдельно.
>
>Имхо, зря: свобода, конечно, хорошо, но вот проблемы с железом (и с
>установкой на железо) обеспечены...
>Согласен.С установкой на железо.
Хотя проблема решается использованием к примеру, образа firmware-testing-amd64-netinst.iso.
>>Миграция со стандартной системной библиотеки GNU C Library (glibc) на eglibc >2.11 (Embedded GLIBC).
>
>Интересно :), надеюсь, не будет регрессийда вроде бы как не должно - исходники-то по сути те же
Одному мне показалось, что "Основные особенности будущего релиза" как-то не очень ярко выглядят?
таки релиз вовсе и не яркий. Дебиановцы не рекомендовали обновляться до Squeeze на рабочих машинах, а сразу обновляться с Lenny до семёрки.
Ссылочку на рекомендацию не дадите?...
я не корректно выразился: Дебиановцы не не рекомендовали пропускать Squeeze, а обещали поддержку обновления пятой версии на седьмую.
>Переход на новую систему инициализации insservТеперь у каждого дистра своя система инициализации?
>>Переход на новую систему инициализации insserv
>Теперь у каждого дистра своя система инициализации?Когда в зоопарке только обезьяны, это весело, но быстро надоедает.
>>Переход на новую систему инициализации insserv
>
>Теперь у каждого дистра своя система инициализации?Вообще insserv в SUSE используется вместе с SystemV и ничего, все нормально работает.
Молодцы. Отправил $30.
а поддержка pppoe в инсталлере появится?
> Переход на использование Linux-ядра 2.6.32Блин, 2.6.35 на дворе, они только на 2.6.32 переходят...
Лучше бы проявляли консервативность там, где от этого удобнее - не извращались бы с идентификаторами дисков и скриптами инициализации.
На дворе .35, а в стабильном Debian-е - .32. Какие у _Вас проблемы с этим?
В каждом ядре добавляются новые "фишки", улучшается поддержка железа, исправляются баги. Регрессии конечно тоже бывают, но это поправимо. А вот сидеть на старых ядрах — значит лишиться части новых возможностей свежих ядер.
>> Переход на использование Linux-ядра 2.6.32
>
>Блин, 2.6.35 на дворе, они только на 2.6.32 переходят...это как раз хорошо, т.к. 2.6.32 будет поддерживаться долго. 6й рхел тоже на нём будет
Обновились base-file
cat /etc/debian_version пишет Debian 6.0
>Блин, 2.6.35 на дворе, они только на 2.6.32 переходят...Так они зато это самое ядро ПОЛНОСТЬЮ встроят в систему, а не выпустят полусырой продукт