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

2012-08-11 Thread Chris Knadle
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 shutdo

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

2012-08-11 Thread Matthias Klumpp
> 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'

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

2012-08-11 Thread Andrey Rahmatullin
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 That doesn't sound like an inherent systemd

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

2012-08-11 Thread Chris Knadle
On Saturday, August 11, 2012 01:12:10, Thomas Goirand wrote: > On 08/11/2012 05:53 AM, Eugene V. Lyubimkin wrote: > > 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 developin

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

2012-08-11 Thread Thomas Goirand
On 08/11/2012 10:29 PM, Marco d'Itri wrote: > On Aug 11, Thomas Goirand wrote: > > the programs are systemd and udev. If we can have an alternative, >^^ > > >> Please stop saying "we". *You* are not Debian. Thanks. >> > Pot.

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

2012-08-11 Thread Marco d'Itri
On Aug 11, Thomas Goirand wrote: > >> the programs are systemd and udev. If we can have an alternative, ^^ > Please stop saying "we". *You* are not Debian. Thanks. Pot. Kettle. Black. -- ciao, Marco signature.asc Description: Digital signature

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

2012-08-11 Thread Thomas Goirand
On 08/11/2012 05:14 PM, Marco d'Itri wrote: > On Aug 11, Thomas Goirand wrote >> Exactly! And in this particular case, the "vendor" is RedHat, and >> the programs are systemd and udev. If we can have an alternative, >> using OpenRC and mdev, then I really welcome it! Choosing systemd >> just becau

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

2012-08-11 Thread Marco d'Itri
On Aug 11, Thomas Goirand wrote: > Exactly! And in this particular case, the "vendor" is RedHat, and > the programs are systemd and udev. If we can have an alternative, > using OpenRC and mdev, then I really welcome it! Choosing systemd > just because it *seem* to look better *now*, knowing that

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

2012-08-11 Thread Alexander Wirt
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 exam

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

2012-08-11 Thread Vincent Bernat
❦ 11 août 2012 01:12 CEST, Josselin Mouette  : >> 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. > >

multiarch, held up, precedence (Re: choice in core infrastructure decisions)

2012-08-11 Thread Eugene V. Lyubimkin
Too bad, a personal attack in the first (level of) answer already. On 2012-08-10 20:22, Steve Langasek wrote: [...] > ... says the man who thinks multiarch should be held up indefinitely because > a perl reimplementation of apt should take precedence. No, I don't think so. Neither of 'multiarch s