[arch-general] RFC: OpenRC as init system for Arch

[Tom Gundersen]

Hi Patrick,

On Mon, May 7, 2012 at 3:30 PM, Patrick Lauer <patrick at gentoo.org> wrote:
> People have thrown "event based" and such words around, but no one has
> dared to clarify or properly define what they mean by it. Thus I can't
> understand if there's anything missing in OpenRC or people are just
> throwing words around because it feels good.

I assumed anyone working with init systems had a firm grasp of the
main selling-points of the competition, but let me try to explain what
I have in mind (by no means take this as authorative, there is plenty
of writing on this both by the upstart guys and the systemd guys who
know it better than me).

I guess it is best explained in terms of an example, let's take
storage: Traditionally we would wait for all the storage devices to be
enumerated, then fsck all of them, then mount all of them, then start
the daemons which might require something from say /var. This no
longer works well with modern hardware and a modern kernel.

The reason is that we don't know when the kernel has finished
enumerating all the devices (sometimes we do, but not always, it
depends on the device), and we certainly don't know in case the user
has not yet plugged in all the devices at boot, or some of them are
network devices that may or may not appear depending on what network
we are currently connecting to.

An event-driven init system would turn this on its head, and never
wait for "all the things to be ready", rather start things on-demand
and whenever their dependencies are satisfied. This leads to a much
simpler system (from the admin/system daemon developers point of
view), but it requires the init system to keep closer control over the
state of the system, listen to events, etc.

This means that there is no difference between "boot time" and any
other time. If you plug in your network cable, or your external hard
drive a week after switching on your computer they will be mounted (if
that's what you configured in your /etc/fstab) in exactly the same way
as if they were connected when you started your computer.

>> On Thu, Apr 26, 2012 at 1:27 AM, Patrick Lauer <patrick at gentoo.org> wrote:
>>> About modules and bloat - for systemd you're going from a few hundred
>>> lines of shell to a few hundred thousand lines of mandatory
>>> dependencies.
>> I have no idea where you get these numbers from, or why they should matter.
> These numbers come from comparing the code that is involved in system
> startup. If you get really fancy you use something like "sloccount", or
> if you're lazy like me you just use wc -l.

I know how to measure the number of lines of code, and I do
acknowledge that if you can do the same job with less code that's
nice. My question was: what are you counting as "mandatory
dependencies" for systemd. I know of libdbus (the daemon is not
mandatory) and, contrary to what it says on the openrc website, glib2
is not a mandatory dependency.

What do I do when things don't work? Use the awesome debugging tools
that systemd provides. Makes my life a hell of a lot easier compared
to when debugging initscripts.

On Mon, May 7, 2012 at 3:54 PM, Patrick Lauer <patrick at gentoo.org> wrote:
> Already udev lost features and got wrongly renamed, and we haven't even
> had a proper release yet.

Udev got slimmed down a bit, but this was the right thing to do even
without systemd. One tool for one job, right? It no longer creates
device nodes, instead it says that that is the job of the kernel
(mostly) or (for the few exceptions the kernel can't deal with) some
separate user-space tool that is called during boot. systemd ships one
such tool, which you could easily copy, or you could make your own. It
would be about three lines of bash ;-)

>> What's wrong with WantedBy? You don't like the term, or do you have a
>> technical problem with it?
> It's very difficult to handle properly - you have to check all init
> scripts / unit files / znargfruzzles every time to see if their
> dependencies changes, and if they have any WantedBys.

I'm struggling to follow your line of thought... "every time" what?
WantedBy are simply used when you enable a service. Typically you'll
either have WantedBy=multi-user.target or WantedBy=graphical.target,
to tell systemd which "runlevel" the service should start in, I don't
see why this, of all things, would cause such huge problems.

> And you should ask
> people that had to debug threaded INTERCAL why it's not as awesome as it
> sounds at first glance ...

I didn't know what INTERCAL was:

"INTERCAL is an esoteric programming language that was created as a
parody by [...] two Princeton University students, in 1972. It
satirizes aspects of the various programming languages at the time, as
well as the proliferation of proposed language constructs and
notations in the 1960s."

Doesn't seem very relevant to the current discussion...

> "Not possible" is not a valid response to my problem-removal-needs.
> SystemD is too big and too undocumented for me to trust my skills, I
> wouldn't want to have to rely on a system that I mutilated like that
> just to fix a rare corner case that "shouldn't be there" (yeah, great,
> thanks, it *is* there. Do you want to make it go away?)

I think some of the point of systemd is that once you find a weird
corner-case that does not work you can bring it to the attention of
the dozens of talented hackers from all
distros/formfactor/architectures/... and someone will be able to fix
it (hopefully without any unwanted side-effects).

> You have no idea how much it bothers me to have to repeat myself, again,
> for the last time I hope ... but ...
> What do people actually *mean* by event driven?

If you had given people a chance to reply to your first email, you
would not have needed to ask twice ;-)

On Mon, May 7, 2012 at 4:25 PM, Patrick Lauer <patrick at gentoo.org>
wrote (in reply to Nicolas Sebrecht):
> So all in all you just managed to upset some greybeards and turned a
> technical discussion into random ad hominems. Nice :)

No he didn't. He was quite right in pointing out that distribution
maintainers are not necessarily great developers, which probably has
lead to lots of bad shell scripts over the years spread around in
different distributions. You are the only one attacking people (in
particular one of the systemd maintainers, who is not even involved in
this discussion). It is really making the OpenRC community look bad.

On a somewhat related note, I was reminded to check your website again
to see if you corrected your table of features. I thought I might let
you know of the errors I found (making these kind of blunders makes it
look like you don't really know the competition):

 * systemd is portable to non-x86 (as far as I know, it is tested on a
wide range of architectures and aims to work on anything that works
with the Linux kernel)
 * systemd definitely separates code and config, as far as the
admin/user is concerned s/he only has to deal with /etc/systemd/ which
contain declarative .desktop-style configuration files. No code.
 * systemd is very extensible, you can easily add in your own .service
files to do whatever you want (I imagine you could even use systemd as
your init and only run openrc as your only service file and it should
just work).
 * friendly upstream: no comment.
 * complex init scripts: don't know what you mean, but you can use
whatever initsrcipts you want in systemd
 * i'd be interested in reading more about how you automatically
calculate dependencies to a greater extent than systemd. do you have a
link, or could you elaborate?
 * systemd integrates into virtualization (more so in the next release)
 * the architecture is definitely modular, just look at the sourctree,
most of those subfolders correspond to separate tools that can be
disabled or exchanged for something else.
 * lots and lots and lots of verbose debugging available if you chose
to enable it. Both from systemd itself and from whatever your daemons
spits out to stderr.

Cheers,

Tom