
On 1/6/2012 2:16 PM, Cristian Rodríguez wrote:
On 03/01/12 09:24, Carlos E. R. wrote:
With the old system, users can help and find/correct errors, tailor things for their particular needs. With systemd, few people can, we have to write bugzillas and wait instead.
The lack of understanding of people is hardly a problem on systemd don't you think ?
You continue to ignore problems that don't interest you, stating that they are invalid without demonstrating how or why. When people say "how do I do this with systemd" that is not an empty question, and requires an non-empty answer. As the person advocating a change, YOU are the one obligated to assume that whatever someone is doing right now via sysv init, it must be for a valid reason, and it is up to you to figure out and prove if it is not for a valid reason, and/or how to accomplish the same job via systemd. I can only assume the lack of understanding lies with you until you actually address these issues with something of more substance than merely claiming "that's not a problem" or "you're wrong for wanting to do that". Maybe they are, but they are not trying to inflict damage and disruption and expensive time and effort on anyone else. You are. I believe I have demonstrated enough understanding of my particular top problem by suggesting that at least one way to get a service (such as container-based vm's) that don't employ a constant daemon, but never the less do have a start action, a stop action, and a status action, is by adding a watchdog process that will serve as the always-running daemon process that systemd can then watch the way it expects to, and would perform those same actions that the init script currently does. But that's a shitty answer. That's a downgrade. I don't want or need another process running for this even if it would be a pretty light weight one. Ultimately, it's just adding a part to a system, thus increasing it's complexity and thus reducing it's robustness, by definition, inarguable, for no benefit AT ALL other than systemd pacification. None of the other almost-answers like static unit (vs service) or using the inotify or pidfile hooks can do the job that needs doing (yes I am quite familiar with inotify, I use it and incron for many things and I maintain up to date opensuse packages for many build targets in obs) but, all importantly, a fairly simple init script DOES, because it's a script, that performs actions and tests various conditions and calculates a correct and current answer based on that current info-gathering, and all of it is very application-specific and nothing that a generic service like systemd should ever have internal knowledge of. Now, if I'm wrong, and there IS a way to get all the proper functionality and behavior via systemd that I currently enjoy via sysv init, it is YOUR OBLIGATION, as the person who is trying to inflict such a disruptive change to such a long-standing core part of the system, to provide the drop-in systemd replacement. You will have to spend the time to understand what a container vm is, and how the current lxc tools work (and how the current libvirt lxc support does not), including the concept of application/service containers vs full system containers. You will have to forgive everyone whose life you are impacting for not being sympathetic that this would be a lot of work and consume a lot of your time. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org