choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

"Eugene V. Lyubimkin" <jackyf@debian.org> writes:
> On 2012-08-10 09:09, Steve Langasek wrote:

>> No, it really isn't. It's about creating a technically excellent
>> operating system that meets our users needs.

>> Developers need the freedom to *make* autonomous technical choices as
>> part of the process of making Debian technically excellent; and in some
>> cases the answer for meeting our users needs is "both". But this
>> latter argument does not apply to core infrastructure decisions, and
>> arguing that Debian is *about* the freedom to choose is missing the
>> point.

> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

> I believe this hurts Debian (or any other project which chose to
> not accept choices in certain areas) in the long run and don't fit to
> 'making [...] technically excellent' well.

I think Steve's point is that the goal is to make Debian technically
excellent. Sometimes that means providing choice, and sometimes it
doesn't. All things being equal, I think a system that's flexible is more
technically excellent than one that isn't, but all things are almost never
equal (in one way or another).

There are choices that we don't support because the process of supporting
that choice would involve far more work than benefit, and the final goal
is excellence, not choice for its own sake. For example, we don't allow
users to replace the system C library with a different one. That's
something that we *could* do, but the general consensus of the project is
that investing our effort in that is not the best way to produce
excellence.

I happen to think that supporting multiple init systems *is* the correct
technical choice to achieve technical excellence, but I agree with Steve
that freedom to choose should not be stated as the end goal.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87628qz999.fsf@windlord.stanford.edu">http://lists.debian.org/87628qz999.fsf@windlord.stanford.edu

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

Le samedi 11 août 2012 Ã* 00:53 +0300, Eugene V. Lyubimkin a écrit :
> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

That’s a very theoretical reasoning. Practically, when you have several
init implementations, what you can do is limited by the least capable of
them — even worse, instead of bringing more features, you can only use
the intersection of their functionality.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1344640360.4958.20.camel@tomoyo

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

On 08/11/12 01:12, Russ Allbery wrote:
> There are choices that we don't support because the process of supporting
> that choice would involve far more work than benefit, and the final goal
> is excellence, not choice for its own sake. For example, we don't allow
> users to replace the system C library with a different one. That's
> something that we *could* do, but the general consensus of the project is
> that investing our effort in that is not the best way to produce
> excellence.

I kind of disagree with that. I don't think that the fact that we don't
support multiple C libraries is the result of a "consensus decision".

I think it's just because noone attempted to properly do that and prove
it's viability and usefulness either to a portion of the userbase or the
project as a whole.

Similarly, I don't think the kFreeBSD ports or any of the other Linux
architecture ports were a consensus decision. People just did it, the
work was of reasonable standards and useful both to expanding the
userbase and to improving the quality of the other ports.

People are working on building Debian with LLVM (which is great IMHO).
Very few people complained about that and the talk was very much
welcomed at DebConf. We even have a GSoC project about it. There are
other similar examples.

As for OpenRC, as far as I understand it, it's similar -but with its LSB
header compatibility much less intrusive- with file-rc. None of the two
are an /sbin/init replacement.

The fact that the systemd-upstart debate is hot and controversial
doesn't mean that everything else that is even remotely related to the
boot process must be rejected from the archive. And certainly not
because a few people think so and are being loud in a mailing list.

Regards,
Faidon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5025ABC8.8070908@debian.org">http://lists.debian.org/5025ABC8.8070908@debian.org

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

Faidon Liambotis <paravoid@debian.org> writes:
> On 08/11/12 01:12, Russ Allbery wrote:

>> There are choices that we don't support because the process of
>> supporting that choice would involve far more work than benefit, and
>> the final goal is excellence, not choice for its own sake. For
>> example, we don't allow users to replace the system C library with a
>> different one. That's something that we *could* do, but the general
>> consensus of the project is that investing our effort in that is not
>> the best way to produce excellence.

> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".

> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.

> Similarly, I don't think the kFreeBSD ports or any of the other Linux
> architecture ports were a consensus decision. People just did it, the
> work was of reasonable standards and useful both to expanding the
> userbase and to improving the quality of the other ports.

I think we're actually agreeing, so let me try to rephrase what I meant to
make that more obvious. :) I think Debian makes a lot of implicit
consensus decisions not to do something simply by no one going and doing
it. And this is particularly true of things like allowing multiple C
libraries that require lots of work by everyone in the project. People
realize how much work it would be up front and never attempt it, which is
a form of consensus decision-making.

It doesn't have to mean that we explicitly discussed it and decided not to
do it. In fact, I find the discussions about things like this to be
mostly useless. They're generally mostly conducted by a small number of
people who are usually bystanders to the actual work, the arguments become
quickly repetitive, and the discussions provide very little substantive
input into whether the work should continue or not.

The real way consensus decision-making tends to happen in the project is
that people try to do something and see how much push-back they get, often
with the help of a few highly-connected people in Debian who are able to
push on making a general change with the various teams. (And we have a
hard time doing things that are project-wide, because that process isn't
very formal.)

For things that someone can go work on by themselves, such as exploring
openrc, the most effective approach seems to be to open a discussion on
debian-devel if they want some input, read the first couple day's worth of
discussion, and then ignore the rest of the thread and just go on and do
whatever one feels the right thing is. Almost none of the subsequent
discussion after the first few days will be original or worth reading, let
alone responding to. Even for things that can't be done by one team,
seeking consensus by talking directly to the other teams and groups most
affected is probably going to be more productive than participating in a
100-message thread in debian-devel.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zk62uriw.fsf@windlord.stanford.edu">http://lists.debian.org/87zk62uriw.fsf@windlord.stanford.edu

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

On Sat, Aug 11, 2012 at 12:53:45AM +0300, Eugene V. Lyubimkin wrote:
> On 2012-08-10 09:09, Steve Langasek wrote:

