KDE's new Plasma Login Manager is tightly bound to systemd(forums.freebsd.org)
forums.freebsd.org
KDE's new Plasma Login Manager is tightly bound to systemd
https://forums.FreeBSD.org/threads/kde-plasma-login-manager-wont-support-systemd-free-linux-or-bsd-systems.101393/
82 comments
Plasma Login Manager was how the KDE developers planned to support remote Wayland sessions. And they will remove X11 sessions. Someone will have to add VNC and RDP to SDDM? Or is there another way?
However it does look as though KDE will depend on systemd more in the future. In which case it will gradually drop support for BSDs and Linux distros without systemd.
FWIW, I tend to think eventually everything will. But I am more worried about Wayland than systemd for the *BSDs. AFAIK, all systemd does is start items KDE needs, so with some work I think workarounds can be created.
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.
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.
Wayland needs... I think some EGL stuff to create OpenGL or Vulkan contexts in Wayland apps and a kernel API for graphics modesetting (resolution and refresh rate + misc related stuff). Also input support in libinput. Modesetting is perhaps the biggest piece of work, but I dare say not a huge one compared to having drivers for modern GPUs in the first place.
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.
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.
FreeBSDs Wayland support is pretty good, it supports Plasma perfectly and most wlroots based compositors. OpenBSD is more experimental, I know Sway (and presumably other simple wlroots based compositors) work alright but I wouldn't hold my breath for KDE support. I haven't heard anything from NetBSD or DragonflyBSD
OpenBSD is working on Wayland support. They aren’t doctrinally opposed to it, they just want to implement it properly according to their standards. They are having to implement their own equivalents to udev etc to make it work.
I agree, Wayland is a much larger problem.
Unlikely, KDE has well-respected developers who have been around forever who run and maintain it on BSD. No one would tell these guys to pound sand for the minor convenience that systemd brings. IMO, KDE developers (I'm a mostly inactive one myself) are generally too eager to rely systemd, but they aren't extremist about it.
Thanks, that is reasuring. It was the comment by the supposed KDE developer on the reddit thread not vlabout leaning more on systemd that worried me. I thought it would have been called out here or on forum thread if wrong.
I don't oppose leaning on systemd for small non essential things like this, especially if there's an easy replacement for non systemd systems
Graphical login managers are just a nightmare altogether.
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.
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.
> Are university computer labs with desktop computers still a thing?
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.
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.
> 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?
These were reasons GDM integrated GNOME components and KDE forked SDDM to PLM.
These were reasons GDM integrated GNOME components and KDE forked SDDM to PLM.
> 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?)
When I was a student in 2015, we had several computer labs. One was called the Delphinium because it was populated with Dell machines running Linux, and another was called the Orchard because it was full of iMacs. There was a lab of Windows machines too which didn't have a memorable name.
When I was a student in 2015, we had several computer labs. One was called the Delphinium because it was populated with Dell machines running Linux, and another was called the Orchard because it was full of iMacs. There was a lab of Windows machines too which didn't have a memorable name.
> Genuine use cases for multiuser desktop Linux are exceedingly rare.
Not everyone is a rich american. People share computers.
Not everyone is a rich american. People share computers.
I think there is a fundamental misunderstanding here.
A multiuser system is a system where multiple users are logged in at the same time and ussing the computer.
So a multi-user desktop Linux would be a computer where multiple people are logged in each with their own desktop session on the same machine.
That was the way unix was first used, a big computer somewhere with multiple client terminals connected to it all doing their own thing. This is the environment x11 came about as well.
Nowadays even if the computer is shared by multiple people each with their own account only one of them is using it at a time.
A multiuser system is a system where multiple users are logged in at the same time and ussing the computer.
So a multi-user desktop Linux would be a computer where multiple people are logged in each with their own desktop session on the same machine.
That was the way unix was first used, a big computer somewhere with multiple client terminals connected to it all doing their own thing. This is the environment x11 came about as well.
Nowadays even if the computer is shared by multiple people each with their own account only one of them is using it at a time.
No. gyulai complained of graphical login managers and advised to set up automatic login. Multiple users sharing a computer with their own accounts would use the login manager for account selection.
I even am a well-off American and i share one of my computers
Putting Linux on dumpster-find computers is a hobby for some rich Americans. They'd be happy to hand those out to the poor and needy who, however, wouldn't be caught dead with one of those. Because, sporting the latest iPhone at all times is part of the reason they're poor. -- The world is a complicated place, man.
...let me rephrase that. I frequently am quite surprised by how poor some people are who still manage to sport the latest iPhone at all times. Conversely, a small amount of money or even no money at all and a dumpster find will get you surprisingly far, when it comes to having your basic computational needs met. The world is more complicated than a bunch of stereotypes. "Someone who thinks of sharing of computers as rare, must be rich and conceited" is not a good model of the world. "Someone who is poor must be spending too much money on iPhones" is not a good model of the world either. (One reading of what I wrote would be this, but it's not what I meant to imply).
You shouldn't assume that someone with the disk password is entitled to the user's data. That's kinda a fundamental separation. Your home directory should be encrypted separately from the disk anyway
Universities have computer labs. Companies have shared computers. Households have shared computers.
I am willing to downgrade my statement “exceedingly rare” to “relatively rare”. It is certainly exceedingly rare in my sphere of experience. The last time I worked for a company that had shared computers was 16 years ago. This was on a trading floor set up for compliance. And they were in the process of phasing that out and making the computers on the trading floor just dumb terminals for Windows terminal server. So the desktops, themselves, ceased to be multi-user because they only ran the terminal server client, and it didn't matter which user that ran under.
After that, the only setup I've ever known was company-issued single-user laptops, and rarely BYOD. Company-issued single-user laptops are also what is used by all my friends and colleagues, where I have knowledge of such things.
With that said: The multi-user model is pretty broken on modern desktop Linux anyway, if you only look at how much stuff goes in $HOME these days, including software installed through flatpaks, configuration, even configuration with system-wide effects like power management and network, etc.
After that, the only setup I've ever known was company-issued single-user laptops, and rarely BYOD. Company-issued single-user laptops are also what is used by all my friends and colleagues, where I have knowledge of such things.
With that said: The multi-user model is pretty broken on modern desktop Linux anyway, if you only look at how much stuff goes in $HOME these days, including software installed through flatpaks, configuration, even configuration with system-wide effects like power management and network, etc.
Many companies issue laptops. But even some of them have shared computers in meeting rooms or connected to equipment. Single user laptops are rare in medical facilities, banks, call centers, and many other places in my experience. Many shared desktops could be replaced by virtual desktop infrastructure theoretically. But this would cost more in many cases.
My network configuration is in /etc. Flatpak applications can be installed for system or user. And users able to install applications for themselves does not make the multi user model broken.
My network configuration is in /etc. Flatpak applications can be installed for system or user. And users able to install applications for themselves does not make the multi user model broken.
> Households have shared computers.
I have about five Fedora desktops running in my house that I share with my partners. Domain-style logins are handled by FreeIPA. Basic login with the KDE Fedora spin works great.
I've been meaning to set up auto-mounting network shares and such, but haven't gotten around to it; but the login management is very convenient and we use every day.
I have about five Fedora desktops running in my house that I share with my partners. Domain-style logins are handled by FreeIPA. Basic login with the KDE Fedora spin works great.
I've been meaning to set up auto-mounting network shares and such, but haven't gotten around to it; but the login management is very convenient and we use every day.
Can KDE function without it, using e.g. lightdm? If so, not a big deal.
> We are not sure where you folks are getting your info, but it is dead wrong.
> 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
> 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
Yes. You can also continue to use SDDM.
SDDM will keep working, and KDE maintains a LightDM greeter. You don't even need to use a login manager, most people in the BSD space launch it from the tty
You mean people still log into a virtual terminal and call startx? (blushing emoji)
I mean, if that's the way they like it, that's fine. It feels a bit quaint, though, at least to me. If a graphical desktop is what I want anyway, why not make it automatic? I'm not judging, just trying to understand.
I mean, if that's the way they like it, that's fine. It feels a bit quaint, though, at least to me. If a graphical desktop is what I want anyway, why not make it automatic? I'm not judging, just trying to understand.
I know a lot of arch users that do that, especially if they just use simple window managers like i3 or window maker. Though, on a wayland system startx doesn't work, each compositor has its own command
Huh. If you go through the hazing of installing arch without that new installation script, it is consistent, I suppose. One thing in favor of this approach, is that it is very straightforward.
Not what I'd choose, but I think that is the beauty of the whole free software movement - one thing you get in utter abundance is choice.
Not what I'd choose, but I think that is the beauty of the whole free software movement - one thing you get in utter abundance is choice.
It can. For now, at least.
it can yes
Can someone explain why SystemD was controversial in the first place? I just saw faster boot times when distros adopted it.
Scope creep, violation of the Unix philosophy, large attack surface area, second system syndrome, interoperability concerns. It didn’t help that the creator’s other well-known project, PulseAudio, was also controversial at the time, for similar reasons.
PulseAudio, when it came out, was utterly broken. It was clearly written by someone with little experience in
low-latency audio, and it was as if the only use case was bluetooth music streaming and nothing else. Systemd being from the same author made me heavily averse to it.
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.
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.
Wrote about present day reasons to dislike systemd a few days ago on HN, which encompasses most arguments of actual substance[0] (tldr: Unix philosophy, it homogenizes distros and it may be too heavy for some low-resource environments).
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.
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.
To over-simplify, it's about conflicting philosophical alignment:
- 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.
- 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.
systemd also replaces some pre-existing services with its own reimplementations that are worse. The systemd developers aren't e.g. DNS or NTP experts, but they act like it and the results reflect all that.
[deleted]
You are correct. My comment was over simplified deliberately. I felt integration and scope accounted for the details in a TL;DR one slide answer.
I worked on both Linux login process, SDDM and LightDM in the past. The process is complex to put it mildly.
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.
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.
PAM is indeed a minefield.
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.
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.
> PAM is indeed a minefield.
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.
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.
Even configuring PAM to get what I wanted to begin with was somewhat of an ordeal and took a few tries where I locked myself out of the system as I was building it before I eventually got it right.
Also my problem wasn't really pacman either. It was full disk encryption.
Also my problem wasn't really pacman either. It was full disk encryption.
Understanding how PAM works is a source of confusion, and the documentation is almost non-existent and tribal. That part is very true.
But, after understanding it once, I found the process very intuitive and logical, to be honest.
But, after understanding it once, I found the process very intuitive and logical, to be honest.
pacman puts `.pacnew` files just like RPM does.
Pacman does check for changes in configuration files, and adds .pacnew files instead of overwriting them:
https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave
https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave
[deleted]
Gentoo already has elogind which mimics the necessary systemd facilities... surely that could be used on other distros/OSes to support PLM as well.
Yeah, elogind + sddm is what I'm running on Void Linux with KDE.
I didn't install a login manager. I login to console and run startplasma-wayland if I want a gui.
I'm not sure I'm missing anything.
I'm not sure I'm missing anything.
Ability to run a session remotely.
lol, sounds like you've got extra something
I hope there can be ways to circumvent this limitation and make it usable on non-systemd installs, i.e. with elogind (systemd's "logind extracted out to be a standalone daemon") https://github.com/elogind/elogind
There’s nothing to circumvent. Just continue to use you current login manager like you’ve been doing for years already.
This only affects a new login manager. Not existing ones.
This only affects a new login manager. Not existing ones.
It's worth noting that all of this drama stems from the (somewhat opaque, to put it nicely) reddit comments of one KDE developer, so that warrants treating it as a rumor in my book.
It would be prudent to wait for an announcement or clarification from KDE leadership before assuming anything one way or the other.
It would be prudent to wait for an announcement or clarification from KDE leadership before assuming anything one way or the other.
The Reddit thread had comments of 2 KDE developers and a link to the merged merge request removing FreeBSD support.
[deleted]
Sounds like a dependency. Not a particularly new issue in software.
Are there still a lot Linux distros that don't use systemd?
tl;dr: this is a new login manager. Nothing is changing for existing login managers.
So you can continue to use KDE Plasma on alternative init daemons / non-Linux OSs like before.
So you can continue to use KDE Plasma on alternative init daemons / non-Linux OSs like before.
[deleted]
KDE's decision to move toward only supporting systemD systems is a real loss and saddens me. KDE has been my favorite DE for years. I guess all good things come to an end, though.
They’re not. This is one new and entirely optional login manager. Nothing that is already available is changing
As one frog said to the other frog: it's only a couple of degrees warmer! What's the problem?
Again, this is a new piece of software. It does not affect existing login managers (eg SDDM) and nor does it affect KDE Plasma itself.
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
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
It's a minor temperature increase, but I believe that KDE quite explicitly does not intend to boil that frog.
No, Plasma Login Manager relies on systemd. SDDM and any other login manager doesn't. You can still use KDE.
For now, but the writing on the wall seems clear.
> 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-...
> 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-...
Hackaday, and you, omit the last sentence in the comment they quote: “The compromise is going all in contained areas where alternatives exist.”
I hope that's true, and remains true.
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.
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.
> 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.