Разработчики проекта CentOS объявили (http://lists.centos.org/pipermail/centos-announce/2011-Augus...) о создании непрерывно обновляемого репозитория (Continuous Release) для ветки CentOS 5.6, который позволит установить связанные с безопасностью исправления, выпускаемые для уже вышедшего релиза Red Hat Enterprise Linux 5.7 (http://www.opennet.me/opennews/art.shtml?num=31264), на базе которого будет сформирован выпуск CentOS 5.7. Релиз CentOS 5.7 ожидается через 7-10 дней, тем не менее всем пользователям CentOS 5.6 настоятельно рекомендуется не дожидаясь релиза обновить свои системы из представленного CR-репозитория.
В связи с задержкой выхода CentOS 5.7 обновления для CentOS 5.x не выпускаются уже почти месяц. В начале года отставание релиза CentOS 5.6 от RHEL 5.6 составило 82 дня, все это время пользователи оставались без обновлений с исправлением проблем безопасности. На этот раз, желая не повторить печальный опыт, было решено провести перепаковку для CentOS 5.6 обновл...URL: http://lists.centos.org/pipermail/centos-announce/2011-Augus...
Новость: http://www.opennet.me/opennews/art.shtml?num=31509
Хороший вариант. Лишь бы обновляли своевременно, а не как обновления в начале года.ps. http://ftp.scientificlinux.org/linux/scientific/5rolling/
Я так и не понял зачем было делать папку cr ?
Почему ЭТО просто в папку updates не закинуть было ?
И debuginfo, разумеется, опять нет. Проанализировать затыки производительности через perf или oprofile невозможно. Спасибо, не надо - остаюсь на SL.
Бедный какой ПОТРЕБИТЕЛЬ.
Вы это к чему?Способа "дособрать" debuginfo, к вашему сведению, нет; корректный debuginfo выделяется только в момент сборки пакета. И "самому" добавлять debuginfo - это значит пересобирать (и использовать постоянно свои версии) kernel, glibc, gcc, libstdc++ и ко всем-всем библиотекам, которые могут использоваться и на что-то влиять.
У меня на рабочей машинке с федорой, где мне нужен gdb на пару прог и иногда perf:
$ rpm -qa|grep debuginfo|wc -l
66На сервере с SL6, где очень часто нужен perf и стоит debuginfo к большей части библиотек, вызовы в которых отнимают ресурсы процессора или ввода вывода:
$ rpm -qa|grep debuginfo|wc -l
151
Видимо, он это к тому, что реальные пацаны собирают свои собственные дистры (убунту + нескучные обои), а не ПОТРЕБЛЯЮТ сделанное другими.
> На сервере с SL6Тьфу ты, уже напугал меня. Я то подумал что это за сервак такой с дебугинфо ...
А оказывается обычный тестово-девелоперский с сл6 ...P.S.
и у меня заодно вопрос. Вы эти затыки в чем ищете ? В ядре и глибс что ли ?
А не в пхп-жабы ( 1с и прочая ... ) ваших быдло-программах что ли ?
Нет, это на самом деле вполне себе продакшен. SL6.1 и инструменты для поиска проблем, да.Затыки видны везде. Например, одна программа постоянно ставила колом процессор - с perf'ом легко стало видно, что проблема в malloc'е - потвикал, пересобрал ее с гугловским маллоком, проблема прошла. С помощью perf timechart можно смотреть проблемы взаимного взаимодействия программ - когда один модуль ждет другой, когда они ждут диск или процессор и тд. Видны и проблемы конкретных библиотек - например, если у вас тормозит пхп, можно увидеть, на каком уровне возникает проблема.
Проблемы ядра и драйверов тоже замечательно видны - у железа и драйверов нередко есть тонкие настройки по внутренним буферам, прерываниям и т.д. - с помощью perf можно видеть подобные проблемы; он сразу показывает что, например, ядро проводит очень много времени в обработчике прерываний драйвере какого-то контроллера - и сразу знаешь, куда копать. Легко запомнить состояние, изменить и промониторить прогресс.
perf замечателен тем, что практически не дает замедления работы того, что мониторится; поэтому нет проблем с использованием его на продакшене, в отличие от скажем valgrind.
ребят, а не подскажете, есть ли репозитарий для SL6 где был бы snort.
можно конечно собрать с исходников, но хотелось бы, готовое :)
Это самое "готовое" точно так же кто-то собрал