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
Steve Langasek writes:
> While it's fair to note that Canonical is a smaller company with fewer
> resources than Red Hat, Canonical is certainly not the only company
> working on technologies that don't fit into systemd upstream's model.
> On the question of cgroup management for instance, while
Hi Russ,
On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > For the TC decision, what kind of information are you looking for about
> > the plans, beyond "the Ubuntu developers expect to need to address this
> > before upgrading from systemd logind 204 and
The original question was which init system[s] are going to be the
default. But there are still some other things I'm curious about:
1. we already have alternate init systems in the archive; could it be
some kind of release goal to ensure they are installable? i.e. make it
possible for them to
On Tue, Nov 5, 2013 at 2:02 PM, Russ Allbery wrote:
> Peter Dolding writes:
>
>> ExecStartPre=, ExecStartPost= can be written many times.
>
>> ExecStartPre= rm somewhere
>> ExecStartPre= touch somewhere
>
> That really doesn't help, because...
>
>> In fact lot of cases I see one line entries in s
Hi TC and people,
Another issue that might or might have not already been answered, that
was triggered from seeing direct comparison metrics. Do we have some
kind of a metric or some even personal experience with regards to which
project has been the most friendly in accepting patches *from* Debia
* Thijs Kinkhorst (th...@debian.org) [131106 12:51]:
> Nonetheless, that's not relevant here. There are several likely candidates
> in existence, so the choice will not be to use something existing versus
> implementing from scratch; the choice will be between existing projects,
> and given that, t
On Wed, November 6, 2013 09:10, Russ Allbery wrote:
> "Thijs Kinkhorst" writes:
>> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
>
>>> We'll want to look at both sides of that question, and try to
>>> understand how much work like that is potentially on the horizon with
>>> the various choic
"Thijs Kinkhorst" writes:
> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
>> We'll want to look at both sides of that question, and try to
>> understand how much work like that is potentially on the horizon with
>> the various choices.
> Do you? In the past Debian has not shied away from m
On Wed, November 6, 2013 01:16, Russ Allbery wrote:
> We'll want to look at both sides of that question, and try to understand
> how much work like that is potentially on the horizon with the various
> choices.
Do you? In the past Debian has not shied away from making the choice that
it considers
* Russ Allbery (r...@debian.org) [131106 01:21]:
> We'll want to look at both sides of that question, and try to understand
> how much work like that is potentially on the horizon with the various
> choices.
Yes, and I hope that all potential init systems add appropriate
information to their posit
Andreas Barth writes:
> I would like to ask this question even a bit more general (for all
> involved init systems):
> How much would we have "vendor lock-in" by each init system? Means, is
> there more software except the pure init system we might need to take if
> we switch to that init system
* Russ Allbery (r...@debian.org) [131102 04:12]:
> If Canonical *is* the sole upstream, the upstream future here is troubling
> to me, particularly given Canonical's current strategic direction towards
> Unity. To give a specific example of the sort of thing that I'm worried
> about, suppose that
On Tuesday, November 05, 2013 10:05:40 Andreas Barth wrote:
[...]
> However, it shows two things: one is as you said that systemd contains
> many more subsystems as the others (whether this is good or not is a
> different question), the other is that code documentation seems to be
> not as verbose
* Russ Allbery (r...@debian.org) [131104 18:21]:
> Carlos Alberto Lopez Perez writes:
>
> > Regarding the development force behind each project, I find the following
> > comparison at Ohloh very illustrative
>
> > https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=syste
]] Russ Allbery
> Peter Dolding writes:
>
> > ExecStartPre=, ExecStartPost= can be written many times.
>
> > ExecStartPre= rm somewhere
> > ExecStartPre= touch somewhere
>
> That really doesn't help, because...
>
> > In fact lot of cases I see one line entries in systemd and I see bad
> > fo
On 10/31/2013 09:51 PM, Russ Allbery wrote:
> You can, of course, be
> disciplined about this when writing systemd helper scripts by always
> exernalizing the shell script into a separate file, but I really like that
> upstart lets me inline trivial shell fragments without worrying about
> that whi
Peter Dolding writes:
> ExecStartPre=, ExecStartPost= can be written many times.
> ExecStartPre= rm somewhere
> ExecStartPre= touch somewhere
That really doesn't help, because...
> In fact lot of cases I see one line entries in systemd and I see bad
> form. Unless one line has like if or for
On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery wrote:
> Peter Dolding writes:
>
>> The one property about systemd unit files that is extremely good is
>> there are no multi line commands. Every command is a single line.
>
> Yes, that's exactly what I think is obnoxious. I prefer the upstart
> sy
Carlos Alberto Lopez Perez writes:
> Regarding the development force behind each project, I find the following
> comparison at Ohloh very illustrative
> https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd
This isn't really a fair comparison since systemd as a pr
On 02/11/13 04:11, Russ Allbery wrote:
> I think the right way to put this is that systemd has significant
> development resources behind it and is working in fairly close cooperation
> with both kernel developers and GNOME developers to make available new
> kernel functionality and to provide impl
Hi,
Russ Allbery writes:
> Steve Langasek writes:
>
>> For the TC decision, what kind of information are you looking for about
>> the plans, beyond "the Ubuntu developers expect to need to address this
>> before upgrading from systemd logind 204 and will hold at 204 until a
>> correct solution i
Steve Langasek writes:
> For the TC decision, what kind of information are you looking for about
> the plans, beyond "the Ubuntu developers expect to need to address this
> before upgrading from systemd logind 204 and will hold at 204 until a
> correct solution is known"?
I think the right way t
Hi Russ,
On Tue, Oct 29, 2013 at 04:16:04PM -0700, Russ Allbery wrote:
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality. Either
> there needs to be an argument that the functionality is not important and
>
Peter Dolding writes:
> The one property about systemd unit files that is extremely good is
> there are no multi line commands. Every command is a single line.
Yes, that's exactly what I think is obnoxious. I prefer the upstart
syntax, which avoids the temptation to write unreadable one-line
Russ Allbery (r...@debian.org)
> In general, upstart's integration with arbitrary actions in shell
> fragments is considerably better than systemd's, at least based on the
> documentation I've read. upstart feels like it provides more useful
> flexibility
This is in fact a extremely bad idea how
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote:
> On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> > I'm surprised by this comment. Very little policy is actually encoded in
> > upstart's C code; in fact, the only policy I can think of offhand that is is
> > some ba
David Härdeman writes ("Bug#727708: tech-ctte: Decide which init system to
default to in Debian."):
> I'm not a DD, just a random contributor, and I haven't been actively
> involved in the init system debate at all, nor do I have any stake in
> it, though I'
* Theodore Ts'o:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
Curiously, a lot of system administrators do not do this correctly
usin
On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> I'm surprised by this comment. Very little policy is actually encoded in
> upstart's C code; in fact, the only policy I can think of offhand that is is
> some basic stuff around filesystems, which, aside from some must-have kernel
>
* Russ Allbery (r...@debian.org) [131031 02:19]:
> Theodore Ts'o writes:
> > On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
>
> >> Well, I've said this before, but I think it's worth reiterating.
> >> Either upstart or systemd configurations are *radically better* than
> >> init sc
Dear Committee members,
I'm not a DD, just a random contributor, and I haven't been actively
involved in the init system debate at all, nor do I have any stake in
it, though I've followed it with some interest.
Now that the question has been referred to the Technical Committee
(which seems r
Op 31-10-13 02:50, Theodore Ts'o schreef:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of exposing
>> some of those degrees of freedom to every init script author, but if you
>> have some more specific examples of p
On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> > Well, I've said this before, but I think it's worth reiterating. Either
> > upstart or systemd configurations are *radically better* than init scripts
> > on basically
]] Russ Allbery
(Cleaned up the Cc line somewhat)
> You can do quite a bit with the hooks that are part of the specification
> of both types of files. For example, logic that you may add to control
> whether the service should start at all can be implemented by adding a
> pre-start stanza to th
On 10/31/2013 02:50 AM, Theodore Ts'o wrote:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some mor
Theodore Ts'o writes:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of
>> exposing some of those degrees of freedom to every init script author,
>> but if you have some more specific examples of policy that you wan
On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> I suspect you and I have a root disagreement over the utility of exposing
> some of those degrees of freedom to every init script author, but if you
> have some more specific examples of policy that you wanted to change but
> couldn't,
On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> Well, I've said this before, but I think it's worth reiterating. Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis. They're more robust, more maintainable, easier
> for the
Theodore Ts'o writes:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
>> Well, I've said this before, but I think it's worth reiterating.
>> Either upstart or systemd configurations are *radically better* than
>> init scripts on basically every axis. They're more robust, more
>>
On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote:
> While I agree with your point, it's pretty difficult to reimplement the
> "interesting" parts of systemd in other implementations of pid1 if
> whoever wrote the "interesting" parts does not document it, does not say
> what it's supp
2013/10/30 Helmut Grohne :
> What is going to happen with non-Linux ports?
Debian is not Debian without non-Linux ports.
As for me, I think it is not very hard to maintain diffrent init
systems for different kernels.
Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart
]] Wouter Verhelst
> Yes, absense of documentation is common on Unix and Linux systems; but
> no, I do not think that this is okay, or that we should in any way
> encourage that sort of thing.
By absense of documentation, are you referring to the almost 10% of the
source base that are comments o
On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote:
> The interfaces of all init systems (except sysvinit, but are we really
> considering that one?) still are somewhat in flux, so this is the point
> where we can still influence and shape them.
>
>
> Imagine a world where upstart and
Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
>
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8R
Hi Steve,
On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
> > consideration. If
Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.
With some work, sure.
> This is a much better outcome
> across our distribution as a whole than to require developers to continue
>
Carlos Alberto Lopez Perez writes:
> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
>> For those who haven't seen it, Lennart has posted some of his comments
>> about all this on G+:
>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> And here is the reply from Gentoo de
On 28/10/13 20:14, Christoph Anton Mitterer wrote:
> For those who haven't seen it, Lennart has posted some of his comments
> about all this on G+:
> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
And here is the reply from Gentoo developer Patrick Lauer:
http://gentooexperim
On Tue, Oct 29, 2013 at 12:05:25PM -0700, Steve Langasek wrote:
> Hi Paul,
Good afternoon, Steve,
> Thanks for bringing this question to the Technical Committee. It's been on
> my todo list to raise this myself, with the intent of getting a TC decision
> before the end of this year. With only t
Hi guys, I'm just an user.
Well, can I make a suggestion?
We know systemd can't run on kFreeBSD and because of it Gnome can't run on
kFreeBSD too, but what about Cinnamon? Cinnamon is dependent on systemd?
1- If not, so Cinnamon + good apps can make kFreeBSD usable. So replacing
Gnome by Cinnamon o
Hi Paul,
On Fri, Oct 25, 2013 at 02:43:44PM -0400, Paul Tagliamonte wrote:
> And, since I've been informed that this was basically a contentless bug,
> I'd like to frame the technical half of the question better:
Thanks for bringing this question to the Technical Committee. It's been on
my todo
Hi Helmut,
On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> Having read the parts of the ctte bug, it feels odd to preclude the
> option of supporting multiple init systems from discussion or
> consideration. If Debian is to support only one init system and that one
> init system i
TL;DR: Thoughts on using systemd .service files on non-Linux ports.
On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
> Note that there are two options that could be explored, to remove the
> need to maintain init scripts:
> - generating sysvinit scripts from systemd service files or
On Mon, Oct 28, 2013 at 05:22:14PM +, Wouter Verhelst wrote:
> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right. Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;
> While I'm not su
On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
>
> > Also, since all alternative init implementations under consideration do
> > support sysv-style init scripts, I think that whatever init system we
> > (well, you, the TC) end up choosing, the requirement in policy shou
Anyone suggesting staying with sysvinit should be shot at down for
foolishness If you wish to stay something sysvinit like you should
be backing OpenRC.
The basic issue with sysvinit is lack of process tracking.
This is the historic problem.
You start a service.
You stop a service.
Ok everythi
Wouter Verhelst writes:
> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init config
On Tue, 2013-10-29 at 00:45 +, Steven Chamberlain wrote:
> a commitment to
> support two chosen init systems.
The question is would supporting two be enough to give a
considerable benefit?
I guess the competition will be mostly between: systemd vs. upstart.
And not between sysvinit, anythi
Hi!
Please may I suggest another option for consideration: a commitment to
support two chosen init systems.
On mainstream ports (Linux amd64, i386) where two init systems are
available, a package should be tested and made to work reasonably well
on both. Any port would have at least one of thes
For those who haven't seen it, Lennart has posted some of his comments
about all this on G+:
https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Wouter Verhelst schrieb am Monday, den 28. October 2013:
> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right. Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;
>
> While I'm not sure fr
On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> Right. Whichever init system we pick, I do expect the next step to be to
> drop the requirement to maintain sysvinit backwards-compatibility;
While I'm not sure from your mail whether you meant to suggest otherwise, I do
think that
Hi,
apart of the arguments raised by others, I'd like to point out three
more things:
- If we'd be inclined to switch the init system to something different
to sysvinit, let's start rather soon than later. Starting with today we
have one year until we expect to freeze which sounds like a lot, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi there!
I've been asked to write about OpenRC here. I'm a bit reluctant to do
it, but feel that it's my duty as I've been mentoring the OpenRC GSoC
project this summer.
Well, it's been a month the OpenRC package is waiting in the FTP NEW
queue (a
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > I don't think either of these are the right question. Even if we change
> > the default init system for jessie, because we *must* support backwards
> > compatibility with sysvinit for upgrades, there is no
Steve Langasek writes:
> I don't think either of these are the right question. Even if we change
> the default init system for jessie, because we *must* support backwards
> compatibility with sysvinit for upgrades, there is no justification for
> requiring packages to do anything else for jessie
On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote:
> I think that there are two different questions:
> 1) Could you clarify which init system(s) must be supported by packages
>involved during system startup (daemons, etc.) and low-level services?
>[ the answer to that ques
On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote:
> In response to the recent threads, I'd like to ask the tech-ctte to
> please vote on and decide on the default init system for Debian.
I agree. I don't think that many substantial new arguments are going to
be brought by waiting more on this to
And, since I've been informed that this was basically a contentless bug,
I'd like to frame the technical half of the question better:
Whereas:
* the init system / pid 1 is a bit of software that multiple packages provide
* the choice of init system also dictates which types of init scripts
On Fri, Oct 25, 2013 at 04:53:52PM +, Thorsten Glaser wrote:
> Paul Tagliamonte dixit:
>
> >It may be, but it's not for the project. Let's let this bug be, and
> >have the tech cttie decide on *the* init system for Debian. If you want
>
> No, this must really really be decided first.
Moving
Paul Tagliamonte dixit:
>It may be, but it's not for the project. Let's let this bug be, and
>have the tech cttie decide on *the* init system for Debian. If you want
No, this must really really be decided first.
bye,
//mirabilos
--
Beware of ritual lest you forget the meaning behind it.
yeah
On Fri, Oct 25, 2013 at 04:40:15PM +, Thorsten Glaser wrote:
> Paul Tagliamonte dixit:
>
> >please vote on and decide on the default init system for Debian.
>
> It’s not (just) about the _default_ but also on whether we will
> force this default init system onto *all* our users, or whether
>
Paul Tagliamonte dixit:
>please vote on and decide on the default init system for Debian.
It’s not (just) about the _default_ but also on whether we will
force this default init system onto *all* our users, or whether
we commit to support more than one, and if so, how.
This is an *important* dis
Package: tech-ctte
Severity: normal
thanks
In response to the recent threads, I'd like to ask the tech-ctte to
please vote on and decide on the default init system for Debian.
There's been quite a lot of discussion and it's clear no consensus is
coming out of the discussion.
In addition, I find
76 matches
Mail list logo
