Q: Does the Plasma Login Manager require systemd to work?
A: Yes.
Q: So you ARE forcing Plasma users to use systemd!!?!?!
A: No. The Plasma Login Manager is one of probably half a dozen Login Managers (or more) that can boot Plasma. We made PLM because it will give distro creators a cool piece of kit that can (not “must”, not “should”: can) be tacked onto a system to boot into Plasma.
Q: So I don’t have to use PLM?
A: No! You can completely ignore PLM! Please be our guest and use any of the other non-systemd dependent LMs that will work and continue to work just fine, now and in the future.
Q: Is KDE planning on making any of Plasma’s core components dependent on systemd?
A: No.
Q: So Plasma does not and will not require systemd to work now or in the future?
A: That is correct.
Q: And it will continue to work on non-Linux systems like FreeBSD?
A: Also correct.
Q: Why have I been hearing that KDE will force systemd down everybody’s throats via Plasma then?
A: There are sad people who will do anything for attention and clicks, and will spread FUD and fake controversies to obtain them, including decontextualising comments on merge requests, stating as facts and official communications what are personal opinions, and finally straight up lying.
I would even be surprised if plasma-login-manager really has a dependency on systemd.
It is just much more likely that requires that certain setup steps have been taken care of externally and that come D-Bus interfaces are available.
In such cases the most convenient or readily-available solution could be the systemd eco-system with other approaches becoming viable after additional testing.
For example many login managers use the D-Bus interface initially introduced by systemd-logind which has since then also been provided by elogind and other alternatives.
which are coming soon, reducing PLM backend to very little.
The longer term plans is to move the abstraction layer slightly higher rather than in the backend and holding us back.
I had PLM-greeter running against greetd at some point, it’s trivial, probably in the history somewhere. My longer term plan is to push the frontend back up to plasma-workspace with the abstraction there.
What feature of systemd was necessary to make it a hard dependency on the Plasma Login manager? Do other init systems not offer this feature? Would it be possible to abstract away this feature in the future so that it’s not a hard dependency anymore?
See David’s post earlier.
The first link has a list of things a login manager needs to do and then goes into how most of these can be delegated.
It is likely less a matter of init system and more what the respective service manager, etc can do. I.e. the processes that implement the D-Bus interfaces (or equivalent of) of logind and so on.
See the first point in the ticket David linked to:
* Find free ttys and configure them
Logind is already tracking all of this.
Yes, quite possibly.
The alternative eco-system, e.g. elogind, just needs to be capable of delivering the same or compatible features.
Thank, it makes sense. I’m a systemd user myself but I’m all for choice and it’s great to hear that there’s a path forward for other init systems to support it.
I’m a systemd user myself, not by choice, just the default that my distro of choice uses. I am actually pretty excited for the Plasma login manager because I find SDDM and other login managers rather clunky, and I think unifying the login manager with KDE would solve some issues I have.
I think it would be a shame if non-systemd users can’t use it because they simply choose not to use systemd, many of them have legitimate reasons not to use it.
and it’s great to hear that there’s a path forward for other init systems to support it.
But it seems like doing double the work, no? If SDDM is the base for both login managers, a systmd dependant one and non-systemd dependand one, just improve SDDM, instead of retroconning Plasma Login Manager.
I don’t know, I am not a dev, and I was advised by developers for the original FAQ.
I have not consulted with a dev for this, so maybe it is a dumb idea…
Well, only it’s not true, unfortunately. I can no longer have krdp without systemd on the current Gentoo ebuild kde-plasma/plasma-meta-6.6.0-r1. Let’s hope it’s a packaging bug only.
!!! The ebuild selected to satisfy "kde-plasma/plasma-meta" has unmet requirements.
- kde-plasma/plasma-meta-6.6.0-r1::gentoo USE="X bluetooth browser-integration crash-handler crypt cups display-manager elogind gt
k kwallet networkmanager pulseaudio rdp sddm smart wallpapers -accessibility -discover (-firewall) -flatpak -grub -ocr -oxygen-the
me -plymouth (-qt5) -sdk (-systemd) -thunderbolt -unsupported -virtualkeyboard -wacom -webengine" ABI_X86="(64)"
The following REQUIRED_USE flag constraints are unsatisfied:
rdp? ( systemd )
You will be happy to learn the hard dependency of systemd in kdrp issue got fixed recently:
Regarding kinfocenter dependency on vulkan. That should be optional, we all agree, especially for an application that is here to just tell you your system state.
There is even a patch, that could be the base to be upstreamed but no-one has done so, so far:
Unconventional configuration need some their users to get involved, like for BSD for instance. Those will always be under-tested by the mass and you can’t expect the small KDE community to tackle all of the portability issues. Still reasonable patches are welcome.
Except we were not lying. krdp is far from being a core component in Plasma and you can run Plasma perfectly without it. Like the Plasma Login Manager, it is just a nice thing to have if you need it.
If Gentoo requires it, that is a packaging bug on their behalf.
Well, I am sorry, Paul, but that is precisely the attitude and stance that is being criticized lately.
I can live without kMines (for example), because that’s not a core feature and has alternatives. Krdp does not. Whether one can access their desktop remotely or not is a pretty core question when choosing a DE. If you think that’s a “non-core” or niche feature, you don’t understand the needs of your users.
No, unlike the Plasma Login Manager, it’s the only thing that provides RDP access, and if you need that, you need that. So, are you seriously suggesting that we’ll (or should be) be faced with the choice between switching to systemd or having RDP?
Let’s set this straight: I never accused you of lying, especially not on your motivation or planning. “Well, only it’s not true, unfortunately” wasn’t referring to your intentions, but whether there was such a dependency outside of the PDM. I pointed out that there was a dependency from a core component (plasma-meta “represents” basically all of KDE on Genntoo), on systemd on my distro. Which was quite shocking. In fact I haven’t read/heard anything regarding this, I hit this thread researching why I couldn’t build KDE without systemd anymore, which was simply my “user experience” when I posted. So from my point of view, I wasn’t “lying” either.
Later on, this fine forum wouldn’t let me post (or edit a post I made), because “new users” can only post 3 replies (and it only tells you that, when you try to save. Yay!). That won’t really help in converting new users to recurring users. Since you made the mistake to reply, I got three more, HARHAR…
I was about to say:
I’ve since informed downstream at Gentoo #970981. (I can’t post links either. Weird to be feared.)
I’m happy to agree to disagree whether RDP support is a niche feature of a desktop environment. I doubt your 99.999% number, but OK, hyperbole is fine, I do the same. In times of home office and remote work this feature is essential (read: “core”) to some. What’s core and what isn’t has got nothing to do with how many people (or what percentage of users) use it, but whether those that depend on it have alternatives. Or whether the thing builds without it. Or if the thing needs to reach into the guts of the DE, such as the graphics stack and HID I/O. There are a ton of things on a Linux system many users never see, need or even know about, but they’d still be considered core. But oh well, I won’t convince you…
But with you not lying twice, I’ll take your word for it.
