On 04/25/12 21:40, Arto Jantunen wrote: [snip] >> 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),
* stateful init scripts (e.g. /etc/init.d/apache2 start -> * WARNING: apache2 has already been started) * nice management tools (rc-status shows what init scripts are in the current runlevel and their current state) And many small features that just make life a bit easier like named runlevels (so it's "single" instead of "1") > 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. Both upstart and systemd suffer from NIH and (imo) fail to be simple and reliable. But you are right, OpenRC is not revolutionary, it's more a consequent evolution that happened as we were slowly fixing all the little bugs that annoyed us. > > 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). In my experience OpenRC has the most reliable and deterministic bootup, and it makes it easy to figure out your current state (is apache still running? Should it be running?) Performance and all that is just a bonus for me, always correct is more important than fast :) > 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. I mildly disagree there. The init system doesn't need to know about such things, it only provides the actions. The device manager (what used to be udev+hal, then was udev/gudev and is now systemd) should handle the policy. So - connecting a usb wlan card triggers a kernel event, which udev processes, and udev then decides from its rules what action to take - say /etc/init.d/net.wlan0 start (Although there is a considerable overlap between rules and actions) For me there's no reason why udev / mdev can't stay standalone, integrating it into the startup scripts doesn't feel right. Have a nice day, Patrick Lauer -- 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/4f980e8e.6020...@gentoo.org
