From: heroxbd@gmail.com
To: gentoo-soc@lists.gentoo.org
Subject: [gentoo-soc] (draft) final report for OpenRC soc project 2012
Date: Thu, 16 Aug 2012 00:14:46 +0900 [thread overview]
Message-ID: <861uj8faqh.fsf_-_@gmail.com> (raw)
In-Reply-To: <5028BBBE.6060109@gentoo.org> (Luca Barbato's message of "Mon, 13 Aug 2012 10:33:02 +0200")
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
next prev parent reply other threads:[~2012-08-15 18:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 8:58 [gentoo-soc] report 7.16-7.23: improving OpenRC heroxbd
2012-08-07 4:53 ` [gentoo-soc] report 7.24-8.7: " heroxbd
2012-08-07 9:16 ` Luca Barbato
2012-08-08 23:24 ` [gentoo-soc] report 8.8: " heroxbd
2012-08-09 6:05 ` Luca Barbato
2012-08-10 2:56 ` [gentoo-soc] report 8.9: " heroxbd
2012-08-10 8:51 ` Luca Barbato
2012-08-11 0:31 ` [gentoo-soc] report 8.10: " heroxbd
2012-08-11 23:50 ` [gentoo-soc] report 8.11: " heroxbd
2012-08-13 8:33 ` Luca Barbato
2012-08-15 15:14 ` heroxbd [this message]
2012-08-15 21:47 ` [gentoo-soc] (draft) final report for OpenRC soc project 2012 Luca Barbato
2012-08-16 8:38 ` heroxbd
2012-08-16 11:41 ` Rich Freeman
2012-08-17 5:39 ` heroxbd
2012-08-17 7:29 ` Luca Barbato
2012-08-17 11:56 ` Rich Freeman
2012-08-20 3:04 ` heroxbd
2012-08-20 8:16 ` Luca Barbato
2012-08-20 10:25 ` Fabian Groffen
2012-08-20 16:32 ` Luca Barbato
2012-08-20 18:25 ` Fabian Groffen
2012-08-20 10:47 ` Rich Freeman
2012-08-20 16:34 ` Luca Barbato
2012-08-20 18:12 ` Rich Freeman
2012-08-20 18:28 ` Luca Barbato
2012-08-20 16:15 ` EBo
2012-08-21 14:07 ` heroxbd
2012-08-21 15:55 ` Luca Barbato
2012-08-22 2:04 ` heroxbd
2012-08-22 7:35 ` Luca Barbato
2012-08-27 10:46 ` Patrick Lauer
2012-08-27 12:37 ` Rich Freeman
2012-08-27 13:29 ` Luca Barbato
2012-08-27 14:10 ` Rich Freeman
2012-08-27 14:35 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=861uj8faqh.fsf_-_@gmail.com \
--to=heroxbd@gmail.com \
--cc=gentoo-soc@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox