Unfortunately, you don't like features 😎🤪

I do, but I don't like them in critical processes / systems. An init that is too stupid to crash keeps the system running better than an everything-and-the-kitchen-sink init that itself depends on at least one other process, and containing an ever-increasing crapload of features. See Re: How not to implement updaters.

Having a fileserver that is unable to shut down because the f***ing init replacement has lost its ability to receive the shutdown command is not fun. It's worse enough if it happens to the fileserver containing your valuable collection of p*rn holiday images. But it is a nightmare if it happens to the company's fileserver. Yes, there is a daily backup. Created during the previous night. In the worst case, you loose an entire work day of the entire company. Plus at least one day to restore the backup. At that point, the inventor of this really great software was very lucky to be far away from me.

Oh, by the way: The fileserver runs in a virtual machine. Imagine the "fun" if you can't shut down a VM host running several VMs. Imagine the "fun" if NUT can't cleanly shut down the VM host because the UPS battery is almost empty, and the f***ing init process can't receive the shutdown command. Imagine the "fun" to restore the VM host and all VMs running on that machine. A "fun" week of restoring backups, in the worst case. Plus nobody being able to work with those VMs.

My idea of fun is very different from that. That's why I prefer a small and stupid init. There is plenty of room for tons of features in the management processes started by init.

Alexander