It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle.

I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time.

If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.

> I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time.

Well said. I'd add that "service" is actually doubly confusing because the command was IIRC actually introduced by Ubuntu when they were doing Upstart, which was their own attempt an an init replacement. Ubuntu still has the service command, actually, and now it supposedly runs both init scripts and systemd units. I've never actually tried it because I'm rather spooked by having multiple mechanisms to activate a service. It still mostly has the upstart command syntax from what I can recall.

My Ubuntu server actually has a Upstart service file from one of the daemons I have installed, I only hope it's not somehow being activated or translated into an init script by some compatibility system Ubuntu has built in.

You might even be talking about RHEL 6, in which they used Upstart, and not whatever they're doing now. RHEL 6 is still under extended support, which means that there are still quite a lot of Upstart systems out there.

I was actually talking about RHEL 7, which uses systemd. When you type "service foo restart", it redirects to "systemctl restart foo.service" and prints a message saying so. It's a nice way to nudge people to use the new command without being obtuse, redundant, or confusing.

In fact, init scripts are only used by systemd when there are no corresponding native unit files.

A lot of debian packages supply both systemd unit files and init scripts. You can use either to step on the other's foot.

As I said, init scripts are only used if there's no unit file. If there's a systemd unit, the init script is ignored.

If there's a systemd unit, the init script is redundant, confusing, and possibly dangerous. It should not exist in the first place, perhaps except as a thin wrapper around the corresponding systemd command.

If you invoke the init script on a system booted with systems then it does indeed wrap the equivalent systemctl command.

If the package maintainer wants to support systemd-less systems out there, I don't see a reason to not let them to.

Having that support come in the form of installing both on all systems does have its downsides though.

OTOH, I wouldn't be surprised if every other feasible approach's downsides are widely regarded to be worse.

Software. Yay :D

Gentoo seems to manage.