OK so because of how much time has been spent arguing about systemd with little technical content, i've spent some time on the freedesktop site reading Lennart's blog and also going through the source to find answers to my questions about the socket activator. i've also been going through the man pages of netctl too and am horrified at the lack of what i would call enterprise features.
this is by no means a definitive list. I just thought that i would share what i had found. please correct me if i am wrong in any of these. please add to the list for technical items only. thanks! pros 1.very modular, everything can be disabled though not removed 2.socket based activator allows restart of services with no service interruption 3.if activator.c is used for this, then the code is actually pretty clean using supplied sd-daemon.c simplifies sockets for daemons and also adds extra watchdog features 4.can disable socket based activation according to Canek, but i can't find how. 5.fschecking mounts and logging output (though how for corrupt / notsure) 6.auto-gettys allows for lower numbered X windows by default for e.g. multiseat and dynamic serial ttys 7.clever logging, including from nspawned containers' logs and distributed for enterprise 8.nspawning using filename namespaces 9.systemctl kill <service> -- killing service and all forks and spawn cgtop -- top with cgroups 10.much easier to define resource limitations per service cons 1.new tools to learn, new gotchas to learn. 2.yet to go through systemd source to find out how modular or not it is. 3.not clear how the socket activator works, the code activator.c appears to be to _test_ activation only, with activator code being elsewhere. if it is used then you would have one process running for each port it is virtually listened to. 4./etc/machine-id because hostname and node id in the <cluster of your choice> are not enough. 5./fsck.options gives more options than "auto""force""skip" on reboot 6.requiring logging tools in rescue cds in order to view logs 7.chroots no longer work. forcing use of nspawn to ensure environment set up correctly. 8.strange gotchas: that because of socket/dbus etc activation you have to disable a service first, then stop it in case it is then restarted in the background 9.the new deal breaker for me is the networking. for anything remotely complex (i.e. two IP addresses on an interface woo), need to use netctl. a.which doesn't support vlan naming types i.e. padding zeroes b.doesn't appear to support gre keys c.doesn't appear to support multiple routing tables d.doesn't appear to support "ip rule" e.doesn't have lacp support for bonding f.there is the option for running a script in PRE and POST UP but...no 10.strange gotchas: /tmp being tmpfs using up to 50% ram. unless mounted in fstab 11.strange gotchas: logging is volatile by default _unless_ /var/log/journal exists, when it becomes persistent due to the "auto" default. 12.transitions into systemd are non-trivial. my own conclusions systemd seems to be excellent for a desktop good for _new_ instances of service VMs. I say new because of the large job of transitioning away from openRC, but all the watchdog and better resource management will help to pack datacentres. It would also be good for big iron running many services because of this, but then i thought everyone was using small fast service specific gentoo VMs to compartmentalise anyway --- or was that just me? Unless I have completely got netctl wrong it is terrible for a firewall/router scenario, or being the host server for LXC containers which is a shame because resource management built in to service control combined with say docker.io would be a great combination; as long as you don't use custom VLAN settings. As Gentoo is a meta-distro (says Larry the Cow http://www.gentoo.org/main/en/about.xml) and a rolling release distro, I'm all for choice, but I would sincerely hope that unlike all of the other distributions from Arch to Ubuntu systemd is not adopted by default as udev and baselayout transitions were bad enough. I will however be installing a systemd desktop in a vm to play properly. YMMV
