Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 03:43:40PM -0500, Tanstaafl wrote:
> On 11/15/2014 7:20 AM, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > On Vi, 14 nov 14, 08:55:47, Tanstaafl wrote:
> >> On 11/14/2014 5:26 AM, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >>> It was claimed that sysvinit was the default *and only* (emphasis not
> >>> mine) init, and therefore no selection was needed, but now that there
> >>> are several a selection suddenly is needed.
> >>
> >> I don't recall claiming that sysvinit was the *only* init, nor do I
> >> recall anyone else making such a claim.
> >
> > https://lists.debian.org/debian-user/2014/11/msg00814.html
> > Maybe a language issue? (I'm not a native speaker).
>
> Nope, that was me and I actually did say it... weird that I didn't
> remember saying that... but it doesn't really change anything...
That's a attempt at moonlighting people, not very classy.
> Just because other init systems exist doesn't mean they were actually
> being used, other than maybe just someone toying around.
>
> Are you seriously suggesting that anything other than a tiny and
> insignificant fraction were using anything other than sysvinit (until
> systemd came along at least)?
> > For fresh installs, given that there is a suitable[1] workaround
>
> <sigh>
>
> how many times does it have to be said - that is not a workaround for a
> CLEAN INSTALL.
>
> > For dist-upgrades, even assuming systems will be switched automatically
> > (which is still undecided):
> >
> > - one can prevent switching by installing sysvinit-core before the
> > dist-upgrade step
> > - the sysvinit package contains the binary /lib/sysvinit/init which can
> > be used with the init= kernel parameter
> > - there is a grub patch[3] pending integration[4] to offer an
> > alternative sysvinit boot option
>
> Yes, and how long after upgrading to jessie staying with sysvinit until
> things start breaking (most likely subtle breakage, which is the least
> desirable on a server).
The distinction server/desktop is clearly not relevent. There is huge deployment
of Debian desktop, and they do not want subtle breakage anymore than others people.
Now, if there is breakage ( so far, you speak of the future ), it will be because
no one detected them in the first place, and given the Debian structure,
that mean that not enough people were using that setup on testing and/or unstable.
For this, there is a few fixes :
- find people to test that ( starting by yourself ). If half of the people who rant since a few months
on this list were doing tests and filling bug report, this would be rock solid.
- automate that testing ( Ubuntu has a lot of ressources on the topic https://wiki.ubuntu.com/Testing/Automation
and so does OpenSuse ).
- make sure that bugfixes are propagated faster to stable and provides patches and or bugs when stable is here.
Now of course, if no one take time to do any of theses, that's gonna cause problem. But that's
a problem because people who want the work to happen do not make it happen. ( and no "we do not
have time", if people have time to post on ml, they have time to post bug reports ).
> > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
> > [4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html
> >
> > The transition plan[5] has been posted on -devel since July with no
> > objections.
>
> Maybe because most debian *users* don't follow the dev list because they
> aren't devs...
At the same time, most debian users likely do not really care about transition
plan and systemd. It was widely published everywhere in March and yet, no one would have cared if this
mattered ?
And those that care should make the efforts to follow what happen in the distribution, reading
one or two time a week the title on a web archive is not a huge time investment.
( at least not more than following this lists and answering on it )
--
l.
Reply to: