From: "Brian May" <brian(a)microcomaustralia.com.au>
FreeBSD could be so much better if only they adopted something like
SystemD too :-)
talking about how an approach like systemd is needed on FreeBSD." --
"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.
# REQUIRE: mountd hostname gssd nfsuserd
# REQUIRE: NETWORKING rpcbind quota
# REQUIRE: NETWORKING ntpdate syslogd
# 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.
# 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"
worry we go wireless".
And a few days later: "Well, we need this on an Ethernet cable."
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
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.