[gentoo-soc] report 7.16-7.23: improving OpenRC

[gentoo-soc] report 7.16-7.23: improving OpenRC

[heroxbd]

Dear Guys and Gals,

After the mid term evaluation, this project shifts its emphasis from
Prefix support to improving OpenRC (borrowing ideas from brother
systems)

During the last week, the following are finished:

       1. deploy a Debian Unstable(aka. Sid) VM for OpenRC dev
       2. a deep look into Debian's existing init framework
          init, LSB headers, insserv
       3. a check of dependency handling and script sourcing in OpenRC

Next week, the following tasks are scheduled:

     1. use OpenRC to boot a Debian system
     2. find a way for OpenRC to use debian LSB init-scripts
        OR, find a way to convert LSB init-scripts to OpenRC scripts
     3. Patch OpenRC build system to respect EPREFIX (yes, take this by myself)
     
the following tasks are natural consequences and not scheduled:
    
    a. find a way for debian rc system to use OpenRC scripts
       OR, find a way to convert OpenRC scripts to LSB init-scripts
    b. bump OpenRC and push it into Gentoo Prefix tree

Yours,
Benda

[gentoo-soc] report 7.24-8.7: improving OpenRC

[heroxbd]

Dear Guys and Gals,

heroxbd@gmail.com writes:

> After the mid term evaluation, this project shifts its emphasis from
> Prefix support to improving OpenRC (borrowing ideas from brother
> systems)
>

During the last two weeks, the following are finished:

>      1. use OpenRC to boot a Debian system
       
       DONE
       
>      2. find a way for OpenRC to use debian LSB init-scripts
>         OR, find a way to convert LSB init-scripts to OpenRC scripts

       DONE, it is the "lsb.pl" script.

       The process is documented at http://wiki.debian.org/OpenRC

>      3. Patch OpenRC build system to respect EPREFIX (yes, take this by myself)

       I reviewed my old patch at bug 415899, and it seems to be able to
       serve as a base for the prefix integration.

bonus:

   ccxCZ from #openrc made a GLEP draft
        
        http://wpr.cz/ccx/wobsite/article/openrc-supervisor.html

   The interesting point to me is to make openrc running closely
   with daemontools and runit for extended features.

   In this project proposal, modern extensions (a timer, a oom-killer, a
   daemon watcher) were discussed. To make openrc friendly talk to other
   tools (cron, incron, runit, etc.) to achieve these extensions are
   closest to my heart.
       
> the following tasks are natural consequences and not scheduled:
>     
>     a. find a way for debian rc system to use OpenRC scripts
>        OR, find a way to convert OpenRC scripts to LSB init-scripts

      waiting list
         
>     b. bump OpenRC and push it into Gentoo Prefix tree

      waiting list

Regarding the schedule restriction, I will report on a daily basis for
the next week.

tomorrow, I will,

      1. finish the documentation on http://wiki.debian.org/OpenRC
      1b. consult rleigh@debian and aron@debian for how to do the things
          in the wiki page with deb helper scripts when packaging.
      2. ping Prefix team for the official adoption of openrc-prefix.

Regards,
Benda

Re: [gentoo-soc] report 7.24-8.7: improving OpenRC

[Luca Barbato]

On 8/7/12 6:53 AM, heroxbd@gmail.com wrote:
> Dear Guys and Gals,
>
> heroxbd@gmail.com writes:
>
>> After the mid term evaluation, this project shifts its emphasis from
>> Prefix support to improving OpenRC (borrowing ideas from brother
>> systems)
>>
>
> During the last two weeks, the following are finished:
>
>>       1. use OpenRC to boot a Debian system
>
>         DONE
>
>>       2. find a way for OpenRC to use debian LSB init-scripts
>>          OR, find a way to convert LSB init-scripts to OpenRC scripts
>
>         DONE, it is the "lsb.pl" script.
>
>         The process is documented at http://wiki.debian.org/OpenRC
>
>>       3. Patch OpenRC build system to respect EPREFIX (yes, take this by myself)
>
>         I reviewed my old patch at bug 415899, and it seems to be able to
>         serve as a base for the prefix integration.

Great =)


> bonus:
>
>     ccxCZ from #openrc made a GLEP draft
>
>          http://wpr.cz/ccx/wobsite/article/openrc-supervisor.html

That's interesting

>     The interesting point to me is to make openrc running closely
>     with daemontools and runit for extended features.

>     In this project proposal, modern extensions (a timer, a oom-killer, a
>     daemon watcher) were discussed. To make openrc friendly talk to other
>     tools (cron, incron, runit, etc.) to achieve these extensions are
>     closest to my heart.

=) I'm looking forward to see some of those implemented.

lu

Re: [gentoo-soc] report 8.8: improving OpenRC

[heroxbd]

Dear Guys and Gals,

Luca Barbato <lu_zero@gentoo.org> writes:

> On 8/7/12 6:53 AM, heroxbd@gmail.com wrote:
>>
>>> After the mid term evaluation, this project shifts its emphasis from
>>> Prefix support to improving OpenRC (borrowing ideas from brother
>>> systems)
>>>

>>         The process is documented at http://wiki.debian.org/OpenRC

This wiki page is finished, and passed a first round of critisism
from #debian-devel. We are expecting it more ;) 

>>>       3. Patch OpenRC build system to respect EPREFIX (yes, take this by myself)
>>
>>         I reviewed my old patch at bug 415899, and it seems to be able to
>>         serve as a base for the prefix integration.

If this will not be included in a timely manner (OpenRC herd is loaded
with tons of bugs), I'll continue improve on my overlay.

>> bonus:
>>
>>     ccxCZ from #openrc made a GLEP draft
>>
>>          http://wpr.cz/ccx/wobsite/article/openrc-supervisor.html
>>     The interesting point to me is to make openrc running closely
>>     with daemontools and runit for extended features.
>>     In this project proposal, modern extensions (a timer, a oom-killer, a
>>     daemon watcher) were discussed. To make openrc friendly talk to other
>>     tools (cron, incron, runit, etc.) to achieve these extensions are
>>     closest to my heart.
>
> =) I'm looking forward to see some of those implemented.

runit and deamontools and foreground things look really cool.

bonus things finished on 8.8:

  tested out runit: it is a good piece of work. I began to doubt why
    systemd would reinvent the wheel for a "built-in" supervisor.

Plans for 8.9

  1. foreground some process (ssh, tinc, nginx and squid) and train openrc to
    run them by runit.  
  2. Begin to package OpenRC with debian new maintainer's guide.
  3. portage-prefix, follow the discussion result with grobian and
    lu_zero: implement a mechanism to export EPREFIX from within runscript.sh
-- 
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

Re: [gentoo-soc] report 8.8: improving OpenRC

[Luca Barbato]

