That is good. More deterministic behavior. Less bugs. Servers don't shutdown and Laptops / workstations sleep. Fast "reboot" time is an old-fashioned concept. Even Windows doesn't shutdown by default these days.
Parallel service startup works reliable on other OS. It's principle handling is known for decades.
Tell me one laptop where
hibernation works on FreeBSD. I managed to get
suspend-to-disk to a special IRST partition (after a timeout fires in suspend mode); that's UEFI/BIOS not FreeBSD, a workaround, and one of very few exceptions. The partition can't be used for anything else yet. Plus it requires careful setup e.g. USB, modem, etc. I can do it, a newbie/non-nerd, s/o who just wants to use a solid system build of and providing sound & proven modules & methods, can not (easily enough, e.g.
here). To make FreeBSD more user-friendly is a key to widen it's user base, which will result in more skilled developers after some years. Currently, young IT people leaving university employ Linux for their 1st professional projects, because that is what their're used to.
I would rather mistakes in plain-text scripts than binary Win32/systemd units. Either way, bugs happen in all approaches. BSD's are just easier to debug.
100%
d'accord.
This hack doesn't have a name yet because systemd is too young. I call it ".ini files are crap for handling services". Catchy huh?
I did not promote
systemd. Instead, I posted a link with the comment:
"a nice article on how not to do it"
These have different use-cases. For example Windows, macOS and systemd all target consumer desktop environments.
So why do you think FreeBSD should not be targeting desktop use-case? Same argument as above: people like to use the same system they already know for any new use-case. Are you one of those who's attitude is:
"It was hard to write, it should be hard to use"? I can't find any "
For Nerds Only"-sign on any FreeBSD website.
…and my yesterdays adventure was getting to know who else can overwrite my resolv.conf on a systemd machine (and where its sources are spread over the system)… 99% you don't have to bother about this little file, but when automatic things fail you spent hours to fix it - instead of writing one simple line in a config file.
Again here too, I'm not promoting
systemd. Just because there's a very bad example doesn't mean others are equally bad, right? I explicitely noted
runit & OpenRC.
FreeBSD has
resolvconf.conf(5) and it can easily bite you the same way. In fact, it bites me because by default
dhclient(8) does not seem to use
resolvconf(8) (or there's a bug).
And yes, such things could be done configurable, so that it behaves as I want. But even then: The price is getting things much more complicated.
That is to be verified. I do not know if
runit & OpenRC are leightweight or blown up.
…so: In which cases would such a init thing be usefull? I've heard many times that this would be great to have, but I've never heard of an example or usecase with a real benefit.
Desktop. Despite I'm one of few who can hibernate, my setup of devices is not 100% perfect, thus I prefer to reboot.
Embedded devices.