> Порядок перечисления мало о чём говорит, т.к. плюсы и минусы вариантов можно
> расписывать отдельно и довольно подробно -- но мне, например, дурной работой
> на ровном месте уже много лет кажутся убунтушные "полугодовые релизы",Со своей стороны могу констатировать, что эта идея и ее реализация тем не менее нашли немало поклоников.
> причём цена этой марковой дури -- немалое количество *выгоревших* разработчиков Debian,
Мне кажется проблема здорово преувеличена на почве конкурентских антипатий. Торвальдс вообще один релизит огроменный кернел, раз в 2-3 месяца, и так - много лет. Он, конечно, такой один. Но при 20М пользователей - из их числа по любому будет иногда находиться кто-то достаточно грамотный для того чтобы подхватывать знамя. Да и дебианщики часть работы делают. И я вижу некоторое количество кадров которые в проекте уже длительное время. В целом имхо механика работает. То что более короткий релиз имеет шансы быть более забагованым - да, имеет. Но т.к. политика версионирования между релизами дебианообразная, это лучше чем testing репы в дебиане по стабильности и предсказуемости. В том плане что между релизами у меня не помрет внезапно grub2 на том основании что модули и core сильно разъехались по версиям, и никто не припрет мне systemd при "просто апгрейде", без предупреждения и чего доброго что-нибудь сломав, на что выли любители тестинга, узнавшие наконец почему тестинг так называется.
> имевших неосторожность пойти за этим человеком.
По моему мнению - у людей должен быть выбор. И частые релизы одна из опций. Кто-то тянет такой темп, кто-то нет. Разработка софта - не выпас стада, ориентироваться на самых медленных овeц совершенно не обязательно. Кому хочется более скромный темп развития - есть хоть тот же дебиан (от существования которого выигрывают многие, в том числе и убунта). У людей был выбор. Они должны понимать на что шли и оценивать свои силы.
С другой стороны - бэкпортирование довольно бесполезная работа. Люди тратят время на борьбу с искусственными политическими ограничениями и потом на такой софт даже баг например апстриму особо не зарепортишь - мало ли что там поменяли и кто баг посадил. Если софт идет более-менее апстримно, с нулевыми или небольшими изменениями - баги или улучшения можно апстриму отдавать относительно малой кровью. Де факто я считаю что бэкпорты отвлекают толпу народа на непродуктивную в долговременном плане активность и клинят общее развитие софта.
Ну и кроме того - со своей стороны я в обещм случае не хочу тяжеловесный интрузив от майнтайнеров. Для меня майнтайнеры - лишь вратари которые должны ловить явные плюхи апстрима. Компетенция майнтайнеров в глубинном устройстве софтины - является весьма рандомной величиной, поэтому лучше всего если они будут только опакечивать и проверять что это заработало и донапиливать только абсолютно неизбежное, в минимальном объеме. Экономя силы себе и не создавая своей жизнедеятельностью искусственные сложности другим.
> Полностью ошибаетесь с характеристикой. Конфликт здесь в том, что хочется обновлением
> платформы заниматься пореже (т.к. это морока и потеря времени),
С другой стороны - это ведет к застою и протуханию софта и core-части и клинит развитие софта, да и проекта в целом.
Ну понятно что альту с полутора землекопами на проект, где в пересчете на человека уйма работы - большой темп развития взять технически сложно. А Шатлворт принял иные решения и в конечном итоге получилось так, что он себе это может позволить. И это вроде работает. В силу толпы разработчиков знакомых с убунтой и базирования на дебиане, объем работ в пересчете на каждого конкретного индивида судя по всему не такой уж и огромный.
> а нужные кусочки прикладного софта и/или драйверов иметь посвежее
> (т.к. это нужная функциональность).
1) У ядра нет "кусочков" как таковых. Ну то-есть есть некие внутренние границы по подсистемам, но они больше для разработчиков и их процесса разработки. Для сборщика самый простой вариант менять все ядро целиком, все остальное - жуткий запрыг по костылям и уйма контрпродуктивной возни.
2) Вы никогда не угадаете какой именно свежий софт или компонент хочет конкретный юзер (например, я). Это означает что .. для того чтобы угодить всем, надо апдейтить все. И заявы про стабильность платформы стало быть идут лесом. Разработчики в массе своей например искренне ненавидят бодаться с багами древних либ, починеных в новых версиях. И поэтому имеют тенденцию не поддерживать откровенно тухлые компоненты в новых версиях. Подход такого плана интересует в основном всяких корпоративщиков. Ну да, там есть редхат. Они окучивают бизнес. Это сравнительно малочисленный, но высокодоходный рынок, которому чаще всего хватает ограниченного типового набора софта. Поэтому редхат не гоняется за поддержкой 100500 пакетов как дебиан и убунта. С другой стороны по этой причине они не конкурент Шатлворту на десктопе - general public редхаты с их приоритетами и полутора пакетами - малоинтересны.
3) Вот лично мне например удобнее подтягивать софт по версиям с риском отвала массово, в оговоренный интервал времени, а размазывая гемор и риски на весь срок эксплуатации. Для меня полдня концентрированного гемора и танцев с бубном на верификацию, а потом полгода более-менее предсказуемой и спокойной работы выглядят более интересной опцией чем лишняя возня с мануальщиной и повышенные риски по всему периоду эксплуатации.
4) Наверное логично, что я со своей стороны - за подходы которые мне оказываются удобны.
> А я вообще не мумукаюсь, т.к. у нас нет ни проблем testing
> (тем более unstable), ни проблем stable.
Это всего лишь потому что мумукание размазано во времени и менее заметно на первый взгляд. Поскольку в целом процесс более-менее эквивалентен (я или уж получаю свежую версию энного компонента или уж нет), вся разница - лишь в формате подачи. Ну то-есть вкатывая более новую версию из бэкпорта я буду валидировать ее поведение и нести риски что что-то сломается. Просто это окажется размазано по времени на весь срок эксплуатации вместо того чтобы размахаться сразу с кипой софта за полдня и забыть про все это на полгода.
> Есть другие, но выбор между теми и этими для меня оказался прост.
Ну а мой выбор вот такой. Меня он устраивает. Иначе он, очевидно, был бы другим. Правда жизни такова что я вообще не люблю тухляк в либах, ядрахи прочем, но не собираюсь заниматься ультра-камикадзинком по типу роллинга.
> Да-да, эту рекомендацию ещё вчера заметил и спасибо. Только там, по
> словам майнтейнера, не всё так гладко с обновлением (не помню детали).
Могу предположить что проблема в том что завязка на LLVM. Иногда бывает так что фича превращается в баг. И это именно тот случай - code reuse это здорово. Но есть нюансы. LLVM как бы довольно системная штука. И вот так наобум его подкинуть в версии на 1-2 major релиза - эм, у юзера могут быть тулчайны на его основе, их тоже надо подтягивать. И вообще надо пересобирать то что LLVM юзало. Если об этом не подумать заранее - может получиться немало грабель. А если юзер какой-то кастомный тулчейн собрал... ну... его придется еще раз собирать. Или как-то утрясать жизнь нескольких версий либ в системе и чтобы остальная механика и майнтайнеры на это не смотрели волком. В общем в живой стабильной системе такой пируэт действительно может быть нетривиален и граблеопасен.
...в этом месте мы начинаем догадываться что "частые релизы" здорово уменьшают эту проблему ;). А подобный класс проблем - он характерен далеко не только для LLVM.
Подтянуть версии тех или иных либ может хотеться по куче причин. Но это далеко не всегда просто сделать. Поэтому долговременная платформа может начать клинить уйму всего, на бэкпорты начнет уходить дофига усилий, которые в глобальном масштабе есть работа на мусорный бак: при обновлении платформы эти усилия будут во многом аннулированы.
> Краем уха слышал.
Ну вот там можно увидеть пример недружественного поведения фирмвары. Одного из. Если быть пессимистом - можно ожидать что фирмварь сможет запатчить операционку при загрузке.
> Съехидничал малость.
"Над кем смеетесь?". Проблема с блоботой в фирмварах - у нас всех. И если вы еще не поняли насколько большой залет у нас по этой линии намечается: http://auto.onliner.by/2015/04/27/auto-11/ (ума не приложу - попадает ли это оборзение под тематику опеннета и стоит ли сюда новость постануть).
> В основном в firmware-linux, а это то, что отдельно
А, то-то я смотрю - какие-то довольно экзотичные сетевухи.
> Эт хорошо ;-)
Со своей стороны я разумеется приветствую такие инициативы и искренне желаю остальным производителям последовать примеру. Жаль что до идеала как до луны, а встроенные фирмвары открывать и вовсе стимула мало. Зато западлостроения - много. В стандарте BlueRay например диск (а точнее софт на нем) может совершенно официально убить привод, если посчитает что прошивка привода хакнутая и не соблюдает DRM. Впрочем, это еще цветочки, ягодки вон General Motors готовит...