On 08/09/2012 01:24 AM, heroxbd@gmail.com wrote:
> Dear Guys and Gals,
> 
> Luca Barbato <lu_zero@gentoo.org> writes:
> 
>> On 8/7/12 6:53 AM, heroxbd@gmail.com wrote:
>>>
>>>> After the mid term evaluation, this project shifts its emphasis from
>>>> Prefix support to improving OpenRC (borrowing ideas from brother
>>>> systems)
>>>>
> 
>>>         The process is documented at http://wiki.debian.org/OpenRC
> 
> This wiki page is finished, and passed a first round of critisism
> from #debian-devel. We are expecting it more ;) 
> 
>>>>       3. Patch OpenRC build system to respect EPREFIX (yes, take this by myself)
>>>
>>>         I reviewed my old patch at bug 415899, and it seems to be able to
>>>         serve as a base for the prefix integration.
> 
> If this will not be included in a timely manner (OpenRC herd is loaded
> with tons of bugs), I'll continue improve on my overlay.
> 
>>> bonus:
>>>
>>>     ccxCZ from #openrc made a GLEP draft
>>>
>>>          http://wpr.cz/ccx/wobsite/article/openrc-supervisor.html
>>>     The interesting point to me is to make openrc running closely
>>>     with daemontools and runit for extended features.
>>>     In this project proposal, modern extensions (a timer, a oom-killer, a
>>>     daemon watcher) were discussed. To make openrc friendly talk to other
>>>     tools (cron, incron, runit, etc.) to achieve these extensions are
>>>     closest to my heart.
>>
>> =) I'm looking forward to see some of those implemented.
> 
> runit and deamontools and foreground things look really cool.
> 
> bonus things finished on 8.8:
> 
>   tested out runit: it is a good piece of work. I began to doubt why
>     systemd would reinvent the wheel for a "built-in" supervisor.

keeping all the eggs in a single basket is a problem IMHO.

> Plans for 8.9
> 
>   1. foreground some process (ssh, tinc, nginx and squid) and train openrc to
>     run them by runit.

Sounds good

>   2. Begin to package OpenRC with debian new maintainer's guide.

I hope that will make more people happy, we definitely want more audience

>   3. portage-prefix, follow the discussion result with grobian and
>     lu_zero: implement a mechanism to export EPREFIX from within runscript.sh

Good!

Looking forward to see the results =)

lu

[gentoo-soc] report 8.9: improving OpenRC

[heroxbd]

Luca Barbato <lu_zero@gentoo.org> writes:

> On 08/09/2012 01:24 AM, heroxbd@gmail.com wrote:
>>> On 8/7/12 6:53 AM, heroxbd@gmail.com wrote:
>> Plans for 8.9
>> 
>>   1. foreground some process (ssh, tinc, nginx and squid) and train openrc to
>>     run them by runit.
>
> Sounds good

DONE, just foregrounded dropbear, and others is straightforward.

the repo is at http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git

branch runit. Got feedback from bonsaikitten and ccxCZ on #openrc.

supervising can really be done under runit, in a smooth way.

(I'll use this openrc + runit on my home NAS to monitor ssh, mysql, nginx
and squid.)

>>   2. Begin to package OpenRC with debian new maintainer's guide.
>
> I hope that will make more people happy, we definitely want more audience

started, slower than I thought. hopefully today first draft can come out.

>>   3. portage-prefix, follow the discussion result with grobian and
>>     lu_zero: implement a mechanism to export EPREFIX from within runscript.sh
>
> Good!

pending for deb packaging, todo for today.

-- 
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

Re: [gentoo-soc] report 8.9: improving OpenRC

[Luca Barbato]

On 08/10/2012 04:56 AM, heroxbd@gmail.com wrote:
> Luca Barbato <lu_zero@gentoo.org> writes:
> 
>> On 08/09/2012 01:24 AM, heroxbd@gmail.com wrote:
>>>> On 8/7/12 6:53 AM, heroxbd@gmail.com wrote:
>>> Plans for 8.9
>>>
>>>   1. foreground some process (ssh, tinc, nginx and squid) and train openrc to
>>>     run them by runit.
>>
>> Sounds good
> 
> DONE, just foregrounded dropbear, and others is straightforward.
> 
> the repo is at http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git
> branch runit. Got feedback from bonsaikitten and ccxCZ on #openrc.

looks interesting, in the long run might be nice to figure out how hard
would be have startstopdaemon learn runit tricks.

Later we should fix the hardwired paths probably.

> supervising can really be done under runit, in a smooth way.
> 
> (I'll use this openrc + runit on my home NAS to monitor ssh, mysql, nginx
> and squid.)

That's good to heard =)

>>>   2. Begin to package OpenRC with debian new maintainer's guide.
>>
>> I hope that will make more people happy, we definitely want more audience
> 
> started, slower than I thought. hopefully today first draft can come out.

Great!

[gentoo-soc] report 8.10: improving OpenRC

[heroxbd]

Luca Barbato <lu_zero@gentoo.org> writes:

>> DONE, just foregrounded dropbear, and others is straightforward.
>> 
>> the repo is at http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git
>> branch runit. Got feedback from bonsaikitten and ccxCZ on #openrc.
>
> looks interesting, in the long run might be nice to figure out how hard
> would be have startstopdaemon learn runit tricks.

Hmm, I don't think start-stop-daemon will. Because runit forks services
foreground while start-stop-daemon start backgrounded ones.

some reference: http://mywiki.wooledge.org/ProcessManagement

> Later we should fix the hardwired paths probably.

What kind of hardwired paths? /var/run/runit/xxx ?

>> supervising can really be done under runit, in a smooth way.
>> 
>> (I'll use this openrc + runit on my home NAS to monitor ssh, mysql, nginx
>> and squid.)
>
> That's good to heard =)

:)

>>> I hope that will make more people happy, we definitely want more audience
>> 
>> started, slower than I thought. hopefully today first draft can come out.
>
> Great!

a debian ITP bug here

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684396 waiting for
rleigh to review my package.

Today's plan,

1. EPREFIX export from runscript.sh
2. test the EPREFIX and update http://wiki.gentoo.org/wiki/OpenRC/Prefix
   run runit supervised services on my NAS
3. write a similar helper as lsb.pl for OpenRC to let it understand
   systemd unit.
-- 
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

[gentoo-soc] report 8.11: improving OpenRC

[heroxbd]

heroxbd@gmail.com writes:

> Today's plan,
>
> 1. EPREFIX export from runscript.sh

DONE

> 2. test the EPREFIX and update http://wiki.gentoo.org/wiki/OpenRC/Prefix
>    run runit supervised services on my NAS

DONE

http://www.awa.tohoku.ac.jp/~benda/projects/runit.html

> 3. write a similar helper as lsb.pl for OpenRC to let it understand
>    systemd unit.

Not yet, roll into today's plan.

I will install a OpenSUSE first for trying out native systemd. Then
write a tool to parse its unit files.


another plan for today

install newest ubuntu to try out upstart natively. Make a draft
event driven system on my laptop(debian) by newly packaged OpenRC with
incron/inotify extension.

The event is like this:

Trigger: pluggin iPhone to my laptop

a. open up iproxy to redirect sshd inside iPhone out
b. ssh into iPhone and make a socks proxy
b1. auto tune tinc configure file
c. fire up proxychain to start tinc vpn through the socks proxy

