Hi, On 01.01.2018 17:42, Josh Triplett wrote: > There's a difference between "dropping support" and "not mandating > support". Ideally, yes, but in practice the difference isn't very large. The main reasons I see for people to use sysvinit are: - reliability: there have been a few interesting surprises when systemd internal functionality changed. - standards compliance: you can use a common management framework for various SysV-compatible systems in a heterogeneous environment. - small footprint: starting a few daemons on an embedded system doesn't require anything more complex than a script to invoke all of them, so there is no point in keeping a complex program around to resolve dependencies. The first two go out of the window if init scripts become optional, and these are precisely the main reasons for me to run sysvinit. > It seems far harder to do so for a service that provides no > daemonization support at all, expects socket or D-Bus activation, > integrates with containerization, or otherwise makes use of the variety > of mechanisms that make it far easier to write more capable and secure > services these days.) A daemon must be capable of running standalone and dealing with the fallout of depended-on services shutting down, restarting, crashing or being generally unavailable. All of these are significantly harder to get right than startup in a SysV environment. Simon
Attachment:
signature.asc
Description: OpenPGP digital signature