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
