Debian looks at OpenRC
Posted Aug 23, 2012 21:50 UTC (Thu) by rleigh
In reply to: Debian looks at OpenRC
Parent article: Debian looks at OpenRC
This is one of my primary objections to systemd, which was mentioned here: http://lists.debian.org/debian-devel/2012/04/msg00751.html.
The tight-coupling between components which systemd is encouraging and requiring is something which, for those who remember back then, we used to criticise Microsoft for, due to their inability to dig themselves out of the rut such philosophy had led to, being unable to fix even trivial bugs due to fixing them breaking old code. It leads to inflexible systems which can't change, whereas loosely-coupled systems, which Linux has had until now, allow components to be easily swapped out and changed providing that the interfaces between the components are relatively well specified. The loose coupling does have the disadvantage that components aren't necessarily as well integrated, but this hasn't really been a problem in practice--the benefits far outweigh these downsides, and this seems to have been forgotten in some camps.
An example is the requirement for stuff like cgroups, autofs, D-Bus etc. Having these as a requirement, rather than merely being optional and used if available, imposes constraints on other projects. cgroups can never be removed from the kernel, and distribution kernels must include it. So it indirectly forces other parties not to allow certain components to evolve or be removed. Likewise in userspace with D-Bus. I can't say I'm particularly happy to have such a nasty bit of code required to be running on my system, let alone being used by init. If systemd was a bit less aggressive in its strict requirements, it would be rather more portable (including to Linux, for kernels which don't have all the extra bits built in).
The other issue is the reliability of the system. sysvinit is tiny (~30KiB on i386), because it does relatively little. This makes it very reliable. PID 1 must never die! There's no need for PID1 to do anything but the bare minimum--it's quite fine for more advanced stuff to be done by other processes forked from init. The ideas behind other less well known alternatives such as s6 are also well worth looking into. The nice thing about OpenRC is that it's run from init, so it can do some more advanced stuff like dependency-based boot, but the extra complexity is not going into PID 1. Now, it's clearly not as advanced as systemd. But it's most certainly more advanced than sysv-rc. It gives us some of the features that systemd offers, but without the massive downsides.
Lastly, while there's a lot of momentum in the adoption of systemd across several other distributions, I always feel somewhat bothered by the arguments that we must adopt it or get left behind. Blindly jumping on the latest bandwagon is rarely a sensible choice, particuarly when it might not be taking us where we want to go. And while having a single init across distributions is touted as a generally good idea, having different implementations does prevent gross stupidities from taking place, nor give any single party the ability to force unwanted changes upon eveyone. Systemd certainly has a lot of good ideas, but the package as a whole is does not allow one to pick and choose the good from the bad due to its lack of modularity. That might require them to be reimplemented. As has happened with cgroups in OpenRC.
to post comments)