On 10/21/2014 at 11:39 AM, Matthias Klumpp wrote: > 2014-10-21 17:24 GMT+02:00 Robert Lemmen <robertle@semistable.com>: > >> hi matthias, >> >> On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote: >>> first place. Having ten processes responsible for bits&pieces of >>> what systemd-as-PID1 does instead of one isn't a benefit -- not >>> if all you gain by that is nine additional processes. >>> >>> "It's a big monolithic thing, and big monolithic things are bad >>> and evil and non-Unix-y, so there!!1!" is not a valid argument. >> >> but that's the thing, to some (e.g. me) ten separate processes that >> each do a fairly small thing with understandable interfaces between >> them is an *enormous* benefit over one bigger thing that does all >> that in an integrated fashion. to the point that even if the one >> big thing would have nice,additional features, I would still opt >> for the decomposed one. > > Well, you just now described systemd. The systemd project develops > many small tools which do one thing ant interact together via > defined interfaces. > The init daemon is a bit more powerful that sysvinit, but it still > only does what it is supposed to do: Starting, stopping and > monitoring services. The other tools under the systemd umbrella do > different things. Is that really what the init daemon is supposed to do? At a glance at the sysvinit source, it doesn't look to me like /sbin/init itself does service management, in the "starting, stopping and monitoring services" form; at most, it seems to handle some subset of the "monitoring" part, in the form of noticing when something has died abnormally. (Which goes well beyond just services, when necessary.) From what I can see, it looks as if sysvinit's service management is actually handled pretty much entirely by sysv-rc, which is not PID 1. If that's correct, and if the systemd PID 1 binary handles service management, then that's something it's doing which the init daemon itself has not traditionally done. Which doesn't automatically mean that it shouldn't, but which does seem to eliminate the argument that it "only does what [the init daemon is] supposed to do". Looking at the sysvinit source for this, and thinking about the differences in relation to systemd, has led me to come up with some ideas in regard to possible init-system-et-al. design which I think may be interesting enough to be worth pursuing or at least discussing. However, that discussion would cease entirely to be remotely on-topic for debian-devel (even to whatever extent this entire thread isn't already offtopic). Any suggestions for a place where such discussion would be welcome or at least acceptable, and where it would reach people who are experienced with or at least interested in the design and implementation of init systems? (I suspect that the systemd development forums would satisfy the latter criterion but would not satisfy the former.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature