It’s a new piece of software that’s tied to systemd. Existing software is unchanged.
> To avoid any confusion, it’s important to emphasize that the lack of PLM support on systemd-free Linux distributions or BSD systems does not mean you can’t use the KDE Plasma desktop environment there. Plasma itself remains fully usable on those platforms.
> In other words, for those users, the situation remains unchanged. On their systems, Plasma will continue to rely on SDDM or other platform-specific startup mechanisms, with no indication from KDE that PLM will be made portable beyond systemd environments.
But, once Firefox changes to Wayland only, that will lock out NetBSD and OpenBSD. I heard FreeBSD has some kind of support for Wayland, but that probably forced FreeBSD to import a lot of Linuxisms.
I get the impression OpenBSD will not bring in those Linux specific items and NetBSD already posted Wayland is to big a project for them to import at this point.
What's going to suck is that every major compositor +wlroots for the non-major ones is also going to need patches to use the BSD modesetting API - something that the BSD guys don't have direct control over and which is maybe a little out of their traditionalist(?) comfort zone.
Or are the BSDs simply going for a copy of the Linux KMS (kernel modesetting) API? Wouldn't be the worst idea, Linux finally seems to have something robust there after earlier attempts that were considered problematic.
> The focus of the KDE team is clear, as stated in the referenced Reddit thread, where a KDE developer replies that the goal is to rely on systemd for more tasks in the future. This means that PLM is just the first step.
https://hackaday.com/2026/02/02/kde-binds-itself-tightly-to-...
I mean, this is not exactly the most important issue in the world. I love KDE and hope it remains usable to me, but if things keep going as a fear, there are other DEs that I can live with.
The approach the KDE team took here is 100% the correct approach and, crucially, does not affect Plasma’s cross platform support at all.
This whole thing has been blown out of proportion by armchair critics commenting with made up hypotheticals without any of them reading what the actual change was. It’s ridiculous
So you can continue to use KDE Plasma on alternative init daemons / non-Linux OSs like before.
While PAM is a relatively straightforward system, interfacing with it and handling what it says is a bit backwards and complex (e.g.: Try to handle and relay LDAP password policy warnings to the user while in the login screen, and you'll have a fun time).
While I don't like systemd, I can understand why KDE devs want to integrate with it, esp. if doing so simplifies their life and reduces the number of edge cases.
Also, last but not the least, a KDE session is a complex beast. KDE overrides almost half of the environment it inherits to realize what the user has requested via System Settings (locales, esp.).
So this is why I don't condone, but understand what they did.
...and yes, as everyone said, KDE will work with any login manager.
A while back I lost a system because I had it configured with full disk encryption and pam_usb for totp-enhanced logins. A bugged update that I applied via pacman broke PAM and I lost my ability to login. This would have been just annoying and not catastrophic had I not also had FDE and forgotten where I stored my LUKS key.
Lesson learned.
I'd not label it such, but as "critical infrastructure". The problem in your case actually was not in PAM but in pacman. For example, apt and yum/dnf checks whether the checksum of the file being changed is different from the original (provided by the package). In standard configuration, apt asks what to do, dnf just puts the file with .rpmnew extension to prevent these kinds of problems.
pacman's "I don't care, this is the new file and I overwrite what I see" is very dangerous behavior.
ThAnkS rEd HaT, EU fUndS WelL SpEnT
It would be prudent to wait for an announcement or clarification from KDE leadership before assuming anything one way or the other.
- systemd: integration and features at the cost of complexity and scope
- traditional: simplicity and composability at the cost of boot speed and convenience
systemd conflicts against the more traditional unix philosophies as well as minimalism.
Historic reasons mostly come down to systemds developers being abrasive jerks to people. Systemd has some weird behavior choices that only really make sense from the perspective where every computer is a desktop; ie. it terminates all processes spawned by a user when logging out unless they were made in a specific way with systemd-run. This makes sense on a desktop - users log out, you want everything they did to be cleaned up. On a server it makes less sense, since you probably want a tmux/screen session to keep running when you sign out of your ssh session (either by choice as a monitoring tool, or alternatively because you have an unstable connection and need a persistent shell).
Every downstream distro got surprised by this change[1] and nowadays just ships a default configuration that turns it off, because upstream systemd developers weren't interested in hearing the complaints.
Most of these footguns have been ironed out over the years though.
There's also some really dumb arguments to dislike systemd, most of which just can be summarized as "people have an axe to grind with Lennart Poettering for some reason".
[0]: https://news.ycombinator.com/item?id=46794562
[1]: It was always available, but suddenly turned on by default in an update.
However, unlike PulseAudio, I've encountered few problems with systemd technically. I certainly dislike the scope creep and appreciate there are ideological differences and portability problems, but at least it works.
I'm not sure I'm missing anything.
Genuine use cases for multiuser desktop Linux are exceedingly rare. (Are university computer labs with desktop computers still a thing? Or is it just Wi-Fi and BYOD now?)
On an effectively-single-user system, there is very little point in distinguishing between the state where the single user has logged in and the session has been locked versus the state where the single user has not yet logged in. Dealing with the discontinuities between those two states, on the other hand, is a nightmare. (e.g. Wi-Fi might be controlled through the desktop session. Why should the computer not be connected to Wi-Fi and its network services reachable, just because the user hasn't logged in yet? What about power management? If the single user has turned off the feature to automatically suspend after x minutes of inactivity through KDE settings, why should that setting only start to apply after the user has logged in, and not yet when the greeter is still sitting idle? Those kinds of behaviours are usually not what you want) -- And, subjectively, I've found the KDE login manager to be the buggiest part of my KDE experience anyway.
I would advise anyone to set up auto login with something like sddm, and skip the whole thing. Password entry is a bit redundant, assuming the user has already entered at least one password for disk encryption, and things like ssh are governed through key pairs.
Not everyone is a rich american. People share computers.
Of course, people shouldn't be forced to bring or even have a laptop powerful enough for using during the classes or finishing their tasks.
nine_k•1h ago
ta988•1h ago
throwatdem12311•1h ago
arusahni•1h ago
nargek•1h ago
> FreeBSD users will still be able to boot into Plasma with any other login manager that works on FreeBSD, including SDDM, which is upstream from Plasma anyway.
> Linux users will just have one more option.
> Plasma has no hard systemd dependencies.
cf. https://floss.social/@kde/115933236466022060
fullstop•1h ago
mghackerlady•40m ago