OpenRC GLEP proposal

Sat, 02/11/2017 - 08:09 - augustin

Preamble

There has been some serious concerns expressed in the Gentoo forums about the recent development of OpenRC. This blog entry tries to address them in a constructive, positive way. Should my personal opinion, expressed below, gain favourable reviews by the Gentoo community and by the OpenRC user community, this blog entry could be turned into a Gentoo Linux Enhancement Proposals (GLEP). If there is enough support for such a motion, the entire text below could be copied into the gentoo wiki, reformatted to fit the GLEP guidelines, and, of course, edited, amended and completed in which ever way the community sees fit in view of starting the official GLEP submission procedure. On the other hand, shouldn't there be any sufficient active support for such a motion, this blog entry will simply remain here, as a record of my opinion on the subject.

Context

systemd

In recent years, systemd has taken over much of the Linux ecosystem. Its meteoric rise has been such that all major Linux distributions have adopted it as their only supported init system. Despite this apparent global acceptance, systemd has been the major topic of dissent and cause of divisions within the Linux community. A vocal minority of Linux users refuse to install systemd on their systems, on both philosophical and technical grounds. So strong was the anti-systemd sentiment that some major distributions were even forked in order to provide a systemd-free alternative. Today, only few, minor distributions remain that offer its users a systemd-free Linux system.

It is not the purpose of this document to discuss the technical merits or shortcomings of systemd. However, we would have failed the reader if we hadn't mentioned it. It is indeed the proverbial elephant in the room. If systemd hadn't existed, this paper wouldn't have been written.

OpenRC

Although there exist numerous init systems, as of today OpenRC appears to be the only contender to stand as the main alternative to systemd. OpenRC is a fully functional, yet simple init system. It is actively maintained and it is evolving to meet the needs of current and future users.

Gentoo

Today, the OpenRC project is being hosted by Gentoo. The software itself is being maintained and enhanced by Gentoo developers.

According to NeddySeagoon1, OpenRC was written by, Roy Marples, a Gentoo and BSD developer known UberLord.
You can read a brief History of OpenRC.

Opportunity

The current state of affairs actually represent a very important opportunity for Gentoo. As mentioned above, OpenRC is probably the main alternative to systemd. It is hosted and maintained by Gentoo, and the Gentoo distribution itself is slowly becoming (or might become) the main distribution that offers a systemd-free alternative.

The strength of the anti-systemd sentiment is a major contributing factor to this opportunity. It is important to maintain a strong level of confidence in OpenRC users, so as to enhance the challenger status of OpenRC and bring to Gentoo a new generation of users-developers.

This opportunity shouldn't be wasted in needless disputes nor questionable technical choices. OpenRC has already been forked (notably by Funtoo). There is no need for any further divisions. It is the purpose of this paper to put forward some guidelines to ensure long term confidence in OpenRC and to encourage united efforts supporting its future development.

At this stage, it is opportune to cite the Principles of the Gentoo Foundation, its four pillars:

  1. Gentoo provides choices
  2. Gentoo is open
  3. Gentoo lives for the community, by the community
  4. Gentoo is independent

This proposal is another step towards ensuring that the above Principles are being upheld.

OpenRC commitments

Stability

The OpenRC project commits itself to providing a stable and reliable init system. An init system is one of the key component of a working Linux system. A broken or misconfigured init system might lead to an unbootable system, causing needless frustration and headaches.

OpenRC users must have the confidence that OpenRC will do its job reliably, in every condition. Users should be able to upgrade OpenRC in the full confidence that their systems will remain bootable and usable. No OpenRC upgrade should be allowed to lead to any system breaking.

Sometimes, however, it is necessary for OpenRC to change some key configurations or to change the default behaviour of some important settings in order to allow for further improvements. Such critical changes should be handled appropriately:

  1. Those changes must be adequately documented.
  2. The motivation behind those changes should equally be documented.
  3. OpenRC should be notified well in advance of such upcoming changes in such a way that they have time to take the necessary precautions and prepare their system for the upgrade:
    • Gentoo OpenRC user should be forewarned at least one month in advance via an official Gentoo news item (as in: eselect news list).
    • For OpenRC users of other distributions, and especially for the OpenRC packagers of such distributions, a low traffic, read-only mailing list should be established to notify them at the same time as Gentoo users would be.
  4. A proper description of the necessary changes to be performed at the moment of the upgrade shall be provided, together with links to the aforementioned documentation.

Any operation or behaviour of the OpenRC software that betrays this commitment to stability and reliability shall be considered a critical bug. An appropriate bug report shall be filed in the official OpenRC bug tracker, and kept open until satisfactorily resolved.

Also, as long as any such bug exist, the affected branches and versions shall not be considered stable and shall not be promoted for use on stable systems.

Flexibility

