Wouter and Gergely: software monopoly vs diversity

Eugene V. Lyubimkin · External Since: Oct 08, 2009 Posts: 54

Hello,

What is your vision about how many different software pieces can be
supported by Debian as a project for each part of the software stack,
would it be architectures, kernels, init systems, high-level package
managers, desktop environments or something else? In other words, would
you want Debian:

a) concentrate more on the things people use most;
b) or give more choices;
c) stay like it is now?

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer

--
To UNSUBSCRIBE, email to debian-vote-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Archive: http://lists.debian.org/20120316085028.GA14637@r500-debian

Wouter Verhelst · External Since: Nov 08, 2004 Posts: 653

Hi Eugene,

On Fri, Mar 16, 2012 at 10:50:28AM +0200, Eugene V. Lyubimkin wrote:
> Hello,
>
> What is your vision about how many different software pieces can be
> supported by Debian as a project for each part of the software stack,
> would it be architectures, kernels, init systems, high-level package
> managers, desktop environments or something else? In other words, would
> you want Debian:

Given the positions I've consistently defended over the years to
problems relating to this, I think most of this, in my case, isn't a
secret. Nevertheless, it's probably a good idea to make it somewhat more
explicit. Thanks for giving me the chance to do that.

> a) concentrate more on the things people use most;
> b) or give more choices;

For starters, I believe that in most cases, these two don't necessarily
need to be in conflict. We can concentrate on what people use most, make
that the default, and make that default work really really well, without
making it impossible to allow people to work on alternatives
(architectures, kernels, user interfaces).

In some cases, of course, that isn't the case, and then things get
somewhat more complex. A good example on that is the systemd discussion
on -devel currently: making systemd the default and required init
implementation would, in the current state of things, instantly axe the
kFreeBSD port. I am of the opinion that this simple fact therefore rules
out systemd as the default and required init implementation for Debian;
but it looks as if not everyone shares that opinion currently.

My personal opinion in the specific case of the systemd discussion, and
in any case of a conflict between the above two options in general,
would lean more towards providing more choices. However, I am well aware
that not everyone is of that same opinion; so while as DPL I might
participate in discussions about such a subject, it is unlikely I will
be wearing my DPL hat in such a discussion.

(Of course, the systemd discussion is a bit more complex than just the
above paragraph, but a full discussion about the ifs and maybes there
would be far beyond the scope of just answering your question)

> c) stay like it is now?

I believe my above position isn't that, but YMMV Smile

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

--
To UNSUBSCRIBE, email to debian-vote-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org
Archive: http://lists.debian.org/20120316135748.GH8426@grep.be

Paul Wise · External Since: Jan 30, 2007 Posts: 234

On Fri, Mar 16, 2012 at 9:57 PM, Wouter Verhelst wrote:

> In some cases, of course, that isn't the case, and then things get
> somewhat more complex. A good example on that is the systemd discussion
> on -devel currently: making systemd the default and required init
> implementation would, in the current state of things, instantly axe the
> kFreeBSD port. I am of the opinion that this simple fact therefore rules
> out systemd as the default and required init implementation for Debian;
> but it looks as if not everyone shares that opinion currently.

I think you will find that debootstrap supports installing different
packages on different architectures. For wheezy chroots it uses this
mechanism to install the right libc package but it could easily be
extended to use sysvinit on non-Linux architectures and
systemd/upstart on Linux ones. apt/dpkg support architecture-specific
depends. I'm assuming that d-i/tasksel also do so. So personally I
don't think switching the default init system on the Linux
architectures "instantly axes the kFreeBSD port" in any way at all.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-vote-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Archive: http://lists.debian.org/CAKTje6FisWDOjdExQa7VsqRi_ngynt7k+mQTV7+zVdwcM...dw@mail

Wouter Verhelst · External Since: Nov 08, 2004 Posts: 653

On Sat, Mar 17, 2012 at 09:01:55AM +0800, Paul Wise wrote:
> On Fri, Mar 16, 2012 at 9:57 PM, Wouter Verhelst wrote:
>
> > In some cases, of course, that isn't the case, and then things get
> > somewhat more complex. A good example on that is the systemd discussion
> > on -devel currently: making systemd the default and required init
> > implementation would, in the current state of things, instantly axe the
> > kFreeBSD port. I am of the opinion that this simple fact therefore rules
> > out systemd as the default and required init implementation for Debian;
> > but it looks as if not everyone shares that opinion currently.
>
> I think you will find that debootstrap supports installing different
> packages on different architectures.

