>> Персонаж с ником arisu тебе не знаком?
> Да, и?Не знаком? В ответ на обоснованные аргументы начинал изливать помои. Причём, как-то так оказывалось, что пост его оппонента потом выпиливался, а помои arisu оставались (Привет, Майкл!).
> Стандартная библиотека СИ в соответствии со стандартами C11 и POSIX.1-2008.
> Можно конкертные примеры, чтобы я понял о чём сейчас идёт речь?
Речь о том, что это комбайн, причем не заменяемый. Даже при замене на eglibc, которая всего лишь форк, а не написанный с нуля аналог, куча пакетов переставала собираться. А перевести дистрибутив с glibc на ту же uclibc - это закат Солнца вручную. Так что, если дистрибутив завязан на glibc, то никакой аналог ты в него не впихнёшь. Поэтому все разговоры о наличии аналогов для стандартной библиотеки - это чистая философия. Выпилить systemd из дистрибутива на порядки проще.
> Давайте конкретику (хотя бы по паре примеров). Замена нескольких мелких костылей одним
> монстроузным -- это плохой выход, IMHO.
Systemd - это не чистый init. Он может служить в качестве init, но это только малая часть его функциональности. Соединить вместе журналирование, мониторинг и контроль демонов, управление сеансами и т.д. с помощью сторонних инструментов можно, но не факт, что это будет работать, как ожидалось. Как гарантированно прибить потомков, после прибития родительского процесса?
> У меня как-то до systemd загрузка работала лучше, чем с появлением systemd.
> Пара примеров:
> - Если 3 раза ввести неверный пароль для монтирования крипто-раздела, то загрузка
> напрочь halt-ится.
> - По какой-то причине, первые разы экран был на нулевой яркости (я
> не сразу догадался, что всё в порядке и проблема просто с
> яркостью). Я уже не помню, как это исправлялось, но помню, что
> с удивлением обнаружил, что виноват systemd.
Я не уверен, что это проблема именно systemd, а не конфигурации.
> Легко, я уже писал (например, одна из программ была а-ля nest). Спасибо
> BSD libc и uclibc.
И этот демон будет работать на системе с glibc без пересборки с glibc?
>> И systemd не запрещает монтирование /usr. Тебя цинично обманули.
> Серьёзно, можно без initrd и каких-либо проблем держать /usr отдельно и грузиться
> с systemd?
Какие-то предубеждения против initrd? Попробуйте набором отдельных программ реализовать всю функциональность systemd. Что, никому из них не нужен примонтированный /usr?
