From: "Brian May" <brian(a)microcomaustralia.com.au> "Something like systemd" does not mean "systemd", as said. In one point Hubbart is a bit unkind to FreeBSDs init scripts. For a while now they are now "ahead" of old-fashioned sysV where the number S## determines the order. rcorder orders them at run time before running them. E.g. nfsd: # REQUIRE: mountd hostname gssd nfsuserd mountd: # REQUIRE: NETWORKING rpcbind quota rcpbind: # REQUIRE: NETWORKING ntpdate syslogd ntpdate: # REQUIRE: NETWORKING syslogd So this describes a logical order for nfsd and dependencies. Obviously some order is needed but they all come after a milestone NETWORKING and syslogd. syslogd_enable ="NO" makes the later a NOP. pppoed has # REQUIRE: NETWORKING so it could run in parallel. Yes, there is inetd, and there is cron.. (something else?) and there is a risk of having things in parallel (needeing semaphores). Ansd there are events as e.g. a USB device plugged in and caught by devfs etc. I am pretty sure that will be dealt with in a sensible way. systemd is a bit like our office renovations at the moment. [Slightly made up] "There is a cable in the way" "Just cut it" "Don't worry we go wireless". And a few days later: "Well, we need this on an Ethernet cable." "Don't worry, I still have a piece of string and a band aid" I just helped someone on the German mailing list with boot problems under OpenSUSE. He had /home coming from an iSCSI target. It just did not boot. He could not figure out how to fix the sequence so it worked, and started to hole it through the boot.local and rc.local scripts. This are fallbacks which are more or less obsolete for twenty years but needed as a life support for him. Regards Peter