Hi Colin,
Le mercredi 01 janvier 2014 à 17:17 +, Colin Watson a écrit :
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I think
> > > it amounts to different basic views of the world, but the basic
Le mardi 31 décembre 2013 à 19:01 -0800, Steve Langasek a écrit :
> It's not true that it's unrelated. In v205, logind hands off the cgroup
> heirarchy creation to PID 1, precisely because it's preparing for the
> anticipated future kernel requirement of a single cgroup writer.
This change wou
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> > On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > > On the other hand even when using upstart as an init replacement, we'll
> > > continue to use large chunk
On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
> On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
> > and I think it'd be a shame if we ended up losing or demotivating a
> > good bunch of good developers again.
>
> Pretty much every time the CTTE makes a ruling, someone is going to be
>
Colin Watson writes ("Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]"):
> Is there any useful way we could take a reasonably quick non-binding
> straw poll of developers? Sort of an "if we voted a particular way, is
> it likely that we would be on the wro
Colin Watson writes:
> On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
>> On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
>> > and I think it'd be a shame if we ended up losing or demotivating a
>> > good bunch of good developers again.
>>
>> Pretty much every time the CTTE makes a rul
On Thu, Jan 02, 2014 at 01:09:27PM +, Ian Jackson wrote:
> Colin Watson writes ("Re: CTTE and Developer Buy-in [Re: Bug#727708: init
> system other points, and conclusion]"):
> > Is there any useful way we could take a reasonably quick non-binding
> > straw poll of developers? Sort of an "if
Colin Watson writes ("Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]"):
> On Thu, Jan 02, 2014 at 01:09:27PM +, Ian Jackson wrote:
> > Obviously that would be embarrassing for us and substantially damage
> > our credibility. But I don't think it's at
On Thu, 02 Jan 2014, Ian Jackson wrote:
> And, despite the fact that the decision has become very politicised
> (to some extent along the lines of preexisting camps of strongly
> disagreeing contributors), I think it is primarily a technical
> decision.
The line of thought that you have been defen
So we know where Colin, Steve, Russ and I stand on the main question.
If we want to make a decision soon we need to start to thrash out the
details so that we have something concrete to vote on.
It would be helpful to know how far along the other TC members are.
So:
Andreas, Bdale, Don, Keith: pl
On Thu, 2014-01-02 at 12:37 +, Colin Watson wrote:
> On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
> > On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
> > > and I think it'd be a shame if we ended up losing or demotivating a
> > > good bunch of good developers again.
> >
> > Prett
Raphael Hertzog writes ("Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]"):
> I do. I know at least one person who expressed his intent to leave Debian
> if Debian wasn't able to make the choice of systemd. So if one is ready to
> resign, there will likely
Ansgar Burchardt writes:
> Sometimes I also wonder if a GR might be a better way to deal with the
> decision as this feels more and more like an "political" or "opinion"
> decision rather then a technical decision to me as tech-ctte members
> have found both upstart and systemd to be suitable so
On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> > You can simply not install any of these additional services if you don't
> > want them. This is completely trivial to do.
>
> It is indeed technically trivial, but I invite you
(Long time listener, first time caller - so apologies if I'm doing this wrong.)
Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
>3.1. Ecosystem Reality Check
...
> Therefore, I believe the burden of proof is on upstart to show that it is
> a clearly superior init syst
Ian Jackson writes:
> And, despite the fact that the decision has become very politicised (to
> some extent along the lines of preexisting camps of strongly disagreeing
> contributors), I think it is primarily a technical decision.
I think this is a remarkable statement given that you're the pri
Ian Jackson writes:
> As the TC, I think we have two options for the process:
> (a) Make a decision based on our assessment of the merits; that
> includes considering the strength and health of the communites
> behind each project. But for me it doesn't include consideration
> of th
Russ Allbery writes ("Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708:
init system other points, and conclusion]"):
> Ian Jackson writes:
> > I don't think any of the TC are going to propose (b). Perhaps we
> > should put (b) on the TC ballot for form's sake; I guess most of the
> > TC wou
]] Colin Watson
> Perhaps this is the fundamental disagreement. I do not necessarily
> consider compatibility as an end in itself. Where Debian is already
> better than other distributions, we should remain better, not stick to a
> lowest common denominator for the sake of compatibility.
I thi
Ian Jackson writes:
> Based on the responses to the recurring flamewars on debian-devel, I
> think the majority of contributors are happy not to have to wrestle
> with this decision and would prefer to leave it to us.
Agreed.
> Perhaps we
> should put (b) on the TC ballot for form's sake; I gue
I wanted to lift this out of the thread it was buried in and see if I'm
understanding it correctly, since if I am, it seems like a significant
issue.
Cameron Norman writes:
> I think you raise a lot of good points in this email, but here you are
> saying something which may demonstrate your (und
Sjoerd Simons writes:
> While i don't have a good answer for your question, i did trigger me to
> have a look at popcon to see what that told me in terms of popularity of
> systemd vs. upstart.
Thank you!
Bdale
pgpPoSk59R79j.pgp
Description: PGP signature
On Thu, Jan 02, 2014 at 02:39:15PM +0100, Sjoerd Simons wrote:
> While i don't have a good answer for your question, i did trigger me to
> have a look at popcon to see what that told me in terms of popularity of
> systemd vs. upstart. Unfortunately systemd can be pulled in quite easily
> via depend
Josselin Mouette writes:
> It shouldn’t come as a surprise that it is hard for developers to
> respect the TC’s decisions when we see disrespectful sentences like the
> one above from some of its members.
I agree.
We are of course each entitled to hold opinions about such things, but I
would st
]] Colin Watson
> On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
> > On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
> > > and I think it'd be a shame if we ended up losing or demotivating a
> > > good bunch of good developers again.
> >
> > Pretty much every time the CTTE makes a ru
On Thu, Jan 2, 2014 at 8:35 AM, Russ Allbery wrote:
> I wanted to lift this out of the thread it was buried in and see if I'm
> understanding it correctly, since if I am, it seems like a significant
> issue.
>
> Cameron Norman writes:
>
> > I think you raise a lot of good points in this email, b
As I mentioned in some of my previous notes, I was unable to evaluate
OpenRC in a meaningful way during my general experiments for a few
reasons. My impression was formed based on previous discussion and what
documentation I could find, which was fairly minimal.
Thomas Goirand sent me considerabl
Ian Jackson writes:
> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
> and what more information/discussion would be useful.
Right. I've meant to post something before now, but after returning
home from a family road trip over the holidays, I was hit by a nasty
cold. Feel
Bdale Garbee writes ("Bug#727708: init system discussion status"):
> [stuff]
Thanks for posting your views.
You'll have seen Russ's comments on the details and loose ends as I
call them. Russ and I were mostly agreed on these points.
I have written a draft resolution from my own point of view a
Russ Allbery writes:
> This message is about a transition plan for an init system replacement and
> about how to handle portability to our non-Linux ports. I'm keeping the
> same subject as Ian's message on the same basic topics and attaching it to
> the same thread, but this is more of a separat
On Mon, Dec 30, 2013 at 02:03:22 -0800, Steve Langasek wrote:
> The upstart "session init" runs as the user, not as root.
Note that a session init can run as root ("sudo init --user") but yes,
conventionally they are run as non-priv users.
> I'm not sure if
> upstart as a user session has any depe
On Thu, 02 Jan 2014, Russ Allbery wrote:
> Ian Jackson writes:
>
> > And, despite the fact that the decision has become very politicised (to
> > some extent along the lines of preexisting camps of strongly disagreeing
> > contributors), I think it is primarily a technical decision.
>
> I think t
Steve Langasek writes:
> However, I think this gets to the heart of why upstart upstream has avoided
> ever recommending the use of socket-based activation. There are some fairly
> fundamental problems that basically halted development of socket-based
> activation in upstart (beyond merging of Sc
Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
> I think there is one additional questions that will probably need to be
> decided by the tc but hasn't really been discussed yet:
>
> Will packages that explicity depend on a (non-default) init system be
> allowed in Debia
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> I have written a draft resolution from my own point of view and
> checked it into the tech-ctte git repo. Perhaps some of it is useful.
> Ansgar commented a bit on it on IRC. I guess I should post it.
Here's my draft.
Thos
Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
> For example, a hypothetical future program to interactively adjust
> program cgroups cannot be sysvinit compatible in any meaningful sense,
> because it does not need to be supervised, started, or stopped. However,
> th
On 01/02/2014 10:20 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
>> I think there is one additional questions that will probably need to be
>> decided by the tc but hasn't really been discussed yet:
>>
>> Will packages that explicity depend on a
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> > I have written a draft resolution from my own point of view and
> > checked it into the tech-ctte git repo. Perhaps some of it is usef
Cameron Norman writes ("Re: Bug#727708: init system discussion status"):
> On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:
...
> | 9. [ Policy should provide non-binding suggestions to Debian
> > |contributors who are converting daemons to upstart and/or
On 01/02/2014 10:30 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
>> For example, a hypothetical future program to interactively adjust
>> program cgroups cannot be sysvinit compatible in any meaningful sense,
>> because it does not need to b
Cameron Norman writes:
> Should it not be added that raise(SIGSTOP) should only be used with a
> command line option (like --debian-Z) to ensure that the daemon does not
> hang on sysv or systemd?
No, because see Colin's point that Debian developers may be doing the
integration and adding a new
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Cameron Norman writes:
> > Should it not be added that raise(SIGSTOP) should only be used with a
> > command line option (like --debian-Z) to ensure that the daemon does not
> > hang on sysv or systemd?
>
> No, because see Colin
Ian Jackson writes:
> I think it would be reasonable to state that the raise(SIGSTOP)
> integration should be done with a new command line option OR a new
> environment variable; ie that the daemon should not be changed to
> raise(SIGSTOP) by default.
Agreed.
> I don't know whether it's valuabl
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
>> I have written a draft resolution from my own point of view and checked
>> it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar
>> commented a bit on it on IRC. I guess I should post
Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> I would hope that we can standardise on a single API to the system's
> single cgroup writer.
I have already explained why this is not going to happen. The cgroups
API in systemd is already part of the core systemd interface and subje
Russ Allbery writes ("Bug#727708: init system discussion status"):
> Thank you very much for writing this. (And, in general, thank you for
> often taking the initiative in producing drafts. It's something that I
> find difficult, and I really appreciate your work on it.)
Thanks. I agree with mu
Josselin Mouette writes ("Bug#727708: loose ends for init system decision"):
> Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> > I would hope that we can standardise on a single API to the system's
> > single cgroup writer.
>
> I have already explained why this is not going to hap
On Thu, Jan 2, 2014 at 11:46 AM, Josselin Mouette wrote:
> Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
> > I would hope that we can standardise on a single API to the system's
> > single cgroup writer.
>
> I have already explained why this is not going to happen. The cgroups
> A
]] Ian Jackson
> I think it would be reasonable to state that the raise(SIGSTOP)
> integration should be done with a new command line option OR a new
> environment variable; ie that the daemon should not be changed to
> raise(SIGSTOP) by default.
I don't see why you think that doing so because a
]] Ian Jackson
> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
> > I think there is one additional questions that will probably need to be
> > decided by the tc but hasn't really been discussed yet:
> >
> > Will packages that explicity depend on a (non-default) init s
Tollef Fog Heen writes:
> ]] Ian Jackson
>> I think it would be reasonable to state that the raise(SIGSTOP)
>> integration should be done with a new command line option OR a new
>> environment variable; ie that the daemon should not be changed to
>> raise(SIGSTOP) by default.
> I don't see why
Tollef Fog Heen writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson:
> > So, firstly, I would say that all packages must, in jessie at least,
> > continue to support sysvinit. Russ (from the other side of the
> > upstart/systemd fence) agrees. Failure to support sysvinit wou
On Thu, Jan 02, 2014 at 05:51:11PM +0100, Tollef Fog Heen wrote:
> In addition to the popcon numbers referenced from Sjoerd, we have the
> numbers from Michael's systemd survey in May 2013. The numbers there
> were 35%/30%/33% for yes/dunno/no for systemd as default init when only
> counting DD/DM
| 8. Policy rules for support for init systems must:
|
|(a) Specify the use of a non-forking startup protocol (for
|upstart and systemd),
I'm not sure about upstart, but systemd is perfectly happy with
daemons which double fork (Type=forking in systemd parlance).
It is mildly discoura
Zbigniew Jędrzejewski-Szmek writes ("Bug#727708: requirement of non-forking
startup protocol"):
> | 8. Policy rules for support for init systems must:
> |
> |(a) Specify the use of a non-forking startup protocol (for
> |upstart and systemd),
[ Replying to this thread after a large gl
Zbigniew Jędrzejewski-Szmek writes:
> | 8. Policy rules for support for init systems must:
> |
> |(a) Specify the use of a non-forking startup protocol (for
> |upstart and systemd),
> I'm not sure about upstart, but systemd is perfectly happy with daemons
> which double fork (Type=f
Russ Allbery writes ("Bug#727708: requirement of non-forking startup protocol"):
> Zbigniew Jędrzejewski-Szmek writes:
> > I think this should be changed to:
> > | 8. Policy rules for support for init systems must:
> > |
> > |(a) Encourage the use of a non-forking startup protocol (for
> > |
On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
> Josselin Mouette writes:
> > It shouldn’t come as a surprise that it is hard for developers to
> > respect the TC’s decisions when we see disrespectful sentences like the
> > one above from some of its members.
> I agree.
> We are
On Thu, Jan 02, 2014 at 10:04:12PM +, Ian Jackson wrote:
> Zbigniew Jędrzejewski-Szmek writes ("Bug#727708: requirement of non-forking
> startup protocol"):
> > | 8. Policy rules for support for init systems must:
> > |
> > |(a) Specify the use of a non-forking startup protocol (for
> > |
Ian Jackson writes:
> Russ Allbery writes:
>> Yeah, this is a good point. Since systemd uses the daemon-written PID
>> file for tracking forking daemons, it doesn't have the same issues as
>> the upstart expect fork or expect daemon protocols. Obviously, an
>> external PID file is not ideal, bu
Le jeudi 02 janvier 2014 à 14:27 -0800, Steve Langasek a écrit :
> For several years the GNOME Team ignored section 9.7 of Policy, concerning
> integration with the MIME handling system. They did this in favor of
> implementing the related freedesktop.org on the grounds that the fd.o
> standard i
> Yeah, most daemons that write external PID files have issues with external
> PID files left from other running instances of the same daemon. (I assume
> that's what you're talking about.) It's probably possible to avoid that
> with judicious use of file locking, but that's not common and is mor
On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > Upstart (as implemented in Ubuntu) restores this guarantee (with
> > provisions for failsafe booting in the case of a wrong network config),
> > and it takes advantage of upstart's capability of sending arb
To wrap up this subthread, I want to state clearly for the record that the
answers that have been given here have addressed my concerns about the
raciness of systemd socket activation. It appears that the state of the art
is rather substantially improved since the last time I had looked at
Fedora'
Processing control commands:
> tag -1 - patch
Bug #670170 [apparmor] apparmor: should load profiles before networking is setup
Removed tag(s) patch.
> block -1 by 727708
Bug #670170 [apparmor] apparmor: should load profiles before networking is setup
670170 was not blocked by any bugs.
670170 was
Hi,
first, thank you for describing this problem in details.
I have never met it while using systemd on Debian Wheezy and sid for
18 months. Anyhow, with your indications at hand, I realize that my
use cases probably fall into the category that does not expose
this problem.
Steve Langasek wrote
66 matches
Mail list logo
