Differences between revisions 4 and 5
Revision 4 as of 2013-10-30 10:25:01
Size: 3929
Editor: ?Thomas Goirand
Comment:
Revision 5 as of 2013-10-30 10:35:22
Size: 4847
Editor: ?Thomas Goirand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * upstream version of OpenRC provides an intefaces for extending it with additional modules by plugin system of s-s-d (openrc-plymouth is done in that way)
 * openrc is designed to do service management and do it well, thus it's acts as a central place and glue for other existing systems that can solve subtasks in the best way. i.e. glue for init(pid-1), supervision(s6/monit), loggin utilities. So it's possible to construct scalable solutions on the top of it
 * OpenRC is ready for contribution and work on openrc-daemon: additional package that can provide additional interfaces for openrc (e.g. some sort of systemd-compatibility)
 * OpenRC provides librc that can be used in the 3rd party tools that want's to extend openrc
Line 24: Line 28:
 * not everything from the plans are ready (i.e. there is no clean supervision integration), however work is done
 * no big vendor behind openrc, thus there is no paid developers

Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainers.

OpenRC position statement

OpenRC wishes to continue implementing things in a small, simple and efficient way, with the minimum things written in C. It also aims at portability. OpenRC is used in Gentoo by default, but also works very well in a number of BSD systems, and it can already work under Debian GNU/kFreeBSD very easily. OpenRC doesn't "take over" the PID 1, it doesn't even implement it, it only implements what's after it: it is a replacement for sysv-rc, not for sysv-init.

Pros

  • OpenRC is straightforward: we don't reinvent the wheel, and just keep what we used to have. update-rc.d, invoke-rc.d, etc just "work" as expected. OpenRC continues to use start-stop-daemon, which it enhanced. Though if we want to switch to the newer interface of OpenRC (rc-update, etc.) it is possible as well.
  • The runscript file format allow both a completely declarative (something like 7 lines should be enough in most cases), but it also supports the old sysv-rc format, with the addition for the support of the LSB headers which has been added last summer by the GSoC studdent. So the transition would be extremely easy: just switch to OpenRC, then slowly move away from sysv-rc style. Nothing to force on anyone.
  • OpenRC is a very good compromise between features and complexity of upstream code. As few as possible code is written in C, the rest of is easily maintained using scripting (perl, shell...), making it very easy to maintain.
  • OpenRC does not reimplement sysvinit. Yes, this is a good thing. Rewriting the PID 1 process is very dangerous, and adding a lot of code in it is the recipe for disaster. Here, we would continue to reuse what has worked well for decades, and enhance the features later in the boot process.

  • OpenRC has a runlevel namespace. Bye bye runlevel 0, 2 and 4, and say hello to runlevels with comprehensive names "shutdown" (instead of 0), "single" (instead of 1), "reboot" (instead of 6) or "default". Note that this is handled in an extremely easy way using /etc/init.d/rc (which is specific to Debian, for compatibility reasons). OpenRC doesn't even need /etc/inittab to be edited since last September, so we could even keep what we have currently, including any user modified inittab files.
  • Everything stays as we are used to. No huge revolution needed, like rewriting getty and so on for no valid reason (are these tools broken? if so, how???)
  • OpenRC uses control groups to ensure that any service, regardless of its state, can be shut down properly. Though that's not a forced feature, it continues to work on systems who wont CGroups available.
  • OpenRC allows very fast boots. One of upstream author made a proof of concept with booting in 250ms.
  • OpenRC supports nested runlevels this mean you can create complicated system layout by creating specialized runlevels: like default/X11, default/nonetwork, default/network
  • OpenRC upstream is friendly and open as for contributions and for suggestions for feature and portability, they will try to find consensus for the every edge case. They have already been extremely helpful during this summer for the GSoC, with one of the upstream doing the mentoring work as well. They also helped with the porting to kFreeBSD (took only a few hours).
  • OpenRC supports a subset for event-driven action,e.g. services hotpluging [example: http://wiki.gentoo.org/wiki/Iphone_USB_Tethering#udev_trigger]

  • upstream version of OpenRC provides an intefaces for extending it with additional modules by plugin system of s-s-d (openrc-plymouth is done in that way)
  • openrc is designed to do service management and do it well, thus it's acts as a central place and glue for other existing systems that can solve subtasks in the best way. i.e. glue for init(pid-1), supervision(s6/monit), loggin utilities. So it's possible to construct scalable solutions on the top of it
  • OpenRC is ready for contribution and work on openrc-daemon: additional package that can provide additional interfaces for openrc (e.g. some sort of systemd-compatibility)
  • OpenRC provides librc that can be used in the 3rd party tools that want's to extend openrc

Cons

  • OpenRC doesn't have socket activation yet.
  • While some porting efforts has been put on OpenRC, it still needs some more work to get into Debian, namely the rename of /sbin/rc which clashes with the /usr/bin/rc from the "rc" package.
  • No effort yet to port it to Hurd.
  • not everything from the plans are ready (i.e. there is no clean supervision integration), however work is done
  • no big vendor behind openrc, thus there is no paid developers