Hi all, Currently LightDM supports both legacy password/preferences (pwd.h and .dmrc) and AccountsService (http://cgit.freedesktop.org/accountsservice/). AccountsService is a relatively new D-Bus service that was started in January 2010 that wraps up user information into a D-Bus service and abstracts away account manipulation. I think AccountsService is a really great piece of software and I'd like to see it widely adopted and LightDM have a hard dependency on it. The question is: if you are a consumer or potential consumer of LightDM is this an issue? Specifically: GNOME - developed from GNOME, so not a blocker KDE - ? Oracle - ? LXDE - ? XFCE - ? Elementary - ? Other - ? Thanks, --Robert
Putting something in git.freedesktop.org does not automatically make it a standard. I did not remember that poeple had consensus on this one. Of course, this is a good thing, but this caused portability issues as some other systems may not adopt this. Two good examples are udisks and PolicyKit which should be portable but finally became Linux-specific. OpenSolaris and others have different security models for which Polkit is not suitable. UDisks is too Linux-centric and is built on top of udev and there are no other systems plan to support it. Unless this gets wide adoption, adding a hard dependence to this is not a good idea. It can be an optional feature, but at least for LXDE, I do not think that we should rely on this. Something like PolicyKit brings many problems already. I'd like to call this Dbus hell or *Kit hell. We have more and more dbus *Kit. IMO we're now moving away from KISS principle and beauty of UNIX. On Thu, Aug 18, 2011 at 9:14 AM, Robert Ancell <robert.ancell at gmail.com>wrote:> Hi all, > > Currently LightDM supports both legacy password/preferences (pwd.h and > .dmrc) and AccountsService > (http://cgit.freedesktop.org/accountsservice/). AccountsService is a > relatively new D-Bus service that was started in January 2010 that > wraps up user information into a D-Bus service and abstracts away > account manipulation. > > I think AccountsService is a really great piece of software and I'd > like to see it widely adopted and LightDM have a hard dependency on > it. The question is: if you are a consumer or potential consumer of > LightDM is this an issue? > > Specifically: > GNOME - developed from GNOME, so not a blocker > KDE - ? > Oracle - ? > LXDE - ? > XFCE - ? > Elementary - ? > Other - ? > > Thanks, > --Robert > _______________________________________________ > LightDM mailing list > LightDM at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/lightdm >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20110818/a4199a23/attachment.html>
On jeu., 2011-08-18 at 11:14 +1000, Robert Ancell wrote:> Currently LightDM supports both legacy password/preferences (pwd.h and > .dmrc) and AccountsService > (http://cgit.freedesktop.org/accountsservice/). AccountsService is a > relatively new D-Bus service that was started in January 2010 that > wraps up user information into a D-Bus service and abstracts away > account manipulation. > > I think AccountsService is a really great piece of software and I'd > like to see it widely adopted and LightDM have a hard dependency on > it. The question is: if you are a consumer or potential consumer of > LightDM is this an issue? > > Specifically: > GNOME - developed from GNOME, so not a blocker > KDE - ? > Oracle - ? > LXDE - ? > XFCE - ? > Elementary - ? > Other - ?Keeping the whole quote and adding Xfce on CC:, I don't think they read the lightdm list. I don't know much about accountservice. I'm not completely against some way to share the burdain and prevent code duplication, but I kind of wonder if it's not over-engineering something. dmrc seems to work fine and could have been a standard (at least an unofficial one) simple enough to be tuned with a text editor, so support for various desktops is already done. Now I'm not exactly sure how desktops are supposed to manage stuff in accountservices maybe it simple enough, but in Xfce cases at least there are some manpower issues meaning that support might lag a bit (or not be done at all). Not sure how bad it is and if there are other way to tune account informations. Regards, -- Yves-Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20110818/01800208/attachment.pgp>
On 18 August 2011 15:02, PCMan <pcman.tw at gmail.com> wrote:> On Thu, Aug 18, 2011 at 9:50 AM, Robert Ancell <robert.ancell at gmail.com> >> Is LXDE opposed to the concept or the particular implementation? > > The concept looks good, but I just felt that we have more and more *Kit and > *Service which kept us from KISS. > Having many options is the best part of OSS world, but it's also the most > problematic part. > Sometimes having only one robust and simple solution for one problem is > better than having a lot of various options. > The best example for this is the ALSA/OSS/OSS4/Jack/esound mess. > Someone wants to solve this with a common interface, pulseaudio. > Apparently it brings more problems at the same time and make correctly > configuring our systems difficult. > > UDisks is another example. Traditionally we have various ways for distros to > control device access rights. With udisks and policykit, how to correctly > configure user permissions becomes a FAQ and few people really know how to > use them. > If possible, I prefer avoiding unnecessary complexity added to existing > stack. Most of time, KISS is better. > I'm not against the idea, but I'm just worry about the increasing numbers of > deamons, services, abstraction layers, and stacks.The reason I see for a system like accounts service is the current API for user accounts (i.e. the passwd, shadow and various config files / programs) is old, inconsistent between OS's, hasn't changed in many years and is unable/unwilling to do so. It's not competing against other services so it's not in the same problem as the audio system is (who has responsibility for what in audio?). The worst outcome would be for multiple next generation accounts services to be created instead of us all using the same one. I think a modern service better meets the KISS principle, as the current solution is highly complex and inconsistent. Absolutely agree that systems like PolicyKit have very poor documentation which makes them very hard to understand.