Hi,
I got a *new* argument in the favor of OpenRC:
http://youtu.be/zoNoi8BgQjs
Yes, we made it work in Debian GNU/kFreeBSD! :)
Upstream was very friendly helping to do this last night and this
morning. Now, the next blocker would be renaming /sbin/rc to
/sbin/openrc, though upstream pretends
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
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
12 matches
Mail list logo
