On Mon, Jul 25, 2011 at 12:41:59AM +0200, Tollef Fog Heen wrote: > ]] Wouter Verhelst > > Hi Wouter, > > | At any rate, by not wanting to do scripts, you're making life harder for > | yourself, since now you suddenly have to implement everything what > | people have trivially done in shell scripts for years in C. Writing > | flawless C isn't exactly easy either[1], and even if systemd's author is > | a perfect coder (which he isn't, since perfection does not exist), > | there's going to be a need to have some other people write some systemd > | module at some point in the future, since 'plain' systemd doesn't do > | what their software requires, or what their corporate environment likes, > | or whatever, and they're going to make mistakes. > > There's not such thing as a systemd module. (I assume you're not > talking about the systemd units which is the collective name for mounts, > services and so on.) I saw someone point to files in /usr somewhere from the systemd package that seemed a like modules to me, but I could have misunderstood what they were. What matters is not whether it's a loadable module or a separate process or whatever, but that it's a piece of C code specifically written to extend systemd functionality, which would previously have been written in a script. > | And as a result, rather than have an initscript that does the > | equivalent of "killall -KILL -1", you're going to have someone > | implement socket enablement (or whatever it's called) incorrectly, > | thereby creating a remotely exploitable buffer overflow. > > If you need socket activation, you obviously have to write the code to > do so. There is nothing in systemd itself that requires you to use > socket activation unless it actually gains you something. > > I have no idea why you are confusing the idea of stopping a service > using (or doing a reload) using killall and socket activation, unless > you're just doing this to rant, though. Please grab me here at debconf > (or send email) if you're interested in having a discussion about it. To be perfectly frank, I'm not interested in systemd; it's just that I'm sceptical about it, and about its motives. That doesn't mean I'm opposed to it being uploaded, or even to it being made the default if it can be done in a technically sound way that would not either make the kFreeBSD ports impossible, or require SysV initscripts, *and* systemd unit files, *and* upstart stuff, and so on ad nauseum. I've seen people suggest in this thread to use some script to convert systemd unit files to sysv init scripts, and/or to whatever upstart calls its configuration; and while I can see that being done, I wonder whether using systemd files as 'source' for the conversion would be the better option, as opposed to something a little more under our control--if some other init system were to have a feature that systemd does not support, then this feature could not be used by Debian packages, since there's no way to implement it in a systemd unit file. We've implemented similar meta configuration for cron implementations, window manager menu systems, and a multitude of other things. I don't see why we couldn't do the same for init systems. In fact, we've done so for a long time, and it is still supported to some extent. All that's really needed, is to make it a bit more meta, so that the simple cases are covered by the meta language, and the more complex cases can be handled by shipping specific configuration files or init scripts, or some such. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a
Attachment:
signature.asc
Description: Digital signature