> на этом можно и закруглиться.Ну да, ну да, вякнув стандартное "сначала добейся" или "все пи..сы, а вот я со шпагой".
[del]
>> того, в случае проблем с кастомным ядром их заведомо придется разгребать
>> самостоятельно. Остальные ничем таким не смогут помочь.
> Ядра нужны, не стандартные, например, из-за разного шедулера,
И что, часто вам требовался шедулер (шедулер чего именно?) который надо вкомпиливать, да еще так чтобы все эти прыжки и ужимки окупили бы весь сопутствующий геморрой? Очень интересно как выглядит реальная ситуация где это надо. Учтя что в стоковом ядре и так есть несколько шедулеров (и CPU, и I/O, и сеть) на выбор.
> с вкюченной/выключенной отладкой.
На боевом сервере? Отлаживаться? Гхм, а с фига ли?
> У меня они собираются быстро и легко, и не нужно ни каких пакетов потом поддерживать,
Как по мне так пакетирование скорее добавляет удобство: можно передумать и поставить что-то иное заведомо корректным образом, а не думать где же я там чего еще забыл и как еще и где накосячил.
> всего-то есть один конфиг на одно ядро и не нужно толпы спецов и даже если
> нужно закрыть секюрити дыры, достаточно одной команды на обновление сорцов,
> двух команд на каждое ядро: пересбор и установка на базовой системе и одной
> команды, что бы все эти ядра разъехались по машинам. Все делается, еще
> раз повторю, быстро и легко.
Да я не спорю что вариант, просто с пакетами явно гибче. Например захотелось перепрофилировать "вот эту вот машину" на "сервер виртуализации XEN" допустим. Ну воткнули на нее другой пакет с ядром и вот оно уже "сервер виртуализации XEN" (потребные зависимости вкатятся, etc). Ну понятно что вам все это не грозит, по понятной причине. Но вообще сие довольно удобно.
> а во фре не нужно вообще мозг парить, достаточно нужный патч положить
> в /usr/ports/PATH/PORT/files, если нужны какие-то не стандартные опции занести их в
> /etc/make.conf и скомпилить так, как это делается обычно.
Опять же, я не сильно хочу при каждом обновлении проверять насколько там какой патч наложится/не наложится и тестировать насколько корректно все это будет работать потом.Да, у вас стрелять в свои пятки поудобнее, пожалуй. Но я бы для начала избегал нужды стрелять в них.
> А во фре, как правило, даже порта своего не нужно, и не
> нужно потом заботиться о своевременной его синхронизацией с основным портом.
Свой явно оформленный пакет хорош тем что его можно явно пометить как "зависящий от ... и конфликтующий с тем, тем и тем". Потом если захочется передумать - по крайней мере не пальнешь себе в пятку тем что какие-то хвосты от старой деятельности все сломают нафиг. ИМХО идея оформлять все пакетами - EPIC WIN. Так и integrity проверять проще, и восстанавливать порушенное проще, и все можно корректно и адекватно обновлять, вместе с зависимостями, и менять разные компоненты системы, в том числе на взаимоисключающие и без риска внезапных факапов.
[del]
>> мне кажется что единственной проблемой является то что "это делается не
>> так как в привычной BSD".
> Делается это везде, если захотеть, вопрос только в затраченном времени первоначально и
> затрачиваемом времени в дальнейшем на поддержку всего этого.
Да собственно у дебианщиков пакетная система вполне культурная и какого-то геморроя с ней я не заметил. Делано людьми для людей явно. Свои бестолковости конечно у всех есть, но все в пределах разумного.
> юзер, ну хватит уже лукавить
Так я и не лукавлю: по моему убеждению, идея попилить систему на пакеты-модули, такие же как и весь остальной софт - EPIC WIN, уж не знаю как понятнее это можно объяснить :)
