Nicolas Williams schrieb: > On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote: >> This sort of design is contrary to the way people want GDM to work >> on other distros, so I am unsure if the changes needed to make it work >> this way would go upstream. Most other distros want it to work with >> all local userids out-of-the-box as it does in other popular operating >> systems. > > I don't think the local user heuristics are a good idea on any Unix or > Unix-like OS. I don't mind if the upstream community prefers to have > those heuristics on Linux or *BSD, but I don't think those heuristics > are at all appropriate, so let's not have those on Solaris. >
Browsable user lists [*] are a standard feature of the login experience on most systems. They should be usable out of the box on a newly installed system. Local users added during installation or using local management tool should usually be part of the browseable list. Obviously these user browsers have a problem when used with a usually large user list from a central name service. Another reason not to show all users from a network name service is that the computer may still be a personal one that is (almost) never used by anyone but the owner. The local/non-local distinction seems to be an obvious one to reconcile these requirements. But with local accounts a set of rules is needed to eliminate the system accounts. [*] The term 'Face Browser' is misleading here. There is absolutely no need to use photos of the users as the login picture. > IMO: yes, but I'm not an ARC member. Moreover, I think solving (a) > makes it trivial to solve (b) -- we've discussed a variety of schemes > that solve (b) already. > I don't see that. This is about a browsable user list, not about having anyone's actual face in that list. >> - If the new GDM does not meet requirement (b) then does this mean that >> we need to disable the Face Browser so it can't be used, or just be >> turned off by default? > > I'd say "disable the Face Browser so it can't be used". > I'd say that is too hard. I may want to use the face browser, even if some stray accounts that aren't meant for actual login show up at the end of the list over time. It would be useful to have an admin-accessible exclusion list so I can at least fix that locally, like old gdm had. I believe a design goal of new gdm was to avoid requiring admins to have to configure this kind of things over and over. But not having such a list means that third-party developers that need to add special user accounts for their layered products have no way to hide their accounts from the list. The alternative design is see is to have a positive list of accounts to always include and to make interactive install and local GUI tools for user administration add new users to that list (by default). Accounts for which this had been missed could still become browseable through the history. We'd still need a way to filter accounts like root from the history, but here the uid<100 rule might be sufficient (vs. more extensive heuristics. Such a positive list should become a freedektop.org standard, in order to get it supported accross display managers and user management tools. That makes this a longer-term effort. >> - Assuming we have time to meet both requirements, will the Face Browser >> be turned on or off by default? > > IMO: on by default. Whether AI disables it by default is another matter > (and, IMO, AI should disable it by default). > Why? >> I also suggest it could work: >> >> - Nobody shows up initially >> - The users show up in the face browser after you log into them the >> first time. > > Yes that's fine. > The part where nobody shows up initially and newly added local users also don't show up is what I don't agree to: - Mummy, you said you'd make me an account on the computer - But Nick, I did - But it doesn't know me! I am not in the list! (And that can happen not only with children. Why should people have to remember and type correctly a strange shorthand user 'name', when the can find and select their real name in almost on almost all systems.) >>> The whole notion of that GDM needs to care about whether a user is local >>> or not is broken. Please remove it. On a personal computer with a few accounts which I - the owner - have added myself, I want all of them to show up in the list by default. Without me having to remember obscure user names or having to copy files into strange locations assigning equally obscure file names. If I am on a network that provides a long list of centrally configured accounts, I don't really want all of those to show up on my login screen. Here the history-only mechanism is a reasonable choice. And I definitely don't want accounts (local or not) which aren't for real people but internal mechanisms of some piece of software in my list. If there aren't reliable interfaces for all these distinctions, it may require heuristics to satisfy those requirements. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
