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

[Stephen E. Baker]

> On 25/07/2012 5:54 AM, Heiko Baums wrote:
[snip]
> 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. 
This DAEMONS array is nice, one of the things I like about Arch, but it 
is specific to Arch not SysV.  If you run Gentoo, or others you won't 
have something like that, you'll have a program that arranges symlinks, 
not entirely unlike systemd.

Why you would want to specify which services had to come before or after 
which other services is obvious when you consider that systemd boots 
services in parallel.  There is no way in the current system, and no way 
without specifying, to boot several daemons at the same time and then 
boot other daemons afterwards that depend on them having completely 
launched.  Similarly with devices being available.  This is why people 
have to put in ugly hacks like sleep in daemons that require the network 
to be up. 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.
>> 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.
Odd, Arch uses SysV's init, but it certainly doesn't have a SysVinit 
init system. It's much closer to BSD, and a lot of the tools we use are 
custom.
Others include OpenRC (used by Gentoo), Upstart (used by Ubuntu) and of 
course systemd (used by Fedora)
> 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