hi matthias, On Tue, Oct 21, 2014 at 05:39:49PM +0200, Matthias Klumpp wrote: > Did you play around with systemd already? not as much as would be ideal, but I have been running it on one machine, adapted a few things that I run for starting, and trieid the monitoring/restart. but really, my main concerns are fueled by pages like this [0]. > 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 ok, the way you put this sounds great, but let me contrast that with the originall paragraph: 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. I don't quite see how these two paragraph line up. to me these seem to be contradicting a bit... The other point is what you expect from the interfaces between components. In the paragraph towards the top you just say "defined", but I am sure your quality requirements for an interface of that type are higher than that. I would argue that the most important aspect is compatibility across large range of versions of the interface, and a looseness that allows either end of the interface to be (partially) reimplemented in a different way. so for me "POSIX" is a well-defined, stable interface (not without problems, mind you). "DBUS" means next to nothing. There are a few symptoms that make me think that while an interface may actually be defined in some way, it is so specific that there really can only be a single implementation. In other words, what should really be an optional part now becomes a mandatory part of the implementation of the interface. For example, one of the core complaints about systemd is the fact that it is linux-only. I understand that cgroups is a nice facility, but if an init system can't start a process without it, then it simply is far too specific (for my taste). Equally, if my window manager has such specific and absolute requirements that there is only a single init system that can start it, then something is terribly amiss. it's just another process after all! but note that I have nothing against anyone using systemd, or it being supported in debian! what kinda rubs me the wrong way is intreoduction of something new and shiny with the expectation that it is now everyone else's job to make sure that the existing still works. The GR just says that your package (with the exceptions) must not be specific to an init system. That seems to be a no-brainer to me, of course a normal package must work independently of how or who started it! regards robert [0] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ -- Robert Lemmen http://www.semistable.com
Attachment:
signature.asc
Description: Digital signature