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

[Heiko Baums]

Am Wed, 25 Jul 2012 10:44:34 +0200
schrieb Nicolas Sebrecht <nsebrecht at piing.fr>:

> I can find anything in systemd which could make think of the registry
> on Windows.

I didn't say that.

> You are mixing up two things:
> - adding/removing services on boot;
> - configuring the services.
> 
> The first - adding/removing services - changes with systemd. Yes, it
> is done using a dedicated command (which comes naturally with
> autocompletion, here with zsh at least). This is for services provided
> by the distribution.

And this is against UNIX philosophy and makes it like something
proprietary, at least it's anything else than comfortable. Why not just
using a simple text file where I can list every "service" that I want
to have started? systemd could easily read this file and do whatever it
thinks to have been done internally.

Btw., it's called "daemon" in Linux and UNIX. It's called "service" in
Windoze. So one more step towards a second Windoze. The naming scheme
in systemd is also not really the best.

If people want a second Windoze they should stay with Windoze or help
to improve ReactOS.

> If a service is not provided:
> - with SysVinit you have to write the whole script usually relying on
>   whatever library the distribution provides (which tend to be
>   error-prone);
> - with systemd, you just write a configuration file.

Writing such a "whole" script is usually very easy and pretty little
error-prone. A configuration file can also be pretty inconvenient. I
haven't yet tested systemd, but from what I saw so far it doesn't look
too intuitive or easy. But maybe I'm wrong in this case.

Why do I have to tell systemd in all of those init scripts what
"service" has to run before or after this "service"? In DAEMONS in
rc.conf I just have a list of daemons I want to have started in one
single line. And the order in which they have to be started is the
order in which I list those daemons. Just plain and simple, and can
easily be parsed.

> For the second, whether you use systemd or SysVinit, configuring a
> service is typically done by editing the configuration file dedicated
> to this service.  In systemd, the file is declared like this
> 
>   EnvironmentFile=/etc/conf.d/nfs
> 
> which is by itself much easier to hack (rather than reading in a shell
> script to find where and how such a file is used).

You really don't need to read in a shell script to find where and how a
config file is used. With SysVinit you have a rc script in /etc/rc.d
and the corresponding config file in /etc/conf.d, both have the same
name and the config files are usually very well documented, either by
comments or by a man page.

And what's hard in reading a very short init script with only a few
lines? Btw., most lines are always the same (function declarations,
case structures, etc.). The only important part is usually only one
line.

> This is systemd internals. It's not expected from the user to play
> with symlinks.

Just like in proprietary software. Once again: Why does it need such
symlinks in some cryptic directories? The point is, I want to have full
control over my system and not to rely on some software's internals.
And I don't want to read source codes to know what an init system is
doing. And full control includes knowing what file is saved where and
doing what.

> No, I won't assume something that the software is going wrong. I
> assume the change raise fear, whether it is well-founded or not.

Wrong, if there's such a long discussion, there is something going
pretty wrong. If this software would be that well-founded, nobody had a
problem with it, nobody would fear anything, and there would only be a
very short discussion. Someone asks or mentions his concerns, somebody
else clarifies it, and everything is good. This is not the case with
Poetterix.

And like I said before, I never - never ever - saw such a long
discussion and so many concerns about a software like I saw for
PulseAudio and systemd. So something must go pretty wrong in this case.
This software can't be so well-founded. The people who are discussing
about it, who have concerns against it and/or don't like systemd are not
all stupid.

> OTOH for the systemd case, we are changing of paradigm for the boot
> process. I'm not aware of such a change in the boot process for years.
> All recent event-based init systems have raise fear.

Which init systems? I only know SysVinit. And why wasn't there a change
for years? Actually there was never a change. Because this init system
is so bad? I would rather say because it's so well tested and approved,
and because it's simple and just works and does what it is supposed to
do.

Maybe there are things that can be improved. Maybe there is code which
has to be written or executed more than once with SysVinit. Well, this
could be changed and improved. If this justifies a complete new init
system is questionable I think.

Heiko