On 01/04/2014 12:07 PM, Russ Allbery wrote:
Cory writes:
If Debian go's with systemd they need to use systemd 207 as its
supported in RHEL 7 so we know it's going to be supported for around 10
years also why does Debian have systemd 204 in it's repos?? systemd 207
is way better
Because it's t
]] Steve Langasek
> On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
> > ]] Ian Jackson
>
> > > I think you have misunderstood. Or perhaps I hae misunderstood you.
> > > The "work" that I'm saying needs to be done anyway is the work to
> > > disentange the parts of systemd whic
On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson
> > I think you have misunderstood. Or perhaps I hae misunderstood you.
> > The "work" that I'm saying needs to be done anyway is the work to
> > disentange the parts of systemd which are required by (say) GNOME fr
Cory writes:
> If Debian go's with systemd they need to use systemd 207 as its
> supported in RHEL 7 so we know it's going to be supported for around 10
> years also why does Debian have systemd 204 in it's repos?? systemd 207
> is way better
Because it's the last version before cgroup handling
Steven Chamberlain writes ("Bug#727708: init system other points, and
conclusion"):
> Policy may need to explain whether hard systemd requirement is
> permissible, if it should be expressed in package dependencies, or what
> it should do otherwise (e.g. refuse to start, fail
Anthony Towns writes ("Bug#727708: init system other points, and conclusion"):
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?
Thanks for bringing up this point so very clearly.
I agree entirely with the thrust of your argumen
On 01/04/2014 11:21 AM, Steven Chamberlain wrote:
Commenting as a porter, the decision on default init system might affect
me something like this:
If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arch
Commenting as a porter, the decision on default init system might affect
me something like this:
If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arches. I'm really grateful of Dimitri's work on this a
Anthony Towns writes:
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?
My personal answer to this is that I truly don't know.
On one hand, we have four different init systems in Debian right now, plus
a fifth in experimental, and several of t
On 31 December 2013 12:32, Steve Langasek wrote:
> I agree that maintaining a systemd unit plus an upstart job is better than
> maintaining an init script. I just can't see any way through to a world
> where these will both actually be maintained (the testing problem),
> particularly if upstart u
Sune Vuorela writes ("Bug#727708: init system other points, and conclusion"):
> I've ignored the menu system as a part of the KDE Team. And I have a plan to
> even more aggressively ignore it (as in, hide it from the menu).
>
> Both things are ancient relics that sho
On Thursday 02 January 2014 14:27:14 Steve Langasek wrote:
> 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 is techn
On Thu, 2014-01-02 at 14:27 -0800, Steve Langasek wrote:
> 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
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
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 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
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
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
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'
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
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
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
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 1, 2014 at 4:56 AM, Colin Watson wrote:
> On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> > On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson
> > >inotify is used to notice changes to configuration files. This is
> > >certainly helpful for users, but it isn't critical as "ini
add that I am a core
developer of a Debian derivative that relies on GNOME and does not
intend to switch any time soon.
> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
>> The difference lies in who are the people who "need" to do this work
&g
On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson
> >inotify is used to notice changes to configuration files. This is
> >certainly helpful for users, but it isn't critical as "initctl
> >reload-configuration" works without it. We could prob
On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
> > Ansgar Burchardt writes ("Bug#727708: init system other points, and
> > conclusion"):
> > > What about the cgroup management fu
Tollef Fog Heen writes:
> Given how the voting ratio so far looks, I've been giving the whole GR
> process a bit of thought lately and at least I am unlikely to pursue it,
> simply because I don't think it's a good way to spend my and the
> project's energy.
There's one point that I think is wor
First of all, thanks a lot for writing this mail. It expresses a lot of
my thoughts and feelings on the subject a lot more eloquently than I am
able to do myself. You're a wordsmith and a master of words. I am
not.
]] Russ Allbery
> Occasionally, there are decisions with sweeping consequence
Josselin Mouette writes:
> Which brings me to the other point: you are not going to decide what
> people want to spend their time on. If systemd is selected as the
> default, the systemd maintainers are not going to ask Steve to fix their
> upgrades problem for them. And if upstart is selected, y
On Tue, Dec 31, 2013 at 12:13 PM, Josselin Mouette
wrote:
Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
> What about the cgroup management functionality that newer
versions
]] Ian Jackson
> I think you have misunderstood. Or perhaps I hae misunderstood you.
> The "work" that I'm saying needs to be done anyway is the work to
> disentange the parts of systemd which are required by (say) GNOME from
> the parts which are only relevant for systemd as init.
>
> This is
Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit :
> Ansgar Burchardt writes ("Bug#727708: init system other points, and
> conclusion"):
> > What about the cgroup management functionality that newer versions of
> > logind require? Should the systemd mainta
On Tue, Dec 31, 2013 at 10:31 AM, Ian Jackson
wrote:
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
What about the cgroup management functionality that newer versions
of
logind require? Should the systemd maintainers also reimplement it
in
On Tue, Dec 31, 2013 at 06:21:15PM +0100, Ansgar Burchardt wrote:
> And if upstart wants to use parts of systemd, why shouldn't the upstart
> maintainer do the work for this? Or they could fork logind which they
> suggested before... This would also allow having a newer systemd in
> Debian.
upstar
Ansgar Burchardt writes ("Bug#727708: init system other points, and
conclusion"):
> What about the cgroup management functionality that newer versions of
> logind require? Should the systemd maintainers also reimplement it in
> upstart?
This is a somewhat separate issue, bu
Ian Jackson writes:
> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
>> The difference lies in who are the people who "need" to do this work
>> "anyway", and who else may instead dedicate their time to other tasks,
>&g
intrigeri writes ("Bug#727708: init system other points, and conclusion"):
> (Sorry if I am duplicating a point that was already made.
> These threads are huge, and don't fit entirely into my memory.)
That's fine, of course.
> Ian Jackson wrote (30 Dec 2013 18:58
Hello.
I'm writing to you to request to do not use no systemd, nor upstart.
I can guess that you have very important reasons to discuss this
possibilities, but…
IMHO, "systemd" doesn't even fit to UNIX philosophy [1].
[1] http://en.wikipedia.org/wiki/Unix_philosophy
Sorry if I'm wrong.
"upst
Steve Langasek wrote:
> On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
>> Please recall the context here: this whole aside started with an objection
>> to my contention that adopting upstart requires disassembly and redoing of
>> an integration that we would otherwise not have to dis
On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson
wrote:
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
My belief, and again I welcome concrete reasons why I'm not
correct, is
that adopting upstart poses a similar risk for the Hurd port as
adopting
systemd, and I care just as
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > From comments made by various GNOME upstream developers on this, I think
> > they are being suitably cautious about avoiding scope creep where the
> > systemd dependencies are concerned. So in what sense a
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
> My belief, and again I welcome concrete reasons why I'm not correct, is
> that adopting upstart poses a similar risk for the Hurd port as adopting
> systemd, and I care just as much about the Hurd port as kFreeBSD. And
> while kFreeBS
On Tue, Dec 31, 2013 at 12:27:28AM -0008, cameron wrote:
> systemd lists logind as non-reimplementable, and that was pretty
> much proven when Ubuntu tried to reimplement it and ended up
> reimplementing or pulling in a ton of systemd anyway.
All this proves is that Ubuntu developers have the goo
On Mon, Dec 30, 2013 at 3:30 PM, Steve Langasek
wrote:
On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
>> Rather, we're talking about whether or not to swap out a core
component
>> of an existing integrated ecosystem with a component that we like
>> better.
> Unless you a
Steve Langasek writes:
> From comments made by various GNOME upstream developers on this, I think
> they are being suitably cautious about avoiding scope creep where the
> systemd dependencies are concerned. So in what sense are the GNOME and
> KDE requirements not already being met on top of up
On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
> Also, I get the impression me that the "integration" of much of this
> functionality into the systemd source package has been done for
> political rather than technical reasons. Indeed to the extent that
> there is a problematically tight tec
On Mon, Dec 30, 2013 at 01:44:10PM -0800, Russ Allbery wrote:
> * systemd provides really nice command-line tools for understanding the
> state of the system and the relationships between the unit files. I
> don't believe upstart has an equivalent of systemctl list-dependencies,
> for exampl
On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
> >> Rather, we're talking about whether or not to swap out a core component
> >> of an existing integrated ecosystem with a component that we like
> >> better.
> > Unless you are proposing to make systemd mandatory for all Debian
> > i
Hi,
(Sorry if I am duplicating a point that was already made.
These threads are huge, and don't fit entirely into my memory.)
Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) :
> Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
>> Rather, we
This message contains some supplemental information to go with my primary
writeup, and some profound thanks for the people involved in this
investigation.
I apologize for the huge volume of mail, and I know it's going to take a
while to digest. I appreciate people's willingness to read all these
On Mon, Dec 30, 2013 at 1:35 PM, Tollef Fog Heen wrote:
]] cameron
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen
wrote:
>> If this is not required by systemd, why is it done by sd_notify
?
>>
> It's not.
You obviously did not read the code. It is. Here is a G+ convo with
Lenn
]] cameron
> On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen wrote:
>
> >> If this is not required by systemd, why is it done by sd_notify ?
> >>
> > It's not.
>
> You obviously did not read the code. It is. Here is a G+ convo with
> Lennart I had:
>
> > As a sender you only have to set SCM_
On Mon, Dec 30, 2013 at 11:56 AM, Russ Allbery wrote:
The latest that I have seen on this porting effort is here:
http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
I asked previously on this bug if someone had later news. Do you have
more information than that?
The
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen wrote:
If this is not required by systemd, why is it done by sd_notify ?
It's not.
You obviously did not read the code. It is. Here is a G+ convo with
Lennart I had:
> As a sender you only have to set SCM_CREDENTIALS manually if you
wan
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
>> First, other choices besides systemd and upstart.
> I agree with your comments here; it appears you've investigated OpenRC
> in more detail than I have but I&#x
Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
> We seem to be at the point of the process where at least those of us who
> did early investigation are stating conclusions. I think I have enough
> information to state mine, so will attempt to
On Mon, 30 Dec 2013 09:05:57 -0800, Russ Allbery wrote:
> > By comparison, upstart is effectively used only by Ubuntu, [...]
> Both of these statements are incorrect.
> I'm sure that somewhere in the many vast threads that we've had over the
> init system, someone pointed out to me that Google's
]] Ian Jackson
> Tollef Fog Heen writes ("Bug#727708: init system other points, and
> conclusion"):
> > Ian Jackson:
> > > This is exacerbated by the fact that systemd's Debian maintainers are
> > > (IMO) much too deferential to upstream.
> >
Russ Allbery writes:
> * Red Hat adopted upstart but never did a wholescale conversion, and then
> abandoned upstart in favor of systemd. Obviously, one should not put
> too much weight on this; Red Hat is a commercial company that has a
> wealth of reasons for its actions that do not appl
Tollef Fog Heen writes ("Bug#727708: init system other points, and conclusion"):
> Ian Jackson:
> > This is exacerbated by the fact that systemd's Debian maintainers are
> > (IMO) much too deferential to upstream.
>
> That's because the bits of systemd yo
Tollef Fog Heen writes:
> ]] Russ Allbery
>> I think the upstart approach is better, but I think the drawbacks of
>> the systemd approach could be mostly overcome with some fairly simple
>> Debian tools.
> We were initially considering using ucf and checking if the file in /etc
> had changed (b
]] Russ Allbery
First, thanks to both you and Ian for the quite comprehensive
write-ups.
> If the package later changes the flags in some orthogonal way, it's
> easy for the system to miss that change. This is something that,
> under systemd, will probably require development of new tools to wa
We seem to be at the point of the process where at least those of us who
did early investigation are stating conclusions. I think I have enough
information to state mine, so will attempt to do so here.
This is probably going to be rather long, as there were quite a few
factors that concerned me a
Ian Jackson writes:
> It does, however, have a number of missing features. Those I have in
> mind are:
> - ability to log daemon output to syslog
> - multiple socket activation (systemd socket activation protocol)
> - socket activation for IPv6 (and datagram sockets)
>
> Of these Russ right
]] Ian Jackson
> This is exacerbated by the fact that systemd's Debian maintainers are
> (IMO) much too deferential to upstream.
That's because the bits of systemd you've asked to change isn't just a
piece of software. It's a standardised API, and you're effectively
asking us to change that API
Hi,
On Sat, 28 Dec 2013, Ian Jackson wrote:
> It does, however, have a number of missing features. Those I have in
> mind are:
> - ability to log daemon output to syslog
> - multiple socket activation (systemd socket activation protocol)
> - socket activation for IPv6 (and datagram sockets)
Michael Stapelberg writes:
> You then asked for these features to be carried as a patch in the Debian
> systemd package, and both requests were rejected. I think this is what
> you refer to when saying “the systemd Debian maintainers are much too
> deferential to upstream”. The reason why we don’
Hi Ian,
My apologies in advance for answering only to one email, but quoting
several. It could be that you had some threading in mind which my reply
might break.
Ian Jackson writes:
> * systemd's readiness protocol is an unattractive implementation
> target for an upstream daemon author. I th
Ian Jackson writes:
> Firstly, unlike the systemd maintainers, I think portability to
> non-Linux systems is important. It may be that our existing non-Linux
> ports are not very widely used, undermained, and/or not of production
> quality. However, I think it is important for us to keep those
I have reported on my impressions and experiences of both systemd and
upstart in my previous messagges.
I'd like to run through the remaining points I want to make. I'll
then summarise and set out my primary conclusion.
Firstly, unlike the systemd maintainers, I think portability to
non-Linux s
72 matches
Mail list logo
