From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7630F1381F4 for ; Thu, 16 Aug 2012 00:07:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 042AA21C08C for ; Thu, 16 Aug 2012 00:07:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 39B30E08E1 for ; Wed, 15 Aug 2012 21:47:53 +0000 (UTC) Received: from Nyx.local (dynamic-adsl-84-221-248-58.clienti.tiscali.it [84.221.248.58]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 002021B4022 for ; Wed, 15 Aug 2012 21:47:51 +0000 (UTC) Message-ID: <502C1903.1090805@gentoo.org> Date: Wed, 15 Aug 2012 23:47:47 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120808 Thunderbird/15.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 To: gentoo-soc@lists.gentoo.org Subject: Re: [gentoo-soc] (draft) final report for OpenRC soc project 2012 References: <86wr1tcz8f.fsf@gmail.com> <86d333cngt.fsf@gmail.com> <5020DD0A.3030506@gentoo.org> <86ipct6k80.fsf_-_@gmail.com> <50235319.5000504@gentoo.org> <867gt75uab.fsf_-_@gmail.com> <5024CB9F.4060906@gentoo.org> <86y5lml15i.fsf_-_@gentoo.org> <86vcgpj8d8.fsf_-_@gmail.com> <5028BBBE.6060109@gentoo.org> <861uj8faqh.fsf_-_@gmail.com> In-Reply-To: <861uj8faqh.fsf_-_@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: f465310b-5b2d-4ece-a7b8-ca622a168f51 X-Archives-Hash: d110537cd90e87d0337367f268269ca0 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 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