On 11/06/2013 07:00 AM, Paul Tagliamonte wrote:
If you want to hold your own system back, there's nothing stoping you
(and your rights granted by f/oss software allow you to do so).
And there's nothing stopping you from contributing to OpenRC either, if
you feel, like me, that it's free of
On 11/06/2013 09:33 PM, Gergely Nagy wrote:
Switching to systemd/upstart/OpenRC will not mean the rest will be
dropped.
Whatever the decision we take, I really wish we deprecate sysv-rc in the
favor of OpenRC. It would really make sense, even if systemd or Upstart
becomes the default.
Also, I
On 11/06/2013 10:14 PM, Thorsten Glaser wrote:
but the propo-
nents of systemd, upstart *and* openrc (to a lesser amount)
alike *all* want to *not* keep supporting init scripts).
Just FYI, here's my view...
I'd love to have a patch in OpenRC so that we'd have something like
/etc/init.d.openrc
On 12/25/2013 08:46 AM, Thomas Goirand wrote:
And overriding the *entire* service file seems excessive if you wish to
override just one line of the package's service file.
And also, systemd would be the only package behaving this way, which is
counter-intuitive for our users. I'd even go up
On 12/25/2013 05:50 PM, John Paul Adrian Glaubitz wrote:
On 12/25/2013 08:46 AM, Thomas Goirand wrote:
And overriding the *entire* service file seems excessive if you wish to
override just one line of the package's service file.
And also, systemd would be the only package behaving this way,
On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote:
On 2013-12-23 13:15, Sergey B Kirpichev wrote:
[a potentially badly-phrased question]
...I don't think many continue to read your rant and take your
feedback seriously. Apart from those who already resonate with
your opinion. And
On Tue, Dec 24, 2013 at 05:47:05PM +0100, Tzafrir Cohen wrote:
On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote:
On 2013-12-23 13:15, Sergey B Kirpichev wrote:
[a potentially badly-phrased question]
...I don't think many continue to read your rant and take your
feedback
On 10/31/2013 09:47 PM, Steven Chamberlain wrote:
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
two places where to place systemd service files. One is located
below /usr/lib/systemd which is the directory where service files
provided by the package are placed, and one is
You don’t want anything like these in your local init service. For such
tests you have Nagios, Icinga or similiar daemons. And they can do much
deeper checks, e.g. can you login into your webservice because your
database backend on a different server is available.
Once your monitoring
On 2013-12-23 13:15, Sergey B Kirpichev wrote:
You don’t want anything like these in your local init service. For
such
tests you have Nagios, Icinga or similiar daemons. And they can do
much
deeper checks, e.g. can you login into your webservice because your
database backend on a different
Matthias Urlichs dixit:
A systemd service file is five lines.
Someone has shown that this works with sysvinit as well,
if you use #!/path/to/some-helper as shebang.
Want more features in your init script? Like, say, a reliable way to
figure out if any parts of your server are still running
On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote:
Matthias Urlichs dixit:
A systemd service file is five lines.
Someone has shown that this works with sysvinit as well,
if you use #!/path/to/some-helper as shebang.
Nice theory, but in practice it is a mess. That people
On Mon, Nov 11, 2013 at 10:24:36PM +0100, Olav Vitters wrote:
On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote:
Or a private tmp?
I shudder at the mere thought of allowing a dæmon to unshare
its /tmp from the rest of the system, because of the maintenance
nightmare this
Marko Randjelovic markoran at eunet.rs writes:
That's exactly how I feel when I want to create a small daemon using a
SystemV init script. I feel like building an airplane from scratch while
I would just use a bike.
Sure, systemd is bloated. Just like the kernel is bloated, I presume.
On 11/01/2013 02:00 AM, Kevin Chadwick wrote:
previously on this list Wouter Verhelst contributed:
By absense of documentation, are you referring to the almost 10% of the
source base that are comments or the 15% that is DocBook XML based
documentation? (Almost 14kLOC and almost 36kLOX,
On Sun, Nov 10, 2013 at 11:25:32AM +, Matthias Urlichs wrote:
Want more features in your init script? Like, say, a reliable way to
figure out if any parts of your server are still running after it
crashed? Or a way to determine that it has started up correctly?
You don’t want anything like
Le dimanche 10 novembre 2013 à 20:23 +0100, Stephan Seitz a écrit :
You don’t want anything like these in your local init service. For such
tests you have Nagios, Icinga or similiar daemons. And they can do much
deeper checks, e.g. can you login into your webservice because your
database
On Tue, 5 Nov 2013 18:00:09 -0500
Paul Tagliamonte paul...@debian.org wrote:
What? Sorry, what? Are you disagreeing with yourself? If it's so
important to a UNIX system, why do you say it's not technical ...
I said it's not *only* technical.
Big companies all over and over again show they
On Tue, 5 Nov 2013, Paul Tagliamonte wrote:
First of all, I do not agree Debian community is hurt because of
split about init system,
I disagree strongly. Please read through every flame thread over the
last 4 years and try to say this with a straight face.
That’s why I say let’s just
And SysVInit just works well and it is simply enough. It has much less
dependencies than systemd. Do not make unneeded weight on people to learn
systemd in addition to shell scripts, if systemd is powerful that also means
there is a lot to learn. I really doubt non-standards task can be solved
Thorsten Glaser t.gla...@tarent.de writes:
On Tue, 5 Nov 2013, Paul Tagliamonte wrote:
First of all, I do not agree Debian community is hurt because of
split about init system,
I disagree strongly. Please read through every flame thread over the
last 4 years and try to say this with a
On Wed, Nov 06, 2013 at 02:33:36PM +0100, Gergely Nagy wrote:
Please no. That's a maintenance nightmare. I'm fine with one on
GNU/Linux, another everywhere else (but I'll treat everything else as
secondary), but supporting all of them, everywhere they're available, is
madness.
This is now in
On Wed, 6 Nov 2013, Gergely Nagy wrote:
Please no. That's a maintenance nightmare. I'm fine with one on
GNU/Linux, another everywhere else (but I'll treat everything else as
secondary), but supporting all of them, everywhere they're available, is
madness.
And:
Freedom of choice remains
On Wed, Nov 06, 2013 at 03:14:14PM +0100, Thorsten Glaser wrote:
[snip]
Some good points made all around, more for the ctte to consider. As
Jonathan says, it's in ctte's hands now, let's agree to disagree and let
the poor souls on the commitee do their job
Cheers,
Paul
--
.''`. Paul
On Wed, 06 Nov 2013 14:04:53 +0100
Adrien CLERC adr...@antipoul.fr wrote:
And SysVInit just works well and it is simply enough. It has much less
dependencies than systemd. Do not make unneeded weight on people to learn
systemd in addition to shell scripts, if systemd is powerful that also
This discussion isn't really furthering the development of Debian
and the init system question is already with the technical committee
so can we please take such discussions off-list, if one is determined
to continue them.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
* Thorsten Glaser:
On Thu, 31 Oct 2013, Florian Weimer wrote:
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct way, anyway?
Renaming the S symlinks to K
On Wed, Nov 06, 2013 at 06:53:40PM +0100, Florian Weimer wrote:
[...]
Again, good points, but ones we've discussed. Perhaps we should end this
thread?
Fondly,
Paul
--
.''`. Paul Tagliamonte paul...@debian.org
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A
❦ 6 novembre 2013 18:53 CET, Florian Weimer f...@deneb.enyo.de :
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct way, anyway?
Renaming the S symlinks to
❦ 6 novembre 2013 17:43 CET, Marko Randjelovic marko...@eunet.rs :
That's exactly how I feel when I want to create a small daemon using a
SystemV init script. I feel like building an airplane from scratch while
I would just use a bike.
Use /etc/init.d/skeleton and you'll see it's very
On Sat, 26 Oct 2013 11:07:36 +0200
Lucas Nussbaum lea...@debian.org wrote:
I think that it would be a failure of the Debian project if we had to have a
GR
about such a technical decision. I think that we need to trust that the
Technical Committee will make the right decision. A GR about this
On Tue, Nov 05, 2013 at 11:43:16PM +0100, Marko Randjelovic wrote:
On Sat, 26 Oct 2013 11:07:36 +0200
Lucas Nussbaum lea...@debian.org wrote:
I think that it would be a failure of the Debian project if we had to have
a GR
about such a technical decision. I think that we need to trust
previously on this list Ben Hutchings contributed:
In other words, Canonical gets the right to take a free software
contribution and make it proprietary. The contributors gets to own the
software, and can continue releasing it as free software, but can't
prevent Canonical from making
On 10/30/2013 11:58 PM, Tollef Fog Heen wrote:
]] 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
On Wed, 30 Oct 2013 21:50:53 -0400, Theodore Ts'o wrote:
It's not necessarily the init script author who might want the degrees
of freedom, but the local system administrator.
The most basic is the idea that whether you can control (via shell
scrpit fragments) whether or not a service
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
Op 30-10-13 16:58, Tollef Fog Heen schreef:
]] 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
* 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
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
On Wed, Oct 30, 2013 at 10:52:15PM -0700, Russ Allbery wrote:
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
On a different subject, which I don't think has been raised so far ---
has the Debian maintinares for the upstart package made any comments
about bug fixes or code contributions from Debian Developers who are
personally opposed to being forced to sign copyright assignment
agreements, or for whom
Hi,
On 31/10/13 12:45, Theodore Ts'o wrote:
On a different subject, which I don't think has been raised so far ---
has the Debian maintinares for the upstart package made any comments
about bug fixes or code contributions from Debian Developers who are
personally opposed to being forced to
On Thu, 31 Oct 2013, Florian Weimer wrote:
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct way, anyway?
My coworkers tell me to delete the symlinks in
Hi Thorsten,
On Wed, Oct 30, 2013 at 04:05:48PM +, Thorsten Glaser wrote:
* Write scripts for one system and generate the other from it
or even
* Write ???Debian init declaration??? and let something take care
of generating an initscript and whatever the other systems
use out of it
On 31/10/13 12:27, Thorsten Glaser wrote:
On Thu, 31 Oct 2013, Florian Weimer wrote:
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct way, anyway?
My
On Thu, 31 Oct 2013, Simon McVittie wrote:
file-rc ships its own update-rc.d implementation (at least, according to
the package description it does) which hopefully has the enable/disable
subcommands.
It does, but…
My understanding is that something like `update-rc.d $service disable`
…
* Thorsten Glaser [Thu Oct 31, 2013 at 01:27:12PM +0100]:
On Thu, 31 Oct 2013, Florian Weimer wrote:
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct
On 31/10/13 13:06, Thorsten Glaser wrote:
My understanding is that something like `update-rc.d $service disable`
… isn’t that overwritten by the update-rc.d commands in the
maintainer scripts (postinst) when the package is upgraded?
Not in the sysv-rc implementation, at least. `update-rc.d
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
two places where to place systemd service files. One is located
below /usr/lib/systemd which is the directory where service files
provided by the package are placed, and one is /etc/systemd where
your own, custom service files
On Thu, Oct 31, 2013 at 01:47:37PM +, Steven Chamberlain wrote:
And overriding the *entire* service file seems excessive if you wish to
override just one line of the package's service file.
You add a file /etc/systemd/system/xxx.service.d/yyy.conf with the following
contents:
[Service]
]] Theodore Ts'o
The upstart documentation, from my brief examination, seems to be much
more approachable for someone who is starting from ground zero.
Have you read the «The systemd for Administrators Blog Series» linked to
from http://www.freedesktop.org/wiki/Software/systemd/ ?
--
Tollef
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
messed up custom code may end up rendering your whole system unusable
if you are smart enough to mess up an rm command. Just have a look
at this wonderful bug in upstart [1].
[1]
]] Theodore Ts'o
I don't think copyright assignment is a concern which afflicts
Systemd, although there is a related concern which is that the
upstream systemd developers appear to have a very strong point of
view, and if there is some change which is needed for Debian or
Debian's users,
On Oct 31, 2013, at 07:45 AM, Theodore Ts'o wrote:
On a different subject, which I don't think has been raised so far ---
has the Debian maintinares for the upstart package made any comments
about bug fixes or code contributions from Debian Developers who are
personally opposed to being forced to
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
The difference of course is that with the CLA, you continue to own the
copyright in the contribution, with full rights to re-use, re-distribute, and
continue modifying the contributed code, but it allows Canonical to use your
On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote:
[1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
This doesn't appear to be a bug in Upstart.
Strictly, no, but there was a surprising amount of resistance to adding
some boilerplate to that script to
On 10/31/2013 03:04 PM, Steven Chamberlain wrote:
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
messed up custom code may end up rendering your whole system unusable
if you are smart enough to mess up an rm command. Just have a look
at this wonderful bug in upstart [1].
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 Thu, Oct 31, 2013 at 03:59:25PM +, Jonathan Dowland wrote:
On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote:
[1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
This doesn't appear to be a bug in Upstart.
Strictly, no, but there was a surprising
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
Actually, contributing to Upstart does not require copyright assignment (as
for example, would contributing to an FSF-owned GNU project). Instead, it
requires a Contributor License Agreement be signed:
previously on this list Theodore Ts'o contributed:
So hopefully that is something the technical committee will take into
account --- how well things are documented, both in terms of a
comprehensive reference manual, and a tutorial that helps people with
common things that system
previously on this list Wouter Verhelst contributed:
By absense of documentation, are you referring to the almost 10% of the
source base that are comments or the 15% that is DocBook XML based
documentation? (Almost 14kLOC and almost 36kLOX, respectively.)
That particular comment was
On Oct 31, 2013, at 06:10 PM, Lars Wirzenius wrote:
Quoting from the PDF linked from that page (Canonical Individual
Contributor License Agreement for individual contributors):
Based on the grant of rights in Sections 2.1 and 2.2, if We
include Your Contribution in a Material, We may
--text follows this line--
Theodore Ts'o writes (Re: Bug#727708: tech-ctte: Decide which init system to
default to in Debian.):
On a different subject, which I don't think has been raised so far ---
has the Debian maintinares for the upstart package made any comments
about bug fixes or code
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
On Thu, 31 Oct 2013 18:10:31 +, Lars Wirzenius wrote:
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote:
Actually, contributing to Upstart does not require copyright assignment (as
for example, would contributing to an FSF-owned GNU project). Instead, it
requires a
On Thu, Oct 31, 2013 at 11:40:20PM +0100, gregor herrmann wrote:
[...]
In other words, Canonical gets the right to take a free software
contribution and make it proprietary. The contributors gets to own the
software, and can continue releasing it as free software, but can't
prevent
Russ,
It seems we don't have at all the same reading of Patrick post. Note
that what's below is my comments on your comments about Patrick's
comments, and do not represent my view (which I do not wish to express
it more at this point).
On 10/30/2013 07:16 AM, Russ Allbery wrote:
the core
On 29/10/13 23:51, Svante Signell wrote:
On Tue, 2013-10-29 at 00:51 -0700, Steve Langasek wrote:
(Also, do remember that any decisive outcome other than “support
multiple ones including systemd” and “systemd-only” will need to
lead to the removal of GNOME from Debian.
Absolutely not true.
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,
Le mardi, 29 octobre 2013 15.08:01 Russ Allbery a écrit :
However, making all package maintainers continue to go through the
pain of maintaining SysV init scripts to support Hurd and kFreeBSD
doesn't strike me as a good outcome.
It does for me.
First we're not talking about _all_ package
on Tue, 29 Oct 2013 15:08:01 -0700 Russ Allbery wrote:
However, I, as a packager, want to stop writing and maintaining SysV init
scripts because they're awful.
I didn't really expect this. I'd assumed until now that most
maintainers would be concerned that existing init scripts don't work
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
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
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, 30 Oct 2013 15:10:16 +0100 Helmut Grohne wrote:
Furthering this thought leads to turning non-Linux ports
into derivatives as presented by others in this thread.
If packages are no longer required to provide SysV init scripts,
producing a non-Linux Debian derivative would at least entail
]] 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
Steven Chamberlain dixit:
[…]
substitute Upstart here if you prefer), each package's maintainer could:
[…]
* Write scripts for one system and generate the other from it
or even
* Write “Debian init declaration” and let something take care
of generating an initscript and whatever the other
On Wed, 30 Oct 2013 16:05:48 +, Thorsten Glaser wrote:
* Write scripts for one system and generate the other from it
or even
* Write “Debian init declaration” and let something take care
of generating an initscript and whatever the other systems
use out of it
Perhaps an existing
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
previously on this list Zbigniew Jędrzejewski-Szmek contributed:
Hi Helmut,
exec vs. ExecStart= and export vs. Environment= is easy.
Anyone can whip up a sed script to convert between those. The question
is how to deal with more advanced options. Let's say that I have a
systemd unit with
previously on this list Helmut Grohne contributed:
Most participants in this thread appear to agree that the sysvinit
*interface* for services (shell scripts) is suboptimal.
Not so sure, I have various thoughts on this and even the reasons that
it is considered sub optimal but think some like
On Wed, Oct 30, 2013 at 08:59:00PM +0400, Игорь Пашев wrote:
Debian is not Debian without non-Linux ports.
You are entitled to your opinion, which is what this is. Debian
certainly was Debian without non-Linux ports prior to February
2011, and some are of the opinion that it should be again in
On Wed, Oct 30, 2013 at 07:25:55PM +, Kevin Chadwick wrote:
Couldn't they just be ignored not to mention already having existing or
far more functional and robust *options* that work with any init system.
A cursory glance at the example above…
PrivateTmp=yes
On Wed, 30 Oct 2013 20:39:32 + Jonathan Dowland wrote:
[...] Debian without non-Linux ports prior to February
2011, [...]
That's only when a non-Linux Debian port (GNU/kFreeBSD) first became a
_release architecture_; it existed as a port since May 2003. Hurd has
been an official unstable
previously on this list Jonathan Dowland contributed:
Couldn't they just be ignored not to mention already having existing or
far more functional and robust *options* that work with any init system.
A cursory glance at the example above…
PrivateTmp=yes
Kevin Chadwick ma1l1i...@yahoo.co.uk writes:
Well I meant that they would be used by systemd and ignored likely
noisily by default by others. However this really should be the job of
the service in any case as depending on a third party service for
security that isn't extra such as
previously on this list Russ Allbery contributed:
Well I meant that they would be used by systemd and ignored likely
noisily by default by others. However this really should be the job of
the service in any case as depending on a third party service for
security that isn't extra such as
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
Tollef Fog Heen tfh...@err.no writes:
]] 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
Thorsten,
On Mon, Oct 28, 2013 at 05:23:33PM +, Thorsten Glaser wrote:
Lucas Nussbaum leader at debian.org writes:
I think that it would be a failure of the Debian project if we had to
have a GR about such a technical decision. I think that we need to
trust that the Technical
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
1 - 100 of 147 matches
Mail list logo
