Slashdot Mirror
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?
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?
As we've all learned from Apple: No half-assed shit. Do or don't do. No place for inbetween stuff.
systemd has downsided but it also has upsides. We should stick with the upsides and patch the downsides until they're basically a non-issue.
I don't do much init-fiddling although I do like the text based init/runlevel thing, and I would guess that plug-and-play - one of systemd's strong areas - should be a userspace problem, but that's just me not really know what's going on in the init process.
However, since all major distros have moved to systemd it can't be that bad as some people make it out to be. I trust the debian and ubuntu crew to know what they are doing at init-level.
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance. Seriously, who cares? It's mostly Linux left, right and center these days anyway. The BSD people will be fine with whatever they choose as init process, as usual, and no one gives a damn about other non-FOSS unixes anymore anyway. Unix basically is Linux these days.
But, as I said at the beginning: There is no use going systemd, but only kinda so-so. If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
My 0.5 eurocents.
We suffer more in our imagination than in reality. - Seneca
If you're allergic to trimming your neckbeard and running a modern init,
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
"First they came for the slanderers and i said nothing."
All of your questions are easily answered by reading the link provided at the top of the article:
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Why does the desktop care who's booted it up?
The Init System "We don't care. It doesn't affect us."
logind Allows KDE to provide user-switching features.
Device Management Allows KDE to have access to your mouse and keyboard without root access and without random applications being able to sniff your keystrokes.
Inhibitor Locks Allows KDE to react to notifications like "the system is about to go down" and delay until a condition is met (example: delay a suspend until the lock screen is displayed and all your desktop windows are hidden behind the lock screen).
timedated and Friends Allows KDE to set time and date without root; allows KDE apps to be notified if time and date gets changed. (KDE currently runs a daemon just to watch for time and date changes, and they would like to get rid of this daemon and simplify their code.)
User Units If KDE takes advantage of the "units" in systemd, then when any part of KDE crashes or hangs, systemd will restart the misbehaving part.
that implies they won't work on *BSD at all. Right?
"Projects like [SystemBSD] bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features."
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
I encourage you to read the whole article and see what big things you are missing.
I don't know about you, but when I read that article I didn't think "Man those KDE guys are idiots, why would they want any of that." It all makes sense to me.
It's easier for me to believe that SystemD has some merit than to believe that all the Debian core developers are idiots, plus all the Ubuntu developers, and now all the KDE developers and for that matter the Gnome developers.
My biggest concerns with systemd are the monoculture of it all, so projects like UselessD and SystemBSD sound great to me. Force the SystemD guys to document and justify everything, and provide alternatives.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Yeah and no. As pointed out in the article, the culprit is upower. But upower is mandatory for KDE power management. So it does not really matter whether it is Powerdevil that requires systemd or upower. ConsoleKit2 recently gained support? Was ConsoleKit2 actually been packaged? Does upower supporting ConsoleKit2 been packaged? If not, user experience wise, that is not palatable. And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd? Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not? If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative? Just as a reminder, ConsoleKit2 exists "because there isnâ(TM)t currently a standard for system actions like suspend/hibernate anymore. We use these features in Xfce and it would be nice to keep the session manager and power manager in sync (i.e. you inhibit something and the session manager doesnâ(TM)t see it). Obviously thereâ(TM)s systembsd in the works, so this is a stop gap until that matures (however long that may be). But Iâ(TM)ll happily continue to maintain and support ConsoleKit2 as long as someone finds it useful". https://erickoegel.wordpress.c... The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won't do. And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers. Hence the question: will KDE be still usable in 2016 without systemd.