Am Wed, 25 Jul 2012 10:44:34 +0200 schrieb Nicolas Sebrecht <nsebrecht@xxxxxxxx>: > 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
