LightDM, or: an examination of a misunderstanding of the problem

[mjg59]

LightDM'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.

Comments

Power management policy

[(Anonymous)]

The power management policy problem can be seen the other way around: it's a bad design decision that the policy is maintained by a gnome-only program.

Re: Power management policy

[(Anonymous)]

Fucking roger that.

What the hell does power policy have to do with a graphical desktop environment? I don't get why what happens when I close my laptop lid should change based on whether or not I am running X.

Seriously?

[(Anonymous)]

Look... does everything between Canonical and GNOME (aka Red Hat)...

Have to lead to a long pointless post in the negative tone that accomplishes nothing?

I don't read GNOME planet to ruin my day thank you...

This kind of pointless arguing (with no actually point, if everything is weighed appropriately from a neutral standpoint) is ANNOYING!

Re: Seriously?

[mjg59]

The actual point is that decisions are being made without appropriate technical insight, and that hurts everyone. I don't benefit from Ubuntu failing. It's genuinely to my advantage to see them make sound technical choices.

Reusing desktop policies

[kevinkofler.wordpress.com]

> 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 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

[mjg59]

Because there's no way to make it work. Different desktops define different policies. If you want a display manager to handle that consistently then it needs to know what desktop the user's going to log into before the user logs into that desktop. So why bother trying? Running a DM with a desktop other than the one it's written for is going to be an unsatisfying experience, no matter how much additional code you add.

[(Anonymous)]

Actually, I'd love to have different power policy from the login screen vs. desktop: If I'm not logged in, I'm not expecting instant access, so I'd rather have shorter timeouts to hibernate, rather than sleep, for example.

[mjg59]

I should probably have made that clearer. There's obviously situations in which you want policy to differ between the login screen and an active session. The issue is whether you can configure those policies to be consistent with each other or not. For instance, if you can configure your login session to change cpufreq settings but can't configure your session to do so, you're probably going to find that odd. If you have both configured to suspend on lid close on battery and then find that one suspends if you close the lid and then unplug, and the other doesn't, that's going to cause you issues. Having different implementations makes it effectively impossible to ensure you have consistent behaviour.

perhaps all of thrse functions need not be...

[(Anonymous)]

...handled by the dm? It seems as though lennart intends for systemd to handle session management. That seems reasonable to me and given that, there is one less thing for a *dm to worry about. Perhaps the nix tradition(while not always applicable) of one tool for one job should be considered here?
Btw I completely agree with your assessment of "lite" codebases whose very size seems to be their sole grace.

Re: perhaps all of thrse functions need not be...

[mjg59]

Shifting it into systemd is certainly an interesting approach and one that makes a great deal of sense. But you still need a certain amount of integration - your greeter needs to provide appropriate UI for the session daemons, and again that's something that's going to vary between desktops.

[(Anonymous)]

My my, the Gnome Shell vs Unity split is still burning, huh? No worries, though. Most users hate both.

Finally!

[(Anonymous)]

I've been waiting years for a thorough Linux census which would allow one to make these statements.
Do you recall the URL to that extremely thorough census? I've always been curious as to how many desktop users Linux really had!

I wish there was a NoDM and no greeters

[mapopa.blogspot.com]

Take a look at android it just boots and then
you don't need to log in , it's your netbook and home desktop

One of the first things i do at home and on my netbook is to enable autologin
and most of the time gdm is the pig that stays in memory after it autologins

Re: I wish there was a NoDM and no greeters

[fluffymormegil]

My android device takes longer to play the poncy fanfare and swirly graphics at powerup than it takes me to type my login credentials on my netbook or my desktop PC.

BSD kernels

[(Anonymous)]

The BSD kernel may be more lightweight then linux ( how much of that is missing drivers? ), but it still ships with zfs ;) which is why every storage server I have uses it, whereas my laptop runs kubuntu.

I agree that a yet another login manager will not solve anything, just cause more diversion, which does more to hinder then to help...

CADT

