![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59LightDM's a from-scratch implementation of an X display manager, ie the piece of software that handles remote X connections, starts any local X servers, provides a login screen and kicks off the initial user session. It's split into a nominally desktop-agnostic core (built directly on xcb and glib) and greeters, the idea being that it's straightforward to implement an environment-specific greeter that integrates nicely with your desktop session. It's about 6500 lines of code in the core, 3500 lines of code in the gtk bindings to the core and about 1000 in the sample gtk greeter, for a total of about 11,000 lines of code for a full implementation. This compares to getting on for 60,000 in gdm. Ubuntu plan to switch to LightDM in their next release (11.10).
This is a ridiculous idea.
To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.
Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.
And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.
Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.
But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.
This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.
The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.
The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.
And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.
This is a ridiculous idea.
To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.
Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.
And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.
Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.
But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.
This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.
The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.
The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.
And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Reusing desktop policies
Date: 2011-05-12 06:39 pm (UTC)> sets of policy - one at the login screen, and one in your
> session. How do I ensure they're consistent?
The exact same problem happens with GDM vs. e.g. KDE PowerDevil. The settings are entirely different.
> The only sane solution is to ignore the functionality the
> backend provides and have my greeter run
> gnome-power-manager.
That's a GNOME-only solution and will NOT solve the problem for any other desktop. It also means GDM requires large parts of GNOME which makes it a non-starter for the Fedora KDE spin (which uses KDM instead). LightDM may or may not become a true cross-desktop solution (We'll see what Kubuntu makes of it.), but at least it is designed so that it could technically become one, unlike the entirely GNOME-centric GDM.
> It'll behave differently to your desktop
As I said, it's the same for GDM unless your desktop happens to be GNOME.
> - the range of policy you can implement will be limited
> to what the daemon provides, even if your desktop
> environment has a different range of features.
That's also what happens with GDM for KDE PowerDevil users, due to you dismissing its additional features as "mak[ing] no sense".
Now, unfortunately, KDM currently does not support power management at all. But running gnome-power-manager is not a cross-desktop solution for that. It does the job for GNOME users, and GNOME users only.
And by the way, another big issue is that GNOME is GDM-centric, e.g. it supports only the GDM interfaces for fast user switching whereas KDE Plasma supports both KDM's and GDM's. (This also implies that supporting GDM's interfaces will be sufficient for LightDM to interoperate with both GNOME and KDE Plasma.)
This "The display manager must match the desktop, ergo all users on the machine must use the same desktop." design needs fixing. The KDE developers do their part to support GDM, why doesn't GNOME support other DMs instead of badmouthing them?
Re: Reusing desktop policies
Date: 2011-05-12 06:49 pm (UTC)Re: Reusing desktop policies
Date: 2011-05-12 08:38 pm (UTC)Come on... you can do better.
Re: Reusing desktop policies
Date: 2011-05-12 08:58 pm (UTC)Re: Reusing desktop policies
Date: 2011-05-13 12:34 am (UTC)You do have a point in that they will eventually re-invent the world and frankly... LightDM is NOT lightweight if it's using Webkit. Webkit is massive. It makes GTK+ look like a short Sunday stroll around the block.
Re: Reusing desktop policies
Date: 2011-05-13 02:21 am (UTC)Re: Reusing desktop policies
Date: 2011-05-13 05:14 am (UTC)Re: Reusing desktop policies
Date: 2012-01-11 03:15 am (UTC)I would have thought that would be obvious - it should appear as the amount of light being emitted by the device's builtin display device increasing or decreasing independently of the image being displayed (assuming a backlight on the aforementioned device is currently present, active and is capable of being controlled by software).
Just as it does in KDE, Gnome, wmii, ratpoison, xfce, a virtual terminal, etc. After all, that policy is defined by scripts under /etc/acpi (on Debian) and does not require duplication in the login manager.
I use xdm as my login manager and I would call that lightweight. Sure, it doesn't solve all the stuff that gdm or kdm solve, but that's because it doesn't need or try to. Works for me, but it may not be suitable for everyone.
Re: Reusing desktop policies
Date: 2011-05-12 09:16 pm (UTC)(FWIW, the only reason shutdown/restart works in GNOME even with KDM is because GNOME now uses ConsoleKit's interfaces to do so, which bypasses the display manager entirely. Of course, this means the policy settings set for KDM in System Settings will get ignored and PolicyKit policies will be used instead. Yet another case of different policies for the same thing. As for GDM, it just dropped its shutdown/restart interfaces, which also required KDE Plasma to play catchup with new incompatible interfaces.)
Re: Reusing desktop policies
Date: 2011-05-13 02:23 am (UTC)Re: Reusing desktop policies
Date: 2011-05-13 03:12 pm (UTC)It is a backend (without a GUI) and frontend (called a Greeter) which can be whatever the hell you like.
This logic -> visual separation should make it a lot easier to maintain. The Gnome version will use GTK and have all the normal Gnome stuff. No-one gets an unsatisfying experience.
Also - LightDM will have a plugin-able backend to making, so it's already thinking of Wayland.
Have you worked on GDM? I know Robert Ancell (the main LightDM guy) has, therefore he probably understands the problem pretty damn well.
Re: Reusing desktop policies
Date: 2011-05-13 03:43 pm (UTC)Re: Reusing desktop policies
Date: 2011-05-12 11:51 pm (UTC)GDM being the GNOME Desktop Manager, yeah ...