>>> А то так можно и до типовой аргументации MS дойти
>> И эта аргументация имеет право на жизнь.
> Да, просто надо понимать ей цену.Как по мне аргументация может быть справедливой и нет. А вот с ценой уже вопрос сложный. Нам, получается, нужно ввести меру. А в чём оценивать аргументацию? Можем попробовать например оценить в последующих продажах конкурентных продуктов. Как тебе такая мера? =)
> Не так уж и сильно, как мне видится; тонкая порезка, например, меняет куда принципиальней.
Что ж там принципиального. Ну вот на одной стороне весов опциональные зависимости и их правильное выделение -- вот это действительно меняет представление о построении результирующей системы. Потому что на выходе получается система с binary-based дистром, содержимое которой можно скомпоновать совершенно произвольным образом, выкинув ненужные драйвера или плагины, например. Но при этом оставив их установку по умолчанию, что подходит большинству пользователей.
С другой стороны у нас тонкая нарезка бинарных пакетов. Я как-то по умолчанию всегда предполагаю, что к тонкой нарезке надо стремиться. Впрочем, это в последнее время играет всё меньше роли. Разве что эмбедки могут этому порадоваться. На десктопе можно, в принципе, ставить всё сопутствующее скопом. На серверах раньше дробление позволяло сузить attack surface, а сейчас весь новый софт по умолчанию в контейнерах идёт, в основном docker + alpine. Кому ещё нынче дробление нужно, не знаю.
>> control вряд ли кому-то в debian понадобится, там debconf есть стандарт.
>> Он работает, и всех вроде бы устраивает, как он работает.
> Медленно только, ага. В control-то тормозить просто нечему.
Ну так быстро нам вроде и не надо. Заменить debconf на control можно. Но только аккуратно. Надо враппер написать, чтобы control заменил debconf -- ну и базу мигрировать из одного в другой при установке.
> Кстати, покажи, какие есть возможности управления конкретно взятым su при помощи debconf
Посмотрел, util-linux настроек debconf не имеет. Но у нас как-то больше sudo в ходу.
