On Wed, Mar 14, 2012 at 7:22 PM, Timo Weingärtner wrote:
> Why do people always forget that there is service(8)?
I personally got used to using /etc/init.d/foo before service existed.
So its not that people forget about service, but that they never
learnt about it.
--
bye,
pabs
http://wiki.deb
Hallo,
2012-03-14 um 01:30:45 schrieb Paul Wise:
> On Wed, Mar 14, 2012 at 7:33 AM, Juliusz Chroboczek wrote:
> > (There's a third issue, of course, which is whose environment the daemon
> > should be inheriting -- the sanitised environment of init, or the
> > environment of the shell of whoever i
On Wed, Mar 14, 2012 at 7:33 AM, Juliusz Chroboczek wrote:
> (There's a third issue, of course, which is whose environment the daemon
> should be inheriting -- the sanitised environment of init, or the
> environment of the shell of whoever is running "/etc/init.d/foo start"
> or whatever.)
That i
>>> Maybe we could have an intermediate goal to patch any daemon to add an
>>> option to not fork on start.
>> Yes, please. All the more so since it is effort well-spent,
> No, this is not an effort well spent. And as already mentioned,
> running the daemon in foreground has unwanted side-e
Russ Allbery writes:
> Goswin von Brederlow writes:
>> Vincent Bernat writes:
>>> Goswin von Brederlow writes:
>
That would actually make things more difficult since then you have to
add some delay into the sysvinit files to wait for the daemon to
become ready before the init.d
On 11.03.2012 20:24, Juliusz Chroboczek wrote:
>> Maybe we could have an intermediate goal to patch any daemon to add an
>> option to not fork on start.
>
> Yes, please. All the more so since it is effort well-spent, as it is
No, this is not an effort well spent. And as already mentioned, r
Goswin von Brederlow writes:
> Vincent Bernat writes:
>> Goswin von Brederlow writes:
>>> That would actually make things more difficult since then you have to
>>> add some delay into the sysvinit files to wait for the daemon to
>>> become ready before the init.d script returns.
>> Is start-st
Vincent Bernat writes:
> OoO Pendant le repas du dimanche 11 mars 2012, vers 19:24, Goswin von
> Brederlow disait :
>
>>> Yes, but systemd relies on cgroups which are not portable. If all
>>> daemons were able to not fork, it would be easier to convert a .service
>>> file to a classi
> Maybe we could have an intermediate goal to patch any daemon to add an
> option to not fork on start.
Yes, please. All the more so since it is effort well-spent, as it is
likely to be useful not only for systemd and upstart, but also for
whatever service management daemon comes next. (Not
OoO Pendant le repas du dimanche 11 mars 2012, vers 19:24, Goswin von
Brederlow disait :
>> Yes, but systemd relies on cgroups which are not portable. If all
>> daemons were able to not fork, it would be easier to convert a .service
>> file to a classic init.d script and therefore use
Vincent Bernat writes:
> OoO Vers la fin de l'après-midi du dimanche 11 mars 2012, vers 16:14,
> Fernando Lemos disait :
>
>>> Maybe we could  have an intermediate goal to patch any  daemon to add an
>>> option  to not  fork on  start.  If  any daemon  can be  started
>>> without
OoO Vers la fin de l'après-midi du dimanche 11 mars 2012, vers 16:14,
Fernando Lemos disait :
>> Maybe we could have an intermediate goal to patch any daemon to add an
>> option to not fork on start. If any daemon can be started without
>> forking, it seems easy to start/stop them wi
On Sun, Mar 11, 2012 at 7:25 AM, Vincent Bernat wrote:
> OoO En cette nuit nuageuse du mercredi 07 mars 2012, vers 00:21,
> Fernando Lemos disait :
>
>>> To give one particular example: systemd uses Linux-specific features to
>>> accurately track all the processes started by a service, wh
OoO En cette nuit nuageuse du mercredi 07 mars 2012, vers 00:21,
Fernando Lemos disait :
>> To give one particular example: systemd uses Linux-specific features to
>> accurately track all the processes started by a service, which allows
>> accurate monitoring and shutdown of processes whi
On 08.03.2012 20:40, Steve Langasek wrote:
> The sshd process that supervises the user's session is not part of the pam
> session. It *must* sit outside of it, to ensure proper teardown. And this
> process should persist across restarts of the sshd service. So killing all
> processes in the ssh
On Thu, Mar 08, 2012 at 08:11:11AM +0100, Tollef Fog Heen wrote:
> > There are also complications to using cgroups, in that suddenly any service
> > that needs to be able to spawn long-running processes that outlive the
> > service has to start caring about cgroups - both so that they survive the
>
Tollef Fog Heen writes:
> ]] Russ Allbery
>> Er, "UsePAM no"?
> That's «changing sshds configuration» which for most people is on a
> completely different scale than patching the application itself. UsePAM
> yes is also the default nowadays.
That reduces the scope of affected users, but it do
]] Russ Allbery
> Tollef Fog Heen writes:
> > ]] Steve Langasek
>
> >> ssh is going to be the first problem in this regard, though I'm sure
> >> there will be others. Has someone patched openssh to be cgroup-aware?
>
> > This is most of what libpam-systemd does. No need to patch sshd itself
Tollef Fog Heen writes:
> ]] Steve Langasek
>> ssh is going to be the first problem in this regard, though I'm sure
>> there will be others. Has someone patched openssh to be cgroup-aware?
> This is most of what libpam-systemd does. No need to patch sshd itself.
Er, "UsePAM no"?
sshd has a
]] Steve Langasek
> There are also complications to using cgroups, in that suddenly any service
> that needs to be able to spawn long-running processes that outlive the
> service has to start caring about cgroups - both so that they survive the
> service being shut down from the outside, and so t
Michael Biebl writes:
> Am 07.03.2012 23:34, schrieb Michael Biebl:
>> On 07.03.2012 22:46, Steve Langasek wrote:
>>> On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
>>>
It's rather easy to confuse upstart's process tracking. You
explicitly have to tell upstart if a daemo
On Thu, 8 Mar 2012 02:25:52 +0100
m...@linux.it (Marco d'Itri) wrote:
I'm not taking a stance on the wider issue, just wanted to comment on
these two points.
> On Mar 06, Wouter Verhelst wrote:
>
> > > Should Debian reject using > > system
> > > component> just to support toy ports which are
On Mar 06, Wouter Verhelst wrote:
> > Should Debian reject using > component> just to support toy ports which are used by a dozen of people?
> Except that kFreeBSD is not a toy port.
>
> FreeBSD is a serious operating system that is used by many people in
> system-critical applications, which r
Am 07.03.2012 23:34, schrieb Michael Biebl:
On 07.03.2012 22:46, Steve Langasek wrote:
On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
It's rather easy to confuse upstart's process tracking. You
explicitly have to tell upstart if a daemon forks once or twice
(expect daemon, expe
Steve Langasek wrote:
> There are also complications to using cgroups, in that suddenly any service
> that needs to be able to spawn long-running processes that outlive the
> service has to start caring about cgroups - both so that they survive the
> service being shut down from the outside, and so
On 07.03.2012 22:46, Steve Langasek wrote:
> On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
>
>> It's rather easy to confuse upstart's process tracking. You
>> explicitly have to tell upstart if a daemon forks once or twice
>> (expect daemon, expect fork) and if the daemon forks mu
On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
> > By the way, upstart uses ptrace for this:
> > http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/
> > It's an interesting trick, and probably more portable too.
> It's an ugly hack, even Scott didn't like t
Peter Samuelson wrote:
> [Josh Triplett]
> > To give one particular example: systemd uses Linux-specific features
> > to accurately track all the processes started by a service, which
> > allows accurate monitoring and shutdown of processes which could
> > otherwise disassociate themselves from the
Detailed replies below, but first of all, a quick top-level response,
because in my previous mail I missed mentioning an obvious point:
systemd can easily become the default for Debian GNU/*Linux* without
necessarily becoming the default for Debian GNU/kFreeBSD. This seems
like the most likely sce
Michael Biebl writes:
> On 07.03.2012 00:21, Fernando Lemos wrote:
>> Hi,
>>
>> On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett wrote:
>>> To give one particular example: systemd uses Linux-specific features to
>>> accurately track all the processes started by a service, which allows
>>> accurate
On 07.03.2012 00:21, Fernando Lemos wrote:
> Hi,
>
> On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett wrote:
>> To give one particular example: systemd uses Linux-specific features to
>> accurately track all the processes started by a service, which allows
>> accurate monitoring and shutdown of proc
On Tue, Mar 06, 2012 at 02:46:44PM -0800, Josh Triplett wrote:
> Wouter Verhelst wrote:
> > On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> > > On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > > > But I do think that writing portable software isn't that hard, and
Peter Samuelson (06/03/2012):
> This "one particular example" is the same feature (cgroups) that
> everyone keeps talking and talking about. Everyone keeps saying
> "systemd uses Linuxisms like cgroups", but nobody mentions any others.
> Is this the only major Linuxism in systemd, or is it just t
[Josh Triplett]
> To give one particular example: systemd uses Linux-specific features
> to accurately track all the processes started by a service, which
> allows accurate monitoring and shutdown of processes which could
> otherwise disassociate themselves from their parent processes via the
> us
On Wed, Feb 29, 2012 at 09:54:56AM +0100, Goswin von Brederlow wrote:
> >> One of the worst contributors to the use of 'script' in upstart jobs
> >> instead of 'exec' is the need for backwards-compatibility with pre-upstart
> >> /etc/default/* files. The options here are all fairly poor:
> >> -
Hi,
On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett wrote:
> To give one particular example: systemd uses Linux-specific features to
> accurately track all the processes started by a service, which allows
> accurate monitoring and shutdown of processes which could otherwise
> disassociate themselve
Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> > On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > > But I do think that writing portable software isn't that hard, and that
> > > not
> > > doing it is pure lazyness.
> >
> > It's not abou
]] Wouter Verhelst
> kFreeBSD is already part of Debian. Systemd is not. The answer would
> seem to be obvious.
$ rmadison systemd
systemd | 37-1| wheezy | source, amd64, armel, i386, ia64, mips, mipsel,
powerpc, s390, s390x, sparc
systemd | 37-1+b1 | wheezy | armhf
systemd | 37-1.1 | s
On Tue, Mar 06, 2012 at 03:58:49PM +, Ben Hutchings wrote:
> Do jails still provide features that LXC does not?
Like, say, any security separation at all?
LXC is a glorified chroot with some scheduler niceties and a way to set
default IP for a group of processes. If you want any security ben
On Tue, Mar 06, 2012 at 08:07:37AM +0100, Wouter Verhelst wrote:
> On Mon, Mar 05, 2012 at 02:44:45PM +0100, Marco d'Itri wrote:
> > On Mar 05, Marc Haber wrote:
> >
> > > Should Debian restrict itself to being a Linux platform just to have
> > > systemd?
> > If it is worth it, yes.
> >
> > Shou
One more thing...
On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > But I do think that writing portable software isn't that hard, and that not
> > doing it is pure lazyness.
>
> It's not about difficulty, systemd i
On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> The features you've defended FreeBSD for (jails, ZFS) are not portable either;
> which is to say, if you write software that depends on them, it won't work on
> Linux.
Very true.
However, the difference between the systemd position an
On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> > Er, let's not call upstream lazy just because they don't want to do
> > work that has no interest for themselves.
>
> I don't see what else I should call them.
>
On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> > Er, let's not call upstream lazy just because they don't want to do
> > work that has no interest for themselves.
>
> I don't see what else I should call them.
I
On Tue, Mar 06, 2012 at 07:23:53AM +, Philip Hands wrote:
> On Tue, 6 Mar 2012 08:07:37 +0100, Wouter Verhelst wrote:
>
> > So far, I haven't seen any features in systemd that outweigh those. And
> > the fact that upstream is lazy and doesn't want to do this portability
> > thing shouldn'
On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> On Tue, Mar 06, 2012 at 08:07:37AM +0100, Wouter Verhelst wrote:
> > So far, I haven't seen any features in systemd that outweigh those. And
> > the fact that upstream is lazy and doesn't want to do this portability
> > thing shouldn
On Mon, 2012-03-05 at 14:44 +0100, Marco d'Itri wrote:
> On Mar 05, Marc Haber wrote:
>
> > Should Debian restrict itself to being a Linux platform just to have
> > systemd?
> If it is worth it, yes.
>
> Should Debian reject using component> just to support toy ports which are used by a dozen o
On Tue, Mar 06, 2012 at 08:07:37AM +0100, Wouter Verhelst wrote:
> So far, I haven't seen any features in systemd that outweigh those. And
> the fact that upstream is lazy and doesn't want to do this portability
> thing shouldn't mean we should throw out our other ports.
Er, let's not call upstrea
On Tue, 6 Mar 2012 08:07:37 +0100, Wouter Verhelst wrote:
...
> So far, I haven't seen any features in systemd that outweigh those. And
> the fact that upstream is lazy and doesn't want to do this portability
> thing shouldn't mean we should throw out our other ports.
I know it's already been men
On Mon, Mar 05, 2012 at 02:44:45PM +0100, Marco d'Itri wrote:
> On Mar 05, Marc Haber wrote:
>
> > Should Debian restrict itself to being a Linux platform just to have
> > systemd?
> If it is worth it, yes.
>
> Should Debian reject using component> just to support toy ports which are used by a
On Mar 05, Marc Haber wrote:
> Should Debian restrict itself to being a Linux platform just to have
> systemd?
If it is worth it, yes.
Should Debian reject using just to support toy ports which are used by a dozen of people?
> Debian being a platform which is frequently used for low-powered,
>
On Sun, 4 Mar 2012 16:54:22 +0100, Matthias Klumpp
wrote:
>No, and that's why this is an issue very specific to Debian. But the
>above examples show, that systemd (or upstart) can bring many useful
>features and improvements to Linux platforms.
Should Debian restrict itself to being a Linux platf
2012/3/4 Marc Haber :
> On Sun, 26 Feb 2012 01:19:14 +0100, Matthias Klumpp
> wrote:
>>Debian - as always - is extremely slow in making a decision on this,
>>but this time it might be an advantage: Fedora, openSUSE, Mageia, etc.
>>already switched to systemd (and Ubuntu, AFAIK the only distributio
On Sun, 26 Feb 2012 01:19:14 +0100, Matthias Klumpp
wrote:
>Debian - as always - is extremely slow in making a decision on this,
>but this time it might be an advantage: Fedora, openSUSE, Mageia, etc.
>already switched to systemd (and Ubuntu, AFAIK the only distribution
>using upstart at time)
Di
On Tue, Feb 28, 2012 at 02:36:11PM +, Ian Jackson wrote:
> Josselin Mouette writes ("Re: upstart: please update to latest upstream
> version"):
> > Or, as has been said countless times otherwise: kFreeBSD should not
> > hinder the improvement of the Linux ports.
* Matthias Klumpp:
> He does not want portability patches in systemd, because much
> invasive changes would be needed, making the code more difficult to
> read (which might even lead to buggy code).
It seems that this also applies to older Linux versions. According to
the documentation, the curr
Marco d'Itri writes:
> On Feb 29, Russell Coker wrote:
>
>> One thing that would be really convenient in such situations is the ability
>> to
>> have the old and new versions of the package installed such that the new
>> version would run the old version if appropriate.
> Yes. Except that thi
On Feb 29, Russell Coker wrote:
> One thing that would be really convenient in such situations is the ability
> to
> have the old and new versions of the package installed such that the new
> version would run the old version if appropriate.
Yes. Except that this was not applicable to udev bec
On Thu, 1 Mar 2012, "Marco d'Itri" wrote:
> > them. But that isn't really the kernels fault. It's udevs fault for not
> > supporting both ways from the start.
>
> Talk is cheap. Supporting both sysfs layouts would have had a
> significant maintenance overhead.
> Red Hat does not support upgrading
On Feb 29, Goswin von Brederlow wrote:
> Lets hope it is improving. But that only shows that depending on
> controversial linux features should still be a concern.
Expect more of the same (IIRC in the next upload), because the udev
upstream maintainer likes to use modern kernel features.
The same
Darren Salt writes:
> I demand that Steve Langasek may or may not have written...
>
> [snip]
>> One of the worst contributors to the use of 'script' in upstart jobs
>> instead of 'exec' is the need for backwards-compatibility with pre-upstart
>> /etc/default/* files. The options here are all fai
Ben Hutchings writes:
> On Tue, Feb 28, 2012 at 09:58:01PM +0100, Goswin von Brederlow wrote:
>> Ben Hutchings writes:
>>
>> > On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
>> >> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
>> >> > Roger Leigh wrote:
>> >> > > On
I demand that Steve Langasek may or may not have written...
[snip]
> One of the worst contributors to the use of 'script' in upstart jobs
> instead of 'exec' is the need for backwards-compatibility with pre-upstart
> /etc/default/* files. The options here are all fairly poor:
>
> - ignore the a
On Feb 28, Svante Signell wrote:
> > means permanently tying ourselves to the Linux kernel.
> Definitely, and this is not in line with Debian goals.
Says who?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Feb 28, Ian Jackson wrote:
> The Linux kernel project has some serious and ongoing structural
> problems and I think it's very important that as a project we keep our
> options open.
Even if I were willing to accept this argument as valid[1], it's worth
remembering that switching to a new (an
On Tue, Feb 28, 2012 at 09:58:01PM +0100, Goswin von Brederlow wrote:
> Ben Hutchings writes:
>
> > On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
> >> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
> >> > Roger Leigh wrote:
> >> > > On Fri, Feb 24, 2012 at 04:20:47PM
Ben Hutchings writes:
> On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
>> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
>> > Roger Leigh wrote:
>> > > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
>> > > > > [note: it's somewhat desirable for them to be
]] Ian Jackson
> Josselin Mouette writes ("Re: upstart: please update to latest upstream
> version"):
> > Or, as has been said countless times otherwise: kFreeBSD should not
> > hinder the improvement of the Linux ports.
>
> It's not just kFreeBSD.
On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
> > Roger Leigh wrote:
> > > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> > > > > [note: it's somewhat desirable for them to be optional on Linux
> > > > > t
On Tue, 28 Feb 2012, Russ Allbery wrote:
> When people are complaining about Canonical's contributor licensing
> agreement, saying that something is appealing because it's a GNU
> project is kind of amusing. I, for one, have even more of a problem
> contributing to FSF projects that require copyrig
Matt Zagrabelny writes:
> On Tue, Feb 28, 2012 at 12:22 PM, Russ Allbery wrote:
>> I, for one, have even more of a problem contributing to FSF projects
>> that require copyright assignment than I would contributing to upstart.
> Would you comment on why you have issues with the FSF contributor
On Tue, Feb 28, 2012 at 12:22 PM, Russ Allbery wrote:
> I, for one, have even more of a problem
> contributing to FSF projects that require copyright assignment than I
> would contributing to upstart.
Hi Russ,
Would you comment on why you have issues with the FSF contributor agreement?
Thanks,
Svante Signell writes:
> There are alternatives to systemd and upstart available: runit and GNU
> DMD ("Daemon managing Daemons") as well as links to other OS init
> systems at http://smarden.org/runit/. The DMD looks a little
> unmaintained though, latest release in 2003, but at least this is a
On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
> Excuse me, but what you're implying here is that systemd can dictate
> the development of kernel interfaces. Sorry, but that's too far.
> Can't you see the massive problem here? You are now preventing
> cgroups being removed from the
On Tue, 2012-02-28 at 17:25 +0100, Josselin Mouette wrote:
> Le mardi 28 février 2012 à 14:36 +, Ian Jackson a écrit :
> > It's not just kFreeBSD. Accepting systemd, in the current state,
> > means permanently tying ourselves to the Linux kernel.
> >
> > The Linux kernel project has some ser
On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
> Roger Leigh wrote:
> > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> > > > [note: it's somewhat desirable for them to be optional on Linux
> > > > too, to prevent feature lock-in and future compatibility problems].
> >
Le mardi 28 février 2012 à 14:36 +, Ian Jackson a écrit :
> It's not just kFreeBSD. Accepting systemd, in the current state,
> means permanently tying ourselves to the Linux kernel.
>
> The Linux kernel project has some serious and ongoing structural
> problems and I think it's very importan
On Tue, 2012-02-28 at 14:36 +, Ian Jackson wrote:
> Josselin Mouette writes ("Re: upstart: please update to latest upstream
> version"):
> > Or, as has been said countless times otherwise: kFreeBSD should not
> > hinder the improvement of the Linux ports.
Josselin Mouette writes ("Re: upstart: please update to latest upstream
version"):
> Or, as has been said countless times otherwise: kFreeBSD should not
> hinder the improvement of the Linux ports.
It's not just kFreeBSD. Accepting systemd, in the current state,
me
On 28/02/12 11:08, Riku Voipio wrote:
> What is more important is to provide the
> infrastructure to avoid the need of scripting in first place. Like in upstart
> where there are handy stanzas like umask, env, nice, limit, and so on.
This is the reason I like systemd and Upstart better than sysvin
On Mon, Feb 27, 2012 at 10:12:07AM -0800, Steve Langasek wrote:
> No disagreement with any of that. But how high is that price, in point of
> fact? If no one's measured it, then converting scripts to C programs to
> avoid the added exec() calls is premature optimization.
If it were just blindl
Steve Langasek writes:
> On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
>> > Well, I fudged a little here. You're right that, as written above, nis is
>> > not guaranteed to start before autofs. Due to a (well-understood and
>> > recognized) limitation of upstart's curren
On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
> > Well, I fudged a little here. You're right that, as written above, nis is
> > not guaranteed to start before autofs. Due to a (well-understood and
> > recognized) limitation of upstart's current event handling, if the
> > '
Goswin von Brederlow wrote:
> Steve Langasek writes:
> > /etc/default/* files. The options here are all fairly poor:
> Option 2 is also bad. There is a reason why we have /etc/default instead
> of setting the options in the init.d scripts directly. Most importantly
> the init.d scripts can be up
I said this in another message, but I'm not sure I was sufficiently
explicit, so I'm going to try again to inject a bit more reality into this
thread.
The next step for looking at alternative init systems is finalizing the
Policy changes that are required to support alternative init systems.
That
Steve Langasek writes:
> I would certainly welcome it if someone did profiling that showed whether
> the shells are a bottleneck. My own subjective experience is that this is
> probably not the low-hanging fruit on a general-purpose distro, but if it
> turns out that there are significant speed
Steve Langasek wrote:
> If no one's measured it, then converting scripts to C programs to
> avoid the added exec() calls is premature optimization. If the only
You keep repeating the same FUD. Again, avoiding shell is not just an
optimization, much less a premature one. Also, if I understand the
Matthias Klumpp, le Mon 27 Feb 2012 18:42:39 +0100, a écrit :
> 2012/2/27 Samuel Thibault :
> > Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> >> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> >> discussion is the comparison of these three init systems:
> >> h
On Mon, Feb 27, 2012 at 12:24:25PM +0200, Riku Voipio wrote:
> On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > > I have. Not on debian, but on debianish system with dash. And the result
> > > was that shellscripts are indeed the bottleneck. We still did convert to
> > > upstart
2012/2/27 Samuel Thibault :
> Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
>> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
>> discussion is the comparison of these three init systems:
>> http://0pointer.de/blog/projects/why.html
>> Of course, Lennart Poetterin
On Mon, Feb 27, 2012 at 05:45:14PM +0100, Matthias Klumpp wrote:
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points ment
Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points mention
Maybe interesting to read in this upstart vs. systemd vs. sysvinit
discussion is the comparison of these three init systems:
http://0pointer.de/blog/projects/why.html
Of course, Lennart Poettering did this, but the points mentioned are
valid. (Although the list is a bit outdated, at least on upstar
On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > I have. Not on debian, but on debianish system with dash. And the result
> > was that shellscripts are indeed the bottleneck. We still did convert to
> > upstart since we believed it would allow us to cut down the amount of
> > sh
On 21/02/12 22:57, Michael Biebl wrote:
On 21.02.2012 21:25, Russ Allbery wrote:
The most likely way forward is some period where either can be used and we
see how things shake out. Unfortunately, neither currently supports
kFreeBSD. The upstart upstream seems more amenable to doing so than t
On Sun, Feb 26, 2012 at 17:24, Goswin von Brederlow wrote:
> Maybe the solution isn't event base or dependency based. Maybe the
> right solution is event based and dependency based.
In one sense this is obviously right. Any solution has to respond to
various kinds of events and has to be able to
On Sun, 2012-02-26 at 17:24 +0100, Goswin von Brederlow wrote:
> Steve Langasek writes:
>
> > On Fri, Feb 24, 2012 at 10:55:46PM +0100, Thomas Hood wrote:
> >> On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote:
> >> > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote:
> >
>
Steve Langasek writes:
> On Fri, Feb 24, 2012 at 10:55:46PM +0100, Thomas Hood wrote:
>> On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote:
>> > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote:
>
>> >> Upstart also does not support Should-Start which makes it impossible to
Arno Töll writes:
> On 24.02.2012 17:07, Goswin von Brederlow wrote:
>> Josselin Mouette writes: And we write a
>> compatibility layer for non-Linux
>>> systems, that generates sysvinit-compatible scripts based on
>>> systemd services or upstart jobs.
> ...
>> So what you are saying is:
>>
>> L
Steve Langasek writes:
> Now, parts of this design were hard won, based on issues encountered in the
> first iteration of event-based booting in Ubuntu. Since that first
> iteration is present in the only Ubuntu LTS release to date that uses native
> upstart jobs, it's possible this is where you
1 - 100 of 252 matches
Mail list logo
