@lobocode Oh, I'm not strictly against replacing #mewburnrc by something NOT relying on shell scripting, possibly integrated with #init. That probably makes sense.

The thing is, I still have the strong feeling that #systemd is "doing it wrong".

Regarding the "multitasking power" argument, I don't think that's directly tied here, you *could* solve this with scripting as well. Instead of just deducing an order (like mewburnrc does), you "just" need a real dependency graph.

But of course, moving away from shell scripting has the potential to give both better reliability and performance. But then, please take the time for a design of some portable, unintrusive and standardized interface between daemons and init systems 😉

@lobocode On the one hand, #FreeBSD never suffered the brokenness of #sysvinit. It uses a minimalistic init with a quite well-designed rc-system: #mewburnrc. Sure that's still based on shell-scripting, but at least it comes with a sane framework making your typical init-script short, maintainable and correct.

On the *other* hand, at least for me, whenever I have to deal with #systemd, it feels ill-designed.

Just a little example, I recently wrote quite a few daemons. There's a simple "interface" allowing an init-system to know when a daemon is really "up", exactly when its first (parent) process exits with a successful exit code. With systemd, the default mode of operation is "don't care" (started and not died yet is good enough), and if you want to inform systemd when the service is ready, the recommendation is to implement some systemd-specific startup notification API. No, thanks.