Patrick Lauer <patr...@gentoo.org> 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehrcc4kw....@kirika.int.wmdata.fi