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
Hi Russ,
On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
Steve Langasek vor...@debian.org 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
Steve Langasek vor...@debian.org 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
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 r...@debian.org wrote:
Peter Dolding oia...@gmail.com 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
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*
Thijs Kinkhorst th...@debian.org 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
On Wed, November 6, 2013 09:10, Russ Allbery wrote:
Thijs Kinkhorst th...@debian.org 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
* 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, the
]] Russ Allbery
Peter Dolding oia...@gmail.com 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
* Russ Allbery (r...@debian.org) [131104 18:21]:
Carlos Alberto Lopez Perez clo...@igalia.com writes:
Regarding the development force behind each project, I find the following
comparison at Ohloh very illustrative
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 as
* 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
Andreas Barth a...@ayous.org 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
* 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
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
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
Carlos Alberto Lopez Perez clo...@igalia.com 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=openrcproject_1=upstartproject_2=systemd
This isn't really a fair comparison since
On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery r...@debian.org wrote:
Peter Dolding oia...@gmail.com 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
Peter Dolding oia...@gmail.com 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
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 while
Hi,
Russ Allbery r...@debian.org writes:
Steve Langasek vor...@debian.org 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
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
Steve Langasek vor...@debian.org 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
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 every
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 policy
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
* Russ Allbery (r...@debian.org) [131031 02:19]:
Theodore Ts'o ty...@mit.edu 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
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
* 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
using
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've followed it with some interest.
Now
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 basic
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 it
Peter Dolding oia...@gmail.com 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
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
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 30-10-13 00:16, Russ Allbery schreef:
Carlos Alberto Lopez Perez clo...@igalia.com 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+:
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.
dream
Imagine a world where upstart and
]] 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 or
2013/10/30 Helmut Grohne hel...@subdivi.de:
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
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 supposed to
Theodore Ts'o ty...@mit.edu 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,
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
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,
Theodore Ts'o ty...@mit.edu 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
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 more
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 in
]] 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 the
On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
Wouter Verhelst wou...@master.debian.org 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
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 sure
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
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 is
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 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
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 two
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:
Carlos Alberto Lopez Perez clo...@igalia.com 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
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
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 from
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
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
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,
Wouter Verhelst wou...@master.debian.org 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
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
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,
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
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
Steve Langasek vor...@debian.org 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
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
Steve Langasek vor...@debian.org 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,
-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
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
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*
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
we
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
--
diogenese Beware of ritual lest you forget the meaning behind
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 bug off
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
76 matches
Mail list logo
