Devuan в продакшене

Shaman007> У меня вообще есть мнение, что когда проблемы «продакшена» связаны с systemd, то тот продакшн хостится под партой.

А как же сдохшие материнские платы? А как же дикие глюки с заменой fstab от Поцеринга? А как же критические уязвимости в PID 1 в виде DoS'а? И это только самое свежее. Проблем просто дофигище. Ясное дело, что задача администратора - проблемы решать. Но зачем тогда брать тот инструмент, который заведомо и из-за своей архитектуры даёт колоссально большее количество проблем?

Сейчас во многих дистрибутивах работает и journalctl и rsyslog. journalctl пишет бинарные логи, и также транслирует их в rsyslog, который уже пишет обычные текстовые.

Это да. В продакшене же постгрес не используют, верно?

По умолчанию бинарные не сохраняются, но если создать каталог /var/log/journal, они будут писаться туда. Текстовые логи оставлены как легаси.

из инсталлятора

2016 год, кто-то надеится на инсталляторы, которыми никто не пользуеться уже десятки лет

2016 год, кто-то надеится на инсталляторы

Я ещё как минимум с 2012 на него особо не надеюсь, просто проверил осталось ли оно таким же Г или таки стало лучше.

которыми никто не пользуеться уже десятки лет

Готов для десктопа.

Почему тогда при удалении systemd дебьян требует и его удаления как зависящего пакета?

debtree в помощь. Про зависимости зависимостей слышал?

но если создать каталог /var/log/journal

Отличная практика конфигурирования.
*sarcasm*

А как же критические уязвимости в PID 1 в виде DoS'а? > И это только самое свежее. Проблем просто дофигище.
Но зачем тогда брать тот инструмент, который заведомо и из-за своей архитектуры даёт колоссально большее количество проблем?

Ну ту же брешешь как шелудивый пёс: В Linux зафиксирована уязвимость CVE-2016-5195

С точностью до буквы твой высер применим к ядру GNU/Linux. Тем не менее именно этот инструмент выбирает множество разработчиков и в том, и в другом случае. Никогда не пробовал задумываться, почему?