гыгы нунее как стоял у мну 2.6.16-rc3 так и пусть стоит всё настроено и работает

вроде была уже такая новость.

Как-то чудно разработка идет.

Аж сразу три подветки 2.6: 2.6.16.x, 2.6.17.x, 2.6.18-rc.

Не перебор ли это...

> Аж сразу три подветки 2.6: 2.6.16.x, 2.6.17.x, 2.6.18-rc.

> Не перебор ли это...

Вовсе нет.

Новая стабильная ветка 2.6.16.x, временно стабильная 2.6.17(+n).x до выхода 2.6.18(+n), где n от нуля до неопределенности, 2.6.18 пока unstable.

А в 2.4 на 16-м патче просто сделали форк "2.5"... запутано все очень...

> Новая стабильная ветка 2.6.16.x, временно стабильная 2.6.17(+n).x до выхода 2.6.18(+n), где n от нуля до неопределенности, 2.6.18 пока unstable.

"Немножко беременная" :)

Хорошая новость. Неохота на продакшн ставить 2.6.17 и выше, мало ли что они там поломают, а обновлений безопасности хочется.

> Хорошая новость. Неохота на продакшн ставить 2.6.17 и выше, мало ли что они там поломают, а обновлений безопасности хочется.

Ну вы и разогнались... на продакшене еще пока только думают о перспективах обновления с 2.6.9... а тут уже "2.6.17 и выше" :)

маразм крепчал. неужели нельзя сделать stable и current? есть сервак, там крутится stable, нашли баг, обновили stable. а сейчас: все работают в current, исправили баг, а попутно внесли другой. непонятно, что лучше -- работать со старым или с новым багом?

Может не надо продакшен с собой ассоциировать ?
У меня на продакшене 2.6.16

>маразм крепчал.

это у тебя маразм. ванильное ядро не предполагает использование. Дистроклипатели поддреживают свои старые стабле ядра.

> Может не надо продакшен с собой ассоциировать ? > У меня на продакшене 2.6.16

Та я не с собой, я с RHEL со всеми его сервиспаками... В гробу видал такую политику, чесслово, и сам бы ставил vanilla на все серваки, но вы подите объясните манагерам, почему разработка должна вестись под либки, а не под сертифицированныйЪЪ оттестированныйЪЪ коммерческийЪЪ дистрибутивЪЪ (C)+(TM).

>на продакшене еще пока только думают о перспективах обновления с 2.6.9

Production == redhat?? Еще ведь и sles/nld/sled есть...

> это у тебя маразм. ванильное ядро не предполагает использование.

Неужели? И фиксы для него stable kernel team просто от нечего делать выпускает?

> Production == redhat?? Еще ведь и sles/nld/sled есть...

Ну вот счас я все бросил и побежал пионерить на работающих серваках, меняя дистры и закупая оптом поддержку :) Стоит, пашет, давно, не падает и не намерено - что еще нужно? ;)

В SLES9 с последним паком ядро тоже кажись было 2.6.9, по аналогии.

>Ну вот счас я все бросил и побежал пионерить на работающих серваках..

Начальство прикажет - придется :).

>В SLES9 с последним паком ядро тоже кажись было 2.6.9, по аналогии.

Не 2.6.5 случайно? Или я с NLD путаю?

Но смысл моего сообщения был в том, что стабильность ядра на production сервере зависит от дистрибутива, а не от версии. Совсем не факт что 2.6.9 на debian'e (например) настолько же стабильно как и на redhat'e.

> Начальство прикажет - придется :).

Начальство ни в жисть такой херни не выкинет, т.к. разработка идет, программы поддержки оплачены, и так далее. А до следующего форка в новый релиз конторы еще год-два как минимум, к тому времени уже уволюсь пять раз в нефтянку.

> Не 2.6.5 случайно? Или я с NLD путаю?

Хз, но учитывая тот спорность факта, что по основным параметрам RHEL и SLES - близнецы братья, то возможно путаю я...

> Но смысл моего сообщения был в том, что стабильность ядра на production сервере зависит от дистрибутива, а не от версии. Совсем не факт что 2.6.9 на debian'e (например) настолько же стабильно как и на redhat'e.

Хз, шаманство это все. Главный смысл в том, что если епнется RH, то вопли уйдут в техподдержку, а если на слаке - то придется распечатывать вазелиновый НЗ. Но ИМХО грамотный админ может сделать стабильный "простой" сервер (ftp/www/ldap/smb/autobuild/cvs, базовые сервисы) на базе хоть LFS, было бы время и желание ипацца, но с таким подходом слишком много геморроя.

birdie - злостный баянист. Эта "новость" уже раза 2-3 была, причем несколько месяцев назад.

>В SLES9 с последним паком ядро тоже кажись было 2.6.9, по аналогии.

Не сочиняете, как было 2.6.5-7 так и осталось.

Что-то я уже запутался в ядрах и перестал соображать что там и как. Ну да благо я использую ядро от вендора (ALT Linux) и мне сильно вникать в эту кухню не нужно -- достаточно просто apt-get install kernel-image-std26-up скомандовать :)

>Ну вы и разогнались... на продакшене еще пока только думают о перспективах обновления с 2.6.9... а тут уже "2.6.17 и выше" :)

Нам дистровое ядро не подошло по какой-то причине (уже не помню, каких-то фич не хватало, что-ли), а сидеть на старом ванильном ядре - себе дороже, в них известных незакрытых дыр хватает.

> Не сочиняете, как было 2.6.5-7 так и осталось.

Ну 2.6.5, так 2.6.5, все равно боянище изрядный, уже 17-патч пролетел и устарел.

> Нам дистровое ядро не подошло по какой-то причине (уже не помню, каких-то фич не хватало, что-ли), а сидеть на старом ванильном ядре - себе дороже, в них известных незакрытых дыр хватает.

Не надо ассоциировать RHEL-2.6.9 и vanilla-2.6.9 Дыры в RHEL патчатся, только версия ядра остается таже, да и патчей там мегобайта на 2 (на железо, fix, в т.ч. и security) Для примера, офиициальная поддержка для scsi-контроллера PERC 4 (dell pe2850) появилась только 2.6.12 ядре, а RHEL есть патч и т.п.

> Нам дистровое ядро не подошло по какой-то причине (уже не помню, каких-то фич не хватало, что-ли), а сидеть на старом ванильном ядре - себе дороже, в них известных незакрытых дыр хватает.

Чайники идут и открывают для себя обновления безопасности. Получая обновления безопасности можно сидеть на полностью пропатченном 2.6.5, 2.6.8 или 2.6.9 в течение всего периода сопровождения.

Только некомпетентные дупланы, не слышавшие про обновления безопасности, считают, что только обновление версии ядра до текущей позволит устранить уязвимость.

А причем тут RHEL? Дистр был Debian/Sarge...

>Чайники идут и открывают для себя обновления безопасности. Получая обновления безопасности можно сидеть на полностью пропатченном 2.6.5, 2.6.8 или 2.6.9 в течение всего периода сопровождения.

Можно. Например, используя дистровое ядро, которое будут латать мэйнтейнеры дистра. Самому латать левыми патчами у меня желания нет, поэтому-то я и хочу сидеть на 2.6.16, да чтоб мне его латали регулярно.

>Только некомпетентные дупланы, не слышавшие про обновления безопасности, считают, что только обновление версии ядра до текущей позволит устранить уязвимость.

Ну типа да. Например, патчи на 2.6.16 продолжали выходить и после выхода 2.6.17.

Дело в том, что для начальства debian не катит для production, ибо нету support'а :(, и за все проблемы отдуваться приходится админу.

Впрочем, для малых фирм это не проблема.

Веб-сервак с average в 44.6 Мбит/с. Живет под постоянным DDoSом, файрволлит ублюдков десятками в час.

Ядро 2.6.16.27. Вторые сутки, полет нормальный.

...

>в тоже время ядра 2.4.x и 2.2.x уже морально устарели, предлагают поддержку меньшего количества устройств и технологий, не поддерживают preemption

Кто мне объяснить нах на роутере к примеру preemption и "поддержка новых устройств". Я их туда как буду вешать то ? Паялником чтоли ?

2.4 (и в меньшей степени 2.2) вполне нормально занимает свою нишу на старом железе которое легче выкинуть чем обновлять, на всяких роутерах там и прочей мелочи.

Вообще - это тема, банальный аптайм для линукса уже слишком мелкое понятие, в современных условиях стоит использовать понятие "аптайм под непрервным DDoS'ом", +1.