multiarch, held up, precedence (Re: choice in core infrastructure decisions)
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 should be held up indefinitely', 'because' and 'a perl reimplementation of apt should take precedence'. I don't know where did you get what you wrote above from, but please refrain from publicly making further statements about what I think when these statements are not based on something I wrote myself. TIA. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120811080511.GC12900@r500-debian
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
❦ 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. > > 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) pgpMXfH80upPp.pgp Description: PGP signature
Re: choice in core infrastructure decisions (Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120811090705.gb8...@snow-crash.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
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 we have > a quite hostile upstream, *and* dismissing any other alternative, We are not dismissing any other alternative, upstart still looks like an option. We are dismissing just openrc because its incremental benefits are trivial. -- ciao, Marco signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
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 because it *seem* to look better *now*, knowing that we have >> a quite hostile upstream, *and* dismissing any other alternative, >> > We are not dismissing any other alternative, upstart still looks like > an option. > We are dismissing just openrc because its incremental benefits are > trivial. > Please stop saying "we". *You* are not Debian. Thanks. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502651b4.9030...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
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)
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. Kettle. Black. > It would be nice if you could explain to the readers in what way I have spoken in the name of Debian by writing "If we can have alternatives". Or maybe you totally missed the "if" in my sentence, showing an hypothesis? What if I write "If there was" instead of "if we can have"? No, I'm not at all guilty of the very thing that I accused you, contrary to what you are trying to demonstrate here. Also, this long thread has started because you started writing on the name of everyone else. If you don't want to make a fool of yourself, I would suggest you to stop doing so. I don't think I'm the only one to think this way also (this huge thread also demonstrates it). Thanks, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5026b391.8050...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
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 developing the standards. Have seen examples of all > > that occasionally. > > 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 we have > a quite hostile upstream, *and* dismissing any other alternative, > is a very dangerous bet which I don't think Debian should do. That > is, I believe, the most important point of all this thread. 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, which in the end made it more annoying than helpful for me so I ended up switching back to file-rc. > Let's welcome OpenRC and see how it goes... This doesn't mean that > we are choosing *now* what will be the *default* init system. Just > that we are open to a new alternative. If and when there are Debian packages available for OpenRC I'd like to try it. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: choice in core infrastructure decisions (Re: 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 That doesn't sound like an inherent systemd problem. -- WBR, wRAR signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny9YmW0pQp0FYx6R4C9z9cRsPQsb=huxs_revsdujjz...@mail.gmail.com
Re: choice in core infrastructure decisions (Re: 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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