[(Anonymous)]

Different but similar to a jwz from years ago. If you ever adopt a "No Linux on the desktop" policy you'll know you've become as curmudgeonly :)

[vincentt.myopenid.com]

I have no experience with the technical side, but aren't most of the problems you describe inherent to pre-login screens? Shouldn't the login screen have different power management options than a desktop after login? After all, what if different users have different preferences about what should happen when they close the lid? There is no way that the login screen can predict which user is going to log in and adjust its settings on that, so it'll have to use some default/system wide setting. There's _always_ going to be two or more sets of policy, right? I believe this is even true for gdm - its preference come, IIRC, from the special account 'gdm', not from some user that might log in. (That aside, without being able to oversee all possible uses of the display manager, I could on first sight even defend not having a power policy at all, as there is no risk of data loss and the login screen will in most cases only be shown for a short period anyway.)

[(Anonymous)]

On a multi-user-local-desktop machine, such as in a shared lab, you don't want different user's conflicting policies taking effect at different times. You want a single lab-wide policy dictated by the sysadmins and non-overrideable.

LightDM looks more to the future of computing -- I think

[(Anonymous)]

"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."
Or the larger one is massively more competently written than the smaller one because the next person to touch the code can look at the code (not comments) and easily understand it. And, smaller code size does not necessarily mean less functionality as there are other factors involved including things like shared libraries and different hardware implementations. What matters is not code size, but executable size and runtime data storage needs and here is where LightDM may (I don't know for sure) have an advantage.

As to LightDM not starting the gnome session -- so what? All this means is that there is added flexibility -- you are not stuck with starting a gnome session. From a system architectural viewpoint this is fine as this gives one the freedom to massage LightDM as one sees fit based upon target hardware and system requirements. Your example of a power manger is a good one. First power management is best done at the driver level with user level configuration available. Properly done this means that all high level (eg gnome-power-manager) should do is provide configuration information to the actual drivers (as in I don't care what the actual hardware or how it works but this is what I would like it to do.) Along with performance, battery, etc configurations one could also have a default for when no one is logged onto the system all of which are made available in a known location so any GUI or text editor can do configuration -- what's the big deal with one, or even three, additional policy sets which no one will probably ever change anyway (How many people change the defaults for most policy settings?)

And why worry about consistency between the login screen and your session? You want the user to have consistency between her/his login screens and between her/his sessions but it is not necessary between login screens and sessions. In fact it can be a problem in a multiuser system; who decides which users policies apply to the login screen or there may be corporate requirements to shut down only if no one is logged in after 10 minutes?

"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." The range of policy is always limited by what the software provides. If your desktop environment has a different range of features than your daemon, than the system obviously has been configured wrong swapping in a new daemon should be no big deal.

Actually from what little I've looked at LightDM, I think the developers are thinking about multi-core systems and trying to move in a direction which would allow LightDM to run on multi-core systems more efficiently. By breaking things up into smaller discrete executable chunks, it's much easier to divvy those chunks up among execution units. In the end, it's not lines of code but efficiency of executables and data combined with I/O. That's where LightDM might actually have it's big advantage.

Re: LightDM looks more to the future of computing -- I think

[mjg59]

So your argument is that the future of computing is one where it's fine for everything to be incompatible, because nobody is likely to care?

Actually from what little I've looked at LightDM, I think the developers are thinking about multi-core systems and trying to move in a direction which would allow LightDM to run on multi-core systems more efficiently. By breaking things up into smaller discrete executable chunks, it's much easier to divvy those chunks up among execution units.

Would you like to guess how many threads LightDM runs? Here's a hint: It's the same number that gdm uses. And, honestly, if your login manager is consuming significant CPU on a modern system then you've already fucked up beyond all recognition.

[(Anonymous)]

Now assuming that you are right, the interesting question is why is lightdm happening?
- Did Ubuntu decide that GDM was bad and needed a replacement?
- Did Ubuntu decide that GDM maintainers were unresponsive?
- Did Ubuntu decide that GDM was way too red-hat'ed for them?
- Did somebody just pitch a different DM and they fell for it?
- Does Ubuntu lack the knowledge to realize the problems you mention?

[(Anonymous)]

Judging by this - http://doctormo.org/2011/04/12/how-to-make-a-gnome-login-screen-in-python/comment-page-1/#comment-11483

I suggest it is a case of 'rewrite what you don't understand' - the rest is rationalizing on the part of the author. Its a shame that trivial developer whims impact the direction of a major distro so much.

[(Anonymous)]

Sometimes I enjoy your posts, but this one was stupid (really, like: not intelligent). It's one thing to argue about LightDM vs GDM vs KDM but it's another to make stupid claims:

'To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves".'

I've seen people change from a simple ascii based table to an xml based table format and then wonder why the filesize jumped up and free bandwidth dopped down. What does that have to do with your post? Well, sometimes "bloat" means simply that: more features than I need, and takeing more resources than I want.

All you write about "bloat" beeing just features that the others will implement as well
is only true under the assumption that it is not "bloat" but features. But all you write in your post about these features are unbacked claims. The only topic you go into detail is power management, and let me tell you (as most other commenters have): you are wrong here. Consistency is not possible. Never.

From your comments it seems that you think "consistent" means that is is configurable through gsettings. Everything else you claimed that could be "consistent" is simply not possible. Not with many users having possibly many different policies.

And if you come up again with this "Lightdm requires you to have different policies. How is that anything other than technically inferior?" Let me tell you that ascii table parsers don't have XPAth implementations. Just sayin.

I'm not claiming that GDM is bloated or LightDM will not be bloated in the future, all I'm saying is that your post is stupid. Maybe not as stupid as some other recent posts of people bashing Ubuntu, making lists of software features like "developers use bzr: bad, developers use git: great", but it's close.

Still: I'm looking forward to read an intelligent post of you, maybe about *technical* problems of [x]DM, at least if you take the time to come up with good arguments. Because writing such a blog post without good arguments is a ridiculous idea.

[mjg59]

It's clearly possible. Consistency here doesn't mean identical policy. It means policy that works in the same way. Does my power manager change brightness by jumping directly to a value, or does it scale smoothly between them when possible? Does pressing the power button result in a dialog box appearing or does it just shut the machine down? Is it possible for the administrator to impose a policy on the users that's identical to that in the desktop manager? If you're running the same code then it's obviously possible to provide that consistency. If you're not then it's effectively impossible and the user experience suffers as a result.

Missing Graphics

[(Anonymous)]

> 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.
I also don't need graphics, but I know that many of my friends prefer a 3d nice login greeter. It's about the feeling of your pc. And yes, its more important for them then accessibility.

[(Anonymous)]

"And then they need to implement support for handling remote filesystems": well, you only do if you are trying to bypass the dedicated OS interfaces (mounting). You pay a price for fighting the OS (and sometimes, you also break compatibility with non-desktop use...). When the OS interfaces are inadequate, the only long term solution is to fix them there.

History from the original GDM author

[(Anonymous)]

Here's a fun bit of history from the original GDM author that really puts this post in context.

http://mkp.net/musings/cereal.html

(gdm comes in on the second page).

Design and Bloat

[hasenj.myopenid.com]

Two things you don't understand:

1. Visual design matters

Gnome is notorious for being ugly. If the only advantage of LDM was its ability to produce a beautiful login screen, then that alone would be enough of an advantage.

The ugliness of gtk (or at least gtk2) is the biggest burden that Ubuntu is carrying, and is perhaps the really big reason of why Ubuntu is still way behind in the market.

2. Bloat is stuff that doesn't matter

Less is more. Who cares about power settings? So what if the screen dims after 10 minutes instead of 20 minutes? The truth is, no one is going to be annoyed by that, because no one leaves their computers at the login screen for that long, and even if they do, it still wouldn't matter because no one will be staring at the computer to be bothered by the display being dimmed or going off.

It just doesn't matter

http://gettingreal.37signals.com/ch05_It_Just_Doesnt_Matter.php

And if it doesn't matter, it's bloat.

Re: Design and Bloat

[(Anonymous)]

Yeah, who cares about accessibility? If people are disabled and can’t use a computer, it just doesn’t matter.

Troll, troll, troll your boat...

[schaiba.wordpress.com]

Matthew, as far as I see, a good part of this article is flamebait waiting to happen. And, to put the cherry on top, putting a Linux-vs-BSD refernce at the end
makes for confirmation. If you don't like LightDM, fine, don't use it. But don't be that arrogant as to say "it's my oppinion and it must be true."

And now, for an examination of YOUR misunderstanding.

[(Anonymous)]

Look at Debian. Red Hat and Fedora. Ubuntu. Mint. Arch. The other thousands of distros, as partially listed by distrowatch.com. What does this tell you about the Linux community? All of us believe that one size doesn't fit all. You have the people who prefer a slightly lower maintenance desktop. They install GNOME or KDE. You have people who have specific needs due to hardware. They might install LXDE. Some people use Linux as a server. They don't even have X. Blah blah blah, you get the idea.
Now, LightDM is fundamentally flawed because it doesn't give you full integration, bells and all, with GNOME. Of course. No one uses KDE. No one uses XFCE, Enlightenment or LXDE. No one takes Openbox, tint2, their own handwritten daemons and what-not and builds essentially their own desktop and try to find a desktop-agnostic DM and write their own integration. No one.
The GDM devs are competent? Of course. Everyone has some sort of competency. But some people are more competent than others. BitKeeper, the revision control system Linus Torvalds used before writing Git is good software, no? I'm quite sure it is, since Torvalds used it. But then he wrote Git. It is better, at least in my opinion. By what black magic is it that it beats a competently written piece of software? It is MORE competently written.
Besides, LightDM doesn't do less, it assumes less. Its devs see that not everyone uses GNOME. But the capability is there. Or will be. Its developing. Rule of Modularity: Write simple parts connected by clean interfaces. Rule of Simplicity: Design for simplicity; add complexity only where you must. Rule of Diversity: Distrust all claims for "one true way".
"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer
You think lightweight software is flawed? Go use Windows. Install 4GB applications that can only do one thing while looking ugly at it. Linux is for people who know how to customize or at least be open about others' customization.

Re: And now, for an examination of YOUR misunderstanding.

[mjg59]

Linux is for people who know how to customize or at least be open about others' customization

Citation needed.

I've no objection to LightDM existing. I've no objection to people choosing to run it if they find that it fits their needs better in some way. But replacing gdm with it by default on a Gnome-based distribution is a demonstrable reduction in functionality, for what benefit? git took a completely different design philosophy to bitkeeper, and its benefits are more in that than in the implementation. LightDM is effectively just a rewrite of gdm with a different API between the greeter and the daemon.

Oh man

[(Anonymous)]

I thought I smelled a Lennart; this article confirms it.

Re: Oh man

[(Anonymous)]

There can be only one Lennart! At least we all hope so.

[(Anonymous)]

Lets make an analogy:

Say you were a child, and you were playing with blocks. Say you built (what you thought was) this great structure. Now, what if someone else, who was playing next to you, made a different (but equally interesting, however smaller) structure that shared the same purpose. Would you go and tell that person he was stupid, that there was nothing wrong with your own structure and so his was pointless, or something to that effect? What would happen to that person? Would he be forever marred by his "failure" and decide to never build with blocks again? Would it be less drastic? Maybe he would just dis-associate himself with the person who said his structure wasn't good. Maybe he doesn't care, and will continue building this other structure despite the ridicule.

There is only one possible good outcome, and that's him continuing to build his own structure (or, maybe, someone else's). What about him working on yours, you ask? Why the hell would he want to do that, after you shit all over his hard work? Any other outcomes aren't good either, as you've effectively stifled future innovation, or at the very least, (possibly/likely) ostracized someone from ever coming to your own group. Congratulations.

[mjg59]

Let's make another analogy. Say you were a child, and you were playing with blocks. You've helped the child next to you build a huge tower. The other child decides that part of the infrastructure isn't ideal. You ask them in what way and they tell you that it should be smaller and a different shape. You point out that it needs to be the same size in order to keep the tower up, and while changing the shape isn't a problem in itself it'll take some time to figure out exactly what the new shape should be. You suggest to the other child that maybe you'd be better off spending time on making the tower taller, but instead they decide to spend an hour coming up with a new support structure that ends up looking almost exactly like the old one. Who benefits?

Everyone should feel free to experiment with new ways of doing things, but it's appropriate to figure out why things are the way they are beforehand. If there are people with prior experience in the field, should they just let you make mistakes or should they point out that you're wasting your time? I don't object to the existence of LightDM. I object to it being described as lighter than gdm without any acceptance of it having a massively more limited feature set. I object to the suggestion that a distribution will directly benefit from the adoption of a more abstracted backend. I object to a decision being made without any obvious discussion of the real issues involved. I think Ubuntu will suffer because of this decision, and when Ubuntu suffers I think all of desktop Linux suffers.

common theme

[(Anonymous)]

seems to be a common theme in software.

you have a great featureful program. someone says its too bloated. they start a new lightweight version (or make a fork), that does the subset of what they need. other folk gradually add what they need to the lightweight version. and by the time it has the enough features to please everyone people are calling it bloated again.

mozilla suite -> firefox -> epiphany/fennec
gnome -> xfcd -> lxde

i am sure there are others

Re: common theme

[(Anonymous)]

tomboy -> gnote
f-spot -> shotwell
pidgin -> empathy

Why LightDM

[https://www.google.com/accounts/o8/id?id=AItOawlASvrOcAZwhIzLSB7D9IMxB8TeDLjnL0E]

As an end user I can tell you, from an eye-candy perspective that GDM1 was very themeable and looked great. Then they moved to GDM2 with a very boxy, clunky look. "We will add more themeing options later," is what they said. Well now we are on GDM3 and it is just as ugly and boxy looking as ever.

Ubuntu has the option of keeping with the boxy look. Patching GDM on their own, always at the mercy of having to rehack their code when upstream changes come along. They could also make changes to GDM3 and try to get Gnome to accept the patches. Which would leave them on some technical committee trying to get consensus or making revisions till they are to Gnomes liking. With the recent Unity / Gnome fallout, that does not seem to be a very productive route.

I think Ubuntu wanted to have 1 greeter, that works well with Ubuntu / Xubuntu / Kubuntu /Lubuntu (which GDM3 does not) and is easily themeable for all the above environments AND being possible to make the themeing very elegant and beautiful looking.

I have been waiting 3 years for Gnome to do that with GDM. I am quite thrilled that LightDM will offer another choice.

I think the "its lighter" and "it has 80% less code" arguments are bunk. Ubuntu is trying to avoid saying what I am saying, "GDM is as ugly as sin and Gnome will not fix it or accept help in fixing it, so we are doing something different"

Re: Why LightDM

[(Anonymous)]

Also since LightDM doesn't start a GNOME session it probably can be started earlier in the boot process. I think that's one of the main reasons for Ubuntu switching greeters.

Power management

[(Anonymous)]

I use Xfce which has Xfce-power-manager but I must use Gnome power manager ?
My laptop boots in about 45 seconds, why would I want to close the lid within that time ?

Your argument is illogical and absurd.

Re: Power management

[mjg59]

If you're running Xfce then it makes more sense to run Xfce-power-manager, yes. And if you always have your machine automatically log in from the desktop manager then there's no real benefit in having the behaviour at the desktop manager mimic that of your desktop. But in that case there's also no real point in running a desktop manager, so it's still not a reason to favour LightDM.