https://github.com/davmac314/dinit/blob/master/doc/COMPARISON#L71
It's a shame that this gets a number of things wrong about several of the
systems.
Jonathan de Boyne Pollard:
To anyone running the service manager and bundles from nosh version
1.28 or later on Linux: You are encouraged to look at your control
group hierarchy, with a tool like "systemd-cgls /", with the "cgroup"
field of the ps command, or by simply listing your
Guillermo:
I suppose the interesting suprise is that as consequence, when a
service definition gets 'imported' to nosh from a unit file (and this
covers pretty much everything in the nosh-bundles* binary
packages),the corresponding service gets placed in a cgroup of its own
when launched by
2016-12-07 6:26 GMT-03:00 Jean Louis:
>
> On Wed, Dec 07, 2016 at 09:14:00AM +, Jonathan de Boyne Pollard wrote:
>> [...]
>> To anyone running the service manager and bundles from nosh version 1.28 or
>> later on Linux: You are encouraged to look at your control group hierarchy,
>> with a
of
capacility control (eg. one example for ulimit, plus one example for
cgroup) into the comparison page, or an independent page.
Such "systemd supporters" don't actually know systemd.
* http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html
To anyone running the servi
Many thanks :)
On Tue, Dec 06, 2016 at 12:53:14AM +, Jonathan de Boyne Pollard wrote:
> * http://jdebp.eu./Softwares/nosh/guide.html
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Casper Ti. Vector:
the docs are in tarballs on jdebp.eu
* http://jdebp.eu./Softwares/nosh/guide.html
of chainloading with reference to
already employed capability control chainloaders (ulimit, user/group...)
in the init script comparison page would, to some extent, prepare the
impatient reader for the contents to come.
On Mon, Dec 05, 2016 at 09:31:20AM +, Jonathan de Boyne Pollard wrote
Casper Ti. Vector:
one example for ulimit
An irony here is that the page *already contains* two entire sets of
examples that set memory resource limits, using daemontools,
daemontools-encore, freedt, perp, s6, and nosh tools.
On 6/15/2015 9:00 PM, Colin Booth wrote:
I only know s6 and runit well enough to comment on for the most part but
filling in some blanks on your matrix:
Updated, thanks for the help. As I said, it's a start. It'll need some
time to improve. I mostly needed it for the project, to help me
AM
To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org
Subject: Re: comparison
On Tue, 16 Jun 2015 04:05:29 -0700
James Powell james4...@hotmail.com wrote:
I agree Laurent. Though, even though complete init+supervision
systems like Runit exist, it's been nearly impossible to get
Paynemailto:avery.p.pa...@gmail.com
Sent: 6/16/2015 11:26 AM
To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org
Subject: Re: comparison
On 6/16/2015 5:22 AM, James Powell wrote:
Very true, but something always seems to say something along the lines of if
we had done #2 years ago
Implying that the distributions would have transitioned from System
V-style to daemontools-style mechanisms?
Strongly doubt it.
For all the noise and controversy that's been happening over PID1, I
always got the impression that most distros back in the day simply
didn't care. They happily
AM
To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org
Subject: Re: comparison
On 6/16/2015 5:22 AM, James Powell wrote:
Very true, but something always seems to say something along the
lines of if we had done #2 years ago, we might have avoided a huge
mess that now
On 16/06/2015 22:32, post-sysv wrote:
Soon systemd arrives with its promise of being a unified userspace
toolkit that systems developers can supposedly just plug in and
integrate without hassle to get X, Y and Z advantages. No more
writing initscripts, no more setting policy because systemd will
: comparison
On 16/06/2015 22:32, post-sysv wrote:
Soon systemd arrives with its promise of being a unified userspace
toolkit that systems developers can supposedly just plug in and
integrate without hassle to get X, Y and Z advantages. No more
writing initscripts, no more setting policy because
On Tue, 16 Jun 2015 09:29:15 +0200
Laurent Bercot ska-supervis...@skarnet.org wrote:
In the meantime, if you don't want to get your hands dirty,
you can still use s6-svscan/s6-supervise as a process supervision
system without trying to make it run as an init system, just as you
can use
On Tue, 16 Jun 2015 09:29:15 +0200
Laurent Bercot ska-supervis...@skarnet.org wrote:
On 16/06/2015 04:54, Steve Litt wrote:
One thing I can tell you is that daemontools and daemontools-encore
were never intended to be init systems, whereas I'm pretty sure that
runit, s6 and nosh intended
On Mon, 15 Jun 2015 17:37:45 -0700
Buck Evan b...@yelp.com wrote:
Is there any resource that compares the capabilities of daemontools,
daemontools-encore, runit, s6, and friends?
One thing I can tell you is that daemontools and daemontools-encore
were never intended to be init systems, whereas
On Mon, 15 Jun 2015 17:37:45 -0700
Buck Evan b...@yelp.com wrote:
Is there any resource that compares the capabilities of daemontools,
daemontools-encore, runit, s6, and friends?
One more thing: It's been my subjective impression that
daemontools-encore is a lot easier to install, set up, and
I only know s6 and runit well enough to comment on for the most part but
filling in some blanks on your matrix:
Daemontools is public domain, freedt is the OpenBSD license (which doesn't
appear to currently exist according to the OpenBSD licensing page). I'd
treat it like the ISC license.
I'm working on something similar, but you're asking for capabilities,
and most of what I have is a mapping. I've tried to include a few
critical links in the comparison for the various homepages, licenses,
source code, etc. It's incomplete for now, but it's a start.
https://bitbucket.org
22 matches
Mail list logo
