On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
Openrc is included in Debian.
It was one of the candidates considered when deciding what init system to adopt, altought it had much less support than systemd or upstart (and I suspect it's even less tested than sysvinit).
yeahh it was a pity it hadn't had as much mindshare: i've installed it by default on the parabola gnu/linux-libre eoma68-a20 images and, whilst it works well, it feels a little... odd. perhaps that's down to being unfamiliar with it, or that parabola / archlinux requires that if you install e.g. openssh you have to remember to install openssh-openrc and then also run a manual command to make sure it's enabled at boot time (pacman lacks the postinst functionality of dpkg, and archlinux itself seems to lack the concept of setting up "default configured behaviour" for services, leaving that to the user themself).
one good thing: i wasn't aware that openrc could be parallelised: it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i will try out very shortly.
back when the openmoko came out, you remember you bought one phil, and told me that it was terribly unresponsive? they used an ARM9 processor, which has a very poorly-designed 1st level cache. on the ARM9, thread/process context-switching results in COMPLETELY throwing away the contents of the 1st level cache.
so any context-switch - x11, d-bus, parallel startup, whatever - resulted in performance that was last seen when sysvinit was initially designed, because it *was* designed [N decades ago] to start services *in series* so that context-switching could be minimised as much as possible.
unfortunately, developers who primarily use x86/amd64 forget that it is only intel / AMD processors that have heavily-optimised context switching: hyperthreading, 4 or more cores / hardware-threads (usually, these days), 1st level cache that's often larger than the 2nd level cache of embedded processors and so on...
... so they design software that really only works well on x86. i remember around 2004 running opie / familiar on 600mhz Intel ARM PXA 270 processors (before PXA was sold to marvell) and the boot time was often in the *TWO MINUTE* range. god only knows what would happen if systemd was deployed on such processors.
systemd unfortunately makes heavy use of d-bus for message-passing. unlike most client-server RPC architectures, d-bus acts as an INTERMEDIARY. that makes for DOUBLE context-switching. client SWITCH d-bus-as-intermediary SWITCH server. for *each part of a round-trip*. that means *FOUR* context-switches for a simple "request-response" as opposed to just two for any other client-server RPC architecture.
the heavy usage of d-bus for the openmoko OS basically was part of what killed the project. it would not surprise me at all to find that d-bus is similarly slowing systemd down when compared to other init systems.
anyway i'll dig the parabola microsd card out again, switch to parallel openrc and boot it up. it might be a bit much for the A20 to handle, but we'll soon see.
l.