"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.
LightDM looks more to the future of computing -- I think
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.