| |||||||||||||
GNOME and/or systemdGNOME and/or systemdPosted Nov 1, 2012 23:42 UTC (Thu) by apoelstra (subscriber, #75205)In reply to: GNOME and/or systemd by HelloWorld Parent article: GNOME and/or systemd
> So your logic is basically that out of the existing init implementations you pick one of which you *know* it's broken (being unable to do basic things like reliably stopping a service) over one that *might* be broken?
Given a choice between "I know how this is broken", and "I don't know how this is broken, and even if I did, that could change in a month", I'd take the former.
Having said that, I've been using systemd since it became the default on Fedora, and I've really had to go out of my way to break it.
(Log in to post comments)
GNOME and/or systemd Posted Nov 2, 2012 0:56 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> "I don't know how this is broken, and even if I did, that could change in a month"
Yeah, like every init implementation must be broken and the only difference between them is how.
Sorry, but "it changes too fast and is thus too unstable" is just a knee-jerk reaction to any kind of change, be it for the better or for the worse. It is *not* what I consider a sensible criticism.
GNOME and/or systemd Posted Nov 2, 2012 8:01 UTC (Fri) by paulj (subscriber, #341) [Link]
It's perfectly sensible. Change in software leads to bugs - inescapable fact. Further, it can take time to find bugs, because some of them will live in rarely exercised code paths. General software changes tend to result in net positive change in the # of bugs. Changes that are strictly limited to fixing bugs can average to a net negative change in # of bugs, if done with care.
So if you take a piece of software, with its features just developed to an acceptable state, then compare that software with itself after a long period of use, it should be obvious that a lot more bugs will be /known/ about after the period of use. That information alone is worth something if you want to understand the behaviour and stability of a system in the face of whatever inputs. It means if needs be you could choose to limit the input in order to avoid whatever bugs. Further, if during that period of use those bugs are fixed (and fixes strictly limited to that), then the software at the end stands a good chance of being less buggy than the software at the beginning, for the given features.
This all sounds obvious to me. In case it isn't to you, or you think it's hand-wavingly subjective, let me point that the like of RedHat objectively earn billions of $ per annum exploiting this.
|
|||||||||||||