In keeping with the Gentoo foundation's principle to upkeep choices, OpenRC should remain flexible and shall not actively limit its users in the way they wish to configure their system, how they want to organize their file systems and distribute their partitions and mount points.

OpenRC shall remain flexible enough to suit everybody's needs.

OpenRC shall not impose limitations in order to follow any kind of 'standards' imposed by outside entities.

Every OpenRC behaviour that imposes such limitations on the user shall be considered a bug. A bug report shall be filed in the official OpenRC bug tracker and the bug report be kept open until the issue is satisfactorily resolved. Any user-submitted patch should be reviewed by the OpenRC maintainers. Should the patch conform to the quality standards and to the above guidelines, it shall be committed into the code repository.

Usability

While the importance of authoritative documentation (man pages, etc) is obviously primordial, it does not prevent OpenRC to strive to be ever more usable and intuitive.

OpenRC shall strive to minimise the number of occasions a user of any level of experience has to refer to documentation. The goal is to make OpenRC as intuitive to use as possible, and do so without removing any features.

OpenRC today is shipped with a collection of scripts (all the openrc* and rc* executables) which is great for experienced users. They are convenient to use in higher level scripts. A newbie user however might get easily confused and overwhelmed.

A new, single menu-based interface, simply named openrc2, shall be implemented as a complement to those existing executable in order to facilitate further the administration of a OpenRC system, especially by new users. This new interactive executable would act as a wrapper and be a comprehensive, single point of entry, especially for new OpenRC users. With a series of menus and sub-menus, it would guide the user to the action it actually wants to perform. In addition to performing the required action, the script would print out the CLI command that the user could have typed in order to perform the action directly. Doing so would provide a bridge between reliance on the menu-based, interactive script and the use of lower level existing script. It would allow new users to intuitively learn how to operate OpenRC and adopt the workflow that best suits its own preferences and habits.3

Allow me here to make a comparison with phpmyadmin to illustrate my point. Phpmyadmin allows users to use a convenient GUI interface to administer their databases and perform queries. On the other end of the spectrum, experienced database administrators might not use phpmyadmin at all, but invoke mysql from the command line and type in queries manually. But this is not a "either/or", "GUI vs CLI" situation. This is more a spectrum going from one extreme to the other, with many users using alternatively both the GUI and the CLI according to what best suits their needs at the time. The point here is that phpmyadmin empowers the user and allows it to learn in a very convenient way : indeed, for each action performed via the GUI, phpmyadmin will display the actual query that was issued. Thus, a complete newbie, who may at first not be able to write out the simplest SELECT... statement, can use the very convenient and very intuitive GUI, and see at the same time the SQL queries, allowing it to progressively learn SQL language.

In order to further enhance usability, OpenRC executables shall always provide clear messages, wherever appropriate. This is particularly important in cases where user action is required or when something goes wrong. The executables shall provide sufficient information for users of any level of proficiency with OpenRC to know what action to perform, why, and where to look for further information (e.g. a specific section of a man page).

In my experience as a new Gentoo user, I find that the various Portage tools (emerge, etc.) get it mostly right, with clear, coloured output, clear messages that tell us what command to issue at the appropriate times, and where to look (man page and section) when more in depth information might be necessary, etc.

OpenRC shall implement the best (information, warning, error...) logging standards. The logs shall remain in plain text, providing clear, intelligible messages. Third party scripts should also be able to easily parse the logs. Specific errors should be assigned a code number to uniquely identify issues. User feedback should be integrated into the documentation as to what situations can cause specific issues and how to remedy them.

OpenRC shall avoid double negatives, especially in configuration files (e.g. replace rc_nocolor=NO with rc_color=YES).

OpenRC shall strive to be consistent (e.g. why are some script named rc-something while others are called ? Why are OpenRC's files by default called rc.conf, rc.log and not openrc.conf, openrc.log, etc.?)

Any issue as may be reported by any user that contravenes the aforementioned usability goals shall be filed in the official OpenRC bug tracker, and the report be kept open until the issue has been satisfactorily resolved. Where the resolution of those issues would implicate backward compatibility and changes in behaviour that may require configuration adjustments, it shall be done as stated above in the section regarding stability.

  • 1. https://forums.gentoo.org/viewtopic-p-8032504.html#8032504
  • 2. It would conflict with the already existing openrc executable, but the simplest choice would also be the most intuitive. The current script could be renamed openrc-somethingelse, but only in accordance to the stability standards expressed earlier.
  • 3. To clarify my original thought: I am not speaking about a GUI tool at all. What I have in mind is a light weight bash or python script, that would allow a beginner user to get started very quickly and very easily. My goal generally speaking, is to make every software installed on my or any linux machine be as intuitive and usable as possible. I am pointing out a way OpenRC could gain in usability, from the perspective of a newbie user.