I'm pretty sure that ConsoleKit2 and elogind can coexist. I was toying with Wayland-1.16/Weston some time ago and was just building elogind to satisfy the dependency.

2 members found this post helpful.

What value do you imagine there is in such a condescending and inaccurate statement? Yes there has been some worries over little or nothing details but "Feature Creep" and "Exclusivity" are not mere Myth. It seems to me we are all better off without FUD and sticking to Logic and Reason instead of politicizing every damned thing. How else can we weigh both sides of an issue?

5 members found this post helpful.

MyLQ -> Edit Ignore List

3 members found this post helpful.

THX skaendo I was looking for that

@volkerdi has answered though. He has said it's not a question of if, but when. That is all we need to know. End of debate. I mean, we can still argue the merits of including Plasma5 just for the sake of it, which is kind of amusing in and of itself, but we have our answer as far as I'm concerned.

2 members found this post helpful.

Since I have ZhaoLin1457 in my ignore list, I only read his comments if they are quoted.

In this case, I have to say: there's nothing evil about elogind. It's exactly like eudev which is already part of Slackware: a useful piece of code extracted from systemd and modified to be independent of systemd.

Yes, the Wayland compositor of KDE's window manager KWin depends on the presence of the login1 D-Bus service. This is provided by elogind, and it is partly also provided by ConsoleKit2. Eric Koegel's intention is to add full login1 API compatibility to ConsoleKit2 but even when that happens, the programs that want a "login1" service will look for that string and not for "ConsoleKit2". Eric Koegel did not seem fond of the idea of calling his CK2 dbus-service "login1" so it will have to be "the other programs" like SDDM which have to add ConsoleKit2 as an alternative implementation of the login1 API.
Support for CK2 as alternative to systemd-logind or elogind was added to KWin long ago, see https://cgit.kde.org/kwin.git/commit...86016aadbbf18f

5 members found this post helpful.

I liked KDE3, and I was sceptical of KDE4, but then I liked it, and I was worried about KDE5, but then I liked it. KDe5/Plasma5 is great actually. KDE5 is better than KDE4 which is better than KDE3, but I like them all. I don't think we need to talk too much about KDE5 at this time, it's been mature for a long time, is very stable and for a full desktop does not clog resources.

The big question is when is KDE6 approaching and how will that be? KDE5 is more modular than KDE4, and if this progression continues, I think with KDE6 we can have anything from a Window Manager to a full desktop environment available to us as we please.

The question of timing and how long Slackware will then stick with KDE5 when KDE6 is released is more relevant, and what version of KDE then is the better match for Slackware.

Thank you, Eric. It appears I may have jumped the gun and assumed he was referring to the whole systemd "deal" not just elogind. I'm probably a tad "gun shy" after my attempt at a reasonable and discussion on systemd in another thread.

+1 to no.

KDE Plasma is a great DE and doesn't rely on systemd.

2 members found this post helpful.

Programs should be looking for things that implement the interface(s) that they desire to use. That's the way DBus is supposed to work.

(I know: If fish had feet, they'd be mice.)

I don't use DE's anyway. I'm wedded to Fluxbox.

I remember back in the day I liked Blackbox. I guess if I went back in that direction it would be openbox or fluxbox which would be most natural? Meanwhile I am overly comfortable with a full desktop environment. Sometimes I use Enlightenment as well.

Anyways, good thing is that we still have choice in the GNU/Linux world. With Windows it's take it or leave it approach bundle. I actually like the Slackware installer alot in this regard.

Nearly same(?). i3wm all the way for me.

My problem with using a WM instead of a DE is that I end up spending so much time tinkering with it to make it look at behave "perfect" that I end up not getting much else done. But I agree, having a choice is great.

One aspect, not discussed, is that any included KDE leaves "stable" users eventually hanging in the wind and exposed to security issues, as has been the case for the last two years when KDE stopped support for KDE4. Pat rightly determined his focus is on Linux core libraries and applications, not on all the office. security, network, games, and other apps we choose to use (the beauty of Linux choice). Derivatives of Slackware offer specific apps, added libraries and even window managers. Slackbuilds.org, with many contributors, offers apps, libraries and window managers (LXDE, Lumina, E, LXQT) not included in the Slackware base. Other core Slackware team members focus on DE's and libraries, in their own repositories, which require extensive rebuilds or modifications of the core Slackware platform. Eric chose to focus on KDE Frameworks and Plasma, but that development eventually out grew support available in stable. So stable's KDE4 became stale and open to security issues.

How does Pat add KDE to the next release of stable and not end up with the same KDE development outgrowing the Slackware base issue? I don't' think it is possible. Pat has no way to know what direction the KDE Developers might navigate to KDE6. The only sane answer is to continue to focus Slackware as a base and let users extend that base with the packages useful for them.

For my configuration that means not even installing KDE4 or it's outdated applications. I've found replacements on Slackbuilds.org for KDE apps. It would be wonderful if these alternate basic GUI applications to the KDE suite, which can work in any window manager, were included to make Slackware more complete. KDE can be dropped from the Slackware core and instead come from a separate repository, as -current users do today from Eric's KTOWN. Pat is focusing on a base that gives a robust Linux system which can be extended. Other repositories offer extensions of the base that let users have a Linux system the way they desire. But if a users wants to be on stable with few regular updates they'll may again be stuck with KDE5, no KDE Developers support, lack of alternative X window apps usable in any window manager, and potential security issues that are beyond Pat's support ability without major rebuilds of what is published as stable.

My fear is that including KDE5 will again be stuck when the KDE developers move on to KDE6. For users of -current this may not be an issue. For users of stable it is an issue. Is there a flaw in my logic or comments. Let me hear them. Cheers, BrianA_MN

2 members found this post helpful.