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