This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):

    shutdown
    reboot
    whoami
    uname
    mount
    ...

Here's a good summary of the issue: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...

A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.

But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.

It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.

http://dvdhrm.wordpress.com/2013/08/24/session-management-on...

http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-work...

http://dvdhrm.wordpress.com/2013/08/25/sane-session-switchin...

Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.

I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.

More than that though, is the fact that it's going to be the new default everywhere. So while you say

I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.

I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.

So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.

1) No desktop features are of any interest to me.

2) My position is between "that sucks" and "ambivalent"

But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.

Postgres and Apache? Seriously?

But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.

[1] http://fedoraproject.org/wiki/Server/Product_Requirements_Do...

[2] https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD

I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).

If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.

Elias Probst:

"Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal [to use systemd features to make Plasma startup under Wayland a little bit simpler]:

* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for [BSDs]. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.

* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it."

via: https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/GMtZr...

[0] http://mail.kde.org/pipermail/kde-windows/2014-October/threa... [1] http://mail.kde.org/pipermail/kde-mac/2014-October/thread.ht...

Yes, really.