On 05/23/2013 03:15 PM, Lucas Nussbaum wrote: > I have the (possibly wrong) impression that OpenRC is less advanced > technically than systemd and upstart, and lacks many of their advantages > For example, according to https://bugs.gentoo.org/show_bug.cgi?id=391945 > which is linked from > http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems, parallel > boot does not work due to problems in dependency handling.
I don't think that taking any random bug (which is a "can", not "always") is fair. > I also understand that OpenRC does not replace sysvinit, but instead > is an additional layer on top of it (for example, sysvinit stays PID 1). I believe that is a very strong thing in *favor* of OpenRC. Why on earth do you need to reimplement the PID 1 for booting your system? It works very well, and doesn't need to be changed and over-engineered. All the logic is done away from it, in its child PIDs, because PID 1 is a very dangerous place to hack (if it crashes, your whole system is dead). > I'm not saying that OpenRC should be excluded right now. I'm open to be > proven wrong. :) And actually, I'd recommend that once you are > reasonably sure that OpenRC is a viable alternative, you follow the same > path as for other init systems (policy support, explore how it can > co-exist in the archive, explore how we could transition to it, etc.) Actually, I believe that OpenRC transition should be one of the most smooth of all the init systems, once the port to Debian is done, and when the support for existing LSB header is tackled (we already have some script in both python and perl to handle automatic conversion of the LSB header). Meaning that we could simply replace sysvrc with OpenRC, have all the nice added features (cgroups, nicer headers than LSB headers, tiny small init scripts), and still continue to have the possibility to keep large, bulky init scripts, if that is your thing. They all coexist together, you just decide what you wish to implement. What I like the most with it is that it is very, very simple, and easy to hack. I think I wrote too much already. I would prefer to be able "it does" rather than "it could". Thomas -- 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/519e7a67.7080...@debian.org
