>> технология разворачивания 20..50 серверов 2..3 типов.
> Могу придумать несколько вариантов на этот счет. Но пока лично мне не
> требовалось. на этом можно и закруглиться.
>[оверквотинг удален]
> это надо - я не вижу никаких проблем это сделать. И
> даже оформить как +1 пакет с еще одним видом ядра. Убунтуи
> делают же. Чем остальные хуже? Но я бы этого избегал, из
> соображений что это куча работы которая сильно пригрузит достаточно квалифицированых специалистов
> на существенное время (==дорогое удовольствие для компании). И вообще, одно дело
> когда толпа хомяков баги вытопчет а другое - когда полтора человека
> в внутреннем тестировании. Риск факапов заметно растет, потому что полтора человека
> за разумный срок никогда не оттестят так же как миллионы. Кроме
> того, в случае проблем с кастомным ядром их заведомо придется разгребать
> самостоятельно. Остальные ничем таким не смогут помочь.
Ядра нужны, не стандартные, например, из-за разного шедулера, с вкюченной/выключенной отладкой. У меня они собираются быстро и легко, и не нужно ни каких пакетов потом поддерживать, всего-то есть один конфиг на одно ядро и не нужно толпы спецов и даже если нужно закрыть секюрити дыры, достаточно одной команды на обновление сорцов, двух команд на каждое ядро: пересбор и установка на базовой системе и одной команды, что бы все эти ядра разъехались по машинам. Все делается, еще раз повторю, быстро и легко.
> 3) Если честно, я apc (если это про пыховый кеш а не
> бесперебойники) ни разу не юзал а кешировать предпочитаю по возможности уже
> сгенерированное в статику, где потом нжинкс может эпически отдуплиться, будучи монстром
> отгрузки статики и весьма приятным в плане настроек кеширования. Тем не
> менее, в дебиянской пакетной системе нет никаких проблем сгрузить сорец пакета
> (в т.ч. со всеми зависимостями нужныим для пересборки), допатчить, переконфигурировать
> и собрать заново.
а во фре не нужно вообще мозг парить, достаточно нужный патч положить в /usr/ports/PATH/PORT/files, если нужны какие-то не стандартные опции занести их в /etc/make.conf и скомпилить так, как это делается обычно.
>>> Это актуально только если ну очень надо, а в репах нету.
>> именно так.
> Ну, собрать самому и (из соображений долговременной администряемости) оформить из этого
> пакет, если этого еще никто до нас не сделал. Слегка читерским
> checkinstall-ом это даже будет "дешево и сердито". Не догоняю - в
> каком месте должны наступать какие-то трудности?
А во фре, как правило, даже порта своего не нужно, и не нужно потом заботиться о своевременной его синхронизацией с основным портом.
>> описал выше.
> Не вижу каких-то фундаментальных проблем сделать то же самое в дебианообразных системах,
> если оно надо. Вы так говорите как будто это нельзя. Хотя
> мне кажется что единственной проблемой является то что "это делается не
> так как в привычной BSD".
Делается это везде, если захотеть, вопрос только в затраченном времени первоначально и затрачиваемом времени в дальнейшем на поддержку всего этого.
>> Непонятно с чего вы взяли, что FreeBSD исключение.
> С того что у бсдшников какие-то свои, очень специфичные понятия о отсутствии
> геморроя.
юзер, ну хватит уже лукавить
