Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?

New submitter yeupou writes: Early this year, David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit". A perfectly sensible explanation. But, then, one might wonder to which point KDE would remain usable without systemd?

Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the "Debian fork" I'm using to "ripe out" systemd without "coming with any of the supported solutions Plasma provides". I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.

While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit". So, is it likely that we'll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?

Comments

Re:Duh

[phantomfive]

So now there's no Gnome or KDE on anything but Linux.

That is Lennart's plan. Here's what he says::

"I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore."

Without Systemd Wiki

[dissy]

Without Systemd Wiki: http://without-systemd.org/wik...

Much todo about zip--ConsoleKit2 is also supported

[FreeUser]

Sigh.

First, only an idiot would want a monoculture, particularly in the Linux world, so to those saying "just to systemd full bore or go to (someplace else)" the rest of us need to respond with a very loud and resounding: Fuck You.

That said, things aren't nearly as dire as this post implies. Reading from the responses to the bug he himself linked to, I find the following:

> Unless KDE is prepared to make a statement that it depends on systemd

of course not. Powerdevil recently also gained support for ConsoleKit2, see: http://commits.kde.org/powerde...

Which turns it into a distro problem. Your distribution configured the system in a way that suspend/hibernate is broken. It doesn't come with any of the supported solutions Plasma provides. Which makes it a distro problem. The distro integrates various parts of the software stack. This includes it's the distro's task to ensure that components work together. It failed here by ripping out systemd and replace it with well nothing.

So while I'm sure the systemd zealots would love to see KDE, Gnome3, etc. only work with systemd and drop support for all other distros, this doesn't appear to be happening. In the case of KDE, ConsoleKit2 is supported (and therefor Funtoo, Gentoo, Arch with OpenRC, etc. will continue to work just fine).

Re:yes

[Anonymous Coward]

Systemd is not (supposed to be) part of the desktop environment either, it's supposed to manage starting system daemons like sshd, httpd, dhcp, networking services, access to your keyboard, graphics management, and many other things that a system daemon starting utility has no business being involved in. The problem is that a large number of current required services are no longer properly maintaining their "non systemd" startup config and code, and are instead relying on the half-baked garbage that is systemd. Anyone who disagrees with the switch to systemd is then countered with social pressure and "get with the modern world, loser!" type arguments, rather than actual technical reasons, since for the most part, there aren't any. (Cue systemd fans giving reasons like "if it wasn't good, then nobody would be using it! Everyone else is doing it, get with the modern world loser!" now...)

Re:Yeah

[Anonymous Coward]

svchost.exe isn't analogous to systemd.

scm.exe is the windows equivalent to systemd. The Service Control Manager (scm.exe) is a process that starts during the boot sequence, shortly before control is handed off to the login and desktop manager process (lsass.exe). Windows' boot process goes from loader (ntldr) to kernel (ntoskrnl) to session manager (smss) to service control manager (scm) to Winlogon. Everything you interact with in Windows is hosted by the Winlogon process. The only exception to this is the services.msc control panel snap-in, which allows you to very indirectly poke at scm.exe.

svchost.exe is a wrapper host that handles service events for applications that don't behave like services. All Windows services must respond in a timely fashion to requests to start, stop, restart, pause, continue, and a few other events. If a process doesn't handle these, they can still be run as a service by running them inside the Service Host process.

Re:OpenRC forever!

[Anonymous Coward]

I don't understand this. If systemd is so backwards compatible with the traditional way of doing stuff, why don't distros enable that?

Erm, some do. Debian forwards everything to syslog and throws away the journal by default.