From mpgritti at gmail.com Thu May 1 12:47:47 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Thu, 1 May 2008 14:47:47 +0200 Subject: Online Desktop run-through redux In-Reply-To: <1209381858.31626.1.camel@cookie.hadess.net> References: <1209156591.5014.41.camel@huygens.home.fishsoup.net> <1209381858.31626.1.camel@cookie.hadess.net> Message-ID: On Mon, Apr 28, 2008 at 1:24 PM, Bastien Nocera wrote: > > On Fri, 2008-04-25 at 16:49 -0400, Owen Taylor wrote: > > > > * On Fedora 9 (and on all GNOME-2.22?) the dialog > > you get when you select "Log out or Shutdown..." > > only allows you to log out, not to shut down. > > > > http://bugzilla.gnome.org/show_bug.cgi?id=529967 > > Fedora ships with the new GDM, upstream GNOME shipped gdm 2.20. Probably > something Fedora specific. FWIW, the logout dialogue on my F8 system > only shows logout, shutdown is a different menu item. Yeah, it's fedora specific: https://bugzilla.redhat.com/show_bug.cgi?id=444870 Marco From mcepl at redhat.com Fri May 2 16:41:47 2008 From: mcepl at redhat.com (=?utf-8?b?TWF0xJtq?= Cepl) Date: Fri, 2 May 2008 16:41:47 +0000 (UTC) Subject: few ideas how to make fedora better as a desktop References: <64b14b300803250330q1aeb24dbsda367a7dc9db91d8@mail.gmail.com> <1206528868.4412.52.camel@localhost.localdomain> <64b14b300803260442x15a90e39sf7c68832e6e8a9d3@mail.gmail.com> <1206540796.4412.58.camel@localhost.localdomain> Message-ID: Alexander Larsson redhat.com> writes: > The thread I linked to contains a couple of real-life examples. > > Basically it forces every selection change to be copied to another > process, and the selection changes all the time and can be large. This > can be very slow. It also means you're not able to do smart things when > you cut and paste inside an application (which is the common operation, > and which basically every application uses). So, what is the *proper* solution to this? Something changed in X? Or would just limiting the size of the object to be put into glipper be enough? Mat?j From ajackson at redhat.com Tue May 6 14:04:49 2008 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 06 May 2008 10:04:49 -0400 Subject: few ideas how to make fedora better as a desktop In-Reply-To: References: <64b14b300803250330q1aeb24dbsda367a7dc9db91d8@mail.gmail.com> <1206528868.4412.52.camel@localhost.localdomain> <64b14b300803260442x15a90e39sf7c68832e6e8a9d3@mail.gmail.com> <1206540796.4412.58.camel@localhost.localdomain> Message-ID: <1210082689.2308.1.camel@localhost.localdomain> On Fri, 2008-05-02 at 16:41 +0000, Mat?j Cepl wrote: > Alexander Larsson redhat.com> writes: > > The thread I linked to contains a couple of real-life examples. > > > > Basically it forces every selection change to be copied to another > > process, and the selection changes all the time and can be large. This > > can be very slow. It also means you're not able to do smart things when > > you cut and paste inside an application (which is the common operation, > > and which basically every application uses). > > So, what is the *proper* solution to this? Something changed in X? Or would just > limiting the size of the object to be put into glipper be enough? I'm pretty well convinced by now that the only way to do c&p sanely is to do it with something other than X selections. There's just no way to overload selections with sensible behaviour while preserving all the semantics that unix nerds are used to. Take off and nuke the site from orbit. I'm happy to add the feature to X if we know what we want it to act like in Gnome. - ajax From CarstenBreuerFDDesk at textwork.de Wed May 14 22:54:49 2008 From: CarstenBreuerFDDesk at textwork.de (Carsten Breuer) Date: Thu, 15 May 2008 00:54:49 +0200 Subject: No Network with Network-Manager Daemon Message-ID: <482B6DB9.20904@textwork.de> Hi all, i have updated FC8 at may, 14. After that my network was broken. eth0 was up but there was no proper setup of the route. After /etc/init.d/network restart everything was fine (since the next reboot). It seems to me that NetworkManager Daemon make worse things? Is this a new daemon? Best Regards, Carsten Breuer From dcbw at redhat.com Thu May 15 14:24:36 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 May 2008 10:24:36 -0400 Subject: No Network with Network-Manager Daemon In-Reply-To: <482B6DB9.20904@textwork.de> References: <482B6DB9.20904@textwork.de> Message-ID: <1210861476.24995.31.camel@localhost.localdomain> On Thu, 2008-05-15 at 00:54 +0200, Carsten Breuer wrote: > Hi all, > > > i have updated FC8 at may, 14. > After that my network was broken. > eth0 was up but there was no proper setup > of the route. > After /etc/init.d/network restart > everything was fine (since the next reboot). > > It seems to me that NetworkManager Daemon > make worse things? > > Is this a new daemon? Nope; it's been around since FC3 at least. Had you turned NetworkManager on before May 14th? It wasn't turned on in F8 by default, so if it's running now then either (a) you turned it on, or (b) I messed up the packaging and it's getting turned on in the %post or something. Is your eth0 supposed to be your default route to the internet, and do you have a list of custom routes defined for the eth0 device when it's brought up? Dan From CarstenBreuerFDDesk at textwork.de Thu May 15 17:36:02 2008 From: CarstenBreuerFDDesk at textwork.de (Carsten Breuer) Date: Thu, 15 May 2008 19:36:02 +0200 Subject: No Network with Network-Manager Daemon In-Reply-To: <1210861476.24995.31.camel@localhost.localdomain> References: <482B6DB9.20904@textwork.de> <1210861476.24995.31.camel@localhost.localdomain> Message-ID: <482C7482.2020808@textwork.de> Hi Dan, hi all, >> It seems to me that NetworkManager Daemon >> make worse things? >> Is this a new daemon? > Nope; it's been around since FC3 at least. Had you turned > NetworkManager on before May 14th? It wasn't turned on in F8 by > default, so if it's running now then either (a) you turned it on, or (b) > I messed up the packaging and it's getting turned on in the %post or > something. I can't say for sure that it was not running before, but if i read the mail from logwatch right, it was installed with that update: Packages Installed: kdegraphics-libs - 7:3.5.9-2.fc8.i386 PersonalCopy-Lite-patches - 4.1-3.fc8.noarch imlib - 1:1.9.15-6.fc8.i386 NetworkManager - 1:0.7.0-0.6.7.svn3370.fc8.i386 system-config-network-tui - 1.5.5-1.fc8.noarch kdebase-libs - 6:3.5.9-7.fc8.i386 NetworkManager-glib - 1:0.7.0-0.6.7.svn3370.fc8.i386 kernel-devel - 2.6.24.5-85.fc8.i686 libpaper - 1.1.22-1.fc8.1.i386 python-mpd - 0.2.0-3.fc8.noarch kernel - 2.6.24.5-85.fc8.i686 poppler-qt - 0.6.2-1.fc8.i386 Packages Updated: kdebase - 6:3.5.9-7.fc8.i386 perl - 4:5.8.8-39.fc8.i386 shared-mime-info - 0.23-2.fc8.i386 rsync - 2.6.9-5.fc8.i386 openoffice.org-langpack-en - 1:2.3.0-6.14.fc8.i386 libgnomeprint22-devel - 2.18.4-1.fc8.i386 systemtap-runtime - 0.6.2-1.fc8.i386 openoffice.org-core - 1:2.3.0-6.14.fc8.i386 ...... I make the update from the console (yum update), so i think that there are dependencies with NetworkManager. > Is your eth0 supposed to be your default route to the internet, Yes. i only setup the default gateway address of the router. I have seen that eth0 is more often switched on and off during boot if NetworkManager is active and i first thought that Fedora is trying to configure the route during the off period. > and do > you have a list of custom routes defined for the eth0 device when it's > brought up? No. I only do the default fedora network setup (ip, netmask, DNS, Gateway). I never changed anything in the routing. Thanks for replying and Best Regards, Carsten From mclasen at redhat.com Thu May 22 17:59:00 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 22 May 2008 13:59:00 -0400 Subject: A new user management tool Message-ID: <1211479140.4922.13.camel@localhost.localdomain> We (Jon McCann and myself, with some input from others) have been working on a design for a new user management tool, with the goal of coming up with something better than the current trias of system-config-users, gnome-about-me and gdmsetup. The design is not finalized, you can see the current state of affairs here: http://people.redhat.com/mclasen/user-account3.pdf.bz2 (I really wanted to put this on the wiki, but all I could only get proxy errors when trying to do so). Comments are welcome. Please note the section on target audience and use cases. Matthias From stevelist at silverorange.com Thu May 22 18:32:17 2008 From: stevelist at silverorange.com (Steven Garrity) Date: Thu, 22 May 2008 15:32:17 -0300 Subject: A new user management tool In-Reply-To: <1211479140.4922.13.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> Message-ID: <4835BC31.1080704@silverorange.com> Matthias Clasen wrote: > Comments are welcome. Please note the section on target audience and use > cases. Perhaps a note with the Short Name field on the "Create a new user" dialog explaining the basic limitations (no spaces, special chars, etc.) Maybe even auto-generate the Short Name if the field is empty when Name is entered? Turn "Ed Jones" into "edjones", etc.? Cheers, Steven Garrity From wwoods at redhat.com Thu May 22 19:39:26 2008 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 May 2008 15:39:26 -0400 Subject: A new user management tool In-Reply-To: <4835BC31.1080704@silverorange.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> Message-ID: <1211485166.3181.11.camel@metroid.rdu.redhat.com> On Thu, 2008-05-22 at 15:32 -0300, Steven Garrity wrote: > Matthias Clasen wrote: > > Comments are welcome. Please note the section on target audience and use > > cases. > Maybe even auto-generate the Short Name if the field is empty when Name > is entered? Turn "Ed Jones" into "edjones", etc.? It's already in the design document, at the bottom of page 3: "The tool then generates a Unix username from the full name and prefills the Short Name field. There was some idea to define a set of rules for this (e.g. Matthias Clasen?mclasen or Jon McCann?jonm) and update the currently used rule based on the corrections that are made to the pregenerated username." -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From skvidal at fedoraproject.org Thu May 22 20:09:08 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 16:09:08 -0400 Subject: A new user management tool In-Reply-To: <1211485166.3181.11.camel@metroid.rdu.redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <1211485166.3181.11.camel@metroid.rdu.redhat.com> Message-ID: <1211486948.9686.4.camel@cutter> On Thu, 2008-05-22 at 15:39 -0400, Will Woods wrote: > On Thu, 2008-05-22 at 15:32 -0300, Steven Garrity wrote: > > Matthias Clasen wrote: > > > Comments are welcome. Please note the section on target audience and use > > > cases. > > > Maybe even auto-generate the Short Name if the field is empty when Name > > is entered? Turn "Ed Jones" into "edjones", etc.? > > It's already in the design document, at the bottom of page 3: > > "The tool then generates a Unix username from the full name and prefills > the Short Name field. There was some idea to define a set of rules for > this (e.g. Matthias Clasen?mclasen or Jon McCann?jonm) and update the > currently used rule based on the corrections that are made to the > pregenerated username." > Umm, is the above really a problem we need to solve? Is there a great problem with people being able to create usernames? -sv From mclasen at redhat.com Thu May 22 20:20:25 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 22 May 2008 16:20:25 -0400 Subject: A new user management tool In-Reply-To: <1211486948.9686.4.camel@cutter> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <1211485166.3181.11.camel@metroid.rdu.redhat.com> <1211486948.9686.4.camel@cutter> Message-ID: <1211487625.4732.2.camel@localhost.localdomain> On Thu, 2008-05-22 at 16:09 -0400, seth vidal wrote: > On Thu, 2008-05-22 at 15:39 -0400, Will Woods wrote: > > On Thu, 2008-05-22 at 15:32 -0300, Steven Garrity wrote: > > > Matthias Clasen wrote: > > > > Comments are welcome. Please note the section on target audience and use > > > > cases. > > > > > Maybe even auto-generate the Short Name if the field is empty when Name > > > is entered? Turn "Ed Jones" into "edjones", etc.? > > > > It's already in the design document, at the bottom of page 3: > > > > "The tool then generates a Unix username from the full name and prefills > > the Short Name field. There was some idea to define a set of rules for > > this (e.g. Matthias Clasen?mclasen or Jon McCann?jonm) and update the > > currently used rule based on the corrections that are made to the > > pregenerated username." > > > > Umm, is the above really a problem we need to solve? Is there a great > problem with people being able to create usernames? There is no problem being solved here, just a tiny bit of smart convenience added. You can still specify a username yourself if you like. From dwinship at redhat.com Thu May 22 20:52:34 2008 From: dwinship at redhat.com (Dan Winship) Date: Thu, 22 May 2008 16:52:34 -0400 Subject: A new user management tool In-Reply-To: <1211479140.4922.13.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> Message-ID: <4835DD12.5020609@redhat.com> Matthias Clasen wrote: > The main dialog Looks too much like the OS X one, particularly in the way that "Login Options" is in a place where it doesn't make sense. :) > The Email, Language and Location fields are here because they are > frequently useful... I assume "Location" will tie in in some way with the improved Location/Time Zone stuff? > The password dialog An alternate UI possibility would be to autogenerate a few passwords of different strength levels and put them directly in the actions list: Choose a password now Choose a password at next login Use this random password: zintelforb Use this random password: fas42Br0x Use this random password: y8Tx$mrA Allow login without a password I don't think "Disable this account" belongs in the password dialog, even though that's how it's implemented underneath. > We've discussed ways to generate useful hints to go along with generated > passwords, including somewhat crazy ideas like computer?generated poetry > (cf gnoetry). Hm... how could that work though? Without knowing at least one "secret" about the user besides their password, how can you autogenerate a hint that will make sense to them (when they've forgotten their password), but not make just as much sense to anyone else? "Sites where people use randomly-generated passwords" and "sites that allow password hints" are probably mostly orthogonal anyway. -- Dan From mclasen at redhat.com Thu May 22 21:09:04 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 22 May 2008 17:09:04 -0400 Subject: A new user management tool In-Reply-To: <4835DD12.5020609@redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835DD12.5020609@redhat.com> Message-ID: <1211490544.4732.13.camel@localhost.localdomain> On Thu, 2008-05-22 at 16:52 -0400, Dan Winship wrote: > Matthias Clasen wrote: > > The main dialog > > Looks too much like the OS X one, particularly in the way that "Login > Options" is in a place where it doesn't make sense. :) Yeah. Thats only gimped in anyway, and won't work like that in a real treeview. > > The Email, Language and Location fields are here because they are > > frequently useful... > > I assume "Location" will tie in in some way with the improved > Location/Time Zone stuff? You tell us :-) I don't know how much thought Jon has put into this particular field... > > The password dialog > > An alternate UI possibility would be to autogenerate a few passwords of > different strength levels and put them directly in the actions list: > > Choose a password now > Choose a password at next login > Use this random password: zintelforb > Use this random password: fas42Br0x > Use this random password: y8Tx$mrA > Allow login without a password > > I don't think "Disable this account" belongs in the password dialog, > even though that's how it's implemented underneath. Unless it is implemented via /usr/bin/nologin...but you have a point. > > We've discussed ways to generate useful hints to go along with generated > > passwords, including somewhat crazy ideas like computer?generated poetry > > (cf gnoetry). > > Hm... how could that work though? Without knowing at least one "secret" > about the user besides their password, how can you autogenerate a hint > that will make sense to them (when they've forgotten their password), > but not make just as much sense to anyone else? It is a hint that helps you remember your password, not a challenge/response pair to use instead of your password. Anyway, I don't think generated hints are very high on the priority list - it was just an idea that came up during discussion. From mcepl at redhat.com Fri May 23 09:19:37 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 11:19:37 +0200 Subject: A new user management tool References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> Message-ID: <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> On 2008-05-22, 18:32 GMT, Steven Garrity wrote: > Matthias Clasen wrote: >> Comments are welcome. Please note the section on target audience and use >> cases. > > Perhaps a note with the Short Name field on the "Create a new user" > dialog explaining the basic limitations (no spaces, special chars, etc.) Could we just call it "Login name"? This sounds really like a bad macintoshism to me -- generating nonsensical name just for sake of not sounding like a computerese -- even the Aunt Tillie these days knows what login name is, and this duo "Name/Short Name" is guaranteed to confuse everybody. Mat?j From nphilipp at redhat.com Fri May 23 10:23:56 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 May 2008 12:23:56 +0200 Subject: A new user management tool In-Reply-To: <1211479140.4922.13.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> Message-ID: <1211538236.9887.70.camel@gibraltar.str.redhat.com> On Thu, 2008-05-22 at 13:59 -0400, Matthias Clasen wrote: > We (Jon McCann and myself, with some input from others) have been > working on a design for a new user management tool, with the goal of > coming up with something better than the current trias of > system-config-users, gnome-about-me and gdmsetup. > > The design is not finalized, you can see the current state of affairs > here: http://people.redhat.com/mclasen/user-account3.pdf.bz2 > (I really wanted to put this on the wiki, but all I could only get proxy > errors when trying to do so). > > Comments are welcome. Please note the section on target audience and use > cases. [...] > The target usage scenarios are home and smb, not enterprise customers and big deployments, > although we do need to make sure that the tools not totally break down when used in a big > deployment scenario, since users should still be able to use it for changing their own account. > But we do expect system administrators in enterprise settings to use a web interface to their > directory server, not this tool. That's a pretty daring assumption IMO. I don't think that there should be one tool for both home/smb and enterprise (or home and smb/enterprise, but I digress ;-), but I'm not sold to the idea that enterprise admins will want to use web interfaces over native tools anytime soon, assuming that native interfaces will always outperform web interfaces for the same job (more performance with a given level of convenience, or more convenience with given level of performance). And, just as a datapoint, there are people using s-c-users against an LDAP directory ;-). I'd like to think that a backend handling the conventional passwd type of stuff should be able to cater for more than one use case. This would make it fairly easy to implement several UIs on top of it for the different use cases: graphical home/smb and enterprise, text-mode and what have you -- and I'm pretty sure that we'll (have to) end up with something like that anyway. Whether or not that same backend would handle the non-Unix properties of users would need some dicussion, I don't have a firm opinion on that one. > Another use case is temporary access to a computer (guest account). The proposed workflow > for this is to offer a "Guest" user on the login screen. Selecting this user will not ask for a > password, the account will have limited privileges (Account type: Guest), and all data will be > removed at the end of the session, unless the user chooses 'Convert to normal account' from the > menu of the user?switch applet. Todo: this is not reflected in the screenshots below. I trust that the ability to convert a guest account to a normal one would be protected by an appropriate amount of PolicyKit ;-)? > The Name field is first, since we expect the full name to be entered first. The tool then > generates a Unix username from the full name and prefills the Short Name field. There was > some idea to define a set of rules for this (e.g. Matthias Clasen?mclasen or Jon > McCann?jonm) and update the currently used rule based on the corrections that are made to > the pregenerated username. We do need to validate the Name and Short Name fields to ensure > that there are no conflicts with existing users. While it is technically possible to have two users > with the same Name, we at last want to ask 'Did you really mean to do this ?'. Ignoring technical possibility (which is just a side effect of that the full name has no bearing w.r.t. the Unix side of things), we shouldn't allow this, to avoid confusion about which "John Doe" a user should log into in the login greeter. > Likewise, the home directory, the uid and gid, the shell, and other uninteresting pieces of > legacy information will be automatically determined by the tool and/or the service. People who > have a strong interest in these will probably be better served by useradd anyway. ... or a suitable different frontend ;-). > Clicking on the face image brings up a dialog for selecting the user image which offers a set of > predefined images, as well as an option to use a webcam (if available), a simple drawing tool > (such as MeMaker) or pick an image from the filesystem. Fine point: when showing the > predefined faces, we should indicate which ones are already 'taken'. This dialog has not been > mocked up yet. > When creating a new user, it initially gets a randomly picked image from the predefined > images (excluding those that are already used for a different user) I don't think that's a good idea, as there are too many ways to unintentionally insult people by picking the wrong one, even colors can have bad connotations in some cultures ("Your @*?$"!?%" tool picked {a monkey, something green, ...} for my account, now I'll {have your guts, not do any business with you again, ...}!"). > The Account Type field associates (still to be implemented) PolicyKit 'roles' with the account. > The Password field shows information about the kind of password that is currently set. The > password change dialog is a bit more complicated than the other change dialogs, and is > discussed in a separate section below. > The Email, Language and Location fields are here because they are frequently useful (e.g. the > language is needed on the login screen to relieve gdm from storing this information in .dmrc). > Also, they are part of the standard LDAP user schema. Todo: these dialogs should perhaps > provide some hints as to how these fields are used. E.g. entering an email address here does > not create an email account or set up the mail client to use it. At least for some SMBs (those who don't trust Google/Yahoo/... with their mails), a user mgmt tool should at some point (by way of a plugin or else) do exactly that, e.g. log into the company's cyrus-imapd and create a mailbox for the user. Maybe that's better suited for the enterprisey kind of user mgmt tool, however. > The Parental Controls field is just an idea that needs to be fleshed out. > Beyond direct user management, we also want the new tool to take up some login screen > configuration (which is, after all, more or less related to users and passwords). Shouldn't that be somehow done in the login greeter so you directly see your changes (suitably authenticated of course)? > The service will certainly have the expected Create, Delete, Modify functions dealing with > individual users. It is well?known that it is a bad idea to have a enumerate?all?users function, > since the cost may be prohibitive and user interfaces that rely on such a function will simply > not work in large deployments (cf fast?user?switch?applet vs NIS). Which makes "Show list of users" in the login settings kind of dead in the water, unless that list of users is somehow limited, e.g. to people who were logged into the system in a certain timeframe (e.g. since 4 weeks before the last successful login), and/or people who have been created on that system, ... > By the same token, > exposing every user as a dbus object will not work very well in such situations. One idea > (inspired by LDAP again) is to have a Query function that allows querying for users by certain > criteria. ... which would return the list of user names and create the matching dbus objects? Sounds sensible to me. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri May 23 10:41:29 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 May 2008 12:41:29 +0200 Subject: A new user management tool In-Reply-To: <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> Message-ID: <1211539289.9887.83.camel@gibraltar.str.redhat.com> On Fri, 2008-05-23 at 11:19 +0200, Matej Cepl wrote: > Could we just call it "Login name"? This sounds really like a bad > macintoshism to me -- generating nonsensical name just for sake > of not sounding like a computerese -- even the Aunt Tillie these > days knows what login name is, and this duo "Name/Short Name" is > guaranteed to confuse everybody. I concur. The connotation "Login screen" <-> "Login name" should be easier made than "Login screen" <-> "Short name". People are hardly confused by seeing their real names in the login screen if there is a list of users, but they need to make that connotation if they only see "User Name: ______ Password: _____". As a side note, I don't like the login screen a bit for going corporate on me by using full names instead of given ones (or nicknames?). I haven't seen a Mac or Windows user using a full name on his home computer anyway ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri May 23 10:46:43 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 May 2008 12:46:43 +0200 Subject: A new user management tool In-Reply-To: <4835DD12.5020609@redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835DD12.5020609@redhat.com> Message-ID: <1211539603.9887.89.camel@gibraltar.str.redhat.com> On Thu, 2008-05-22 at 16:52 -0400, Dan Winship wrote: > I assume "Location" will tie in in some way with the improved > Location/Time Zone stuff? I'm interested in that part as well -- if we map locations to timezones (which I guess isn't trivial), there should be one component doing it, regardless of if that frontend is s-c-date or a desktop-specific/user-centric tool. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mclasen at redhat.com Fri May 23 12:36:20 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 23 May 2008 08:36:20 -0400 Subject: A new user management tool In-Reply-To: <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> Message-ID: <1211546180.4743.1.camel@localhost.localdomain> On Fri, 2008-05-23 at 11:19 +0200, Matej Cepl wrote: > On 2008-05-22, 18:32 GMT, Steven Garrity wrote: > > Matthias Clasen wrote: > >> Comments are welcome. Please note the section on target audience and use > >> cases. > > > > Perhaps a note with the Short Name field on the "Create a new user" > > dialog explaining the basic limitations (no spaces, special chars, etc.) > > Could we just call it "Login name"? This sounds really like a bad > macintoshism to me -- generating nonsensical name just for sake > of not sounding like a computerese -- even the Aunt Tillie these > days knows what login name is, and this duo "Name/Short Name" is > guaranteed to confuse everybody. > > Mat?j We're following the recommendations of gnome documentation team here: http://mail.gnome.org/archives/gnome-doc-list/2008-April/msg00028.html login (n., adj.) The act of logging in to a computer, or something related to logging in to a computer. Do not use "login" or "login name" as a synonym for username. Do not use "logon". From mclasen at redhat.com Fri May 23 13:06:21 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 23 May 2008 09:06:21 -0400 Subject: A new user management tool In-Reply-To: <1211538236.9887.70.camel@gibraltar.str.redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <1211538236.9887.70.camel@gibraltar.str.redhat.com> Message-ID: <1211547981.4743.18.camel@localhost.localdomain> On Fri, 2008-05-23 at 12:23 +0200, Nils Philippsen wrote: > > > The target usage scenarios are home and smb, not enterprise customers and big deployments, > > although we do need to make sure that the tools not totally break down when used in a big > > deployment scenario, since users should still be able to use it for changing their own account. > > But we do expect system administrators in enterprise settings to use a web interface to their > > directory server, not this tool. > > That's a pretty daring assumption IMO. I don't think that there should > be one tool for both home/smb and enterprise (or home and > smb/enterprise, but I digress ;-), but I'm not sold to the idea that > enterprise admins will want to use web interfaces over native tools > anytime soon, assuming that native interfaces will always outperform web > interfaces for the same job (more performance with a given level of > convenience, or more convenience with given level of performance). And, > just as a datapoint, there are people using s-c-users against an LDAP > directory ;-). I'd like to think that a backend handling the > conventional passwd type of stuff should be able to cater for more than > one use case. This would make it fairly easy to implement several UIs on > top of it for the different use cases: graphical home/smb and > enterprise, text-mode and what have you -- and I'm pretty sure that > we'll (have to) end up with something like that anyway. Whether or not > that same backend would handle the non-Unix properties of users would > need some dicussion, I don't have a firm opinion on that one. The backend needs to be flexible enough to support more enterprise-oriented frontends, sure. Perhaps that hasn't been stated clearly enough. Wrt to storage, I think we are pretty much within the standard LDAP user schema. > I trust that the ability to convert a guest account to a normal one > would be protected by an appropriate amount of PolicyKit ;-)? Of course. > > Clicking on the face image brings up a dialog for selecting the user image which offers a set of > > predefined images, as well as an option to use a webcam (if available), a simple drawing tool > > (such as MeMaker) or pick an image from the filesystem. Fine point: when showing the > > predefined faces, we should indicate which ones are already 'taken'. This dialog has not been > > mocked up yet. > > When creating a new user, it initially gets a randomly picked image from the predefined > > images (excluding those that are already used for a different user) > > I don't think that's a good idea, as there are too many ways to > unintentionally insult people by picking the wrong one, even colors can > have bad connotations in some cultures ("Your @*?$"!?%" tool picked {a > monkey, something green, ...} for my account, now I'll {have your guts, > not do any business with you again, ...}!"). Or maybe we just make the business customers use the other frontend... > At least for some SMBs (those who don't trust Google/Yahoo/... with > their mails), a user mgmt tool should at some point (by way of a plugin > or else) do exactly that, e.g. log into the company's cyrus-imapd and > create a mailbox for the user. Maybe that's better suited for the > enterprisey kind of user mgmt tool, however. In fact, an earlier draft of the design had the idea of plugins for this kind of setup tasks. Maybe we'll have to revisit it. For the client-side email setup, I guess you could get 90% of the way there sabayon - just give the user a sabayon profile that has all the mail configuration set up except for the email address, that evolution can then pick up from the user service... > > Beyond direct user management, we also want the new tool to take up some login screen > > configuration (which is, after all, more or less related to users and passwords). > > Shouldn't that be somehow done in the login greeter so you directly see > your changes (suitably authenticated of course)? The old gdm had something like that, and it was not very nice. Maybe it was just not very well done, with the configuration options being directly visible in a toolbar on the greeter, and all gtk themes in a long menu... > > The service will certainly have the expected Create, Delete, Modify functions dealing with > > individual users. It is well?known that it is a bad idea to have a enumerate?all?users function, > > since the cost may be prohibitive and user interfaces that rely on such a function will simply > > not work in large deployments (cf fast?user?switch?applet vs NIS). > > Which makes "Show list of users" in the login settings kind of dead in > the water, unless that list of users is somehow limited, e.g. to people > who were logged into the system in a certain timeframe (e.g. since 4 > weeks before the last successful login), and/or people who have been > created on that system, ... ...which is pretty much exactly what the user list in the greeter already does. From nphilipp at redhat.com Fri May 23 14:25:31 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 May 2008 16:25:31 +0200 Subject: A new user management tool In-Reply-To: <1211547981.4743.18.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> <1211538236.9887.70.camel@gibraltar.str.redhat.com> <1211547981.4743.18.camel@localhost.localdomain> Message-ID: <1211552731.9887.133.camel@gibraltar.str.redhat.com> On Fri, 2008-05-23 at 09:06 -0400, Matthias Clasen wrote: > The backend needs to be flexible enough to support more > enterprise-oriented frontends, sure. Perhaps that hasn't been stated > clearly enough. Wrt to storage, I think we are pretty much within the > standard LDAP user schema. Do you access LDAP directly or do you use libuser -- for s-c-users, libuser abstracted local user accounts from LDAP ones enough so that it could handle local as well as directory accounts without (any= much? haven't checked lately) distinction in the tool. > > > Clicking on the face image brings up a dialog for selecting the user image which offers a set of > > > predefined images, as well as an option to use a webcam (if available), a simple drawing tool > > > (such as MeMaker) or pick an image from the filesystem. Fine point: when showing the > > > predefined faces, we should indicate which ones are already 'taken'. This dialog has not been > > > mocked up yet. > > > When creating a new user, it initially gets a randomly picked image from the predefined > > > images (excluding those that are already used for a different user) > > > > I don't think that's a good idea, as there are too many ways to > > unintentionally insult people by picking the wrong one, even colors can > > have bad connotations in some cultures ("Your @*?$"!?%" tool picked {a > > monkey, something green, ...} for my account, now I'll {have your guts, > > not do any business with you again, ...}!"). > > Or maybe we just make the business customers use the other frontend... I think that point's valid enough for home users. Even if we ignore home/SMB use as a potential business market, we surely don't want to hurt users' feelings. I don't like having to jump through hoops to achieve that as much as anybody else, but I'd rather not pull a "Pajero"[1] if it can be avoided -- I recently read an article in the newspaper about clashes of cultures and it's amazing how things that are innocuous in one culture are offensive in another. [1]: http://en.wikipedia.org/wiki/Mitsubishi_Pajero > > Which makes "Show list of users" in the login settings kind of dead in > > the water, unless that list of users is somehow limited, e.g. to people > > who were logged into the system in a certain timeframe (e.g. since 4 > > weeks before the last successful login), and/or people who have been > > created on that system, ... > > ...which is pretty much exactly what the user list in the greeter > already does. That's nice. On account of not using LDAP/NIS/Kerberos on any of my systems (which have a gdm login screen), I wasn't aware of that it makes such a distinction. The last thing in that context I heard about was fast-user-switch-applet excessively burning CPU cycles to enumerate all NIS users (multiplied by a number of these applets running concurrently on a VNC/NX terminal server ;-), so I wanted to cover that bit. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mcepl at redhat.com Fri May 23 15:24:04 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 17:24:04 +0200 Subject: A new user management tool References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> <1211546180.4743.1.camel@localhost.localdomain> Message-ID: On Fri, 23 May 2008 08:36:20 -0400, Matthias Clasen scripst: > We're following the recommendations of gnome documentation team here: > http://mail.gnome.org/archives/gnome-doc-list/2008-April/msg00028.html > > login (n., adj.) > The act of logging in to a computer, or something related to logging in > to a computer. Do not use "login" or "login name" as a synonym for > username. Do not use "logon". OK, I used to be a lawyer, so I am used to distinguishing between authorities which I need to strongly adhere and to somebody who just made to much crack and nothing to do. I am afraid this falls squarely into the latter camp. Cannot we somehow object to this nonsense? Can I do something about it (so that we are not wasting your time)? Matej -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From davidz at redhat.com Fri May 23 15:37:27 2008 From: davidz at redhat.com (David Zeuthen) Date: Fri, 23 May 2008 11:37:27 -0400 Subject: A new user management tool In-Reply-To: References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> <1211546180.4743.1.camel@localhost.localdomain> Message-ID: <1211557047.3469.2.camel@davidz-x61.fubar.dk> On Fri, 2008-05-23 at 17:24 +0200, Matej Cepl wrote: > On Fri, 23 May 2008 08:36:20 -0400, Matthias Clasen scripst: > > We're following the recommendations of gnome documentation team here: > > http://mail.gnome.org/archives/gnome-doc-list/2008-April/msg00028.html > > > > login (n., adj.) > > The act of logging in to a computer, or something related to logging in > > to a computer. Do not use "login" or "login name" as a synonym for > > username. Do not use "logon". > > OK, I used to be a lawyer, so I am used to distinguishing between > authorities which I need to strongly adhere and to somebody who just made > to much crack and nothing to do. I am afraid this falls squarely into the > latter camp. I disagree. Besides, I'm not sure how useful is to bikeshed about strings in gimped up stuff. David From quasar at ja.rosz.org Fri May 23 17:27:46 2008 From: quasar at ja.rosz.org (Quasar Jarosz) Date: Fri, 23 May 2008 12:27:46 -0500 Subject: A new user management tool In-Reply-To: <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> Message-ID: <79f4f780805231027n6ef1deedl84845e52ec4c3fb3@mail.gmail.com> > Could we just call it "Login name"? This sounds really like a bad > macintoshism to me -- generating nonsensical name just for sake > of not sounding like a computerese -- even the Aunt Tillie these > days knows what login name is, and this duo "Name/Short Name" is > guaranteed to confuse everybody. I agree, Short Name sounds awful, and doesn't seem to mean anything. "Login name" or "Username" would make much more sense. Quasar From drago01 at gmail.com Fri May 23 19:35:31 2008 From: drago01 at gmail.com (drago01) Date: Fri, 23 May 2008 21:35:31 +0200 Subject: A new user management tool In-Reply-To: <79f4f780805231027n6ef1deedl84845e52ec4c3fb3@mail.gmail.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> <79f4f780805231027n6ef1deedl84845e52ec4c3fb3@mail.gmail.com> Message-ID: On Fri, May 23, 2008 at 7:27 PM, Quasar Jarosz wrote: >> Could we just call it "Login name"? This sounds really like a bad >> macintoshism to me -- generating nonsensical name just for sake >> of not sounding like a computerese -- even the Aunt Tillie these >> days knows what login name is, and this duo "Name/Short Name" is >> guaranteed to confuse everybody. > > I agree, Short Name sounds awful, and doesn't seem to mean anything. > "Login name" or "Username" would make much more sense. +1 From dwinship at redhat.com Fri May 23 21:36:20 2008 From: dwinship at redhat.com (Dan Winship) Date: Fri, 23 May 2008 17:36:20 -0400 Subject: A new user management tool In-Reply-To: <1211539603.9887.89.camel@gibraltar.str.redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <4835DD12.5020609@redhat.com> <1211539603.9887.89.camel@gibraltar.str.redhat.com> Message-ID: <483738D4.8000502@redhat.com> Nils Philippsen wrote: > On Thu, 2008-05-22 at 16:52 -0400, Dan Winship wrote: > >> I assume "Location" will tie in in some way with the improved >> Location/Time Zone stuff? > > I'm interested in that part as well -- if we map locations to timezones > (which I guess isn't trivial), there should be one component doing it, > regardless of if that frontend is s-c-date or a > desktop-specific/user-centric tool. See also http://fedoraproject.org/wiki/Features/TimeZoneAndLocation -- Dan From bnocera at redhat.com Fri May 23 23:19:02 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 00:19:02 +0100 Subject: A new user management tool In-Reply-To: References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> <1211546180.4743.1.camel@localhost.localdomain> Message-ID: <1211584742.3566.108.camel@cookie.hadess.net> On Fri, 2008-05-23 at 17:24 +0200, Matej Cepl wrote: > On Fri, 23 May 2008 08:36:20 -0400, Matthias Clasen scripst: > > We're following the recommendations of gnome documentation team here: > > http://mail.gnome.org/archives/gnome-doc-list/2008-April/msg00028.html > > > > login (n., adj.) > > The act of logging in to a computer, or something related to logging in > > to a computer. Do not use "login" or "login name" as a synonym for > > username. Do not use "logon". > > OK, I used to be a lawyer, so I am used to distinguishing between > authorities which I need to strongly adhere and to somebody who just made > to much crack and nothing to do. I am afraid this falls squarely into the > latter camp. Cannot we somehow object to this nonsense? Can I do something > about it (so that we are not wasting your time)? I'll reiterate what's in the mail, which is also in the dictionary: login is a verb, not a noun. FWIW, MacOS X qualifies it with "Unix" username. It should probably never be visible to the user though (so could easily be generated, or hidden in a disclosure triangle). Anybody fancies filing bugs about visible login names when apps should use the person's name? From bnocera at redhat.com Fri May 23 23:29:54 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 00:29:54 +0100 Subject: A new user management tool In-Reply-To: <1211547981.4743.18.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> <1211538236.9887.70.camel@gibraltar.str.redhat.com> <1211547981.4743.18.camel@localhost.localdomain> Message-ID: <1211585394.3566.116.camel@cookie.hadess.net> On Fri, 2008-05-23 at 09:06 -0400, Matthias Clasen wrote: > > At least for some SMBs (those who don't trust Google/Yahoo/... with > > their mails), a user mgmt tool should at some point (by way of a plugin > > or else) do exactly that, e.g. log into the company's cyrus-imapd and > > create a mailbox for the user. Maybe that's better suited for the > > enterprisey kind of user mgmt tool, however. > > In fact, an earlier draft of the design had the idea of plugins for this > kind of setup tasks. Maybe we'll have to revisit it. > For the client-side email setup, I guess you could get 90% of the way > there sabayon - just give the user a sabayon profile that has all the > mail configuration set up except for the email address, that evolution > can then pick up from the user service... I'm not sure we should be having e-mail addresses, or even e-mail setup in the system (unless it was possible to do for sysadmins as a Python plugin, or something). I have 6 e-mail addresses from different projects, some are aliases, some are different accounts, which would be too complicated to 1) present in the UI rationally, 2) setup without having people bored about the details when they're just trying to login. It would make more sense, for the "this is my e-mail" to be able to call up evolution's addressbook to be able to enter parts of that information, or have a way to import the data from somewhere else (beam a vCard from your phone). MacOS X has that "that vCard is me" concept in the addressbook as well. What we _could_ setup would be an GNOME Online Desktop login, that's been discussed previously for setting up a small storage, blog, etc. for single users, similar to .Mac. This would be less intrusive as a first step, but would certainly require more infrastructure. Cheers From nphilipp at redhat.com Mon May 26 09:43:06 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 26 May 2008 11:43:06 +0200 Subject: A new user management tool In-Reply-To: <1211585394.3566.116.camel@cookie.hadess.net> References: <1211479140.4922.13.camel@localhost.localdomain> <1211538236.9887.70.camel@gibraltar.str.redhat.com> <1211547981.4743.18.camel@localhost.localdomain> <1211585394.3566.116.camel@cookie.hadess.net> Message-ID: <1211794986.9337.8.camel@wombat.tiptoe.de> On Sat, 2008-05-24 at 00:29 +0100, Bastien Nocera wrote: > On Fri, 2008-05-23 at 09:06 -0400, Matthias Clasen wrote: > > > > At least for some SMBs (those who don't trust Google/Yahoo/... with > > > their mails), a user mgmt tool should at some point (by way of a plugin > > > or else) do exactly that, e.g. log into the company's cyrus-imapd and > > > create a mailbox for the user. Maybe that's better suited for the > > > enterprisey kind of user mgmt tool, however. > > > > In fact, an earlier draft of the design had the idea of plugins for this > > kind of setup tasks. Maybe we'll have to revisit it. > > For the client-side email setup, I guess you could get 90% of the way > > there sabayon - just give the user a sabayon profile that has all the > > mail configuration set up except for the email address, that evolution > > can then pick up from the user service... > > I'm not sure we should be having e-mail addresses, or even e-mail setup > in the system (unless it was possible to do for sysadmins as a Python > plugin, or something). That's roughly what I meant -- this would really only have a tangible benefit in multi user situations with homogenous email settings, e.g. a company where most users will have mail addresses that can be generated programatically ("username at domain.tld", "firstname.surname at domain.tld", ...), with known POP/IMAP/SMTP servers. Granted, "multi" may be as low as "2", for instance home user systems where you have one computer buff in the family who administrates the system. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From twoerner at redhat.com Mon May 26 17:52:40 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 26 May 2008 19:52:40 +0200 Subject: A new user management tool In-Reply-To: <1211479140.4922.13.camel@localhost.localdomain> References: <1211479140.4922.13.camel@localhost.localdomain> Message-ID: <483AF8E8.6000308@redhat.com> Matthias Clasen wrote: > We (Jon McCann and myself, with some input from others) have been > working on a design for a new user management tool, with the goal of > coming up with something better than the current trias of > system-config-users, gnome-about-me and gdmsetup. > > The design is not finalized, you can see the current state of affairs > here: http://people.redhat.com/mclasen/user-account3.pdf.bz2 > (I really wanted to put this on the wiki, but all I could only get proxy > errors when trying to do so). > > Comments are welcome. Please note the section on target audience and use > cases. > > > Matthias > > Please add fields to set and change user and group IDs - they are important especially in an enterprise environment. Am I right, that the "Login options" are not user specific? (No user is selected.) So please separate it from the users list and move it below the "Add"- and "Remove"-user buttons. Then it is more clear that you can not add and remove "Login options", but something in the list. BTW: I think it would be nice to give the list a description. If you do not like the word "login", then you could use these two: "User Name" and "Full Name". Thomas From nphilipp at redhat.com Tue May 27 08:00:25 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 27 May 2008 10:00:25 +0200 Subject: A new user management tool In-Reply-To: <1211584742.3566.108.camel@cookie.hadess.net> References: <1211479140.4922.13.camel@localhost.localdomain> <4835BC31.1080704@silverorange.com> <9qeig5xrt1.ln2@ppp1053.in.ipex.cz> <1211546180.4743.1.camel@localhost.localdomain> <1211584742.3566.108.camel@cookie.hadess.net> Message-ID: <1211875225.4446.12.camel@wombat.tiptoe.de> On Sat, 2008-05-24 at 00:19 +0100, Bastien Nocera wrote: > It should probably never be visible to the user though (so could easily > be generated, or hidden in a disclosure triangle). Anybody fancies > filing bugs about visible login names when apps should use the person's > name? Sometimes you need a username to differentiate between people that have the same real name. In Germany for instance, you'll find a lot of "Markus M?ller"s and I'm sure other languages have their share of common names as well, so that should be taken into account. A unix username is a good differentiator there IMO. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Tue May 27 08:06:42 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 27 May 2008 10:06:42 +0200 Subject: A new user management tool In-Reply-To: <483AF8E8.6000308@redhat.com> References: <1211479140.4922.13.camel@localhost.localdomain> <483AF8E8.6000308@redhat.com> Message-ID: <1211875602.4446.17.camel@wombat.tiptoe.de> On Mon, 2008-05-26 at 19:52 +0200, Thomas Woerner wrote: > Matthias Clasen wrote: > > We (Jon McCann and myself, with some input from others) have been > > working on a design for a new user management tool, with the goal of > > coming up with something better than the current trias of > > system-config-users, gnome-about-me and gdmsetup. > > > > The design is not finalized, you can see the current state of affairs > > here: http://people.redhat.com/mclasen/user-account3.pdf.bz2 > > (I really wanted to put this on the wiki, but all I could only get proxy > > errors when trying to do so). > > > > Comments are welcome. Please note the section on target audience and use > > cases. > > > > > > Matthias > > > > > > Please add fields to set and change user and group IDs - they are > important especially in an enterprise environment. I think this tool is meant especially for not enterprisey environments, for such you can use s-c-users if you want a native GUI which lets you set them. > Am I right, that the "Login options" are not user specific? (No user is > selected.) So please separate it from the users list and move it below > the "Add"- and "Remove"-user buttons. Then it is more clear that you can > not add and remove "Login options", but something in the list. BTW: I > think it would be nice to give the list a description. > > If you do not like the word "login", then you could use these two: "User > Name" and "Full Name". Sounds good to me. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011