Debian's Systemd Adoption Inspires Threat of Fork

New submitter Tsolias writes It appears that systemd is still a hot topic in the Debian community. As seen earlier today, there is a new movement shaping up against the adoption of systemd for the upcoming stable release [of Debian], Jessie. They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle. Note that the linked Debian Fork page specifically says that the anonymous developers behind it support a proposal to preserve options in init systems, rather than demanding the removal of systemd, and are not opposed to change per se. They just don't want other parts of the system to be wholly dependent on systemd. "We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs."

Comments

Re:its not a claim, its a fact of life.

[kthreadd]

This isnt a thought or a prediction, this is something systemd actually does when it takes NTP, console, logging, and networking and forces them into one application.

Except it's not. /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-timesyncd /usr/lib/systemd/systemd-networkd

My system is too old so I don't have the consoled on it, but I imagine that will be a separate daemon as well.

the fork threat is to be taken seriously because of the leaderships inability to actually recognize this as a massive security, scalability, and overall functionality problem that was steamrolled into debian largely at the behest of KDE and Gnome devs. The best solution to avoid a fork in my opinion is to give the user something thats also been forgotten about in the linux community: choice. Systemd or RC Init, or uselessd (a fork of systemd that tries to rehabilitate systemd)

That would of course be nice. But someone has to do the work. It's not like it's just a matter of flipping a bit and everything just works. You actually need to go in and make sure that stuff works with all of them.

Re:UNIX Philosophy

[armanox]

We've tried having standards in Linux before, and they were utterly ignored (Linux Standard Base). Basically, there is no reason for certain groups or developers (Red Hat (and to a lesser extent, Canonical) and developer-who-shall-not-be-named) to listen to everyone when they can do whatever they want and everyone else has to deal with it.

Re:Too late

[jedidiah]

> Systemd is deployed in real systems and these aren't crashing or suffering chronic problems.

Some people seem to be reporting this very thing. The cult of mindless progress just seems intent on ignoring everyone that isn't drinking the Kool-Aid.

A rather empty threat

[Peter H.S.]

There are +150 Debian forks (derivates) already, so yet another one hardly matters. The main reason why its is an empty "threat" is that there basically isn't any real development of needed infrastructure in the non-systemd camp, and as time goes by, more and more alternative development will be need by non-systemd distros.

The fork of systemd's "udev", "eudev", is basically just a shadow fork with patches, but soon eudev maintainers have to decide between having to support a kdbus manager, thereby become more developers instead of just patch maintainers, or their fork will deviate so much from the real udev, that they no longer just can leech new patches from it.

Of course, ConsoleKit is still dead with nobody picking up development, the only alternative is a rather limited implementation of systemd-logind, and is basically maintained by a Canonical developer who are unlikely to maintain it after Canonical have switched to systemd.

Stuff like root-less X.org can at the moment only be safely done by systemd. Some Wayland implementations will also depend on systemd simply because the upstream projects aren't getting any help at all in supporting non-systemd distros.

Even SysVinit isn't in such a hot state, it haven't made a release in five years, and the defacto upstream maintainers have been SUSE/Reed Hat for years. At some point they will drop maintaining it anymore.

I could go on, but the fact is that there is an increasing amount of work needed to be done, just in order to keep status quo somewhat, and that the non-systemd camp are severely lacking developers that could help maintaining such critical infrastructure.

It would actually be quite good for the non-systemd camp if there was a proper Debian fork that solely was about non-systemd developemnt. They have been lacking a focal point for such development for a long term stable distro for years (Slackware, despite its merits, is ultra conservative and probably too limited in certain ways for this).

The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.

Re:And this is why Linux will never win the deskto

[hansbogert]

Wait.. so you went to the websites of the software you wanted to have installed? Do you realize that most distro's have had a unified app-store way before OSX did? Talking about building.. I've had to build more software on my macbook then on my linux machines because OSX lacks a good package manager. Though macports & brew fill that gap somewhat, but the build times - the agony.

Don't forget you still have to update Windows

[rHBa]

Don't forget that once Windows is installed and you've installed all your drivers you then have to update it!

If I install a Linux distro that came out, let's say, 5 months ago I'd expect that to take about 30 mins on a slow ADSL connection.

If I install a version of Windows that's 5 months old I'd expect it to take most of the day if not some of the next day!

Having said that I'd never install a version of Windows that's 5 months old, instead I would install a version of Win7 with the latest service pack streamlined in and it would STILL TAKE A WHOLE FU**ING DAY.

Re:It's a bluff

[thaylin]

They dont have time to get into the politics, not the contribution.

Re:its not a claim, its a fact of life.

[nabsltd]

One might as well complain about all the basic utilities under the GNU project umbrella.

I can use ls without having to use info, but I can't use systemd-networkd without using systemd. Conversely, there is no logging system other than systemd-journald that works with systemd.

In other words, each individual program that makes up the "systemd brand" must all be installed and running or else none of them work. This is completely different from the current init system, which doesn't care which system logger (for example) you use, and doesn't even require you to use one at all.

So, even though the "systemd brand" is many separate applications, the net result is no different from one monolithic application with many shared libraries.

Re:Fedora fork too

[linuxrocks123]

All that proves is that Fedora's init scripts suck. I'll believe that.

Here's Slackware's rc.sendmail script:

#!/bin/sh
# Start/stop/restart sendmail.

# Start sendmail:
sendmail_start() {
    if [ -x /usr/sbin/sendmail ]; then
        echo "Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m" /usr/sbin/sendmail -L sm-mta -bd -q25m
        echo "Starting sendmail MSP queue runner: /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m" /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
    fi
}

# Stop sendmail:
sendmail_stop() {
    killall sendmail
}

# Restart sendmail:
sendmail_restart() {
    sendmail_stop
    sleep 1
    sendmail_start
}

case "$1" in
'start')
    sendmail_start ;;
'stop')
    sendmail_stop ;;
'restart')
    sendmail_restart ;;
*)
    echo "usage $0 start|stop|restart"
esac