Hacker News Reader

Comment by qznc | Hacker News Reader

How does forking Debian solve anything?

The issue is that Gnome, KDE, and other software requires systemd. You need to fix/maintain their compatibility with other init systems. Then it is easy for Debian user to switch init systems.

View on HN

> The issue is that Gnome, KDE, and other software requires systemd.

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
    ...

These and similar tools (or libc functions) give you all information you need (username, etc.) and system functions a desktop environment needs (reboot, hibernate). You then only need something like udev for plug-and-play (which is available without systemd, and as a part of it), and interfaces to the X/Wayland server and the audio system (which are both not a part of systemd). This seems to be all stuff that can easily be abstracted away in one module per OS. I don't see why you have to tightly couple your DE to systemd. (Unless, you are using your DE as a vehicle to push systemd, which I hope is not the case...)

Systemd provides interfaces to reboot/shutdown as non root api which is controlled by polkit. It also allows a non root process running as part of an active session to get the DRM FD and other device FDs as part of the logind interface.

I feel that the only reason Gnome needs SystemD is because RedHat said so. I honestly think making a DE require a specific init system is silly.

Modern DE's also depend on logind. Which could be replaced with non systemd implementation that has same interface on dbus.

To give people some idea of how practical a non-systemd implementation of logind's dbus API is, here's the documentation for it: http://www.freedesktop.org/wiki/Software/systemd/logind/

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.

Please read these posts by David Herrmann to get an idea of the improvements in reliability that systemd-logind provides to desktops:

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...

This I can't wrap my head around, why does Gnome for example need systemd?

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.

You listed two desktop environments, neither of which are of interest to sysadmins.

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.

The idea of a server based fork of Debian is kind of appealing in some ways, like the Fedora server and cloud projects[1][2] which are quite interesting work, aimed at a (sub)distribution with focus on particular use cases, not the kitchen sink approach.

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

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

"The idea of a server based fork of Debian"

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.

I'm in a similar position with regard to those (or any) desktop features not being relevant for most of the systems I administer.

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.

I am almost the same as you except:

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.

"You'll be fighting against ... the default of every bit of third party software targeted at your distro."

Postgres and Apache? Seriously?

Probably not software like Apache and Postgres, no.

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.

KDE doesn't require systemd. The KDE folks are still concerned about operating on the BSDs. Some of them are still concerned about running on Windows [0] and OS X [1].

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...

You can also chose to ditch them and not support anything that requires systemd.

Yes, really.

Good luck getting any adoption that keeps maintainers interested.

Reply on news.ycombinator.com