[arch-general] My end-user $0.02 on /etc/rc.conf splitting.

[Tom Gundersen]

On Tue, Jul 24, 2012 at 3:24 PM, Baho Utot <baho-utot at columbus.rr.com> wrote:
> I am sorry you think any thing you have will be a waste of time.
> I am looking at this "problem" of moving to systemd, staying with current
> init scripts or moving in the LSB init scripts direction. In order for one
> to make an informed decision one needs to consider all the facts.
> Without your insight or wisdom how would/will I do that?
>
> Discussion is healthy

I'm happy to discuss and answer any questions. However, Kevin's emails
were: off-topic (this thread was not on systemd, but on rc.conf),
irrelevant (the kind of embedded systems he is talking about would
never run Arch), plain wrong (his descriptions of how systemd works
and how to use it has nothing to do with reality).

To give a couple of comments, for those who have not looked at systemd yet:

Firstly, systemd is bigger and does more than sysvinit. The reason for
this is that it moves functionality out of the individual daemons and
into init. This functionality is stuff that would otherwise have been
implemented over and over again in every daemon or rc script, each
time it is implemented it would be a potential for bugs. Now we have
it all in one place, where we can all work together to test and review
it. The kind of features implemented in this way are for the purposes
of security and reliability of the daemons on your system (i.e. it
will monitor them and deal with crashes, it will lock down the kinds
of things a daemon is allowed to do, what directories it can
read/write to, what system calls it can make, what user it is run as,
etc). I would not call this bloat, quite the opposite. It means that
the total amount of code on your system, and the total amount of
potential for bugs drastically decreases.

Secondly, most of the functionality of systemd is separated out in
separate processes/tools, and are not part of PID1. In fact, we use
these tools also in initscripts, and this is why I believe we will be
able to maintain initscripts, even if systemd should take over for
most users. Initscripts currently use the following systemd tools:

systemd-module-load
systemd-udevd
systemd-cryptsetup
systemd-tmpfiles
systemd-sysctl
systemd-binfmt
systemd-random-seed
systemd-vconsole-setup
systemd-remount-fs

HTH,

Tom