On Sun, Jul 27, 2014 at 7:47 PM, Tom H <tomh0...@gmail.com> wrote: > On Thu, Jul 24, 2014 at 9:00 AM, Slavko <li...@slavino.sk> wrote: >> Dňa Thu, 24 Jul 2014 13:00:24 +0100 Tom Furie <t...@furie.org.uk> >> napísal: >>> >>> You are, of course, aware that testing and unstable are test platforms >>> where breakage is to be expected? They shouldn't be used for anything >>> "mission critical", that's what stable is for. >> >> No, i will not comply with this. >> >> The testing must be in state, where it must to boot (except some boot >> options tweaks) by default. I think, that nobody here will complain if >> some of software/services on testing doesn't work, but computer must to >> boot! > > Can you point to a document where such a commitment has been made or > such a criterion has been decided?
You've just touched my hotpoint, Tom -- The post that got me kicked off the Fedora developer list was the one a bit more than two years ago where I questioned Poettering's engineering qualifications specifically because he lead the putsch. (I'm apparently no longer on the auto-mod list over there, but I don't really care any more.) Engineering by putsch is simply not what qualified engineers do to users who have not agreed, up front and beforehand, to be fodder for the putsch. Yeah, when we agree to use Sid or Rawhide, we agree to a certain amount of being guinea pigs, but this is a level or two beyond that, even. Being a little less metaphorical, the shift from sysv-init to anything as comprehensive as systemd necessarily breaks APIs en-masse. The parts that are in the specs may be manageable, but it is known that in systems as complex as OSses, there are more implicit linkages than any single person or any committee can plan for. Implicit linkages are where the API providers' understandings and the API users' understandings have some common base that is not recognized as needed to be written down. But when you expand the reach of the API or the user domain, you discover that the common understanding is not there after all, and then programmers start engineering by rumor and superstition. Both the API and the user domain were not just drastically expanded, but also shifted in this case. Uhm, by shift, I mean that the focus has changed significantly. Systemd is not a replacement for sysv-init. It is a set of brand-new functionality that sysv-init was never intended to implement. And it kind-of-sort-of adds the sysv-init functionality as the spoonful of sugar that is supposed to make the medicine go down. Woops, that's more metaphor. One of the symptoms of this kind of implicit linkage is where the end users end up saying, well, the docs say ordering shouldn't matter, but in this particular case it does. (See several recent threads for recent examples.) The sort of changes being brought in by systemd are so sweeping that we cannot expect them all to be shaken out in the distro's experimental release, even if the agreement to be test users were to agree something to that extreme. So the stable users are going to experience downtime. Period. (I'm not going to bet one way or another as to whether Redhat, as a company, survives this. I will be surprised if it does not slow their profit margins down enough that the board members will be looking for scapegoats.) The real damage, we haven't really seen yet. Good engineers would have set up their own distro to implement systemd in, to knock the bugs out, to prove the utility, and to isolate the fallout. Refer to the way SELinux et. al. have been handled. Any less careful approach is beyond hubris. That's why the systemd group, et. al. are often accused of arrogance. I know you're no fan of systemd yourself, Tom, but you (and rest of the community) have to start seeing where you (and we) have been wangled. In this case, yeah, experimental is experimental, but there are limits. And that was not the way to have done it. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inewfsqxparv64qs1wreqwt29cpprhupakdxhr5mnc...@mail.gmail.com
