>> socket-based activation і sandboxing -- це погано?
Це, скажімо так, не є суттєво.
>> що кульгавого є в тому, що мені більше не потрібно виконувати 15 пунктів неофіційного протоколу, коли я пишу демон?
Для вас, як для девелопера, мабуть добре.
>> systemd складається з багатьх компонентів (я би сказав, там забагато всього, ггг), багато компонентів моють feature creep, але загалом--це пречудова інженерна конструкція.
Не сумніваюся, що вона чудова, бо в мене в маку є launchd, який «просто працює». Але якщо він зламається, то я не зможу нічого в нім полагодити, бо не знаю, де в тої машини капот. :)
>> як Ви гадаете, чому всі популярні дістро стали systemd-based? Ви думаєте pkg maintainers мали велику жагу оновлювати половину своїх pkgs? ні. але 99% роботи у написанні і підтримці дістро є підтримка rpm/deb/etc pkgs. з systemd це набагато простіше.
Бо не мали де від того дітися: RH вагомо грюкнув кулаком по столу — усі погодилися.
no subject
Це, скажімо так, не є суттєво.
>> що кульгавого є в тому, що мені більше не потрібно виконувати 15 пунктів неофіційного протоколу, коли я пишу демон?
Для вас, як для девелопера, мабуть добре.
>> systemd складається з багатьх компонентів (я би сказав, там забагато всього, ггг), багато компонентів моють feature creep, але загалом--це пречудова інженерна конструкція.
Не сумніваюся, що вона чудова, бо в мене в маку є launchd, який «просто працює». Але якщо він зламається, то я не зможу нічого в нім полагодити, бо не знаю, де в тої машини капот. :)
>> як Ви гадаете, чому всі популярні дістро стали systemd-based? Ви думаєте pkg maintainers мали велику жагу оновлювати половину своїх pkgs? ні. але 99% роботи у написанні і підтримці дістро є підтримка rpm/deb/etc pkgs. з systemd це набагато простіше.
Бо не мали де від того дітися: RH вагомо грюкнув кулаком по столу — усі погодилися.