Finally: I have internet access through 3G network. Gateway is another
node in my vpn.

Because my phone can be plugged in anytime, dependency itself is not
enough. I will need incron/inotify to drive OpenRC fire up a.b.c. step
timely.

Re: [gentoo-soc] report 8.11: improving OpenRC

[Luca Barbato]

On 8/12/12 1:50 AM, heroxbd@gmail.com wrote:
> heroxbd@gmail.com writes:
>
>> Today's plan,
>>
>> 1. EPREFIX export from runscript.sh
>
> DONE
>
>> 2. test the EPREFIX and update http://wiki.gentoo.org/wiki/OpenRC/Prefix
>>     run runit supervised services on my NAS
>
> DONE
>
> http://www.awa.tohoku.ac.jp/~benda/projects/runit.html

Might be moved to wiki

>> 3. write a similar helper as lsb.pl for OpenRC to let it understand
>>     systemd unit.
>
> Not yet, roll into today's plan.
>
> I will install a OpenSUSE first for trying out native systemd. Then
> write a tool to parse its unit files.

Ok. Please document it.

> another plan for today
>
> install newest ubuntu to try out upstart natively. Make a draft
> event driven system on my laptop(debian) by newly packaged OpenRC with
> incron/inotify extension.
>
> The event is like this:
>
> Trigger: pluggin iPhone to my laptop
>
> a. open up iproxy to redirect sshd inside iPhone out
> b. ssh into iPhone and make a socks proxy
> b1. auto tune tinc configure file
> c. fire up proxychain to start tinc vpn through the socks proxy
>
> Finally: I have internet access through 3G network. Gateway is another
> node in my vpn.
>
> Because my phone can be plugged in anytime, dependency itself is not
> enough. I will need incron/inotify to drive OpenRC fire up a.b.c. step
> timely.

Seems an interesting experiment, go for it!

lu

[gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Dear guys and gals,

For the soft pencil down, I'd like to aggregate a report for the overall
status for my project.

The goals have been achieved:

1. Prefix support of OpenRC

   http://wiki.gentoo.org/wiki/OpenRC/Prefix

   git repo:
   http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/prefix

   for official inclusion

   a. baselayout-prefix, in tree but masked.
   b. portage, sent git pull request, grobian is reviewing it.
   c. openrc, sent git pull request, WilliamH is reviewing it.

2. A evaluation of existing init systems

   This includes solaris SMF, Mac OSX launchd, Fedora systemd, OpenSUSE
   systemd/LSB combo, Ubuntu upstart and Debian LSB/insserv combo.

3. service supervisor

   achieved via runit, doc at
   http://www.awa.tohoku.ac.jp/~benda/projects/runit.html

   will move to wiki after runit feature is pulled in my WilliamH.

   git repo:
   http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/runit

   This is a cool feature, while it have changes to default behavior of
   OpenRC initscripts. Therefore documenting it comprehensively is
   necessary. A GLEP will be composed to serve as an RFC for the Gentoo
   community, official explanation and general guideline to simplify
   present (already simplified compared to LSB conterparts) init scripts
   shipped in ebuilds.

   btw, s6 (http://www.skarnet.org/software/s6/why.html) is a better
   alternative to runit.

4. OOM killer/periodical command

   Not implemented here, tested with monit (http://mmonit.com/monit/)
   and fcron (http://fcron.free.fr/). No integration or modification is
   need in OpenRC, unlike runit. At most, we can introduce a
   IN_PERIODICAL envvar, as how IN_HOTPLUG works.

5. event driven actions

   Same as hotplug feature already in OpenRC, triggered by udev, just
   lack of documentation. If used with runlevel stacking (another under
   documented feature of OpenRC), it can cover all the use cases I could
   imagine.

   That's enough. upstart features a udev-upstart-bridge after all. It
   is a cool feature and we can adopt it with a combo of tools and
   achieve sane default behavior by packaging with, e.g., our beloved
   ebuild. The revolutionary event based init design is more of
   propaganding, IMHO.

6. OpenRC introduction to debian
   
   documented at
   http://wiki.debian.org/OpenRC

   git repo:
   http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/debian

   ITP bug:
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684396

   on going debian packaging collaboration
   http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git;a=shortlog;h=refs/heads/debian

   I will work closely with the debian team. Hope debian can stand
   against the gigantic storm of systemd.

The next time consuming task is to push my contribution to upstreams,
very likely improving it from the feedbacks along the way. I need to
stay tuned and work together with people, including Prefix herd, OpenRC
herd and Debian init system developers.

Thanks to this project, I find init system an interesting topic, with
all the advertisements, politics, debates and cultural collisions
mixed. Making a reliable, minimalistic, elegant, fast and extendable
init system with dependency handling, optional event triggering,
optional service supervising, etc. is definitely not a simple task.

The ideas of OpenRC and the way new features gets added resonates with
my own value of how computer should work. I will continue to work on it
after soc.

I'd like to thank my mentor Luca for introducing me to this exciting
realm, for his support and advise all along. I'd like to thank Patrick,
Fabian, William, Roger for the discussions and support. My thanks also
go to people in mailing lists and IRC channels (esp. cxxCZ and ryao) who
commented for providing nice ideas/criticism and sharping my mind.

Finally replies to my last plans on 8.12,

Luca Barbato <lu_zero@gentoo.org> writes:

>> I will install a OpenSUSE first for trying out native systemd. Then
>> write a tool to parse its unit files.
>
> Ok. Please document it.

Tried systemd on OpenSUSE, disappointed by its ini unit files. At
present don't see the necessity for a parser.

>> another plan for today
>>
>> install newest ubuntu to try out upstart natively. Make a draft
>> event driven system on my laptop(debian) by newly packaged OpenRC with
>> incron/inotify extension.

incron not needed, it is for filesystem after all. udev + hotplug@OpenRC
do the job.

>> The event is like this:
>>
>> Trigger: pluggin iPhone to my laptop
>>
>> a. open up iproxy to redirect sshd inside iPhone out
>> b. ssh into iPhone and make a socks proxy
>> b1. auto tune tinc configure file
>> c. fire up proxychain to start tinc vpn through the socks proxy
>>
>> Finally: I have internet access through 3G network. Gateway is another
>> node in my vpn.
>>
>> Because my phone can be plugged in anytime, dependency itself is not
>> enough. I will need incron/inotify to drive OpenRC fire up a.b.c. step
>> timely.
>
> Seems an interesting experiment, go for it!

Succeeded, thinking of documenting it in wiki.

Cheers,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/15/12 5:14 PM, heroxbd@gmail.com wrote:
> Dear guys and gals,
>
> For the soft pencil down, I'd like to aggregate a report for the overall
> status for my project.
>
> The goals have been achieved:
>
> 1. Prefix support of OpenRC

And it looks quite nice

> 2. A evaluation of existing init systems
>
>     This includes solaris SMF, Mac OSX launchd, Fedora systemd, OpenSUSE
>     systemd/LSB combo, Ubuntu upstart and Debian LSB/insserv combo.

Were is it? I'd like to read it =)

> 3. service supervisor
>
>     achieved via runit, doc at
>     http://www.awa.tohoku.ac.jp/~benda/projects/runit.html
>
>     will move to wiki after runit feature is pulled in my WilliamH.
>
>     git repo:
>     http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/runit
>
>     This is a cool feature, while it have changes to default behavior of
>     OpenRC initscripts. Therefore documenting it comprehensively is
>     necessary. A GLEP will be composed to serve as an RFC for the Gentoo
>     community, official explanation and general guideline to simplify
>     present (already simplified compared to LSB conterparts) init scripts
>     shipped in ebuilds.
>
>     btw, s6 (http://www.skarnet.org/software/s6/why.html) is a better
>     alternative to runit.

Seems interesting indeed, would you consider working on it later?

> 4. OOM killer/periodical command
>
>     Not implemented here, tested with monit (http://mmonit.com/monit/)
>     and fcron (http://fcron.free.fr/). No integration or modification is
>     need in OpenRC, unlike runit. At most, we can introduce a
>     IN_PERIODICAL envvar, as how IN_HOTPLUG works.

I'd like to have more information here.

> 5. event driven actions
>
>     Same as hotplug feature already in OpenRC, triggered by udev, just
>     lack of documentation. If used with runlevel stacking (another under
>     documented feature of OpenRC), it can cover all the use cases I could
>     imagine.
>
>     That's enough. upstart features a udev-upstart-bridge after all. It
>     is a cool feature and we can adopt it with a combo of tools and
>     achieve sane default behavior by packaging with, e.g., our beloved
>     ebuild. The revolutionary event based init design is more of
>     propaganding, IMHO.

I'd like to see a wiki page or some more on that =)

> 6. OpenRC introduction to debian
>
>     documented at
>     http://wiki.debian.org/OpenRC
>
>     git repo:
>     http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/debian
>
>     ITP bug:
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684396
>
>     on going debian packaging collaboration
>     http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git;a=shortlog;h=refs/heads/debian
>
>     I will work closely with the debian team. Hope debian can stand
>     against the gigantic storm of systemd.

Looks great so far and coordination is great

> The next time consuming task is to push my contribution to upstreams,
> very likely improving it from the feedbacks along the way. I need to
> stay tuned and work together with people, including Prefix herd, OpenRC
> herd and Debian init system developers.
>
> Thanks to this project, I find init system an interesting topic, with
> all the advertisements, politics, debates and cultural collisions
> mixed. Making a reliable, minimalistic, elegant, fast and extendable
> init system with dependency handling, optional event triggering,
> optional service supervising, etc. is definitely not a simple task.
>
> The ideas of OpenRC and the way new features gets added resonates with
> my own value of how computer should work. I will continue to work on it
> after soc.
>
> I'd like to thank my mentor Luca for introducing me to this exciting
> realm, for his support and advise all along. I'd like to thank Patrick,
> Fabian, William, Roger for the discussions and support. My thanks also
> go to people in mailing lists and IRC channels (esp. cxxCZ and ryao) who
> commented for providing nice ideas/criticism and sharping my mind.
>
> Finally replies to my last plans on 8.12,
>
> Luca Barbato <lu_zero@gentoo.org> writes:
>
>>> I will install a OpenSUSE first for trying out native systemd. Then
>>> write a tool to parse its unit files.
>>
>> Ok. Please document it.
>
> Tried systemd on OpenSUSE, disappointed by its ini unit files. At
> present don't see the necessity for a parser.

The unit file feature is something touted a lot, why you found it 
disappointing?

>>> another plan for today
>>>
>>> install newest ubuntu to try out upstart natively. Make a draft
>>> event driven system on my laptop(debian) by newly packaged OpenRC with
>>> incron/inotify extension.
>
> incron not needed, it is for filesystem after all. udev + hotplug@OpenRC
> do the job.

More should be said on that =)

> Succeeded, thinking of documenting it in wiki.

Please do

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Dear Luca,

Luca Barbato <lu_zero@gentoo.org> writes:

> On 8/15/12 5:14 PM, heroxbd@gmail.com wrote:
>> 1. Prefix support of OpenRC
>
> And it looks quite nice

Thanks :)

>> 2. A evaluation of existing init systems
>>
>>     This includes solaris SMF, Mac OSX launchd, Fedora systemd, OpenSUSE
>>     systemd/LSB combo, Ubuntu upstart and Debian LSB/insserv combo.
>
> Were is it? I'd like to read it =)

  http://wiki.gentoo.org/wiki/Comparison_of_init_systems

And the "counter systemd" talk page,

  http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

>> 3. service supervisor
>>
>>     achieved via runit, doc at
>>     http://www.awa.tohoku.ac.jp/~benda/projects/runit.html
>>
>>     will move to wiki after runit feature is pulled in my WilliamH.
>>
>>     git repo:
>>     http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/runit
>>
>>     This is a cool feature, while it have changes to default behavior of
>>     OpenRC initscripts. Therefore documenting it comprehensively is
>>     necessary. A GLEP will be composed to serve as an RFC for the Gentoo
>>     community, official explanation and general guideline to simplify
>>     present (already simplified compared to LSB conterparts) init scripts
>>     shipped in ebuilds.
>>
>>     btw, s6 (http://www.skarnet.org/software/s6/why.html) is a better
>>     alternative to runit.
>
> Seems interesting indeed, would you consider working on it later?

Yes, the plan is,

  a. finish the GLEP, raise to gentoo-dev ml, get it accepted.
     with the reference implementation
  b. refine the runit branch according to the accepted GLEP, push into
     OpenRC master and make an OpenRC release. The build system should
     make this feature optional and tunable with USE flags in openrc ebuild.
  c. bug ebuild maintainers for possible polishing of their init
     scripts, referring the GLEP.

>> 4. OOM killer/periodical command
>>
>>     Not implemented here, tested with monit (http://mmonit.com/monit/)
>>     and fcron (http://fcron.free.fr/). No integration or modification is
>>     need in OpenRC, unlike runit. At most, we can introduce a
>>     IN_PERIODICAL envvar, as how IN_HOTPLUG works.
>
> I'd like to have more information here.

Got it, preparing...

>> 5. event driven actions
>>
>>     Same as hotplug feature already in OpenRC, triggered by udev, just
>>     lack of documentation. If used with runlevel stacking (another under
>>     documented feature of OpenRC), it can cover all the use cases I could
>>     imagine.
>>
>>     That's enough. upstart features a udev-upstart-bridge after all. It
>>     is a cool feature and we can adopt it with a combo of tools and
>>     achieve sane default behavior by packaging with, e.g., our beloved
>>     ebuild. The revolutionary event based init design is more of
>>     propaganding, IMHO.
>
> I'd like to see a wiki page or some more on that =)

Got it, underway...

>> 6. OpenRC introduction to debian
>>
>>     documented at
>>     http://wiki.debian.org/OpenRC
>>
>>     git repo:
>>     http://git.heroxbd.z.tuna.tsinghua.edu.cn/openrc.git?p=openrc.git;a=shortlog;h=refs/heads/debian
>>
>>     ITP bug:
>>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684396
>>
>>     on going debian packaging collaboration
>>     http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git;a=shortlog;h=refs/heads/debian
>>
>>     I will work closely with the debian team. Hope debian can stand
>>     against the gigantic storm of systemd.
>
> Looks great so far and coordination is great

Thanks :)

>> Tried systemd on OpenSUSE, disappointed by its ini unit files. At
>> present don't see the necessity for a parser.
>
> The unit file feature is something touted a lot, why you found it
> disappointing?

It's just plain ini, no black magic to prepare my coffee :D

BTW, any reference pointer to classical "touted" articles?

>>>> another plan for today
>>>>
>>>> install newest ubuntu to try out upstart natively. Make a draft
>>>> event driven system on my laptop(debian) by newly packaged OpenRC with
>>>> incron/inotify extension.
>>
>> incron not needed, it is for filesystem after all. udev + hotplug@OpenRC
>> do the job.
>
> More should be said on that =)

Ok, same as event driven topic as above. underway...

>> Succeeded, thinking of documenting it in wiki.

Got it.

Yours,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Thu, Aug 16, 2012 at 4:38 AM,  <heroxbd@gmail.com> wrote:
> Luca Barbato <lu_zero@gentoo.org> writes:
>> On 8/15/12 5:14 PM, heroxbd@gmail.com wrote:
>>> 2. A evaluation of existing init systems
>>>
>>>     This includes solaris SMF, Mac OSX launchd, Fedora systemd, OpenSUSE
>>>     systemd/LSB combo, Ubuntu upstart and Debian LSB/insserv combo.
>>
>> Were is it? I'd like to read it =)
>
>   http://wiki.gentoo.org/wiki/Comparison_of_init_systems
>
> And the "counter systemd" talk page,
>
>   http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

Just a comment on this - OpenRC is listed as having parallel startup
support, but I believe that this configuration is actually considered
unsupported on Gentoo even if the code is there.  I believe even the
configuration options were removed from the config file to discourage
their user (though if somebody happens to know about the option they
can add it in and it will work.

It is probably worth noting that this is an experimental feature in a
comparison.

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Hi, Rich,

Rich Freeman <rich0@gentoo.org> writes:

> On Thu, Aug 16, 2012 at 4:38 AM,  <heroxbd@gmail.com> wrote:
>> Luca Barbato <lu_zero@gentoo.org> writes:
>>> Were is it? I'd like to read it =)
>>
>>   http://wiki.gentoo.org/wiki/Comparison_of_init_systems
>>
>> And the "counter systemd" talk page,
>>
>>   http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
>
> Just a comment on this - OpenRC is listed as having parallel startup
> support, but I believe that this configuration is actually considered
> unsupported on Gentoo even if the code is there.  I believe even the
> configuration options were removed from the config file to discourage
> their user (though if somebody happens to know about the option they
> can add it in and it will work.
>
> It is probably worth noting that this is an experimental feature in a
> comparison.

Thanks a lot for the comment. I agree. Nobody cares about the tiny (not
tested) booting up time gain with rc_parallel.

At present it is documented in rc.conf

,----
| # Set to "YES" if you want the rc system to try and start services
| # in parallel for a slight speed improvement. When running in parallel
| # we prefix the service output with its name as the output will get
| # jumbled up.
| # WARNING: whilst we have improved parallel, it can still potentially
| # lock the boot process. Don't file bugs about this unless you can supply
| # patches that fix it without breaking other things!
| # rc_parallel="YES"
`----

I think it was "Parallel service startup - OpenRC - yes(buggy)" in wiki
before.

Cheers,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/17/12 7:39 AM, heroxbd@gmail.com wrote:
> Hi, Rich,
>
> Rich Freeman <rich0@gentoo.org> writes:
>
>> On Thu, Aug 16, 2012 at 4:38 AM,  <heroxbd@gmail.com> wrote:
>>> Luca Barbato <lu_zero@gentoo.org> writes:
>>>> Were is it? I'd like to read it =)
>>>
>>>    http://wiki.gentoo.org/wiki/Comparison_of_init_systems
>>>
>>> And the "counter systemd" talk page,
>>>
>>>    http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
>>
>> Just a comment on this - OpenRC is listed as having parallel startup
>> support, but I believe that this configuration is actually considered
>> unsupported on Gentoo even if the code is there.  I believe even the
>> configuration options were removed from the config file to discourage
>> their user (though if somebody happens to know about the option they
>> can add it in and it will work.
>>
>> It is probably worth noting that this is an experimental feature in a
>> comparison.
>
> Thanks a lot for the comment. I agree. Nobody cares about the tiny (not
> tested) booting up time gain with rc_parallel.

It can be not so tiny, surely busybox+openrc gives a better gain in many 
cases.

> I think it was "Parallel service startup - OpenRC - yes(buggy)" in wiki
> before.

Keep it like this, help on making it non-buggy is welcome

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Fri, Aug 17, 2012 at 3:29 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 8/17/12 7:39 AM, heroxbd@gmail.com wrote:
>> Thanks a lot for the comment. I agree. Nobody cares about the tiny (not
>> tested) booting up time gain with rc_parallel.
>
> It can be not so tiny, surely busybox+openrc gives a better gain in many
> cases.
>

I suspect that it will depend greatly on what services you're running,
and what order they happen to start in, and what you care about.  In
theory slamming the kernel with a ton of processes will allow it to
manage its queues better with a fuller understanding of demand.
systemd can potentially short-cut this a bit further since it can
consider a dependency resolved if nothing more than a socket is
created, which is a clever trick (I have no idea how well it works out
in practice, though I have used a .socket service once and that worked
out fine (with the caveat that the first connection fails)).

Where I saw the bigger performance difference between openrc and
systemd was in shutdown.  Systemd shuts down REALLY fast, and I've
noticed it tends to actually kill ssh sessions rather than leaving
them unresponsive (plus ssh dies even faster so that makes it seem
subjectively faster - but the difference in full shutdown is still
real).  Obviously people don't care as much about shutdown
performance, but on a laptop (where supposedly event-driven inits
should shine) I know that waiting for a full shutdown before packing
up can be painful at least in the land of Windows.

Just food for thought - it seems odd that parallel startup should have
any issues at all, provided that service scripts don't terminate until
the service is functional and all dependencies are specified.  If
either of those aren't true then you'll have race conditions.

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Rich Freeman <rich0@gentoo.org> writes:

> On Fri, Aug 17, 2012 at 3:29 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>> It can be not so tiny, surely busybox+openrc gives a better gain in many
>> cases.
>>
>
> I suspect that it will depend greatly on what services you're running,
> and what order they happen to start in, and what you care about.  In
> theory slamming the kernel with a ton of processes will allow it to
> manage its queues better with a fuller understanding of demand.
> systemd can potentially short-cut this a bit further since it can
> consider a dependency resolved if nothing more than a socket is
> created, which is a clever trick (I have no idea how well it works out
> in practice, though I have used a .socket service once and that worked
> out fine (with the caveat that the first connection fails)).

Yeah, this is a brilliant idea.

A side question, what is the percentage of the dependencies that is
merely a socket?

> Where I saw the bigger performance difference between openrc and
> systemd was in shutdown.  Systemd shuts down REALLY fast, and I've
> noticed it tends to actually kill ssh sessions rather than leaving
> them unresponsive (plus ssh dies even faster so that makes it seem
> subjectively faster - but the difference in full shutdown is still
> real).  Obviously people don't care as much about shutdown
> performance, but on a laptop (where supposedly event-driven inits
> should shine) I know that waiting for a full shutdown before packing
> up can be painful at least in the land of Windows.

Yeah, that is a problem. We've got to learn from systemd here. Not sure
of the mechanism yet.

> Just food for thought - it seems odd that parallel startup should have
> any issues at all, provided that service scripts don't terminate until
> the service is functional and all dependencies are specified.  If
> either of those aren't true then you'll have race conditions.

OpenRC doesn't have protection against weak (in the sense of use /
order) circular dependencies. I guess that is the source of this
problem.

Cheers,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/20/12 5:04 AM, heroxbd@gmail.com wrote:
> Yeah, that is a problem. We've got to learn from systemd here. Not sure
> of the mechanism yet.

My system shuts down faster on linux than on mac...

Could we please measure it?

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On 20-08-2012 10:16:50 +0200, Luca Barbato wrote:
> On 8/20/12 5:04 AM, heroxbd@gmail.com wrote:
> > Yeah, that is a problem. We've got to learn from systemd here. Not sure
> > of the mechanism yet.
> 
> My system shuts down faster on linux than on mac...

not fair, IMO

you better compare it to FreeBSD


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/20/12 12:25 PM, Fabian Groffen wrote:
> On 20-08-2012 10:16:50 +0200, Luca Barbato wrote:
>> On 8/20/12 5:04 AM, heroxbd@gmail.com wrote:
>>> Yeah, that is a problem. We've got to learn from systemd here. Not sure
>>> of the mechanism yet.
>>
>> My system shuts down faster on linux than on mac...
>
> not fair, IMO

It is for me. I care about the overall reboot time since I switch back 
and forth osx and linux. OpenRC is way faster in both boot and shutdown.

People complaining openrc being slow must have a different setup and I'd 
like to see what could be fixed.

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On 20-08-2012 18:32:28 +0200, Luca Barbato wrote:
> On 8/20/12 12:25 PM, Fabian Groffen wrote:
> > On 20-08-2012 10:16:50 +0200, Luca Barbato wrote:
> >> On 8/20/12 5:04 AM, heroxbd@gmail.com wrote:
> >>> Yeah, that is a problem. We've got to learn from systemd here. Not sure
> >>> of the mechanism yet.
> >>
> >> My system shuts down faster on linux than on mac...
> >
> > not fair, IMO
> 
> It is for me. I care about the overall reboot time since I switch back 
> and forth osx and linux. OpenRC is way faster in both boot and shutdown.

Sorry, I was under the impression you were comparing OSX against a Linux
boot/shutdown.

> People complaining openrc being slow must have a different setup and I'd 
> like to see what could be fixed.

+1


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Mon, Aug 20, 2012 at 4:16 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 8/20/12 5:04 AM, heroxbd@gmail.com wrote:
>>
>> Yeah, that is a problem. We've got to learn from systemd here. Not sure
>> of the mechanism yet.
>
>
> My system shuts down faster on linux than on mac...
>
> Could we please measure it?

Seems like the best comparisons are between linux-based systems of
identical configuration.  Crossing OS boundaries might also be useful
but obviously you aren't going to be testing systemd that way.

Perhaps do a test with both a desktop-like and server-like
configuration (the latter having a LAMP-like set of services, perhaps
samba, postfix, etc - though in a serious production environment those
would be more isolated).

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/20/12 12:47 PM, Rich Freeman wrote:

> Seems like the best comparisons are between linux-based systems of
> identical configuration.  Crossing OS boundaries might also be useful
> but obviously you aren't going to be testing systemd that way.

I do not care about systemd at all. I care about fixing a problem in 
what I'm using. If openrc is really slow on reboot and boot I'd like to 
figure out why it isn't for me. (compared to the OS touted as the best 
for user experience.)

> Perhaps do a test with both a desktop-like and server-like
> configuration (the latter having a LAMP-like set of services, perhaps
> samba, postfix, etc - though in a serious production environment those
> would be more isolated).

A serious production environment nowadays has each of them running 
separately I guess.

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Mon, Aug 20, 2012 at 12:34 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 8/20/12 12:47 PM, Rich Freeman wrote:
>
>> Seems like the best comparisons are between linux-based systems of
>> identical configuration.  Crossing OS boundaries might also be useful
>> but obviously you aren't going to be testing systemd that way.
>
>
> I do not care about systemd at all. I care about fixing a problem in what
> I'm using. If openrc is really slow on reboot and boot I'd like to figure
> out why it isn't for me. (compared to the OS touted as the best for user
> experience.)

Well, if you're comparing OSX to Linux+OpenRC there are a LOT of
variables - one could be faster for any number of reasons.

If you compare systemd to OpenRC you can figure out what is possible on Linux.

Being as good as OSX is a non-starter for me.  If I thought Gentoo was
as good as OSX I wouldn't be using it...

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/20/12 8:12 PM, Rich Freeman wrote:
> Being as good as OSX is a non-starter for me.  If I thought Gentoo was
> as good as OSX I wouldn't be using it...

I use both, people complaining about linux being outdated or slow point 
to osx.

OSX might sucks for somebody else.

What is sure is that I'd like to know how many seconds to boot/shutdown 
what in the different sets would take.

Since you already had both, if you have a list of services and such 
probably we could try to see what happens.

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[EBo]

On Mon, 20 Aug 2012 12:04:26 +0900, heroxbd@gmail.com wrote:
> Rich Freeman <rich0@gentoo.org> writes:
>
>> On Fri, Aug 17, 2012 at 3:29 AM, Luca Barbato <lu_zero@gentoo.org> 
>> wrote:
>>> It can be not so tiny, surely busybox+openrc gives a better gain in 
>>> many
>>> cases.
>>>
>>
>> I suspect that it will depend greatly on what services you're 
>> running,
>> and what order they happen to start in, and what you care about.  In
>> theory slamming the kernel with a ton of processes will allow it to
>> manage its queues better with a fuller understanding of demand.
>> systemd can potentially short-cut this a bit further since it can
>> consider a dependency resolved if nothing more than a socket is
>> created, which is a clever trick (I have no idea how well it works 
>> out
>> in practice, though I have used a .socket service once and that 
>> worked
>> out fine (with the caveat that the first connection fails)).
>
> Yeah, this is a brilliant idea.

just as a side note, when I was doing performance latency testing (for 
industrial robotics applications) on real-time Linux kernels (RTAI, soft 
real-time preempt, and hard real-time preempt) I noticed that I got 
better latencies when when I loaded up the system with a LOT of 
processes and workload.  If you end up looking into the RT stuff, let me 
know off list and maybe I can send a link or six.

   EBo --

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Dear Luca,

heroxbd@gmail.com writes:

>>> 4. OOM killer/periodical command
>>>
>>>     Not implemented here, tested with monit (http://mmonit.com/monit/)
>>>     and fcron (http://fcron.free.fr/). No integration or modification is
>>>     need in OpenRC, unlike runit. At most, we can introduce a
>>>     IN_PERIODICAL envvar, as how IN_HOTPLUG works.
>>
>> I'd like to have more information here.
>
> Got it, preparing...

For monitoring against OOM http://wiki.gentoo.org/wiki/Monit

cron/at is too general to document, there is one at

  http://www.gentoo.org/doc/en/cron-guide.xml

upstart is designed to replace cron

  http://upstart.ubuntu.com/wiki/ReplaceCron

systemd recommends to replace cron

  http://freedesktop.org/wiki/Software/systemd/Optimizations

while OpenRC just work with it. For some fancy new feature to be used on
non-servers, like "run every 5 minutes after start up", fcron can be
used.
  
>>> 5. event driven actions
>>>
>>>     Same as hotplug feature already in OpenRC, triggered by udev, just
>>>     lack of documentation. If used with runlevel stacking (another under
>>>     documented feature of OpenRC), it can cover all the use cases I could
>>>     imagine.
>>>
>>>     That's enough. upstart features a udev-upstart-bridge after all. It
>>>     is a cool feature and we can adopt it with a combo of tools and
>>>     achieve sane default behavior by packaging with, e.g., our beloved
>>>     ebuild. The revolutionary event based init design is more of
>>>     propaganding, IMHO.
>>
>> I'd like to see a wiki page or some more on that =)
>
> Got it, underway...

A stub page is below. Still thinking of how to present it. May be we can
just load it with examples which covers all the cases upstart being
proud of.

   http://wiki.gentoo.org/wiki/OpenRC/Event_Driven


>>> Succeeded, thinking of documenting it in wiki.
>
> Got it.

Together with stacked runlevel.

  http://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel

Cheers,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/21/12 4:07 PM, heroxbd@gmail.com wrote:
> For monitoring against OOM http://wiki.gentoo.org/wiki/Monit

So monit could be integrated in openrc easily ?

> cron/at is too general to document, there is one at
>
>    http://www.gentoo.org/doc/en/cron-guide.xml

Agreed.

> upstart is designed to replace cron
>
>    http://upstart.ubuntu.com/wiki/ReplaceCron
>
> systemd recommends to replace cron
>
>    http://freedesktop.org/wiki/Software/systemd/Optimizations
>
> while OpenRC just work with it. For some fancy new feature to be used on
> non-servers, like "run every 5 minutes after start up", fcron can be
> used.

Not sure exactly what should we add here.

>>>> 5. event driven actions
>>>>
>>>>      Same as hotplug feature already in OpenRC, triggered by udev, just
>>>>      lack of documentation. If used with runlevel stacking (another under
>>>>      documented feature of OpenRC), it can cover all the use cases I could
>>>>      imagine.
>>>>
>>>>      That's enough. upstart features a udev-upstart-bridge after all. It
>>>>      is a cool feature and we can adopt it with a combo of tools and
>>>>      achieve sane default behavior by packaging with, e.g., our beloved
>>>>      ebuild. The revolutionary event based init design is more of
>>>>      propaganding, IMHO.
>>>
>>> I'd like to see a wiki page or some more on that =)
>>
>> Got it, underway...
>
> A stub page is below. Still thinking of how to present it. May be we can
> just load it with examples which covers all the cases upstart being
> proud of.
>
>     http://wiki.gentoo.org/wiki/OpenRC/Event_Driven

Yes, might be a good approach.

>    http://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel

Interesting example

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[heroxbd]

Dear Luca,

Luca Barbato <lu_zero@gentoo.org> writes:

> On 8/21/12 4:07 PM, heroxbd@gmail.com wrote:
>> For monitoring against OOM http://wiki.gentoo.org/wiki/Monit
>
> So monit could be integrated in openrc easily ?

In the way of runit, yes. 

>> cron/at is too general to document, there is one at
>>
>>    http://www.gentoo.org/doc/en/cron-guide.xml
>
> Agreed.

:)

>> upstart is designed to replace cron
>>
>>    http://upstart.ubuntu.com/wiki/ReplaceCron
>>
>> systemd recommends to replace cron
>>
>>    http://freedesktop.org/wiki/Software/systemd/Optimizations
>>
>> while OpenRC just work with it. For some fancy new feature to be used on
>> non-servers, like "run every 5 minutes after start up", fcron can be
>> used.
>
> Not sure exactly what should we add here.

The feature of cron-like feature in systemd is limited, while in upstart
they just replace cron for "cleanness" and integration. I don't think
there is a special task OpenRC/cron can't do.

>> A stub page is below. Still thinking of how to present it. May be we can
>> just load it with examples which covers all the cases upstart being
>> proud of.
>>
>>     http://wiki.gentoo.org/wiki/OpenRC/Event_Driven
>
> Yes, might be a good approach.

New examples welcome ;) How would gentoo deal with udev is still
unclear, while I think we can document the present udev features. udev
merge with systemd is not a big threat, is it?

>>    http://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel
>
> Interesting example

Thanks, it rocks. Now I tend to deploy OpenRC to all my debian boxes
gradually for it's flexibility.

Yours,
Benda

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/22/12 4:04 AM, heroxbd@gmail.com wrote:
> Dear Luca,
>
> Luca Barbato <lu_zero@gentoo.org> writes:
>
>> On 8/21/12 4:07 PM, heroxbd@gmail.com wrote:
>>> For monitoring against OOM http://wiki.gentoo.org/wiki/Monit
>>
>> So monit could be integrated in openrc easily ?
>
> In the way of runit, yes.
>
>>> cron/at is too general to document, there is one at
>>>
>>>     http://www.gentoo.org/doc/en/cron-guide.xml
>>
>> Agreed.
>
> :)
>
>>> upstart is designed to replace cron
>>>
>>>     http://upstart.ubuntu.com/wiki/ReplaceCron
>>>
>>> systemd recommends to replace cron
>>>
>>>     http://freedesktop.org/wiki/Software/systemd/Optimizations
>>>
>>> while OpenRC just work with it. For some fancy new feature to be used on
>>> non-servers, like "run every 5 minutes after start up", fcron can be
>>> used.
>>
>> Not sure exactly what should we add here.
>
> The feature of cron-like feature in systemd is limited, while in upstart
> they just replace cron for "cleanness" and integration. I don't think
> there is a special task OpenRC/cron can't do.
>
>>> A stub page is below. Still thinking of how to present it. May be we can
>>> just load it with examples which covers all the cases upstart being
>>> proud of.
>>>
>>>      http://wiki.gentoo.org/wiki/OpenRC/Event_Driven
>>
>> Yes, might be a good approach.
>
> New examples welcome ;) How would gentoo deal with udev is still
> unclear, while I think we can document the present udev features. udev
> merge with systemd is not a big threat, is it?

Replacing udev-systemd with udev is probably yet another huge project, 
hopefully somebody would help.

meanwhile we have some people using mdev to their satisfaction.

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Patrick Lauer]

On 08/22/12 15:35, Luca Barbato wrote:
> On 8/22/12 4:04 AM, heroxbd@gmail.com wrote:
>> Dear Luca,
>>
>> Luca Barbato <lu_zero@gentoo.org> writes:
>>
>>> On 8/21/12 4:07 PM, heroxbd@gmail.com wrote:
>>>> For monitoring against OOM http://wiki.gentoo.org/wiki/Monit
>>>
>>> So monit could be integrated in openrc easily ?
>>
>> In the way of runit, yes.
>>
>>>> cron/at is too general to document, there is one at
>>>>
>>>>     http://www.gentoo.org/doc/en/cron-guide.xml
>>>
>>> Agreed.
>>
>> :)
>>
>>>> upstart is designed to replace cron
>>>>
>>>>     http://upstart.ubuntu.com/wiki/ReplaceCron
>>>>
>>>> systemd recommends to replace cron
>>>>
>>>>     http://freedesktop.org/wiki/Software/systemd/Optimizations
>>>>
>>>> while OpenRC just work with it. For some fancy new feature to be
>>>> used on
>>>> non-servers, like "run every 5 minutes after start up", fcron can be
>>>> used.
>>>
>>> Not sure exactly what should we add here.
>>
>> The feature of cron-like feature in systemd is limited, while in upstart
>> they just replace cron for "cleanness" and integration. I don't think
>> there is a special task OpenRC/cron can't do.
>>
>>>> A stub page is below. Still thinking of how to present it. May be
>>>> we can
>>>> just load it with examples which covers all the cases upstart being
>>>> proud of.
>>>>
>>>>      http://wiki.gentoo.org/wiki/OpenRC/Event_Driven
>>>
>>> Yes, might be a good approach.
>>
>> New examples welcome ;) How would gentoo deal with udev is still
>> unclear, while I think we can document the present udev features. udev
>> merge with systemd is not a big threat, is it?
>
> Replacing udev-systemd with udev is probably yet another huge project,
> hopefully somebody would help.
We already have patches to fix things thanks to Polynomial-C aka. Lars
Wendler. See:
http://dev.gentoo.org/~polynomial-c/udev/

Now we only need to motivate our maintainers to use the openrc useflag
to fix udev properly.
>
> meanwhile we have some people using mdev to their satisfaction.
>
> lu
>

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Mon, Aug 27, 2012 at 6:46 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> We already have patches to fix things thanks to Polynomial-C aka. Lars
> Wendler. See:
> http://dev.gentoo.org/~polynomial-c/udev/
>
> Now we only need to motivate our maintainers to use the openrc useflag
> to fix udev properly.

Hmm, only a 53K patch.  Why not just fork the thing?  Heaven forbid
maybe that might actually get everybody to agree on virtualizing it
which would seem to make everybody happy anyway.

And I'm not all that keen on having so many changes controlled by a
use flag, unless it were part of some kind of agreed-upon transition
plan like with KDE back in the move to /usr.  It is like having two
different packages in one anyway.

Keep in mind that motivation in a volunteer-based project generally
does not include hitting somebody over the head until they quit.  It
is also generally the case that package maintainers tend to be aligned
with upstream, since if they didn't have a strong interest in the
package they probably wouldn't be maintaining it in the first place.
If somebody submitted a 53K patch to just about any other team in
Gentoo they'd be told to take it upstream.  Heck, Gentoo paid for a
patch to git and we didn't even apply our own patch until upstream
refined and merged it (though we did backport it - and I think all of
this is exactly how it should have been done).

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/27/12 12:46 PM, Patrick Lauer wrote:
> On 08/22/12 15:35, Luca Barbato wrote:
>> On 8/22/12 4:04 AM, heroxbd@gmail.com wrote:
>>> Dear Luca,
>>>
>>> Luca Barbato <lu_zero@gentoo.org> writes:
>>>
>>>> On 8/21/12 4:07 PM, heroxbd@gmail.com wrote:
>>>>> For monitoring against OOM http://wiki.gentoo.org/wiki/Monit
>>>>
>>>> So monit could be integrated in openrc easily ?
>>>
>>> In the way of runit, yes.
>>>
>>>>> cron/at is too general to document, there is one at
>>>>>
>>>>>      http://www.gentoo.org/doc/en/cron-guide.xml
>>>>
>>>> Agreed.
>>>
>>> :)
>>>
>>>>> upstart is designed to replace cron
>>>>>
>>>>>      http://upstart.ubuntu.com/wiki/ReplaceCron
>>>>>
>>>>> systemd recommends to replace cron
>>>>>
>>>>>      http://freedesktop.org/wiki/Software/systemd/Optimizations
>>>>>
>>>>> while OpenRC just work with it. For some fancy new feature to be
>>>>> used on
>>>>> non-servers, like "run every 5 minutes after start up", fcron can be
>>>>> used.
>>>>
>>>> Not sure exactly what should we add here.
>>>
>>> The feature of cron-like feature in systemd is limited, while in upstart
>>> they just replace cron for "cleanness" and integration. I don't think
>>> there is a special task OpenRC/cron can't do.
>>>
>>>>> A stub page is below. Still thinking of how to present it. May be
>>>>> we can
>>>>> just load it with examples which covers all the cases upstart being
>>>>> proud of.
>>>>>
>>>>>       http://wiki.gentoo.org/wiki/OpenRC/Event_Driven
>>>>
>>>> Yes, might be a good approach.
>>>
>>> New examples welcome ;) How would gentoo deal with udev is still
>>> unclear, while I think we can document the present udev features. udev
>>> merge with systemd is not a big threat, is it?
>>
>> Replacing udev-systemd with udev is probably yet another huge project,
>> hopefully somebody would help.
> We already have patches to fix things thanks to Polynomial-C aka. Lars
> Wendler. See:
> http://dev.gentoo.org/~polynomial-c/udev/
>
> Now we only need to motivate our maintainers to use the openrc useflag
> to fix udev properly.

Let's keep a fork call it edev and be done with that.

Sounds fine?

lu

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Rich Freeman]

On Mon, Aug 27, 2012 at 9:29 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>
> Let's keep a fork call it edev and be done with that.
>
> Sounds fine?
>

If you're asking for permission, then it isn't a fork.   :)  The whole
point of a fork is that you just do it...

Rich

Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012

[Luca Barbato]

On 8/27/12 4:10 PM, Rich Freeman wrote:
> On Mon, Aug 27, 2012 at 9:29 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>>
>> Let's keep a fork call it edev and be done with that.
>>
>> Sounds fine?
>>
>
> If you're asking for permission, then it isn't a fork.   :)  The whole
> point of a fork is that you just do it...

I guess you got totally wrong how a fork works. I won't keep my personal 
fork (even if I have one), but I'd rather gather enough people interested =P

lu