The 25/07/12, Heiko Baums wrote: > 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. Right. I don't pretend systemd is perfect. This concern is more about how to configure systemd, so it's more configuration interface thing rather than not following "Unix philosophy" by internals. Now, the CLI problem is limited to enabling/disabling daemons. Saying systemd is against Unix philosophy only because of that is a bit exaggerated, IMHO... Oh wait, there's also the ini configuration files. Well, this is still limited to the user interaction. > 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. Sorry to have affect you because of my semantic. > 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 might be true for a given distribution. Each has its own API and glitches. In a bigger perspective this is wrong. Let's manage more than a distribution to understand what I'm talking about. It's worse when you know that all daemons in a distribution might be configured than /one/ init system. This is the case for Ubuntu where all daemons are not upstart ready, for example... Enjoy! > > 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. Again, this sounds somewhat exaggerated. Other tools work this way (configuration files + CLI) whithout hurt: mdadm, udev, sysclt, grub... > 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. Full control is a licence issue, ONLY. What you're talking about is a totally different thing. It's wrong to talk about control for a software where the user interface is giving the _feeling_ that YOU have control over the software. > > 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. We just disagree here. No matter, it's just a matter of taste about the interpretation if this thread. > If this software would be that well-founded, nobody had a > problem with it, nobody would fear anything, Notice that "a well-founded software" and "users having a problem with it" are uncorrelated, to me: - A "well-founded software" is a software which matches what it has been written for. - A "user having problem" can either be a real problem from the software or anything about the user feelings. -- Nicolas Sebrecht
