[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A few observations about systemd

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

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

Reply to: