Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Excerpts from Thomas Goirand's message of 2014-02-11 00:02:38 -0800:
> On 02/11/2014 12:53 PM, Clint Byrum wrote:
> > Excerpts from Thomas Goirand's message of 2014-02-10 20:20:36 -0800:
> >> On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote:
> >>> Do we allow users to choose their FireWire stack, WiFi or Audio Driver
> >>> stack in the kernel? There were several alternative implementations
> >>> of these, yet we only provide one of each.
> >>
> >> I don't see why we would explicitly forbid this choice (which has
> >> nothing to do with what we provide by default). Last time I checked, it
> >> was possible for our users to rebuild their own kernel. We even provide
> >> some userland tools for that.
> >
> > In the case of init system choice, having choice means having packages
> > that work poorly with the non-default init system.
> >
> > Nobody wants to forbid OpenRC or Upstart. Having all four working init
> > systems is a lot like having kFreeBSD and Hurd.
> >
> > However, the reason we can have kFreeBSD is basically POSIX. Some things
> > don't work, but the majority of things do work. There is a long standing
> > set of rules that things play by for the most part, and when they diverge,
> > that is a choice they make.
> >
> > By and large these init systems work nothing like eachother. So having
> > lots of them, means having lots of variation in init scripts, or having
> > a lowest common denominator init format which AFAIK does not exist and
> > would not achieve anything a switch away from sysvinit is intended to
> > solve.
> >
> > So, perhaps if we teach Upstart and OpenRC to read systemd unit files,
> > and they all can be expected to behave similarly, this will work out.
> > Otherwise, giving everyone a choice just makes work for little gain.
>
> You are talking as if we were starting from zero. Reality: all of our
> packages support both sysv-rc and OpenRC. We only have to maintain that,
> which is anyway important for our non-linux ports, and none of us have a
> crystal ball to predict how it will happen. I don't think it's a good
> idea to just give-up, or to spread the word that we should (give-up)
> before things even happen.
>
One point of moving to a system like upstart or systemd is that the
sysvinit scripts do not run as scripts. They are little tiny declarative
files that run all or most in C. This speeds up boot, but only makes
sense if all of the early stage boot things make use of it.
Leaving most things to just use the sysvinit compatibility layer means
not realizing one of the more important benefits of the default init
system if it should in fact turn out to be systemd.
So at best you're talking about maintaining two for every daemon. That
is still roughly twice the maintenance work and twice the testing.
Not saying I like it, but that is where choice hurts Debian. Perhaps
having the choice will also help Debian enough to make it worthwhile.
Reply to: