Dear KDE team, KDE rocks. Thank you so much for your great work.
However, I wanted to implore you to not become a systemd only operation. There have been a few cracks already, e.g. the KDE System Monitor will launch with a giant area inoperational (the “Applications” view) which to the user looks like it’s broken.
But I heard the new display manager requires systemd. Listen, I get it, people like systemd.
But without opening this can of worms here, the fact is 1. other init systems are still somewhat common, e.g. OpenRC, or Devuan’s SysVinit, and 2. while there are good reasons to use systemd there are also very good reasons not to use it. If anything, FreeBSD alone is a good reason to not require systemd in KDE.
Please leave this systemd-only path forward. Thank you!
The reset of us don’t like these new features and are content with sddm that has not seen much development. Funny story the plasma-login-manager developers used to be sddm developers. What is the justification for requiring systemd in a login manager? What exactly is is going to do?
“systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit.
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.”
Does plasma-login-manager need to do all the above? Or does it just need to log users in with consideration for enterprise setups? Even kde-plasma/drkonqi requires systemd so now no more bug report data from some of us. kde-plasma/plasma-firewall, kde-plasma/krdp, and the list continues to grow. I looked at the proposal for plasma-login-manager and nowhere does it mention systemd so yeah an user from KDE2 I am feeling some kind of way. KDE has been collecting metrics, can we see where the use cases lie. It may be that 99% of users are on systemd based machines and in that case it makes sense to someone to link in a library that does everything. I have been looking forward to having a system time in UTC-0 but set a different time zone for the login manager.
Maybe we get together and help fund support for elogind based systems?
I would love some more elogind love, but I also get systemd is popular.
If I could make a wish, it’d be that core apps remained functional without systemd, without visible in-your-face limits like e.g. the system monitor showing a non-working “Applications” list.
I’m curious, what’s with the firewall? For now, settings version 6.5.4 seems happy showing firewall info with ufw without systemd on my system.
Not sure if the naming is the problem but maybe they just should named sddm into plasma login manager general and the current plasma login manager into plasma login manager systemd.
In a lot of cases when media reports something as depending on systemd there is no actual dependency on systemd as the init process.
Very often it is actually just usage of a system service D-Bus interface that can be provided by any process.
Even on an OS with systemd this is usually not provided by the init process but a system session component, e.g. logind.
There are often alternative implementations, elogind.
Linux (and Unix) system architecture is based a lot around communication between processes, e.g. application delegating some operations to other applications or services.
Such communication is usually handled via well specified protocols on standard system mechanism such as Unix domain sockets.
One such protocol is D-Bus which was primarily designed to allow desktop/UI applications to talk to each other and system services without needing a different protocol for each pairing.
So in a lot of cases a so-called “systemd dependency” is j
Regardless, the thing is KDE is not taking away anything. KDE is not abandoning, cancelling, killing, retiring, moving on from, terminating, snuffing out any project. Quite the contrary: we are adding. The same way KDELinux does not affect any other distro or OS, and Dr Konqi does not avoid you from using any other way of diagnosing and reporting bugs.
We are just expanding and creating something else that may add new and more convenient features in certain areas. And we are doing so using certain tools that are at our disposal on a given platform, as is the developers privilege to do.
All this outrage and fear is completely misplaced.
on invent - plasma/plasma-login-manager/-/blob/master/CMakeLists.txt?ref_type=heads#L84
That is as required as it gets. I posted about it here - plasma-login-manager-systemd-dependency. It would have been nice to have alternate providers but I do understand that a developer may be on a systemd system. And to be fair I have not created a PR for elogind either. I am interested in knowing if that is even on the cards.
KDE had KDM for a long time until porting to Plasma5
“ KDE Display Manager (KDM) was a display manager (a graphical login program) developed by KDE for the windowing systems X11.
KDE Display Manager was based on the source code of X display manager[1] and was the default display manager of the KDE Software Compilation, until it was retired in KDE Plasma 5 in favour of SDDM.”
It wasn’t retired in favor but rather left on the porting backlog and since SDDM filled the hole it was allowed to die. So we haven’t lost anything if they are planning on bringing back KDM.
If SDDM is good enough, why bother with plasma-loging-manager. We want it too for those reasons which David Edmundson outlined on his blog and they don’t say “systemd required”
“What we want
Great out-of-box experience in multi-monitor and high DPI and HDR
Screen readers for blind people (which then means volume control)
Pairing trusted bluetooth devices
Login to known Wi-Fi for remote LDAP
Remote (VNC/RDP) support from startup”
That is what the rest of us running non-systemd systems with elogind would like too. If we don’t speak up then it may be perceived that there is no interest?
I can’t comment much on any technical details and what component supports what, but screenreader support for the display manager sounds fairly important to me! (Sorry if this message isn’t helpful.)
That is what the rest of us running non-systemd systems with elogind would like too.
Maybe the reason elogind (and other display managers) have not got these things is because they are not easy (or as easy) to implement without systemd.
If we don’t speak up then it may be perceived that there is no interest?
I can tell you what you personally, @ekigwana, are perceived as when you speak up: as entitled. You (@ekigwana) are very free to start your own project, or re-start an abandoned one, implement the features you wish, leaving out the frameworks you don’t.
When you have a working prototype, you can even submit it through KDE’s incubation process, and, if it passes, try and convince other KDE devs to work on it with you. Some may join you.
Added bonus: maybe in that process you will gain some insight into why developers make the decisions they do and some appreciation for everything KDE has given to humanity so far for free.
Meanwhile, allow me to reiterate: KDE is not taking anything from you or anyone. If you avoid systemd, the status quo regarding display managers that can boot Plasma does not change. KDE is not blocking or removing anything, so your complaints are baseless and your demands unreasonable.
We are not entitled. We are invested in KDE! I am invested enough that I have created a simple patch so we shall see where it goes. So far it just appears that the developers are on systemd based OS’s which is okay too.
