Here’s something that’s both surprising and, in a way, not surprising at all, especially after yesterday’s announcement from KaOS, a distribution long known for its deep commitment to the KDE Plasma desktop, that it plans to move away from it. The main reason cited was KDE’s reliance on systemd in a specific component.
As expected, the news quickly gained traction, prompting KDE to clarify its dependence on systemd and which parts of the desktop environment rely on it. In a post on KDE’s Reddit community titled “A quick anti-FUD FAQ to debunk ‘the KDE is forcing systemd!’ hoax“, the contributor described the claims as misinformation and provided a short FAQ clarifying the project’s position.
Here’s a brief summary of the facts. As I informed you a month ago, Plasma 6.6 (scheduled for release tomorrow, February 17) will introduce the new Plasma Login Manager (PLM), which is intended to replace the long-used SDDM. However, to many people’s surprise, PLM has functional dependencies on systemd. This means that Linux distributions that don’t use systemd, as well as BSD variants, won’t be able to use it.
But immediately, it’s important to clarify that this applies only to the login manager itself. Nothing prevents you from continuing to use SDDM, or any other login manager, to start Plasma. You can even launch the desktop environment directly from the terminal if you prefer. The systemd dependency applies strictly to the new PLM, and nothing beyond that.
The good news is that in the post, the contributor further stated that KDE has no plans to make Plasma’s core components dependent on systemd. So, the desktop environment will continue to function on systemd-free and non-Linux systems, such as FreeBSD, as before. That’s it. End of the story. There is no need to worry.
Now, let me add a brief perspective of my own. For reasons beyond the scope of this article, systemd has long been a divisive topic in the Linux community. Some strongly support it, while others reject it outright, to the point that an entire category of distributions has emerged around the idea of being systemd-free.
If we look at how things stand with the other leading desktop environment, GNOME, it is obvious that systemd dependencies are more deeply integrated. However, there’s an important nuance here. GNOME, like systemd, has been developed with significant backing from Red Hat, so that this dependency feels somewhat natural and expected. In other words, the open-source community is more or less faced with a fait accompli.
KDE, on the other hand, has traditionally maintained a greater distance from corporate influence, giving it the freedom to chart its own path. This independence is one of the factors (aside from the desktop environment’s undeniable strengths) that has earned it widespread sympathy and a good reputation in open source circles.
For that reason, the introduction of a systemd dependency in the Plasma Login Manager caught some users off guard. Of course, if systemd were ever to become a hard requirement for the desktop environment itself, that would meaningfully change the conversation. But as things stand, this is not expected to happen.
So, at the end of the day, Plasma remains fully usable and accessible across Linux and BSD systems. Yes, some users won’t be able to use the new PLM, but ultimately, it’s just a login manager. The desktop environment itself remains unaffected, which is a wise move by the KDE developers.

Great article, with all the viewpoints offered, which is extremely rare in tech journalism as most pseudo-journalists are biased and processing the information rather than relaying it.
I suppose the systemd-free distros will have no problem ship another greeter to log you in Plasma, it’s not like choice is missing, between sddm, lightdm, ly, greetd, etc…
I personally think this is still a step in the wrong direction, relying more heavily on Red Hat is just plain wrong, and KDE devs are buying into the attempt of Red Hat to spread their tentacles everywhere so as to control every bit of the Linux stack deep enough that users will get locked into their software. It’s a properly dumb move.
But as said above, it’s nothing you can’t bypass. At least for now as we all know Red Hat does these things incrementally.