>>> Персонаж с ником arisu тебе не знаком?
>> Да, и?
> Не знаком?Прошу простить мою неоднозначность с утра в ответах. Я знаком с arisu по беседам в комментариях на opennet.
> В ответ на обоснованные аргументы начинал изливать помои. Причём, как-то
> так оказывалось, что пост его оппонента потом выпиливался, а помои arisu
> оставались (Привет, Майкл!).
И? Что с того? Нашли одного человека? Я не могу найти ниодного systemd-шника, который бы не изливал помои. А у arisu это просто стиль общения такой. Это он со всеми всегда такой, а не только по вопросам systemd.
>> Стандартная библиотека СИ в соответствии со стандартами C11 и POSIX.1-2008.
>> Можно конкертные примеры, чтобы я понял о чём сейчас идёт речь?
> Речь о том, что это комбайн, причем не заменяемый. Даже при замене
> на eglibc, которая всего лишь форк, а не написанный с нуля
> аналог, куча пакетов переставала собираться. А перевести дистрибутив с glibc на
> ту же uclibc - это закат Солнца вручную.
Как-то я под FreeBSD, Windows и другими системами без труда использовал всякие там mc, которые вроде как изначально писались с использованием glibc. Поправьте, если ошибаюсь.
> Так что, если
> дистрибутив завязан на glibc, то никакой аналог ты в него не
> впихнёшь. Поэтому все разговоры о наличии аналогов для стандартной библиотеки -
> это чистая философия.6
Ложь. Я работал с разными libc, но с одними и теми же приложениями поверх, и никаких проблем.
>> Давайте конкретику (хотя бы по паре примеров). Замена нескольких мелких костылей одним
>> монстроузным -- это плохой выход, IMHO.
> Systemd - это не чистый init.
> Он может служить в качестве init,
> но это только малая часть его функциональности.
Про что все и твердят. Это монструозный костыль-комбайн.
> Соединить вместе журналирование, мониторинг
> и контроль демонов, управление сеансами и т.д. с помощью сторонних инструментов
> можно, но не факт, что это будет работать, как ожидалось
Не наблюдал существенных проблем с этим на своих системах до systemd.
> Как гарантированно прибить потомков, после прибития родительского процесса?
Ну, знаю два пути:
- cgroups
- ptrace
Второй способ я даже реализовал ради интереса :). Однако к чему этот вопрос вообще? Использование cgroups никак не означает делать всё как в systemd. Такую feature и в openrc сделали… Но OpenRC может работать без cgroups (и на каком-нибудь там Hurd-е), а systemd?
>[оверквотинг удален]
>> напрочь halt-ится.
>> - По какой-то причине, первые разы экран был на нулевой яркости (я
>> не сразу догадался, что всё в порядке и проблема просто с
>> яркостью). Я уже не помню, как это исправлялось, но помню, что
>> с удивлением обнаружил, что виноват systemd.
> Я не уверен, что это проблема именно systemd, а не конфигурации.
>> Легко, я уже писал (например, одна из программ была а-ля nest). Спасибо
>> BSD libc и uclibc.
> И этот демон будет работать на системе с glibc без пересборки с
> glibc?
Конечно нет, однако к чему этот вопрос? Если вы замените libxml на API-совместимый (но не ABI) аналог, то вам опять же потребуется перекомпиляция. Это не свойство glibc, а свойство shared object как таковых.
И я не понимаю, что сложного в том, чтобы перекомпилировать этот демон. Но главнее, что данная проблема не имеет отношения к glibc.
>>> И systemd не запрещает монтирование /usr. Тебя цинично обманули.
>> Серьёзно, можно без initrd и каких-либо проблем держать /usr отдельно и грузиться
>> с systemd?
> Какие-то предубеждения против initrd?
Да, не люблю лишние сущности. Это источники проблем.
Но вы на вопрос не ответили. Всё-таки systemd вводит это ограничение?
> Попробуйте набором отдельных программ реализовать
> всю функциональность systemd.
Вся нужная мне функциональность _уже_ была реализована ещё _до_ появления systemd.
> Что, никому из них не нужен примонтированный /usr?
Никто из них не требует держать «/usr» на том же разделе, что и «/».
А вообще, см. концовку http://www.opennet.ru/openforum/vsluhforumID3/98827.html#243 и давайте уже прекратим этот бесполезный диалог, ок?
