>> в этом случае быстрее переставить сервер, чем килять какие-то пакеты и ставить новые,
> В случае с бсдами наверное. В случае deb-based переставлять все когда можно
> 2 пакета культурно перетасовать - дурь несусветная. И в десять раз
> больше затрат времени на хзчто.угу, поменять ядро, монтируемые удаленные системы, полный набор софта, конфиги... сразу видно, что вы теоретик.
>>> Не вижу смысла таскать что-то туда-сюда при наличии пакетного манагера.
>> Очень простой пример: у вас есть 10-ть серверов, например, под мускуль, ставились
>> сервера не сразу, по-этому у них разное железо и, соответственно, разные
>> проц-память-возможности, каждый нужно настроить под его конкретные возможности,
> За такое "администрирование" гнать надо. Сразу. Ссаными тряпками и сраной метлой. Потому
> что админ будет дофига времени заниматься абстрактным "настроить под его конкретные
> возможности". Особенно на бсдях.
Ну это у вас админ будет заниматься, а у нас все сделает автоматика.
>> тот же key_buffer и/или innodb_buffer_pool_size в зависимость от оперативки,
>> или thread_concurrency в зависимости от кол-ва ядер, как вы это будете делать и
>> как вы будете это делать при апгрейде железа своим пакетным менеджером
>> или тут уже заступают на службу руки админа?
> Тут должны бы заступить на службу руки манагера - выпнуть тех дятлов
> которые этот зоопарк понапихали, увеличив административную нагрузку на ровном месте в
> несколько раз.
чего-чего? выпнуть разработчиков мускуля которые придумали innodb_buffer_pool_size?
> Тем не менее, если задача ну просто здец какая типовая и это
> реально крупный энтерпрайз таких дров наломал - ну воткнуть в пакет
> скрипт который ввинтит параметры скулю в зависимости от оперативы. На кой
> перец админу дрюкаться с этим лично? А если таких хостов 200
> штук потребуется - админ тоже будет с каждым мудохаться? Это ж
> сколько тогда админов и их времени будет нужно? oO
и чего, при обновлении железа переставлять пакет, что бы отработал ваш скриптик?