Dissatifcation with systemd leads to fork of Debian

[TWPonKubuntu]

Don't know where with will lead but I'm going to keep watching...

https://devuan.org/

[SteveRiley]

The site begins:

Dear Init-Freedom lovers

Debian isn't forcing systemd on anyone. While it will become the default init system, sysv-init will remain in the repositories and people will be free to make the switch. Forks of Debian aren't necessary. Developers will be free to declare a dependency on a particular init system if they so choose (a recent general resultion to require packages to be init-agnostic failed), but how likely is that to happen?

[NickStone]

If your that frightened about systemd you can always try openRC

[dibl]

Debian isn't forcing systemd on anyone.

Right, and anyone who has been paying attention to the controversy knows that by now. I see the real reasons for this fork in the second paragraph:

"This exodus is ultimately being a relief for some of us and should lead to the creation a peaceful space for work we are well able to do."

It's the old story -- interpersonal conflict plus resentment of "rules" for the work -- " ... and do not intend to enforce the vexation hierarchy and bureaucracy ...".

Systemd is just the excuse.

[MoonRise]

Dibl.... +1 on that. The whole argument is quite silly. If they wanted to leave because of the conflict they so felt a part of then that is how they should state it.

[GreyGeek]

In the long run and advances made by Debian and the fork will result in a merger back into one or the other, with one of them eventually fading away. My bet is on Debian as the last man standing.

[SteveRiley]

Compare the elegance of the systemd service file for Sendmail:

[Unit]
Description=Sendmail Mail Transport Agent
After=syslog.target network.target
Conflicts=postfix.service exim.service
Wants=sm-client.service

[Service]
Type=forking
PIDFile=/run/sendmail.pid
Environment=SENDMAIL_OPTS=-q1h
EnvironmentFile=-/etc/sysconfig/sendmail
ExecStartPre=-/etc/mail/make
ExecStartPre=-/etc/mail/make aliases
ExecStart=/usr/sbin/sendmail -bd $SENDMAIL_OPTS $SENDMAIL_OPTARG

[Install]
WantedBy=multi-user.target
Also=sm-client.service

to the sysvinit script for Sendmail:

#!/bin/bash
#
# sendmail      This shell script takes care of starting and stopping
#               sendmail.
#
# chkconfig: 2345 80 30
# description: Sendmail is a Mail Transport Agent, which is the program \
#              that moves mail from one machine to another.
# processname: sendmail
# config: /etc/mail/sendmail.cf
# pidfile: /var/run/sendmail.pid

### BEGIN INIT INFO
# Provides: sendmail smtpdaemon $mail-transfer-agent
# Required-Start: $local_fs $network
# Required-Stop: $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop sendmail
# Description: sendmail is a Mail Transport Agent (MTA)
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
[ -f /etc/sysconfig/network ] && . /etc/sysconfig/network

# Source sendmail configureation.
if [ -f /etc/sysconfig/sendmail ]; then
    . /etc/sysconfig/sendmail
else
    DAEMON=no
    QUEUE=1h
fi
[ -z "$SMQUEUE" ] && SMQUEUE="$QUEUE"
[ -z "$SMQUEUE" ] && SMQUEUE=1h

# Check that we're a privileged user
[ `id -u` = 0 ] || exit 4

# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 1

[ -x /usr/sbin/sendmail ] || exit 5

prog="sendmail"

updateconf() {
    /etc/mail/make > /dev/null 2>&1
    if [ $? -eq 15 ]; then
	echo -n $"Package sendmail-cf is required to update configuration."
	warning
	echo
    fi
    /etc/mail/make aliases > /dev/null 2>&1
}

start() {
    # Start daemons.
    ret=0
    updateconf
    echo -n $"Starting $prog: "
    daemon /usr/sbin/sendmail $([ "x$DAEMON" = xyes ] && echo -bd) \
	$([ -n "$QUEUE" ] && echo -q$QUEUE) $SENDMAIL_OPTARG
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sendmail
    let ret+=$RETVAL

    if [ ! -f /var/run/sm-client.pid ]; then
	echo -n $"Starting sm-client: "
	touch /var/run/sm-client.pid
	chown smmsp:smmsp /var/run/sm-client.pid
	if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then
	    /sbin/restorecon /var/run/sm-client.pid
	fi
	daemon --check sm-client /usr/sbin/sendmail -L sm-msp-queue -Ac \
	    -q$SMQUEUE $SENDMAIL_OPTARG
	RETVAL=$?
	echo
	[ $RETVAL -eq 0 ] && touch /var/lock/subsys/sm-client
	let ret+=$RETVAL
    fi

    [ $ret -eq 0 ] && return 0 || return 1
}

stop() {
    # Stop daemons.
    if [ -f /var/run/sm-client.pid ]; then
	echo -n $"Shutting down sm-client: "
	killproc sm-client
	RETVAL=$?
	echo
	[ $RETVAL -eq 0 ] && rm -f /var/run/sm-client.pid
	[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sm-client
    fi
    echo -n $"Shutting down $prog: "
    killproc sendmail
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sendmail
    return $RETVAL
}

status -p /var/run/sendmail.pid >/dev/null || status -p /var/run/sm-client.pid >/dev/null
running=$?

# See how we were called.
case "$1" in
    start)
	[ $running -eq 0 ] && exit 0
	start
	RETVAL=$?
	;;
    stop)
	[ $running -eq 0 ] || exit 0
	stop
	RETVAL=$?
	;;
    restart|force-reload)
	stop
	start
	RETVAL=$?
	;;
    condrestart|try-restart)
	[ $running -eq 0 ] || exit 0
	stop
	start
	RETVAL=$?
	;;
    status)
	echo -n sendmail; status -p /var/run/sendmail.pid -l sendmail
	RETVAL=$?
	echo -n sm-client; status -p /var/run/sm-client.pid -l sm-client
	[ $RETVAL -eq 0 ] && RETVAL=$?
	;;
    *)
	echo $"Usage: $0 {start|stop|restart|condrestart|status}"
	RETVAL=2
esac

exit $RETVAL

Sure, there's a learning curve for people used to the old ways. But systemd will greatly simplify maintenance and bring all distros closer to a common method of operation. Who really wants to maintain all that sysv cruft, ugh!

[Feathers McGraw]

That's a great example Steve, what a contrast!!

I think the post in this thread explained the major issues well (it's linked from the arch wiki):

https://bbs.archlinux.org/viewtopic....49530#p1149530

I've heard lots of complaining about systemd on soylentnews and /. but it seems most of the complaints are based on misunderstandings, or the parts of systemd that are optional anyway!

Having made plenty of configuration errors that affected the security of my system, I think simplifying init scripts will probably be good for security, assuming systemd itself isn't full of holes!

[kubicle]

My bet is on Debian as the last man standing.

That's a good bet, considering the fact that debian is a succesful software project, and the fork being 2.5 people capable of putting up a web site with big fonts.