Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Arto Jantunen <viiru <at> debian.org>
Subject: Re: RFC: OpenRC as Init System for Debian
Newsgroups: gmane.linux.debian.devel.general
Date: Wednesday 25th April 2012 13:40:31 UTC (over 4 years ago)
Patrick Lauer  writes:
> in the last months there have been many discussions about init systems,
> especially systemd. The current state seems to make no one really happy
> - the current debian init system is a bit minimal and doesn't even do
> stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
> /etc/init.d/apache2 start). On the other hand systemd is just Not The
> Unix Way, it consolidates everything into one huge process and forces
> some imppossible dependencies (dbus? udev? on my server?! and you expect
> a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
> so where does that leave us? (One might notice that "everyone else" is
> just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
> others still not committed to a migration yet)
>
> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> have-always-been-there sysvinit/insserv init scripts in Debian.

Based on this text it seems to me that OpenRC doesn't do anything that
our current init wouldn't do (we already have dependencies and
concurrent startup), and also that it wouldn't solve the problem upstart
and systemd were created to solve. I might be wrong here since I don't
know OpenRC, so correct me if I'm missing something.

It seems to me that many of the conversations about init systems have
been missing the point quite badly as well, so it might be that this
isn't obvious.

To me the point is clearly reliable bootup, not speed or dependencies
themselves (the dependencies are required for implementing reliable
bootup, and the speed is produced as a side effect of correctness).

Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning
for pci or sata busses and loading drivers isn't exactly instant in all
cases either), and the kernel has little choice in the matter. It can
either sleep until "everything is surely detected by now" before passing
control to userspace, or pass control and the problem along (by
providing event notification when the device set changes). The kernel
made its choice about this years ago, and we have been living on
borrowed time and kludges since then.

-- 
Arto Jantunen
 
CD: 3ms