Комментарии 133
хотел поставить но не как не решалься, сегодня думаю посталю, в честь выхода,
CentOS 5.5 Install Fest обьявляю открытым)
CentOS 5.5 Install Fest обьявляю открытым)
НЛО прилетело и опубликовало эту надпись здесь
неа.
PHP 5.1.6 (cli) (built: Mar 31 2010 02:39:17)
PHP 5.1.6 (cli) (built: Mar 31 2010 02:39:17)
Ну что за какашка, опять 5.3 на ВДС через костыли
откройте для себя репозиторий remi. там вполне юзабельный php 5.3.
может, кто-нибудь подскажет репозиторий с юзабельным ImageMagick 6.5.x?
в реми дибильные зависимости у php 5.3, а точнее у расширений php 5.3, которые тянут за собой кучу конфликтов. php 5.2.9 лежит в testing репозитории, при этом ставится нормально и без конфликтов.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
не тянет. да и раньше вроде бы не тянул — на пока что не обновлённой системе avahi стоит, ImageMagick не стоит.
НЛО прилетело и опубликовало эту надпись здесь
а. ну да, и щас вытягивает. только не сам avahi, а avahi-glib. и не напрямую, а опосредованно, через какие-то гномовые либы по-видимому.
НЛО прилетело и опубликовало эту надпись здесь
Для Ваших задач (lamp/web? ) улучшили дисковый шедуллер cfq.
Нам еще очень интересны улучшения в KVM, и заявленная поддержка Magny-Cours
Нам еще очень интересны улучшения в KVM, и заявленная поддержка Magny-Cours
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ну если Вы админ локалхоста, то да, причин не вижу. А если это продакшн сервер, и не дай бог если их больше одного (или 10-20-30) в кластере, и еще более не дай бог, он не Ваш, а Вы просто его обслуживаете и когда-нибудь можете передать его на обслуживание другому человеку, то ставить из сорцов — это моветон )
Правильный вопрос был бы — почему просто не собрать рпм-ку из исходников самой свежей версии и поддерживать ее. Ну это да… только рпм-ки собирать нужно уметь, и как показывает опыт не все это умеют :)
Правильный вопрос был бы — почему просто не собрать рпм-ку из исходников самой свежей версии и поддерживать ее. Ну это да… только рпм-ки собирать нужно уметь, и как показывает опыт не все это умеют :)
подключите dev.centos.org/centos/5/CentOS-Testing.repo :) там 5.2
Можно, кстати, поставить zend-server ce с PHP 5.2 или 5.3 и наслаждаться. Их сборка очень хороша по производительности.
сегодня обновил на двух серверах, полёт нормальный. ночью ещё на одном обновлю =)
отвечу по-армейски: «Ура! Ура! Ура-а-а!»
господа, а если не сложно — расскажите чем этот дистрибутив заслужил столько внимания? в последнее время только о нём и речь. даже с утра скачал 5.4 что бы посмотреть, а тут уже обновление :)
НЛО прилетело и опубликовало эту надпись здесь
если и изучать какой то серверный дистриб линукса так это центос или убунту, все остальные не так часто встречаются.Эй! А как же Debian?
а он ничем не отличается от убунты.
Чо вы сразу на убунту налетели??
Как по мне, убунту не подходит как сервер, а вот дебиан в самый раз.
Помнится както заказывал себе VDS с убунтой… Вот я и нахватался глюков. Там столько древних пакетов было… А собирать из сорцов на ВДС проблематично.
Юзаю дебиан 5 stable
Как по мне, убунту не подходит как сервер, а вот дебиан в самый раз.
Помнится както заказывал себе VDS с убунтой… Вот я и нахватался глюков. Там столько древних пакетов было… А собирать из сорцов на ВДС проблематично.
Юзаю дебиан 5 stable
НЛО прилетело и опубликовало эту надпись здесь
спасибо, я просто действительно часто встречал упоминание CentOS именно здесь, на хабре, а волею судеб сложилось так что свой linux way я начал с Gentoo :)
кому может и ура, а мне пофиг )
ядро все еще 2.6.18?
НЛО прилетело и опубликовало эту надпись здесь
да, с ок. 5000 патчами :) 2.6.32 ожидется в rhel/centos 6
а счетчики для таких программ как iotop когда портируют?
НЛО прилетело и опубликовало эту надпись здесь
iotop нужен для анализа активности ввода-вывода в случае если программ масса, а не только mysql. могли бы и погуглить.
На RHEL5 прекрасно, для неосиливших родные средства вроде SystemTap, работает юзерофильный atop.
А статистику и развернутый анализ мы, например, собираем Zabbix.
И еще раз, не нужно подходить с Debian-way к другой платформе, на RH нужно использовать правильные для платформы инструменты, читать документацию!
Представьте себе махрового Гентушника, который поставил в первый раз в жизни Debian, и все его злит, и USE флагов нет, и компилить не советуют, и куча бинарей собрана как-то странно, и тут он узнает о существовании apt-build и m-a.
Догадываетесь, как погравшись с этими инструментами, он будет троллить среди Debian-юзеров про USE-флаги, и о том, какое Debian уг?
Потрудитесь сначала, пожалуйста, разобраться в том, что хаите, так как некрасиво получается, и смешно :(
А статистику и развернутый анализ мы, например, собираем Zabbix.
И еще раз, не нужно подходить с Debian-way к другой платформе, на RH нужно использовать правильные для платформы инструменты, читать документацию!
Представьте себе махрового Гентушника, который поставил в первый раз в жизни Debian, и все его злит, и USE флагов нет, и компилить не советуют, и куча бинарей собрана как-то странно, и тут он узнает о существовании apt-build и m-a.
Догадываетесь, как погравшись с этими инструментами, он будет троллить среди Debian-юзеров про USE-флаги, и о том, какое Debian уг?
Потрудитесь сначала, пожалуйста, разобраться в том, что хаите, так как некрасиво получается, и смешно :(
Извините, это больше написано не Вам, а fakedream
спасибо за классную утилиту atop :)
так и что? где возможности мониторинга по процессам?
Тут акцент не на том, что Centos другой, а на том, что в он успел отстать от всех остальных линуксов, даже несмотря на уйму патчей.
Тут акцент не на том, что Centos другой, а на том, что в он успел отстать от всех остальных линуксов, даже несмотря на уйму патчей.
atop — Вам же сказали
Посмотрела Ваши сообщения, извините, взъелась зря, у Вас совсем не предвзятое мнение…
Я что-то не понял. Сначала вы соглашаетесь что iotop не работает, а теперь утверждаете, что ее заменяет atop?
Это не так. Программа то есть, но нужные возможности там не работают: жмем D и видим No disk-activity figures available; request ignored!
Так, по крайней мере, в моем тестовом centos5.3
Это не так. Программа то есть, но нужные возможности там не работают: жмем D и видим No disk-activity figures available; request ignored!
Так, по крайней мере, в моем тестовом centos5.3
хм… очень странно. у меня при нажатии на a (выводит все процессы), а затем D (сортирует по обращениям к диску) показывает количество обращений в процентах. Этого мне достаточно, чтобы увидеть, кто вызывает io wait.
# uname -r
2.6.18-164.6.1.el5PAE
# uname -r
2.6.18-164.6.1.el5PAE
черт… фрибсдшная привычка. забыл релиз
# cat /etc/issue.net
CentOS release 5.4 (Final)
Kernel \r on an \m
:)
# cat /etc/issue.net
CentOS release 5.4 (Final)
Kernel \r on an \m
:)
dag.wieers.com/blog/red-hat-backported-io-accounting-to-rhel5
теперь понятно. per process io accounting появилось только в 5.4
теперь понятно. per process io accounting появилось только в 5.4
6-ая ветка уже, практически, зарелизилась. В свое время, к выходу Lenny, в Etch был ну просто очень боянистый софт, и без всяких бэкпортов,
Все хорошо, а будет еще лучше :)
Все хорошо, а будет еще лучше :)
НЛО прилетело и опубликовало эту надпись здесь
ну например для того, чтобы например вывести в Input/Output top rhel5/centos5 для процессов нужно очень долго прыгать вокруг сервера с бубном.
с iotop да, засада :( судя по всему заработает он к rhel 6
НЛО прилетело и опубликовало эту надпись здесь
У меня была куча проблем, когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на нем же — пакеты в репозиториях были старючие (ruby, например, был 1.8.5 еще), пришлось кучу всего компилировать и искать по каким-то непонятным сторонним репам (я вообще не тот момент yum-ом пользоваться не умел).
Соответственно, вопрос — чем ЭТО лучше Ubuntu Server?
Соответственно, вопрос — чем ЭТО лучше Ubuntu Server?
НЛО прилетело и опубликовало эту надпись здесь
А в чем Ubuntu Server нестабильна?
Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли, сейчас проблем не наблюдаю. Правда, особо я её и не юзаю — только для работы.
Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли, сейчас проблем не наблюдаю. Правда, особо я её и не юзаю — только для работы.
Или под стабильностью понимается наличие приложений, версии которых были адекватны современным реалиям где-то 2-3 года назад?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Утипути, ну вот, например, vbulletin www.vbulletin.com/faq.php#faq-125
Minimum Requirements: vBulletin is designed to run on every server that has PHP 5.2 or greater
Minimum Requirements: vBulletin is designed to run on every server that has PHP 5.2 or greater
НЛО прилетело и опубликовало эту надпись здесь
Хотела бы без дальнейших холиваров, на которых не хватит кармы(так как новенькая), ответить на Ваши вопросы :)
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
НЛО прилетело и опубликовало эту надпись здесь
Я запускаю сервер 1 раз в дремучем году. Он работает сам, без моего вмешательства до 2014 года. Сам обновляется, сам затыкает «как только выходит обновление». Я гарантированно знаю, что сервисы, запущенные на нем не отвалятся из-за несовместимости ядра, что драйверы из ядра не пропадут, что сервер гарантированно загрузится даже после обновления ядра (он далекооо). Мне нужна стабильность и гарантированная работа, а не цифирки в версии ядра непонятно кому нужные. RHEL 5.5 умеет все соврменное серверное железо и мне насрать, что у меня цифирь в версии ядра меньше, чем в вашем бубунтусервер.
НЛО прилетело и опубликовало эту надпись здесь
Что у вас не работает на PHP 5.1?
Есть такое понятие — совместимость. Если я в 2007м запустил сервер с php софтом, то это обновления _не могут_ сломать совместимость. Если обновлять версии php, python и прочего — все пользователи центоса взвоют от ужаса ибо начнут спонатнно переставать работать написанные «под те» версии php.
А если у меня собрано 5-10 модулей под php (может даже самописных) ручками? Они все отвалятся при смене ABI. А тут собрала один раз и работай спокойно. Твой пхп стабилен и защищен (ибо затычки уязвимостей как-раз бекпортируются все!)
Есть такое понятие — совместимость. Если я в 2007м запустил сервер с php софтом, то это обновления _не могут_ сломать совместимость. Если обновлять версии php, python и прочего — все пользователи центоса взвоют от ужаса ибо начнут спонатнно переставать работать написанные «под те» версии php.
А если у меня собрано 5-10 модулей под php (может даже самописных) ручками? Они все отвалятся при смене ABI. А тут собрала один раз и работай спокойно. Твой пхп стабилен и защищен (ибо затычки уязвимостей как-раз бекпортируются все!)
И что же мешает поставить 5.2 если он так нужен? Выше уже писали, также, как и у всех остальных дистрибутивов, есть ветка testing
кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела
а Red Hat в курсе? =)
вышла beta, релиза не было.
Отвечу по пунктам на примере Ubuntu 10.04
1) Поддержка LTS server до 2015 года — 5 лет
2) Кривые костыли это а не стек приложений, когда весь рабочий софт ставится с левых репозиториев и совсем непонятно кто за него отчечает и будет ли он поддерживатся все врямя жизни дистриба.
3) Debian/Ubuntu отлично развертывается по сети написанием фаила ответов на вопросы конфигуратора. Ставится все полный автоматом, дальше puppet/chef для настройки отдельных приложений.
4) Да согласен, ведро поддерживают дольше. Иногда это нужно, допустим OpenVZ (2.6.18) да и часто бывает, что производительность падает в новых версиях на специфических задачах.
По моему опыту редко когда нужно больше 2-3 лет поддержки. Чаще железо меняется, приложения обновляются и т.п.
1) Поддержка LTS server до 2015 года — 5 лет
2) Кривые костыли это а не стек приложений, когда весь рабочий софт ставится с левых репозиториев и совсем непонятно кто за него отчечает и будет ли он поддерживатся все врямя жизни дистриба.
3) Debian/Ubuntu отлично развертывается по сети написанием фаила ответов на вопросы конфигуратора. Ставится все полный автоматом, дальше puppet/chef для настройки отдельных приложений.
4) Да согласен, ведро поддерживают дольше. Иногда это нужно, допустим OpenVZ (2.6.18) да и часто бывает, что производительность падает в новых версиях на специфических задачах.
По моему опыту редко когда нужно больше 2-3 лет поддержки. Чаще железо меняется, приложения обновляются и т.п.
1. Да, это огромный плюс LTS перед Debian, но есть холиварные моменты, которые озвучивать бы не хотела, так как спровоцирует бесконечный и оффтопичный флейм, а мое мнение в _этом_ вопросе предвзято, субъективно, и не отражает взгляд большинства Debian и Ubuntu пользователей
2. Это Ваша субъективная оценка, у меня другой опыт: на всех системах приходится пересобирать пакеты, и вести локальные репозитории с патчами и т д, тут только FreeBSD может дать всем фору, так вот на CentOS/RHEL это очень просто, так как есть заточенные инструменты.
Вы не понимаете, что пытаетесь подходить с Debian-way к другой платфоме, и оценивать ее с точки зрения Debian-пользователя, тогда как все в мире относительно, и для RHEL/CentOS другие приоритеты, и другие верные подходы, Debian-way же не на Debian системе лишь приведет к граблям, на которые Вы и наткнулись :)
3. Да, развертываются, debconf, но разница (по функционалу) между Anaconda, Cobbler, Spacewalk и debconf, имхо, такая же как разница по производительности на нагруженной базе на SATA raid5 и SAS raid10 на контроллере с большим кэшем с батарейкой: и то и то нужно увидеть, что бы, как говорится прочувствовать.
А еще, в puppet нет готового менеджмента репозиториев apt. Здесь сравнение совсем не в пользу Debian, прежде чем холиварить, ответьте себе честно на вопрос, Вы действительно уверены, что хорошо понимаете, как именно управляются большие сети на CentOS/RHEL?
Кстати, мы для менеджмента _конфигураций_ используем все-таки Puppet, но вот пакетный менеджмент там и для RH систем откровенно слабый, и дописать его на rubi под себя до уровня _хотя_бы_ Cobbler очень тяжело (мы коомбинируем Puppet с родными средствами платформы)
2. Это Ваша субъективная оценка, у меня другой опыт: на всех системах приходится пересобирать пакеты, и вести локальные репозитории с патчами и т д, тут только FreeBSD может дать всем фору, так вот на CentOS/RHEL это очень просто, так как есть заточенные инструменты.
Вы не понимаете, что пытаетесь подходить с Debian-way к другой платфоме, и оценивать ее с точки зрения Debian-пользователя, тогда как все в мире относительно, и для RHEL/CentOS другие приоритеты, и другие верные подходы, Debian-way же не на Debian системе лишь приведет к граблям, на которые Вы и наткнулись :)
3. Да, развертываются, debconf, но разница (по функционалу) между Anaconda, Cobbler, Spacewalk и debconf, имхо, такая же как разница по производительности на нагруженной базе на SATA raid5 и SAS raid10 на контроллере с большим кэшем с батарейкой: и то и то нужно увидеть, что бы, как говорится прочувствовать.
А еще, в puppet нет готового менеджмента репозиториев apt. Здесь сравнение совсем не в пользу Debian, прежде чем холиварить, ответьте себе честно на вопрос, Вы действительно уверены, что хорошо понимаете, как именно управляются большие сети на CentOS/RHEL?
Кстати, мы для менеджмента _конфигураций_ используем все-таки Puppet, но вот пакетный менеджмент там и для RH систем откровенно слабый, и дописать его на rubi под себя до уровня _хотя_бы_ Cobbler очень тяжело (мы коомбинируем Puppet с родными средствами платформы)
Еще добавлю насчет удобства.
— до черта вспомогательных консольных утилит, например ntsysv и пачка system-config-*, в разы облегчающих рутинные действия.
— офигительно удобная система сервисов и основной конфигурации.
— стандартизация в пакетах. Если я ставлю какой-нибудь демон из репозитория — я точно знаю, что конфиг к нему будет лежать в одном определенном месте, логи будут писаться туда, куда пишутся все остальные, будет создан необходимый независимый юзер (если это нужно), а правильные init-скрипты уже включены в комплект и все, что мне остается — отредактировать конфиг и спокойно запустить сервис, зная, что он будет работать. В дебиане/убунту такое наблюдается далеко не всегда.
— до черта вспомогательных консольных утилит, например ntsysv и пачка system-config-*, в разы облегчающих рутинные действия.
— офигительно удобная система сервисов и основной конфигурации.
— стандартизация в пакетах. Если я ставлю какой-нибудь демон из репозитория — я точно знаю, что конфиг к нему будет лежать в одном определенном месте, логи будут писаться туда, куда пишутся все остальные, будет создан необходимый независимый юзер (если это нужно), а правильные init-скрипты уже включены в комплект и все, что мне остается — отредактировать конфиг и спокойно запустить сервис, зная, что он будет работать. В дебиане/убунту такое наблюдается далеко не всегда.
Попробуйте Debian Lenny Stable.
Надеюсь, он вас приятно удивит ;)
Надеюсь, он вас приятно удивит ;)
Наконец-то! Пошел качать
ll
Никак не доходили руки, теперь буду приобщаться на ноуте, если дрова атишные найду
Таки нашелся основатель?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ура товарищи! вышел CentOS 5.5