From pemboa at gmail.com Tue Oct 2 17:43:36 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 2 Oct 2007 12:43:36 -0500 Subject: Default Firefox settings Message-ID: <16de708d0710021043q1414a664mff0b605dd285bfeb@mail.gmail.com> Hello, I recently asked about ways to benchmark Firefox[1] because of how slow I found Firefox to be on Fedora 7. It was almost unusably slow, prompting me to switch to Konqueror as much as possible. However I have found a short tutorial which after following the speed seems to at least be on par which my laptop (which has half the processing speed, and a slower, IDE hard drive, and slower memory) Assuming I haven't encountered some freak situation, it may be necessary to consider changing the default Firefox settings, one of which is IPV6 DNS. I have zero issues against IPV6 myself, but if it helps make Firefox useful, by all means. Again, if I can provide any objective metrics, please let me know. [1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html [2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From mclasen at redhat.com Wed Oct 3 16:47:54 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 03 Oct 2007 12:47:54 -0400 Subject: Desktop SIG meeting today ? Message-ID: <1191430074.3293.1.camel@localhost.localdomain> I just realized I will be on the road between 2 and 3, so I can't make the lead sig meeting. Maybe David or Chris can step up ? Matthias From bkonrath at redhat.com Wed Oct 3 19:34:04 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Wed, 03 Oct 2007 15:34:04 -0400 Subject: new user creation module in firstboot Message-ID: <1191440044.7817.28.camel@toast.toronto.redhat.com> Hi, I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction: http://bagu.org/scratch/createuser.ogv One open issue that I have is that I'd like to require that a user account be created by greying out the 'next' button until the information requested is complete and correct. If requiring a user account be created is not the best approach, what is the best way to allow the user skip this step? An initial idea I had was to grey out the 'next' button only when the user starts to enter information. The problem with this approach is that it's not easy for a user to cancel out of the account creation if they start the process but decide halfway through that they don't want a user account anymore. Any thoughts or comments would be appreciated. I've also been looking into using cheese to allow users to take a snapshot of their face with a webcam when they are creating their account in firstboot. The stock_person button in the video posted above would activate a dialog for this. I sent a message to cheese-list and one of the developers suggested that a dbus interface might work for this task. I created a mockup of what the interface for choosing a user image could look like: http://bagu.org/scratch/create-user-file.png http://bagu.org/scratch/create-user-webcam.png As you can see, there is a video preview from the webcam in the second mockup. I don't know dbus well enough to comment on if it's appropriate for this type of task. Does anybody know if dbus could work for this or have any other ideas? I'm also looking for comments on the UI design of the mockups. Thanks, Ben From mattdm at mattdm.org Wed Oct 3 19:43:45 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 3 Oct 2007 15:43:45 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> Message-ID: <20071003194345.GA1952@jadzia.bu.edu> On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote: > I'm working on a new user creation module for the new and improved > firstboot. I created a little video to give people an idea of the UI > interaction: > http://bagu.org/scratch/createuser.ogv Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username at localhost? There should also be an advanced button so that parameters like userid can be selected. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bkonrath at redhat.com Wed Oct 3 21:35:33 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Wed, 03 Oct 2007 17:35:33 -0400 Subject: new user creation module in firstboot In-Reply-To: <20071003194345.GA1952@jadzia.bu.edu> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> Message-ID: <1191447333.7817.42.camel@toast.toronto.redhat.com> On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote: > On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote: > > I'm working on a new user creation module for the new and improved > > firstboot. I created a little video to give people an idea of the UI > > interaction: > > http://bagu.org/scratch/createuser.ogv > > Email address? Where's that going to go? What will it be used for? And isn't > my e-mail address username at localhost? The Email address is intended to used to pull in account information from mugshot so using username at localhost wouldn't really work. > There should also be an advanced button so that parameters like userid can > be selected. This user creation module is intended to be used by desktop users, not systems administrators so having a place to select advanced options like userid doesn't really make sense. FWIW, the current user creation module doesn't have those options for local users either. Cheers, Ben From davidz at redhat.com Wed Oct 3 21:51:29 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 03 Oct 2007 17:51:29 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> Message-ID: <1191448289.3414.22.camel@oneill.fubar.dk> Hi, On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote: > Hi, > > I'm working on a new user creation module for the new and improved > firstboot. I created a little video to give people an idea of the UI > interaction: > > http://bagu.org/scratch/createuser.ogv This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right? If we want that we probably need to look at existing functionality in the desktop.. that includes system-config-users (Fedora specific) and the GNOME About Me dialog and how this would fit in. I'd probably say that we want to replace both. And in the same breath I would approach the GNOME community to get this done upstream so all distros can rally around it (share development and maintenance efforts). What is your take on that? Also, if we want this in the desktop environment (and I think we do) it needs to be written in a way that separates the mechanism (would run privileged, e.g. uid 0 however locked down by SELinux or whatever) from the user interface (would run unprivileged user). I'd probably suggest to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus (for activating the mechanism) for that, both of these (especially PK) are kinda written for this kind of thing [2]. Finally, it would be good to have this feature as a "Component" so it's easy to embed into other applications; e.g. if I want to write a OS installer app, then I can easily embed this component. Same, FWIW, goes for the work we're doing on the clock applet and in the future any system configuration bits. I think firstboot has /some/ notion of plug-in architecture but actually haven't reviewed it since I'm not sure it's appropriate in an environment where the UI should run unprivileged. But it just might work. David [1] : http://hal.freedesktop.org/docs/PolicyKit/ [2] : See e.g. http://blog.fubar.dk/?p=93 and http://blog.fubar.dk/?p=94 for some background From pemboa at gmail.com Wed Oct 3 21:58:14 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 3 Oct 2007 16:58:14 -0500 Subject: new user creation module in firstboot In-Reply-To: <1191447333.7817.42.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> Message-ID: <16de708d0710031458p29ee6537u2615b4459cca5ad6@mail.gmail.com> On 10/3/07, Ben Konrath wrote: > On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote: > > On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote: > > > I'm working on a new user creation module for the new and improved > > > firstboot. I created a little video to give people an idea of the UI > > > interaction: > > > http://bagu.org/scratch/createuser.ogv > > > > Email address? Where's that going to go? What will it be used for? And isn't > > my e-mail address username at localhost? > > The Email address is intended to used to pull in account information > from mugshot so using username at localhost wouldn't really work. > > > There should also be an advanced button so that parameters like userid can > > be selected. > > This user creation module is intended to be used by desktop users, not > systems administrators so having a place to select advanced options like > userid doesn't really make sense. FWIW, the current user creation module > doesn't have those options for local users either. > > Cheers, Ben if this is only targeted at desktop users.. what's wrong with firstboot? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From walters at redhat.com Wed Oct 3 22:09:32 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 3 Oct 2007 18:09:32 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191448289.3414.22.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> Message-ID: On 10/3/07, David Zeuthen wrote: > > This looks pretty smooth, thanks a lot for working on this. My first > reaction is that this is not something that should be limited to > firstboot; ideally stuff like that should be able to run from the > desktop environment when adding / deleting / managing users, right? We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM). From davidz at redhat.com Wed Oct 3 23:44:57 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 03 Oct 2007 19:44:57 -0400 Subject: new user creation module in firstboot In-Reply-To: References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> Message-ID: <1191455097.18732.1.camel@oneill.fubar.dk> On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote: > On 10/3/07, David Zeuthen wrote: > > > > This looks pretty smooth, thanks a lot for working on this. My first > > reaction is that this is not something that should be limited to > > firstboot; ideally stuff like that should be able to run from the > > desktop environment when adding / deleting / managing users, right? > > We had a design session on this; the idea was actually that you could > create new users from the login dialog (GDM). I agree that's an interesting idea that would replace the need for a firstboot module (and probably firstboot entirely). However, I think it's still needed as a program you can launch in the desktop session along with an icon in System->Administration. If only we had a component system... David From mclasen at redhat.com Wed Oct 3 23:55:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 03 Oct 2007 19:55:15 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> Message-ID: <1191455715.2648.10.camel@localhost.localdomain> On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote: > Hi, > > I'm working on a new user creation module for the new and improved > firstboot. I created a little video to give people an idea of the UI > interaction: > > http://bagu.org/scratch/createuser.ogv > > One open issue that I have is that I'd like to require that a user > account be created by greying out the 'next' button until the > information requested is complete and correct. > > If requiring a user account be created is not the best approach, what is > the best way to allow the user skip this step? An initial idea I had was > to grey out the 'next' button only when the user starts to enter > information. The problem with this approach is that it's not easy for a > user to cancel out of the account creation if they start the process but > decide halfway through that they don't want a user account anymore. Any > thoughts or comments would be appreciated. If we don't want to make the user creation mandatory, then it is probably best to not make the button insensitive at all. Instead, we can pop up a message telling the user why creating an account is a good idea when he tries to just click through. If he clicks the next button while the entered data is inconsistent or incomplete, we can pop up a warning telling him that the entered data does not allow to create an account. > I've also been looking into using cheese to allow users to take a > snapshot of their face with a webcam when they are creating their > account in firstboot. The stock_person button in the video posted above > would activate a dialog for this. I sent a message to cheese-list and > one of the developers suggested that a dbus interface might work for > this task. Not sure how dbus would come into this. I'd suggest to investigate a) just launching cheese with some argument that tells it to take a single snapshot and where to save it or b) just steal the relevant code from cheese and embed the video directly in the user dialog. Anyway, cool stuff. Matthias From mattdm at mattdm.org Thu Oct 4 01:26:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 3 Oct 2007 21:26:24 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191447333.7817.42.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> Message-ID: <20071004012624.GA14939@jadzia.bu.edu> On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote: > > Email address? Where's that going to go? What will it be used for? And > > isn't my e-mail address username at localhost? > The Email address is intended to used to pull in account information > from mugshot so using username at localhost wouldn't really work. My point is: how is the user presented with that form supposed to guess that? Mugshot integration sounds like a cool idea -- but why not present it as that? > > There should also be an advanced button so that parameters like userid > > can be selected. > This user creation module is intended to be used by desktop users, not > systems administrators so having a place to select advanced options like > userid doesn't really make sense. FWIW, the current user creation module > doesn't have those options for local users either. I'm a desktop user. I want to select my user id. This is a flaw in the current user creation module; if we're changing it, now's the time to fix it. Good design makes easy things easy and more complicated things possible. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mclasen at redhat.com Thu Oct 4 02:49:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 03 Oct 2007 22:49:06 -0400 Subject: new user creation module in firstboot In-Reply-To: <20071004012624.GA14939@jadzia.bu.edu> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> Message-ID: <1191466146.2648.18.camel@localhost.localdomain> On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote: > I'm a desktop user. I want to select my user id. This is a flaw in the > current user creation module; if we're changing it, now's the time to fix > it. > > Good design makes easy things easy and more complicated things possible. It also hides irrelevant things. Why do you need to select a specific user id when creating a new user ? I guess you are not creating a new user at all, but trying to recreate an existing one, to reuse the home directory, etc. Right ? From mattdm at mattdm.org Thu Oct 4 12:36:20 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 4 Oct 2007 08:36:20 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191466146.2648.18.camel@localhost.localdomain> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> <1191466146.2648.18.camel@localhost.localdomain> Message-ID: <20071004123620.GA513@jadzia.bu.edu> On Wed, Oct 03, 2007 at 10:49:06PM -0400, Matthias Clasen wrote: > > Good design makes easy things easy and more complicated things possible. > It also hides irrelevant things. Hence the "advanced" button. > Why do you need to select a specific user id when creating a new user ? > I guess you are not creating a new user at all, but trying to recreate > an existing one, to reuse the home directory, etc. Right ? Often, yes. But I also like to have all user ids the same at home so usernames on removable media just match up. I don't have complicated enough home network (or enough users!) to justify LDAP or even NIS, and anyway I need disconnected operation. So matching up user ids is nice. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gmureddu at prodigy.net.mx Thu Oct 4 14:07:38 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 04 Oct 2007 10:07:38 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191455097.18732.1.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> Message-ID: <4704F3AA.9030506@prodigy.net.mx> David Zeuthen escribi?: > On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote: > >> On 10/3/07, David Zeuthen wrote: >> >>> This looks pretty smooth, thanks a lot for working on this. My first >>> reaction is that this is not something that should be limited to >>> firstboot; ideally stuff like that should be able to run from the >>> desktop environment when adding / deleting / managing users, right? >>> >> We had a design session on this; the idea was actually that you could >> create new users from the login dialog (GDM). >> That would actually be a very cool idea, in my opinion. > > I agree that's an interesting idea that would replace the need for a > firstboot module (and probably firstboot entirely). However, I think > it's still needed as a program you can launch in the desktop session > along with an icon in System->Administration. If only we had a component > system... > > David > I thought that's why we had system-config-users for? Or am I missing something here? From abo at kth.se Thu Oct 4 15:37:48 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 04 Oct 2007 17:37:48 +0200 Subject: new user creation module in firstboot In-Reply-To: <20071004123620.GA513@jadzia.bu.edu> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> <1191466146.2648.18.camel@localhost.localdomain> <20071004123620.GA513@jadzia.bu.edu> Message-ID: <1191512268.5560.40.camel@home.alexander.bostrom.net> tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller: > > Often, yes. But I also like to have all user ids the same at home so > usernames on removable media just match up. I don't have complicated enough > home network (or enough users!) to justify LDAP or even NIS, and anyway I > need disconnected operation. So matching up user ids is nice. Yeah, I do that too. Though perhaps it's time to start thinking about how to solve this automatically. I personally feel that user ids should be local and that anything that's not local to a host (removable media, network file systems etc.) should use something else which then gets mapped to a local uid when necessary. I'm not sure what that something would be, though. Usernames, username at domain, mugshot accounts, user at uuid or whatever. For example, a USB drive with an ext3 file system could contain some database that maps uids for that file system to usernames. Then when you plug that into a machine, the uids are automatically remapped according to this database to match what the host actually uses. Btw, this isn't about improving security, it's just a way to make things work more smoothly. /abo From davidz at redhat.com Thu Oct 4 16:15:59 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 04 Oct 2007 12:15:59 -0400 Subject: new user creation module in firstboot In-Reply-To: <4704F3AA.9030506@prodigy.net.mx> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> <4704F3AA.9030506@prodigy.net.mx> Message-ID: <1191514559.18756.2.camel@oneill.fubar.dk> On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote: > I thought that's why we had system-config-users for? Or am I missing > something here? As I wrote in my original mail there's overlap between this new cool thing, the GNOME About Me dialog and system-config-users. Ideally we should just have a single tool. David From notting at redhat.com Thu Oct 4 17:00:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Oct 2007 13:00:54 -0400 Subject: esc by default? Message-ID: <20071004170054.GA7448@nostromo.devel.redhat.com> Should this be optional? Does this actually get used under Fedora? Bill From skvidal at fedoraproject.org Thu Oct 4 17:10:21 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 04 Oct 2007 13:10:21 -0400 Subject: esc by default? In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> Message-ID: <1191517821.6741.101.camel@cutter> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > Should this be optional? Does this actually get used under Fedora? it should be optional, imo. -sv From mclasen at redhat.com Thu Oct 4 17:17:31 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 04 Oct 2007 13:17:31 -0400 Subject: esc by default? In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> Message-ID: <1191518251.3151.0.camel@localhost.localdomain> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > Should this be optional? Does this actually get used under Fedora? Yeah, it should certainly be optional. From notting at redhat.com Thu Oct 4 17:26:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Oct 2007 13:26:49 -0400 Subject: esc by default? In-Reply-To: <1191518251.3151.0.camel@localhost.localdomain> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191518251.3151.0.camel@localhost.localdomain> Message-ID: <20071004172649.GA8170@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > > On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > > Should this be optional? Does this actually get used under Fedora? > > Yeah, it should certainly be optional. OK, done. Bill From bclark at redhat.com Thu Oct 4 18:05:36 2007 From: bclark at redhat.com (Bryan Clark) Date: Thu, 4 Oct 2007 14:05:36 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191514559.18756.2.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> <4704F3AA.9030506@prodigy.net.mx> <1191514559.18756.2.camel@oneill.fubar.dk> Message-ID: <4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com> On 10/4/07, David Zeuthen wrote: > > > On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote: > > I thought that's why we had system-config-users for? Or am I missing > > something here? > > As I wrote in my original mail there's overlap between this new cool > thing, the GNOME About Me dialog and system-config-users. Ideally we > should just have a single tool. > Yes, I think what we talked about in the GDM discussion was to reuse the user dialog inside GNOME. So there would be a dialog for creating / editing a user account that can be called from GDM as well as a dialog for doing the same inside the Desktop. (i.e. the person probably shouldn't have to log out to create / edit new users) To save effort we should attempt to reuse code paths because the dialogs and actions will be almost exactly the same. ~ Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Thu Oct 4 18:03:59 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 04 Oct 2007 14:03:59 -0400 Subject: new user creation module in firstboot In-Reply-To: <4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> <4704F3AA.9030506@prodigy.net.mx> <1191514559.18756.2.camel@oneill.fubar.dk> <4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com> Message-ID: <1191521039.18756.6.camel@oneill.fubar.dk> On Thu, 2007-10-04 at 14:05 -0400, Bryan Clark wrote: > Yes, I think what we talked about in the GDM discussion was to reuse > the user dialog inside GNOME. So there would be a dialog for > creating / editing a user account that can be called from GDM as well > as a dialog for doing the same inside the Desktop. ( i.e. the person > probably shouldn't have to log out to create / edit new users) To save > effort we should attempt to reuse code paths because the dialogs and > actions will be almost exactly the same. Cool. Btw, in passing, another thing I'd really like to see is support for setting up the fingerprint reader via thinkfinger [1]. David [1] : in F8 (and maybe F7), HAL can tell you whether you have the hardware installed From bpepple at fedoraproject.org Thu Oct 4 19:13:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 04 Oct 2007 15:13:20 -0400 Subject: esc by default? In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> Message-ID: <1191525200.18627.1.camel@kennedy> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > Should this be optional? Does this actually get used under Fedora? I'd be for disabling it by default. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jmagne at redhat.com Thu Oct 4 20:50:15 2007 From: jmagne at redhat.com (Jack Magne) Date: Thu, 04 Oct 2007 13:50:15 -0700 Subject: esc by default? In-Reply-To: <1191525200.18627.1.camel@kennedy> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> Message-ID: <47055207.6090707@redhat.com> We need to have this installed on the machine by default because it allows a user to enroll a smart card. This is required to make use of the smart card login feature. thanks, Jack Brian Pepple wrote: > On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > >> Should this be optional? Does this actually get used under Fedora? >> > > I'd be for disabling it by default. > > /B > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at fedoraproject.org Thu Oct 4 20:54:19 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 04 Oct 2007 16:54:19 -0400 Subject: esc by default? In-Reply-To: <47055207.6090707@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> Message-ID: <1191531259.6741.109.camel@cutter> On Thu, 2007-10-04 at 13:50 -0700, Jack Magne wrote: > We need to have this installed on the machine by default because it > allows a user to enroll a smart card. > This is required to make use of the smart card login feature. 1. smart cards are extremely uncommon. 2. if you have an infrastructure requiring this then your sysadmin/user can install the pkg with a single command why would it need to be on the default install? -sv From notting at redhat.com Thu Oct 4 20:56:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Oct 2007 16:56:27 -0400 Subject: esc by default? In-Reply-To: <47055207.6090707@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> Message-ID: <20071004205627.GA11204@nostromo.devel.redhat.com> Jack Magne (jmagne at redhat.com) said: > We need to have this installed on the machine by default because it allows > a user to enroll a smart card. > This is required to make use of the smart card login feature. That's a logical fallacy. Number of bugs filed against esc by non-RH people relating to its use: 0 Number of bugs filed against thinkfinger by non-RH people relating to its use: 2 And yet, we don't install thinkfinger by default. (We could then compare the number of users with fingerprint scanning hardware vs. smart cards.) Bill From davidz at redhat.com Thu Oct 4 21:25:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 04 Oct 2007 17:25:17 -0400 Subject: esc by default? In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> Message-ID: <1191533117.15479.6.camel@oneill.fubar.dk> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > Should this be optional? Does this actually get used under Fedora? As a general rule of thumb we do try hard to ship as many drivers / hardware enablement features as possible. I'm not sure why esc is any different? Maybe.. because of the fact that it's a resource hog (both in terms of eating cycles and taking up disk space). At least it was like this the last time I looked [1]. (Btw, for me, the resource hog issue alone should be enough to kick it out of the default install. Think boot time, live image size etc. And if this is the case, we should just say it like it is. It might also help get someone to fix it.) David [1] : for starters, they ship their own mozilla stack From jmagne at redhat.com Thu Oct 4 21:51:19 2007 From: jmagne at redhat.com (Jack Magne) Date: Thu, 04 Oct 2007 14:51:19 -0700 Subject: esc by default? In-Reply-To: <1191533117.15479.6.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191533117.15479.6.camel@oneill.fubar.dk> Message-ID: <47056057.7070601@redhat.com> You are correct about the physical size. The upcoming system wide Xulrunner should help us there. By default , only a smaller smart card detection daemon run until someone puts in an actual card. thanks, jack David Zeuthen wrote: > On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote: > >> Should this be optional? Does this actually get used under Fedora? >> > > As a general rule of thumb we do try hard to ship as many drivers / > hardware enablement features as possible. I'm not sure why esc is any > different? > > Maybe.. because of the fact that it's a resource hog (both in terms of > eating cycles and taking up disk space). At least it was like this the > last time I looked [1]. > > (Btw, for me, the resource hog issue alone should be enough to kick it > out of the default install. Think boot time, live image size etc. And if > this is the case, we should just say it like it is. It might also help > get someone to fix it.) > > David > > [1] : for starters, they ship their own mozilla stack > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From davidz at redhat.com Thu Oct 4 21:57:41 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 04 Oct 2007 17:57:41 -0400 Subject: esc by default? In-Reply-To: <47056057.7070601@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191533117.15479.6.camel@oneill.fubar.dk> <47056057.7070601@redhat.com> Message-ID: <1191535061.15479.20.camel@oneill.fubar.dk> On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote: > By default , only a smaller smart card detection daemon run until > someone puts in an actual card. Even this is wrong. You should use either udev or hal to ensure that the daemon is running only when the hardware is present (assuming USB; if people still use serial ports then they can manually edit some config file to make sure the daemon starts up.) David From jmagne at redhat.com Thu Oct 4 22:52:03 2007 From: jmagne at redhat.com (Jack Magne) Date: Thu, 04 Oct 2007 15:52:03 -0700 Subject: esc by default? In-Reply-To: <1191535061.15479.20.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191533117.15479.6.camel@oneill.fubar.dk> <47056057.7070601@redhat.com> <1191535061.15479.20.camel@oneill.fubar.dk> Message-ID: <47056E93.8070808@redhat.com> Yes, we have a bug on the issue to to tie smart card detection to hal. thanks, jack David Zeuthen wrote: > On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote: > >> By default , only a smaller smart card detection daemon run until >> someone puts in an actual card. >> > > Even this is wrong. You should use either udev or hal to ensure that the > daemon is running only when the hardware is present (assuming USB; if > people still use serial ports then they can manually edit some config > file to make sure the daemon starts up.) > > David > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Fri Oct 5 00:39:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 4 Oct 2007 20:39:00 -0400 Subject: esc by default? In-Reply-To: <47055207.6090707@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> Message-ID: <20071004203900.5b98d6e5@redhat.com> On Thu, 04 Oct 2007 13:50:15 -0700 Jack Magne wrote: > We need to have this installed on the machine by default because it > allows a user to enroll a smart card. > This is required to make use of the smart card login feature. That's an argument for having it on the install media, but not an argument to install it by default. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bkonrath at redhat.com Fri Oct 5 03:37:10 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 04 Oct 2007 23:37:10 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191512268.5560.40.camel@home.alexander.bostrom.net> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> <1191466146.2648.18.camel@localhost.localdomain> <20071004123620.GA513@jadzia.bu.edu> <1191512268.5560.40.camel@home.alexander.bostrom.net> Message-ID: <1191555430.13236.8.camel@toast.toronto.redhat.com> On Thu, 2007-10-04 at 17:37 +0200, Alexander Bostr?m wrote: > tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller: > > > > Often, yes. But I also like to have all user ids the same at home so > > usernames on removable media just match up. I don't have complicated enough > > home network (or enough users!) to justify LDAP or even NIS, and anyway I > > need disconnected operation. So matching up user ids is nice. > > Yeah, I do that too. > > Though perhaps it's time to start thinking about how to solve this > automatically. I personally feel that user ids should be local and that > anything that's not local to a host (removable media, network file > systems etc.) should use something else which then gets mapped to a > local uid when necessary. I'm not sure what that something would be, > though. Usernames, username at domain, mugshot accounts, user at uuid or > whatever. > > For example, a USB drive with an ext3 file system could contain some > database that maps uids for that file system to usernames. Then when you > plug that into a machine, the uids are automatically remapped according > to this database to match what the host actually uses. I agree, solving the real problem is the better way to go. But unfortunately that's out of scope for user creation stuff I'm working on. Matt: How do you get around not being able to specify the uid in the current firstboot user creation module? - Just curious. Cheers, Ben From bkonrath at redhat.com Fri Oct 5 03:58:57 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 04 Oct 2007 23:58:57 -0400 Subject: new user creation module in firstboot In-Reply-To: <20071004012624.GA14939@jadzia.bu.edu> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> Message-ID: <1191556737.13236.27.camel@toast.toronto.redhat.com> On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote: > On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote: > > > Email address? Where's that going to go? What will it be used for? And > > > isn't my e-mail address username at localhost? > > The Email address is intended to used to pull in account information > > from mugshot so using username at localhost wouldn't really work. > > My point is: how is the user presented with that form supposed to guess > that? Mugshot integration sounds like a cool idea -- but why not present it > as that? Good point. But since there are other uses for the email address (think any application that asks for the users email address), it's best to just keep it generic. > > > There should also be an advanced button so that parameters like userid > > > can be selected. > > This user creation module is intended to be used by desktop users, not > > systems administrators so having a place to select advanced options like > > userid doesn't really make sense. FWIW, the current user creation module > > doesn't have those options for local users either. > > I'm a desktop user. I want to select my user id. This is a flaw in the > current user creation module; if we're changing it, now's the time to fix > it. When I said desktop user I really meant 'non-computer-savy desktop user', sorry about that. I think for this case uid is not required, but by that logic neither is the unix username (and some might argue that passwords are in the same boat). So maybe an advanced would be useful. Thanks for your input, Ben From mattdm at mattdm.org Fri Oct 5 04:01:57 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 5 Oct 2007 00:01:57 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191555430.13236.8.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> <1191466146.2648.18.camel@localhost.localdomain> <20071004123620.GA513@jadzia.bu.edu> <1191512268.5560.40.camel@home.alexander.bostrom.net> <1191555430.13236.8.camel@toast.toronto.redhat.com> Message-ID: <20071005040157.GA10906@jadzia.bu.edu> On Thu, Oct 04, 2007 at 11:37:10PM -0400, Ben Konrath wrote: > Matt: How do you get around not being able to specify the uid in the > current firstboot user creation module? - Just curious. Skip it. Log in as root on text console, create user with useradd. Which I'm fine with continuing to do, although it'd be *nice* to skip this step. (If I'm installing BU Linux, I can, because we've made our own replacement firstboot module which looks up the user id from our ph/qi server. But I often install vanilla Fedora or CentOS.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Oct 5 04:05:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 5 Oct 2007 00:05:48 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191556737.13236.27.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <20071003194345.GA1952@jadzia.bu.edu> <1191447333.7817.42.camel@toast.toronto.redhat.com> <20071004012624.GA14939@jadzia.bu.edu> <1191556737.13236.27.camel@toast.toronto.redhat.com> Message-ID: <20071005040548.GB10906@jadzia.bu.edu> On Thu, Oct 04, 2007 at 11:58:57PM -0400, Ben Konrath wrote: > > > The Email address is intended to used to pull in account information > > > from mugshot so using username at localhost wouldn't really work. > > My point is: how is the user presented with that form supposed to guess > > that? Mugshot integration sounds like a cool idea -- but why not present it > > as that? > Good point. But since there are other uses for the email address (think > any application that asks for the users email address), it's best to > just keep it generic. Ouch. I don't *want* to provide a working e-mail address to any application that generically asks. And I don't think I'm the only one who's sensitive to this. Anyway, from an old school Unix perspective it just feels weird to ask it the way you are, because e-mail address is exactly equal to username at hostname. But overall I'm with you on this. It's useful to have an external e-mail address. In fact, I'd like to see an option on this screen to automatically alias the root e-mail address to the given address. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gmureddu at prodigy.net.mx Fri Oct 5 03:30:43 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 04 Oct 2007 23:30:43 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191514559.18756.2.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> <4704F3AA.9030506@prodigy.net.mx> <1191514559.18756.2.camel@oneill.fubar.dk> Message-ID: <4705AFE3.1030604@prodigy.net.mx> David Zeuthen escribi?: > On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote: > >> I thought that's why we had system-config-users for? Or am I missing >> something here? >> > > As I wrote in my original mail there's overlap between this new cool > thing, the GNOME About Me dialog and system-config-users. Ideally we > should just have a single tool. > > David > > > Again, I thought system-config-users was for adding users (admin) and changing properties of users as per administration policies, and the about-me tool was for users to *modify* their profiles, password and other preferences, rather than do the *exact* same thing as system-config-users... I'm a bit confused now... From bkonrath at redhat.com Fri Oct 5 04:39:25 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 05 Oct 2007 00:39:25 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191448289.3414.22.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> Message-ID: <1191559165.13236.51.camel@toast.toronto.redhat.com> On Wed, 2007-10-03 at 17:51 -0400, David Zeuthen wrote: > Hi, > > On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote: > > Hi, > > > > I'm working on a new user creation module for the new and improved > > firstboot. I created a little video to give people an idea of the UI > > interaction: > > > > http://bagu.org/scratch/createuser.ogv > > This looks pretty smooth, thanks a lot for working on this. My first > reaction is that this is not something that should be limited to > firstboot; ideally stuff like that should be able to run from the > desktop environment when adding / deleting / managing users, right? As Colin pointed out, the goal here is to allow users to create accounts at more obvious places - at login, when switching users, at firstboot - and share the code / UI for this. This firstboot module was just an easy place for me to start experimenting. So yeah, having the ability to run an account creation app inside the desktop environment is definitely what we want. > If we want that we probably need to look at existing functionality in > the desktop.. that includes system-config-users (Fedora specific) and > the GNOME About Me dialog and how this would fit in. I'd probably say > that we want to replace both. And in the same breath I would approach > the GNOME community to get this done upstream so all distros can rally > around it (share development and maintenance efforts). What is your take > on that? I think that seems like a good plan. > Also, if we want this in the desktop environment (and I think we do) it > needs to be written in a way that separates the mechanism (would run > privileged, e.g. uid 0 however locked down by SELinux or whatever) from > the user interface (would run unprivileged user). I'd probably suggest > to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus > (for activating the mechanism) for that, both of these (especially PK) > are kinda written for this kind of thing [2]. Yes, I agree. I just read those pages and they will be a good starting point. Thanks for the info :) > Finally, it would be good to have this feature as a "Component" so it's > easy to embed into other applications; e.g. if I want to write a OS > installer app, then I can easily embed this component. Same, FWIW, goes > for the work we're doing on the clock applet and in the future any > system configuration bits. I think firstboot has /some/ notion of > plug-in architecture but actually haven't reviewed it since I'm not sure > it's appropriate in an environment where the UI should run unprivileged. > But it just might work. Yeah, firstboot does have a plugin architecture so making a component is probably what I want. Can you elaborate on what you mean by component? - What technologies should I be looking at using? Thanks, Ben From bkonrath at redhat.com Fri Oct 5 04:40:12 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Fri, 05 Oct 2007 00:40:12 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191455097.18732.1.camel@oneill.fubar.dk> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> Message-ID: <1191559212.13236.52.camel@toast.toronto.redhat.com> On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote: > On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote: > > On 10/3/07, David Zeuthen wrote: > > > > > > This looks pretty smooth, thanks a lot for working on this. My first > > > reaction is that this is not something that should be limited to > > > firstboot; ideally stuff like that should be able to run from the > > > desktop environment when adding / deleting / managing users, right? > > > > We had a design session on this; the idea was actually that you could > > create new users from the login dialog (GDM). > > I agree that's an interesting idea that would replace the need for a > firstboot module (and probably firstboot entirely). However, I think > it's still needed as a program you can launch in the desktop session > along with an icon in System->Administration. If only we had a component > system... If the account creation was only in gdm, how would a user know that they need to create an account before they login? - would this be an obvious step? IMO presenting the account creation in firstboot is the way to let a user know that they should create a user account. And since the code would be reused from the other account creation code it shouldn't be too hard to create the module. Ben From bclark at redhat.com Fri Oct 5 14:47:24 2007 From: bclark at redhat.com (Bryan Clark) Date: Fri, 5 Oct 2007 10:47:24 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191559212.13236.52.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191455097.18732.1.camel@oneill.fubar.dk> <1191559212.13236.52.camel@toast.toronto.redhat.com> Message-ID: <4600a0ae0710050747u2e4d3067n9294b2875bc7b987@mail.gmail.com> On 10/5/07, Ben Konrath wrote: > > On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote: > > On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote: > > > On 10/3/07, David Zeuthen wrote: > > > > > > > > This looks pretty smooth, thanks a lot for working on this. My first > > > > reaction is that this is not something that should be limited to > > > > firstboot; ideally stuff like that should be able to run from the > > > > desktop environment when adding / deleting / managing users, right? > > > > > > We had a design session on this; the idea was actually that you could > > > create new users from the login dialog (GDM). > > > > I agree that's an interesting idea that would replace the need for a > > firstboot module (and probably firstboot entirely). However, I think > > it's still needed as a program you can launch in the desktop session > > along with an icon in System->Administration. If only we had a component > > system... > > If the account creation was only in gdm, how would a user know that they > need to create an account before they login? - would this be an obvious > step? If there are no accounts listed in the GDM user list then you'd have to create one. GDM could even prompt for this since it knows if user accounts are present (or rather it has a blacklist of non-user accounts). The thought was that GDM could easily make it obvious that you needed to create a user account when none existed by prompting you. (i.e. if (user_accounts.length == 0) { show_account_creation_dialog(); } ). The other reason GDM was a good entry point for creating accounts was because in (fast) user switching scenarios you will be shown the GDM screen to login as another user, if another user doesn't exist you might want to create them at that point instead of switching back to your original user and finding the system-* dialog that allows that. ~ Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Fri Oct 5 15:26:59 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Oct 2007 11:26:59 -0400 Subject: esc by default? In-Reply-To: <20071004203900.5b98d6e5@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> Message-ID: <1191598019.17992.1.camel@oneill.fubar.dk> On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote: > That's an argument for having it on the install media, but not an > argument to install it by default. Bogus. Extend this argument to other device drivers etc. and you pretty soon have a system that won't install / work anywhere. David From skvidal at fedoraproject.org Fri Oct 5 15:44:48 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 05 Oct 2007 11:44:48 -0400 Subject: esc by default? In-Reply-To: <1191598019.17992.1.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> Message-ID: <1191599088.6741.128.camel@cutter> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: > On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote: > > That's an argument for having it on the install media, but not an > > argument to install it by default. > > Bogus. Extend this argument to other device drivers etc. and you pretty > soon have a system that won't install / work anywhere. extend it in the other direction and pretty soon you have a system that won't be able to fit on any media, anywhere. I think the point we're making here is that we need to find a happy balance. I think smart cards are obscure enough to not include them by default. -sv From mclasen at redhat.com Fri Oct 5 15:55:17 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 05 Oct 2007 11:55:17 -0400 Subject: esc by default? In-Reply-To: <1191598019.17992.1.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> Message-ID: <1191599717.23375.1.camel@localhost.localdomain> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: > On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote: > > That's an argument for having it on the install media, but not an > > argument to install it by default. > > Bogus. Extend this argument to other device drivers etc. and you pretty > soon have a system that won't install / work anywhere. I have a hard time imagining a system that won't install because of missing smart card drivers. From davidz at redhat.com Fri Oct 5 15:52:44 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Oct 2007 11:52:44 -0400 Subject: new user creation module in firstboot In-Reply-To: <1191559165.13236.51.camel@toast.toronto.redhat.com> References: <1191440044.7817.28.camel@toast.toronto.redhat.com> <1191448289.3414.22.camel@oneill.fubar.dk> <1191559165.13236.51.camel@toast.toronto.redhat.com> Message-ID: <1191599564.17992.21.camel@oneill.fubar.dk> On Fri, 2007-10-05 at 00:39 -0400, Ben Konrath wrote: > > Finally, it would be good to have this feature as a "Component" so it's > > easy to embed into other applications; e.g. if I want to write a OS > > installer app, then I can easily embed this component. Same, FWIW, goes > > for the work we're doing on the clock applet and in the future any > > system configuration bits. I think firstboot has /some/ notion of > > plug-in architecture but actually haven't reviewed it since I'm not sure > > it's appropriate in an environment where the UI should run unprivileged. > > But it just might work. > > Yeah, firstboot does have a plugin architecture so making a component is > probably what I want. Can you elaborate on what you mean by component? - > What technologies should I be looking at using? Unfortunately not, hence why I used quotes around component above. There's things like Bonobo, KParts, COM, Eclipse extensions, Mono addins etc.. In NetworkManager, for VPN plugins, we use (or used too, don't know how it works post 0.6) a pretty simplistic in-process approach (not even GObject based) http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RELEASE/vpn-daemons/README?revision=1545&view=markup http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RELEASE/gnome/vpn-properties/nm-vpn-ui-interface.h?revision=1545&view=markup whereby the UI for managing VPN connections would load a GModule providing the UI and functionality (there's at least three different open source plug-ins at this point). Nautilus has a similar concept with it's extension system; see the nautilus-devel package and some of the extensions. The idea was simply that this functionality, along with other things (such as selecting your location/timezone etc.), would be targets for embedding in, say, containers like the OS installer, firstboot, gdm or whatever. Depending on the audience for the OS (or spin), you'd select where each component then goes. For example for home-user oriented desktops you'd want everything to go into the live cd installer, for other targets you want something else. I'm not really sure it's worth worrying about at this point; I'd just focus on creating a single program for now then it can always be retrofitted it into one or more component system later on (and it sounds like you want a firstboot module as well so perhaps writing the program as a library might be a good idea too). Anyway, I'll stop the architecture astronaut thing now (need air!) but I thought it was important to mention that retrofitting the code so it can be used in different contexts is desirable. David From davidz at redhat.com Fri Oct 5 16:06:40 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Oct 2007 12:06:40 -0400 Subject: esc by default? In-Reply-To: <1191599088.6741.128.camel@cutter> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> Message-ID: <1191600400.17992.37.camel@oneill.fubar.dk> On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote: > On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: > > On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote: > > > That's an argument for having it on the install media, but not an > > > argument to install it by default. > > > > Bogus. Extend this argument to other device drivers etc. and you pretty > > soon have a system that won't install / work anywhere. > > extend it in the other direction and pretty soon you have a system that > won't be able to fit on any media, anywhere. > > I think the point we're making here is that we need to find a happy > balance. I think smart cards are obscure enough to not include them by > default. Maybe. But it shouldn't have to be that way; smart cards (or anything where you verify more than one thing about the user (e.g. the classic something you a) have; b) know; c) are) are inherently more secure than just passwords and SSH keys. Hence, I think we should be interested in getting this working. Same for thinkfinger; people are doing very good work at integrating this into the distro. (Heck, if I'm a big company interested in this I should be able to participate in the Fedora project and get my stuff into the distro so it Just Works(tm) out of the box. Maybe even offer some or all Fedora developers a smart card. Just a thought.) But you're right; it's about balance; there's a couple of kernel drivers we don't ship because they're just too obscure. Or they're too buggy. Or too bloated. Whatever. Ideally our OS should be able to detect the hardware and properly request for the driver / enabling software to be installed (clearly, this won't work for kernel drivers now that kmod's are banned but there's a lot of other stuff in userspace). (I do think, however, that pscs-lite and esc should be installed by default as soon they've fixed their resource consumption issues; at least until our OS is smart enough to detect what RPM's to install when we see the hardware [1]) David [1] : e.g. modalias; the package will have a Provides: usb:v413Cp8103d2422dcE0dsc01dp01icFEisc01ip00 From jdennis at redhat.com Fri Oct 5 16:37:52 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 05 Oct 2007 12:37:52 -0400 Subject: esc by default? In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> Message-ID: <47066860.4020603@redhat.com> David Zeuthen wrote: > On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote: >> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: >> I think the point we're making here is that we need to find a happy >> balance. I think smart cards are obscure enough to not include them by >> default. > > Maybe. But it shouldn't have to be that way; smart cards (or anything > where you verify more than one thing about the user (e.g. the classic > something you a) have; b) know; c) are) are inherently more secure than > just passwords and SSH keys. Hence, I think we should be interested in > getting this working. Same for thinkfinger; people are doing very good > work at integrating this into the distro. Everything Red Hat is doing is driving towards the use of stronger authentication. We have made huge monetary investments in this area. Fedora is supposed to be a test ground for emerging technology, especially emerging technology be driven by us. These observations should help answer the question of whether these packages should be candidates for default installation because that will help move the technology forward we have a vested interest in. -- John Dennis From sundaram at fedoraproject.org Fri Oct 5 16:41:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 Oct 2007 22:11:12 +0530 Subject: esc by default? In-Reply-To: <47066860.4020603@redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> <47066860.4020603@redhat.com> Message-ID: <47066928.9070700@fedoraproject.org> John Dennis wrote: > David Zeuthen wrote: >> On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote: >>> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: >>> I think the point we're making here is that we need to find a happy >>> balance. I think smart cards are obscure enough to not include them by >>> default. >> >> Maybe. But it shouldn't have to be that way; smart cards (or anything >> where you verify more than one thing about the user (e.g. the classic >> something you a) have; b) know; c) are) are inherently more secure than >> just passwords and SSH keys. Hence, I think we should be interested in >> getting this working. Same for thinkfinger; people are doing very good >> work at integrating this into the distro. > > Everything Red Hat is doing is driving towards the use of stronger > authentication. We have made huge monetary investments in this area. It be would useful if some of the investments were directed to not making ti start by default unnecessary. The majority of end users in Fedora are unlikely to be using smart cards anytime soon unlike the audience for RHEL. Rahul From jspaleta at gmail.com Fri Oct 5 18:48:45 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 5 Oct 2007 10:48:45 -0800 Subject: esc by default? In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> Message-ID: <604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com> On 10/5/07, David Zeuthen wrote: > But you're right; it's about balance; there's a couple of kernel drivers > we don't ship because they're just too obscure. Or they're too buggy. Or > too bloated. Whatever. Ideally our OS should be able to detect the > hardware and properly request for the driver / enabling software to be > installed (clearly, this won't work for kernel drivers now that kmod's > are banned but there's a lot of other stuff in userspace). Detection of this at install time? Even if all the pieces to do that are available, doesn't that require some significant re-think in installer package management? At the very least we'd have to have a list of packages associated which each sort of hardware detection flag that could be parsed by the installer. Using what we have currently as a starting point, you'd essentially have to group things in a comps group associated with each detection criteria, and then teach anaconda to set that group to install by default if the detection criteria is met. And when installing from livecd targets... could you discriminate in a similar fashion and only install to disk the hardware specific userspace bits that system needed? I think that'd be tougher since the livecd's install a pre-cooked disk image with all the bells and whistles already installed. -jef From davidz at redhat.com Fri Oct 5 19:01:30 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Oct 2007 15:01:30 -0400 Subject: esc by default? In-Reply-To: <604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> <604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com> Message-ID: <1191610890.7397.17.camel@oneill.fubar.dk> On Fri, 2007-10-05 at 10:48 -0800, Jeff Spaleta wrote: > On 10/5/07, David Zeuthen wrote: > > But you're right; it's about balance; there's a couple of kernel drivers > > we don't ship because they're just too obscure. Or they're too buggy. Or > > too bloated. Whatever. Ideally our OS should be able to detect the > > hardware and properly request for the driver / enabling software to be > > installed (clearly, this won't work for kernel drivers now that kmod's > > are banned but there's a lot of other stuff in userspace). > > Detection of this at install time? No, it's basically the wrong mindset to think that we only need to detect hardware at install time; with hot pluggable buses like USB, Firewire, whatever, hardware can come and go at any time. So any solution that only works at install time is just fundamentally wrong. In fact, the installer just be just an installer; not it's own little OS with it's own private hardware detection routines; that kind of services should be part of the core OS and the installer should take advantage of it as should the environment the user normally use too (e.g. the desktop or commandline tools) > Even if all the pieces to do that > are available, doesn't that require some significant re-think in > installer package management? At the very least we'd have to have a > list of packages associated which each sort of hardware detection flag > that could be parsed by the installer. Using what we have currently as > a starting point, you'd essentially have to group things in a comps > group associated with each detection criteria, and then teach anaconda > to set that group to install by default if the detection criteria is > met. Yes, it's a can of worms; basically what most "Enterprise" distros do (because they have a kABI and support vendor drivers not shipped with the OS etc.) is to use RPM Provides: with the modalias for what the driver in the RPM support. So it goes like this 1. Plug in your hardware 2. Find the modalias for the device (look e.g. in sysfs) 3. yum search $modalias 4. yum install package-that-you-found It's not really difficult to imagine this could be automated; you'd have a small tray icon saying "yo, I don't have a driver for this device; would you like to search for one?". Of course the party line of Fedora is (or used to be) that we install all drivers in the default install and that renders the problem moot. In fact, I think it's a bit silly to build all this infrastructure just because - we've changed the party line from "we ship all drivers in the default install" to "we don't ship all drivers in the default install". This kind of baffles me; I'm not really sure DVD space and hard disk space is that expensive. - it creates the illusion that Fedora has a stable kABI; that's just wrong - it'll never work for kernel drivers anyway and the majority of interesting drivers are indeed in the kernel - it's just plain annoying having to click through crap like that just because we decided not to ship all drivers in the default install. Of course, such a gizmo has the side effect to tell you if the hardware you just plugged in is supported or not so we may end up doing something similar *anyway*. > And when installing from livecd targets... could you discriminate in a > similar fashion and only install to disk the hardware specific > userspace bits that system needed? I think that'd be tougher since the > livecd's install a pre-cooked disk image with all the bells and > whistles already installed. I can't really see what's wrong with "we ship all drivers in the default install" but if we want to change it we need some of that silly infrastructure above to make the system Just Work(tm) when you e.g. plug in a USB smart card reader. David From notting at redhat.com Fri Oct 5 19:12:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 5 Oct 2007 15:12:37 -0400 Subject: esc by default? In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> Message-ID: <20071005191237.GA28973@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > I do think, however, that pscs-lite and esc should be installed by > default as soon they've fixed their resource consumption issues; I have no problems with that. But running a separate daemon and xulrunner stack on login for hardware that a fairly minute fraction of our users will ever have isn't really up to snuff right now. Bill From jmagne at redhat.com Fri Oct 5 20:29:54 2007 From: jmagne at redhat.com (Jack Magne) Date: Fri, 05 Oct 2007 13:29:54 -0700 Subject: esc by default? In-Reply-To: <20071005191237.GA28973@nostromo.devel.redhat.com> References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk> <20071005191237.GA28973@nostromo.devel.redhat.com> Message-ID: <47069EC2.7080409@redhat.com> Thanks everyone for the thoughtful responses and suggestions. We will continue to work to solve these issues. thanks, jack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mclasen at redhat.com Wed Oct 10 16:05:20 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 10 Oct 2007 12:05:20 -0400 Subject: Desktop SIG meeting Message-ID: <1192032320.6464.3.camel@localhost.localdomain> ...should take place again today, at 18:00 UTC. Possible things to talk about are pressing issues that need to be adressed before F8 (ie F8Blocker / F8Target bugs) and what is planned for F9. From detonated at o2.pl Sun Oct 14 08:01:08 2007 From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=) Date: Sun, 14 Oct 2007 10:01:08 +0200 Subject: madwifi in fedora 8 Message-ID: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl> Good morning, I wonder why madwifi was not included in fedora 6 & 7 by default. I had a big trouble configuring my wireless network. Will it be included in fedora 8? Greetings From martin at gamesplace.info Sun Oct 14 10:32:52 2007 From: martin at gamesplace.info (Martin =?ISO-8859-1?Q?J=FCrgens?=) Date: Sun, 14 Oct 2007 12:32:52 +0200 Subject: madwifi in fedora 8 In-Reply-To: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl> References: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl> Message-ID: <1192357972.3032.4.camel@localhost6.localdomain6> Hi! The reason for this is that some parts of madwifi are non-free (the HAL). The Fedora project decided not to ship non-free parts, which includes proprietary ATI drivers, proprietary NVIDIA drivers and Madwifi in order to encourage the vendors to publish specifications and / or free drivers. This worked for ATI, and we will have free drivers supporting newer chipsets available soon. Fedora 8 will ship with ath5k, which is open source and supports Atheros chipsets, also. The madwifi developers develop it now. Martin Am Sonntag, den 14.10.2007, 10:01 +0200 schrieb a3ukasz Peb3szynski: > Good morning, > I wonder why madwifi was not included in fedora 6 & 7 by default. > I had a big trouble configuring my wireless network. > Will it be included in fedora 8? > > Greetings > From detonated at o2.pl Wed Oct 17 15:47:15 2007 From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=) Date: Wed, 17 Oct 2007 17:47:15 +0200 Subject: how to run fedora 8 test 3 Message-ID: Good afternoon, First of all I'd like to thank Martin Jorgens for his answer to my question about madwifi. My today's question: Is there any way to log in after booting F8 test 3 live cd ? Looks like there's an error, becuse counter on gdm screen goes below zero. Has anyone noticed that and if so, how did you solve it ? Thanks in advance. Lukasz Pelszynski From martin at gamesplace.info Wed Oct 17 16:34:11 2007 From: martin at gamesplace.info (Martin =?ISO-8859-1?Q?J=FCrgens?=) Date: Wed, 17 Oct 2007 18:34:11 +0200 Subject: how to run fedora 8 test 3 In-Reply-To: References: Message-ID: <1192638851.2914.16.camel@localhost6.localdomain6> Hi! This is related to a ath5k bug in the kernel, see https://bugzilla.redhat.com/show_bug.cgi?id=254192 I run into the same problem having my Atheros card plugged in, but when I remove it out of my computer, everything works fine. I did not yet find a way to run Fedora 8 Test 3 live cd successfully having the Atheros card plugged in. Martin Am Mittwoch, den 17.10.2007, 17:47 +0200 schrieb a3ukasz Peb3szynski: > Good afternoon, > > First of all I'd like to thank Martin Jorgens for his answer to my question about madwifi. > > My today's question: > Is there any way to log in after booting F8 test 3 live cd ? > Looks like there's an error, becuse counter on gdm screen goes below zero. > Has anyone noticed that and if so, how did you solve it ? > Thanks in advance. > > Lukasz Pelszynski > From detonated at o2.pl Fri Oct 19 06:33:00 2007 From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=) Date: Fri, 19 Oct 2007 08:33:00 +0200 Subject: Fedora-desktop-list Digest, Vol 44, Issue 9 In-Reply-To: <20071018160025.C3A8973667@hormel.redhat.com> References: <20071018160025.C3A8973667@hormel.redhat.com> Message-ID: <743ce82d.4ffdc8d2.47184f9c.7ed@o2.pl> > Hi! > > This is related to a ath5k bug in the kernel, see > https://bugzilla.redhat.com/show_bug.cgi?id=254192 ... > Martin Hi! I wasn't aware that it might be an ath5k driver. It all looked like gdm's error... but I hope everything will be OK with atheros driver. Greetings From mclasen at redhat.com Tue Oct 23 19:27:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 23 Oct 2007 15:27:16 -0400 Subject: Desktop SIG meeting tomorrow Message-ID: <1193167636.16178.6.camel@localhost.localdomain> I will most likely not around tomorrow, so interested people will have to self-organize and find something useful to talk about. One topic that I'll throw on the agenda: We should pick a different time for the sig meeting, because several people (jrb, mcepl) said that they have difficulty making the current time. And from now on, I will only be available until 2:15 on most Wednesdays, too. Matthias From caillon at redhat.com Wed Oct 24 10:22:19 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 24 Oct 2007 06:22:19 -0400 Subject: Desktop SIG meeting tomorrow In-Reply-To: <1193167636.16178.6.camel@localhost.localdomain> References: <1193167636.16178.6.camel@localhost.localdomain> Message-ID: <471F1CDB.8090502@redhat.com> Matthias Clasen wrote: > I will most likely not around tomorrow, so interested people will have > to self-organize and find something useful to talk about. One topic that > I'll throw on the agenda: > > We should pick a different time for the sig meeting, because several > people (jrb, mcepl) said that they have difficulty making the current > time. And from now on, I will only be available until 2:15 on most > Wednesdays, too. http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel So, I had a look at the schedule above. I propose to move it to 1500 UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start that schedule until next week since o/~ Tuesday's Gone... Like the Wind. o/~ From wtogami at redhat.com Wed Oct 24 19:51:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 24 Oct 2007 15:51:08 -0400 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <1193248515.22958.111.camel@localhost.localdomain> References: <1193248515.22958.111.camel@localhost.localdomain> Message-ID: <471FA22C.8060105@redhat.com> Tom "spot" Callaway wrote: > On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote: >> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8 >> Request description: Inclusion into Fedora 8 final >> >> Rationale: >> Compiz Fusion has been one of the major attraction to Linux lately, >> and with Ubuntu already providing CF out of the box, users will expect >> other distros to have it too. There no full featured configurator for >> current compiz-fusion in F-8. >> >> Impact not accepting: >> Users will have to use gconf-editor to configure compiz-fusion >> manually. Marketing value might be affected. >> >> Others: >> current compiz in F-8 uses 'glib gconf' as its configuration >> backend, if FedoraProject decided to use libcompizconfig as the >> configuration backend, changes are needed in desktop-effects and >> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM >> requires compiz to use 'ccp' for it to function properly. > > +1 > Spot, did you notice that this requires changes to desktop-effects and gnome-session? It sounds like they expect it to be part of the default install, not just an add-on to the compiz of today. Is the desktop team aware and in agreement with these changes? Warren Togami wtogami at redhat.com From mclasen at redhat.com Wed Oct 24 19:53:13 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 Oct 2007 15:53:13 -0400 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <471FA22C.8060105@redhat.com> References: <1193248515.22958.111.camel@localhost.localdomain> <471FA22C.8060105@redhat.com> Message-ID: <1193255593.4201.0.camel@localhost.localdomain> On Wed, 2007-10-24 at 15:51 -0400, Warren Togami wrote: > > Spot, did you notice that this requires changes to desktop-effects and > gnome-session? It sounds like they expect it to be part of the default > install, not just an add-on to the compiz of today. Is the desktop team > aware and in agreement with these changes? > No and no From wtogami at redhat.com Wed Oct 24 20:04:44 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 24 Oct 2007 16:04:44 -0400 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <1193255688.22958.114.camel@localhost.localdomain> References: <1193248515.22958.111.camel@localhost.localdomain> <471FA22C.8060105@redhat.com> <1193255688.22958.114.camel@localhost.localdomain> Message-ID: <471FA55C.2010100@redhat.com> Tom "spot" Callaway wrote: > On Wed, 2007-10-24 at 15:51 -0400, Warren Togami wrote: >> Tom "spot" Callaway wrote: >>> On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote: >>>> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8 >>>> Request description: Inclusion into Fedora 8 final >>>> >>>> Rationale: >>>> Compiz Fusion has been one of the major attraction to Linux lately, >>>> and with Ubuntu already providing CF out of the box, users will expect >>>> other distros to have it too. There no full featured configurator for >>>> current compiz-fusion in F-8. >>>> >>>> Impact not accepting: >>>> Users will have to use gconf-editor to configure compiz-fusion >>>> manually. Marketing value might be affected. >>>> >>>> Others: >>>> current compiz in F-8 uses 'glib gconf' as its configuration >>>> backend, if FedoraProject decided to use libcompizconfig as the >>>> configuration backend, changes are needed in desktop-effects and >>>> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM >>>> requires compiz to use 'ccp' for it to function properly. >>> +1 >>> >> Spot, did you notice that this requires changes to desktop-effects and >> gnome-session? It sounds like they expect it to be part of the default >> install, not just an add-on to the compiz of today. Is the desktop team >> aware and in agreement with these changes? > > Good point, I read this too quickly. :) I pull back my vote, pending > desktop team signoff. > > ~spot > We could include the requested packages because they alone are harmless, but not make the suggested changes to desktop-effects and gnome-session. Mohd, what exact N-V-R's are you requesting? I would like to inspect them. Warren Togami wtogami at redhat.com From izhar at fedoraproject.org Wed Oct 24 22:16:50 2007 From: izhar at fedoraproject.org (Mohd Izhar Firdaus Ismail) Date: Thu, 25 Oct 2007 06:16:50 +0800 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <471FA55C.2010100@redhat.com> References: <1193248515.22958.111.camel@localhost.localdomain> <471FA22C.8060105@redhat.com> <1193255688.22958.114.camel@localhost.localdomain> <471FA55C.2010100@redhat.com> Message-ID: On 10/25/07, Warren Togami wrote: > We could include the requested packages because they alone are harmless, > but not make the suggested changes to desktop-effects and gnome-session. > > Mohd, what exact N-V-R's are you requesting? I would like to inspect them. (call me Izhar please, as 'Mohd' is a very common prefix in boys name in my country, and we dont use firstname-lastname format, but name-"bin"-fathername instead) the NVRs are compizconfig-python-0.6.0-1.fc8 ccsm-0.6.0-3.fc8 you might want to look at libcompizconfig-0.6.0-3.fc8 if its not included yet, (spec bugfix due to compiz's update to 0.6.2) thank you -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From bclark at redhat.com Thu Oct 25 12:55:07 2007 From: bclark at redhat.com (Bryan Clark) Date: Thu, 25 Oct 2007 08:55:07 -0400 Subject: think finger Message-ID: <4720922B.2080000@redhat.com> Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2]. So to start off with some technical questions about think finger, some of these might be obvious to other people besides me: Can it's presence be detected automatically? And it's (pam) authentication be added automatically? How many times does it take to train think finger support initially? Can it be (re)trained incrementally? Is this required? What are the security models required for this? Thinkfinger && password? Thinkfinger || password? Just Thinkfinger? My assumption here is that either is accepted. Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough. Can we detect / remember the number of failed think finger attempts before a successful one? This is related to retraining, if it's possible to retrain the reader or human to scan better over time. I think that's all for now, I'd like to work off responses. ~ Bryan [1] https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00002.html [2] https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00021.html From skvidal at fedoraproject.org Thu Oct 25 12:58:07 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 25 Oct 2007 08:58:07 -0400 Subject: think finger In-Reply-To: <4720922B.2080000@redhat.com> References: <4720922B.2080000@redhat.com> Message-ID: <1193317087.3517.16.camel@cutter> On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote: > Pushing off from Ben's email on new user creation [1] I wanted to get > some setup for the think finger support that david mentioned [2]. > > So to start off with some technical questions about think finger, some > of these might be obvious to other people besides me: > > Can it's presence be detected automatically? And it's (pam) > authentication be added automatically? It's a device it should be able to be looked up in hal. > How many times does it take to train think finger support initially? 3 good finger swipes that it checks against one another. > Can it be (re)trained incrementally? Is this required? not that I've seen. > > What are the security models required for this? Thinkfinger && > password? Thinkfinger || password? Just Thinkfinger? My assumption > here is that either is accepted. I tested it on my rawhide laptop and while afaict thinkfinger doesn't care gdm and logins and everything else are unprepared for 2-factor auth. They'll accept a finger swipe or a password but cannot handle it if your pam config requires both. > Can we get the image from think finger for user feedback? Ray mentioned > we might be able to fake it, which would probably be good enough. the image of your fingerprint? -sv From mclasen at redhat.com Thu Oct 25 13:09:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 25 Oct 2007 09:09:23 -0400 Subject: think finger In-Reply-To: <1193317087.3517.16.camel@cutter> References: <4720922B.2080000@redhat.com> <1193317087.3517.16.camel@cutter> Message-ID: <1193317763.3598.1.camel@localhost.localdomain> On Thu, 2007-10-25 at 08:58 -0400, seth vidal wrote: > > Can we get the image from think finger for user feedback? Ray mentioned > > we might be able to fake it, which would probably be good enough. > > the image of your fingerprint? > I had to give up my fingerprints to the USCIS recently, and they have impressive scanners that show you your fingerprint in fullscreen. Unfortunately, the fingerprint scanners of your average laptop don't produce anything near that resolution. There simply is no image to show... From rstrode at redhat.com Thu Oct 25 14:00:12 2007 From: rstrode at redhat.com (Ray Strode) Date: Thu, 25 Oct 2007 10:00:12 -0400 Subject: think finger In-Reply-To: <4720922B.2080000@redhat.com> References: <4720922B.2080000@redhat.com> Message-ID: <4720A16C.5080102@redhat.com> Hi, > > Can we get the image from think finger for user feedback? Ray > mentioned we might be able to fake it, which would probably be good > enough. To be clear, what I was saying was: - It would be really cool if we could show a finger print on screen when the user scans their finger - The fingerprint wouldn't have to be the user's fingerprint, just as long as it looked like a fingerprint and looked different than other people's fingerprints I don't know what fingerprint scanners store (actual image data, or just enough information to identify the print or what). Even if we don't have a full image to show, we could potentially just perturb a fake fingerprint seeded by whatever data we do have. Having said that, I think some scanners do give image data. David pointed me to this post he made a long time ago: http://blog.fubar.dk/?p=35 --Ray From katzj at redhat.com Thu Oct 25 14:06:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 25 Oct 2007 10:06:13 -0400 Subject: think finger In-Reply-To: <4720922B.2080000@redhat.com> References: <4720922B.2080000@redhat.com> Message-ID: <1193321173.8896.43.camel@localhost.localdomain> On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote: > Pushing off from Ben's email on new user creation [1] I wanted to get > some setup for the think finger support that david mentioned [2]. I'd actually like to make it a teensy bit more general and think about the non-Thinkfinger readers also. From my Pile Of Laptops, the Authentec readers are pretty common. And davidz has already done some prodding with them based on his blog ;) While not very relevant to the interaction, it's mostly important so that we don't make assumptions of hardware capabilities that may or may not be present. > Can it's presence be detected automatically? And it's (pam) > authentication be added automatically? They're all usb devices, so pretty detectable. Adding the pam config is just a matter of deciding we're doing it and then adding to the stacks written out by authconfig > How many times does it take to train think finger support initially? This probably depends on the hardware. Thinkfinger is 3 swipes and trained in hardware. Some of the other readers just give you back an image and you have to do verification[1] on your own. But probably 3 is a reasonable guess there too. It's at least the range of "more than one, less than many" > Can it be (re)trained incrementally? Is this required? Nope, you pretty much have to do the initial readings upfront. > Can we get the image from think finger for user feedback? Ray mentioned > we might be able to fake it, which would probably be good enough. This is definitely going to be dependent on the hardware, so probably can't be counted on. > Can we detect / remember the number of failed think finger attempts > before a successful one? This is related to retraining, if it's > possible to retrain the reader or human to scan better over time. PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think. Jeremy From krh at bitplanet.net Thu Oct 25 14:16:02 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Thu, 25 Oct 2007 10:16:02 -0400 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <471FA22C.8060105@redhat.com> References: <1193248515.22958.111.camel@localhost.localdomain> <471FA22C.8060105@redhat.com> Message-ID: <59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com> On 10/24/07, Warren Togami wrote: > Tom "spot" Callaway wrote: > > On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote: > >> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8 > >> Request description: Inclusion into Fedora 8 final > >> > >> Rationale: > >> Compiz Fusion has been one of the major attraction to Linux lately, > >> and with Ubuntu already providing CF out of the box, users will expect > >> other distros to have it too. There no full featured configurator for > >> current compiz-fusion in F-8. > >> > >> Impact not accepting: > >> Users will have to use gconf-editor to configure compiz-fusion > >> manually. Marketing value might be affected. > >> > >> Others: > >> current compiz in F-8 uses 'glib gconf' as its configuration > >> backend, if FedoraProject decided to use libcompizconfig as the > >> configuration backend, changes are needed in desktop-effects and > >> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM > >> requires compiz to use 'ccp' for it to function properly. > > > > +1 > > > > Spot, did you notice that this requires changes to desktop-effects and > gnome-session? It sounds like they expect it to be part of the default > install, not just an add-on to the compiz of today. Is the desktop team > aware and in agreement with these changes? This has come up before, and while it would be nice to have a more capable configuration program for compiz the current libcompizconfig is not the right solution. Ideally we would have a configuration application per desktop environment and the GNOME configurator would just talk to gconf directly, similarly for the KDE configurator. If somebody wants to write a settings manager that works with several DEs, I think the burden is on the settings manager to talk to the different configuration systems it wants to operate under. Or this could be part of libcompizconfig, so that setting managers that want to be DE-agnostic can just link to this library and not worry about the underlying config mechanism in use. The current compiz setup is compatible with the above scheme, somebody just need to do the necessary libcompizconfig adjustments. thanks, Kristiani From bnocera at redhat.com Thu Oct 25 14:54:44 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 25 Oct 2007 15:54:44 +0100 Subject: think finger In-Reply-To: <1193321173.8896.43.camel@localhost.localdomain> References: <4720922B.2080000@redhat.com> <1193321173.8896.43.camel@localhost.localdomain> Message-ID: <1193324084.25405.144.camel@cookie.hadess.net> Heya, On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote: > On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote: > > Pushing off from Ben's email on new user creation [1] I wanted to get > > some setup for the think finger support that david mentioned [2]. > > I'd actually like to make it a teensy bit more general and think about > the non-Thinkfinger readers also. From my Pile Of Laptops, the > Authentec readers are pretty common. And davidz has already done some > prodding with them based on his blog ;) The plan for the F9 feature[1] was to not use pam_thinkfinger (it's real crap, and has some gross hacks, such as sending line feeds to accept password auth), and switch to a dbus service instead (so that we don't do threading in pam_thinkfinger). The dbus service would be a HAL singleton, and we could obviously use a different implementation that could drive Authentec readers, or any other, given a sane API. > While not very relevant to the interaction, it's mostly important so > that we don't make assumptions of hardware capabilities that may or may > not be present. > > > Can it's presence be detected automatically? And it's (pam) > > authentication be added automatically? > > They're all usb devices, so pretty detectable. Adding the pam config is > just a matter of deciding we're doing it and then adding to the stacks > written out by authconfig And for which PAM services we'd want to enable this. Cheers From davidz at redhat.com Thu Oct 25 21:57:38 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 25 Oct 2007 17:57:38 -0400 Subject: think finger In-Reply-To: <1193321173.8896.43.camel@localhost.localdomain> References: <4720922B.2080000@redhat.com> <1193321173.8896.43.camel@localhost.localdomain> Message-ID: <1193349458.4248.51.camel@oneill.fubar.dk> On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote: > On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote: > > Pushing off from Ben's email on new user creation [1] I wanted to get > > some setup for the think finger support that david mentioned [2]. > > I'd actually like to make it a teensy bit more general and think about > the non-Thinkfinger readers also. From my Pile Of Laptops, the > Authentec readers are pretty common. And davidz has already done some > prodding with them based on his blog ;) So the one way to do this sanely is to build a simple API that will work for our purposes; e.g. make it high-level driven by application requirements. Since messing around with auth tokens / whatever is a privileged operation, expose it over D-Bus and lock it down via PolicyKit. It doesn't need to be more complicated than the API offered by tf-tool > # tf-tool --help > > ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/) > Copyright (C) 2006, 2007 Timo Hoenig > > Usage: tf-tool [--acquire | --verify | --add-user | > --verify-user ] [--verbose] Notably, to make fingerprint enrollment work in a sane way (we're so not going to do crazy stuff like running X11 apps as root) _anyway_ you need to expose it over D-Bus. And, really, it's pretty trivial, only a matter of a few hours in C; see http://blog.fubar.dk/?p=94 on details how to do it. Hey, you can even do it in Python and since it only involves shelling out to tf-tool, it's probably on the order of hundreds of lines. Now, when we have this API we'll just merge the following properties on the hal device object info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.ThinkfingerService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader' so if someone wants to do Authentec or whatever they just do a D-Bus and make an object that implements the org.freedesktop.FingerPrinterReader D-Bus interface. Then they merge info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.AuthentecService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader' Our UI apps simply don't care what fingerprint_reader.dbus_service is; they only care about poking an object with the D-Bus interface org.freedesktop.FingerPrinterReader. So the UI simply does 1. hal.find_by_caps('fingerprint_reader') 2. read .dbus_service, .dbus_obj, .dbus_iface 3. checks that .dbus_iface=='org.freedesktop.FingerPrinterReader' 4. calls into the service 5. profit David > > While not very relevant to the interaction, it's mostly important so > that we don't make assumptions of hardware capabilities that may or may > not be present. > > > Can it's presence be detected automatically? And it's (pam) > > authentication be added automatically? > > They're all usb devices, so pretty detectable. Adding the pam config is > just a matter of deciding we're doing it and then adding to the stacks > written out by authconfig > > > How many times does it take to train think finger support initially? > > This probably depends on the hardware. Thinkfinger is 3 swipes and > trained in hardware. Some of the other readers just give you back an > image and you have to do verification[1] on your own. But probably 3 is > a reasonable guess there too. It's at least the range of "more than > one, less than many" > > > Can it be (re)trained incrementally? Is this required? > > Nope, you pretty much have to do the initial readings upfront. > > > Can we get the image from think finger for user feedback? Ray mentioned > > we might be able to fake it, which would probably be good enough. > > This is definitely going to be dependent on the hardware, so probably > can't be counted on. > > > Can we detect / remember the number of failed think finger attempts > > before a successful one? This is related to retraining, if it's > > possible to retrain the reader or human to scan better over time. > > PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think. > > Jeremy > From davidz at redhat.com Thu Oct 25 22:05:21 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 25 Oct 2007 18:05:21 -0400 Subject: think finger In-Reply-To: <1193324084.25405.144.camel@cookie.hadess.net> References: <4720922B.2080000@redhat.com> <1193321173.8896.43.camel@localhost.localdomain> <1193324084.25405.144.camel@cookie.hadess.net> Message-ID: <1193349921.4248.58.camel@oneill.fubar.dk> On Thu, 2007-10-25 at 15:54 +0100, Bastien Nocera wrote: > The dbus service would be a HAL singleton, and we could obviously use a > different implementation that could drive Authentec readers, or any > other, given a sane API. Maybe a bit off-topic, but as I said in my other mail, now that we have D-Bus system bus activation, the current advice from the HAL team is to use dedicated services (with standardized interfaces) and use HAL as the directory for looking up the service. That way, there's no HAL dependencies which gives us more freedom to rewrite HAL. (More off-topic but perhaps interesting: As a matter of fact, I talked to Marcel Holtmann about this and it's probably how Bluetooth and Wireless USB audio (and other cloud services) is going to work; the interface will be exactly the same (org.fd.WirelessAudio or whatever) but the services providing them will differ e.g. org.bluez.Audio, org.wusb.Audio and so. The main consumer for Fedora of this, PulseAudio, thus does not need to care at all about the _implementation_ (only the interface) and it will enable us to plug new wireless protocols in without modifying any consumers.) David From izhar at fedoraproject.org Fri Oct 26 12:50:22 2007 From: izhar at fedoraproject.org (Mohd Izhar Firdaus Ismail) Date: Fri, 26 Oct 2007 20:50:22 +0800 Subject: Request for inclusion of compizconfig-python and ccsm into F-8 In-Reply-To: <59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com> References: <1193248515.22958.111.camel@localhost.localdomain> <471FA22C.8060105@redhat.com> <59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com> Message-ID: On 10/25/07, Kristian H?gsberg wrote: > On 10/24/07, Warren Togami wrote: > > Tom "spot" Callaway wrote: > > > On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote: > > >> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8 > > >> Request description: Inclusion into Fedora 8 final > > >> > > >> Rationale: > >> Compiz Fusion has been one of the major attraction to Linux lately, > > >> and with Ubuntu already providing CF out of the box, users will expect > > >> other distros to have it too. There no full featured configurator for > > >> current compiz-fusion in F-8. > > >> > > >> Impact not accepting: > > >> Users will have to use gconf-editor to configure compiz-fusion > > >> manually. Marketing value might be affected. > > >> > > >> Others: > > >> current compiz in F-8 uses 'glib gconf' as its configuration > > >> backend, if FedoraProject decided to use libcompizconfig as the > > >> configuration backend, changes are needed in desktop-effects and > > >> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM > > >> requires compiz to use 'ccp' for it to function properly. > > > > > > +1 > > > > > > > Spot, did you notice that this requires changes to desktop-effects and > > gnome-session? It sounds like they expect it to be part of the default > > install, not just an add-on to the compiz of today. Is the desktop team > > aware and in agreement with these changes? > > This has come up before, and while it would be nice to have a more > capable configuration program for compiz the current libcompizconfig > is not the right solution. Ideally we would have a configuration > application per desktop environment and the GNOME configurator would > just talk to gconf directly, similarly for the KDE configurator. > > If somebody wants to write a settings manager that works with several > DEs, I think the burden is on the settings manager to talk to the > different configuration systems it wants to operate under. Or this > could be part of libcompizconfig, so that setting managers that want > to be DE-agnostic can just link to this library and not worry about > the underlying config mechanism in use. > > The current compiz setup is compatible with the above scheme, somebody > just need to do the necessary libcompizconfig adjustments. Thanks Kristian for the input .. compizconfig-backend-gconf-0.6.0-2.fc8 has just been built in koji (i couldnt build it before due to waiting for libcompizconfig-0.6.0-3.fc8 to get into the buildroot) .. if we include that together on F-8 , it will be running properly on GNOME according to your plans right? -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From jkeating at redhat.com Sun Oct 28 02:54:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 27 Oct 2007 22:54:17 -0400 Subject: Detecting dbus session Message-ID: <20071027225417.3833101c@redhat.com> I'm trying to write a couple NetworkManager Dispatcher calls to futz with a few things that don't yet have NM capabilities. However I'm running into a snag, particularly with pidgin. Pidgin has a purple-remote call that uses dbus. nm-dispatcher runs as root so I have to switch to my user to accomplish things (currently via su - -c "command args"). Seems though that a 'su - ' from root doesn't add the DBUS_SESSION_BUS_ADDRESS env entry, and purple-remote can't find dbus or can't find pidgin on the bus. How can I programmatically figure out what the dbus address is, or otherwise accomplish what I'm trying to do? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sun Oct 28 05:10:37 2007 From: dcbw at redhat.com (Dan Williams) Date: Sun, 28 Oct 2007 01:10:37 -0400 Subject: Detecting dbus session In-Reply-To: <20071027225417.3833101c@redhat.com> References: <20071027225417.3833101c@redhat.com> Message-ID: <1193548237.7779.6.camel@localhost.localdomain> On Sat, 2007-10-27 at 22:54 -0400, Jesse Keating wrote: > I'm trying to write a couple NetworkManager Dispatcher calls to futz > with a few things that don't yet have NM capabilities. However I'm > running into a snag, particularly with pidgin. Pidgin has a > purple-remote call that uses dbus. nm-dispatcher runs as root so I > have to switch to my user to accomplish things (currently via su - > -c "command args"). Seems though that a 'su - ' from root > doesn't add the DBUS_SESSION_BUS_ADDRESS env entry, and purple-remote > can't find dbus or can't find pidgin on the bus. > > How can I programmatically figure out what the dbus address is, or > otherwise accomplish what I'm trying to do? This sounds pretty wrong; root isn't supposed to know about the session bus, and you're going to have a very hard time finding out the address of some random user session bus by design. If you want to do stuff from your user session, the best bet is to have a session-bus dispatcher daemon. Can you just clone the DBus Example Plugin from pidgin and make it do what you want? dan From abo at kth.se Sun Oct 28 09:10:28 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 28 Oct 2007 10:10:28 +0100 Subject: Detecting dbus session In-Reply-To: <1193548237.7779.6.camel@localhost.localdomain> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> Message-ID: <1193562628.9273.57.camel@home.alexander.bostrom.net> s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams: > This sounds pretty wrong; root isn't supposed to know about the > session > bus, and you're going to have a very hard time finding out the address > of some random user session bus by design. Yup. And a user might have multiple sessions on a single computer. Think multiple logins to the guest account, or one log in through GDM and one session established via ssh. Stuff like that happens. /abo From jkeating at redhat.com Sun Oct 28 11:53:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 28 Oct 2007 07:53:50 -0400 Subject: Detecting dbus session In-Reply-To: <1193562628.9273.57.camel@home.alexander.bostrom.net> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> Message-ID: <20071028075350.281fffcd@redhat.com> On Sun, 28 Oct 2007 10:10:28 +0100 Alexander Bostr?m wrote: > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams: > > This sounds pretty wrong; root isn't supposed to know about the > > session > > bus, and you're going to have a very hard time finding out the > > address of some random user session bus by design. > > Yup. And a user might have multiple sessions on a single computer. > Think multiple logins to the guest account, or one log in through GDM > and one session established via ssh. Stuff like that happens. If this is the case, then wouldn't it make sense to have a NetworkManagerDispatcher option to run things in the active session? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sun Oct 28 21:02:57 2007 From: dcbw at redhat.com (Dan Williams) Date: Sun, 28 Oct 2007 17:02:57 -0400 Subject: Detecting dbus session In-Reply-To: <20071028075350.281fffcd@redhat.com> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> <20071028075350.281fffcd@redhat.com> Message-ID: <1193605377.16758.1.camel@localhost.localdomain> On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote: > On Sun, 28 Oct 2007 10:10:28 +0100 > Alexander Bostr?m wrote: > > > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams: > > > This sounds pretty wrong; root isn't supposed to know about the > > > session > > > bus, and you're going to have a very hard time finding out the > > > address of some random user session bus by design. > > > > Yup. And a user might have multiple sessions on a single computer. > > Think multiple logins to the guest account, or one log in through GDM > > and one session established via ssh. Stuff like that happens. > > If this is the case, then wouldn't it make sense to have a > NetworkManagerDispatcher option to run things in the active session? Except for the fact that as root, NMD can't find out the session bus address, nor should it be able to. Dan From abo at kth.se Sun Oct 28 22:26:59 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 28 Oct 2007 23:26:59 +0100 Subject: Detecting dbus session In-Reply-To: <20071028075350.281fffcd@redhat.com> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> <20071028075350.281fffcd@redhat.com> Message-ID: <1193610419.9273.77.camel@home.alexander.bostrom.net> s?n 2007-10-28 klockan 07:53 -0400 skrev Jesse Keating: > > Yup. And a user might have multiple sessions on a single computer. > > Think multiple logins to the guest account, or one log in through > GDM > > and one session established via ssh. Stuff like that happens. > > If this is the case, then wouldn't it make sense to have a > NetworkManagerDispatcher option to run things in the active session? I really don't know enough about NM and DBus to understand all the issues, but perhaps it's better if such things go through the system bus? If root or some part of the system wants to tell me something, I should have something that hooks up to the system bus and accepts input of that kind. Would that work? There could be several of those on each system, for different sessions and different users. /abo From alexl at redhat.com Mon Oct 29 09:51:29 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 29 Oct 2007 10:51:29 +0100 Subject: Detecting dbus session In-Reply-To: <1193605377.16758.1.camel@localhost.localdomain> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> <20071028075350.281fffcd@redhat.com> <1193605377.16758.1.camel@localhost.localdomain> Message-ID: <1193651489.14445.32.camel@dhcp-208-188.arn.redhat.com> On Sun, 2007-10-28 at 17:02 -0400, Dan Williams wrote: > On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote: > > On Sun, 28 Oct 2007 10:10:28 +0100 > > Alexander Bostr?m wrote: > > > > > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams: > > > > This sounds pretty wrong; root isn't supposed to know about the > > > > session > > > > bus, and you're going to have a very hard time finding out the > > > > address of some random user session bus by design. > > > > > > Yup. And a user might have multiple sessions on a single computer. > > > Think multiple logins to the guest account, or one log in through GDM > > > and one session established via ssh. Stuff like that happens. > > > > If this is the case, then wouldn't it make sense to have a > > NetworkManagerDispatcher option to run things in the active session? > > Except for the fact that as root, NMD can't find out the session bus > address, nor should it be able to. Can't something in the desktop connect to the session bus and get a callback when a dispatch happens there, which it then proxies to a list of session bus dispatchers. From caillon at redhat.com Mon Oct 29 13:53:48 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 29 Oct 2007 14:53:48 +0100 Subject: Desktop SIG meeting tomorrow In-Reply-To: <471F1CDB.8090502@redhat.com> References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com> Message-ID: <4725E5EC.6030103@redhat.com> Christopher Aillon wrote: > Matthias Clasen wrote: >> I will most likely not around tomorrow, so interested people will have >> to self-organize and find something useful to talk about. One topic that >> I'll throw on the agenda: >> >> We should pick a different time for the sig meeting, because several >> people (jrb, mcepl) said that they have difficulty making the current >> time. And from now on, I will only be available until 2:15 on most >> Wednesdays, too. > > http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > > So, I had a look at the schedule above. I propose to move it to 1500 > UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start that > schedule until next week since o/~ Tuesday's Gone... Like the Wind. o/~ Feedback would be nice :) From drago01 at gmail.com Mon Oct 29 14:02:59 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 29 Oct 2007 15:02:59 +0100 Subject: Desktop SIG meeting tomorrow In-Reply-To: <4725E5EC.6030103@redhat.com> References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com> <4725E5EC.6030103@redhat.com> Message-ID: <4725E813.8050905@gmail.com> Christopher Aillon wrote: > Christopher Aillon wrote: >> Matthias Clasen wrote: >>> I will most likely not around tomorrow, so interested people will have >>> to self-organize and find something useful to talk about. One topic >>> that >>> I'll throw on the agenda: >>> >>> We should pick a different time for the sig meeting, because several >>> people (jrb, mcepl) said that they have difficulty making the current >>> time. And from now on, I will only be available until 2:15 on most >>> Wednesdays, too. >> >> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel >> >> So, I had a look at the schedule above. I propose to move it to 1500 >> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start >> that schedule until next week since o/~ Tuesday's Gone... Like the >> Wind. o/~ > > Feedback would be nice :) > you asked for it ;) 1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok. From mclasen at redhat.com Mon Oct 29 14:07:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 29 Oct 2007 10:07:39 -0400 Subject: Desktop SIG meeting tomorrow In-Reply-To: <4725E813.8050905@gmail.com> References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com> <4725E5EC.6030103@redhat.com> <4725E813.8050905@gmail.com> Message-ID: <1193666859.4067.9.camel@localhost.localdomain> On Mon, 2007-10-29 at 15:02 +0100, dragoran wrote: > Christopher Aillon wrote: > > Christopher Aillon wrote: > >> Matthias Clasen wrote: > >>> I will most likely not around tomorrow, so interested people will have > >>> to self-organize and find something useful to talk about. One topic > >>> that > >>> I'll throw on the agenda: > >>> > >>> We should pick a different time for the sig meeting, because several > >>> people (jrb, mcepl) said that they have difficulty making the current > >>> time. And from now on, I will only be available until 2:15 on most > >>> Wednesdays, too. > >> > >> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > >> > >> So, I had a look at the schedule above. I propose to move it to 1500 > >> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start > >> that schedule until next week since o/~ Tuesday's Gone... Like the > >> Wind. o/~ > > > > Feedback would be nice :) > > > you asked for it ;) > 1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok. Those all work for me. I can't do later than 17:00 UTC (13:00 EST). From caillon at redhat.com Mon Oct 29 14:52:50 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 29 Oct 2007 15:52:50 +0100 Subject: Desktop SIG meeting tomorrow In-Reply-To: <4725E813.8050905@gmail.com> References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com> <4725E5EC.6030103@redhat.com> <4725E813.8050905@gmail.com> Message-ID: <4725F3C2.5050904@redhat.com> dragoran wrote: > Christopher Aillon wrote: >> Christopher Aillon wrote: >>> Matthias Clasen wrote: >>>> I will most likely not around tomorrow, so interested people will have >>>> to self-organize and find something useful to talk about. One topic >>>> that >>>> I'll throw on the agenda: >>>> >>>> We should pick a different time for the sig meeting, because several >>>> people (jrb, mcepl) said that they have difficulty making the current >>>> time. And from now on, I will only be available until 2:15 on most >>>> Wednesdays, too. >>> >>> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel >>> >>> So, I had a look at the schedule above. I propose to move it to 1500 >>> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start >>> that schedule until next week since o/~ Tuesday's Gone... Like the >>> Wind. o/~ >> >> Feedback would be nice :) >> > you asked for it ;) > 1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok. Except 1600 and 1700 are taken... From davidz at redhat.com Mon Oct 29 14:54:27 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 29 Oct 2007 10:54:27 -0400 Subject: Detecting dbus session In-Reply-To: <1193605377.16758.1.camel@localhost.localdomain> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> <20071028075350.281fffcd@redhat.com> <1193605377.16758.1.camel@localhost.localdomain> Message-ID: <1193669667.2969.6.camel@oneill.fubar.dk> On Sun, 2007-10-28 at 17:02 -0400, Dan Williams wrote: > On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote: > > On Sun, 28 Oct 2007 10:10:28 +0100 > > Alexander Bostr?m wrote: > > > > > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams: > > > > This sounds pretty wrong; root isn't supposed to know about the > > > > session > > > > bus, and you're going to have a very hard time finding out the > > > > address of some random user session bus by design. > > > > > > Yup. And a user might have multiple sessions on a single computer. > > > Think multiple logins to the guest account, or one log in through GDM > > > and one session established via ssh. Stuff like that happens. > > > > If this is the case, then wouldn't it make sense to have a > > NetworkManagerDispatcher option to run things in the active session? > > Except for the fact that as root, NMD can't find out the session bus > address, nor should it be able to. Plus lots of other things as it would have to change user / selinux context etc. etc. I think maybe you want nm-applet (or a NMD with a --session option) to just run stuff from /etc/NetworkManager/session-dispatcher.d/ as the user of the session. Then the natural progression is that you also want ~/.NetworkManager/session-dispatcher.d so an unprivileged user can drop stuff in his own home directory that gets run on events. Thoughts? David From jkeating at redhat.com Mon Oct 29 15:35:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Oct 2007 11:35:44 -0400 Subject: Detecting dbus session In-Reply-To: <1193669667.2969.6.camel@oneill.fubar.dk> References: <20071027225417.3833101c@redhat.com> <1193548237.7779.6.camel@localhost.localdomain> <1193562628.9273.57.camel@home.alexander.bostrom.net> <20071028075350.281fffcd@redhat.com> <1193605377.16758.1.camel@localhost.localdomain> <1193669667.2969.6.camel@oneill.fubar.dk> Message-ID: <20071029113544.252f1dd2@redhat.com> On Mon, 29 Oct 2007 10:54:27 -0400 David Zeuthen wrote: > /etc/NetworkManager/session-dispatcher.d/ > > as the user of the session. Then the natural progression is that you > also want > > ~/.NetworkManager/session-dispatcher.d > > so an unprivileged user can drop stuff in his own home directory that > gets run on events. Thoughts? Seems right to me. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Mon Oct 29 22:15:22 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 29 Oct 2007 23:15:22 +0100 Subject: The KDE-SIG needs (your) help Message-ID: <200710292315.23149.ml@deadbabylon.de> This is a request for participation: The KDE-SIG [1] is atm lacking active contributors. And we really need some help in doing our job to provide a good KDE version in Fedora - especially with the upcoming KDE 4.0 and the inclusion in Fedora 9. If you don't know how you could help us here is a list (which is also in the wiki): * Packagers: There are so many interesting packages that are not yet packaged for Fedora. Package it to improve the user experience. * Reviewers: Only a few persons are doing the kde-related reviews. Help us reviewing so that more packages could be included. * Testers: If you love KDE use the development version or the updates-testing repository and report bugs, bugs, bugs, request enhancements or features. We need your feedback to improve KDE. * Bugs: Become a BugZapper and help us with kde-related bugs. * Documentation writers: The documentation (esp. the DesktopUserGuide) is GNOME-centered. Help us to provide an equivalent for KDE. * Release Notes: The few people that are working on the new KDE-Spin are quite busy with development issues. If you want to help us in writing the release notes for the next version of Fedora we would give you all the info you need. * Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated with end user information. * Artists: To provide a matching theme for nodoka-metacity-theme and provide an unified desktop experience. But this is not a complete list. If you're interested in making KDE in Fedora better, you're more than welcome. The list of participants in the wiki is atm not a list of active contributors. When setting up the wiki the only demand was an interest in KDE to be listed on this page. This list would be changed in the future to be culled down to the list of active (or reactivated) participants. This has become necessarely because there are only (less or more) 3 active contributors atm (plus Than Ngo). But the list indicates that there are enough people helping with KDE. If you are interested in joining the KDE-SIG please add your name to this list, answer to this mail, join us in #fedora-kde at freenode or attend the weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic to the agenda of the meeting next week to introduce new contributors. [2] The attendance at the SIG-Meetings is of course not required. But this way we would know of each other. And they are also the main place of discussing the next steps in the development (besides fedora-devel-list). If you have any further questions please answer to this mail or write me directly. And be sure: If your are willing to help you're welcome (regardless of your skills). :) Sebastian [1] http://fedoraproject.org/wiki/SIGs/KDE [2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mark.bidewell at alumni.clemson.edu Tue Oct 30 13:47:01 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Tue, 30 Oct 2007 09:47:01 -0400 Subject: The KDE-SIG needs (your) help In-Reply-To: <200710292315.23149.ml@deadbabylon.de> References: <200710292315.23149.ml@deadbabylon.de> Message-ID: I am certainly interested in helping with KDE. Is there any way to use testing kde without using full rawhide? Thanks. Mark Bidewell On 10/29/07, Sebastian Vahl wrote: > > This is a request for participation: > The KDE-SIG [1] is atm lacking active contributors. And we really need > some > help in doing our job to provide a good KDE version in Fedora - especially > with the upcoming KDE 4.0 and the inclusion in Fedora 9. > > If you don't know how you could help us here is a list (which is also in > the > wiki): > > * Packagers: There are so many interesting packages that are not yet > packaged > for Fedora. Package it to improve the user experience. > > * Reviewers: Only a few persons are doing the kde-related reviews. Help us > reviewing so that more packages could be included. > > * Testers: If you love KDE use the development version or the > updates-testing > repository and report bugs, bugs, bugs, request enhancements or features. > We > need your feedback to improve KDE. > > * Bugs: Become a BugZapper and help us with kde-related bugs. > > * Documentation writers: The documentation (esp. the DesktopUserGuide) is > GNOME-centered. Help us to provide an equivalent for KDE. > > * Release Notes: The few people that are working on the new KDE-Spin are > quite > busy with development issues. If you want to help us in writing the > release > notes for the next version of Fedora we would give you all the info you > need. > > * Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated > with > end user information. > > * Artists: To provide a matching theme for nodoka-metacity-theme and > provide > an unified desktop experience. > > But this is not a complete list. If you're interested in making KDE in > Fedora > better, you're more than welcome. > > > The list of participants in the wiki is atm not a list of active > contributors. > When setting up the wiki the only demand was an interest in KDE to be > listed > on this page. This list would be changed in the future to be culled down > to > the list of active (or reactivated) participants. This has become > necessarely > because there are only (less or more) 3 active contributors atm (plus Than > Ngo). But the list indicates that there are enough people helping with > KDE. > > > If you are interested in joining the KDE-SIG please add your name to this > list, answer to this mail, join us in #fedora-kde at freenode or attend > the > weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic > to > the agenda of the meeting next week to introduce new contributors. [2] > The attendance at the SIG-Meetings is of course not required. But this way > we > would know of each other. And they are also the main place of discussing > the > next steps in the development (besides fedora-devel-list). > > > If you have any further questions please answer to this mail or write me > directly. And be sure: If your are willing to help you're welcome > (regardless > of your skills). :) > > Sebastian > > > [1] http://fedoraproject.org/wiki/SIGs/KDE > [2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06 > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Tue Oct 30 13:55:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Oct 2007 09:55:43 -0400 Subject: The KDE-SIG needs (your) help In-Reply-To: References: <200710292315.23149.ml@deadbabylon.de> Message-ID: <20071030095543.3edce776@redhat.com> On Tue, 30 Oct 2007 09:47:01 -0400 "Mark Bidewell" wrote: > I am certainly interested in helping with KDE. Is there any way to > use testing kde without using full rawhide? Using Live images is excellent for testing without commitment. You can boot a live image and use it all you want without replacing the installed operating system on your hardware. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From angazi2181 at hotmail.com Tue Oct 30 19:39:47 2007 From: angazi2181 at hotmail.com (Jack Badger) Date: Wed, 31 Oct 2007 06:39:47 +1100 Subject: The KDE-SIG needs (your) help IDEAZ PEOPS In-Reply-To: Message-ID: Although i'm fairly new to the team here, and to the linux thing as a whole, i have a theory for a UI that could see linux through to a professional and more 3d based operating system, including maybe even full support for new release games, software and hardware. if you want me to tell more, just mail me back. Jah Dave _________________________________________________________________ Advertisement: Search for local singles online at Lavalife http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT From angazi2181 at hotmail.com Tue Oct 30 19:43:28 2007 From: angazi2181 at hotmail.com (Jack Badger) Date: Wed, 31 Oct 2007 06:43:28 +1100 Subject: Detecting dbus session In-Reply-To: <20071029113544.252f1dd2@redhat.com> Message-ID: such strange logic you have maybe its best to redesign the gui completely? >From: Jesse Keating >Reply-To: Discussions about development for the Fedora desktop > >To: fedora-desktop-list at redhat.com >Subject: Re: Detecting dbus session >Date: Mon, 29 Oct 2007 11:35:44 -0400 > >On Mon, 29 Oct 2007 10:54:27 -0400 >David Zeuthen wrote: > > > /etc/NetworkManager/session-dispatcher.d/ > > > > as the user of the session. Then the natural progression is that you > > also want > > > > ~/.NetworkManager/session-dispatcher.d > > > > so an unprivileged user can drop stuff in his own home directory that > > gets run on events. Thoughts? > > >Seems right to me. > >-- >Jesse Keating >Fedora -- All my bits are free, are yours? ><< signature.asc >> >-- >Fedora-desktop-list mailing list >Fedora-desktop-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-desktop-list _________________________________________________________________ Advertisement: Make shopping exciting. Join eBay for free @ www.eBay.com.au http://direct.ninemsn.com.au/adclick/CID=02fda8540000000000000000 From davidz at redhat.com Tue Oct 30 20:54:07 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 30 Oct 2007 16:54:07 -0400 Subject: Detecting dbus session In-Reply-To: References: Message-ID: <1193777647.2899.18.camel@oneill.fubar.dk> Hi, On Wed, 2007-10-31 at 06:43 +1100, Jack Badger wrote: > such strange logic you have > > maybe its best to redesign the gui completely? There's nothing strange about this; it's just the classic "split code into mechanism and policy" pattern that is widely accepted as a secure practice throughout computing. David From angazi2181 at hotmail.com Tue Oct 30 20:59:39 2007 From: angazi2181 at hotmail.com (Jack Badger) Date: Wed, 31 Oct 2007 07:59:39 +1100 Subject: Detecting dbus session In-Reply-To: <1193777647.2899.18.camel@oneill.fubar.dk> Message-ID: thats not what i was getting at really, but yea, i get that now anyway. i'm sort of new to the whole linux thing, and im not that big on coding, i've really only done 3d related, and maybe some visual basic, and some c++, nothing too deep. designing GUI's is my thing, thats what im good at. ive done a few, none of them have really been adapted for commercial use, but thats mostly because they're been build around a 3d interface, annd weren't practical at the time... >From: David Zeuthen >Reply-To: Discussions about development for the Fedora desktop > >To: Discussions about development for the Fedora desktop > >Subject: Re: Detecting dbus session >Date: Tue, 30 Oct 2007 16:54:07 -0400 > > >Hi, > >On Wed, 2007-10-31 at 06:43 +1100, Jack Badger wrote: > > such strange logic you have > > > > maybe its best to redesign the gui completely? > >There's nothing strange about this; it's just the classic "split code >into mechanism and policy" pattern that is widely accepted as a secure >practice throughout computing. > > David > > >-- >Fedora-desktop-list mailing list >Fedora-desktop-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-desktop-list _________________________________________________________________ Advertisement: It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT