Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

Hi!

Yes, please... I vote +1 for not silently replace sysvinit by systemd, when upgrading from Debian 7, to 8.

Also, during Debian 8 installation, please, provide an "altinit" option (http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can choose between systemd / sysvinit (before 1st boot). I know that it seems easy to just "apt-get install sysvinit-core" after install (1st boot) but, at least, Debian users will have an option to select a well tested, init system, while it is fully supported.

I'm seeing that, when with systemd, people are complaining that it does not always work, so, it seems that, when with systemd, Debian will stop working on a system that it always worked previously. Then, if people don't have a option to select the `sysvinit-core` during the installation, this will be a huge step back... They'll be forced to install Debian 7, then upgrade to Debian 8, on those machines that systemd seems to not work.

Also, the current Populatiry Contest is unfair, because it shows systemd winning, when it is being pushed.

I like the idea of a new init for this century BUT, since systemd developers lack of social skills (read: "Linus already kicked those guys from kernel dev"), it is wise to wait, at least, until ~2019, to replace sysvinit / upstart, by systemd. I'll stick with Debian 8 + sysvinit (or Ubuntu 14.04 with upstart), until ~2019.

I'm not against change, I'm already using IPv6 and NFTables on a daily basis... ;-)

BTW, if the `sysvinit-core` maintainers will maintain it for, lets say, until kFreeBSD dies, so, why not let people choose between the two? Then, we'll have time to see if this "systemd thing" will become a standard, or not. It is safe to keep two options, until systemd guys proves to the open source community, that they deserve more respect.

Also, providing two init systems during Debian 8 cycle (or until kFreeBSD remains around), will calm down people all over the world. People already don't like change (not me), and a pushed change is even worse, it will make them very unhappy / disappointed / betrayed.

Cheers!

Thiago

On 10 September 2014 18:36, Nick Phillips <nick.phillips@otago.ac.nz> wrote:

On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote:
> On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote:
> > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió:
> > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > > > > ]] Carlos Alberto Lopez Perez
> > > > >
> > > > > > But if you don't (Is not uncommon to have servers on remote locations
> > > > > > that are only accessible via ssh) and the machine don't boots
> > > > > > properly you can find yourself in trouble.
> > > > >
> > > > > Then surely you test the upgrade before making it live, using kvm
> > > > > -snapshot or similar functionality?
> > > >
> > > > This is simply not possible in physical live, productions servers on
> > > > remote CPDs.
> > >
> > > In that case you test on your staging server first...
> > >
> > > Ben.
> >
> > IF you have an staging server... some clients simply do not pay for it.
>
> Then they already accepted the risk of extended downtime during an
> upgrade.

That doesn't, however, mean that it is acceptable for us to recklessly
cause such downtime.

It seems to me that there is clearly a large group of users for whom an
automagic change in init system is desirable, and won't even be noticed.

There is however also a large group of sysadmins for whom a
noninteractive change of init system is a major, annoying issue. If our
priority really is our users, then we can't brush this under the carpet
with "you should have read the release notes" - and certainly not when
the problem has been foreseen. That is simply not how you respond to
someone you actually care about.

Debian has a good and hard-earned reputation for not messing up
sysadmins' changes; upgrading to systemd - however wonderful it is (and
I confess to having no opinion on that) - without at least a debconf
prompt of a reasonable priority telling them what is about to happen and
offering a bailout, is guaranteed to lose us reputation and users.

It doesn't matter whether we think that's reasonable or not, it is what
will happen.

So, is it actually feasible to provide such a prompt?

Cheers,

Nick
--
Nick Phillips / nick.phillips@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago