upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.

sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
also cannot coexist.

so openrc is not an init subsystem on its own.

deamontools are IMHO helpers for broken software like java application
which cannot daemonize itself under unix becaouse of java desing. trying to
convince people that writing unix daemons the old way is badthing(tm).

maybe i should go back to sls.
--
regards
piotr
04-05-2016 18:49, "Steve Litt" <slitt@???> napisał(a):

> On Wed, 4 May 2016 09:54:37 -0400 (EDT)
> Rob Owens <rowens@???> wrote:
>
> > ----- Original Message -----
> > > From: "Steve Litt" <slitt@???>
> >
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > Rob Owens <rowens@???> wrote:
> > >
> > >> I agree with putting each init in its own directory, but sysvinit
> > >> should not own /etc/init.d. sysvinit stuff should go
> > >> in /etc/sysvinit and by default /etc/init.d should be a link
> > >> to /etc/sysvinit/init.d. The reason is that other init systems may
> > >> expect to own /etc/init.d. For instance, openrc puts all its
> > >> scripts in /etc/init.d (at least on Funtoo it does).
> > >
> > > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > > and the only one I know that wants to do that is systemd.
> > >
> > > I wouldn't change sysvinit's expected files one little bit. Everyone
> > > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > > change to sysvinit would require lots of testing, and who needs
> > > that headache?
>
> > Then you would be designing under the assumption that sysvinit is the
> > "one true way"
>
> Not "one true way", but "it's what we have right now, let's not mess
> with it.
>
> > and that all others must be modified to work around
> > sysvinit -- an init system that you/we are actively attempting to make
> > obsolete (eventually) by way of providing all these alternatives.
>
> The other inits should have had the good sense not to entangle
> themselves with sysvinit, and in fact most of them did have that good
> sense, so for them this is a moot point.
>
> At this point I'm not sure that *any* init system other than sysvinit
> puts its daemon starting code/config under /etc/init.d. But if there is
> such an init system putting its stuff under/etc/init.d, that's some
> serious hubris. They could have taken their own namespace, but nooooo,
> they polluted the namespace used by sysvinit for 30 years. If there is
> such an init system, moving their script/config storage is actually
> correcting a problem caused by the init system.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>