On 08/10/2012 09:43 AM, Michał Górny wrote: > vdr is a first example which comes to my mind. They workaround program > configuration limitations and the init.d scripts become a complex > extra-configuration parser + plugin loader. Well, another thing here is > that upstream AFAIK is not willing to cooperate to fix their config > parsing. > > 'oldnet' is an another example. I'm not saying it should go; I'm saying > it should be a stand-alone executable called from the init.d script. > > Last time I looked, squid init.d was performing post-inst in start(). > Many users may find that beneficial but that's not what init.d scripts > should be doing.
This discussion is really derailing. Currently most people using certain features from openrc feel quite defensive and mildly uneasy with the current situation since systemd is pretty much swallowing components we used to rely on and force radical changes w/out providing explanations to people that do not care and that are perfectly happy with what they have. Now Canek seems to feel like that I'm willing to kill systemd and make it impossible to use it in Gentoo. That's not the case, I consider systemd a bad idea since it is only geared to solve some specific issues and does that in a way that I consider dangerous for the global usage patterns I'm aware of. systemd ideas are interesting and for a dumb linux desktop the implementation would be ok. systemd doesn't work in many scenarios and when it gets pointed apparently there is a disagreement on that because "systemd is perfect" like it happens with it gets pointed that pulseaudio has shortcomings (that come from its design) or avahi doesn't seem that stable. I can live with a seldom broken audio subsystem and I can cope with the fact pidgin-bonjour could randomly crash, I'm not happy to be forced to move to something with the same attitude as my init system. The whole point of the debate should be if easier to have systemd split itself in usable components so people with certain focuses could leverage it on linux and replace those on non-linux (apparently not a chance) or have what we currently have and works decently and hopefully be compatible (so have a compatible interface for user-daemons, a compatible dbus interface for the desktop integrations and so on), not which project we should help to kill the others. lu