> > > > Le vendredi 10 août 2012 à 17:04 +0900, heroxbd@gentoo.org a écrit :
> > > > > Debian is about the freedom to choose.

> > No, it really isn't. It's about creating a technically excellent operating
> > system that meets our users needs.

> > Developers need the freedom to *make* autonomous technical choices as part
> > of the process of making Debian technically excellent; and in some cases the
> > answer for meeting our users needs is "both". But this latter argument does
> > not apply to core infrastructure decisions, and arguing that Debian is
> > *about* the freedom to choose is missing the point.

> Declaring "one area -- one chosen tool" is declaring the monopoly in the
> area. As with other monopolies, this often leads to "vendor" lock-in,
> stagnation, stopping developing the standards. Have seen examples of all
> that occasionally.

... says the man who thinks multiarch should be held up indefinitely because
a perl reimplementation of apt should take precedence.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

â�¦ 11 août 2012 01:12 CEST, Josselin Mouette <joss@debian.org>Â*:

>> Declaring "one area -- one chosen tool" is declaring the monopoly in the
>> area. As with other monopolies, this often leads to "vendor" lock-in,
>> stagnation, stopping developing the standards. Have seen examples of all
>> that occasionally.
>
> That’s a very theoretical reasoning. Practically, when you have several
> init implementations, what you can do is limited by the least capable of
> them — even worse, instead of bringing more features, you can only use
> the intersection of their functionality.

There is a workaround for this: declaring that all daemons should
support systemd (or upstart), support for other init being done
through some compatibility layer or, exceptionally, by providing ad-hoc
init scripts.

This is the subject of one GSoC project (I don't know its status):
http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files

As long as the more capable init is used as reference, I really don't
care if people try to fit alternate inits.

If we cannot get a compatibility layer, I agree with you: we should move
forward to a more capable (event driven) init.
--
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

On Sat, 11 Aug 2012, Faidon Liambotis wrote:

> On 08/11/12 01:12, Russ Allbery wrote:
> > There are choices that we don't support because the process of supporting
> > that choice would involve far more work than benefit, and the final goal
> > is excellence, not choice for its own sake. For example, we don't allow
> > users to replace the system C library with a different one. That's
> > something that we *could* do, but the general consensus of the project is
> > that investing our effort in that is not the best way to produce
> > excellence.
>
> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".
>
> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.
>
> Similarly, I don't think the kFreeBSD ports or any of the other Linux
> architecture ports were a consensus decision. People just did it, the
> work was of reasonable standards and useful both to expanding the
> userbase and to improving the quality of the other ports.
>
> People are working on building Debian with LLVM (which is great IMHO).
> Very few people complained about that and the talk was very much
> welcomed at DebConf. We even have a GSoC project about it. There are
> other similar examples.
>
> As for OpenRC, as far as I understand it, it's similar -but with its LSB
> header compatibility much less intrusive- with file-rc. None of the two
> are an /sbin/init replacement.
In fact file-rc now supports depedency based booting and lsb headers. This is
not yet in wheezy but will hopefully get into wheezy.

Alex



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120811090705.GB8874@snow-crash.org">http://lists.debian.org/20120811090705.GB8874@snow-crash.org

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

> On Sat, Aug 11, 2012 at 03:38:25PM -0400, Chris Knadle wrote:
>> systemd may seem better in /most/ cases because it does have some nice
>> features, but I don't think it's better in *all* cases. systemd doesn't allow
>> shutdown/reboot from within KDE4
It *does* work for me here - KDM doesn't support systemd at time, but
if you install the systemd-sysvinit support (package named in a
similar way), everything will work perfectly well.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAKNHny9YmW0pQp0FYx6R4C9z9cRsPQsb=HUxS_revSDUjjZyy Q@mail.gmail.com

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

On Saturday, August 11, 2012 18:02:04, Matthias Klumpp wrote:
> > On Sat, Aug 11, 2012 at 03:38:25PM -0400, Chris Knadle wrote:
> >> systemd may seem better in /most/ cases because it does have some nice
> >> features, but I don't think it's better in *all* cases. systemd doesn't
> >> allow shutdown/reboot from within KDE4
>
> It *does* work for me here - KDM doesn't support systemd at time, but
> if you install the systemd-sysvinit support (package named in a
> similar way), everything will work perfectly well.

Hmm okay -- I'll give that a try. Thanks.

-- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

choice in core infrastructure decisions ( Bug#684396: ITP: openrc -- alternative boot mechanism)
 

On Fri, Aug 10, 2012 at 03:12:50PM -0700, Russ Allbery wrote:
> I think Steve's point is that the goal is to make Debian technically
> excellent. Sometimes that means providing choice, and sometimes it
> doesn't. All things being equal, I think a system that's flexible is more
> technically excellent than one that isn't, but all things are almost never
> equal (in one way or another).
[...]
> I happen to think that supporting multiple init systems *is* the correct
> technical choice to achieve technical excellence, but I agree with Steve
> that freedom to choose should not be stated as the end goal.

Absolutely, choice just for the sake of choice is not really a choice
at all, especially if they are all poor ones.

Just to bring this back on topic, if the initial tests of OpenRC
show it to be viable and that it's possible to upgrade seamlessly
from sysv-rc, then I would propose to drop sysv-rc entirely, rather
than having a choice here. OpenRC would be a replacement rather
than an alternative--I don't see much value in spending the effort
on maintaining two here, since OpenRC is a much more capable system.
Of course, this is quite a long way off--I've not personally booted a
Debian system with OpenRC yet. I did start the initial Debian
packaging work last night though.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120813074445.GQ25141@codelibre.net">http://lists.debian.org/20120813074445.GQ25141@codelibre.net