We now have a truly amazing spreadsheet that tabulates the current state of three display managers. It has sections from community, "soft" attributes (such as licensing and build system), technology support, features and performance. Unfortunately, this did not lead us to any firm conclusions but it was very useful in helping better understand the landscape here, which is what we were after.
Our Requirements
The question we are trying to answer is this: What display manager will we use in Plasma Workspaces 2? Candidates must match a simple and clear set of needs:
- Must be lightweight. We want to use this on desktops and devices.
- Must be maintainable. (Self explanatory.)
- Must be able to write the user interface in QML.
- Must be able to be a Wayland system compositor.
How hard can that be, right? ;) Bonus points are awarded for things like:
- Used by other projects (co-investment and user consistency)
- Familiar tooling (we can always learn and use another revision control system, but we'd rather not as that raises the bar for participation)
Given that as a starting point we looked at three options and here's what my take-away on each was.
Contestant #1: KDM
This contestant is a deep soul with much complexity who likes things the old-fashioned way. 20 year old scotch is its drink of choice, and it hates walks on the beach (not much of a romantic, you see). It holds advanced degrees in many traditional practices. Let's say hello to .. KDM!
KDM does a lot of things very well. It is highly scalable (10k users in LDAP? No problem.), supports features such as remote log in, can be used with hardware and biometric keys and much more. It is themable, as a Google images search can quickly confirm.
Unfortunately, there has not been much work on it lately and none of the active developers know the codebase very well. And what a codebase it is! 34,000+ lines of code, nearly 14,000 lines of which are C with the rest mostly C++. It is a beast. Interestingly, the KDM settings UI is 6,400+ lines of C++. That makes it's control panel nearly twice as big in terms of code count as the Plasma Active shell.
Work had been started on making a QML front end for it (twice, I believe) but it never came to full fruition, and it is unclear just how best to add a Wayland system comositor to KDM would be. So though it has served us well, KDM actually fails to meet our requirements.
Contestant #2: LightDM
This contestant is a young but accomplished fellow with lots of modern features. An outgoing sort, he strives to be useful to all around him and tries not to make many assumptions about what would make you happy. With lots of friends, he's seen at the entrance to many parties .. say hello to: LightDM!
With just over 20,000 lines of C code (though getting closer to 22,000 with the KDE integration bits), LightDM has a terrific number of features. It has a clear separation between the toolkit-agnostic backend and user interface providing front-ends that communicate via a local socket to get the deed done.
Guest login, auto-login, VNC/RDP/XDMCP, power management, fast user switching .. it's all there. Outside of a few things like biometrics, it has a superset of KDM's features. It also has support for new Linux middleware such as systemd and AccountsService, and does it all with a very small footprint (the daemon takes well under 1MB of RAM). It is also quite extensible and used by a large number of projects including the *buntu family of Linux distributions, RazorQt, Elementary and XBMC.
There are three main contributors to the core LightDM according to the commit logs, all of whome work at Canonical. In addition to their efforts, David Edmundson's has been working on KDE integration for LightDM in KDE's repositories. Thanks to his work, you can write your UI in QML and PowerDevil is used for power management giving us consistency and portability. There is still work to be done, but it works rather well right now. I've been using it on my laptop for a while now, so that's not just theory.
A big piece of work that needs to be done is to add a Wayland system compositor. This is where things get tricky. LightDM is a Canonical project, and as such they will not be working on a Wayland compositor since they decided to part ways with the rest of the Free software ecosystem and create their own display system, Mir. One of our big questions was whether a Wayland compositor would be welcome.
Robert Ancell, the LightDM maintainer, attended last night's meeting which was extremely helpful. According to him, a Wayland backend would be welcome (though they won't write any of it) and there will be no hard dependencies on Mir in LightDM. This is reassuring, but means we need to trust the roadmap of Canonical a bit here and also means we'll be doing all the heavy lifting on the Wayland side. David has stepped up to do that work, however, which is also encouraging.
Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. This means that we won't really be able to contribute to core LightDM very effectively as a team. Some individuals may choose to do so, but several have already stated they won't, including those with the most experience with things like Wayland.
The fact that it is already widely used is a plus, however, as it means we may be able to share some efforts with others. This is particularly useful for system integration bits. For instance, Robert noted that Ubuntu will be working on logind support for LightDM. That said, some of our downstream distribution partners seem less than keen on supporting LightDM in their distributions.
So in summary: very featureful, relatively mature after three years of development, we already have a good amount of integration, but it carries risk due to community and commercial dynamics.
Contestent #3: SDDM
This young whipper-snapper is still wet behind the ears, as they say, and is still learning the ropes but she's fast and lean and sports a shiny approach to life. Let's say hello to SDDM!
This project is only three months old and as such is, by far, the youngest of the bunch. It also has the fewest features. However, with less than 2,200 lines of code it already provides the daemon/frontend duality with socket communication much as LightDM does and the user interface is written with QML. In fact, the entire thing is written in C++ using Qt and the code is very clean at this point. As with LightDM, it's memory footprint is more than reasonable.
It is an open, community developed project and has been picked up by the relatively new QML-based Maui desktop project. The use of C++, Qt, CMake and git make this a very familiar feeling to the code base for us Plasma hackers. The QML package structure is actually very similar to our own, and I understand that was not completely by coincidence. There is one main developer with two others who have made some contributions as well. This is fairly similar to the LightDM development profile, except that the contributors are not paid by the same companies to work on it.
As with LightDM and KDM, a Wayland compositor needs to be written for SDDM. It also needs to gain support for a large number of features it is currently missing, such as AccountsServices, guest accounts and a number of others. It does already support systemd and have some power management features.
The biggest concern I have is the youth of the project. Will it continue to be worked on and mantained? Will other projects also adopt it as it matures? Only time can tell. I am very keen to seen how SDDM develops over the next couple of months.
Conclusions
This is a difficult decision to make. KDM is not going to make the transition into a QML and Wayland world with us, despite it having served us well in the past. We need something to take its place, and we'd prefer not to start from scratch when there are good choices that already exist.
On the one hand we have the feature filled LightDM with three years of track record behind it, but which still needs work to make it do what we want, and which has a relatively large codebase that will be hard to contribute to. That said, David has already put a good amount of effort into the QML support for LightDM.
On the other hand we have a youthful, and thus largely unproven, SDDM which needs even more work than what we'd have to dedicate to LightDM but whose code base is very small, modern and uses familiar tools and which is developed openly. We won't need to do any QML work, but we will need more system integration features. With SDDM, there'd also be very limited (if any) opportunities to work with non-Qt/QML desktop projects.
If more projects interested in Wayland got involved with either LightDM or SDDM, that could tilt the scales as we would be able to share the compositor work with them. Personally, I'm torn between the open community and great code base of SDDM and the utility, maturity and wide usage of LightDM.
38 comments:
LightDM could have been the best fit yet the licensing issues make me wish to see it rejected...it's sad to have to drop an otherwise good project but if we can't have the licensing we need then downstream projects can't all benefit from the work being done and that isn't acceptable IMHO. Canonical could, on a whim and we've seen them do that before, alter the projects so that it no longer did what we need.
SDDM looks, to me, to be the best choice and its youth has the advantage of it being free of legacy code and being able to be moulded from the ground up into the best possible long-term option.
Is LightDM free software? Can't it be forked?
Ah, the quandary !
Giving up on a project because of licencing/ownership is a sad but sometimes unavoidable decision.
Pouring energy into a YAFoobar project that might not be a better solution for everybody isn't such a great prospect either.
I'd say wait and see. Competing projects can be good for the community as a whole, so I'd encourage sddm devs right now.
"it requires signing the Canonical CLA which is not acceptable to many developers (including myself)"
Just out of interest, do you feel the same way about the Qt Project's CLA?
Unless LightDM can be forked, SDDM seems to be the way to go to avoid future disputes
[i]it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. [/i]
How come you have no problems doing the same with Qt you hypocrytal?
QT CLA may not be Cannonical's CLA ...
Dunno what's the codebase behind each of those, but given the goals SDDM seems to be the good bet.
Cleaner and easier to extend. Fresh start.
That's just a DM that's heavily integrated with QT (and does not use them only for the greeter) and is secure to use. So i think that SDDM will be the better chioce. ;)
@Ramsees
Except that http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php exists to ensure that Qt would be released under a BSD-style license in case the owners of Qt decide to close source it.
In a comment in http://dot.kde.org/comment/117502#comment-117502 it seems that the Qt CLA is in fact needed to be able to make the Free Qt Foundation legally possible at all.
Not sure Ubuntu's CLA has something like that.
After testing all them 3 in real, i can say lightDM is NOT ready for systemd yet, and the backend is written using GObject (nothing against it, but is not really optimal). SDDM is a better solution for KDE imho, and is really faster , easier to theme and lighter then lightDM.
Jucato: Yeah, and mean while they are free to make the source code closed, what a bunch of hipocrytals with double standars.
So choices are:
1. Unmaintainable spaghetti code
2. Non-free licensing by Canonical
3. A project with a good start needing new features
Hmm... very hard to choose what is best choice...
3. is the only sane and logical choice. We can not give a finger to Canonical because it does as always, rip the open source community. We can not take KDM without rewriting so easier is to start new project. And someone has alreadys tarted new project so we can just jump in and support that.
@Fri13: Actually LightDM is GPLv3, you cannot contribute upstream without signing the CLA, but you can fork it, so that's not an issue.
The choice is actually very easy: Use LightDM and contribute the same way Canonical contributes to Qt: Write a few hooks and develop Wayland support in another repo without CLA. If Canonical is dickish bout the LightDM-Qt, fork that library as well.
@Sam S.: "do you feel the same way about the Qt Project's CLA?"
Yes, I do, and I've said so in the past. However, there are two significant differences between Qt's CLA and Canonical's.
First, some history: It was years of effort to bring Qt to LGPL, to a public repo, to a public bug tracker, to using 3rd party modules that they don't own all the copyrights to (Phonon, WebKit), to open governance ... Qt has been increasingly opening up thanks to the determined efforts of a small but indefatigable group of people. The CLA is the last bit that really is not good enough yet.
Fixing that will require Digia (or whomever ends up owning Qt later) to accept the idea that selling commercial licenses is not a useful income stream and that LGPL alone can fit all use cases; that the real value is in the people, the brand, etc.
So that brings us to difference #1: Qt was always supported by selling commercial licenses. The situation we have now is actually an improvement.
Different #2 is simpler: There is the FreeQt Foundation, so that if Digia closes Qt up and stops committing to the LGPL version, we get Qt under a BSD license .. which would dramatically undermine any reason to close Qt.
That said, I'm still not happy about it and I therefore tend not to contribute directly to Qt myself.
@Ramsees: "How come you have no problems doing the same with Qt you hypocrytal?"
I do. Read above. This isn't news, either.
Seriously, Ramsees, stop trolling my blog. It's been enough years and while you evidently don't like me or what I do, that doesn't excuse this kind of rubbish on such a reliable basis.
You can consider yourself officially persona non-grata on my blog.
Forking LightDM:
Yes, that is a possibility. I consider it highly rude to fork, however, particularly if it is simply a matter of difference of license opinion. I'd rather either hold my noise and use it or work on something else.
As others noted, it is possible to simply develop in a branch that we never expect to get merged into mainline .. though that is effectively the same as forking.
@Manuel Tortosa: Yes, LightDM still needs work as well. It doesn't yet do logind, for instance, which is part of the systemd regime. However, it is actively maintained and time is apparently earmarked for making that happen.
So LightDM is not a completely 100% "just drop it in and use it for everything" solution. It's simply much more complete than the other options.
It's "not complete, but more complete" status does make the decision a bit harder.
.. oh, and yes, I don't think we'll have a firm answer immediately. I'd be happy to have a good answer in 2-3 months time.
While I am a fan of LightDM, I think you should probably switch to SDDM. Since adding support for Wayland will be a lot of work in both cases, and both are missing features such as biometrics; I would go for the DM with the lighter codebase and more community friendly model. Also bare in mind that Canonical seems to have a bad way of radically changing directions, and orphaning projects that they've heavily supported or started, I would keep my distance from their projects. If you go with LightDM, you might end up having to change to another DM or having to fork and maintain everything yourselves either way. Especially if Canonical decides to take LightDM in done other direction, as they go off and chase some new butterfly that caught their eye. :S
Apologies for the block of text as a comment. Alas it is tricky to write longer comments on an Android phone. :p I'm sure that Plasma Active, when it'll be easier to image my phone with it, will be a lot more useable. :)
The other problem with forking LightDM is the question of who is going to maintain the fork. You would basically end up with the same problem as with SDDM: a new project with an unknown future.
Aaron Seigo really the first thing that need to be done is talk to Gnome and others.
The reality here is going forwards on Wayland everyone has to solve the login solution.
There is a big question if it even need wayland support.
Wayland allows application to talk to display compositor/server. exactly what applications do we want to run under the display manager.
KMS DRI and Hybris support come to my mind as requirements not Wayland.
http://qingy.sourceforge.net/
Is what comes to my mind as something like what is required.
There is a reason to go qingy like path at transition it can fire up X11 or Wayland based solutions and it dependant on neither.
SDDM might be the best to take down this path.
Talking to GNOME is not useful, their plans are clear: continue with GDM, which has become an only slightly stripped-down version of gnome-shell, and thus is not suitable for us at all.
well, you could fork LightDM at any later point in case Canonical departs from KDE's best interests since it's GPL'ed anyway. the question is if you're able or willing to do so in the first place.
a DM has lots of dependencies and integration points both software- and community-wise. that's what makes it hard task. hence acceptance and adaption by multiple parties do matter.
the question i'd ask is whether a DM is part of the Plasma Workspaces' distinctive competencies. if so then you might want to invest into it within the KDE community and then it's a matter of which alternative has more actual traction within KDE's ecosystem.
it's a hard decision to make but worth it. all the best!
Kevin Kofler
http://en.wikipedia.org/wiki/X_display_manager_%28program_type%29
I said gnome and others. Main reason is to see what we can share.
http://slim.berlios.de
and lxde lxdm also come to mind.
Ok these are not QT based.
"Talking to GNOME is not useful, their plans are clear: continue with GDM, which has become an only slightly stripped-down version of gnome-shell, and thus is not suitable for us at all."
Still talking to gnome about possible common libraries along with other display mangers would be a good thing.
Ok if they don't take the invite to table so be it. At least KDE will be able to say the invite was put out. Any that agree reduce the coder over head we are looking at for SDDM or other solution.
LightDM licensing model is kinda going to get in way.
Changing to wayland is a very big step. The bigger the team to spread the workload we can do the better.
First step send out the invites and see who bites for a joint project.
LightDM support many different front ends. Problem is its locked under the Canonical license.
Now if there are enough interested parties forking LightDM would not be a problem.
KDE forking it alone would bring the some of the same resource problems KDM suffers from. Taking on SDDM alone also risk some of the same problems.
Time to admit project has limits. Other project have limits as well.
Shared workload would solve some of the problem.
At first I'm inclined to say "choose SDDM!" because it's Qt based and use the same tools we already use.
On second thought I'd say: ask the others, and gently push them to make a choice it they don't care now. There is Gnome, XFCE, LXDE, RazorQt, and other communities out there with almost the same needs as us. Let's try to choose together.
If many others agree on sharing efforts, even forking LightDM (if needed) could be acceptable.
If we end up with only KDE and RazorQt communities, let's go SDDM. At least it would make easier for people from our community to step in and contribute to it.
"Must be able to be a Wayland system compositor"
I hope it does Mir too especially if Mir will be the displays server with proprietary hardware support.
e8hffff
"I hope it does Mir too especially if Mir will be the displays server with proprietary hardware support."
Mir fairly much kills running your own compositor. Desktop effects and other things depend on running your own compositor.
So the code for mir is fairly much the same as LightDM for X11.
Most proprietary hardware support that will be linked to mir will be under libhybris https://github.com/stskeeps/libhybris Basically lets use Android drivers.
So mir support falls under we don't give a stuff. If there are any special drivers appear for mir then wrapper libraries could be considered.
But to get back the compositor this program has to operate independent to Mir. Maybe like qingy able to start mir but not dependant on it in the slightest.
Wayland system compositor could be swapped with must be able to stand on own two feet. Not dependant on anything else to operate.
KDE wants to be able to start is own system compositors. You cannot really do this with mir in the way.
@oiaohm
"I hope it does Mir too especially if Mir will be the displays server with proprietary hardware support."
That statement more or less condemns KDE to the grave yard. If KDE, can't side step with Mir/Ubuntu-Phone then I'll move from Kubuntu to Ubuntu using Mir/QT5, as I want proper hardware support and to take mobile devices seriously.
Too many people have sacred cows around here rather then see the market for what it is and where it's going. If you don't cover the mobile devices then your positioning yourself at the back of the bunch. Sorry but Plasma-Active is no solution as it fails with hardware support, something Mir/Ubuntu will tackle.
Aaron Seigo in my opinion is making decisions based on what 'he' wants rather then what's best for the community. Having sacred vows, a la Plasma-Active at the loss of KDE.
Wayland has failed so far to get hte good out fast enough so now it's time to pick the best project for potential for scoep of devices and users. I'd say that's Mir. Possibly also consider Wayland if Mir doesn't make it.
@e8hffff: "Aaron Seigo in my opinion is making decisions based on what 'he' wants rather then what's best for the community. Having sacred vows, a la Plasma-Active at the loss of KDE."
Your opinion is wrong on that matter :)
"Wayland has failed so far to get hte good out fast enough"
This is propaganda that is being spread by people who have a vested interest in Mir .. and it's false.
There have been commercial products that have shipped with Wayland; there is support for Wayland in all the major toolkits now (we were very much waiting on Qt5); Wayland hit 1.0 last year; there are a number of 3rd party shells/compositors that have been written for it (Enlightenment, Maui).
Some things take time because they take effort. Code bases don't write themselves, nor do they change direction immediately. What we don't want to do is to force a shift away from X11 before everything is in place for that.
"so now it's time to pick the best project for potential for scoep of devices and users"
Which is what we've be doing.
"I'd say that's Mir."
So your suggestion is don't pick Wayland because it isn't far enough long (despite all the milestons noted above) and instead pick a project with fewer people working on it, fewer companies putting money into it and which is ~3 years behind Wayland in development? What kind of logic is that?
Have you actually analyzed either technology through usage, packaging and/or code review? I'm having a hard time believing you're making these kinds of statements if you have.
In any case, we'll know in a year's time which project works out (possibly both) and which, if any, doesn't. See you then ...
@ Aaron: don't bother, e8hffff is a well-known pro-Ubuntu troll. This has all been explained to e8hffff countless times. If e8hffff is listening, then he/she doesn't care.
e8hffff said that Martin should be ousted as the kwin maintainer for not immediately dropping his "no-distro-specific patches" policy and fully embracing Mir.
Interesting choices, I didn't even know SDDM until now. Looks like a promising project to me, very nice!
I like the design of LightDM having the underlying technology toolkit independent, but the close Corporate control is too much of a concern to me.
I'd go with SDDM and hope for the best. The question is: Do we need a decision on a DM "right now"? I still have the feeling as if Wayland as primary display server is not around the corner yet.
@STiAT: "The question is: Do we need a decision on a DM "right now"?"
No, we don't need to make a firm decision right away. We probably have a few months to gather information and see how things develop further.
"I still have the feeling as if Wayland as primary display server is not around the corner yet."
Indeed, but for it to arrive someday, we (plasma team) have to start thinking about these things now. Our decisions affect following releases, and sometimes (as in this case) we need to know what the options are and how to measure them before we can make decisions.
In the case of DMs, we also know that no matter which we pick , work will need to be done. So we need to define which work would need to be done, so we can do that work and know when it is ready.
We kind of live perpetually 1-3 years in the future in our thinking because of this.
eh8fff is a well-known pro-ubuntu and Mir troll that completely disregards any facts thrown at him to defend and support Canonical's decisions.
This is just him going on the offensive because you rustled his feathers, so now he is here harassing you.
By his comments you can clearly understand that he is not a developer, nor does he understand anything about it. He is just a fanboy that got mad at the backlash of the community against Canonical.
As for the topic in hand. LightDM and SDDM seem to be great options. The issue with LightDM is an issue of trust. Do you guys trust that Canonical won't close LightDM in the future and use your work only to themselves? Will they stop development of LightDM in the future and force you guys to assume the development of Light DM in the future?
As for SDDM, those issues don't exist but you don't know if the project will be maintained for long since it is quite new. IMO, this project will only die if it fails to atract any project as KDE, Gnome, etc. If you guys put your weight behind it, it won't die. You will also have something controlled by the company instead of being hostage of a company's whims. is it worth the extra effort that it takes compared to LightDM?
as a user i think sddm would be the right choice, given its relatively light codebase and given that its more community based and that means kde can have its own direction instead of using something which may not be needed by kde's target audience. for eg. canonical may commit something which would introduce a feature for mobile devices and kde wouldn't want it. that would mean that kde would have to maintain a separate fork with completely different codebase overtime.
I would say go with LightDM.
What about O( solid | phonon ) for DMs?
This might be a little extreme, but what if you made the display manager a stripped-down desktop (plasma/kwin) like GNOME wants to do according to Kevin?
One benefit is that this way the only thing that needs porting to wayland is KWin (which is going to be ported anyway).
SDDM seems like too young / lacking in features for a state-of-the-art linux desktop as KDE should be and lightdm is also missing features that users care about and could probably go towards Mir since Canonical is behind it (let alone the CLA concerns).
Of course you still need things like authentication/PAM, KSecretService, biometrics, accessibility, logind, sessionk or systemd as session manager, configuration etc etc but perhaps these can be salvaged from KDM for the most part and/or the implementation of those is probably easier than the graphical parts that need to be done for lightdm to make its qt part a wayland compositor or any KDE-specific features that may be needed in the future.
Of course this is all hand waving, sadly I don't have any free time available to code a proof of concept. Just food for thought ...
Post a Comment