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

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@g.o> 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