Yes, but it's not about debootstrap.

If an init system that is incompatible with our current default init
system becomes the only supported init system, then architectures on
which that init system doesn't work, suddenly have no working init
anymore.

having a choice of multiple init implementations is indeed a good way of
fixing the issue, but that's not what some of the proponents of systemd
seem to be arguing for, and it's not what's relevant for this particular
question.

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

--
To UNSUBSCRIBE, email to debian-vote-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org
Archive: http://lists.debian.org/20120317174627.GJ10552@grep.be

Luk Claes · External Since: May 04, 2005 Posts: 752

On 03/17/2012 06:46 PM, Wouter Verhelst wrote:
> On Sat, Mar 17, 2012 at 09:01:55AM +0800, Paul Wise wrote:
>> On Fri, Mar 16, 2012 at 9:57 PM, Wouter Verhelst wrote:
>>
>>> In some cases, of course, that isn't the case, and then things get
>>> somewhat more complex. A good example on that is the systemd discussion
>>> on -devel currently: making systemd the default and required init
>>> implementation would, in the current state of things, instantly axe the
>>> kFreeBSD port. I am of the opinion that this simple fact therefore rules
>>> out systemd as the default and required init implementation for Debian;
>>> but it looks as if not everyone shares that opinion currently.
>>
>> I think you will find that debootstrap supports installing different
>> packages on different architectures.
>
> Yes, but it's not about debootstrap.
>
> If an init system that is incompatible with our current default init
> system becomes the only supported init system, then architectures on
> which that init system doesn't work, suddenly have no working init
> anymore.
>
> having a choice of multiple init implementations is indeed a good way of
> fixing the issue, but that's not what some of the proponents of systemd
> seem to be arguing for, and it's not what's relevant for this particular
> question.

AFAICS one is requesting to change the default to a dependency based
boot system as the early boot gets less and less reliable (networking as
the key example). The remaining issue seems to be choosing between
upstart and systemd as default. Obviously making sure initscripts keep
working will get harder and it's up to the ports that don't support the
default init system to choose the lesser of two evils (porting the
default init system or making sure initscripts keep working) IMHO.

Opposing evolution because some architectures don't follow it, will
probably only result in more tension. All ports have to evolve due to
changed circumstances. It's only when they do not that the cry to not
support them officially anymore gets louder and louder AFAICT.

Cheers

Luk

--
To UNSUBSCRIBE, email to debian-vote-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org
Archive: http://lists.debian.org/4F64D9A6.6020604@debian.org

Gergely Nagy · External Since: Jun 16, 2011 Posts: 35

"Eugene V. Lyubimkin" writes:

> What is your vision about how many different software pieces can be
> supported by Debian as a project for each part of the software stack,
> would it be architectures, kernels, init systems, high-level package
> managers, desktop environments or something else?

In short: as many as there are enough people to support them
with. Exceptions do exist, as always.

> In other words, would you want Debian:
>
> a) concentrate more on the things people use most;
> b) or give more choices;

A little bit of both, as these choices do not always conflict.

What people use most, should be the defaults in most cases. But that
does not prevent us from offering a choice, either. However, defaults
MUST be consistent, and if choosing a new default would kill off the
ability to choose, then I would advise against that change, as freedom
of choice is in my opinion one of the great strenghts of Debian.

However, too much choice is just as bad as none at all: one gets lost in
the maze, and it's a pain to maintain such a diverse system in the long
run, both for debian developers, and for up- and downstreams alike.

Ideally, we should have a balance of choice and maintainability. Where
that balance lies, depends on a lot of factors, ranging from the quality
of the choices, to the available manpower needed to keep all of them in
good shape, and so on and so forth.

There is no silver bullet: monopoly is just as bad as too many possible
choices. Ideally, we would need to strike a good balance, and have a
little bit of both.

--
|8]

--
To UNSUBSCRIBE, email to debian-vote-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org
Archive: http://lists.debian.org/87vclk1kqu.fsf@luthien.mhp