Hi Led!

Sunday 30, at 07:02:22 PM you wrote:

> > Что мешает тебе сделать отдельное ядро + виртуальный пакет?
> 
> Перманентно печальная судьбы наших kernel-complete отпугивает:) Хотя это тоже 
> вариант решения. Но в случае с ltsp это опять же вносит дополнительные 
> неоднозначности: в принципе, с ltsp можно использовать не только ядро led-tc, 
> но другие ядра, а делать инструкцию "если вы используете led-tc, то делайте 
> просто
> apt-get install kernel-complete-led-tc
> , а если другое ядро, то ... и т.д."
Кстати, а если я захочу OVZ контейнер для ltsp (т.е. -ovz-smp + модули)?
Это будет непоодерживаемой конфигурацией?

> 
> > Как минимум, 
> > это даст экономию своего времени, поскольку избавит от рутины пересборки
> > "сторонних" модулей. Более того, наличие отдельного kernel-source - это
> > 80% работы других мантейнеров для сборки этого модуля для своих ядер.
> 
> С этим согласен (про 80%).
> 
> > Подход "каждой кухарке - свое ядро" вреден тем, что как раз отбрасывает
> > все эти требования - теперь каждый собирает модули и ядра сам по себе, не
> > думая о других, что порождает все больше и больше бесплезных ядер,
> > различающихся только одним патчем/модулем в 2k.
> 
> А про причины возникновения ситуации "каждой кухарке - свое ядро" ты же 
> знаешь?:)
Нет, не знаю. Я знаю, что текущее состояние с ядрами у нас настолько
хреновое, что даже стыдно пользоваться каким-нибудь несобственным/неvsu
kernel-трам-пам-пам из сизифа ;)

> > Привычка обновлять ядро без причины - вредная привычка. И с ней неустанно
> > боролись :)
> 
> Не передёргивай: есть ещё варианты (нередкие) "привычка обновлять ядро С 
> ПРИЧИНОЙ":)
А привычка бэкпортить что нравится не развита? Перенос вкусных фишек в
-stable это как раз и есть работа мантейнера, а не мартышки, делающей git
fetch из git.kernel.org и переносящей собранный тарболл в сизиф (пример с
мартышкой отвлеченный ;) Более того, это не работа пользователя обновлять
ядра, пользователь хочет функционал, пинает манейнера, который чешет репу
и собирает ядро с заданным функционалом.

> 
> > > оверхеде по объёму (да, я знаю про всевозможные костыли-скрипты от разных
> > > авторов, которые "обновляют всё и красиво вместе с ядром", но от этого
> > > они перестают быть костылями). А по факту - ядра обновляются чаще, чем
> > > 90% "внешних модулей", которые потом "догоняют" ядро в репозитарии в
> > > течении нескольких дней. Но "догоняют" только формально, потому как
> > > множество kernel-source-module остаются безнадёжно устаревшими по версиям
> > > :(
> >
> > Если собирать себе каждый день снапшоты из git, то да, модули будут
> > отставать по версиям.
> 
> Опять не передёргивай: я говорил о ВЕРСИЯХ, с вдумчивым прочтением ChangeLog'а 
> (хотя в случае с drm имеет смысл смотреть и на "снапщоты git")
см. выше - иногда лучше прочитать, плюнуть и сделать свой -feat на текущее
ядро. Поскольку маленький кусок всегда лучше читается, чем 100Мб кода.

> 
> > В других случаях описанная ситутация кажется мне 
> > сильно надуманной. kernel-source у нас устаревают не потому, что ядро их
> > обгоняет, а потому что их собирать и чинить некому.
> 
> Воот! То, что я не осмелился сказать - ты озвучил. Вот я и не хочу зависеть от 
> этих "некому":) В kernel-image-led-tc все "как бы внешние" модули совсем не 
> тех версий, что в сизифе (кроме kernel-source-usbip, который я же в сизиф и 
> собираю):)
Я осмелюсь на большее - чем дальше, тем хуже. Думаю, новый дистрибутив
альтилинукс будет сделан на ядре с проприетарной лицензией, собранном
где-то за пределами офиса (если, конечно, ситуация не улучшится).

-- 
WBR et al.