On 2/6/2012 2:23 PM, Vincent Untz wrote:
Le lundi 06 février 2012, à 18:17 +0100, Robert Kaiser a écrit :
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Obvious +1 on this.
But let me hijack your good comment with a request to everybody keeping this thread alive: the discussion doesn't bring anything useful anymore now. We just hear the same points again and again. When a decision will have to be taken, it will be taken by the people involved in the area (including systemd and sysvinit package maintainers) and the release team [1].
So can we stop this thread now? And in general, can we try to stop keeping alive threads when it's obvious they don't bring anything anymore?
Why? Has the risk of my system getting F*'ed up gone away? No? Then why should I stop saying I don't want it? There are three main problems (for me) with systemd. Two are technical and solvable. The other is personal and not. Tech problem 1: A system based on scripts is infinitely more flexible, transparent, debugable, than a system based on a binary compiled c program. That has uncountable value and I want that. And bonus, we already have it. Why throw it away? Tech problem 2: ExecStatus. Systemd appears to be fundamentaly event driven, it reacts to triggers such as a process gong away or inotify telling it a files status changed. ExecStatus is probably hard to do because the very idea doesn't make any sense from a "watch for events and then react to them" stand point. Systemd wants to watch for some sort of event and then react when it happens, but in my LXC example, there is no event to watch for*. Sysv init works because sysv init does both, in /etc/inittab it watches for events and reacts immediately, and running the various init scripts only when the user asked, not in response to any sort of trigger. So in the lxc example, the init script has a perfectly well-working startup and shutdown, AND a status. And the shutdown action uses the status action to know when it's ok to exit and allow the shutdown to proceed. But it has to loop, re-running the status action over again until it finally shows that all vm's are gone. Systemd would have to run ExecStatus every few seconds 24/7 to essentially poll for something that it can't set a properly efficient watch on, which it quite understandably refuses to do. Personal problem: The people behind systemd refuse to acknowledge the technical problems and refuse to either solve them or entertain someone else solving them. All of this may change in time, but it's the current state of affairs, and so at current, I object highly to systemd. In time, if enough other people work on systemd and add features that the author doesn't want and has successfully avoided so far, then I see no reason why eventually it can't be capable of providing both sorts of systems, efficient, orderly, highly managed ones where all processes are managed by systemd itself, and yet still have the flexibility for the script-writing admin or user to be able to do whatever they themselves decide they need to do. Systemd can never include official managed orderly support for every thing anyone ever wrote into an init script. Nor should it. Something like systemd has to stay generic so that it applies equally to all machines. Any weird stuff needs to be in scripts that vendors, admins, and users supply themselves. It's true that there is SOME facility for that with systemd right now but it's not good enough. systemd does make some fundamental assumptions that simply aren't true, and you simply can't reproduce the necessary behavior in systemd right now. Frankly, for most services and other boot/shutdown actions, I'd welcome a transition to having something like systemd handle the nuts & bolts of actually starting/monitoring/stopping the daemons. It could eventually do a better job than most scripts do, and it would be consistent, all services benefit from systemd's quality sort of as if all services had the ultimate perfect init script. The problem is the attitude of the systemd author and certain supporters that disregards all other considerations. There are personal attacks because the biggest problem IS PERSONAL. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org