> Хм. А какая тогда у меня - три линуха, В нда и BSD?

Тогда вопрос наверное звучит так: "почему вы еще не директор зоопарка?" ;). Я не понимаю зачем такой мегаср@чЪ на 1 физической машине. Ну ладно бы это еще на виртуалках жило. Дело то хозяйское, но...

> нем. Ах да, у меня нету никаких grub2 с его наркоманскими
> конфигами в двух или трех местах.

На самом деле конфигурится в одном месте - прописывается как генерить конфиг. А так поздравляю с открытием: иногда то что для одного фича, для другого - баг. Но, имхо, если уж мы о наркомании - я в настроении сказать что пять ОС на одной физической машине значительно ближе к этому чем какой-то grub2. Который даже до операционки толком не дорос. Хоть и старался.

С другой стороны, grub2 может грузиться с хитрых файлух типа btrfs и zfs, RAIDов и шифрованных томов а встроенные скрипты могут реализовывать довольно навороченную логику. Надо ли это лично вам - да не факт. А майнтайнеры дистра могут получить желаемое дефолтное поведение. То что вы можете сделать как-то иначе - так на то и опенсорс...

> конфигом в /boot'е же, который правится ручками. И так уже десять
> лет, без каких-либо проблем.

Ну это коненчо мощный аргумент за такую технологию. Но, боюсь, многим (включая меня) удобнее когда кернел вписывается сам, как только пакет ставишь. Это кроме всего прочего позволяет быстро и комфортно обкатать свежий билд ядра, например. Хорошо когда для этого надо минимум действий. А если это был git bisect, я могу и штук пять ядер за хренацать минут обкатать и наверное меня при этом не очень радует какие-то конфиги grub лишний раз тасовать.

А по-моему неплохой workflow обкатки кернела вышел:
1) make deb-pkg
2) dpkg -i *.deb
3) reboot
4) PROFIT

> Тут как с твоей любимой сисьтемдой - хочешь кофе-в-постель-подавательный комбайн?
> Да пожалуйста, но имей в виду, что он может начать себя вести непредсказуемым
> образом и ты заманаешься узнать, что же не так и как это исправить.

Да вот как-то разок хорошо пободался. И обнаружил фундаментальный баг... на уровне системы. Нет, не системды. А продолб в конфигурации кернела, когда ядерщики поменяли, я прошляпил, а результат получился в целом "не очень". Где-то в новости про системд - рассказ как я за энтропией охотился и как системд срубил джекпот.

> С другой стороны, простой дубовый инструмент не так крут
> и автоматизирован, но зато ты сам, своими силами можешь в нем
> разобраться и при нужде починить.

Знаешь, человек, я конечно могу своими силами накодить апи вачдогования процессов и правильное секвенсирование сисколов для всяких расстановок приоритетов, смены шедулеров и прочих урезаний в контейнер и проч. Но во первых я задолбаюсь прыгать по граблям, а во вторых я при этом напишу половину системд. Только хуже. А то что всякие ископаемые всеми этим фичами пользоваться не умеют или не хотят - не мои проблемы. Я этими фичами не только пользуюсь, но и на эмбедовке это довольно важные для меня фичи. А если там вдруг что-то сбоит - я еще и предъявы за это получаю. И имею заметить что системд как раз неплохо подсвечивает халтуру в системных вещах. По моему опыту - если системд сыпет ошибками, 95% вероятности что баг - не в системд.

> Но что-то придется делать самому, ручками.

И вижу что у таких мегаадминов получается. Когда они потом и 10% фич ядра использовать не могут. Впрочем для тех кто пользуется BSD совершенно нормально админить компы как будто на дворе 80-е. Это ваш выбор. А для меня - такие подходы сильно вклинивают мою эффективность. Пока вы возитесь с 1 замшелой системой по технологиям 80-х, я подниму целый сцуко флот виртуалок, прогоню на них какой-нибудь системный эксперимент и приббю их или верну на нулевый снапшот, если хочу проверить что-то еще. То на что вы тратите ЧАСЫ я делаю за СЕКУНДЫ.

> Каждому, как говорится, свое.

Все так. Кому-то кукурузник. Кому-то звездолет. В кукурузнике вы сами дергаете механические тяги, а в звездолете без кучи бортовых компьютеров - пилоту крышка.