emninger@??? wrote:
> Am Mon, 12 Sep 2016 08:31:54 +0000
> schrieb Jaromil <jaromil@???>:
>
> > not at all. We even plan to roll out our own openrc package, ditching
> > the one from Debian which has many problems. Perhaps what you are
> > hitting is one of them.
> >
> > For Devuan's Openrc we will follow the design proposed by upstream and
> > Gentoo's, the maintainer volunteering for this is Parazyd (also on
> > this list) who works with us at Dyne.org. We will also use Openrc in
> > our projects and are advocating for it as the next new standard in
> > Devuan ascii, at the condition of a 100% smooth transition from
> > sysvinit.
> >
> > At last, we haven't done anything on the OpenRC package yet so your
> > problems are entirely caused by the Debian maintainership, which can't
> > be trusted at all, IMHO
>
> Thanks a lot Jaromil for the info.
>
> It's not - by chance ;) - i could
> pickup from somewhere a beta of the OpenRC package you're working on?
>
> I hate the idea to redo several scripts (i - painfully ;) adapted from
> Gentoo to the previous deb version to make them work with the debian
> crippeled openrc) to make them goable for sysvinit.
>
> In any case, me for one (simple user!), i like a lot the idea to use the
> original gentoo style openrc - and i like openrc for its ease to use.

I'll be interested how this work goes. If I understand
correctly, system startup with Devuanized openrc will be
totally handled for the user, the way it is with sysvinit
now.

To that extent, I'm sure openrc will offer "ease of use",
however going by the feature set and documentation, openrc
aims at a more comprehensive offering (from https://en.wikipedia.org/wiki/OpenRC):

    Parallel service startup (optional, in development)[3]
    Process segregation through cgroups
    Per-service resource limits (ulimit)
    Separation of code and configuration (init.d / conf.d)
    Ability to include an unlimited variety of commands beyond basic "start, stop, and status"
    Stateful init scripts (is it started already?)
    Complex init scripts to start multiple components (Samba (smbd and nmbd), NFS (nfsd, portmap, etc.))
    Automatic dependency calculation and service ordering
    Proper integration into container/virtualization (Linux-VServer, OpenVZ, etc.)[4]
    Proper modular architecture and separation of optional components (Cron, syslog)
    Expressive and flexible network handling (including VPN, bridges, etc.)
    Support for bare-metal bare-dependency servers[5][6]

OOTB support for Samba and NFS (along with being Devuan
default) will definitely win users.

All that is ease of use, but technically speaking, runit
is much simpler and less to master.


> Cheers!

--
Joel Roth