Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
+++ Faidon Liambotis [2012-08-11 03:48 +0300]: 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. Not wishing to get into the general argument, but just to clarify that in fact this (enabling an alternative c-library) has been done in the past, showing that it is technically possible. The SLIND project (http://wiki.network-crawler.de/index.php/SLIND_Siemens_Linux_Distribution) rebuilt a reasonable subset of debian against uclibc. dpkg has had support for uclibc-arch for some years. It's not actually technically very difficult, although proper support would involve some intrusive changes in some places. It would actually be useful to quite a lot of people if a core subset of Debian was easily buildable for use with uclibc and busybox, but so far this work has always been done in forks and derivatives, and not pushed back in, which makes it very hard to maintain. Deciding whether that was still relevant or worth the effort would no doubt require another long thread :-) Steve and Russ have it right. We strive for technical excellence and the widest functional coverage that can sensibly be achieved in the context of a binary distro and the available resources. The implies plenty of choice, but not choice for its own sake. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20120902024201.gz27...@stoneboat.aleph1.co.uk
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
Le samedi 11 août 2012 à 15:38 -0400, Chris Knadle a écrit : 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 In the beginning, ConsoleKit didn’t allow shutdown/reboot from within KDE4. Maybe one of the KDE maintainers will remind us how many lines did the patch measure, but ISTR it’s less than 10. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1345459472.5401.34.camel@tomoyo
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Mon, Aug 20, 2012 at 12:44:32PM +0200, Josselin Mouette wrote: Le samedi 11 août 2012 à 15:38 -0400, Chris Knadle a écrit : 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 In the beginning, ConsoleKit didn’t allow shutdown/reboot from within KDE4. Maybe one of the KDE maintainers will remind us how many lines did the patch measure, but ISTR it’s less than 10. The version in wheezy is crawling with race conditions that make shutdown/reboot attempts randomly fail, seemingly on any desktop environment (I reproduced this on Gnome 3, XFCE, Mate, didn't try KDE). The fail message claims shutdown is not allowed because multiple users are logged in. I investigated the problem, and it turns out it would be pretty hard to fix, certainly not in a matter of 10 lines. Currently, a shutdown/reboot sequence: * sends signals to your processes in the session (tty ones get SIGHUP) * sends a request over dbus to consolekit * if any process in the session is setuid/setgid and still alive, consolekit responds with a failure * a window asking for root's password is spawned; cancelling it will spawn ANOTHER message box claiming shutdown is not allowed (which was already mentioned in the root password question) I see no obvious way to fix this -- merely waiting a bit longer is not going to help as there's no bound on how long processes take to die on a sufficiently loaded system[1]. And you can't tell a process that merely takes some time to die from one like wget that handles the signal and continues. One idea would be to display the authentication box but keep repeatedly requesting shutdown while the box is up. [1]. Especially ex-Windows users assume that a on a barely responsive system, a shutdown attempt is more likely to succeed than trying to find and kill the offender; in a GUI and for non-technical users that's not entirely without merit. And then, the shutdown attempt will be hit by this race. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 08/13/2012 04:50 AM, Marco d'Itri wrote: Waste of time, mdev lacks critical features like modules autoloading so it is laughable to argue that it is a credible udev replacement for any use case except (some) embedded systems. If the time will come the interested parties will fork udev, but let's not overreact. Isn't forking udev something similar to working on mdev? How many people would you have working on a udev fork, compared to the Gentoo guys working on mdev *already*, freeing us from a hostile upstream? At many level, udev has been really annoying, breaking upgrades and so on. As one wrote previously: mdev and OpenRC lack hostile upstreams! :) If there's some people working on a credible udev replacement, please, let's not laugh about it, and hope it soon integrates the needed features. I salute those trying to help to move in this direction. Let's also not forget that we have quite some time remaining until Jessie will be released. Can't you give them a chance? 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/50289f66.2050...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
* Marco d'Itri m...@linux.it [2012-08-11 11:30]: We are not dismissing any other alternative, upstart still looks like an option. We are dismissing just openrc because its incremental benefits are trivial. You don't speak on behalf of the debian project so please refrein from using we - you don't speak for me. Thanks, Martin -- 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/20120813071148.gj10...@anguilla.debian.or.at
Re: choice in core infrastructure decisions (Re: 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/Linuxhttp://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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813074445.gq25...@codelibre.net
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Aug 13, Thomas Goirand z...@debian.org wrote: Isn't forking udev something similar to working on mdev? How many people No, you just have to look at the code bases and features set to understand why. At many level, udev has been really annoying, breaking upgrades and so on. I can't help with you being annoyed by any package, sorry. As one wrote previously: mdev and OpenRC lack hostile upstreams! :) They also lack solving large parts of the problem space. -- ciao, Marco signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 08/13/2012 05:20 PM, Marco d'Itri wrote: As one wrote previously: mdev and OpenRC lack hostile upstreams! :) They also lack solving large parts of the problem space. I don't think anyone denies that fact. Hopefully, this will change. 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/5028e854.6010...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 08/13/2012 03:44 PM, Roger Leigh wrote: I did start the initial Debian packaging work last night though. Is this available in a Git somewhere? 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/5028e9ce.5000...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Mon, Aug 13, 2012 at 07:49:34PM +0800, Thomas Goirand wrote: On 08/13/2012 03:44 PM, Roger Leigh wrote: I did start the initial Debian packaging work last night though. Is this available in a Git somewhere? It's here: http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git;a=shortlog;h=refs/heads/debian It's on collab-maint, so anyone can contribute to it. Benda Xu's patches are at http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813121756.gr25...@codelibre.net
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Mon, 13 Aug 2012, Roger Leigh wrote: 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. Looks like a good plan to me. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120813164908.gb3...@khazad-dum.debian.net
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 13.08.2012 00:50, Marco d'Itri wrote: On Aug 12, Roger Leigh rle...@codelibre.net wrote: Not good. Time to look a bit more seriously at mdev then? Waste of time, mdev lacks critical features like modules autoloading so it is laughable to argue that it is a credible udev replacement for It is laughable to argue that module autoloading is any more complex than a call to `modprobe $MODALIAS'. Thanks, /mjt -- 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/5029859c.2090...@msgid.tls.msk.ru
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 11/08/12 07:12, 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. 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. FYI, I just saw this: Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely - Lennart Poettering (lists.freedesktop.org) http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html http://www.reddit.com/r/linux/comments/y3ao1/yes_udev_on_nonsystemd_systems_is_in_our_eyes_a/ signature.asc Description: OpenPGP digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Aug 12, Carlos Alberto Lopez Perez clo...@igalia.com wrote: Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely - Lennart Poettering (lists.freedesktop.org) If this will become true, I am sure that in the event that Debian will choose to not adopt systemd then we, Ubuntu and the other interested distributions will work out something. :-) This is annoying on many levels, but like most Linux core infrastructure udev is a Red Hat project and they decide which direction it takes. You do not like this? Then start being upstream for something relevant. -- ciao, Marco signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Sun, Aug 12, 2012 at 09:01:38PM +0200, Carlos Alberto Lopez Perez wrote: On 11/08/12 07:12, 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. 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. FYI, I just saw this: Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely - Lennart Poettering (lists.freedesktop.org) Not good. Time to look a bit more seriously at mdev then? The Gentoo folks have mdev support; it works with OpenRC. However, it looks like there would be some regressions. It looks like at the moment, xserver-xorg can't get device info from mdev, so needs manual configuration, and you have to use dmsetup to create LVM device nodes. So it's not /yet/ a direct drop-in replacement for udev, but with a bit more work it could be. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120812195440.gl25...@codelibre.net
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
Roger Leigh rle...@codelibre.net writes: On Sun, Aug 12, 2012 at 09:01:38PM +0200, Carlos Alberto Lopez Perez wrote: Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely - Lennart Poettering (lists.freedesktop.org) Not good. Time to look a bit more seriously at mdev then? While there's certainly merit in that, we should probably also not overreact to one statement from Lennart on a mailing list about something that he hopes to do eventually, with no concrete plan or date. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874no7vow7@windlord.stanford.edu
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On Aug 12, Roger Leigh rle...@codelibre.net wrote: Not good. Time to look a bit more seriously at mdev then? Waste of time, mdev lacks critical features like modules autoloading so it is laughable to argue that it is a credible udev replacement for any use case except (some) embedded systems. If the time will come the interested parties will fork udev, but let's not overreact. -- ciao, Marco signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
❦ 11 août 2012 01:12 CEST, Josselin Mouette j...@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) 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 z...@debian.org 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 z...@debian.org 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 z...@debian.org 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 z...@debian.org 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.
choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 2012-08-10 09:09, Steve Langasek wrote: [...] Le vendredi 10 août 2012 à 17:04 +0900, hero...@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. 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. YMMV. -- 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/20120810215345.GB12900@r500-debian
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
Eugene V. Lyubimkin jac...@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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87628qz999@windlord.stanford.edu
Re: choice in core infrastructure decisions (Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344640360.4958.20.camel@tomoyo
Re: choice in core infrastructure decisions (Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5025abc8.8070...@debian.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
Faidon Liambotis parav...@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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zk62uriw@windlord.stanford.edu
Re: choice in core infrastructure decisions (Re: 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, hero...@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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
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. 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. Thomas Goirand (zigo) -- 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/5025e9aa.7000...@debian.org
