https://www.opennet.ru/openforum/vsluhforumID3/79782.html Разработчики проекта CentOS объявили (http://lists.centos.org/pipermail/centos-announce/2011-August/017689.html) о создании непрерывно обновляемого репозитория (Continuous Release) для ветки CentOS 5.6, который позволит установить связанные с безопасностью исправления, выпускаемые для уже вышедшего релиза Red Hat Enterprise Linux 5.7 (http://www.opennet.ru/opennews/art.shtml?num=31264), на базе которого будет сформирован выпуск CentOS 5.7. Релиз CentOS 5.7 ожидается через 7-10 дней, тем не менее всем пользователям CentOS 5.6 настоятельно рекомендуется не дожидаясь релиза обновить свои системы из представленного CR-репозитория.<br><br><br>В связи с задержкой выхода CentOS 5.7 обновления для CentOS 5.x не выпускаются уже почти месяц. В начале года отставание релиза CentOS 5.6 от RHEL 5.6 составило 82 дня, все это время пользователи оставались без обновлений с исправлением проблем безопасности. На этот раз, желая не повторить печальный опыт, было решено провести перепаковку для CentOS 5.6 обновл...<br><br>URL: http://lists.c https://www.opennet.ru/openforum/vsluhforumID3/79782.html#13 Fri, 19 Aug 2011 12:15:25 GMT Это самое "готовое" точно так же кто-то собрал<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#12 Thu, 18 Aug 2011 11:13:59 GMT Я так и не понял зачем было делать папку cr ?<br>Почему ЭТО просто в папку updates не закинуть было ?<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#11 Wed, 17 Aug 2011 15:54:57 GMT ребят, а не подскажете, есть ли репозитарий для SL6 где был бы snort.<br>можно конечно собрать с исходников, но хотелось бы, готовое :)<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#10 Wed, 17 Aug 2011 09:49:17 GMT Нет, это на самом деле вполне себе продакшен. SL6.1 и инструменты для поиска проблем, да.<br><br>Затыки видны везде. Например, одна программа постоянно ставила колом процессор - с perf'ом легко стало видно, что проблема в malloc'е - потвикал, пересобрал ее с гугловским маллоком, проблема прошла. С помощью perf timechart можно смотреть проблемы взаимного взаимодействия программ - когда один модуль ждет другой, когда они ждут диск или процессор и тд. Видны и проблемы конкретных библиотек - например, если у вас тормозит пхп, можно увидеть, на каком уровне возникает проблема.<br><br>Проблемы ядра и драйверов тоже замечательно видны - у железа и драйверов нередко есть тонкие настройки по внутренним буферам, прерываниям и т.д. - с помощью perf можно видеть подобные проблемы; он сразу показывает что, например, ядро проводит очень много времени в обработчике прерываний драйвере какого-то контроллера - и сразу знаешь, куда копать. Легко запомнить состояние, изменить и промониторить прогресс.<br><br>perf замечателен тем, что практ https://www.opennet.ru/openforum/vsluhforumID3/79782.html#8 Wed, 17 Aug 2011 03:36:37 GMT &gt; На сервере с SL6<br><br>Тьфу ты, уже напугал меня. Я то подумал что это за сервак такой с дебугинфо ...<br>А оказывается обычный тестово-девелоперский с сл6 ...<br><br>P.S.<br>и у меня заодно вопрос. Вы эти затыки в чем ищете ? В ядре и глибс что ли ?<br>А не в пхп-жабы ( 1с и прочая ... ) ваших быдло-программах что ли ?<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#7 Tue, 16 Aug 2011 23:49:13 GMT Видимо, он это к тому, что реальные пацаны собирают свои собственные дистры (убунту + нескучные обои), а не ПОТРЕБЛЯЮТ сделанное другими.<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#5 Tue, 16 Aug 2011 21:42:01 GMT Вы это к чему?<br><br>Способа "дособрать" debuginfo, к вашему сведению, нет; корректный debuginfo выделяется только в момент сборки пакета. И "самому" добавлять debuginfo - это значит пересобирать (и использовать постоянно свои версии) kernel, glibc, gcc, libstdc++ и ко всем-всем библиотекам, которые могут использоваться и на что-то влиять.<br><br>У меня на рабочей машинке с федорой, где мне нужен gdb на пару прог и иногда perf:<br>$ rpm -qa&#124;grep debuginfo&#124;wc -l<br>66<br><br>На сервере с SL6, где очень часто нужен perf и стоит debuginfo к большей части библиотек, вызовы в которых отнимают ресурсы процессора или ввода вывода:<br>$ rpm -qa&#124;grep debuginfo&#124;wc -l<br>151<br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#4 Tue, 16 Aug 2011 21:36:07 GMT Бедный какой ПОТРЕБИТЕЛЬ. <br> https://www.opennet.ru/openforum/vsluhforumID3/79782.html#2 Tue, 16 Aug 2011 18:29:28 GMT И debuginfo, разумеется, опять нет. Проанализировать затыки производительности через perf или oprofile невозможно. Спасибо, не надо - остаюсь на SL.<br>