Willing to propose option A

2014-03-04 Thread Sam Hartman
Hi. I prefer option A from the TC ballot to Matthew's proposal. However, I think I prefer no vote to a GR on option A. So, I'm going to hold off to see if Matthew's proposal gets sufficient seconds before doing anything. That said, I respect Matthew's proposal. I believe he is positively

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Marco d'Itri
In linux.debian.project Ian Jackson ijack...@chiark.greenend.org.uk wrote: For me the answer is: We should preserve diversity and freedom of choice, at the cost of functionality. Making that statement now, very clearly, will make that doomsday scenario less likely. We can easily have a GR on

Re: Willing to propose option A

2014-03-04 Thread Ian Jackson
Sam Hartman writes (Willing to propose option A): I prefer option A from the TC ballot to Matthew's proposal. However, I think I prefer no vote to a GR on option A. So, I'm going to hold off to see if Matthew's proposal gets sufficient seconds before doing anything. That is a sensible

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Ansgar Burchardt
Hi, On 03/01/2014 00:45, Matthew Vernon wrote: 2. Loose coupling of init systems In general, software may not require a specific init system to be pid 1. The exceptions to this are as follows: * alternative init system implementations * special-use packages such as managers

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Ian Jackson
Ansgar Burchardt writes (Re: Proposal - preserve freedom of choice of init systems): So if someone packages a new init system that is not compatible with existing init scripts (e.g. if it does not support /etc/init.d/* as a fallback), then it won't be able to start any service. This point was

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Uoti Urpala
Ian Jackson wrote: Ansgar Burchardt writes (Re: Proposal - preserve freedom of choice of init systems): So if someone packages a new init system that is not compatible with existing init scripts (e.g. if it does not support /etc/init.d/* as a fallback), then it won't be able to start any

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Sam Kuper
(Apologies if this comes through as HTML: I'm using a mobile.) On Mar 4, 2014 11:57 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: The reason why pretty much everyone is by now either already using systemd or moving to it Not everyone is, and the point here is that people certainly don't want

Re: Proposal - preserve freedom of choice of init systems

2014-03-04 Thread Uoti Urpala
On Wed, 2014-03-05 at 00:42 +, Sam Kuper wrote: On Mar 4, 2014 11:57 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: If systemd hegemony becomes a problem, there is a much better open-source answer: fork systemd. By saying this, you have outlined the following competing scenarios for